Portscanner

Ein Portscanner kann die Netzwerkfunktionen des Betriebssystems für TCP oder UDP nutzen (mittels Systemaufrufen), wobei das Betriebssystem TCP oder UDP Pakete erzeugt, sendet, empfängt, und mit Parser verarbeitet. Vorteilhaft bei dieser Methode ist die einfache und wenig aufwendige Programmierung, unter anderem weil die benötigten Systemaufrufe auf unterschiedlichen Betriebssystemen eine ähnliche Semantik haben.

Alternativ kann im Portscanner TCP und UDP implementiert sein, und dieser die Netzwerkfunktionen des Betriebssystems für das IP nutzen. Bei Linux werden Netzwerkfunktionen des Betriebssystems für IP als Raw sockets[1] bezeichnet, und es sind für den Aufruf spezielle Nutzerrechte erforderlich. Der Vorteil dieser Methode gegenüber der ersten ist das hohe Maß an Kontrolle über gesendete Pakete und den Parser für die empfangenen Pakete, unabhängig von der Implementierung des Betriebssystems.

Die dritte Form nutzt sowohl die Netzwerkfunktionen des Betriebssystems als auch des Portscanners.

1. Zuerst sendet der Portscanner ein TCP-SYN-Paket.
2. Ist der Port offen, so wird der Drei-Wege-Handshake weiter durchlaufen.
3. Der Server antwortet mit einer Nachricht des nächsthöheren Protokolls
4. Abschließend sendet der Portscanner ein RST um die Verbindung abzubrechen (so verhält sich Nmap)[2], oder es wird der geregelte Verbindungsabbau durchlaufen, das bedeutet der Portscanner sendet ein FIN und so weiter.

Da die Verbindung zu offenen Ports komplett aufgebaut wird, erscheint sie meistens in den Logdateien des Servers.

Der Portscanner kann den Systemaufruf connect() für den Verbindungsaufbau nutzen. Falls der Systemaufruf connect() erfolgreich war, ist der Port offen, ansonsten geschlossen. Wird die Verbindung mit dem Systemaufruf close() wieder geschlossen, so wird der geregelte Verbindungsabbau durchlaufen.

Beim TCP-SYN-Scan wird ein TCP-Paket mit SYN-Flag an den Ziel-Host gesendet, um einen Verbindungsversuch vorzutäuschen. Die Antwort des Hosts gibt Aufschluss über den Port: Sendet er ein SYN/ACK-Paket, den zweiten Teil des Drei-Wege-Handshakes von TCP, akzeptiert der Port Verbindungen und ist daher offen. Der Quell-Host antwortet dann in der Regel mit einem RST-Paket, um die Verbindung wieder abzubauen (dies geschieht meist allerdings nicht durch den Portscanner, sondern durch das Betriebssystem, da offiziell kein Verbindungsversuch unternommen wurde). Sendet der Host ein RST-Paket, ist der Port geschlossen. Sendet der Ziel-Host überhaupt kein Paket, ist ein Paketfilter vorgeschaltet.

Diese Art von Scan wird auch Stealth-Scan genannt, da TCP-Implementierungen bei nicht vollständig zustande gekommenen Verbindungen den zugehörigen Dienst nicht informieren. Dieser erzeugt daher auch keine Log-Daten für versuchte Verbindungsaufbauten, bzw. bekommt vom Scan überhaupt nichts mit. Aus Anwendungssicht ist der SYN-Scan daher unsichtbar. Dies gilt aber nicht für die Netzwerkebene: Firewalls oder Intrusion Detection Systeme erkennen diese Art von Scan natürlich dennoch und können sie ggf. mit Hilfe des Portknocking-Verfahrens, bei dem der Port erst nach dem Empfangen einer vorvereinbarten Paketsequenz geöffnet wird, blockieren.

Auf den meisten Quell-Systemen sind außerdem Systemverwalterrechte notwendig, weil TCP-Pakete vom Portscanner handgefertigt werden müssen.

TCP-SYN-Scans lassen sich für Denial-of-Service-Attacken in Form von SYN-Flood nutzen.

Diese Methoden bauen keine Verbindung auf, sondern untersuchen das Verhalten auf Folgepakete. Falls ein Port offen ist, sollten die Folgepakete ignoriert werden, da sie nicht zu einer bestehenden Verbindung gehören. Ist der Port geschlossen, sollte ein Reset-Paket gesendet werden.

Welche Flags genau gesetzt werden, hängt vom Scantyp ab:

