Динамические ARP-записи, превращающиеся в статические ARP-записи

Недавно я приобрел клиента, у которого странная проблема с кэшированием ARP на одном из их серверов.

У меня есть сервер, который в конечном итоге начнет превращать свои динамические записи ARP в статические записи ARP. Это вызывает проблемы, потому что, когда машина, имеющая записи статического ARP на этом сервере, получает новый IP через DHCP, сервер не может обмениваться данными с клиентами. Очистка кэша ARP решает проблему, и сервер работает нормально в течение недели, а затем начинает медленно превращать записи ARP в статические записи ARP. Я не ограничил это тем, когда и сколько он начинает делать, но постепенно вы начинаете видеть 1 статический ARP, затем 5 и затем 10.

Рассматриваемый сервер - Windows Server 2003 SP2. Это сервер DC, DHCP и DNS. Я проверил параметры области DHCP, и там нет ничего, что указывало бы на что-либо, связанное со статическими записями ARP. Единственное отличие между этим DNS-сервером и другим DNS-сервером состоит в том, что на проблемном сервере проверяется «Динамическое обновление записей DNA A и PTR для клиентов DHCP, которые не запрашивают обновления».

Я провел небольшое исследование по этому поводу, и кажется, что это может произойти, если запущены какие-либо службы типа PXE, из того, что я могу сказать, ничто не работает на сервере PXE.

Я немного растерялся, потому что никогда не видел, чтобы динамические записи ARP начинали превращаться в статические записи ARP. В настоящее время мое решение представляет собой задачу расписания, которая выполняется каждые 24 часа для очистки кэша ARP (arp -d *). Я не хотел бы полагаться на эту задачу графика.

Кто-нибудь видел это раньше или есть какие-либо предложения о том, как решить эту проблему?

Это может быть доброкачественным или злокачественным. Будем надеяться на доброту: на вашей машине работает что-то, что думает, что знает лучше, чем ARP, и обновляет таблицу ARP «вручную». Я подозреваю что-то вроде брандмауэра или другого типа программы защиты конечных точек, но если вы действительно не можете отследить это, просматривая то, что установлено, то единственный выход - это использовать мощные инструменты аудита, такие как WPR / WPA или ProcessInternals, позволить им сделать свое дело, а затем связать события обратно.

Это может быть злонамеренно: классическая атака «человек посередине» состоит в том, чтобы разослать ARP, претендующий на роль Алисы, когда вы действительно Боб: каждый обновляет свой кеш, и с тех пор все, кто отправляет Алисе, думают, что разговаривают с ней. когда на самом деле их движение идет к Бобу. Или (иным способом) кто-то вломится в вашу машину и настроит статические ARP для «неправильных» целей.

Старая стратегия победы над первым, кстати, состоит в том, чтобы настроить статические записи ARP для всех локальных целей, с которыми вы хотите общаться. Во-вторых, хорошо, если злоумышленник находится на вашей машине, уже слишком поздно.

Я столкнулся с этим пару лет назад, когда я установил избыточные брандмауэры для клиента. Их сервер 2003 года был отведен для удаления после установки нового контроллера домена, поэтому я добавил временное исправление для сброса кэша arp каждые 2 минуты. Я просто использовал планировщик задач для запуска «arp -d» каждые пару минут, поэтому, если брандмауэры поменяли обязанности, DC все равно имел бы доступ в Интернет для служб DNS.