Entrées ARP dynamiques se transformant en entrées ARP statiques

J'ai récemment acquis un client qui a un étrange problème de mise en cache ARP sur l'un de leurs serveurs.

J'ai un serveur qui finira par transformer ses entrées ARP dynamiques en entrées ARP statiques. Cela provoque des problèmes car lorsque la machine qui possède des entrées ARP statiques sur ce serveur reçoit une nouvelle adresse IP via DHCP, le serveur n'est pas en mesure de communiquer avec les clients. L'effacement du cache ARP résout le problème et le serveur fonctionne bien pendant environ une semaine, puis il commence lentement à transformer les entrées ARP en entrées ARP statiques. Je ne l'ai pas limité à quand ou à combien il commence à le faire, mais lentement vous commencez à voir 1 ARP statique puis 5 puis 10.

Le serveur en question est un Windows Server 2003 SP2. Il s'agit d'un serveur DC, DHCP et DNS. J'ai vérifié les options de portée DHCP et il n'y a rien là-dedans qui indiquerait quoi que ce soit à voir avec les entrées statiques ARP. La seule différence entre ce serveur DNS et notre autre serveur DNS est que les `` enregistrements ADN A et PTR à mise à jour dynamique pour les clients DHCP qui ne demandent pas de mises à jour '' sont vérifiés sur le serveur problématique.

J'ai fait un peu de recherche à ce sujet et il semble que cela puisse se produire si des services de type PXE sont en cours d'exécution, d'après ce que je peux dire, il n'y a rien qui exécute un serveur PXE.

Je suis un peu perdu car je n'ai jamais vu des entrées ARP dynamiques commencer à se transformer en entrées ARP statiques. À l'heure actuelle, ma solution est une tâche de planification qui s'exécute toutes les 24 heures pour vider le cache ARP (arp -d *). Je ne voudrais pas me fier à cette tâche de planification.

Quelqu'un a-t-il déjà vu cela ou a-t-il des suggestions sur la façon de résoudre ce problème?

Cela pourrait être bénin ou malin. Espérons bénin: il y a quelque chose en cours d'exécution sur votre machine qui pense qu'il sait mieux qu'ARP et met à jour la table ARP "à la main". Je soupçonne quelque chose comme un pare-feu ou un autre type de programme de protection des points d'extrémité, mais si vous ne pouvez vraiment pas le retrouver en examinant ce qui est installé, votre seul recours est de casser des outils d'audit robustes comme WPR / WPA ou ProcessInternals, laissez-les faire leur chose, puis lier les événements.

Cela pourrait être néfaste: une attaque classique d'homme au milieu consiste à envoyer un ARP prétendant être Alice quand vous êtes vraiment Bob: tout le monde met à jour son cache et à partir de là, tous ceux qui envoient à Alice pensent qu'ils lui parlent alors qu'en fait leur trafic va à Bob. Ou (d'une autre manière) quelqu'un s'introduit dans votre machine et configure des ARP statiques sur les "mauvaises" cibles.

Une ancienne stratégie pour vaincre la première, btw, consiste à configurer des entrées ARP statiques pour toutes les cibles locales auxquelles vous souhaitez parler. Pour le second, eh bien, si l'attaquant est sur votre machine, il est trop tard.

Je l'ai rencontré il y a quelques années lorsque j'ai installé des pare-feu redondants pour un client. Leur serveur 2003 devait être retiré une fois le nouveau contrôleur de domaine installé, j'ai donc mis un correctif temporaire pour vider le cache arp toutes les 2 minutes. J'ai juste utilisé le planificateur de tâches pour exécuter "arp -d" toutes les deux minutes, donc si les pare-feu changeaient de responsabilités, le contrôleur de domaine aurait toujours accès à Internet pour les services DNS.