Portscanner

Ein Portscanner ist eine Software, mit der überprüft werden kann, welche Dienste ein mit TCP oder UDP arbeitendes System über das Internetprotokoll (IP) anbietet. Der Portscanner nimmt dem Anwender dabei die Arbeit ab, das Antwortverhalten eines Systems selbst mit einem Sniffer zu untersuchen und zu interpretieren.

Oft bieten Portscanner auch Zusatzfunktionen wie Betriebssystem- und Diensterkennung an, obwohl diese nichts mit dem eigentlichen Portscannen zu tun haben.

Der Portscanner nimmt im Allgemeinen die Rolle des Clients in einer Client-Server-Architektur ein und beginnt mit dem Senden eines Pakets an einen potenziell vorhandenen Server.

Man spricht von einem offenen Port falls gleichzeitig

1. das initiale Paket den Server über das Netzwerk erreichen kann, und
2. der Server so konfiguriert ist, dass eine Antwort gesendet wird, und die Verbindung akzeptiert wird, und
3. das Antwortpaket über das Netzwerk zurück zum Portscanner kommt.

Ansonsten spricht von einem geschlossenen, oder gefiltertem Port.

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.

(c) Felix Rublack, CC BY-SA 3.0

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.

Die oben genannten Zusatzfunktionen wie OS-Fingerprinting (Erkennen des Betriebssystems) und Diensterkennung, für die z. B. der Portscanner nmap bekannt ist, sind streng genommen keine Portscans mehr und ihr Einsatz kann nicht nur aufgrund eines nicht ganz auszuschließenden Absturzrisikos beim Ziel problematisch sein.

Die Legalität von Portscans ist umstritten, da sie als erste Instanz eines Eindringversuches gewertet werden können. In jedem Fall ist eine Benutzung auf eigenen Systemen legal. Sinn ergibt dies z. B. um das System einem Sicherheitscheck zu unterziehen. Ferdinand Grieger kommt in seiner Publikation zur strafrechtlichen und zivilrechtlichen Analyse von Portscans zu dem Ergebnis, dass beim Ausbleiben typischer Vorgehensweisen wie bei DoS- oder DDoS-Attacken weder ein strafrechtlich relevantes Verhalten des Portscannutzers noch ein zivilrechtlich zu beanstandender Eingriff in den eingerichteten und ausgeübten Gewerbebetrieb im Sinne des § 823 Abs. 1 BGB vorliegt. Sollte man ein zivilrechtlich zu beanstandendes Verhalten des Portscannutzers bejahen, wäre in diesem Fall auch ein Mitverschulden des durch den Scan beeinträchtigten Systeminhaber- oder Betreiber im Sinne des § 254 BGB zu prüfen, sofern dieser zumutbare Maßnahmen nicht ergreift, indem er zuvor bspw. kein Informationssicherheitsmanagementsystem unterhält oder simpelste IT-Sicherheitsmaßnahmen nicht ergriffen hat.^[3]

Unklarer ist die Rechtslage bei Portscans gegen fremde Systeme und Netzwerke. Da beispielsweise empfindliche Computer durch viele Verbindungsanfragen gestört werden können, kann dies als Angriff auf die Verfügbarkeit eines Systems gewertet und in Deutschland durch § 303b StGB (Computersabotage) bestraft werden. Das SANS-Institut bestätigt in einer Veröffentlichung ebenfalls den Zwiespalt von Portscans.^[4]

Portscanner werden jedoch nicht eindeutig als Computerprogramm zum Ausspähen oder Abfangen von Daten nach § 202a StGB oder § 202b StGB(Hackerparagraf) angesehen, da sie keine Sicherheitsmechanismen umgehen und auch keine Daten abfangen können. Je nach Fall kann ein Portscan aber als Vorbereitung zum Ausspähen von Daten gewertet werden. Das Vorbereiten ist nach § 202a StGB ebenfalls strafbar und kann juristisch entsprechend geahndet werden. Die unklare Rechtslage ist also keinesfalls ein Freibrief.

Mit folgendem Befehl kann auf einem unixoiden System mit dem Programm Netcat nach offenen TCP-Ports gesucht werden.

$ nc -vz $zu_scannender_host 1-65535

• Nmap (Unix/Windows/Mac)
• netcat (Unix)
• Scanmetender (Windows und GNU/Linux)
• Blue’s Port Scanner (Windows)
• Superscan (Windows)
• Unicornscan (Unix)
• ZMap (Unix)
• scanrand (Unix)
• Angry IP Scanner (Unix/Windows/Mac)
• iNet Network Scanner (Mac/iOS)

• Penetrationstest
• Netzwerksicherheit

1. ↑ Michael Kerrisk: raw(7) - Linux manual page. In: https://man7.org. 22. Dezember 2023, abgerufen am 23. Januar 2024 (englisch). 
2. ↑ TCP Connect Scan (-sT) | Nmap Network Scanning. Abgerufen am 23. Januar 2024. 
3. ↑ Ferdinand Grieger: Portscans im Lichte des Rechts: eine straf- und zivilrechtliche Analyse. In: International Cybersecurity Law Review. Band 2, Nr. 2. Springer Verlag, 4. Oktober 2021, ISSN 2662-9739, S. 297–316, doi:10.1365/s43439-021-00034-7 (springer.com [abgerufen am 26. Juli 2023]). 
4. ↑ The Ethics and Legality of Port Scanning (englisch)