Остановить OEM-инструменты 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 = «System», стек показывает, что помимо ntoskrnl.exe задействованы netbt.sys и tdx.sys.
Теперь я понимаю, что задействован протокол netbios, но почему (и где) он настроен на заливку этого адреса DELL несколькими подключениями в секунду?
РЕДАКТИРОВАТЬ 2 : где бы ни хранится домен или IP-адрес, его нет в реестре . или взбитый.
Протокол, использующий порт 137 (разрешение имен netbios), работает с широковещательной рассылкой в пределах локальной LAN. Это не маршрутизируемое. Многие люди, использующие VPN на рабочем месте, жалуются на то, что не могут разрешить сетевые имена своих рабочих компьютеров, и им предлагают разместить здесь и там один или несколько DNS-серверов, чтобы преодолеть это ограничение. Или купите специальный VPN-маршрутизатор, который позволяет SMB через VPN.
В последний раз я видел, как кто-то открывал свой порт 137 (8 или 9) для общедоступной сети примерно в 1998–1999 годах, когда мы использовали коммутируемый доступ в Интернет на линиях POTS, эффективно открывая себя для всех, о, ностальгия . Так что DELL , вероятно, не имеет его.
В свете этого я вижу малую вероятность того, что это преднамеренный «домашний телефон». Системный процесс PID4 , в котором размещены некоторые сетевые службы, позволяет NetBios (SMB) бомбардировать всех, кого он может, через порт 137, чтобы, например, объявить имя netbios сервера и тип узла. Затем соединение остается на короткое время в некотором конечном состоянии, например ВРЕМЯ ЖДЕТ. Настоящий вопрос заключается в том, почему, черт возьми, MS все еще позволяет Windows делать то, что 16 лет назад считалось глупым (см. 7-е и 8-е сообщения в этой ветке , где упоминается о том, что журналы брандмауэра заполнены прерванными соединениями SMB).
Я думаю , что какое-то приложение на вашем сервере могло искать обновления, и именно так сервер кэшировал этот IP-адрес, который затем был предметом поведения NetBios, которое на самом деле является виновником ИМХО.
Я достаточно уверен, что Process Monitor от sysinternals позволит вам захватывать данные, чтобы показать, какой процесс выполняет запрос DNS для этого местоположения.
Если вы используете это для захвата сетевой активности, вы увидите PID и имя процесса. Затем найдите UDP-пакеты, вам нужно будет ввести `` исходный IP: 53 '' для перехода к DNS-серверу, а затем фактический домен - я сильно подозреваю, что вам придется немного поработать с этим, чтобы все прошло правильно, хотя извините .