Остановите звонки домой с Windows Server 2012, Foundation Edition.
На DELL PowerEdge T110 II предустановленная Windows Server 2012 R2 (базовая версия) продолжает запрашивать страницу limwinsemea02.mfg.ie.dell.com через http-порт 80. Это известно из-за журнала брандмауэра, который регистрирует ~250 тыс. заблокированные запросы через несколько месяцев. До сих пор мне не удалось выяснить, какой компонент / процесс службы / запуска вызывает это. Что мне нужно настроить, удалить или отключить, чтобы такое поведение "телефона домой" прекратилось, не влияя на нормальную работу сервера?
РЕДАКТИРОВАТЬ: монитор процесса sysinternals показал это:
порт 80 был неверной интерпретацией или предположением. это передача UDP в направлении 163.244.79.191 через известный порт "netbios-ns" (десятичное число 137). Этот IP-адрес находится в диапазоне, назначенном "Dell, Inc.".
PID 4 = "Система", стек показывает, что помимо ntoskrnl.exe, участвуют netbt.sys и tdx.sys.
Теперь я понимаю, что протокол netbios задействован, но почему (и где) он настроен для заполнения этого адреса DELL несколькими соединениями в секунду?
РЕДАКТИРОВАТЬ 2: где бы ни сохранялся домен или IP-адрес, его нет в реестре. или взбитый.
2 ответа
Протокол, использующий порт 137 (разрешение имен netbios), работает с использованием широковещательных сообщений в пределах локальной сети. Это не маршрутизируемый. Многие люди, использующие VPN на своих рабочих местах, жалуются на то, что им не удается разрешить сетевые имена своих рабочих компьютеров, и им предлагаются идеи разместить один или несколько DNS-серверов здесь и там, чтобы преодолеть это ограничение. Или купить конкретный VPN-маршрутизатор, который позволяет SMB через VPN.
В последний раз я видел, как кто-то открывал свой порт 137 (8 или 9) для публичной сети, примерно в 1998–1999 годах, когда мы использовали коммутируемый доступ в Интернет по линиям POTS, фактически открывая себя всем, о ностальгия. Таким образом, DELL, вероятно, не имеет его открытым.
В свете этого я вижу малую вероятность того, что это преднамеренная "домашняя телефонная связь". Системный процесс PID4, на котором размещены некоторые сетевые службы, позволяет NetBios (SMB) бомбардировать всех, кого он может, через свой порт 137, чтобы, например, объявить имя netbios сервера и тип узла. Затем соединение остается на короткое время в каком-то конечном состоянии, например, TIME_WAIT. Реальный вопрос заключается в том, почему, черт возьми, MS по-прежнему позволяет Windows делать то, что 16 лет назад считалось глупым (см. 7-й и 8-й пост в этой теме, где упоминалось, что журналы брандмауэра полны разорванных SMB-соединений).
Я думаю, что какое-то приложение на вашем сервере могло искать обновления, и именно так сервер кэшировал этот IP-адрес, который затем был предметом поведения NetBios, который действительно является виновником ИМХО.
Я вполне уверен, что Process Monitor от sysinternals позволит вам собирать данные, чтобы показать, какой процесс делает запрос DNS для этого местоположения.
Если вы используете его для захвата сетевой активности, вы увидите PID и имя процесса. Затем ищите UDP-пакеты, вам нужно будет ввести "исходный IP:53", идущий на DNS-сервер, а затем реальный домен - я сильно подозреваю, что вам придется немного поработать с этим, чтобы все заработало, хотя и извините,