© Daniel Funke, photocase.com

Ab Version 4.21 enthält Nmap die Scripting Engine NSE. Statt nur nach Ports und Protokollen zu suchen, erweitern dabei Skripte die Funktionen des Netzwerk-Tools erheblich. Eine Programmiersprache und eine Schnittstelle zu den Funktionen des Scanners helfen dem Netzwerker.

Wenn es um Penetrationstests oder einen Überblick der im eigenen Netz angebotenen Dienste geht, ist Nmap das Maß der Dinge [1]. Viele Administratoren wünschen sich jedoch – ausgehend von den Ergebnissen – weitere Tests: Wenn Nmap schon einen HTTP-Dienst gefunden hat, wieso nicht gleich die Version des Webservers abfragen? Bislang schrieb mancher Admin eigene Skripte, die Nmaps Ausgabedateien parsen. Da dies bei großen Netzen aufwändig und langwierig ist, entschloss sich Fyodor, Projektleiter von Nmap, die Entwicklung einer Scripting Engine in die Hände von Diman Todorov zu legen.

NSE erweitert alle Kernbereiche des Scanners [2]. Das Abfragen detaillierter Informationen von Services wie SNMP, NFS, SMB oder RPC reichert die Suche nach aktiven Systemen durch Domain-Lookups, Eigentümerdaten aus Whois-Datenbanken oder anderen Quellen an (Network Discovery). Bereits im Normalbetrieb identifiziert Nmap zwar offene Ports (Version Detection), stellt jedoch durch den Einsatz von NSE-Skripten die Versionen angebotener Dienste sehr viel genauer fest.

Das Werkzeug ist nicht als Vulnerability Scanner ausgelegt, es bietet sich jedoch an, wichtige Sicherheitslöcher beim Scannen durch Nmap gleich mit überprüfen zu lassen. Für umfangreiche Scans sind Tools wie Nessus [3], GFI Languard [4] oder ISS Internet Scanner [5] allerdings besser geeignet.

Um Backdoors zu erkennen, setzt NSE Regular Expressions auf die erkannten Versionsstrings an. Für Penetrationstester ist die Möglichkeit interessant, vorhandene Schwachstellen durch Einbinden von Exploits direkt zu testen. Allerdings weisen die Entwickler darauf hin, dass sich Nmap nicht zur Konkurrenz für das Metasploit-Framework [6] entwickeln soll. In erster Linie erweitert NSE damit die nativen Fähigkeiten von Nmap, ermöglicht aber auch individuelle Anpassungen der Nmap-Scans.

Vom Server des Projekts [7] lädt der Administrator entweder den Sourcecode oder installiert ein Paket aus einem Repository seiner Distribution. Die NSE-Erweiterung ist ab Version 4.21 fest integriert. Herzstück von NSE ist ein Lua-Interpreter [8] (siehe Abbildung 1). Wenn Nmap einen Host oder Port erkannt hat, ruft es den Lua-Interpreter mit passenden Skripten auf, die neben den Funktionen des Lua-Sprachumfangs auch die Nmap-spezifischen Funktionen der NSE-Bibliothek nutzen können.

Abbildung 1: Das Zusammenspiel von NSE-Skripten, Nmap-Bibliotheken und neuen Lua-Aufrufen erweitert den Funktionsumfang des klassischen Nmap.

Die Skripte von NSE finden sich nach der Installation unter »/usr/share/nmap/nselib«. Diese Bibliotheken stellen beispielsweise Hilfen zur Auswertung und Manipulation von IP-Adressen, den Einsatz Perl-kompatibler Regular Expressions oder von URL-Manipulationen bereit, die so in Lua nicht vorhanden sind.

Architektur

Über das Nmap-API tauschen Nmap und die NSE Informationen aus. Hierzu zählen der Name des Zielhosts, dessen Betriebssystem und IP-Adresse, der untersuchte Port und dessen Status. Außerdem erlaubt das API, Socket-Funktionen von Nmap zur Netzwerkkommunikation aufzurufen. Eine Erweiterung, um beliebig definierbare Pakete zu verschicken, steht kurz vor der Freigabe.

Das Normalverhalten von Nmap ist, entsprechend seinen Optionen für einen Host die verfügbaren Ports auf Erreichbarkeit zu überprüfen. Bei einem TCP-Scan stellt das Werkzeug dabei beispielsweise einen Status wie »open«, »closed« oder »filtered« fest. Für weitergehende Tests kommt NSE zum Zuge.

