TCP-Port-Scanning ist ein Verfahren, bei dem es darum geht, TCP/IP-Anwendungen auf einem Zielsystem zu entdecken. Außerdem handelt es sich um einen wichtigen Bestandteil jedes Netzwerksicherheits-Audits. Obwohl die meisten Netzwerk- und Sicherheitsfachleute mit TCP-Port-Scanning vertraut sind, verstehen viele nur selten die Details hinter den verschiedenen Techniken, die für Port-Scanning verwendet werden, und deren Anwendungsmöglichkeiten.
Dieser Artikel erläutert die theoretischen Ansätze, die sich hinter den unterschiedlichen für TCP-Port-Scanning genutzten Methoden verbergen, und liefert Entscheidungshilfen, wann Sie welche davon am besten einsetzen sollten.
Das Ziel von TCP-Port-Scanning besteht darin, die von einem Zielsystem angebotenen Netzwerkdienste zu erkennen. Die Idee, die TCP-Port-Scanning zugrunde liegt, ist relativ simpel. Ein Testpaket wird an den Ziel-Port gesendet, und je nach Antwort – oder fehlender Antwort – des Zielsystems lässt sich einer der folgenden Zustände über den Ziel-Port ableiten: Der Port ist geöffnet, geschlossen oder gefiltert.
Ein offener Port akzeptiert eingehende Verbindungen, um einen bestimmten Dienst zur Verfügung zu stellen. Für einen geschlossenen Port wiederum gibt es keine Anwendung, die eingehende Verbindungen akzeptiert. Infolgedessen weist ein solcher Port etwaige Verbindungsanfragen zurück. Falls eine Paketfilterung eingerichtet wurde, die an den Ziel-Port gesendete Pakete verwerfen soll, handelt es sich um einen gefilterten Port. In der Regel lässt sich in diesem Fall nicht feststellen, ob der Port geöffnet oder geschlossen ist.
Um die für TCP-Port-Scanning eingesetzten Methoden zu verstehen, muss man über einen zentralen Mechanismus des Transmission Control Protocol Bescheid wissen: den TCP-Verbindungsaufbau. Es gibt im Wesentlichen zwei Szenarien für den TCP-Verbindungsaufbau, die sich folgendermaßen veranschaulichen lassen:
Abbildung 1: Zwei Szenarien für den TCP-Verbindungsaufbau.
Im ersten Szenario (offener Port) lauscht eine Anwendung – auf Host B – auf eingehende Verbindungen auf einem bestimmten Port. Der Port gilt somit als offen. Genauer gesagt befindet er sich im Status TCP LISTEN. Beim Empfang einer eingehenden Verbindungsanfrage – in Form eines SYN- oder Synchronisationspakets – antwortet das Zielsystem (Host B) mit einem SYN/ACK-Paket, um die Synchronisation zu bestätigen. Sobald Host A – also der Host, von dem die Verbindungsanfrage ausging – mit einem ACK-Paket antwortet, ist die Verbindung auf beiden Seiten hergestellt.
Im zweiten Szenario (geschlossener Port) lauscht keine Anwendung auf eingehende Verbindungen auf einem bestimmten Port auf Host B. Daher gilt der Port als geschlossen, er befindet sich im Status TCP CLOSED. Beim Empfang einer eingehenden Verbindungsanfrage weist das Zielsystem (Host B) die Verbindungsanfrage mit einem RST- oder Reset-Paket zurück.
Der Einsatz einer Paketfilterung führt zu einem dritten möglichen Szenario. Hierbei werden an einen Zielknoten gesendete Pakete einfach verworfen – entweder auf einem Intermediate System oder dem Zielsystem selbst. Als Folge davon antwortet das Zielsystem nie. Da das Zielsystem nicht antwortet, wenn ein Testpaket an den Port geschickt wird, handelt es sich um einen gefilterten Port. In einigen Fällen kann die Paketfilterung so konfiguriert werden, dass sie die verworfenen Pakete durch ICMP-Fehlermeldungen (Internet Control Message Protocol) signalisiert.
Für gefilterte Ports gelten die folgenden zwei Überlegungen. Erstens: Wenn auf ein Testpaket keine Antwort erfolgt, lässt sich daraus nicht schließen, ob der Port gefiltert wird oder ob das Testpaket einfach verworfen wurde – zum Beispiel als Folge eines überlasteten Netzwerks. Zweitens: Selbst wenn davon auszugehen ist, dass keine Pakete aufgrund eines überlasteten Netzwerks verworfen werden, muss man länger als bei offenen und geschlossenen Ports warten, um ableiten zu können, dass der Port gefiltert wird. Folgendes lässt sich also festhalten: Bei den ersten zwei Szenarien gibt es eine positive Antwort, die den Status des Ports eindeutig zeigt. Im Fall eines gefilterten Ports hingegen muss man länger abwarten, bis man sicher sein kann, dass vom Zielsystem keine Antwort erfolgt.
Der Connect-Scan
Die einfachste Methode für TCP-Port-Scanning ist unter dem Namen TCP-Connect-Scan bekannt. Bei diesem Verfahren versucht das Scan-Tool einfach, eine normale TCP-Verbindung mit dem Ziel-Port aufzubauen und verwendet dazu die normalen Funktions- und Systemaufrufe. Der Zeitbedarf, um herauszufinden, in welchem Status sich der Ziel-Port befindet, lässt sich ungefähr folgendermaßen abschätzen:
In geöffnetem oder geschlossenem Status: 1 * Round Trip Time – das bedeutet, das Tool muss warten, bis das SYN-Paket den Zielknoten erreicht hat und die SYN/ACK- oder RST-Pakete als Antwort auf die Verbindungsanfrage empfangen wurden.
In gefiltertem Status: Üblicherweise mindestens 75 Sekunden. Hierbei handelt es sich um eine Zeitangabe, die abhängig von der jeweiligen Implementierung ist. Danach kommt es zu einem Time-out. Ein Scan-Tool kann allerdings möglicherweise den Wert für den Time-out reduzieren.
Da sich der lokale TCP/IP-Stack – in der Regel im Kern des Betriebssystems – um die Verbindungsanfragen kümmert, besteht ein weiterer wichtiger Aspekt im Zusammenhang mit dem TCP-Connect-Scan darin, dass bei jedem gescannten Port Systemressourcen für die betreffende TCP-Verbindung gebunden werden. Dazu zählt unter anderem ein Eintrag in der Liste der bestehenden Verbindungen, was letztlich die maximale Anzahl der Ports beschränken kann, die sich zu einer bestimmten Zeit gleichzeitig scannen lassen.
Ebenfalls wichtig zu wissen: Im Fall eines offenen Ports wird die TCP-Verbindung vollständig aufgebaut. Das heißt, dass ein Überwachungsgerät – zum Beispiel ein Intrusion Detection System (IDS) – die IP-Adresse des scannenden Knotens isolieren und ableiten könnte, dass sie nicht gefälscht oder anderweitig manipuliert wurde. Das kann unerwünscht sein, falls der TCP-Port-Scan tatsächlich das Ergebnis einer bösartigen Aktivität ist.
Der TCP-Connect-Scan lässt sich mit Nmap folgendermaßen aufrufen:
nmap -sT example.com
Der SYN-Scan
Wenn ein TCP-Port-Scan durchgeführt wird, sollte klar sein, dass kein Interesse daran besteht, tatsächlich eine Verbindung zum Zielsystem aufzubauen. Die Intention liegt vielmehr darin, eine Antwort, oder eben keine Antwort, auf das Testpaket zu erhalten – typischerweise ein SYN-Paket. Aus diesem Grund implementieren TCP-Scan-Tools im Allgemeinen den sogenannten SYN-Scan. Bei einem SYN-Scan ist das Testpaket ein eigens erstelltes SYN-Paket, das vom Scan-Tool gesendet wird, anstatt von der zugrunde liegenden TCP-Implementierung. Diese Methode besitzt eine Reihe von Vorteilen, unter anderem:
Das Scannen eines TCP-Ports bindet nicht zwingenderweise lokale Ressourcen an die gescannten Ports – zum Beispiel merkt der Kern des Betriebssystems nichts vom versuchten Verbindungsaufbau.
Da sogar im Fall von offenen Ports die TCP-Verbindungen nie komplett aufgebaut werden, kann der gescannte Knoten nicht erkennen, ob die Quelladresse der Testpakete gefälscht oder anderweitig manipuliert wurde. Dies gilt insbesondere dann, wenn vorgetäuschter Traffic – das heißt gefälschter Traffic, um den eigentlichen Scan-Traffic zu verbergen – eingesetzt wird, wie bei der Option -D von Nmap.
Das führt üblicherweise zu weniger Paketen, weil die aufgrund von offenen Ports aufgebauten Verbindungen nicht geschlossen oder abgebrochen werden müssen.
Da bei dieser Technik das Scan-Tool die TCP-Pakete erstellen muss, sind in der Regel Superuser-Berechtigungen notwendig. Das ist jedoch heutzutage keine Herausforderung mehr, denn die Nutzer haben im Allgemeinen die volle Kontrolle über das von ihnen verwendete System.
Um mit Nmap einen SYN-Scan auszuführen, geben Sie Folgendes ein:
nmap -sS example.com
Der FIN-, NULL- und XMAS-Scan
Die TCP-Spezifikation deckt die Verarbeitungsregeln von Paketen für alle möglichen Szenarien ab. Das gilt auch für solche, die – obwohl theoretisch denkbar – in der Praxis kaum vorkommen. Einige dieser Szenarien lassen sich zum Zwecke von TCP-Port-Scanning auslösen und nutzen. So besagt etwa die TCP-Spezifikation, dass wenn ein eingehendes TCP-Paket ohne gesetztes ACK-Bit empfangen wird und es sich um kein SYN- oder RST-Paket handelt, der Host folgendermaßen reagieren muss:
Wenn der Port geschlossen ist – das heißt, sich im Status TCP CLOSED befindet –, soll als Antwort ein RST-Segment gesendet werden.
Wenn der Port geöffnet ist – das heißt, sich im Status TCP LISTEN befindet –, soll das eingehende Paket automatisch verworfen werden.
Da je nach Status des entsprechenden Ports ein bestimmtes Paket zu zwei unterschiedlichen Antworten führen kann, lassen sich die zuvor erwähnten Pakete zum Zwecke von TCP-Port-Scanning nutzen. Jedes Paket ohne gesetztes ACK-Bit – das zudem kein SYN- oder RST-Paket ist – kann verwendet werden, um eine der zwei oben beschriebenen Reaktionen auszulösen. Wenn beim Testpaket überhaupt kein TCP-Flag gesetzt ist, wird die Scan-Technik als TCP-NULL-Scan bezeichnet. Wenn beim Testpaket lediglich das FIN- oder Finish-Bit gesetzt ist, spricht man von einem TCP-FIN-Scan. Und wenn beim Testpaket nur das FIN-, PSH- (Push-) und URG- (Urgent-)Bit gesetzt sind, nennt man die Methode XMAS-Scan. Obwohl die Namen für die einzelnen Scan-Verfahren abhängig von den im TCP-Testpaket gesetzten Bits variieren, nutzen alle drei Methoden die gleichen TCP-Verarbeitungsregeln.
Ein möglicher Vorteil dieser Techniken im Vergleich zum Connect- oder SYN-Scan liegt darin, dass dadurch der Port-Scan selbst dann funktioniert, wenn eine Paketfilterung eingehende Verbindungen verhindert, indem sie SYN-Pakete verwirft. Wie beim SYN-Scan kann auch hier ein Zielknoten nicht erkennen, ob die empfangenen Testpakete von einer gefälschten Quelladresse stammen oder nicht – besonders, wenn vorgetäuschter Traffic zum Einsatz kommt.
Um die für TCP-Port-Scanning eingesetzten Methoden zu verstehen, muss man über einen zentralen Mechanismus des Transmission Control Protocol Bescheid wissen: den TCP-Verbindungsaufbau.
Andererseits führen diese Methoden möglicherweise zu einer falschen Interpretation des Port-Status. Da bei einem Port-Scan eines der zwei möglichen Ergebnisse ein verworfenes Testpaket für einen offenen Port ist, kann beispielsweise ein Paket, das aufgrund eines überlasteten Netzwerks – oder aus anderen Gründen – verworfen wurde, entsprechend als offener Port fehlinterpretiert werden. Außerdem müsste das Scan-Tool, um ein verworfenes Paket zu erkennen, üblicherweise länger warten als wenn eine positive Antwort als Hinweis auf einen offenen Port empfangen würde.
Weil diese Scan-Verfahren voraussetzen, dass das Scan-Tool extra erstellte TCP-Pakete sendet, muss das Scan-Tool normalerweise mit Superuser-Berechtigungen ausgeführt werden. Wie bereits für den SYN-Scan gilt aber auch hier: Dies stellt in der Regel keine Herausforderung dar.
Wenn Sie Nmap verwenden, lässt sich der FIN-Scan folgendermaßen starten:
nmap -sF example.com
Anstatt mit der Option -sF für den FIN-Scan können der NULL- und der XMAS-Scan mit den Parametern -sN beziehungsweise -sX aufgerufen werden.
Der ACK-Scan
Beim ACK-Scan handelt es sich im eigentlichen Sinn nicht um eine Methode zum Port-Scanning. Es ist ein Verfahren, das dazu gedacht ist, festzustellen, ob ein bestimmter Port gefiltert wird oder nicht. Wenn ein Paket, bei dem nur das ACK-Bit gesetzt ist, an einen Ziel-Port gesendet wird, gibt es zwei mögliche Resultate, je nachdem, ob eine Portfilterung stattfindet oder nicht:
Nicht gefiltert – das heißt, der Port ist geöffnet oder geschlossen. Als Antwort auf das Testpaket wird ein RST-Paket gesendet.
Gefiltert. Als Reaktion auf das Testpaket wird keine Antwort gesendet.
Wenn Verbindungen zu einem bestimmten Port unterbunden werden, indem eingehende SYN-Pakete verworfen werden, geschieht dies im Allgemeinen automatisch, unabhängig davon, ob der Port geöffnet oder geschlossen ist. ACK-Pakete jedoch lösen nach wie vor eine Antwort aus und helfen dabei, die Art der Paketfilterung, die eingehende Verbindungsanfragen verhindert, festzustellen.
Wie bei den übrigen Scan-Techniken, die eigens erstellte TCP-Testpakete einschließen, lässt sich die Identität des scannenden Knotens leicht verbergen. Das gilt besonders dann, wenn während des Port-Scans vorgetäuschter Traffic zum Einsatz kommt – wie bei der Option -D von Nmap.
Außerdem muss ‑ weil der ACK-Scan voraussetzt, dass das Scan-Tool extra erstellte TCP-Pakete sendet ‑ das Tool in der Regel mit Superuser-Berechtigungen ausgeführt werden. Das allerdings stellt, wie zuvor schon erwähnt, kein ernsthaftes Problem dar.
Um mit Nmap einen ACK-Scan auszuführen, geben Sie den folgenden Befehl ein:
nmap -sA example.com
Fazit
Zwar sind die meisten Netzwerk- und Sicherheitsfachleute mit TCP-Port-Scanning vertraut, dennoch kennen viele nicht die Einzelheiten hinter den verschiedenen, für Port-Scanning verwendeten Techniken und deren Einsatzmöglichkeiten. Dieser Artikel hat Ihnen die zugrunde liegende Theorie hinter jeder der verschiedenen Methoden für TCP-Port-Scanning nähergebracht. Damit besitzen Sie als Netzwerk- und Sicherheitsexperte das notwendige Rüstzeug, um die Scan-Techniken zu identifizieren und zu nutzen, die sich für Ihre Anforderungen und Szenarien am besten eignen. Obwohl die in diesem Artikel vorgestellten Beispiele Nmap verwenden, lassen sie sich auf alle populären Scan-Tools übertragen – etwa auf das im IPv6-Toolkit von SI6 Networks enthaltene Tool scan6.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!
