Hping2 eine Einführung
1. Einleitung
Das versenden von fehlerhaften Paketen kann zu Netzwerkstörungen oder Abstürzen von Computersystemen führen. Ich übernehme keine Verantwortung für Schäden, die durch die Benutzung von hping und diesem Tutorial entstanden sind. Die folgenden Beispiele dürfen nur zu Test- und Lernzwecken im eigenen Netzwerk auf eigene Verantwortung durchgeführt werden.
Hping ( http://www.hping.org ) ist ein Programm, mit welchem Sie selber IP-Pakete erstellen und analysieren können. In diesem Text werde ich eine kurze Beschreibung dieses Programms mit Beispielen aus der Praxis zeigen. Die Möglichkeit mit Hping Pakete erstellen zu können die nicht der Norm entsprechen, machen es zu einem sehr interessanten und zugleich gefährlichen Werkzeug.
2. Installation
Hping setzt die libpcap (Packet Capture Library) vorraus um Pakete
erzeugen zu können.
Installation unter Debian:
apt-get install hping2
Installation aus den Sourcen:
…Hping benötigt die libpcap, wenn diese nicht durch die Distribution zur Verfügung gestellt wird, muss diese ebenfalls von Hand installiert werden (http://sourceforge.net/projects/libpcap/). Nachdem wir uns von (http://www.hping.org/download.html) die Sourcen heruntergeladen haben, entpacken wir das Ganzeund installieren wie folgt:
nxk-01:/home/okami# tar -xzf hping2.0.0-rc3.tar.gz nxk-01:/home/okami# cd hping2.0.0-rc3 nxk-01:/home/okami/hping2.0.0-rc3# ./configure nxk-01:/home/okami/hping2.0.0-rc3# vi Makefile (optional) nxk-01:/home/okami/hping2.0.0-rc3# make nxk-01:/home/okami/hping2.0.0-rc3# su nxk-01:/home/okami/hping2.0.0-rc3# make install
3. Erste Gehversuche
Prinzipiell lässt sich hping nur als root ausführen, da der normaleUser kein Recht hat, ein erstelltes IP-Pakete direkt an ein Netzwerkinterface zu senden. Hping ist ein Komandozeilen-Tool, dessen Bedienung an ping angelehnt ist – der Name ist hier Programm. Während ping aber nur in der Lage ist einfache ICMP-Echo-Requests zu verschicken, liefert uns hping wesentlich mehr. Ein Blick in die Manpage oder das hping –help Kommando geben einen ersten Eindruck. Hping stellt grundlegend folgende Modi zur Verfügung:
-0 --rawip -1 --icmp -2 --udp -8 --scan -9 --listen
Um Beispielsweise hping als ping zu gebrauchen muss man folgendes Kommando ausführen:
nxk-01:/home/okami hping -1 -C 8 192.168.0.1
Die Option „-1“ legt den ICMP-Modus fest und „-C 8“ legt den ICMP-Typ, also Echo-Request fest.
Wenn wir hping ganz ohne Optionen und nur mit der Angabe des Zielhostes starten, sendet hping dabei ein TCP/IP-Paket an 192.168.0.1 Port 0, worauf ein Rechner ohne Firewall mit einem RST-Paket reagiert, welches man an der Ausgabe von hping sieht.
nxk-01:/home/okami# hping 192.168.0.1 HPING 192.168.0.1 (eth0 192.168.0.1): NO FLAGS are set, 40 headers + 0 data bytes len=40 ip=192.168.0.1 ttl=64 DF id=3451 sport=0 flags=RA seq=0 win=0 rtt=0.5 ms len=40 ip=192.168.0.1 ttl=64 DF id=3452 sport=0 flags=RA seq=1 win=0 rtt=1.0 ms len=40 ip=192.168.0.1 ttl=64 DF id=3451 sport=0 flags=RA seq=0 win=0 rtt=0.5 ms len=40 ip=192.168.0.1 ttl=64 DF id=3452 sport=0 flags=RA seq=1 win=0 rtt=1.0 ms len=40 ip=192.168.0.1 ttl=64 DF id=3453 sport=0 flags=RA seq=2 win=0 rtt=0.9 ms len=40 ip=192.168.0.1 ttl=64 DF id=3454 sport=0 flags=RA seq=3 win=0 rtt=0.8 ms len=40 ip=192.168.0.1 ttl=64 DF id=3455 sport=0 flags=RA seq=4 win=0 rtt=0.7 ms
--- 192.168.0.1 hping statistic --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.5/0.8/1.0 ms
Das Ganze liest sich wie folgt:
Len ist die Länge des empfangenen Pakets in Bytes, IP ergibt sich von selber und Flags kann folgende Buchstaben haben:
* R = RST
* S = SYN
* A = ACK
* F = FIN
* P = PSH
* U = URG
DF bedeutet, dass das Don’t Fragment-Bit gesetzt ist und rtt zeigt die Zeit an, nach welcher das Paket zurückgekommen ist.
Wenn wir uns das ganze mit einem Sniffer anschauen, dann sehen wir folgendes :
192.168.0.2.3076 > 192.168.0.1.0: . win 512 192.168.0.1.0 > 192.168.0.1.3076: R 0:0(0) ack 865497768 win 0 (DF)
4. Optionen
Um den Zielport anzugeben (Standard ist 0), verwenden wir die Option „-p“. Dies ist sehr nützlich, da man so einfach Dienste auf ihre Verfügbarkeit abklopfen kann. In dem nächsten Beispiel wollen wir TCP-Pakete mit gesetzten SYN-Bit an einen HTTP-Server geschickt werden. Das SYN-Bit deshalb, weil wir so einen Verbindungswunsch signalisieren.(Three Way Handshake)
Die Option „-S“ wird benutzt, um das SYN-Flag zu setzen (andere Flags verwenden den selben Parameter wie in der Liste in oben, also z.B. -A fürACK).
Eine wesentliche und sehr wichtige Option, wenn man zum Beispiel nicht gleich schlafende Hunde wecken möchte ist die Option „-c“. Mit dieser Option legen wir fest, wieviele Pakete verschickt werden sollen.
Und so haben wir in unserer kleinen Bastelecke schon das erste Beispiel dafür, wie man trotz gefilterten ICMP-Traffic durch Firewalls, Dienste auf Erreichbarkeit testen kann:
nxk-01:/home/okami# hping 192.168.0.1 -p 80 -S -c 1 HPING 192.168.0.1 (eth0 192.168.0.1): S set, 40 headers + 0 data bytes len=44 ip=192.168.0.1 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=32767 rtt=0.6 ms
--- 192.168.0.1 hping statistic --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.6/0.6/0.6 ms
tcpdump ergibt folgendes Bild:
192.168.0.2.3014 > 192.168.0.1.80: S 1059302232:1059302232(0) win 512
192.168.0.1.80 > 192.168.0.2.3014: S 3275439828:3275439828(0) ack 1059302233 win 5840 <mss 1460> (DF)
192.168.0.2.3014 > 192.168.0.1.80: R 1059302233:1059302233(0) win 0
Dies liest sich wie folgt: 192.168.0.2 (der Computer der die Pakete sendet) sendet ein Paket mit gesetztem SYN-Flag nach 192.168.0.1. 192.168.0.1 antwortet mit SYN und ACK und 192.168.0.2 wiederum sendet ein RST zurück. Das geschieht, weil 192.168.0.2 nicht „weiss“, dass hping versucht hat, eine Verbindung herzustellen und denkt, es ist eäußälschlich empfangenes Paket. Um das zu verhindern, können wir dem Kernel oder eine Firewall zwischen den Hosts so konfigurieren, dass keine Pakete mit gesetzten RST-Flag verschickt werden.
Dies bringt uns auch gleich zur nächsten nützlichen Option: „-a“. MitHilfe dieser Option kann das Paket so manipuliert werden, dass die SourceAddresse auf eine beliebig gewünschte IP abgeändert wird, sogenanntes spoofing. So bekommt der „angegriffene“ Host nicht nur nicht unsere IP-Addresse, sondern Antwortet auch an die „gespoofte“ IP-Adresse:
nxk-01:/home/okami# hping 192.168.0.1 -p 80 -S -a 192.168.0.4 HPING 192.168.0.1 (eth0 192.168.0.1): S set, 40 headers + 0 data bytes
--- 192.168.0.1 hping statistic --- 21 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms
192.168.0.4 ist hier eine nicht-existierende Adresse. Tcpdump gibt
hierzu folgendes aus:
192.168.0.4.2835 > 192.168.0.1.80: S 434998816:434998816(0) win 512 arp who-has 192.168.0.4 tell 192.168.0.2
Weil der Rechner im LAN die Mac-Adresse zum Versenden der Nachricht braucht und die nicht hat, benutzt er eine arp-request, der unbeantwortet bleibt. Verwendet man hingegen einen existierenden dritten Rechner, hier 192.168.0.3, bekommt dieser ebenfalls ein paket mit gesetztem SYN-Flag und ACK-Flag.
192.168.0.3.2843 > 192.168.0.2.22: S 408201400:408201400(0) win 512 192.168.0.2.22 > 192.168.0.3.2843: S 118197321:118197321(0) ack 408201401 win 5840 <mss 1460> (DF)
Das Senden der Pakete geht standardmässig im Sekundentakt. Mit der
Option -i oder mit –fast lassen sich andere Geschwindigkeiten festlegen:
* -i n: alle n Sekunden
* -i un: alle n Mikrosekunden (ein Millionstel einer Sekunde)
* –fast: 10 Mal in der Sekunde (wie -i u100000)
5. Scan Techniken
5.1. Syn-Scans
Der Syn-Scan wurde vor ein paar Jahren entwickelt und ist die wohl mittlerweile am verbreitesten Scan-Technik. Ein Syn-Scan gibt uns definitv ein Ergebnis, ob ein Dienst auf einen gescannten Port läuft oder nicht. Dieser Scan, auch als „halb offener Scan“ (oder „half open“) bekannt, arbeitet ähnlich einem TCP Verbindungsaufbau (Three Way Handshake ). Zunächst wird auf einen Port ein SYN Paket geschickt, läuft auf dem Port ein Dienst antwortet dieser gemäß mit einem SYN/ACK – läuft kein Dienst, antwortet uns der Stack mit einem RST/ACK.
Es wurde darauf gesetzt, dass dieser Scan in der Regel nicht von Firewalls erkannt, nicht geloggt und einfach als Verbindungsfehler verworfen wird, da letztendlich die Verbindung nicht aufgebaut wird. Er ist die wohl sinnvollste Kombination aus Unsichtbarkeit und Geschwindigkeit.
Auch SYN DoS-Attacken funktionieren nach diesem Verfahren, da sie den Server mit halboffenen Verbindungen flooden, also quasi zumüllen, und somit daran hindern, normale Verbindungen aufzubauen. Beim Portscannen mit der SYN Technik sollte man einen vernünftigen Rythmus wählen und nicht blind alle Ports scannen, da sonst ein ungewollter DoS begünstigt wird. Das Ziel ist es, unsichtbar zu bleiben, was man mit Sicherheit nicht erreicht, wenn der gescannte Host keine Verbindungen mehr annimmt
nxk-01:/home/okami# hping2 -S 192.168.0.2 -c 1 --scan known Scanning 192.168.0.2 (192.168.0.2), port known 296 ports to scan, use -V to see all the replies +----+-----------+---------+---+-----+-----+ |port| serv name | flags |ttl| id | win | +----+-----------+---------+---+-----+-----+ 22 ssh : .S..A... 128 52563 65535 135 loc-srv : .S..A... 128 62291 65535 139 netbios-ssn: .S..A... 128 63059 65535 445 microsoft-d: .S..A... 128 6996 65535 3689 daap : .S..A... 2 38996 65535 All replies received. Done. Not responding ports:
nxk-01:/home/okami# tcpdump 15:23:05.751543 IP 192.168.0.1.1567 > 192.168.0.2.3689: S 805168091:805168091(0) win 512 15:23:05.751778 IP 192.168.0.2.3689 > 192.168.0.1.1567: S 3310981971:3310981971(0) ack 805168092 win 65535 <mss 1460> 15:23:05.751814 IP 192.168.0.1.1567 > 192.168.0.2.3689: R 805168092:805168092(0) win 0
5.2. SYN/FIN Scans
Der Hintergrund des SYN/FIN Scans liegt in einigen Router- und Firewallimplementierungen. Diese erlauben via Regelsatz, das SYN-Pakete nur in eine Richtung passieren dürfen. Ein SYN/FIN darf allerdings diese Regelsätze passieren und wird darüber hinaus vom Stack des Betriebssystems des Zielhosts wie ein SYN-Paket abgearbeitet, da es das FIN-Flag ignoriert.
296 ports to scan, use -V to see all the replies +----+-----------+---------+---+-----+-----+ |port| serv name | flags |ttl| id | win | +----+-----------+---------+---+-----+-----+ 22 ssh : .S..A... 128 26749 65535 135 loc-srv : .S..A... 128 38013 65535 139 netbios-ssn: .S..A... 128 38781 65535 445 microsoft-d: .S..A... 128 46973 65535 3689 daap : .S..A... 2 12926 65535 All replies received. Done. Not responding ports:
nxk-01:/home/okami# tcpdump 15:43:36.032427 IP 192.168.0.1.1097 > 192.168.0.2.3689: SF 1166959029:1166959029(0) win 512 15:43:36.032711 IP 192.168.0.2.3689 > 192.168.0.1.1097: S 208071229:208071229(0) ack 1166959030 win 65535 <mss 1460> 15:43:36.032749 IP 192.168.0.1.1097 > 192.168.0.2.3689: R 1166959030:1166959030(0) win 0
5.3. RST Scans
nxk-03:/home/okami# hping2 -R 192.168.0.1 -c 1 --scan 80,22,53,139,70,69,8080 -V using eth0, addr: 192.168.0.11, MTU: 1500 Scanning 192.168.0.1 (192.168.0.1), port 80,22,53,139,70,69,8080 7 ports to scan, use -V to see all the replies +----+-----------+---------+---+-----+-----+ |port| serv name | flags |ttl| id | win | +----+-----------+---------+---+-----+-----+ All replies received. Done. Not responding ports: (22 ssh) (53 domain) (69 tftp) (70 gopher) (80 www) (139 netbios-ssn) (8080 webcache)
nxk-03:/home/okami# tcpdump
12:14:44.801256 IP nxk-03.local.net.2487 > 192.168.0.1.netbios-ssn: R 1270347280:1270347280(0) win 512 0x0000: 4500 0028 51e1 0000 4006 a792 c0a8 000b E..(Q...@....... 0x0010: c0a8 0001 09b7 008b 4bb7 f610 28c6 b08e ........K...(... 0x0020: 5004 0200 0725 0000 P....%..
12:14:44.805221 IP nxk-03.local.net.2487 > 192.168.0.1.webcache: R 1943951300:1943951300(0) win 512 0x0000: 4500 0028 0d23 0000 4006 ec50 c0a8 000b E..(.#..@..P.... 0x0010: c0a8 0001 09b7 1f90 73de 57c4 54e7 dce9 ........s.W.T... 0x0020: 5004 0200 05c9 0000
Was wir hier haben, ist ein RST Scan. Dies ist ein Scan, bei dem nur das RST Flag gesetzt wurde. Für was werden nun RST Scans verwendet? RST Scans sind sogenannte umgekehrte Mappings. Diese Scan Technik ist nicht so verbreitet, wie der SYN Scan, aber nichtsdestoweniger sehr wirkungsvoll. Einige ältere IDS ignorieren oder erkennen diese Scan Technik gar nicht.
Wenn man ein RST Paket an einen Port schickt, kann es zu folgenden zwei Szenarien führen.
– keine Antwort:
In diesem Fall können wir mit Gewissheit sagen, dass der Host
existiert.
– ICMP Host unreachable:
In diesem Fall gehen wir mit Gewissheit davon aus der Host
existiert nicht .
5.4. ACK Scans
Der ACK Scan hat den Vorteil, das nur neuere IDS-Systeme und Firewalls ihn erkennen können. Zu dem überträgt jede TCP Verbindung ihre Daten in ACK-Paketen. ACK-Pakete stellen daraus resultierend den größten Anteil des TCP – Traffic dar. IDS-Systeme und Firewalls können diese Pakete keiner Verbindung zuordnen und müssen sie daher passieren lassen, da es sich um validen Traffic handeln könnte. Einzig IDS und Firewalls die mit Zustandstabellen(Connection tracking) arbeiten, sind in der Lage ACK Scans zu filtern.
Das Zielsytem reagiert sowohl bei offen als auch geschlossenen Ports identisch, es versendet jeweils ein RESET. Der ACK Scan ist ein probates mittelum zu testen ob die Firewall mit Zustandstabellen arbeitet, also sogenanntes State Full Inspection. Der Sinn des ACK Scan wird erst so richtig im Zusammenhang mit dem FIN Scan deutlich.
nxk-02:/home/okami# hping2 -A 192.168.0.1 -c 1 --scan 80,22,53,139,70,69 -V using eth0, addr: 192.168.0.1, MTU: 1500 Scanning 192.168.0.1 (192.168.0.1), port 80,22,53,139,70,69 6 ports to scan, use -V to see all the replies +----+-----------+---------+---+-----+-----+ |port| serv name | flags |ttl| id | win | +----+-----------+---------+---+-----+-----+ 22 ssh : ..R..... 64 38697 0 53 domain : ..R..... 64 38953 0 69 tftp : ..R..... 64 39209 0 70 gopher : ..R..... 64 39465 0 80 www : ..R..... 64 39721 0 139 netbios-ssn: ..R..... 64 39977 0 All replies received. Done. Not responding ports:
nxk-01:/home/okami# tcpdump
19:16:56.431104 IP nxk-02.local.net.1253 > nxk-01.local.net.69: . ack 1716092099 win 512 19:16:56.431775 IP nxk-01.local.net.69 > nxk-02.local.net.1253: R 1716092099:1716092099(0) win 0 19:16:56.431797 IP nxk-02.local.net.1253 > nxk-01.local.net.www: . ack 2080830932 win 512 19:16:56.431829 IP nxk-01.local.net.www > nxk-02.local.net.1253: R 2080830932:2080830932(0) win 0 19:16:56.431850 IP nxk-02.local.net.1253 > nxk-01.local.net.69: . ack 4229750357 win 512 19:16:56.431869 IP nxk-01.local.net.69 > nxk-02.local.net.1253: R 1650875159:1650875159(0) win 0 19:16:56.431889 IP nxk-02.local.net.1253 > nxk-01.local.net.www: . ack 3507053261 win 512 19:16:56.431909 IP nxk-01.local.net.www > nxk-02.local.net.1253: R 1292916896:1292916896(0) win 0 19:16:56.431928 IP nxk-02.local.net.1253 > nxk-01.local.net.69: . ack 3963263259 win 512 19:16:56.431946 IP nxk-01.local.net.69 > nxk-02.local.net.1253: R 1384388061:1384388061(0) win 0 19:16:56.431965 IP nxk-02.local.net.1253 > nxk-01.local.net.www: . ack 3893404848 win 512 19:16:56.431984 IP nxk-01.local.net.www > nxk-02.local.net.1253: R 1679268483:1679268483(0) win 0
5.5. FIN Scans
Der Sinn des FIN Scans liegt in der Eigenschaft, wenn ein FIN Paket an einen geschlossenen Port geschickt wird, antwortet dieser mit einem RESET. Trifft das Paket allerdings auf einen offenen Port, so erfolgt keinerlei Reaktion. Hierbei sind geschlossenen Port geschickt wird, antwortet dieser mit einem RESET. Trifft das Paket allerdings auf einen offenen Port, so erfolgt keinerlei Reaktion. Hierbei sind natürlich eventuelle Paketfilter die dazwischen liegen zu berücksichtigen. Diese sind in der Lage, solche Pakete einfach zu vewerfen, diese Pakete mit einem TCP RST oder einem ICMP Port unreachable abzulehnen.
Im folgenden wird ein Rechner gescannt, der die Dienste WWW, SSH und DNS anbietet. Zum Vergleich sind zusätzlich noch geschlossene Ports angegeben.
nxk-02:/home/okami# hping2 -F 192.168.0.1 -c 1 --scan 80,22,53,139,70,69 -V using eth0, addr: 192.168.0.1, MTU: 1500 Scanning 192.168.0.1 (192.168.0.1), port 80,22,53,139,70,69 6 ports to scan, use -V to see all the replies +----+-----------+---------+---+-----+-----+ |port| serv name | flags |ttl| id | win | +----+-----------+---------+---+-----+-----+ 69 tftp : ..R.A... 64 32553 0 70 gopher : ..R.A... 64 32809 0 All replies received. Done. Not responding ports: (22 ssh) (53 domain) (80 www) (139 netbios-ssn)
nxk-01:/home/okami# tcpdump
19:04:04.237700 IP nxk-02.local.net.2060 > nxk-01.local.net.69: F 2097340466:2097340466(0) win 512 19:04:04.238255 IP nxk-01.local.net.69 > nxk-02.local.net.2060: R 0:0(0) ack 2097340467 win 0 19:04:04.238295 IP nxk-02.local.net.2060 > nxk-01.local.net.www: F 1865954356:1865954356(0) win 512 19:04:04.238317 IP nxk-02.local.net.2060 > nxk-01.local.net.69: F 1204387144:1204387144(0) win 512 19:04:04.238338 IP nxk-01.local.net.69 > nxk-02.local.net.2060: R 0:0(0) ack 3402013975 win 0 19:04:04.238358 IP nxk-02.local.net.2060 > nxk-01.local.net.www: F 159239183:159239183(0) win 512 19:04:04.238377 IP nxk-02.local.net.2060 > nxk-01.local.net.69: F 402581311:402581311(0) win 512 19:04:04.238397 IP nxk-01.local.net.69 > nxk-02.local.net.2060: R 0:0(0) ack 2600208142 win 0 19:04:04.238417 IP nxk-02.local.net.2060 > nxk-01.local.net.www: F 1959156577:1959156577(0) win 512 19:04:05.240152 IP nxk-02.local.net.2060 > nxk-01.local.net.www: F 1945803406:1945803406(0) win 512 19:04:05.248173 IP nxk-02.local.net.2060 > nxk-01.local.net.www: F 1144184958:1144184958(0) win 512 19:04:05.256161 IP nxk-02.local.net.2060 > nxk-01.local.net.www: F 1616398122:1616398122(0) win 512 19:04:05.269283 IP nxk-02.local.net.2060 > nxk-01.local.net.www: F 573280409:573280409(0) win 512 19:04:05.289284 IP nxk-02.local.net.2060 > nxk-01.local.net.www: F 1734955292:1734955292(0) win 512
5.5. XMAS Scans
Hier wird einfach ein TCP-Paket an den Server geschickt, bei dem die FIN/URG/PSH Flags gesetzt sind. Wenn der Port offen ist, wird der Server antworten; ist der Port geschlossen, sendet der Server ein Packet zurück bei dem die RST/ACK Flags gesetzt sind. Dies gillt bei allen Betriebssystemen deren TCP Implementierung auf dem Standard (RFC 793[4]) für TCP basiert. Da Microsoft sich wie so oft nicht an einen Standard hält und seinen eigenen Kram macht, bekommt man bei allen Windows Betriebsystemen nur geschlossene Ports als Ergebnis zurück.Windows ist daher nicht für einen Xmas Scan anfällig.
nxk-03:/home/okami# hping2 -X 192.168.1.5 -c 1 --scan 80,22,53,139,70,69,8080 -V using eth0, addr: 192.168.0.11, MTU: 1500 Scanning 192.168.1.5 (192.168.1.5), port 80,22,53,139,70,69,8080 7 ports to scan, use -V to see all the replies +----+-----------+---------+---+-----+-----+ |port| serv name | flags |ttl| id | win | +----+-----------+---------+---+-----+-----+ 53 domain : ..R.A... 63 1792 0 69 tftp : ..R.A... 63 2048 0 70 gopher : ..R.A... 63 2304 0 80 www : ..R.A... 63 2560 0 139 netbios-ssn: ..R.A... 63 2816 0 8080 webcache : ..R.A... 63 3072 0 All replies received. Done. Not responding ports: (22 ssh)
nxk-03:/home/okami# tcpdump
10:11:13.118765 IP 192.168.1.5.www > nxk-03.local.net.2919: R 0:0(0) ack 1206382416 win 0 0x0000: 4500 0028 001d 4000 3f06 b952 c0a8 0105 0x0010: c0a8 000b 0050 0b67 0000 0000 6a2c 6617 0x0020: 5014 0000 5175 0000 0000 0000 0000
10:11:13.118802 IP nxk-03.local.net.2919 > 192.168.1.5.ssh: E win 512 0x0000: 4500 0028 a9d4 0000 4006 4e9b c0a8 000b 0x0010: c0a8 0105 0b67 0016 5f87 f6e2 64da df66 0x0020: 5040 0200 851b 0000
5.6. NULL Scans
Hier wird gar kein Flag gesetzt. Ist der Port geöffnet, kommt nichts zurück;ist er geschlossen, ein Paket bei dem die Flags RST/ACK gesetzt sind. Wie beim Xmas Scan sind nur Betriebssysteme für diese Technike anfällig, die dem RFC Standard entsprechen. Somit lässt sich jedoch wenigstens das Betriebsystem des Hosts, den man scannt, grob eingrenzen.
Ein weiteres Problem bei Xmas, FIN und Null Scans sind Firewalls. Normalerweise geben diese kein RST zurück, sondern droppen(=verwerfen) die Pakete einfach. Somit sieht es dann aus,als seien alle Ports geöffnet. Trotzdem ist diese Technik eine einfache, mächtige und unsichtbare Methode Systeme zu scannen.
5.6. Idle Scans
Kommen wir nun zu einer interessanten Scantechnik, die auf eine etwas andere Art und Weise arbeitet als die vorherigen. Aus Sicht eines Angreifers sind all diese Techniken unbefriedigend, da sie nicht zuverlässig verhindern können, dass seine IP-Adresse registriert wird. Ideal wäre es, wenn er gar keine Pakete mit seiner wahren Adresse an sein Opfer schicken müsste. Und genau das ermöglicht der so genannte Idle-Scan.
Hier wird der Umstand ausgenutzt, auf welche Art und Weise IP-IDs vom Betriebsystem vergeben werden. Jedes IP-Paket wird vom Host mit einer ID versehen. Dies geschieht abhängig vom Betriebssystem – in der Regel wird die ID einfach inkrementiert. Das gibt uns zum Beispiel die Möglichkeit mit ziemlich einfachen Mitteln die Auslastung eines Servers herauszubekommen. Wie die ID vom jeweiligen Server vergeben wird, testen wir mit einem einfachen Ping und die Antwortpakete zeigen uns die Art und Wiese der Vergabe.
Beim Idle Scan bedient sich der Scanner eines zweiten Systems, das derzeit keine eigenen Internet-Aktivitäten aufweist. Das äußert sich bei Windows-Systemen (und einigen anderen) so, dass die IP-IDs der Pakete des Idle-Hosts sequenziell ansteigen.
nxk-03:/home/okami# hping2 -S -p 80 192.168.0.1 HPING 192.168.0.1 (eth0 192.168.0.1): S set, 40 headers + 0 data bytes len=46 ip=192.168.0.1 ttl=128 id=3556 sport=80 flags=RA seq=0 win=0 rtt=0.2 ms len=46 ip=192.168.0.1 ttl=128 id=3557 sport=80 flags=RA seq=1 win=0 rtt=0.2 ms len=46 ip=192.168.0.1 ttl=128 id=3558 sport=80 flags=RA seq=2 win=0 rtt=0.2 ms
Dieses Feature lässt sich unter anderem auch zu heimlichen Lastmessungen ausnutzen (Details dazu finden Sie in c’t 23/03, S. 212: „Wer zählt gewinnt“).
Dann deckt der Scanner den Idle-Host mit einem kontinuierlichen Strom von Paketen ein, die eine Antwort erzeugen und wertet deren IP-IDs aus. Das können beispielsweise Ping-Anfragen und die dazughörigen Antworten sein. Jedes weitere Paket, das der Idle-Host jetzt verschickt, bewirkt einen Sprung in der IP-ID-Sequenz: 3, 4, 6, 7 bedeutet, dass der Rechner ein Paket mit der ID 5 an eine andere Adresse geschickt hat (sofern das Paket nicht verloren gegangen ist, was aber recht selten geschieht).
Im nächsten Schritt schickt der Scanner ein SYN-Paket mit der Absender-Adresse des Idle-Hosts an sein eigentliches Opfer, den Server. Ist auf dem angesprochenen Port ein Dienst aktiv, antwortet der Server mit SYN/ACK an den Idle-Host. Dieser weiß jedoch nichts von einer Verbindungs-Anfrage seinerseits und antwortet deshalb mit einem Reset-Paket. War der Port jedoch geschlossen, schickt der Server ein Reset an den Idle-Host, das dieser jedoch ignoriert.
Der Scanner sieht also bei einem offenen Port einen Sprung in der IP-ID-Sequenz des Idle-Hosts (das RST-Paket), bei einem geschlossenen Port tut sich nichts. Eventuelle Paketverluste kann man durch Wiederholen der Scans auf den fraglichen Ports erkennen.
Offener Port
Das RST-Paket bewirkt einen Sprung in der IP-ID-Sequenz des Idle-Hosts, den der Scanner registriert.
Angreifer –> IPID Probe –> Zombie
(SYN/ACK)
Zombie –> Response; IPID=12345 –> Angreifer
(RST)
Angreifer –> Session Request from Zombie –> Ziel
(Syn auf Port 80 mit der Zombie Absenderadresse)
Ziel –> Session Acknowledgement –> Zombie
(SYN/ACK)
Zombie –> Bogus Session; IPID=12346 –> Ziel
(RST)
Angreifer –> IPID Probe –> Zombie
(SYN/ACK)
Zombie –> Response; IPID=12347 –> Angreifer
(RST)
Geschlossener Port
Das RST-Paket des Servers erfordert keine Antwort, die IP-ID-Sequenz bleibt
linear.
Angreifer –> IPID Probe –> Zombie
(SYN/ACK)
Zombie –> Response; IPID=12345 –> Angreifer
(RST)
Angreifer –> Session Request from Zombie –> Ziel
(Syn auf Port 80 mit der Zombie Absenderadresse)
Ziel –> Bogus Request; Port Closed –> Zombie
(RST)
Angreifer –> IPID Probe –> Zombie
(SYN/ACK)
Zombie –> Response; IPID=12346 –> Angreifer
(RST)
Da es kein Problem darstellt, solche Idle-Hosts aufzupüren, sind Port-Scan-Alarme
nutzlos geworden. Die einzigen, die man damit noch fängt, sind Script-Kiddies –Klingelputzer eben. Echte Einbrecher kennen und nutzen die Idle-Scan-Technik längst. Bei einer Strafverfolgung beziehungsweise bei disziplinarischen Maßnahmen gegen vermeintliche Verursacher von Port-Scans ist zu beachten, dass die Fährten auch bewusst falsch gelegt worden sein können.
Zuerst suchen wir uns einen „Zombieserver“:
nxk-03:/home/okami# hping2 -SA -r 192.168.0.1 HPING 192.168.0.1 (eth0 192.168.0.1): SA set, 40 headers + 0 data bytes len=46 ip=192.168.0.1 ttl=128 id=4808 sport=0 flags=R seq=0 win=0 rtt=0.2 ms len=46 ip=192.168.0.1 ttl=128 id=+1 sport=0 flags=R seq=1 win=0 rtt=0.2 ms len=46 ip=192.168.0.1 ttl=128 id=+1 sport=0 flags=R seq=2 win=0 rtt=0.2 ms
Nun iniziieren wir den gespooften Scan:
nxk-03:/home/okami# hping2 -I eth0 -a 192.168.0.1 -S 192.168.10.33 -p ++20 HPING 192.168.0.33 (eth0 192.168.0.33): S set, 40 headers + 0 data bytes
In einer weiteren Session überprüfen wir das IP IDENTIFICATION Feld:
nxk-03:/home/okami# hping2 -I eth0 -r -S 192.168.0.1 -p 2000 HPING 192.168.0.1 (eth0 192.168.0.1): S set, 40 headers + 0 data bytes
len=46 ip=192.168.0.1 flags=RA seq=86 ttl=255 id=+1 win=0 rtt=1.6 ms len=46 ip=192.168.0.1 flags=RA seq=87 ttl=255 id=+2 win=0 rtt=1.6 ms (port 21) len=46 ip=192.168.0.1 flags=RA seq=88 ttl=255 id=+1 win=0 rtt=1.8 ms len=46 ip=192.168.0.1 flags=RA seq=89 ttl=255 id=+1 win=0 rtt=1.7 ms len=46 ip=192.168.0.1 flags=RA seq=90 ttl=255 id=+1 win=0 rtt=1.8 ms len=46 ip=192.168.0.1 flags=RA seq=91 ttl=255 id=+2 win=0 rtt=1.4 ms (port 25)
6.0 Firewall Mapping
6.1. Firewalking
Beim firewalking geht es darum, mittels gezielten Netzwerkpaketen herauszufinden, welche Layer 4 Protokolle durch ein Firewall-/ Paketfilterdevic) weitergeleitet werden. Beim Firewalking werden TCP oder UDP Pakete mit einer um eins grösseren TTL als das Gatewaydevice verschickt. Wenn das Paket die Firewall passieren darf, wird dieses auf dem darrauffolgenden Device mit einer ICMP-Mitteilung »Time excceded« quittiert, da die TTL abgelaufen ist. Falls die Firewall keine Weiterleitung erlaubt, werden die Pakete verworfen und wir erhalten kein Antwortpaket.
Die Arbeitsweise ist die selbe wie bei traceroute. Bringen wir uns dies noch einmal kurz in Erinnerung: Hier kommen zwei Techniken zum Einsatz. Zum einen ist dies die Variation des Time-to-live-Feldes der UDP-Testpakete. Erinnern Sie sich an die Aufgabe dieses TTL-Feldes, das verhindern soll, dass fehl geleitete Pakete ewig im Netz kursieren. Jeder Rechner, den ein Paket passiert, inkrementiert hierzu den Wert des Feldes. Sinkt der Wert auf Null, wird der aktuelle Rechner, insofern er nicht das Ziel markiert, das Paket verwerfen und eine Fehlermitteilung an den Absender initiieren (ICMP-Meldung Time excceded). Traceroute erzwingt eine solche Fehlernachricht von jeder Zwischenstation, die das Paket durchläuft.
Auf dem Zielrechner kontaktiert Traceroute den Port 33434. In der Regel wartet niemals ein Programm auf diesem Port, sodass der Rechner den Verbindungswunsch als Fehler interpretiert und seinerseits mir der ICMP-Mitteilung Unreachable Port antwortet. Hieran erkennt Traceroute das Erreichen des Ziels.
Aus Effizienzgründen sendet Traceroute zu einer Zeit gleich mehrere UDP-Pakete aus Des Weiteren wird in der Voreinstellung jedes Paket genau drei Mal versandt, um zum Einen eine gewisse Resistenz gegenüber Fehlern zu wahren (bspw. darf ein Router bei Überlastung Pakete verwerfen, ohne entsprechende Fehlerpakete auszusenden) und zum Anderen mehrere Zeitmessungen vorzunehmen (um Ausreißer zu markieren). Fehlversuche kennzeichnet Traceroute mit einem Stern (*). Es ist durchaus möglich, dass Traceroute einen Weg zum Ziel findet, obwohl ein Zwischenrechner scheinbar nicht erreichbar ist (nur Sterne in der Ausgabe). Ursachen sind zumeist Fehler in Traceroute -Implementierungen mancher Unix-Systeme, die dazu führen, dass die Time exceeded Fehlermitteilung den Absender nicht erreichen.
Wenn wir nun den genauen Hopcount unseres Zieles kennen, können wir den Scan beginnen. Je nach Anforderung nutzen wir HPING im TCP, UDP oder ICMP Modus. Kurz noch ein paar hilfreiche Optionen kurz erläutert:
-t setzt die TTL mit der wir beginnen wollen
-z mit ctrl+z erhöhen wir die TTL um eins
nxk-03:/home/okami# hping2 -z -t 1 -S target.host.net -p 666 HPING target.host.net (eth0 www.xxx.yyy.zzz): S set, 40 headers + 0 data bytes TTL 0 during transit from ip=192.168.0.1 name=aaa.bbb.ccc.ddd TTL 0 during transit from ip=192.168.0.1 name=aaa.bbb.ccc.ddd TTL 0 during transit from ip=192.168.0.1 name=aaa.bbb.ccc.ddd TTL 0 during transit from ip=192.168.0.1 name=aaa.bbb.ccc.ddd (Erhöhung der TTL mittels ctrl+1) 2: TTL 0 during transit from ip=xx.yy.zz.32 name=erster.knoten.net TTL 0 during transit from ip=xx.yy.zz.32 name=erster.knoten.net (Erhöhung der TTL mittels ctrl+1) 3: TTL 0 during transit from ip=xx.yy.ff.8 name=zweiter.knoten.net TTL 0 during transit from ip=xx.yy.ff.8 name=zweiter.knoten.net (Erhöhung der TTL mittels ctrl+1) 4: TTL 0 during transit from ip=xx.yy.dd.152 name=dritter.knoten.net TTL 0 during transit from ip=xx.yy.dd.152 name=dritter.knoten.net . . . 9: TTL 0 during transit from ip=www.xxx.yyy.zzz name=target.host.net TTL 0 during transit from ip=www.xxx.yyy.zzz name=: TTL 0 during transit from ip=www.xxx.yyy.zzz name=target.host.net TTL 0 during transit from ip=www.xxx.yyy.zzz name=target.host.net 10: TTL 0 during transit from ip=www.xxx.yyy.zzz name=target.host.net TTL 0 during transit from ip=www.xxx.yyy.zzz name=target.host.net TTL 0 during transit from ip=www.xxx.yyy.zzz name=target.host.net TTL 0 during transit from ip=www.xxx.yyy.zzz name=target.host.net 11: len=46 ip=www.xxx.yyy.zzz ttl=119 id=30524 sport=666 flags=SA seq=26 win=16384 rtt=89.5 ms len=46 ip=www.xxx.yyy.zzz ttl=119 id=31219 sport=666 flags=SA seq=27 win=16384 rtt=99.3 ms len=46 ip=www.xxx.yyy.zzz ttl=119 id=31900 sport=666 flags=SA seq=28 win=16384 rtt=89.0 ms len=46 ip=www.xxx.yyy.zzz ttl=119 id=32588 sport=666 flags=SA seq=29 win=16384 rtt=79.7 ms len=46 ip=www.xxx.yyy.zzz ttl=119 id=33320 sport=666 flags=SA seq=30 win=16384 rtt=88.7 ms len=46 ip=www.xxx.yyy.zzz ttl=119 id=34028 sport=666 flags=SA seq=31 win=16384 rtt=88.3 ms len=46 ip=www.xxx.yyy.zzz ttl=119 id=34690 sport=666 flags=SA seq=32 win=16384 rtt=79.1 ms len=46 ip=www.xxx.yyy.zzz ttl=119 id=35340 sport=666 flags=SA seq=33 win=16384 rtt=68.9 ms
(Hopcount 11) gesendet und dessen IP-ID’s lassen uns darauf schliessen, das dort eine Menge los ist ;-).
7.0 Honeypot und IDS Detection
Honeypots und IDS werden verwendet um Angriffe und Vorgensweisen von Angreifern zu protokollieren. Aktuelle Versionen von IDS – Systemen bieten darüber hinaus noch die Möglichkeit einer Reaktion, zum Beispiel das zurücksetzten von Ports(senden eines RST). Im Gegensatz zu IDS-Systemen werden Honeypots gezielt plaziert, um Angreifer in die Irre zu führen und um seine Vorgensweise zu analysieren. Im Gegenzug versuchen IDS Systeme an neuralgischen Punkten des Unternehmensnetzwerkes sowohl Mißbrauch, Anomalien sowie Angriffe
zu erkennen und zu protokollieren. Im Einzelfall lösen Sie einen bestimmten Maßnahmenkatalog aus, der von der Alamierung via eMal, SMS bis hin zu aktiven Eingriff in etwa den Paketfilter reichen kann.
7.1. Spiele mit dem Honigtopf
Ein Angreifer ist immer versucht Server und Dienste auf Schwachstellen zu testen. Hierbei ist er jedoch nicht in der Lage zwischen existierenden Servern/Diensten und Honeypots zu unterscheiden. Trifft er nun auf einen Honeypot wird er zwangsläufig die angebotenen Dienste in Anspruch nehmen. Der Honeypot protokolliert in diesem Fall sein Vorgehen, dieses Material kann dann zur Analyse seines Vorgehens verwendet werden. Um das restliche Unternehmensnetzwerk zu schützen, werden Honeypots mir Hilfe von transparente Brücken abgesichert. Diese Überwachen den Traffic zu und von den Honeypots und filtern alle ausgehenden Angriffe.
Genau hier setzt das Verfahren an, man schickt einfach einen Ping mit einem Datenpacket das einen Shellcode enthält an den Server und vergleicht das ausgehende ICMP Packet mit der Rückgabe des Servers. Erhält man keine Antwort auf einen Ping mit Shellcode, oder ein verändertes Datenpacket, dann handelt es sich bei dem Server um einen Honeypot, der durch eine Honeywall gesichert wird. Am besten man schickt zuvor einen Ping mit einem Packet ohne Shellcode um zu testen ob der Server überhaupt auf Pings reagiert. Letztenendes kann man jedoch nach diesem Schema jeden Dienst zum testen auf eine Honeywall verwenden, der die gleichen Daten zurückliefern muss, wie die, die er bekamm. Schickt man also ein ICMP Packet mit dem Datenpacket Security an den Honeypot, so sieht man dass man keinen Packetlost hat und mittels Etheral auch, dass es sich um den selben Inhalt handelt:
nxk-01:/home/okam#hping2 -d 5 -E testpacket.txt -c 1 10.0.0.20 HPING 10.0.0.20 (eth0 10.0.0.20): icmp mode set, 28 headers + 5 data bytes [main] memlockall(): Success Warning: can't disable memory paging! len=46 ip=10.0.0.20 ttl=64 id=3471 icmp_seq=0 rtt=1.2 ms 10.0.0.20 hping statistic 1 packets tramitted, 1 packets received, 0% packet loss roundtrip min/avg/max = 1.2/1.2/1.2 ms
Sendet man nun hingegen ein Packet mit einem Shellcode, so bekommt man entweder keine Antwort oder aber ein Datenpacket dessen Inhalt sich geändert hat:
nxk-03:/home/okami#hping2 -1 -d 45 -E shellcode.txt -c 1 10.0.0.20 HPING 10.0.0.20 (eth0 10.0.0.20): icmp mode set, 28 headers + 45 data bytes [main] memlockall(): Success Warning: can't disable memory paging! 10.0.0.20 hping statistic 1 packets tramitted, 0 packets received, 100% packet loss roundtrip min/avg/max = 0.0/0.0/0.0 ms
Getest habe ich dieses Verfahren mit der Honeywall RO1.0.hw189 http://www.honeynet.org/