Sobald Nmap einen Port erkannt hat und NSE mit der Option »-sC« aktiviert ist, sucht das Subsystem nach einem passenden Skript für diesen Test. Ob Nmap ein NSE-Skript ausführt oder nicht, hängt in erster Linie von der Skriptregel ab. Diese Regel ist im Programmcode als Funktion implementiert und legt die Bedingung fest, unter der das Skript startet.

Erkennt der Scanner beispielsweise den TCP-Port 80 als offen und erklärt sich das Skript »showHTMLTitle.nse« für diesen Port zuständig, wird es aufgerufen. Es fragt die Startseite des Webservers ab und zeigt deren Titel an (Abbildung 2). Der Programmcode, um Webserver zu analysieren, befindet sich zusammen mit über 30 bereits mitgelieferten Skripten unter »/usr/share/nmap/scripts«.

Abbildung 2: Im neuen Skriptmodus mit »-sC« ruft Nmap externe Skripte auf. Da Nmap einen offenen Port 80 erkennt, fragt das Werkzeug unter anderem den Titel einer erkannten Website ab und zeigt ihn an. Auch pro Host sind zusätzliche Auswertungen möglich: Hier erkennt NSE den Netbios-Namen des Ziels.

Auswahlverfahren

Ein Skript »showHTTPVersion.nse« im selben Verzeichnis würde jedoch im Beispiel nicht ausgeführt, weil es der Kategorie »version« angehört, deren Skripte beim Standardverhalten nicht aktiviert sind. NSE teilt Skripte in Kategorien ein, um eine genauere Steuerung zu ermöglichen. Bestimmte Skripte könnten die Systemstabilität beeinträchtigen und lassen sich daher nur ausführen, wenn der Admin sie explizit einbindet.

Erfolgt der Aufruf mit »-sC«, werden nur die Skripte der Kategorie »safe« und »intrusive« ausgeführt. Das genannte NSE-Skript »showHTTPVersion.nse« ist allerdings keiner dieser beiden Kategorien zugeordnet und läuft daher normalerweise nicht ab.

Skriptkategorien

Die bisher vorhandenen Skriptkategorien heißen »safe« und »intrusive« sowie »malware«, »version«, »discovery« und »vulnerability«. Während NSE Skripte der Kategorie »safe« als sicher einstuft und sie in den seltensten Fällen zu Problemen auf dem zu scannenden Rechner führen, fallen in die Kategorie »intrusive« jene Skripte, die zwar ebenfalls kaum Schaden anrichten dürften, aber beispielsweise versuchen, durch Standardpasswörter in die Systeme einzudringen, und damit häufiger zu Logeinträgen auf dem gescannten System führen.

Skripte der Kategorien »malware« und »vulnerability« testen das gescannte System auf Malware und bekannte Schwachstellen. Die Kategorie »version« besitzt eine Sonderstellung: Hat ein Entwickler Skripte dieser Kategorie zugeordnet, ruft der Anwender sie über die Option »-sV« auf. Sie sind als Erweiterung zur Versionserkennung von Nmap gedacht und unterscheiden sich in der Ausgabe nicht von der Standardausgabe von Nmap. Der Titel des Skripts erscheint also nicht im erzeugten Report.

Die Kategorie »discovery« umfasst alle Skripte, die darauf ausgelegt sind, durch Abfragen verschiedener Dienste (unter anderem SNMP oder LDAP) mehr über das gescannte System oder das Netzwerk zu erfahren. Alle Kategorien sind laut Entwickler ein erster Entwurf und werden in Zukunft noch erweitert.

Mit dem Argument »–script« gibt der Admin Kategorien, Verzeichnisse oder einzelne Skripte an, die NSE einbinden und ausführen soll. Mehrere durch Kommas voneinander getrennte Werte sind möglich. Zunächst sucht Nmap nach einer Kategorie des angegebenen Namens. Ist diese Suche erfolglos, sucht der Scanner nach einem entsprechend benannten Verzeichnis und bindet alle Skripte mit der Endung ».nse« ein. Unterverzeichnisse berücksichtigt er nicht.

