[Einleitung]

1) Normaler Scan mit vollem TCP-Connect:

Wie der Name schon sagt, hierbei handelt es sich um eine Scan-Methode, die darauf abzielt, Services, die auf Basis des TCP arbeiten zu finden. Der Ablauf funktioniert folgendermaßen: Der Client(der scannende) versucht, zu jedem Port des Hostes eine vollständige Verbindung herzu- stellen - hat dies funktioniert, gilt der Port als erreichbar. Der Client schickt ein TCP/IP-Paket mit gesetztem SYN-Flag und erhält vom Host entweder "RST" bei einem nicht erreichbaren Port, oder "SYN-ACK" bei einem erreichbaren. In diesem Fall antwortet der Client wieder mit "ACK" und die Verbindung steht. Jede Verbindung auf diese Weise einzeln aufzubauen und dann wieder zu beenden würde viel zu lange dauern, als daß man damit viele Ports scannen könnte. Also wird hierbei meistens die Multi-Socket-Methode angewandt, bei der der Client viele Anfragen gleichzeitig stellt. Der Vorteil dieser Scan-Methode ist, daß sie - bei Verwendung von Muli-Socket-Scans - sehr schnell ist, allerdings in jeder Logfile auftaucht. Wird jede Verbindung einzeln gescannt, so ist der Zeitrahmen nicht mehr vertretbar...


2) Halboffenes Scanning Auch eine TCP-Scanmethode:

Hierbei wird keine volle Verbindung zum Host hergestellt, sondern nach Erhalt der "SYN-ACK"-Bestätigung von einem erreichbaren Socket sofort mit "RST" die Verbindung abgebrochen. Der Vorteil dieser Methode ist, daÏ sie bei geringem Sicherheits- und Überwachungsstatus des Hosts nicht geloggt wird. Der Nachteil ist, daß man unter Linux/Unix root sein muß, um diese Methode durchzuführen, unter Windows funktioniert sie glaube ich gar nicht...


3) TCP-Fin-Scanning:

Diese Methode beruht auf einem Bug in vielen TCP-Implementationen. Hierbei wird an die zu scannenden Ports ein TCP-Paket mit dem "FIN"-Flag geschickt, welches normalerweise dazu dient, eine bestehende Verbindung ordentlich zu beenden. Offene Ports beantworten dieses "Fin"-Paket jedoch oftmals nicht mit dem zu erwartenden "RST" - geschlossene tun dies. Diese Methode ist zwar ziemlich unauffällig (wenn auch nicht unentdeckbar), funkioniert aber nicht bei allen Betriebsystemen (Microsoft ist immun, Unix/Linux funktionieren bis jetzt noch). Weiterer Nach- teil ist, daß dies eigentlich eine "unsaubere" Scanmethode ist, da man hier nach Ports scannt, die NICHT erreichbar sind. Bis jetzt kenne ich keinen Portscanner für Windows, der diese Mehode unterstützt...


4) Fragmentiertes Scanning:

Nur eine Abart der anderen TCP-Scans, bei der die TCP-Pakete in viele kleine Pakete aufgeteilt werden. Diese zusÔtzliche Technik hilft manchmal, Paket-Filter zu umgehen.


5) FTP-Bounce-Attacke über Proxy:

Ganz selten verwendete Technik zum Erkennen von TCP-Ports. Ihr Vorteil ist, daß hiermit in manchen Fällen Rechner hinter Firewalls gescannt werden können, der große Nachteil, daß sie extrem langsam ist und nur für gezielte Angriffe/"Stichproben" taugt. Hierbei wird über einen Proxy ein FTP-Server kontaktiert und mit dem Port-Kommando ein Ausgangsport des Konnektors definiert. Wird jetzt z.B. das LIST-Kommando gesendet, versucht der FTP-Server, das Verzeichnis- listing an den Socket (zu scannender Host+definierter Port) zu senden. Ist dieser Port erreichbar, so antwortet der FTP-Server mit "LIST command successful", ansonsten mit "Couldn't establish connection" Diese Technik funktioniert in den seltensten Fällen.


6) UDP ICMP Port-Unreachble-Scanning:

Scanmethode für UDP. Das Problem bei UDP ist ja, das keine EmpfangsbestÔtigungen zurìckgesendet wird. Allerdings wird eine "nicht-erreichbar"-Meldung von geschlossenen Ports zurückgeschickt. Man scannt also Ports durch und wartet auf eine ICMP_PORT_UNREACH-Meldung. Damit weiÏ man dann, welche Ports NICHT erreichbar sind. Auch diese Methode funktioniert meines Wissens nur unter Linux/Unix (allerdings gegen jedes OS) und der scannende Prozess muß die UID 0 haben.


7) UDP Recvfrom-And-Write-Scanning:

Die Methode (6) hat den Nachteil, daß nur root die ICMP_PORT_UNREACH-Meldung erhält. Es gibt jedoch auch für normale Benutzer über einen Umweg die Möglichkeit, von nicht erreichbaren UDP- Ports in Kenntnis gesetzt zu werden. Grund ist wieder ein Bug: Versucht man zu einem Port, der eben schon mal mit ICMP_PORT_UNREACH geantwortet hat zu schreiben, so erhält man meist die Meldung: "Error 13 - Try Again", anstatt des normalen: "Error 111 - Connection refused" Bei dieser Methode wird also jeder Port zweimal gescannt - bei Fehler 13 ist der Port zu.


8) ICMP echo scanning/ping Scan für das ICM-Protokoll:

Eigentlich kein Portscan, da ICMP keine Adressierung an Ports kennt, ist aber auch ziemlich wichtig, da so festgestellt werden kann, welche hosts überhaupt erreichbar sind - sollte man anwenden, bevor man einen Portscan startet, sonst hat man einen Host gescannt, den es gar nicht gibt - das ist natürlich Zeitverschwendung! Hierbei handelt es sich um den einfachen Ping über ICMP...

[Wenn man offene Ports gefunden hat]

Hat man jetzt offene Ports gefunden, so hat man schonmal einen Überblick über die laufenden Services (siehe Portliste). Jetzt kann man anfangen, nach evtl. schon bekannten Bugs in diesen Prozessen zu suchen, oder selber welche zu erforschen. Weiter kann erfahren, welches OS läuft (unter FTP STAT und SYST, Telnet). Auch kann man Rückschlüsse über das Netzwerk, in dem sich der Host befindet ziehen. Ist z.B. rlogin offen, so weiß man das es noch weitere Hosts gibt, die mit dem gescannten in Verbindung stehen - vorausgesetzt, der Rechner ist nicht fehlkonfiguriert...