Netzwerk Inventory

Jedes mal nervt es mich, wenn ich wieder mal ein "Telefon" in meinem Subnetz suchen muss. Natürlich gibt es viele Programme, die einen "Nachbarschaftsscan" machen aber ich würde das Thema etwas weiter treiben wollen und verschiedene Quellen anzapfen. In meinem Netzwerk gibt es aber immer mehrere Forests (Test-VMs etc.), alleinstehende Maschinen etc., so dass eine Suche in einem Active Directory oder eine DNS-Auflistung nicht vollständig sind. Ein Client in einem Subnetz hat aber immer eine MAC-Adresse, die er auch verwendet und auf einen ARP-Request zumindest darauf antwortet. So bekommt man zumindest eine eindeutige Liste der Endgeräte in einem Subnetz.

Computer und ARP - Erkennen oder Auslesen?

Jedes Gerät in einem Subnetz muss ich sich mit einer MAC-Adresse melden. Sie besteht aus einer Hersteller-Kennung (erste 3 Byte) und einer vom Hersteller hoffentlich einmalig vergebe Nummer (3 Byte). All diese Server können aber gefälscht sein und ein Gerät könnte sogar als "FF:FF:FF:FF:FF:FF" (Broadcast) senden und empfangen. Aber ich kenne kein interessantes Protokoll, welches man so anzapfen könnten ohne sich mit einer normalen MAC-Adresse zu verbinden. Also wird jeder "Teilnehmer" irgendwie schon eine MAC-Adresse bei der Kommunikation verwenden, damit Pakete auch wieder bei im ankommen. Diese MAC-Adressen lernen auf jeden Fall die "Switches".

Ein Weg im gleichen Subnetz nach Adressen zu suchen besteht darin, jede IP-Adresse einfach einmal "anzupingen" und dann die Daten aus dem ARP-Cache auszulesen. In der Regel antwortet ein Gerät auf einem ARP-Request auch wenn nachfolgende Kommunikation (Hier ICMP) blockiert sein sollte. Zu dem Status weiß das Ziel ja noch nicht, welchen Dienst der anfragende Client ansprechen will. Ich habe aber keinen Weg gefunden, wie man per PowerShell einen einfach nur einen ARP-Request auslösen kann und dann die ARP-Tabelle ausliest. Es sieht so aus, dass alle anderen Entwickler mit dieser Aufgabe einfach "ARP.EXE" dazu verwenden und die Ausgabe parsen.

ping -4 192.168.23.216
arp -a 192.168.23.216

Eine andere Möglichkeit eine Liste der aktiven MAC-Adressen zu erhalten ist natürlich die Abfrage der ARP-Tabelle im Switch. Sofern der Client IP zu anderen Systemen außerhalb des eigenen Subnetz spricht, kennt auch der Router die MAC-Adresse in seiner ARP-Tabelle und ein Router ist vielleicht noch eher per SNMP abfragbar als ein dummer Switch.

Theoretisch könnte man auch per DNS oder genauer, "Reverse-DNS" zu einem Subnetz einfach die Hosts ermitteln. Das ist aber nicht zuverlässig, da sich dazu die Endgeräte immer erst am Reverse-DNS auch eintragen müsste oder der DHCP-Server dies übernimmt.

Dann wäre eine Abfrage am DHCP-Server noch interessanter, da so zumindest die "freundlichen" Systemen erfasst würden.

Über die MAC-Adresse lässt sich auch der Hersteller ermitteln.

Informationen von Switch oder WLAN AP

Die beste Datenquelle um eine komplette Liste der Endpunkte in ihrem LAN mit eine Standorteinschätzung zu geben, ist daher der Switch, der allerdings dazu "managebar" sein muss. Ein Swtich unterscheidet sich gerade dahingehend von einem dummen Hub, dass er eine Liste der MAC-Adressen pro Port pflegt und die Pakete abhängig von der Ziel-MAC-Adresse an den richtigen Port weiter leitet und die anderen Ports nicht belastet. Nur wenn eine unbekannte MAC-Adresse oder FF:FF:FF:FF:FF:FF als Ziel angegeben ist, muss der Switch das Paket an alle Ports senden, damit hoffentlich ein Endgerät darauf antworten kann.