Sollte auch die Suche nach einem Verzeichnis erfolglos sein, wird nach einem einzelnen Skript des angegebenen Namens gesucht. Die Option »–script discovery,malware« bindet beispielsweise die Kategorien »discovery« und »malware« ein. Eine Datenbankdatei namens »script.db« im Unterverzeichnis »scripts« ordnet die Kategorien den jeweiligen Skripten zu. Der Admin kann diese Datei mit dem Kommando »–script-updatedb« aktualisieren, wenn er weitere Skripte hinzugefügt hat.

NSE-Skripte im Eigenbau

Ein konkretes Beispiel hilft den Aufbau von NSE-Skripten zu verstehen. Die meisten mitgelieferten Skripte sind einfach gehalten, im Quelltext kommentiert und gehen selten über 100 Zeilen hinaus. Der Code von »ripeQuery.nse« (siehe Listing 1) gibt einen Einblick in die Funktionsweise von Lua und die Komponenten von NSE. Das Skript fragt den Ripe-Eintrag der Adresse ab.

Jedes NSE-Skript hat einen Header, der aus vier beschreibenden Angaben besteht. Das Feld »id« enthält den Skriptnamen, wie er in der Ausgabe von Nmap auftaucht. »description« beinhaltet eine Kurzbeschreibung, »author« kennzeichnet den Namen des Autors. Der Interpreter verarbeitet nicht direkt das Feld »license«, das die Lizenz anzeigt.

01 require "ipOps"
02 
03 id          = "RIPE query"
04 description = "Connects to the RIPE database,
05                extracts and prints the role-entry for the IP."
06 author      = "Diman Torodov <diman.todorov@gmail.com>"
07 license     = "See nmaps COPYING for licence"
08 
09 categories = {"discovery"}
10 
11 hostrule = function(host, port)
12     return not ipOps.isPrivate(host.ip)
13 end
14 
15 action = function(host, port)
16     local socket = nmap.new_socket()
17     local status, line
18     local result = ""
19 
20     socket:connect("whois.ripe.net", 43)
21     socket:send(host.ip .. "n")
22 
23     while true do
24         local status, lines = socket:receive_lines(1)
25 
26         if not status then
27             break
28         else
29             result = result .. lines
30         end
31     end
32     socket:close()
33 
34     local value  = string.match(result, "role:(.-)n")
35 
36     if (value == "see http://www.iana.org.") then
37         value = nil
38     end
39 
40     if (value == nil) then
41         value = ""
42     end
43         
44     return "IP belongs to: " .. value
45 end

Ein Skript startet nur unter bestimmten Bedingungen. So genannte Port- und Host-Regeln steuern dieses Verhalten. Jedes Skript entscheidet selbst, ob es in einem Kontext ausgeführt werden möchte. Das Beispiel in Listing 1 definiert in den Zeilen 11 bis 13 eine Funktion, die als Argumente die Lua-Tabellen »host« und »port« übernimmt. In ihnen sind alle von Nmap während des Scans ermittelten Werte enthalten (mehr zu den Lua-Tabellen im Kasten “Was ist Lua?”). So bietet beispielsweise »host.ip« Zugriff auf die IP-Adresse, »port.number« auf den aktuell gescannten Port.

Die Funktion »hostrule« prüft also mittels der Bibliotheksfunktion »ipOpts.isPrivate«, ob die aktuell zu untersuchende IP eine private Adresse nach RFC 1918 ist. Nur wenn das nicht der Fall ist, ergibt eine Ripe-Überprüfung Sinn. Dann führt NSE auch den Kern des Skripts aus, die Funktion »action« ab Zeile 15.

Wer keinen kompletten Host, sondern lediglich einen einzelnen Dienst untersuchen will, verwendet in der Regel eine Zeile der Art

portrule = shortport.port_or_service(21, "ftp")

wie sie auch im Skript »anonFTP.nse« zu finden ist. Allerdings muss dazu die Lua-Extension »shortport« über »require “shortport”« eingebunden sein.

Und Action!

Die eigentliche Arbeit des Skripts folgt den Angaben im Kopf der Funktion »action=function(host, port)«. Die definierte Funktion übernimmt wieder »host« und »port« als Argumente. In Zeile 16 erzeugt das Skript zunächst einen neuen TCP/IP-Socket und definiert die lokalen Variablen »status«, »line« und »result«. Mit

