Im Test: Roguescanner 2.5.0 - Access Points ausfindig machen

Lesezeit
3 Minuten
Bis jetzt gelesen

Im Test: Roguescanner 2.5.0 - Access Points ausfindig machen

11.09.2008 - 10:00
Veröffentlicht in:
Roguescanner ist ein Open-Source-Tool, das Geräte im Netzwerk scannt und versucht, Wireless Access Points ausfinding zu machen. Der Sinn der Software besteht also darin, Administratoren ein Werkzeug in die Hand zu geben, mit dem sie schnell und einfach dazu in der Lage sind, drahtlose Zugriffspunkte ausfindig zu machen, die ohne ihr Wissen im Netzwerk installiert wurden. IT-Administrator hat das Programm genauer unter die Lupe genommen.
Der Roguescanner steht als Source und als Windows Binary unter [1] zum Download bereit. Das Tool sammelt nach dem Start Daten zu allen Systemen, die es im Netz finden kann und gleicht diese dann mit einer Online-Datenbank namens "Collaborative Device Classification Database" ab, um den Gerätetyp und die Geräteidentität zu identifizieren. Da die zentrale Datenbank Informationen über alle Devices enthält, die jemals mit dem Roguescanner untersucht wurden (zur Zeit angeblich mehr als eine Million, darunter mehr als 800 verschiedene Wireless Access Points), stehen die Chancen einer korrekten Identifizierung nach Herstellerangaben sehr gut.

Der Datenabgleich erfolgt in Echtzeit, so dass die Anwender bereits kurz nach dem Abschluss des Scans Ergebnisse erhalten. Roguescanner hebt die gefundenen Access Points in der Liste der gescannten Geräte farbig hervor, um die zuständigen Mitarbeiter auf ihre Anwesenheit aufmerksam zu machen.

Installation unter Windows
Im Test installierten wir Roguescanner in Version 2.5.0.12602 zunächst auf einem System unter Windows Vista Ultimate, stellten dabei aber leider fest, dass die Software auf dieser Windowsvariante (auch im Kompatibilitätsmodus) nicht läuft. Beim Versuch, das Programm zu starten, erschien lediglich die Fehlermeldung, dass die Lösung die Datei npptools.dll nicht finden könne. Deswegen spielten wir die Windows-Binary im zweiten Versuch auf dem vom Hersteller empfohlenen Windows XP mit Service Pack 2 ein. Dabei kam es zu keinen Problemen.

Installation unter Linux

Unter Linux läuft das Setup etwas anders ab, da die Anwender hier gezwungen sind, den Source-Code selbst zu kompilieren. Im Test richteten wir Roguescanner auf einem System unter Ubuntu Linux ein. Die Software benötigt zwingend folgende Libraries und Header-Dateien: Bison, Flex, libpcap, openssl und Ruby (im Ubuntu-Paket enthalten) sowie SNMP++3.x und gsoap.

Der erste Schritt besteht darin, die Roguescanner-Sources sowie SNMP++3.x [2] (in unserem Fall war Version 3.2 aktuell) und gsoap [3] herunterzuladen. Dann kommt der Build-Vorgang für SNMP++ an die Reihe. Nach dem Entpacken des entsprechenden Tarballs müssen Administratoren in das Verzeichnis "snmp++/src" wechseln und dort die Datei Makefile.linux öffnen. Dort ist es nun erforderlich, unter "COPTIONS" die Zeile

-DSNMP_PP_NAMESPACE –D_USE_OPENSSL

hinzuzufügen, und das Paket mit

make –f Makefile.linux

zu kompilieren. Es ist für den Betrieb von Roguescanner nicht erforderlich, die gerade kompilierten Dateien mit "make install" systemweit verfügbar zu machen. Die Benutzer haben auch die Option, die Speicherorte der Libraries und Header-Dateien über die "--with-snmp-libs"- und "--with-snmp-headers"-Optionen des Configure-Skripts der Roguescanner-Sources fest einzutragen.

Die Installation von gsoap läuft dann einfacher ab, hier reicht es nämlich, den Tarball zu entpacken, in das neue Verzeichnis zu wechseln und den Befehl

./configure && make

aufzurufen. Auch hier haben die Anwender die Option, die Dateien über "make install" systemweit verfügbar zu machen, es ist aber auch möglich, die Speicherorte der Files dem Roguescanner-Konfigurationsskript direkt mitzuteilen, und zwar über die Switches "--with-gsoap-imports", "--with-gsoap-libs", "--with-gsoap-headers", "--with-wsdl2h-path" und "--with-soapcpp2-path".

Jetzt kommt das Bauen des Roguescanners selbst an die Reihe. Da das System nach einer Library namens libruby.so sucht, mussten wir auf unserem Rechner zunächst einen symbolischen Link dieses Namens anlegen:

