Connaissez-vous les voisins de votre réseau ?

En tant qu'administrateur d'un système VOS, vous ne vous souciez généralement pas de savoir quels sont les autres hôtes du sous-réseau local. Vous vous souciez des passerelles qui sont configurées et, bien sûr, des hôtes locaux qui communiquent avec votre système, mais les autres hôtes sont en dessous de votre radar. Il y a cependant deux très bonnes raisons de savoir qui sont vos voisins de réseau. Premièrement, en cas de problème de communication, vous pouvez utiliser ces autres hôtes pour tester votre connexion réseau. Deuxièmement, ce sont les hôtes qui sont les plus susceptibles d'être les sources de tout type d'attaque basée sur le réseau.

Ce n'est pas une mauvaise idée de scanner le sous-réseau local de temps en temps (disons tous les mercredis matin) juste pour voir qui est là. VOS n'a pas de scanner intégré, mais il dispose de la commande ping qui, lorsqu'elle est entourée de quelques lignes d'une macro de commande, peut être transformée en scanner.

L'utilisation de ping pour rechercher des hôtes pose trois problèmes. Premièrement, ce n'est pas très efficace. Le délai par défaut est de 15 secondes et la commande essaiera 4 fois. Il faudra donc une minute pour rechercher un hôte qui n'est pas là ou qui ne répond pas aux pings. Heureusement, le nombre d'essais peut être réduit à 1 et le délai d'attente à 1 seconde. Ce n'est pas encore efficace du point de vue d'un outil de balayage dédié, mais je pense que c'est suffisant pour nos besoins.

Le deuxième problème est que tous les hôtes ne répondent pas aux pings. Ce n'est cependant pas un problème important car avec une seule ligne supplémentaire, notre macro de commande indiquera quels hôtes ont envoyé une réponse ARP. Les ARP sont utilisés pour mapper une adresse IP en une adresse MAC Ethernet et le VOS doit connaître l'adresse MAC Ethernet avant de pouvoir envoyer le ping. Il envoie donc une demande ARP à l'hôte cible et place les données de la réponse dans le cache ARP. Tous les hôtes répondront à la demande ARP par une réponse ARP même s'ils ne répondront pas à la demande ping suivante. La commande arp affichera l'entrée demandée s'il y en a une.

La macro de commande ci-dessus a les demandes et les réponses ping entremêlées avec les données ARP, elle n'est pas très lisible. La macro suivante produit un joli tableau de voisins dans un fichier nommé arp_scan.(date).out. Elle suppose un réseau de classe C, c'est-à-dire que les 3 premiers octets sont fixes et recherche les hôtes 1 à 254. Je vous suggère de l'exécuter comme un processus lancé.

Le délai d'attente du cache ARP est de 10 minutes. Si une entrée a un délai inférieur à 10 minutes, vous saurez que le module communiquait déjà avec cet hôte avant que l'analyse ne soit effectuée.

Le troisième problème est la plainte que vous pourriez recevoir de votre administrateur de réseau pour avoir scanné activement le réseau. S'il s'oppose à cette activité, vous pouvez l'analyser passivement en utilisant la commande packet monitor pour capturer les paquets de diffusion.

L'utilisation de cette technique repose sur la communication active et l'envoi d'émissions par les autres hôtes du réseau pendant le fonctionnement de packet_monitor. Si vous utilisez cette technique, vous devrez laisser fonctionner packet_monitor pendant un certain temps, dont la durée dépendra de votre réseau. Je vous suggère de placer la commande ci-dessus dans une macro de commande (packet_monitor_scan.cm) et de l'exécuter comme un processus lancé. N'oubliez pas d'exécuter le processus comme un processus privilégié.

Une fois que vous avez une trace, vous devez la convertir en un tableau d'adresses utilisable. La macro suivante s'en chargera (elle suppose que packet_monitor_scan était un processus lancé générant un fichier process_packet_monitor_scan.out).

qui donnera le tableau suivant.