socket:connect("whois.ripe.net", 43)

verbindet sich das Skript direkt mit der Ripe-Datenbank, die auf TCP-Port 43 Anfragen direkt antwortet. Dazu erwartet der Whois-Dienst als Anfrage eine IP-Adresse in Quatted-Dot-Schreibweise. Der Code »socket:send(host.ip .. “n”)« sendet sie. Eine Anfragezeile muss durch ein Newline abgeschlossen sein. Daher hängt der Concatenator-Operator »..« an die über »host.ip« ermittelte IP-Adresse des gescannten Hosts noch »n« an. Innerhalb der Endlosschleife ab Zeile 23 liest das Skript mit

local status, lines = socket:receive_lines(1)

eine Antwortzeile der Ripe-Datenbank ein, bis es keine weiteren Daten mehr empfängt. Die Boolean-Variable »status« zeigt dabei an, ob die Verbindung noch Daten liefert.

Ist das nicht mehr der Fall, wird die Schleife in Zeile 27 mittels »break« wieder verlassen. Die aktuell gelesene Antwortzeile steht in »lines«, »result« akkumuliert sie. Der Code »socket:close()« schließt den Socket, wenn alle Antwortzeilen eingelesen sind.

Alles unter Kontrolle

Die nächsten Zeilen sollen herausfinden, welcher Eintrag für die gesendete IP-Adresse besteht. Der Whois-Server liefert eine große Anzahl von Antwortzeilen zurück, das angegebene Beispiel sucht nur solche, die mit »role:« beginnen. Hierzu greift das Skript auf die eingebaute Lua-Funktion »string.match()« zu. Der Code

local value  = string.match(result, "role:(.-)n")

sucht in der Variablen »result« nach einer Zeile, auf die das Suchmuster passt. Das Muster beginnt mit »role:«, die Funktion liefert aber nur den in runden Klammern stehenden Rest der Zeile zurück. Aus Übersichtsgründen ist das Skript, das im Lieferumfang von Nmap enthalten ist, etwas gekürzt. Um robuster zu sein, sollten Skripte beispielsweise die Rückgabewerte noch auf Plausibilität prüfen.

Schätze des Nmap-API

Über das Nmap-API können die NSE-Skripte mit Nmap kommunizieren. Die bereits vorgestellten Lua-Tabellen »host« und »port« bieten Zugriff auf die wichtigsten Werte wie IP-Adresse, Port, Service oder den Status des Ports.

Die Lua-Tabelle »host« liefert die in Tabelle 1 angegebenen Werte, sofern Nmap sie erkannt hat, andernfalls einen leeren String. Dies gilt auch für Angaben zu einem aktiven Port, die in der Lua-Tabelle »port« mit den Attributen zu Protokoll, Dienst und Status hinterlegt sind.

Wie sich diese Werte abrufen und in ein NSE-Skript integrieren lassen, macht das Beispielskript deutlich. Um im Netzwerk mit anderen System zu kommunizieren, ist für die NSE-Skripte eine Schnittstelle notwendig. Ein API ermöglicht den Zugriff auf die Nsock-Bibliothek, die Nmap ebenfalls intern verwendet.

Socket-Programmierung

Eine klassische Kommunikation läuft nach einem Schema ab, dem üblicherweise die Socketprogrammierung folgt. Zunächst erzeugt der folgende Code einen neuen Socket namens »sock« und verbindet ihn mit dem angegebenen Host über den angegebenen Port. Das Protokoll ist optional und darf »tcp«, »udp« oder »ssl« sein:

sock = nmap.new_socket()
sock:connect(Host, Port [, Protokoll])

Der Code »sock:send(Anfrage)« ist dann in der Lage, eine vorbereitete Anfrage an den Zielhost zu versenden. Eine eigenwillige Semantik hat

status, value = sock:receive_lines(Zeilen)
um Daten vom Socket zu lesen. Kommen bis zu einem Timeout die angeforderten oder weniger durch Newline terminierten Zeilen an, finden sie sich in der Variablen »value«. Sollten jedoch im Netzwerkbuffer mehr Zeilen eingegangen sein, übergibt das API auch mehrere Zeilen. Die API-Beschreibung gibt hier Aufschluss [2]. Bei Erfolg erhält »status« den Wert »true«. Zuletzt schließt »sock:close()« den Socket wieder. Das Nmap-API stellt noch wesentlich mehr Funktionen bereit, doch mit den genannten sind die meisten Fälle abgedeckt.