Jeder Switch hat also eine MAC-Table aber nicht jeder Switch bietet einen passenden Zugang zu diesen Daten. Die Switches unterscheiden sich in

  • Unmanaged
    Oft sind solche Switche daran erkennbar, dass sie selbst keine IP-Adresse haben und auch sonst sich auf die grundlegende Funktion beschränken. Das ist durchaus i.O. als Switch in einem Testfeld, um Homeoffice oder notfalls auch im Schreibtisch um an einer LAN-Dose neben dem PC auch noch ein Telefon oder einen Drucker anzuschießen.
  • Smart Managed
    Oft sind aber solche Switches nicht sehr viel teurer und können zumindest per Webbrowser konfiguriert werden. Es ist durchaus interessant zu sehen, wie leistungsfähig solche Switches sind, obwohl sie kaum mehr kosten als dumme "unmanaged Switches". Der Zugang per Browser erlaubt einfache Einstellungen und die Anzeige des Status. Eine einfache Fehlersuche ist damit auch per Fernwartung möglich. Leider unterstützen diese Switches meist weder SNMP nocht andere automatisierte Protokolle. Eine MAC-Tabelle kann man also maximal per HTTP-Abruf einer Webseite samt nachfolgendem Parsing realisieren. Nicht sehr elegant und zuverlässig und schon gar nicht standardisiert und oft erlaubt der Switch nur eine HTTP-Session gleichzeitig, so dass bei einem automatischen Abruf eine parallele Konfiguration nicht mehr möglich ist.
  • Managed
    Voll managebare Switches unterstützen zumindest SNMP als Protokoll und haben oft auch eine Kommandozeile und noch mal deutlich umfangreichere Funktionen. Allerdings schlägt sich das auch im Preis nieder. In Firmen ist dennoch der Einsatz solcher Switches anzuraten, das Sie meist auch Zusatzfunktionen wie DHCP-Schutz, Floodingschutz etc. haben und natürlich in das Enterprise Monitoring integriert werden können.

Wenn ihr Switch entsprechend ausgestattet ist, dann können Sie von hier autoritative Daten von Endgeräten und ihrem Anschlusspunkt erhalten. Einige Switche können Änderungen der MAC-Table z.B. per SYSLOG weiter melden und so ein IDS-System füttern.

ARP-Watch und Schnüffeln

Wer keinen "managebaren"-Switch hat, kann überlegen in jedem Subnetz ein Device zu platzieren, was die ARP-Requests ermittelt und so ein passives Inventory des Subnetz erstellt. Wenn ein Netzwerk-Client einen anderen Client per IP erreichen will, muss er die MAC-Adresse des Ziels ermitteln. Das passiert in der Regel über ARP (Adddress Resolution Protocol). Der Client sendet einen Broadcast mit seiner MAC-Adresse und IP-Adresse und der gesuchten IP-Adresse. Als Ethernet-Broadcast bekommen dieses Paket alle Clients im LAN und der gewünschte Client antwortet zurück. Diese ARP-Broadcasts kann man überwachen. Wenn ein Client dann mitspielt, hat er eine IP-Adresse und antwortet seinerseits in der Regel auf ARP-Anfragen, so dass ein Inventory auch einen Subnetz-Scan machen kann. Natürlich können Angreifer auf ARP verzichten. Sie müssen dann aber Geduld haben und selbst die Broadcasts anderer ARP-Anfragen mitlesen und sich so eine Liste der Teilnehmer erstellen und auf ARP-Anfragen an ihre IP müssen sie natürlich auch nicht jedem Antworten, sondern nur den Systemen, die sie selbst erreichen wollen. Und selbst hier kann ein Client mit einem "besonderen" ARP-Paket seine eigene reale MAC-Adresse verschleiern. (Siehe auch NLB, welches den Switch per dazu bringt, die Pakete an alle Ports des VLAN zu senden. Dennoch ist ein ARP-Watch auch eine Möglichkeit seine Nachbarn im gleichen Netzwerk/VLAN aufzulisten, wenn man keinen direkten Zugriff auf den Switch oder Router hat.

Natürlich gibt es schon entsprechende Tools für Unix und sogar die ein oder andere Box ist verfügbar. Wer mehrere Subnetze hat, kann also solche Boxen oder auch einen RasPi als "Watcher" in das LAN bringen.

IIS Logs/Proxy-Logs

Die Suche nach Clients per MAC-Adresse erfordert natürlich eine Analyse pro Subnetz. Da heute aber jedes Gerät irgendwie per HTTP kommuniziert (Windows Updates, Google Startseite, "Nach Hause telefonieren", Virenscannerupdates etc. hinterlässt es auf diese Weite natürlich auch Spuren auf dem internen Webserver, der Firewall oder einem Proxy-Server, speziell wenn dieser per WPad im LAN bereitgestellt wird. Insofern kann man auch hier eine Auswertung über Source-IP-Adressen machen, die aber nicht wirklich vollständig ist.

Weitere Links