В основном у нас есть Exchange 2013 на основном сайте с ролями CAS и почтовых ящиков, и предположительно все пользователи подключаются к этому обмену из своего Outlook.
Теперь мы установили другой Exchange 2013 на сайте DR .. Наш главный офис и сайт аварийного восстановления соединены мостом Layer2, поэтому два коммутатора подключены к одному домену и также находятся в одной сетевой подсети. Таким образом, два сервера Exchange имеют по одной сетевой карте на каждом из них, которая является сетью LAN / домена.
Мы создали группу DAG, и репликация баз данных работает нормально ... но проблема, с которой мы сейчас сталкиваемся, заключается в том, что некоторые пользователи подключаются напрямую к DR Exchange из нашего главного офиса со своим Outlook, что не является тем, что мы хотели бы иметь. Мы хотим, чтобы DR размещал копию БД и активировался только в случае возникновения каких-либо проблем на основном сайте, и мы приходится переключать все на сайте аварийного восстановления вручную.
Мы заметили эту проблему, когда пошли проверять статус подключения в их Outlook и заметили, что прокси-сервер, к которому они подключены, является обменом аварийного восстановления. Запуск Nmap 6.47 (http://nmap.org) в 2015-12-28 12:14 CET Отчет о сканировании Nmap для localhost (127.0.0.1) Хост включен (0 ....
Запуск nmap на моем локальном хосте показывает мне странные открытые порты:
$ nmap -p- localhost
Starting Nmap 6.47 ( http://nmap.org ) at 2015-12-28 12:14 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00047s latency).
All 65535 scanned ports on localhost (127.0.0.1) are closed
Nmap done: 1 IP address (1 host up) scanned in 2.51 seconds
$ nmap -p- localhost
Starting Nmap 6.47 ( http://nmap.org ) at 2015-12-28 12:14 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00046s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE
36642/tcp open unknown
50826/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 2.55 seconds
$ nmap -p- localhost
Starting Nmap 6.47 ( http://nmap.org ) at 2015-12-28 12:14 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00050s latency).
Not shown: 65531 closed ports
PORT STATE SERVICE
37700/tcp open unknown
46694/tcp open unknown
48334/tcp open unknown
53438/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 2.60 seconds
$ nmap -p- localhost
Starting Nmap 6.47 ( http://nmap.org ) at 2015-12-28 12:14 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00046s latency).
All 65535 scanned ports on localhost (127.0.0.1) are closed
Nmap done: 1 IP address (1 host up) scanned in 2.51 second
Как видно из этого вывода, открытые порты меняются быстро и случайным образом. Я не могу видеть эти порты через netstat, если я я правильно интерпретирую вывод:
$ sudo netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN 0 17081 809/dnsmasq
udp 0 0 0.0.0.0:5449 0.0.0.0:* 0 30885 2855/dhclient
udp 0 0 127.0.1.1:53 0.0.0.0:* 0 17080 809/dnsmasq
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 30321 2855/dhclient
udp 0 0 0.0.0.0:45170 0.0.0.0:* 107 15289 606/avahi-daemon: r
udp 0 0 0.0.0.0:631 0.0.0.0:* 0 15931 636/cups-browsed
udp 0 0 0.0.0.0:5353 0.0.0.0:* 107 15287 606/avahi-daemon: r
udp6 0 0 :::34146 :::* 107 15290 606/avahi-daemon: r
udp6 0 0 :::55654 :::* 0 30886 2855/dhclient
udp6 0 0 :::5353 :::* 107 15288 606/avahi-daemon: r
Я попытался использовать lsof для исследования этих портов, но результата нет, я думаю, когда Nmap вернется, порт больше не будет открыт:
lsof -i :`nmap -p- localhost|grep '/tcp'|cut -d'/' -f1|head -n1`
Что я могу сделать для дальнейшего исследовать эту проблему? Должен ли я беспокоиться? Это нормально? Следует ли мне подозревать, что запущены какие-либо вредоносные процессы?
Обратите внимание, что эти вопросы и ответы отличаются, поскольку я запускаю все на своем локальном компьютере.
Это ошибка в Nmap 6.40 - 6.47, которую я подробно обсудил в в ответе на StackOverflow. Она была исправлена с 6.49BETA-серии, поэтому обновление до последнего Nmap (7.01 на момент написания этой статьи) решит эту проблему.