Kennen Sie Ihre Netzwerknachbarn?

Als Systemadministrator eines VOS-Systems ist es Ihnen normalerweise egal, welche anderen Hosts sich im lokalen Subnetz befinden. Sie interessieren sich für die konfigurierten Gateways und natürlich für alle lokalen Hosts, die mit Ihrem System kommunizieren, aber die anderen Hosts sind für Sie nicht sichtbar. Es gibt jedoch 2 sehr gute Gründe dafür, dass Sie wissen, wer Ihre Netzwerknachbarn sind. Erstens können Sie im Falle eines Kommunikationsproblems diese anderen Hosts verwenden, um Ihre Netzwerkverbindung zu testen. Zweitens sind dies die Hosts, die am ehesten als Quelle für netzwerkbasierte Angriffe in Frage kommen.

Es ist keine schlechte Idee, das lokale Subnetz von Zeit zu Zeit zu scannen (z.B. jeden Mittwochmorgen), um zu sehen, wer da draußen ist. VOS hat keinen eingebauten Scanner - aber es hat den Ping-Befehl, der, wenn er von ein paar Zeilen eines Befehlsmakros umgeben ist, zu einem Scanner gemacht werden kann.

Es gibt 3 Probleme bei der Verwendung von ping für die Suche nach Hosts. Erstens ist es nicht sehr effizient. Die Standardzeitüberschreitung beträgt 15 Sekunden, und der Befehl versucht es viermal, so dass es eine Minute dauert, nach einem Rechner zu suchen, der nicht vorhanden ist oder nicht auf Pings reagiert. Glücklicherweise kann die Anzahl der Versuche auf 1 und das Timeout auf 1 Sekunde reduziert werden. Das ist zwar immer noch nicht effizient im Vergleich zu einem dedizierten Scan-Tool, aber ich denke, es reicht für unsere Bedürfnisse aus.

Das zweite Problem besteht darin, dass nicht alle Hosts auf Pings antworten werden. Dies ist jedoch kein großes Problem, da unser Befehlsmakro mit nur einer weiteren Zeile meldet, welche Hosts eine ARP-Antwort gesendet haben. ARPs werden verwendet, um eine IP-Adresse auf eine Ethernet-MAC-Adresse abzubilden, und VOS muss die Ethernet-MAC-Adresse kennen, bevor es den Ping senden kann. Daher sendet es eine ARP-Anfrage an den Zielhost und legt die Daten der Antwort im ARP-Cache ab. Alle Hosts antworten auf die ARP-Anfrage mit einer ARP-Antwort, auch wenn sie auf die anschließende Ping-Anfrage nicht antworten. Der Befehl arp zeigt den angeforderten Eintrag an, wenn er vorhanden ist.

Das obige Befehlsmakro hat die Ping-Anfragen und -Antworten mit ARP-Daten vermischt, es ist nicht sehr lesbar. Das folgende Makro erzeugt eine hübsche Tabelle der Nachbarn in einer Datei namens arp_scan.(date).out. Es geht von einem Klasse-C-Netz aus, d.h. die ersten 3 Oktette sind fest und es wird nach den Hosts 1 bis 254 gesucht. Ich schlage vor, dass Sie es als gestarteten Prozess ausführen.

Der ARP-Cache-Timeout beträgt 10 Minuten. Wenn es einen Eintrag mit einer Zeit von weniger als 10 Minuten gibt, wissen Sie, dass das Modul bereits mit diesem Host kommuniziert hat, bevor der Scan durchgeführt wurde.

Das dritte Problem ist die Beschwerde, die Sie von Ihrem Netzwerkadministrator erhalten könnten, wenn Sie das Netzwerk aktiv scannen. Wenn er mit dieser Aktivität nicht einverstanden ist, können Sie das Netzwerk passiv scannen, indem Sie den Befehl packet monitor verwenden, um Broadcast-Pakete zu erfassen.

Diese Technik setzt voraus, dass die anderen Hosts im Netzwerk aktiv kommunizieren und Broadcasts senden, während packet_monitor läuft. Wenn Sie diese Technik verwenden, müssen Sie packet_monitor eine ganze Weile laufen lassen, wie lange, hängt von Ihrem Netzwerk ab. Ich schlage vor, dass Sie den obigen Befehl in ein Befehlsmakro (packet_monitor_scan.cm) einfügen und es als gestarteten Prozess ausführen. Vergessen Sie nicht, den Prozess als privilegiert zu starten.

Sobald Sie einen Trace haben, müssen Sie ihn in eine brauchbare Adresstabelle umwandeln. Das folgende Makro erledigt das (es geht davon aus, dass packet_monitor_scan ein gestarteter Prozess war, der eine process_packet_monitor_scan.out-Datei erzeugt).

was die folgende Tabelle ergibt.