Dieser Scan wird über einen Mittelsmann, der als Zombie bezeichnet wird, ausgeführt. Der Idlescan ist zurzeit die einzig bekannte Scanmethode, bei der der gescannte Host keine Rückschlüsse auf den scannenden Host ziehen kann, da er nur Pakete des Zombies zu sehen glaubt.

Um als Zombiehost für den Idlescan geeignet zu sein, muss er Bedingungen erfüllen:

1. Der Zombiehost muss Pakete vom Ziel empfangen können
2. Die IPID (IP Identification Number, ein Teil des IP-Headers) muss für den Portscanner vorhersehbar sein.

Die Vorhersagbarkeit der IPID ergibt sich einerseits aus der Tatsache, dass die meisten Betriebssysteme für die IPID einen systemglobalen Zähler einsetzen, der immer dann, wenn das System ein selbst erzeugtes Paket versendet, um einen bestimmten Wert erhöht wird. Die Werte sind je nach Betriebssystem unterschiedlich und typischerweise 1, 4 oder 8. Zudem ist für die Vorhersagbarkeit wichtig, dass der Zombie selbst im Betrieb idealerweise keine der IPID-verändernden Pakete generiert, das System also Idle ist – daher der Begriff Idle-Scan.

Überraschenderweise eignen sich Router recht gut als Zombies, da diese normalerweise Pakete nur durchleiten (wobei sich deren IPID nicht ändert), aber nicht selbst am Netzwerkverkehr teilnehmen.

Schematische Darstellung eines TCP Idlescans

Für den eigentlichen Scan braucht der Portscanner die aktuelle IPID des Zombies. Um die IPID herauszufinden, wird z. B. einfach eine TCP-Verbindungsanfrage (SYN) an ihn geschickt. Der Zombie antwortet SYN|ACK oder RST, das Antwortpaket enthält die aktuelle IPID (2).

Für den eigentlichen Portscan schickt der Angreifer ein gespooftes SYN-Paket an das Ziel (3). Als Quell-IP-Adresse setzt der Angreifer die IP-Adresse des Zombiehosts. Falls der Port offen ist, sendet das Ziel ein SYN|ACK-Paket an den Zombie (4a). Da er keine Verbindung geöffnet hat, schickt der Zombie ein RST-Paket an das Ziel (4a). Unter der Annahme, dass der Zombie die IPID immer um den Wert eins inkrementiert, gilt: Dieses Reset wird mit einer IPID + 1 an das Ziel gesendet. Ist der Port geschlossen, sendet das Ziel ein RST-Paket an den Zombie (4b). Dieses Paket wird vom Zombie einfach ignoriert. Nun fragt der Angreifer in gleicher Weise wie zu Beginn nach der aktuellen IPID (5). Ist die IPID um 2 gestiegen (1 Paket an Ziel + 1 Paket an Angreifer), ist der Port offen. Ist die IPID nur um 1 höher (nur 1 Paket an Angreifer), so ist der Port geschlossen (6).

Ein direkter Scan von UDP-Ports ist nicht möglich, da das Protokoll verbindungslos arbeitet. Über einen Umweg ist ein Scan trotzdem möglich. Dazu wird ein leeres UDP-Paket an den entsprechenden Port geschickt. Kommt ebenfalls ein UDP-Paket zurück, ist der Port offen. Kommt keine Antwort, ist der Port entweder geschlossen oder gefiltert. Wird eine „Port Unreachable“-Fehlermeldung empfangen, ist der Port geschlossen. Auf den meisten Systemen ist die Ausgabe von ICMP-Fehlermeldungen gedrosselt, um einen Denial-of-Service-Angriff zu verhindern. Daher sind UDP-Scans meistens zeitaufwendig.

Bei einem FTP-Bounce-Scan benötigt der Angreifer einen FTP-Server, der den PORT-Befehl zulässt. Über den PORT-Befehl kann der Angreifer die IP-Adresse des Opfers und einen zu überprüfenden Port übergeben. Kann der FTP-Server mit den übergebenen Daten eine Verbindung etablieren, so läuft ein Dienst auf dem Port, was der Server dem Angreifer bekanntgibt. Diese Spielart von FTP war ursprünglich dazu gedacht, Dateien zwischen Servern bequem kopieren zu können. Der Angreifer bleibt dabei unsichtbar für das Opfer, da nie eine direkte Verbindung zwischen Opfer und Angreifer aufgebaut werden muss.