Exception Handling

Über das Nmap-API ist auch ein Mechanismus für das Exception Handling implementiert. Dessen Zweck ist es, Fehler abzufangen und ein Skript abzubrechen, das mit fehlerhaften Voraussetzungen nicht mehr zu einem korrekten Ergebnis kommen kann. Exceptions sind für robuste Skripte sehr wichtig, da gerade beim Netzwerk-Scanning nicht immer gewährleistet ist, dass ein untersuchter Dienst wie erwartet reagiert. Ein Blick in das Skript »finger.nse« in Listing 2 zeigt das Exception Handling in Aktion. Sollte bei der Verbindung zum Zielsystem ein Fehler auftreten oder die Verbindung in einen Timeout laufen, schließt die Ausnahme-Funktion den Socket korrekt.

01 local err_catch = function()
02     socket:close()
03 end
04 
05 local try = nmap.new_try(err_catch())
06 
07 socket:set_timeout(5000)
08 try(socket:connect(host.ip,
09                    port.number,
10                    port.protocol))
11 try(socket:send("nr"))
12 
13 status, results = socket:receive_lines(100)
14 socket:close()
15 if not(status) then
16     return results
17 end

Das Skript ruft zunächst eine Funktion ins Leben, deren einzige Aufgabe darin besteht, den Socket im Fehlerfalle zu schließen. Den Exception Handler legt

try = nmap.new_try()

an. Er übernimmt als Funktionsargument »err_catch()«, das für das Schließen des Sockets sorgt. Liefern Funktionen Fehler zurück, beendet sie der Interpreter, ohne Angaben zu machen. Die als Argument übergebene Funktion bestimmt die Aktionen, die dann in Kraft treten.

Lua-Extensions

Während das Nmap-API für die Kommunikation zwischen Nmap und den NSE-Skripten sorgt, erweitern die Lua-Extensions die Möglichkeiten der Programmiersprache. Es handelt sich um Module, die sich im Unterverzeichnis »nselib« befinden. Ein NSE-Skript bindet sie über »require Modulname« ein. Tabelle 2 listet die verfügbaren Erweiterungen auf. Ob man die Module vor oder hinter dem Header einbindet, ist nicht wichtig. Die vorhandenen Skripte handhaben dies auch unterschiedlich.

Potenzial zum Klassiker

Nmap bietet mit NSE eine leistungsstarke und flexible Erweiterung, mit der der Admin seine Scans individuell gestalten kann. Ein Nmap-Skript besteht aus folgenden Komponenten: Der »Header« definiert den Namen des Skripts in der Nmap-Ausgabe, die Skriptkategorie sowie den Runlevel. Anschließend legt die »Rule« fest, unter welchen Bedingungen das Skript zur Anwendung kommt. Hauptteil ist drittens die »Action«. Sie ruft eine Funktion ins Leben, die die eigentliche Aufgabe der Erweiterung übernimmt. Alle drei Abschnitte implementiert der Autor eines Skripts in Lua.

Zum Erweitern der Basisfunktionalität der zugrunde liegenden Skriptsprache Lua bieten sich Module der NSE-Extensions-Bibliothek an. Das Nmap-API erlaubt es, über die Tabellen »host« und »port« auf die Scanergebnisse zuzugreifen und bietet zahlreiche Möglichkeiten zur Kommunikation für das Skript.

NSE-Skripte dringen schnell in die Domänen anderer Security-Tools wie etwa Nessus ein, obwohl dies von den Entwicklern gar nicht angestrebt wird. Es liegt an der Kreativität der Community (siehe Kasten “NSE-Programmierwettbewerb”), wie sie diese mächtige Erweiterung optimal ausreizt.

Noch liegt NSE nicht in einer stabilen Version vor, Nmap 4.21 enthielt nur Alphaversionen und 4.22 war Teil des Google Summer of Code. Die stabile Version Nmap 4.5 wird NSE enthalten und soll bis zum Erscheinungstermin dieses Linux-Magazins erschienen sein. Potenzial zum umverzichtbaren Bestandteil von Nmap hat NSE allemal. (mg)