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:

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:

 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:

Um Beispielsweise hping als ping zu gebrauchen muss man folgendes Kommando ausführen:

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.

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 :

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:

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:

192.168.0.4 ist hier eine nicht-existierende Adresse. Tcpdump gibt
hierzu folgendes aus:

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.

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

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.

5.3. RST Scans

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.

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.

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.

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.

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“:

Nun iniziieren wir den gespooften Scan:

In einer weiteren Session überprüfen wir das IP IDENTIFICATION Feld:

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

(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:

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:

Getest habe ich dieses Verfahren mit der Honeywall RO1.0.hw189 http://www.honeynet.org/