ln –s /usr/lib/libruby1.8.so /usr/lib/libruby.so

Nach dem Entpacken des Source-Pakets und dem Wechsel in das neue Verzeichnis, reicht es nun, wenn die Administratoren das Configure-Skript mit den benötigten Optionen aufrufen, zum Beispiel in dieser Form:

 Listing

./configure
--with-snmp-libs=/opt/roguescanner/snmp++/lib
--with-snmp-headers=/opt/roguescanner/snmp++/include
--with-gsoap-imports=/opt/roguescanner/gsoap-2.7/gsoap/import
--with-gsoap-libs=/opt/roguescanner/gsoap-2.7/gsoap
--with-gsoap-headers=/opt/roguescanner/gsoap-2.7/gsoap
--with-wsdl2h-path=/opt/roguescanner/gsoap-2.7/gsoap/bin/linux386
--with-soapcpp2-path=/opt/roguescanner/gsoap-2.7/gsoap/bin/linux386
--with-pcap-libs=/usr/lib --with-ruby-libs=/usr/lib
--with-ruby-headers=/usr/lib/ruby/1.8/i486-linux


Nach dem Abschluss des Konfigurationsskripts lässt sich die Software mit "make" kompilieren und mit "make install" als root systemweit zur Verfügung stellen.


Im Betrieb
Nach dem Aufruf des Programms erscheint unter Windows ein Fenster, das nach dem zu verwendenden Netzwerkinterface und dem zu scannenden Netzwerk fragt. Unter Linux erfolgt die Übergabe der entsprechenden Informationen über eine auf der Website des Herstellers [4] genau beschriebene Konfigurationsdatei, die der zuständige Mitarbeiter der Roguescanner-Binary als Parameter beim Start von der Kommandozeile mitgibt, zum Beispiel so:

/usr/local/sbin /RogueScanner –c
/usr/local/etc/scanner.conf


Danach erscheint das Benutzerinterface der Lösung und der Scan-Vorgang beginnt. Bei uns benötigte die Software knapp fünf Minuten zum Scannen eines Netzwerks mit etwa 2.000 Adressen. Wenn der Scan-Vorgang abgeschlossen ist, geht es automatisch an die Datenbankabfrage im Internet. Das dauerte im Test nochmals ein bis zwei Minuten.

In unserem Testnetz fand die Lösung auf Anhieb alle Komponenten und klassifizierte auch die bei uns vorhandenen Access Points von D-Link, Netgear und Zyxel korrekt. Die genauen Device-Bezeichnungen stimmten zwar nicht immer, aber alle Access Points erschienen in der Liste mit einem leicht rotgefärbten Hintergrund. Damit erfüllt das Tool seine Aufgabe, die Administratoren auf unbekannte drahtlose Zugriffspunkte hinzuweisen.

Die restlichen Klassifikationen der übrigen Komponenten im Netz sollte man aber nicht zu ernst nehmen. Roguescanner klassifizierte beispielsweise ein Ubuntu-System als Windows Workstation und einen Centos-basierten Server als 3com Super Stack Switch. Der Hersteller bietet das Produkt übrigens auch als Appliance an, in dieser Form soll es deutlich leistungsfähiger sein und Gerätetypen genauer erkennen, dann ist es allerdings nicht mehr kostenlos.



IT-Administrator. Autor: Götz Güttich

[1] www.paglo.com/opensource/roguescanner
[2] www.agentpp.com/snmp_pp3_x/snmp_pp3_x.html
[3] www.cs.fsu.edu/~engelen/soap.html
[4] www.paglo.com/system/downloads/roguescanner_readme.txt

Ähnliche Beiträge

Netzwerkverwaltung an der Medizinischen Universität Wien

Die IT-Abteilung der Medizinischen Universität Wien betreibt das Netzwerk der Universität, wozu die Betreuung von rund 10.000 Anschlüssen sowie Hunderten Endgeräten und Servern gehört. Für diese Aufgabe wurde eine neue Informations- und Planungssoftware für Kabelmanagement und Netzwerkdokumentation implementiert. Das neue Werkzeug ist flexibel, skalierbar und deckt die steigenden Sicherheitsanforderungen voll ab.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (3)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im dritten und letzten Teil gehen wir auf weitere Varianten ein, etwa die ZTP-Provisionierung ohne proprietären Server, die Boot-Loader-Variante iPXE oder das alte Verfahren AutoInstall.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (2)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im zweiten Teil der Workshopserie schildern wir den proprietären Cisco-Ansatz "Network-Plug-and-Play", der über eine GUI erfolgt und bei dem sich die ausgerollten Komponenten an die Gegebenheiten im Netzwerk anpassen lassen.