IDS - Intrusion Detection System, Teil I

ArticleCategory: [Choose a category, translators: do not translate this, see list below for available categories]

SystemAdministration

AuthorImage:[Here we need a little image from you]

[Photo of the Author]

TranslationInfo:[Author + translation history. mailto: or http://homepage]

original in de Klaus M�ller

AboutTheAuthor:[A small biography about the author]

Klaus M�ller a.k.a. 'Socma' ist momentan noch Sch�ler und besch�ftigt sich vor allem mit Linux-Programmierung und sicherheitsrelevanten Themen.

Abstract:[Here you write a little summary]

Dies ist der erste Artikel in einer Serie �ber Intrusion Detection Systeme. Im diesem ersten Teil werden nicht nur typische IDS-Architekturen vorgestellt, sondern vor allem typische Angriffe gegen Intrusion Detection Systeme behandelt und analysiert.

ArticleIllustration:[One image that will end up at the top of the article]

[Illustration]

ArticleBody:[The main part of the article]

Einleitung

Bevor ich mit dem eigentlichen Text anfange, vorab einige Dinge, damit keine Missverst�ndnisse entstehen: IDS steht f�r Intrusion Detection System, im Verlauf des Textes verstehe ich unter IDS auch ein System, das Einbr�che erkennt und Gegenma�nahmen einleitet (wobei das Einleiten von Gegenma�nahmen ein optionales Feature ist). Anfangs werde ich erst einmal eine �bersicht �ber die verschiedenen Arten von IDS geben, um anschlie�end n�her auf verschiedene Taktiken eingehen zu k�nnen. Im letzten Teil werden dann diverse Programme wie Snort, bofh ... und mein eigenes Projekt COLOID besprochen.
Vorab einige Erl�uterungen zu Begriffen, die ich nicht direkt im Text erkl�ren werde :

IDS-�bersicht

Sinn dieses Artikels ist, die verschiedenen Arten von Intrusion Detection Systemen vorzustellen, gleichzeitig auch ihre Vor- und Nachteile. Vorab aber erstmal ein paar einleitende Worte zum Sinn und Zweck von Intrusion Detection Systemen. Ein IDS beobachtet sozusagen die Vorg�nge, die auf dem jeweiligen Rechner oder im jeweiligen Netzwerk vorgehen, anhand von verschiedenen Methoden, die ich hier vorstellen werde, wird versucht herauszufinden, ob die Sicherheit der Rechner bedroht ist (ein "Angriff" vorliegt), um anschlie�end Aktionen dagegen einzuleiten. Da meistens zus�tzlich Log-Files erstellt werden, geh�rt es auch zu einer Hauptaufgabe diese zu analysieren und bei Anzeichen eines Einbruchs oder einem illegalen Versuch eines Users seine Rechte zu erweitern, zu reagieren.
Grunds�tzlich lassen sich folgende drei Arten von Aufgabenbereichen spezifizieren:

Response und Analysis werden sp�ter nochmals genauer behandelt, die verschiedenen Arten der "Information Sources" gleich. Aufgrund der umfassenden M�glichkeiten einen PC oder ein Netzwerk "anzugreifen", gibt es auch verschiedene Arten von IDS (diese lassen sich nat�rlich auch miteinander kombinieren), die sich grunds�tzlich darin unterscheiden, wo sie kontrollieren und was sie kontrollieren (daher Information Sources - Quellen).

Host-Based Intrusion Detection

Host-Based Intrusion Detection Systeme analysieren Informationen auf einem einzelnen Host. Da sie sich normalerweise nicht um den gesamten Netzwerkverkehr k�mmern m�ssen, sondern "lediglich" die Vorg�nge auf dem eigenen PC, k�nnen sie meist pr�zisere Angaben �ber die Art des Angriffs geben. Au�erdem sieht man hier direkt die Auswirkungen auf dem jeweiligen PC, also ob ein bestimmter User erfolgreich einen Angriff gestartet hat. Host-Based IDS benutzen meist zwei verschiedene Arten, Auskunft �ber die Vorg�nge zu geben : System Logs und Operating System Audit Trails. Beide haben ihre Vorteile, so sind Operating System Audit Trails meist exakter, ausf�hrlicher und k�nnen daher besser Auskunft �ber die Vorg�nge geben, w�hrend System Logs meistens nur die allerwichtigsten Informationen liefern und daher wesentlich kleiner sind. System Logs lassen sich aufgrund ihrer Gr��e nat�rlich besser kontrollieren und analysieren, doch wie gesagt, beides hat seine Vor- und Nachteile.

Vorteile:
Nachteile:
Beispiele:

Network Intrusion Detection (NIDS)

Hauptaufgabe eines Network IDS ist das Analysieren und Auswerten der Pakete, die �ber das Netzwerk transferiert werden. Um die Pakete nach "auff�lligem" Inhalt wie z.B. /etc/passwd zu untersuchen, werden Signatures erzeugt, doch darauf wird w�hrend des Textes noch eingegangen. Meist werden sogenannte Sensoren (oft einzelne Hosts) verwendet, die eben nichts anderes machen als den Verkehr zu analysieren und gegebenenfalls Alarm auszul�sen. Da dies ihre einzige Aufgabe ist, besteht die M�glichkeit diese Sensoren besser zu sch�tzen. In diesem Zusammenhang taucht auch �fter der sogenannte "Stealth Mode" auf, also dass die Sensoren praktisch "unsichtbar" agieren, um es dem Angreifer schwieriger zu machen, sie zu lokalisieren oder anzugreifen.

"Stealth mode can be used for network sensors to make the promiscuous mode network interface card (NIC) invisible because it simply doesn't have an IP address in this mode. This is achieved by using a separate NIC in each network sensor machine to communicate with the console over, usually, a physically isolated secure network. Stealth mode makes it more difficult for a hacker to attack the network sensor itself."

Dieser Abschnitt (aus der Beschreibung zu RealSecure entnommen) verdeutlicht nochmals, was es heisst, wenn sich ein Sensor im Stealth Mode befindet. Der Sensor switcht also in den Promiscuous Mode (vereinfacht gesagt, der Modus in dem das Netzwerkger�t den gesamten Verkehr des Netzwerks mitliest) und besitzt keine eigene IP, dadurch soll es dem Angreifer m�glichst schwer gemacht werden, den Sensor zu lokalisieren. Dieser Zustand wird �brigens von Paket-Sniffern wie tcpdump genutzt...

Grunds�tzlich kann man die Sensoren in folgende Bereiche platzieren:

Innerhalb der Firewall (vereinfacht): 
 --------------------------------                        
 |       Internet               |
 --------------------------------        
                 |
                 |
         ----------------------------------
         |             Firewall           |
         ----------------------------------
                         |
                  -------------
                 |   Sensor   |  
                  -------------
                         |
                 -----------------
                 |      LAN      |
                 -----------------
Diese Darstellung ist nur eine m�gliche und soll nur verdeutlichen, dass die Sensoren nicht zwischen DMZ und Firewall stehen. Sollte euch der Begriff DMZ unbekannt sein, er steht f�r Demiltarized Zone und ist ein Bereich, der von allen Seiten gesch�tzt wird.

Wenn die Sensoren innerhalb der Firewall sitzen, ist es f�r sie besser m�glich festzustellen, ob eventuell eine Firewall falsch konfiguriert wurde, au�erdem "erf�hrt" man, ob ein potentieller Angriff durch kam oder nicht. Erfahrungsgem�� erzeugen Sensoren, hier auch weniger False Positives, da sie "unauff�lliger" agieren und deshalb nicht so viel Traffic auf sie zu kommt (womit die Wahrscheinlichkeit eines falschen Alarms sinkt).

Sensoren, die innerhalb der Firewall platziert sind, dienen der Einbruchserkennung, sollen eure Sensoren diesen Zweck erf�llen, solltet ihr sie demnach innerhalb der Firewall platzieren...

Au�erhalb der Firewall (vereinfacht): 
 --------------------------------
 |           Internet           |
 --------------------------------        
                 |                                                                       
   ----------------------------                  
   |          Sensor          |          
   ----------------------------          
                 |                               
   ----------------------------
   |        Firewall          |
   ----------------------------  
                 |
         -----------------
         |      LAN      |
         -----------------
Sensoren werden h�ufig, wie in der Darstellung gezeigt, au�erhalb der externen Firewall platziert. Der Grund hierf�r liegt darin, dass der Sensor so den ganzen Verkehr aus dem Internet empf�ngt und analysieren kann. Wenn man den Sensor hier platziert, ist noch nicht garantiert, dass wirklich alle Angriffe gefiltert und erkannt werden, z.B. bei TCP-Attacken. In diesem Fall w�rde man versuchen, die Attacke zu erkennen, indem man sogenannte Signatures verwendet (mehr dazu siehe in dem Teil �ber Signaturen). Nichtsdestotrotz wird von vielen Experten dieser Standort bevorzugt, da er den Vorteil hat, die Attacken (die auf die Firewall...) ausge�bt werden, zu protokollieren und analysieren, dadurch kann der Admin sehen, wo er eventuell die Konfiguration der Firewall umstellen sollte.

Sensoren, die au�erhalb der Firewall platziert sind, dienen der Angriffserkennung, (Unterschied zur Platzierung innerhalb der Firewall!). Sollen eure Sensoren also die Angriffe erkennen, solltet ihr sie au�erhalb der Firewall platzieren...

- Au�erhalb und innerhalb der Firewall

Nun, diese Variante verbindet die beiden zuvor genannten Varianten. Allerdings ist hier die Gefahr gro�, dass man die Sensoren und/oder die Firewall falsch konfiguriert, d.h. man kann nicht einfach die Vorteile der beiden Varianten zusammenrechnen und dieser Variante hier zuschreiben. Diese M�glichkeiten, die Sensoren zu platzieren, sind nicht die einzigen, man k�nnte sie nat�rlich noch anders platzieren, doch die oben genannten Standorte sind wohl die am h�ufigsten verwendeten.

Vorteile:


Nachteile:


Beispiele:


Obwohl ich hier zwischen HIDS und NIDS unterscheide, wird der Unterschied zwischen beiden ID-Systemen immer geringer, da mittlerweile auch HIDS die Grundfunktionalit�t eines NIDS haben. Bekannte ID-Systeme wie ISS RealSecure bezeichnen sich auch nicht nur als NIDS, sondern als "host-based and network-based IDS". In Zukunft wird der Unterschied zwischen beiden Systemen also immer geringer werden (so dass die beiden Systeme mehr und mehr "zusammenwachsen").

Network Node Intrusion Detection (NNIDS)

Grunds�tzlich arbeitet dieser neue Typ (NNIDS) so wie die typischen NIDS, d.h. man nimmt sich Pakete aus dem Netzwerkverkehr und analysiert diese. Allerdings betrifft das nur Pakete, die an den Network Node adressiert sind (daher der Name). Ein anderer Unterschied zwischen NNIDS und NIDS besteht darin, dass NIDS im Promiscuous Mode laufen, w�hrend NNIDS nicht im Promiscuous Mode laufen. Dadurch, dass l�ngst nicht jedes Paket analysiert wird, wird die Performance des Systems nicht zu sehr darunter leiden, bzw. solche Systeme laufen in der Regel sehr schnell.

Application Based Intrusion Detection

Application Based IDS sind eine Untergruppe der Host-Based IDS, dennoch erw�hne ich sie hier getrennt. Es �berwacht die Interaktion zwischen User und Programm, wobei haupts�chlich zus�tzliche Log-Files erzeugt werden, um Auskunft �ber die Vorg�nge zu geben. Da man direkt zwischen User und Programm operiert, kann man hier sehr leicht auff�lliges Verhalten "rausfiltern". Sinnbildlich k�nnte man sich ABIDS so vorstellen: 
-------------------
|   Application   |
-------------------
          |
-------------------
|        IDS      |
-------------------
          |
-------------------
|        User     |
-------------------

Vorteile:

Nachteile:

Stack Based Intrusion Detection

Auch eine neuere Art der IDS ist das sogenannte Stack Based Intrusion Detection System (SBIDS). Momentan stehen mir allerdings nicht gen�gend Informationen zur Verf�gung, die es mir erm�glichen w�rden, �ber diesen IDS-Typ ausreichend zu informieren.

Honeypot

F�r Honeypots gibt es viele Assoziationen, damit keine Missverst�ndnisse auftauchen, hier eine recht gute Definition aus der SANS Institute's Intrusion Deception FAQ : "Honeypots are programs that simulate one or more network services that you designate on your computer's ports. An attacker assumes you're running vulnerable services that can be used to break into the machine. A honeypot can be used to log access attempts to those ports including the attacker's keystrokes. This could give you advanced warning of a more concerted attack". In manchen F�llen ist ein Honeypot einfach eine "Box". Nach aussen hin erscheint sie ungesch�tzt, dabei protokolliert sie den Verkehr und analysiert ihn auch. Dadurch, dass Honeypots ungesch�tzt erscheinen und "normalerweise" keine Verbindung zu ihnen hergestellt werden sollte, wird jede Verbindung zum Honeypot als verd�chtig erachtet. 
 -------------------------                       
 |      Internet          |
 -------------------------
         |
 -------------------------
 |     ext. Firewall      |
 -------------------------
         |
 -------------------------
 |     Honeypot           |              <---- in DMZ
 -------------------------
         |
 -------------------------
 |     int. Firewall      |
 -------------------------

Das interne Netzwerk muss also nicht offengelegt werden, da ein Honeypot normalerweise in der DMZ (DeMilitarized Zone) platziert wird. Hauptaufgabe eines Honeypots besteht meist darin, den Verkehr zu analysieren, z.B. wann bestimmte Prozesse gestartet wurden, welche Dateien ver�ndert wurden..., so dass man recht gut ein Profil von potentiellen Angreifern erstellen kann.

Doch Honeypot ist nicht gleich Honeypot, so dass man zwischen drei "Varianten" unterscheidet, die auf unterschiedliche Weise die Sicherheit des Systems erh�hen:

Prevention: Verhinderung der Attacke-Detection: Melden, dass eine Attacke vorliegt (m�glichst auch Lokalisierung des Angreifers, was f�r ein Angriff, welche Dienste sind betroffen...?) Reaction: Die (Gegen)reaktion, Detection alleine bringt nichts, wenn man nichts dagegen unternimmt. Padded Cell Systems bieten besondere M�glichkeiten, die Gegenma�nahmen betreffend. Reaction beinhaltet also was man oder das IDS macht, wie man auf einen Angriff reagiert.

Sp�ter werden die verschiedenen Response Options von IDS nochmal gekl�rt... Au�erdem lassen sich Honeypots noch in zwei gr��ere Kategorien einteilen, die Research und die Production Honeypots. Production Honeypots sollen dabei helfen (potentielle) Risiken in einem Netzwerk zu lindern, w�hrenddessen Research Honeypots dem Sammeln und Erfragen von Informationen �ber den/die Angreifer dienen.

Prevention:
Honeypots sind sicherlich nicht die geeignetsten Systeme zur Verhinderung von Angriffen. Wie ihr sp�ter noch bei Padded Cell Systems sehen werdet, kann ein falsch programmierter und konfigurierter Honeypot Angriffe noch erleichtern, wobei dies wohl f�r den gesamten Themenbereich IDS gilt.

Detection:
Hier liegt wohl der gro�e Vorteil von Honeypots, da sie ausgezeichnet sein k�nnen, um Angriffe zu erkennen. Hierbei k�nnen sie vor allem System Logs analysieren und auswerten. Die Platzierung des Honeypots spielt eine entscheidene Rolle, bzw. ein Admin kann nur dann von Honeypots profitieren, wenn sie richtig konfiguriert und platziert sind. Oft werden sie zwischen wichtige Server platziert, um eventuelle Scans auf das gesamte Netzwerk zu erkennen oder in die N�he eines wichtigen Servers, um mit Hilfe von Port Redirection illegalen Zugriff auf den Server feststellen zu k�nnen (z.B. jemand versucht �ber bestimmte Ports auf den Server zuzugreifen, er wird umgeleitet zum Honeypot, da dieser Zugriff nicht gestattet sein sollte, wird eine Warnung ausgegeben.)

Reaction:
Welche M�glichkeiten ein Honeypot hat, auf Ereignisse zu reagieren, seht ihr in dem Teil �ber Responses (weiter unten). Bei der Verwendung/Entwicklung eines Honeypots sollte man darauf achten, dass der Rechner m�glichst attraktiv f�r einen Angreifer scheint, d.h. es sollte nicht schwer sein, den Rechner anzugreifen. Grunds�tzlich sollten nur wenige �nderungen an der Default-Konfiguration gemacht werden, da zu viele �nderungen nur auff�llig wirken k�nnten. Nichtsdestotrotz sollte der eigentliche Sinn nicht vergessen werden, also Kontrollieren des Traffics, Protokollieren der Aktivit�ten, ... Ein Ansatz von dem ich schon �fter geh�rt habe, ist es, den Honeypot in ein eigenes Subnetz hinter eine Firewall zu platzieren. Diese besitzt meist Alarm-F�higkeiten und kann daher auch Warnungen ausgeben. Da die Logs begehrte Ziele der Angreifer sind, sollte man sie nicht auf dem Rechner selbst protokollieren, sondern an einen anderen Server schicken. Manchmal werden auch Sniffer benutzt, um den Verkehr nach bestimmten Zeichen zu durchsuchen und den Verkehr zu "protokollieren". Sollte man genug Informationen gesammelt haben, sollte man die Logs untersuchen und nach Schw�chen des Netzwerks schauen, bzw. diese bereinigen. Durch die F�lle an Informationen sollte es leichter sein, Sicherheitsl�cken zu schlie�en und bei schwereren Angriffen auch gegen den Angreifer vorzugehen. Allerdings muss man auch beachten, dass Honeypots nicht ganz legal sind, bzw. m�sst ihr bei der Verwendung von Honeypots aufpassen. Das Problem besteht darin, dass der Honeypot als "Einladung zum Angriff" aufgefasst werden k�nnte, und wenn man merkt, dass der Rechner angegriffen wurde (und man keine Gegenma�nahmen einleitet), dies zus�tzlich als "grobe Fahrl�ssigkeit" ausgelegt werden k�nnte. Manche gerichtlichen Argumentationen gegen Honeypots klingen schon banal, dennoch solltet ihr euch vorher erkundigen, wie das Gesetz es bei euch sieht. Wird von eurem Netzwerk aus ein anderes Netzwerk angegriffen und dort entsteht Schaden, werdet ihr (wahrscheinlich) daf�r bezahlen m�ssen, aus bereits genannten Gr�nden.
Weitere Recherchen ergaben allerdings, dass der Einsatz von Honeypots in z.B. Europa kein Problem darstellt (solltet ihr einen Paragraphen finden, der dies widerlegt, schreibt mir bitte. Bei meiner Suche habe ich n�mlich keinen solchen Paragraphen gefunden...)

Padded Cell Systems

Diese Systeme arbeiten normalerweise mit einem der anderen, bereits genannten Systeme zusammen. Sollte von dem verwendeten IDS gemeldet werden, dass ein Angriff vorliegt, so wird der entsprechende Angreifer zu einem "padded cell host" weitergeleitet. Sobald sie einmal in diesem Padded Cell Host sind, k�nnen sie keinen Schaden mehr anrichten, da die gesamte Umgebung eine simulierte, eine "Scheinumgebung" ist. Wichtig dabei ist, dass diese Umgebung so realistisch wie m�glich dargestellt werden muss, bzw. der Angreifer muss denken, dass der Angriff erfolgreich war (sozusagen). In diesem Padded Cell Host besteht die M�glichkeit jegliche Aktivit�t des Angreifers zu protokollieren, zu analysieren und mitzuverfolgen. Das Problem bei der Verwendung von Padded Cell Systems ist, dass es u.U. nicht legal ist, es in dem jeweiligen Land einzusetzen (da eventuell entsprechende Gegen-Aktionen des IDS als "Angriff" empfunden werden k�nnten, obwohl sie nur dem Sammeln von Informationen �ber den richtigen Angreifer dienen).

Vorteile:


Nachteile:

Angriffsarten

Bevor man ein IDS entwickelt oder benutzt, sollte man die potentiellen Gefahren spezifieren, also auch welche Angriffe man zu erwarten hat. Trotz der vielen verschiedenen M�glichkeiten lassen sich Angriffe und ihr Ziel dennoch in vier Kategorien einteilen:

1)Confidentiality
Der Angriff hat zur Folge, dass sich die Vertrauensverh�ltnisse gegen�ber dem bestimmten User (meist zu seinen Gunsten ;) ge�ndert haben, also z.B., dass man sich nicht mehr authentifizieren muss gegen�ber einem bestimmten Programm... Solche F�lle werden auch heute noch missbraucht, z.B., wenn zwischen zwei PCs ein "Vertrauensverh�ltnis" besteht, d.h. der User des einen PC kann sich ohne Passworteingabe beim anderen einloggen (oder sonst was). Erreicht ein Angreifer ein vergleichbares Ergebnis mit seinem Angriff, so ist es manchmal sehr schwer solche "missbrauchten" Vertrauensverh�ltnisse aufzudecken.

2)Integrity
Wenn der User wichtige Konfigurations- und Systemdateien ver�ndert, bestehende Binaries durch seine eigenen ersetzt... Oft werden bestehende Binaries... (wie z.B. /bin/login) durch eigene Binaries ersetzt. Dort muss dann der entsprechende User nur ein (im Source) festgelegtes Passwort eingeben und bekommt (meist) root-Rechte. Solche Angriffe dienen also auch der Erweiterung seiner eigenen Rechte, z.B. durch das Einbauen einer Login-Backdoor. Zwar gibt es Tools wie Tripwire, doch l�ngst nicht jeder benutzt es. Au�erdem werden in der Konfiguration und Benutzung oft verheerende Fehler gemacht, die Tripwire in solchen F�llen zu einem weiteren Risiko machen.

3)Availability
Hierdurch wird die Erreichbarkeit des Systems beeintr�chtigt. Dies k�nnte sich �ussern in dem Verbot, dass bestimmte User sich �berhaupt einloggen d�rfen oder dass man sich nur zu bestimmten Zeiten einloggen darf... Ziel ist es meist, dass man selbst "ungest�rt" arbeiten kann und von keinem User entdeckt wird.

4)Control
Z.B. wenn der Angriff der "�bernahme" des Systems gilt, also Kontrolle �ber Dateien, Programme... Hierbei solltet ihr beachten, dass es einem Angreifer nat�rlich auch die anderen drei M�glichkeiten er�ffnet. Sollte er die totale Kontrolle �ber das System haben, kann er ver�ndern, einschr�nken ... wie er will.

Bevor ich nun auf die verschiedenen Angriffsarten (DoS, DDoS, Scans, ...) zu sprechen komme, erstmal ein kleiner Ausflug in die Welt der Integrity Checker. Tools wie Tripwire z�hlen zu den Host-Based IDS, zu der Aufgabe eines Integrity Checkers geh�rt es, die Integrit�t diverser Dateien zu �berpr�fen und gegebenenfalls eine Warnung auszugeben, wenn man �nderungen an einer Datei erkennt. Das Vorgehen bei der Verwendung von Integrity Checkern ist meist das gleiche, daher ist die Beschreibung eines bestimmten Integrity Checkers wohl nicht notwendig...

1) Erstellen einer Datenbank
Der erste Schritt nach der Installation eines Integrity Checkers wie Tripwire ist das Erstellen einer Datenbank. Dieser Schritt sollte (muss) auf jeden Fall zu einem Zeitpunkt vollzogen werden, in dem der Zustand des Systems keinesfalls fragw�rdig ist. Erstellt man eine Datenbank zu einem sp�teren Zeitpunkt (und der Angreifer hat vielleicht schon bestehende Binaries ersetzt), w�rde die Verwendung eines Integrity Checkers den eigentlichen Sinn nicht erf�llen. In einem solchen Fall w�rden die ersetzten Binaries als "Originale" betrachtet werden. Sollte der Admin sp�ter diese Binaries wiederum durch die eigentlichen "Orignale" ersetzen, w�rde ein Alarm ausgel�st... Die meisten Tools bieten umfangreiche M�glichkeiten, die Dateien / Verzeichnisse zu spezifizieren, von denen man eine Hashsumme... erstellen m�chte. Man k�nnte also vereinfacht ausgedr�ckt sagen, dass ein Fingerabdruck vom System angefertigt wird. (Der Modus heisst �brigens bei Tripwire "Database Initialization Mode")

2) Check der Integrit�t
Nachdem der Admin eine Datenbank (bzw. den Fingerabdruck) des Systems hat, kann er zu jeder Zeit sein System erneut �berpr�fen. Mit der erstellten Datenbank als Fundament, ermittelt er erneut die Hashsumme... vergleicht diese mit der Datenbank, und wenn die Werte differenzieren, wird ein Alert ausgegeben. Tripwire bietet hier noch mehr M�glichkeiten, lest daf�r einfach mal die Manpage zu Tripwire oder eine zugeh�rige Dokumentation.

Diese beiden Schritte sind eigentlich beim Umgang mit den meisten Integrity Checkern vorzufinden. Tripwire bietet noch die M�glichkeit, die Datenbank zu aktualisieren (man hat neue Tools installiert...) oder die Policy File zu aktualisieren, das EMail Notification System zu testen...

Welche Fehler kann man nun beim Umgang mit Integrity Checkern machen?

Der erste und mit Abstand gr�bste Fehler, den ein Admin machen kann, ist, eine MD5-Hashsummendatenbank zu erstellen, zu einem Zeitpunkt, in dem bestehende Binaries mit gro�er Wahrscheinlichkeit bereits ersetzt wurden. Geht ein Admin davon aus, dass ein Angriff erfolgreich war und erstellt danach von diesem "kompromittierten" System die Hashsummen-Datenbank, w�rde die vom Angreifer ersetzte Binary (z.B. Login-Backdoor) als "richtige" Binary gelten. Man sollte also m�glichst schnell nach der Installation die Datenbank erstellen. Ein weiterer kapitaler Fehler beim Umgang mit Integrity Checkern (wie z.B. Tripwire) besteht darin, die Hashsummen-Datenbank auf der Festplatte zu lassen. Auf den ersten Blick erscheint es ganz normal, die Datenbank auf der Festplatte gespeichert zu lassen, doch wenn man schon die Datenbank auf der Festplatte l�sst, sollte man zumindest darauf achten, dass die Partition / das Medium read-only ist. Es muss also sicher gestellt werden, dass niemand Schreibzugriff auf unsere Datenbank hat. W�re es dem Angreifer erlaubt, in die Datenbank zu schreiben, k�nnte er diese nach Belieben ver�ndern. Solltet ihr bereits mit Tripwire gearbeitet haben, wisst ihr sicherlich auch, dass man per Konfigurationsdatei einstellen kann, von welchen Dateien die Integrit�t �berpr�ft werden soll. Doch was, wenn der Angreifer diese Konfigurationsdatei lesen/beschreiben kann? Er k�nnte die "Suchpfade" �ndern, so dass das Verzeichnis mit den ge�nderten Binaries gar nicht erst durchgescant wird. Am besten lasst ihr also die Konfiguration auch nicht auf der Platte und packt sie wiederum auf ein read-only Medium. Einigen wird es umst�ndlich erscheinen, die Dateien auf ein read-only Medium zu setzen, allerdings m�sst ihr wohl hier etwas mehr Zeitaufwand in Kauf nehmen, zu Gunsten h�herer Sicherheit (ein interessanter Aspekt bei Benutzerfreundlichkeit ist ja, dass viele Sicherheitsl�cken erst dadurch er�ffnet werden/wurden, weil man Programme benutzerfreundlich gestalten wollte. In unserem Fall heisst das also, dass man etwas an Benutzerfreundlichkeit einspart, allerdings einen h�heren Sicherheitsstandard besitzt). Tripwire (und andere Integrity Checker) sind sicherlich leistungsf�hige Programme, die die Sicherheit erh�hen k�nnen und es potentiellen Angreifern schwerer machen k�nnen, erfolgreich anzugreifen, doch bringt das beste Tool nichts, wenn die sonstigen Sicherheitseinstellungen des Systems nicht stimmen. Verlangt also nicht von Integrity Checkern, dass sie euch die gesamte Arbeit abnehmen, k�mmert euch selbst zus�tzlich um die Sicherheit eurer Kiste...

Eine neuere Form der Integrity Checker sind die sogenannten Realtime Integrity Checker. Im Gegensatz zu den "normalen" Integrity Checkern �berpr�fen sie Realtime die Integrit�t der Datei. Hier ein kurzes Schema:

1) Der erste Schritt ist auch hier das Erstellen einer Hashsummen-Datenbank
2) Bevor jemand ein Programm ausf�hren kann, wird die Hashsumme der Datei ermittelt. Wenn der Wert mit dem in der Datenbank nicht �bereinstimmt, wurde die Binary ersetzt. Liegt ein solcher Fall vor, wird die Ausf�hrung verhindert
Dieses Konzept ist nur ein m�gliches Konzept f�r Realtime Integrity Checker (zumindest habe ich mir dieses Konzept mal so aufgestellt). Im Unterschied zu Integrity Checkern, verl�sst man sich also nicht darauf, dass der Admin regelm��ig die Dateien �berpr�ft, es wird also versucht die Korrektheit der Binary vor Ausf�hrung zu �berpr�fen, um gegebenenfalls die Binary gar nicht erst auszuf�hren...

Neben den eben aufgef�hrten Kategorien (Integrity, Control, ...) lassen sich die Angriffe nat�rlich auch anders aufteilen, z.B. wie angegriffen wird, bzw. mit welchen Mitteln. Auch hier gibt es nat�rlich viele M�glichkeiten, doch die h�ufigsten Attacken gegen�ber IDS sind wohl:

- Scans
Heutzutage geh�ren Scans zu allt�glichen "Attacken", das Problem hierbei besteht darin, dass das IDS nicht zu viele False Positives erzeugen sollte. Meistens dienen Scans dem Einholen von (weiteren) Informationen �ber einen Host / ein Netzwerk (z.B. um anschlie�end weitere Attacken zu starten). Welche Informationen ein Angreifer �ber das eigene Netzwerk einholen kann, sieht man beispielweise am folgenden Scan-Ergebnis (nmap - nur ein kleines Beispiel, zeigt noch l�ngst nicht alle M�glichkeiten von nmap): 
 ...
 Host (192.168.0.0) seems to be a subnet broadcast address (returned 1
 extra pings).
 Skipping host. Interesting ports on playground.yuma.net 192.168.0.1):
 Port           State           Protocol                Service
 22             open            tcp             ssh
 111            open            tcp             sunrpc
 635            open            tcp             unknown
 1024           open            tcp             unknown
 2049           open            tcp             nfs

 TCP Sequence Prediction: Class = random positive increments
                             Difficulty=3916950 (Good luck!)
 Remote operating system guess: 
        Linux 2.1.122 - 2.1.132; 2.2.0-pre1 - 2.2.2

 Interesting ports on vectra.yuma.net (192.168.0.5):
 Port           State           Protocol                Service
 13             open            tcp             daytime
 21             open            tcp             ftp
 22             open            tcp             ssh
 23             open            tcp             telnet
 37             open            tcp             time
 79             open            tcp             finger
 111            open            tcp             sunrpc
 113            open            tcp             auth
 513            open            tcp             login
 514            open            tcp             shell

 TCP Sequence Prediction: Class = random positive increments
                             Difficulty = 17719 (Worthy challenge)
 Remote operating system guess: OpenBSD 2.2. - 2.3

 Nmap run completed -- 256 IP addresses (2 hosts up) scanned in 6 seconds
Haupts�chlich kann man vor allem also folgendes herausfinden: Viele der verschiedensten Scan-Techniken f�hren zusammen zu einer Masse von Informationen, durch die es dem Angreifer m�glich gemacht wird, seinen Angriff einzuleiten. Zwar werde ich jetzt hier nicht alle Scan-Techniken beschreiben/erw�hnen, allerdings werden einige h�ufig benutzte schon genannt (bei Fragen zu den Protokollen... guckt einfach mal in die entsprechenden RFC):

Ping Scanning:
Ping Scans werden dazu verwendet, um herauszufinden, welche Hosts online sind. Daf�r schickt man dem entsprechenden Host (oder den Hosts) ein ICMP Datagramm vom Typ 8 (also Echo Request) und erwartet ein ICMP-Antwort-Datagramm vom Typ 0 (also Echo Reply). Manchmal wird allerdings nicht nur ein Echo Request geschickt, sondern zus�tzlich noch ein ACK, da ICMP manchmal gesperrt wird. Wird ein RST zur�ckgesendet, ist der Host online.

Nmap Parameter: -sP

TCP Scanning (Vanilla) :
Beim TCP Scanning wird (meist) auf alle Ports versucht ein connect() anzuwenden, nachdem der Three-Way-Handshake durchlaufen wurde, also eine Verbindung zu den Ports aufgestellt wurde (bzw. die Verbindung mit den Ports verlief erfolgreich), wird der R�ckgabewert von connect() �berpr�ft. Der R�ckgabewert gibt dem Angreifer hierbei Auskunft dar�ber, ob der verwendete Port (oder die Ports) offen oder geschlossen sind. Ziel eines TCP Scans ist es also herauszufinden, ob Ports offen/geschlossen sind.

Nmap Parameter: -sT

Die folgenden Nmap-Outputs sind von einem meiner Rechner direkt nach einer Standardinstallation durchgef�hrt worden. Ich habe absichtlich keine �nderungen (an der Konfiguration) vorgenommen: 
 [Socma]$ nmap -sT localhost
 
Starting nmap V. 2.54BETA36 ( www.insecure.org/nmap/ )
Interesting ports on Diablo (127.0.0.1):
(The 1552 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp                     
23/tcp     open        telnet                  
80/tcp     open        http                    
111/tcp    open        sunrpc                  
113/tcp    open        auth                    
6000/tcp   open        X11                     

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second

Ein Ausschnitt eines Tcpdump-Traces (dieses Scans): 
 02:10:15.804704 Diablo > Diablo: icmp: echo request
                         4500 001c 2db8 0000 3501 5a27 7f00 0001
                         7f00 0001 0800 fc95 fb69 0000
 02:10:15.814704 Diablo > Diablo: icmp: echo reply (DF)
                         4500 001c 0000 4000 ff01 7dde 7f00 0001
                         7f00 0001 0000 0496 fb69 0000
 02:10:15.814704 Diablo.58725 > Diablo.http: . ack 110306597 win 3072
                         4500 0028 d223 0000 2a06 c0aa 7f00 0001
                         7f00 0001 e565 0050 ad48 0003 0693 2525
                         5010 0c00 e718 0000
 02:10:15.814704 Diablo.http > Diablo.58725: R 110306597:110306597(0) 
         win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 0050 e565 0693 2525 0000 0000
                         5004 0000 a070 0000
 02:10:16.114704 Diablo.1727 > Diablo.821: S 196002918:196002918(0) 
 win 32767 <mss 16396,sackOK,timestamp 213509[|tcp]> (DF)
                         4500 003c 8663 4000 4006 b656 7f00 0001
                         7f00 0001 06bf 0335 0bae c466 0000 0000
                         a002 7fff 739c 0000 0204 400c 0402 080a
                         0003 4205
 02:10:16.114704 Diablo.821 > Diablo.1727: R 0:0(0) ack 196002919 
        win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 0335 06bf 0000 0000 0bae c467
                         5014 0000 d7c4 0000
 02:10:16.114704 Diablo.1728 > Diablo.440: S 195504823:195504823(0) 
 win 32767 <mss 16396,sackOK,timestamp 213509[|tcp]> (DF)
                         4500 003c 68b2 4000 4006 d407 7f00 0001
                         7f00 0001 06c0 01b8 0ba7 2ab7 0000 0000
                         a002 7fff 0ecf 0000 0204 400c 0402 080a
                         0003 4205

UDP Scanning:
Sinn und Zweck von UDP Scans sind �hnlich dem von TCP Scans, man will offene UDP Ports finden. Ein Scan l�uft hier allerdings anders ab, da UDP ein verbindungsloses Protokoll ist (und TCP ein verbindungsorientiertes). Beim UDP Scanning wird ICMP "ausgenutzt", schickt man nun an die jeweiligen Ports 0 Byte UDP Packete, um dann auf die "Antwort" von ICMP zu warten. Wenn gemeldet wird, dass der Port nicht erreichbar ist (oder wie es richtig heisst "Port Unreachable" / Code-Wert 3), bedeutet dies, dass der Port geschlossen ist. Sollte der jeweilige Admin..., z.B. in seiner /etc/inetd.conf bestimmte Dienste deaktiviert haben und man versucht auf den entsprechenden Port ein Paket zu schicken, so h�tte dies die Fehlermeldung "Port Unreachable" zur Folge...

Nmap Parameter: -sU 

 [Socma]$ nmap -sU localhost

Starting nmap V. 2.54BETA36 ( www.insecure.org/nmap/ )
Interesting ports on Diablo (127.0.0.1):
(The 1459 ports scanned but not shown below are in state: closed)
Port       State       Service
111/udp    open        sunrpc                  

Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds

Der zugeh�rige Tcpdump-Trace: 
10:41:55.954397 Diablo > Diablo: icmp: echo request
                         4500 001c cc8f 0000 2801 c84f 7f00 0001
                         7f00 0001 0800 8471 738e 0000
10:41:55.954397 Diablo > Diablo: icmp: echo reply (DF)
                         4500 001c 0000 4000 ff01 7dde 7f00 0001
                         7f00 0001 0000 8c71 738e 0000
10:41:55.964397 Diablo.63793 > Diablo.http: . ack 994287972 win 2048
                         4500 0028 79e3 0000 2506 1deb 7f00 0001
                         7f00 0001 f931 0050 06d8 0003 3b43 a164
                         5010 0800 cccd 0000
10:41:55.964397 Diablo.http > Diablo.63793: R 994287972:994287972(0) 
     win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 0050 f931 3b43 a164 0000 0000
                         5004 0000 dbb4 0000
10:41:56.274397 Diablo.63773 > Diablo.15: udp 0
                         4500 001c 8a0b 0000 3011 02c4 7f00 0001
                         7f00 0001 f91d 000f 0008 08af
10:41:56.274397 Diablo > Diablo: icmp: Diablo udp port 15 
     unreachable (DF) [tos 0xc0] 
                         45c0 0038 0000 4000 ff01 7d02 7f00 0001
                         7f00 0001 0303 fb18 0000 0000 4500 001c
                         8a0b 0000 3011 02c4 7f00 0001 7f00 0001
                         f91d 000f
10:41:56.274397 Diablo.63773 > Diablo.1459: udp 0
                         4500 001c 6c2f 0000 3011 20a0 7f00 0001
                         7f00 0001 f91d 05b3 0008 030b
10:41:56.274397 Diablo > Diablo: icmp: Diablo udp port 1459 
     unreachable (DF) [tos 0xc0] 
                         45c0 0038 0100 4000 ff01 7c02 7f00 0001
                         7f00 0001 0303 fb18 0000 0000 4500 001c
                         6c2f 0000 3011 20a0 7f00 0001 7f00 0001
                         f91d 05b3
Eine etwas andere Variante eines UDP Scans (UDP recvfrom() and write() Scan) besteht darin, jeden Port zweimal zu scannen. Die eben besprochene Methode benutzt ICMP mit "Port Unreachable", allerdings erh�lt nur root diese Meldung. Scant man zwei mal einen geschlossenen Port erh�lt man nach dem zweiten Scan ein "Error 13 : Try Again"...

ACK Scanning:
Durch Senden eines ACK-Pakets an Ports an die Firewall wird herausgefunden, welche Ports gefiltert werden und welche nicht gefiltert werden. Erh�lt man ein RST zur�ck, bedeutet es, dass der entsprechende Port "ungesch�tzt" ist, bzw. nicht gefiltert wird, ansonsten bekommt man eine ICMP Error Message zur�ck. Zwar wird nicht direkt herausgefunden, welche Ports offen sind, allerdings gewinnt man so genauere Informationen �ber die Firewall (und deren Einstellungen).

Nmap Parameter : -sA 

 [Socma]$ nmap -sA localhost

Starting nmap V. 2.54BETA36 ( www.insecure.org/nmap/ )
All 1558 scanned ports on Diablo (127.0.0.1) are: UNfiltered

Nmap run completed -- 1 IP address (1 host up) scanned in 6 seconds

 Der Tcpdump-Trace:

10:45:51.864397 Diablo > Diablo: icmp: echo request
                         4500 001c 1617 0000 3901 6dc8 7f00 0001
                         7f00 0001 0800 113d e6c2 0000
10:45:51.864397 Diablo > Diablo: icmp: echo reply (DF)
                         4500 001c 0000 4000 ff01 7dde 7f00 0001
                         7f00 0001 0000 193d e6c2 0000
10:45:51.864397 Diablo.53119 > Diablo.http: . ack 2682022466 win 3072
                         4500 0028 0dda 0000 3206 7cf4 7f00 0001
                         7f00 0001 cf7f 0050 0650 0003 9fdc 6a42
                         5010 0c00 c590 0000
10:45:51.864397 Diablo.http > Diablo.53119: R 2682022466:2682022466(0) 
     win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 0050 cf7f 9fdc 6a42 0000 0000
                         5004 0000 d7ef 0000
10:45:52.164397 Diablo.53099 > Diablo.14: . ack 2457451592 win 3072
                         4500 0028 218d 0000 3206 6941 7f00 0001
                         7f00 0001 cf6b 000e 5938 4710 9279 bc48
                         5010 0c00 e74d 0000
10:45:52.164397 Diablo.14 > Diablo.53099: R 2457451592:2457451592(0) 
     win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 000e cf6b 9279 bc48 0000 0000
                         5004 0000 93a2 0000
10:45:52.164397 Diablo.53099 > Diablo.imap3: . ack 2457451592 win 3072
                         4500 0028 a075 0000 3206 ea58 7f00 0001
                         7f00 0001 cf6b 00dc 5938 4710 9279 bc48
                         5010 0c00 e67f 0000

Stealth Scanning (NULL, XMAS, FIN, SYN, ...): Beim Stealth Scanning wird u.a. der Three-Way-Handshake "missbraucht". Zwar ist es eigentlich Vorraussetzung zu wissen, wie dieser abl�uft, da man Stealth Scans aber besser daran erkl�ren kann, f�hre ich hier noch mal kurz den Three-Way-Handshake vor: 
------------------      SYN                       -------------
| Rechner A      | ---------------------------- > | Rechner B |
------------------                                -------------

------------------              ACK/SYN         -------------
| Rechner A      | <----------------------------| Rechner B |
------------------                              -------------

------------------              ACK               -------------
| Rechner A      | ---------------------------- > | Rechner B |
------------------                                -------------

Das Problem der TCP-Scans ist, dass sie recht auff�llig sind (da jedesmal der Three-Way-Handshake durchlaufen wird). Beim Stealth Scanning passiert stattdessen folgendes: 
------------------      SYN                       -------------
| Rechner A      | ---------------------------- > | Rechner B |
------------------                                -------------

------------------              ACK/SYN         -------------
| Rechner A      | <----------------------------| Rechner B |
------------------                              -------------
Diese Darstellung sieht zwar so aus wie beim Three-Way-Handshake, allerdings mit einem wesentlichen Unterschied: In der hier gezeigten Darstellung w�rde keine Verbindung zwischen A und B bestehen, bzw. Rechner B w�rde denken, die Verbindung w�rde stehen, obwohl die Verbindung erst dann steht, wenn A ein weiteres ACK an B schickt (man spricht hier auch von einem "half-open" Port). Der oben gezeigte SYN Scan impliziert, dass der Port auf dem Zielrechner offen ist (aufgrund des ACK/SYN), w�re er geschlossen, so w�rde man ein RST/ACK zur�ckerhalten.

Nmap Parameter : -sS 

 [Socma]$ nmap -sS localhost

Starting nmap V. 2.54BETA36 ( www.insecure.org/nmap/ )
Interesting ports on Diablo (127.0.0.1):
(The 1552 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp                     
23/tcp     open        telnet                  
80/tcp     open        http                    
111/tcp    open        sunrpc                  
113/tcp    open        auth                    
6000/tcp   open        X11                     

Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds

Tcpdump-Trace:

10:47:41.674397 Diablo > Diablo: icmp: echo request
                         4500 001c 8f08 0000 3501 f8d6 7f00 0001
                         7f00 0001 0800 99a9 5e56 0000
10:47:41.674397 Diablo > Diablo: icmp: echo reply (DF)
                         4500 001c 0000 4000 ff01 7dde 7f00 0001
                         7f00 0001 0000 a1a9 5e56 0000
10:47:41.674397 Diablo.58038 > Diablo.http: . ack 1561498752 win 3072
                         4500 0028 afe5 0000 3206 dae8 7f00 0001
                         7f00 0001 e2b6 0050 82b0 0003 5d12 9480
                         5010 0c00 4e85 0000
10:47:41.674397 Diablo.http > Diablo.58038: R 1561498752:1561498752(0) 
     win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 0050 e2b6 5d12 9480 0000 0000
                         5004 0000 dd44 0000
10:47:41.984397 Diablo.58018 > Diablo.1488: S 2803535203:2803535203(0) 
     win 3072
                         4500 0028 a4f5 0000 3206 e5d8 7f00 0001
                         7f00 0001 e2a2 05d0 a71a 8d63 0000 0000
                         5002 0c00 88ef 0000
10:47:41.984397 Diablo.1488 > Diablo.58018: R 0:0(0) ack 2803535204 
     win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 05d0 e2a2 0000 0000 a71a 8d64
                         5014 0000 94dc 0000
Nun kommen weitere Scans ins Spiel: FIN Scanning, NULL Scanning und XMAS Scanning. Beim FIN Scanning wird lediglich dem "Ziel-Rechner" eine FIN-Message geschickt, obwohl keine Verbindung zwischen beiden besteht. Bei einem geschlossenen Port wird nun RST zur�ckgegeben, ansonsten passiert nichts.

Nmap Parameter : -sF 

 [Socma]$ nmap -sF localhost

Starting nmap V. 2.54BETA36 ( www.insecure.org/nmap/ )
Interesting ports on Diablo (127.0.0.1):
(The 1552 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp                     
23/tcp     open        telnet                  
80/tcp     open        http                    
111/tcp    open        sunrpc                  
113/tcp    open        auth                    
6000/tcp   open        X11                     

Nmap run completed -- 1 IP address (1 host up) scanned in 6 seconds

Tcpdump-Trace:

10:48:28.704397 Diablo > Diablo: icmp: echo request
                         4500 001c b29d 0000 3401 d641 7f00 0001
                         7f00 0001 0800 a1a7 5658 0000
10:48:28.704397 Diablo > Diablo: icmp: echo reply (DF)
                         4500 001c 0000 4000 ff01 7dde 7f00 0001
                         7f00 0001 0000 a9a7 5658 0000
10:48:28.704397 Diablo.52201 > Diablo.http: . ack 2873378189 win 4096
                         4500 0028 cbeb 0000 2b06 c5e2 7f00 0001
                         7f00 0001 cbe9 0050 9020 0003 ab44 458d
                         5010 1000 54a3 0000
10:48:28.704397 Diablo.http > Diablo.52201: R 2873378189:2873378189(0) 
     win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 0050 cbe9 ab44 458d 0000 0000
                         5004 0000 f4d2 0000
10:48:29.004397 Diablo.52181 > Diablo.233: F 0:0(0) win 4096
                         4500 0028 10c6 0000 2b06 8108 7f00 0001
                         7f00 0001 cbd5 00e9 0000 0000 0000 0000
                         5001 1000 d522 0000
10:48:29.004397 Diablo.233 > Diablo.52181: R 0:0(0) ack 1 win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 00e9 cbd5 0000 0000 0000 0001
                         5014 0000 e50e 0000
Besonders interessant (vor allem bei der praktischen Umsetzung einer Protocol Anomaly Detection) sind die NULL und Xmas Scans. Der Xmas Scan tr�gt seinen Namen, aufgrund der Tatsache das dort alle Flags gesetzt sind, also: SYN, ACK, FIN, URG, PUSH. Wie beim FIN Scanning wird auch hier RST zur�ckgegeben, wenn der Port geschlossen ist.

Nmap Parameter : -sX 

 [Socma]$ nmap -sX localhost

Starting nmap V. 2.54BETA36 ( www.insecure.org/nmap/ )
Interesting ports on Diablo (127.0.0.1):
(The 1552 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp                     
23/tcp     open        telnet                  
80/tcp     open        http                    
111/tcp    open        sunrpc                  
113/tcp    open        auth                    
6000/tcp   open        X11                     

Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds

Tcpdump-Trace:

10:44:24.004397 Diablo > Diablo: icmp: echo request
                         4500 001c ffcc 0000 2a01 9312 7f00 0001
                         7f00 0001 0800 103d e7c2 0000
10:44:24.004397 Diablo > Diablo: icmp: echo reply (DF)
                         4500 001c 0000 4000 ff01 7dde 7f00 0001
                         7f00 0001 0000 183d e7c2 0000
10:44:24.004397 Diablo.36398 > Diablo.http: . ack 718216305 win 2048
                         4500 0028 2e28 0000 2906 65a6 7f00 0001
                         7f00 0001 8e2e 0050 9220 0003 2acf 1c71
                         5010 0800 41f0 0000
10:44:24.004397 Diablo.http > Diablo.36398: R 718216305:718216305(0) 
     win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 0050 8e2e 2acf 1c71 0000 0000
                         5004 0000 dc1f 0000
10:44:24.304397 Diablo.36378 > Diablo.1996: FP 0:0(0) win 2048 urg 0
                         4500 0028 7651 0000 2906 1d7d 7f00 0001
                         7f00 0001 8e1a 07cc 0000 0000 0000 0000
                         5029 0800 13d3 0000
10:44:24.304397 Diablo.1996 > Diablo.36378: R 0:0(0) ack 1 win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 07cc 8e1a 0000 0000 0000 0001
                         5014 0000 1be7 0000
Die andere M�glichkeit, der NULL Scan, bedeutet, dass kein Flag gesetzt ist. Sollte der Port geschlossen sein, wird wiederum RST zur�ckgesendet.

Nmap Parameter : -sN 

 [Socma]$ nmap -sN localhost

Starting nmap V. 2.54BETA36 ( www.insecure.org/nmap/ )
Interesting ports on Diablo (127.0.0.1):
(The 1552 ports scanned but not shown below are in state: closed)
Port       State       Service
21/tcp     open        ftp                     
23/tcp     open        telnet                  
80/tcp     open        http                    
111/tcp    open        sunrpc                  
113/tcp    open        auth                    
6000/tcp   open        X11                     

Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds

Tcpdump-Trace:

10:43:37.594397 Diablo > Diablo: icmp: echo request
                         4500 001c 2ecf 0000 2c01 6210 7f00 0001
                         7f00 0001 0800 8f87 6878 0000
10:43:37.594397 Diablo > Diablo: icmp: echo reply (DF)
                         4500 001c 0000 4000 ff01 7dde 7f00 0001
                         7f00 0001 0000 9787 6878 0000
10:43:37.604397 Diablo.34607 > Diablo.http: . ack 1932747046 win 4096
                         4500 0028 ee0f 0000 3706 97be 7f00 0001
                         7f00 0001 872f 0050 5b20 0003 7333 6126
                         5010 1000 ead5 0000
10:43:37.604397 Diablo.http > Diablo.34607: R 1932747046:1932747046(0) 
     win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 0050 872f 7333 6126 0000 0000
                         5004 0000 5605 0000
10:43:37.904397 Diablo.34587 > Diablo.408: . win 4096
                         4500 0028 e3bb 0000 3706 a212 7f00 0001
                         7f00 0001 871b 0198 0000 0000 0000 0000
                         5000 1000 192f 0000
10:43:37.904397 Diablo.408 > Diablo.34587: R 0:0(0) ack 0 win 0 (DF)
                         4500 0028 0000 4000 ff06 7dcd 7f00 0001
                         7f00 0001 0198 871b 0000 0000 0000 0000
                         5014 0000 291b 0000
Man ben�tigt also nicht den kompletten Three-Way-Handshake, dadurch ist Stealth Scanning (wie schon gesagt) "unauff�lliger" als TCP Scanning. IDS sollten auf jeden Fall in der Lage sein, diese Anormalit�ten (Xmas und NULL) zu erkennen...

FTP Bounce:
In manchen FTPD kann das PORT Kommando dazu missbraucht werden, eine beliebige Verbindung vom Ftp Server zu einer anderen Maschine herzustellen. Doch erst einmal ein kleiner �berblick, wie das ganze "normalerweise" abl�uft. Zuerst stellt der Client eine Verbindung zum Ftp Server (Port 21) her, der FTP Server "erstellt" eine zweite Verbindung zur�ck zum Client (damit er auch Daten zur�cksenden kann). F�r diese zweite Verbindung wird das PORT-Kommando verwendet. Das interessante hieran ist, dass das Kommando sowohl IP als auch Port (den es zu �ffnen gilt) des Client enth�lt. Anschlie�end stellt der Server eine Verbindung her, wobei der Source Port 20 und der Destination Port, der Port ist, der bei PORT spezifiziert wurde. Der Angriffspunkt ist nun das PORT-Kommando, bei dem man die IP und den Port des (angeblichen) Client manipulieren kann, um eben eine Verbindung zum Opfer herzustellen, anstatt zu unserem PC. Nachdem also IP und Port manipuliert wurden, kann der eigentliche Verkehr durch "list" oder "get" initialisiert werden. Jetzt �berpr�ft man die Antwort von FTP, denn wenn wir ein "425: Can't build data connection: Connection refused" erhalten, ist der spezifierte Port geschlossen. Erhalten wir hingegen ein "150 : File status okay about to open data connection" oder "226: Closing data connection. Requested file action successful (for example, file transfer or file abort)" als Antwort, wissen wir, dass der spezifizierte Port offen ist.

Nmap Parameter: -b

Fragmented Packets: Bei diesem "Verfahren" wird die Fragmentierung eines IP-Pakets durch TCP "ausgenutzt". Normalerweise kommt es zur Fragmentierung, wenn die Datagramme gr��er als die verarbeitbare Gr��e sind, diese Gr��enbeschr�nkung wird MTU (Maximum Transmission Unit) genannt. Die fragmentierten Datagramme werden am Ende des Knotens wieder zusammengesetzt. Dieses Verhalten kann aber auch ausgenutzt werden. Nicht jede IDS/Firewall... kommt mit der Fragmentierung klar, d.h. bei fragmentierten Paketen kommt es schon mal zu Fehlern. Anstatt nun unser Paket ganz normal zu verschicken, unterteilen wir es (in Fragmente). Diese beinhalten dann die "gew�hnlichen" Daten wie Source IP, Destination IP, Source Port... Nun kann es sein, dass die angesprungene Firewall/IDS Probleme bei der Zusammensetzung der Fragmente hat. Diese Probleme k�nnen sich auf verschiedenste Art und Weise �ussern, entweder f�hrt es zu einem Absturz des ganzen Systems, oder das Paket ist durch. Unser Paket k�nnte m�glicherweise durchkommen, da die Zusammensetzung fehlerhaft war und das Paket f�lschlicherweise als "harmlos" spezifiert wurde. Manchmal werden auch nicht alle Fragmente richtig kontrolliert, d.h. es wird nur ein bestimmtes Fragment kontrolliert, so dass unser Paket wiederum durchkommen w�rde. Durch diese Technik kann man also unauff�lliger scannen, da der Verkehr als "harmlos" bewertet werden k�nnte und somit gar nicht erst ein Alarm entsteht. Andererseits beruht diese Theorie darauf, dass die IDS (Firewall) Probleme bei der Bearbeitung und der Zusammensetzung der Fragmente hat.

Reverse Ident Scanning:
Erst einmal ein Ausschnitt aus RFC1413 - dem RFC zum Identifcation Protocol: "The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident Protocol") provides a means to determine the identity of a user of a particular TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system." Beim Reverse Ident Scanning nutzt man identd also aus, um den Eigent�mer des laufenden Prozesses zu "erfragen". Diese Technik dient vor allem dem Auffinden von Daemons die als root laufen, um sp�ter genau diese Daemons angreifen zu k�nnen. Dumb Scanning: Voraussetzung zum Dumb Scanning ist der sogenannte 
 ----------                --------------             ----------               
 | YOU    | <------------> | Dumb Host  | <---------->| TARGET |              
 ----------                --------------             ----------
Hierbei gilt, dass der Dumb Host m�glichst wenig Traffic haben sollte, warum, wird am Ende sicherlich deutlicher. Nur wie wird jetzt der Dumb Host genutzt, bzw. warum brauchen wir �berhaupt einen? Ok, diese Frage f�hrt zur eigentlichen Attacke und somit auch der Erkl�rung, warum ein Dumb Host notwendig ist. Damit man sp�ter herausfinden kann, ob bei TARGET ein Port offen oder geschlossen ist, muss man das IP ID-Feld des Dumb Hosts untersuchen. Daf�r wird dem Dumb Host erst einmal ein Paket zugesendet (Echo Request), anhand seines Replys kann man das ID-Feld, bzw. den Wert, den das ID-Feld hat, auslesen. Anschlie�end kann man TARGET ein Paket schicken, wobei die Source Address die vom Dumb Host ist. Die Antwort von TARGET erh�lt daraufhin unser Dumb Host. Sollte er SYN/ACK von TARGET erhalten, so bedeutet das, dass der Port offen ist. Als Antwort wird unser Dumb Host dann ein Paket zur�ckschicken, in dem RST gesetzt ist. Sollte der Dumb Host allerdings ein RST/ACK von der Target Machine erhalten, schickt er keine Antwort mehr an TARGET. Um nun herausfinden zu k�nnen, welche Antwort der Dumb Host vom TARGET bekam, schicken wir dem Dumb Host nochmals ein Ping. Wenn der Port des Targets offen war und somit ein RST zur�ckgesendet wurde, wird auch das IP ID-Feld des Dumb Hosts inkrementiert, bei geschlossenem Port passiert nichts. Durch Auslesen des neuen IP ID-Wertes des Dumb Host kann man also erkennen, ob die Ports offen oder geschlossen waren. Nun ist hoffentlich auch klarer, warum wir einen Dumb Host verwenden, also einen Host mit m�glichst wenig Traffic. Wenn zuviel Traffic auf dem Host herrscht, w�re es schwieriger zu spezifizieren, welche Ports offen sind (bei TARGET), die Wahrscheinlichkeit, dass man sich vertun w�rde, w�re bei gr��erem Traffic nat�rlich dadurch auch h�her.

Fingerprint OS Detection:
Die Fingerprint OS Detection hat zum Ziel, das (auf dem Server...) verwendete Betriebssystem zu erkennen. Die meisten neueren Scanner liefern hier nicht nur z.B. "Linux" oder "Solaris" als Antwort, sondern eine genauere Spezifizierung der Versionen (des jeweiligen Betriebssystems). Hierf�r wird ein "Fingerabdruck" (Profil) des Betriebssystems erstellt. Heutzutage kann man eigentlich den Bannern von Telnet, Ftp (siehe oben)... nicht mehr wirklich trauen, da man diese auch �ndern/manipulieren kann. Wenn der Angreifer die genaue Version des anzugreifenden Rechners erf�hrt, kann er darauf aufbauend entsprechende Skripts, Exploits, ... heraussuchen und mit seinem Angriff fortfahren. Diese Technik nutzt aus, dass sich die Betriebssysteme in (den manchmal kleinsten) Dingen unterscheiden (welch Erkenntnis ;). Da es zahlreiche Dokumente zu dieser Technik gibt, werde ich mich hier kurzfassen und nur die wichtigsten Test-M�glickeiten kurz erl�utern:

- FIN Test: Wenn ein Rechner ein FIN-Paket an einem offenen Port empf�ngt, sollte er eigentlich nicht antworten (gem�� RFC793), allerdings gibt es dort auch Ausnahmen, z.B. bei MS Windows, BSDI, CISCO, MPS, ... die ein RESET als Antwort schicken.

- ACK-Sequenznummern: Beim Senden eines FIN|PSH|URG an einen geschlossenen TCP-Port wird meistens die Sequenznummer des ACK-Pakets auf die eigene Sequenznummer gesetzt. Doch auch hier muss Windows mal wieder eine Ausnahme bilden ;) Windows gibt n�mlich die eigene Sequenznummer + 1 zur�ck...

- BOGUS Flag Test: Wird ein undefiniertes TCP Flag im TCP Header verwendet (in einem SYN-Paket), �bernehmen Linux Rechner < 2.0.35 diese Flageinstellungen. Andere OS resetten beim Erhalten eines SYN+BOGUS-Pakets...

- TCP Initial Window: Die meisten Betriebssysteme verwenden (nahezu) konstante Fenstergr�ssen (der Reply-Pakete). Z.B. AIX liefert 0x3F25, MS NT5, OpenBSD und FreeBSD verwenden 0x402E...

- Don't Fragment Bit Test: Einige Betriebssysteme unterscheiden sich darin, dass (oder ob) sie dieses Bit in einigen Paketen setzen oder nicht. Dadurch l�sst sich hierdurch zus�tzlich differenzieren, welches OS vorliegt...

-TCP Options Test: Die Grundlage dieses Tests ist recht einfach erkl�rt: Man sendet eine Anfrage an den entsprechenden Rechner, setzt diverse Optionen und guckt in seiner Antwort, ob dort auch die Optionen gesetzt sind. Die in der Antwort enthaltenen Optionen werden unterst�tzt... Je nach Betriebssystem (und Version) werden bestimmte Optionen grunds�tzlich nicht unterst�tzt, manche schon. Dadurch l�sst sich das verwendete Betriebssystem zus�tzlich (exakter) bestimmen.

Nmap Parameter : -O

Insgesamt gibt es noch viele nicht besprochene Tests, doch gibt es im Netz gen�gend Texte �ber Fingerprint OS Detection. Fyodor (NMAP) hat ein Paper dazu geschrieben, schaut es euch mal an. Dieser kleine Teil sollte lediglich eine kleine �bersicht �ber weitverbreitete Scan-Techniken geben. F�r denjenigen, der sich mit Protocol Anomaly Detection besch�ftigt, waren sicherlich einige Ans�tze dabei (bestimmte Flagkombinationen, die man als "anormal" betrachten muss...).

Other ICMP Related Stuff
Neben den bereits erw�hnten Echo-Reply / Request, stellt ICMP noch weitere Meldungstypen zur Verf�gung, durch deren Verwendung man durchaus noch weitere Informationen zum Netzwerk sammeln kann (sogenannte NON - ECHO - REQUESTS):

ICMP Time Stamp Request / Reply (RFC792):
Eigentlicher Sinn eines Time Stamp Request (Typ 13) ist es, die Uhrzeiteinstellungen eines Remote System zu ermitteln. Empf�ngt der Remote-Rechner einen Time Stamp Request, so sendet er einen Time Stamp Reply (Typ 14) zur�ck . Erst einmal zum Aufbau eines Time Stamp (entsprechend der RFC): 
 ---------------------------------------------------
 |         Typ  |      Code      |   Pruefsumme    |
 ---------------------------------------------------
 |      Bezeichner      |       Sequenz            |
 ---------------------------------------------------
 |              Absendezeit                        |
 ---------------------------------------------------
 |              Empfangszeit                       |
 ---------------------------------------------------
 |              Ruecksendezeit                     |
 ---------------------------------------------------
Bevor ich auf den Nutzen eines Time Stamp Request f�r einen Angreifer komme, erst einmal grunds�tzlich etwas zum Time Stamp. F�r uns sind eigentlich nur die letzten drei "Felder" von Interesse. Hier aber erstmal die entsprechende Stelle im RFC: 
 The Originate Timestamp is the time the sender last touched the
 message before sending it, the Receive Timestamp is the time the
 echoer first touched it on receipt, and the Transmit Timestamp is
 the time the echoer last touched the message on sending it."


Entsprechend dem RFC ist der zur�ckgegebene Time Stamp die Anzahl der Millisekunden, die seit Mitternacht UT (GMT) vergangen ist.

Welchen Nutzen hat aber nun ein Time Stamp Request / Reply f�r uns?

Erh�lt man einen Time Stamp Reply zur�ck, so w�sste man schon mal, dass der Host erreichbar ist, zum anderen kann man anhand der Absende-/Empfangs- und R�cksendezeit R�ckschl�sse auf die Belastung des Netzwerkes ziehen (Differenz von R�cksendezeit und Empfangszeit ist entscheidend, nat�rlich abh�ngig von den verwendeten Kabeln, Karten... ).

Abschliessend noch ein Tcpdump-Trace: 

 11:38:37.898253 Diablo > Diablo: icmp: time stamp query id 53763 seq 64548
 (ttl 254, id 13170, len 40)
                 4500 0028 3372 0000 fe01 8b60 7f00 0001
                 7f00 0001 0d00 61fb d203 fc24 0211 c0ca
                 0000 0000 0000 0000

 11:38:37.898253 Diablo > Diablo: icmp: time stamp reply id 53763 seq 64548 :
 org 0x211c0ca recv 0x211c0ca xmit 0x211c0ca (DF) (ttl 255, id 0, len 40)
                 4500 0028 0000 4000 ff01 7dd2 7f00 0001
                 7f00 0001 0e00 db43 d203 fc24 0211 c0ca
                 0211 c0ca 0211 c0ca
ICMP Information Request / Reply (RFC792): "This message may be sent with the source network in the IP header source and destination address fields zero (which means "this" network). The replying IP module should send the reply with the addresses fully specified. This message is a way for a host to find out the number of the network it is on. "

Ein Information Request (Typ 15) hat also den Sinn und Zweck, die Netznummer des Rechners zu ermitteln, der den Request gesendet hat. 

 The address of the source in a information request message will be
 the destination of the information reply message.  To form a
 information reply message, the source and destination addresses
 are simply reversed, ..."


Bei einem Information Reply (Typ 16) nimmt man also die Source IP des Information Request als Destination IP des Reply (oder vereinfacht ausgedr�ckt: Man sendet den Reply an denjenigen, der die Informationen angefordert hat). Als Source IP des Reply nimmt man sich die Destination IP des Request ...

Normalerweise ist es allerdings so, dass der Sender eines Information Request als Destination Address 0 einsetzt (bedeutet dann soviel wie "dieses Netzwerk"). Es besteht allerdings auch die M�glichkeit, sowohl Destination als auch Source IP (beim Absenden des Request) auf 0 zu setzen, in diesem Fall w�rde der Information Reply sowohl im Source, als auch im Destination Address - Feld die Netznummer des Rechners zugesendet bekommen. Ist das Source Address - Feld beim Request ungleich 0, wird die Netznummer des Rechners nur im Source IP - Feld des Reply zur�ckgesendet. 
 ------------------------------------------------------------------
 |         Typ  |      Code      |   Pruefsumme          |
 ------------------------------------------------------------------
 |      Bezeichner      |       Sequenz            |
 ------------------------------------------------------------------
Es scheint, als k�nnte man nur innerhalb des Netzwerks einen Information Request versenden (s.o.), doch dies muss nicht zwangsl�ufig so sein. Einige Betriebssysteme antworten auch auf einen Information Request, bei dem die Destination IP nicht im selben Netzwerk liegt. In einem solchen Information Reply w�rden wir dann die IP des Hosts erhalten (und nicht die Netznummer).

Zum Abschluss wiederum ein kurzer Tcpdump-Trace: 
11:42:35.608253 Diablo > Diablo: icmp: information request (ttl 255,
 id 13170, len 28)
                         4500 001c 3372 0000 ff01 8a6c 7f00 0001
                         7f00 0001 0f00 1afc d603 0000
11:42:36.608253 Diablo > Diablo: icmp: information request (ttl 255,
 id 13170, len 28)
                         4500 001c 3372 0000 ff01 8a6c 7f00 0001
                         7f00 0001 0f00 19fc d603 0100
ICMP Address Mask Request / Reply (RFC 950): Der Address Mask Request (Typ 17) ist in einem anderen RFC beschrieben worden, schaut f�r n�here Infos also im RFC 950 und nicht im RFC 792 nach. Sinn und Zweck eines Address Mask Request ist es, die Subnetmask des verbundenen Netzes zu ermitteln. Wenn ein Gateway einen solchen Request empf�ngt, sollte er die entsprechenden Informationen an den entsprechenden Knoten zur�cksenden (Address Mask Reply - Typ 18) 
 ------------------------------------------------------------
 | Typ  |      Code      |   Pruefsumme                     |
 ------------------------------------------------------------
 | Bezeichner   |       Sequenz                             |
 ------------------------------------------------------------
 |               Address Mask                               |
 ------------------------------------------------------------
Ihr k�nnt somit nicht nur Hosts im Netzwerk entdecken (die online sind), ihr k�nntet anhand weiterer Tests auch mehr �ber die Netzwerk-Konfiguration erfahren ....

Tcpdump-Trace: 

 11:45:26.678253 Diablo > Diablo: icmp: address mask request (ttl 254, id
  13170, len 32)
                4500 0020 3372 0000 fe01 8b68 7f00 0001
                7f00 0001 1100 edd7 dc03 2524 0000 0000
Ich hoffe, dieser Abschnitt hat euch gezeigt, dass man weitaus mehr M�glichkeiten hat, Informationen �ber ein Netzwerk zu erhalten, und dass man nicht immer auf das "normale" ping zur�ckgreifen muss... In den entsprechenden RFC sind meistens auch Hinweise enthalten, die beschreiben, was man beachten sollte, wenn man die verschiedenen Requests "unterst�tzen" m�chte. Entwickler von ("richtigen") IDS m�ssen solche Dinge nat�rlich auch beachten, wenn sie unterst�tzt werden sollen, muss darauf geachtet werden, dass dies richtig geschieht (s. RFC). Doch auch hier ist noch nicht Schluss, wie ihr im n�chsten Abschnitt nachlesen k�nnt...

Even more information about the Target: Der Einsatz von Paketfiltern (oder allgemeiner Firewalls) ist heutzutage sicherlich nichts seltenes, bzw. besonderes mehr. Auch der Einsatz von sogenannten Firewall Modulen in IDS ist mittlerweile h�ufiger vorzufinden. Oft hat ein Angreifer gar nicht die M�glichkeiten, einige der besprochenen Scans anzuwenden, da sie geblockt, gefiltert, ... werden. Ziel dieses kleinen Abschnittes ist es, M�glichkeiten aufzuf�hren, mit denen ihr einige Filter-Rules / Firewall-Rules des Target erarbeiten k�nnt.

Das Prinzip hinter dieser Idee ist recht einfach, man versucht ICMP-Fehlermeldungen hervorzurufen, bzw. "illegale" Pakete zu versenden, anhand derer man schon die ersten Aussagen �ber das Ruleset machen kann. 
If the gateway or host processing a datagram finds a problem with
the header parameters such that it cannot complete processing the
datagram it must discard the datagram.  One potential source of
such a problem is with incorrect arguments in an option.  The
gateway or host may also notify the source host via the parameter
problem message.  This message is only sent if the error caused
the datagram to be discarded."

Dieser Abschnitt stammt aus dem RFC 792 und ist ein Teil der Beschreibung des sogenannten Parameter Problem (Typ 12). Wie man diesem Abschnitt entnehmen kann, kann ein Grund f�r die Meldung "Parameter Problem", ein falscher IP Header sein, d.h. wenn wir einem Rechner ein Paket mit falschem IP Header schicken w�rden, m�ssten wir eigentlich diese Fehlermeldung zur�ckbekommmen. Diese Fehlermeldung hat noch einen weiteren Vorteil, die Unterst�tzung dieser Fehlermeldung wird n�mlich vom RFC 1122 "empfohlen": 
A host SHOULD generate Parameter Problem messages.  An
incoming Parameter Problem message MUST be passed to the
transport layer, and it MAY be reported to the user.

DISCUSSION:
 The ICMP Parameter Problem message is sent to the
 source host for any problem not specifically covered by
 another ICMP message.  Receipt of a Parameter Problem
 message generally indicates some local or remote
 implementation error."
Insgesamt betrachtet, ist dies eine sehr gute M�glichkeit, Hosts im Netzwerk zu erkennen (aus genannten Gr�nden)...

Ausserdem sei noch auf RFC 1812 verwiesen: 
 4.3.3.5 Parameter Problem

A router MUST generate a Parameter Problem message for any error not
specifically covered by another ICMP message.  The IP header field or
IP option including the byte indicated by the pointer field MUST be
included unchanged in the IP header returned with this ICMP message.
Section [4.3.2] defines an exception to this requirement.  "
Nichtsdestotrotz interpretieren verschiedene Router diese Stelle (und auch weitere) auch unterschiedlich, wodurch nicht wirklich sicher gestellt ist, dass ein Parameter Problem gemeldet wird...

Ein IDS (bzw. Firewalls) sollten dennoch die Felder in dem IP Header �berpr�fen, da es zwar schon mal dazu kommen kann, dass man ein Paket mit falschem Header erh�lt, dies sollte aber eigentlich seltener vorkommen. Ein Angreifer, der anhand dieser Methode ein ganzes Netzwerk "scant" (oder sonst einen bestimmten IP Range), weiss schon mal, dass die Firewall / Paketfilter ... diese Fehlermeldung nicht blockiert, filtert..., erh�lt man hingegen kein Parameter Problem zur�ck, weiss man schon mal, dass diese Meldung blockiert wird.

Diese Methode zur Feststellung des Ruleset ist allerdings erst der erste Schritt (die Methode stellt vor allem eine Alternative zum "normalen" Ping da). Um eine m�glichst exakte Access Control List (ACL) m�glicher Filtering / Firewall Software erstellen zu k�nnen, m�ssen wir noch weitere Informationen zur Topologie ... einholen. Um dies zu erreichen, k�nnte man z.B. die verschiedenen ICMP-Meldungstypen an die einzelnen Hosts schicken (mit falschem IP Header), und darauf warten, wann ein Parameter Problem gemeldet wird. Wenn bei einem Host "X" ein Parameter Problem gemeldet wird, heisst das f�r uns schon mal, dass der Host diesen ICMP-Meldungstyp nicht filtert (und das der entsprechende Host erreichbar ist). Desweiteren bedeutet das f�r uns, dass der/die fehlerhaften Eintr�ge im IP Header nicht �berpr�ft werden... Sollten wir kein Parameter Problem erhalten, so k�nnen wir auch daraus verschiedenste Schl�sse ziehen. Zum einen w�re es m�glich, dass ein Filter den ICMP-Meldungstyp filtert/blockiert, desweiteren w�re es durchaus denkbar, dass der Router ... den Header �berpr�ft und diese Anormalit�t nicht zul�sst ... etc ... Wie ihr seht, kann man aus beiden Ergebnissen R�ckschl�sse auf m�gliche Filterregeln ziehen, letztendlich erh�lt man also schon mal eine grobe Vorstellung von dem, was erlaubt ist und was nicht. Weitere M�glichkeiten k�nnten darin bestehen, die verwendeten Protokolle (TCP, UDP, ...) zu variieren, so dass man weitere Regeln herausfinden k�nnte. Es best�nde z.B. die M�glichkeit, dass ein bestimmtes Protokoll geblockt/gefiltert wird oder ein bestimmter Port (des Hosts) oder die bereits besprochenen Gr�nde, k�nnten der Grund daf�r sein, dass kein Parameter Problem zur�ckgemeldet wird.

Ich denke, die Abhandlung zum Parameter Problem war jetzt ausreichend, so dass wir uns weiteren Fehlermeldungen zuwenden k�nnen.

Der folgende Abschnitt ist wiederum dem RFC 1812 entnommen und beschreibt, was ein Destination Unreachable - Fehler ist und was der Grund f�r diesen Fehler sein kann: 
 The ICMP Destination Unreachable message is sent by a router in
 response to a packet which it cannot forward because the destination
 (or next hop) is unreachable or a service is unavailable.  Examples
 of such cases include a message addressed to a host which is not
 there and therefore does not respond to ARP requests, and messages
 addressed to network prefixes for which the router has no valid
 route.

 A router MUST be able to generate ICMP Destination Unreachable
 messages and SHOULD choose a response code that most closely matches
 the reason the message is being generated.

 0 = Network Unreachable - generated by a router if a forwarding path
      (route) to the destination network is not available;

 1 = Host Unreachable - generated by a router if a forwarding path
      (route) to the destination host on a directly connected network
      is not available (does not respond to ARP);

 2 = Protocol Unreachable - generated if the transport protocol
      designated in a datagram is not supported in the transport layer
      of the final destination;

 3 = Port Unreachable - generated if the designated transport protocol
      (e.g., UDP) is unable to demultiplex the datagram in the
      transport layer of the final destination but has no protocol
      mechanism to inform the sender;

 4 = Fragmentation Needed and DF Set - generated if a router needs to
      fragment a datagram but cannot since the DF flag is set;

 5 = Source Route Failed - generated if a router cannot forward a
      packet to the next hop in a source route option;

 6 = Destination Network Unknown - This code SHOULD NOT be generated
      since it would imply on the part of the router that the
      destination network does not exist (net unreachable code 0
      SHOULD be used in place of code 6);

 7 = Destination Host Unknown - generated only when a router can
      determine (from link layer advice) that the destination host
      does not exist;

 11 = Network Unreachable For Type Of Service - generated by a router
      if a forwarding path (route) to the destination network with the
      requested or default TOS is not available;

 12 = Host Unreachable For Type Of Service - generated if a router
      cannot forward a packet because its route(s) to the destination
      do not match either the TOS requested in the datagram or the
      default TOS (0).         "
Wenn wir nun z.B. probieren, an irgendeinen Port ein Paket zu senden, das ein Protokoll verwendet, das gar nicht existiert, sollte eigentlich Destination Unreachable mit Code - Wert 2 (Protocol Unreachable) gemeldet werden. Um bei diesem Beispiel zu bleiben, m�sst ihr erst einmal wissen, welche Protokolle "zul�ssig" sind, dies k�nnt ihr rausfinden, indem ihr eure /etc/protocols �ffnet. Nach der Installation auf einem meiner Rechner, sah die /etc/protocols z.B. so aus: 
 -------------- /etc/protocols ----------------
# /etc/protocols:
# $Id: protocols,v 1.2 2001/01/29 17:29:30 notting Exp $
#
# Internet (IP) protocols
#
#       from: @(#)protocols     5.1 (Berkeley) 4/17/89
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
#
# See also http://www.isi.edu/in-notes/iana/assignments/protocol-numbers

ip      0       IP              # internet protocol, pseudo protocol number
#hopopt 0       HOPOPT          # hop-by-hop options for ipv6
icmp    1       ICMP            # internet control message protocol
igmp    2       IGMP            # internet group management protocol
ggp     3       GGP             # gateway-gateway protocol
ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially ``IP'')
st      5       ST              # ST datagram mode
tcp     6       TCP             # transmission control protocol
cbt     7       CBT             # CBT, Tony Ballardie 
egp     8       EGP             # exterior gateway protocol
igp     9       IGP             # any private interior gateway 
                                # (Cisco: for IGRP)
bbn-rcc 10      BBN-RCC-MON     # BBN RCC Monitoring
nvp     11      NVP-II          # Network Voice Protocol
pup     12      PUP             # PARC universal packet protocol
argus   13      ARGUS           # ARGUS
emcon   14      EMCON           # EMCON
xnet    15      XNET            # Cross Net Debugger
chaos   16      CHAOS           # Chaos
udp     17      UDP             # user datagram protocol
mux     18      MUX             # Multiplexing protocol
dcn     19      DCN-MEAS        # DCN Measurement Subsystems
hmp     20      HMP             # host monitoring protocol
prm     21      PRM             # packet radio measurement protocol
xns-idp 22      XNS-IDP         # Xerox NS IDP
trunk-1 23      TRUNK-1         # Trunk-1
trunk-2 24      TRUNK-2         # Trunk-2
leaf-1  25      LEAF-1          # Leaf-1
leaf-2  26      LEAF-2          # Leaf-2
rdp     27      RDP             # "reliable datagram" protocol
irtp    28      IRTP            # Internet Reliable Transaction Protocol
iso-tp4 29      ISO-TP4         # ISO Transport Protocol Class 4
netblt  30      NETBLT          # Bulk Data Transfer Protocol
mfe-nsp 31      MFE-NSP         # MFE Network Services Protocol
merit-inp       32    MERIT-INP       # MERIT Internodal Protocol
sep     33      SEP             # Sequential Exchange Protocol
3pc     34      3PC             # Third Party Connect Protocol
idpr    35      IDPR            # Inter-Domain Policy Routing Protocol
xtp     36      XTP             # Xpress Tranfer Protocol
ddp     37      DDP             # Datagram Delivery Protocol
idpr-cmtp       38    IDPR-CMTP       # IDPR Control Message Transport Proto
tp++    39      TP++            # TP++ Transport Protocol
il      40      IL              # IL Transport Protocol
ipv6    41      IPv6            # IPv6
sdrp    42      SDRP            # Source Demand Routing Protocol
ipv6-route      43    IPv6-Route      # Routing Header for IPv6
ipv6-frag       44    IPv6-Frag       # Fragment Header for IPv6
idrp    45      IDRP            # Inter-Domain Routing Protocol
rsvp    46      RSVP            # Resource ReSerVation Protocol
gre     47      GRE             # Generic Routing Encapsulation
mhrp    48      MHRP            # Mobile Host Routing Protocol
bna     49      BNA             # BNA
ipv6-crypt      50    IPv6-Crypt      # Encryption Header for IPv6
ipv6-auth       51    IPv6-Auth       # Authentication Header for IPv6
i-nlsp  52      I-NLSP          # Integrated Net Layer Security TUBA
swipe   53      SWIPE           # IP with Encryption
narp    54      NARP            # NBMA Address Resolution Protocol
mobile  55      MOBILE          # IP Mobility
tlsp    56      TLSP            # Transport Layer Security Protocol
skip    57      SKIP            # SKIP
ipv6-icmp       58    IPv6-ICMP       # ICMP for IPv6
ipv6-nonxt      59    IPv6-NoNxt      # No Next Header for IPv6
ipv6-opts       60    IPv6-Opts       # Destination Options for IPv6
#       61                      # any host internal protocol
cftp    62      CFTP            # CFTP
#       63                      # any local network
sat-expak       64      SAT-EXPAK       # SATNET and Backroom EXPAK
kryptolan       65      KRYPTOLAN       # Kryptolan
rvd     66      RVD             # MIT Remote Virtual Disk Protocol
ippc    67      IPPC            # Internet Pluribus Packet Core
#       68                      # any distributed file system
sat-mon 69      SAT-MON         # SATNET Monitoring
visa    70      VISA            # VISA Protocol
ipcv    71      IPCV            # Internet Packet Core Utility
cpnx    72      CPNX            # Computer Protocol Network Executive
cphb    73      CPHB            # Computer Protocol Heart Beat
wsn     74      WSN             # Wang Span Network
pvp     75      PVP             # Packet Video Protocol
br-sat-mon      76      BR-SAT-MON      # Backroom SATNET Monitoring
sun-nd  77      SUN-ND          # SUN ND PROTOCOL-Temporary
wb-mon  78      WB-MON          # WIDEBAND Monitoring
wb-expak        79      WB-EXPAK        # WIDEBAND EXPAK
iso-ip  80      ISO-IP          # ISO Internet Protocol
vmtp    81      VMTP            # Versatile Message Transport
secure-vmtp     82      SECURE-VMTP     # SECURE-VMTP
vines   83      VINES           # VINES
ttp     84      TTP             # TTP
nsfnet-igp      85      NSFNET-IGP      # NSFNET-IGP
dgp     86      DGP             # Dissimilar Gateway Protocol
tcf     87      TCF             # TCF
eigrp   88      EIGRP           # Enhanced Interi
Was, wenn der Host aber kein Protocol Unreachable zur�ckgibt (obwohl man ein Protokoll verwendet hat, das es eigentlich nicht gibt)? Dies kann nun zwei Ursachen haben, zum einen k�nnte es sein, dass ihr eine AIX, HP-UX oder Digital Unix Maschine erwischt habt oder aber das Ruleset des Rechners erlaubt den Zugriff auf diese Ports nicht. Stellt also erst mal sicher, was f�r einen Rechner ihr scant (u.a. mit OS Fingerprint Detection), ansonsten k�nnt ihr davon ausgehen, dass eben gefiltert/geblockt wird.

Anmerkung: Die Erkennung einer solchen Attacke ist recht einfach (und geh�rt �brigens ins Gebiet der Protocol Anomaly Detection). Anomaly Detection wird im n�chsten Abschnitt (Analysem�glichkeiten) besprochen, f�r jetzt reicht es zu wissen, dass der Verkehr nach "Anomalit�ten" durchsucht wird, die Verwendung eines nicht vorhandenen Protokolls geh�rt zu diesen "Anormalit�ten".

- Denial of Service (DoS)
DoS (Denial of Service) - Attacken haben meist zum Ziel, den Zielserver lahmzulegen, so dass dieser erst einmal eine Zeit lang nicht erreichbar ist. Hier gibt es viele Techniken, durch die man die Ressourcen des Zielservers v�llig "verbrauchen" kann. Im folgenden stelle ich euch die gebr�uchlichsten Techniken vor:

ICMP Flooding:
Beim ICMP Flooding wird ICMP "ausgenutzt". Erh�lt ein Rechner ein ICMP echo request, wird er normalerweise versuchen, darauf mit einem ICMP Echo Reply zu antworten. Dieser Sachverhalt wird beim ICMP Flooding ausgenutzt: Schickt man dem Opfer zu viele Echo Requests, werden dessen Ressourcen sehr lange damit besch�ftigt sein, diese Requests zu beantworten (in Form von Echo Replies). Da zus�tzlich die IP des Angreifers meist noch gespoofed ist, bekommt nicht er die Replies, sondern jemand anders.

SYN Flooding:
Um SYN Flooding zu verstehen, hier nochmal kurz der "normale" Three-Way-Handshake: 
------------------      SYN                               -------------
| Rechner A      | ------------------------------------ > | Rechner B |
------------------                                        -------------

------------------              ACK/SYN                 -------------
| Rechner A      | <------------------------------------| Rechner B |
------------------                                      -------------

------------------              ACK                       -------------
| Rechner A      | ------------------------------------ > | Rechner B |
------------------                                        -------------
Rechner A schickt also Rechner B ein SYN, um zu sagen, dass er eine Verbindung haben will, B antwortet mit ACK/SYN und wartet nun auf das abschlie�ende ACK, womit die Verbindung vollst�ndig w�re. Doch was ist, wenn das letzte ACK gar nicht erst gesendet wird? Wenn B sein SYN/ACK zur�ckschickt, wartet er (wie bereits gesagt) schlie�lich noch auf das ACK von A, solange wird diese noch nicht vollst�ndige Verbindung in die sogenannte Connection Queue von "B" aufgenommen. Sollte der Verbindungsaufbau abgeschlossen sein (also A hat B noch ACK geschickt), wird sie wieder aus der Connection Queue entfernt. Da meist noch die IP-Adresse gespoofed ist, erh�lt B niemals ein ACK zur�ck (sollte zumindest so sein). Man kann also einfach die Connection Queue "f�llen", jeder weitere Verbindungsversuch w�rde scheitern, da der Rechner keine weiteren Verbindungen aufnehmen kann.

UDP Flooding:
Bei dieser Flooding-Attacke wird der Zielserver... mit UDP-Paketen �berflutet. Schickt man ein UDP-Paket an einen Port auf dem Zielserver, wird erst �berpr�ft, welcher Dienst f�r diese "Anfrage" zust�ndig ist. Nun w�hlt man hier meist willk�rliche/zuf�llige Ports, an die man die Pakete schickt, um die Wahrscheinlichkeit zu erh�hen, dass ein "Port Unreachable" von ICMP gemeldet wird. Als Folge eines solchen Floods, leidet die Performance des Netzwerksegments (oft) erheblich.

Land:
Sp�ter werdet ihr einen Filter sehen, der erkennt, ob eine Land-Attacke vorliegt und Gegenma�nahmen einleiten kann, vorerst aber mal zur eigentlichen Attacke. Bei der Land-Attacke sind sowohl Absender-, als auch Empf�nger-IP gleich. Durch Senden eines z.B. SYN-Pakets (mit gleicher Source / Destination IP) an einen offenen Port, wird bei dem Opfer eine Race Condition ausgel�st, die dazu f�hrt, dass das gesamte System lahmgelegt wird. Hier ein Trace einer Land-Attacke: 
 23/06/02  23:12:48  194.157.1.1  80  -> 194.157.1.1
 23/06/02  23:14:57  194.157.1.1  31337  ->     194.157.1.1
Wie ihr hier nochmals sehen k�nnt, sind Source IP und Destination IP gleich. Damit Svoern seine Tcpdump-Traces bekommt, hier noch ein Tcpdump-Trace ;) : 
 12:35:26.916369 192.168.38.110.135>192.168.38.110.135: udp 46[tos0x3,ECT,CE]   
         4503 004a 96ac 0000 4011 15c7 c0a8 266e        
        c0a8 266e 0087 0087 0036 8433 6920 616d         
        206c 616d 6520 646f 7320 6b69 6420 6275         
        7420 6920 7265
 12:35:26.916566 192.168.38.110.135>192.168.38.110.135: udp 46[tos0x3,ECT,CE]
        4503 004a 2923 0000 4011 8350 c0a8 266e         
        c0a8 266e 0087 0087 0036 8433 6920 616d         
        206c 616d 6520 646f 7320 6b69 6420 6275         
        7420 6920 7265
 12:35:26.916682 192.168.38.110.135>192.168.38.110.135:udp 46[tos0x3,ECT,CE]    
        4503 004a 50a0 0000 4011 5bd3 c0a8 266e         
        c0a8 266e 0087 0087 0036 8433 6920 616d         
        206c 616d 6520 646f 7320 6b69 6420 6275         
        7420 6920 7265
Die Attacke, die ihr hier sehen k�nnt, wird �brigens auch Snork genannt.

Teardrop:
Hier wird die M�glichkeit der Fragmentierung der IP-Pakete genutzt. Wie ihr schon bei der Beschreibung der Scans lesen konntet, kommt es zur Fragmentierung, wenn die Datagramme gr��er als die verarbeitbare Gr��e sind, diese Gr��enbeschr�nkung wird MTU (Maximum Transmission Unit) genannt. Bei dieser Attacke �berlappen sich diese Fragmente, als Folge dieser �berlappung haben (hatten) viele OS Probleme und es kam meistens zum Systemabsturz. 
 10:13:32.104203 10.10.10.10.53>192.168.1.3.53: udp 28(frag 242:36@0+)(ttl64)   
        4500 0038 00f2 2000 4011 8404 0a0a 0a0a         
        c0a8 0103 0035 0035 0024 0000 0000 0000         
        0000 0000 0000 0000 0000 0000 0000 0000         
         0000 0000 0000

 10:13:32.104272 10.10.10.10 >192.168.1.3: udp 28(frag 242:4@24)(ttl 64)        
        4500 0018 00f2 0003 4011 a421 0a0a 0a0a         
        c0a8 0103 0035 0035 0024 0000 0000 0000         
        0000 0000 0000 0000 0000 0000 0000
Ping of Death:
Auch hier spielt die Fragmentierung der IP-Pakete wiederum eine Rolle. Hier will ich allerdings etwas (nur etwas ;) genauer auf die Fragmentierung eingehen. Wie bereits gesagt, bedeutet Fragmentierung, dass die Gr��e der Datagramme "reduziert" wird, wobei die einzelnen Fragmente nat�rlich nicht gr��er als die MTU sein d�rfen. Bei der Fragmentierung muss man allerdings noch beachten, dass man nicht beliebig (nach Lust und Laune) fragmentieren darf, bzw. gewisse Felder m�ssen in jedem Fragment enthalten sein. So muss z.B. jedes Fragment den IP-Protokollkopf enthalten, damit die richtige Route gew�hlt wird. Damit die Router die Fragmente wieder zu einem Datagramm zusammensetzen k�nnen, enth�lt jedes Fragment eine 16-Bit Kennung (des urspr�nglichen "gro�en" Datagramms). Anhand dieser 16-Bit Kennung ist es also sp�ter m�glich, die einzelnen Fragmente wieder dem richtigen Datagramm zuzuordnen. Au�erdem gibt es noch einen Fragment-Offset, der angibt, an welcher Position das Fragment im urspr�nglichen Datagramm stand. Die Position wird allerdings in 8-Oktett-Einheiten bestimmt (da die Position in 8-Oktett-Einheiten gemessen wird). Zus�tzlich wird durch das 'More-Bit' gezeigt, ob weitere Fragmente dieses Datagramms folgen oder nicht, steht es auf 1 so folgen noch weitere, steht es auf 0, so war es das letzte Fragment des urspr�nglichen Datagramms. Nun aber zum eigentlichen Ping-of-Death-Angriff. Beim Ping-of-Death wird nun dem letzten Fragment ein Offset gegeben f�r den gilt: Offset + Fragmentgr��e > 65535 Bytes . Hierdurch ist es m�glich, interne 16-Bit-Variablen zu �berfluten, was z.B. einen Systemabsturz als Folge h�tte. 
 17:43:58.431 pinger > target: icmp echo request (frag 4321: 380@0+)
 17:43:58.431 pinger > target: (frag 4321: 380@2656+)
 17:43:58.431 pinger > target: (frag 4321: 380@3040+)
 17:43:58.431 pinger > target: (frag 4321: 380@3416+)

Smurf:
Bei dieser Attacke wird zur Broadcastadresse ein Ping geschickt, besser gesagt, viele Pings werden geschickt. An die Broadcastadresse gesandte Pakete werden an alle Rechner des Netzwerks gerichtet und auch von allen "ausgewertet". Wenn man nun viele Pings (ICMP Echo Requests) an die Broadcastadresse schickt (z.B. 10000 pro Sekunde), und man hat ein relativ gro�es Netzwerk mit 1000 Rechnern, so bedeutet das, dass bei dem Opfer 10000 * 1000 ICMP Echo Replies pro Sekunde eintreffen, also 10 000 000 ICMP Echo Replies. 
 09:28:28.666073 179.135.168.43>256.256.30.255: icmp: echo request (DF)         
        4500 001c c014 4000 1e01 6172 b387 a82b         
        c0a8 1eff 0800 f7ff 0000 0000 0000 0000         
        0000 0000 0000 0000 0000 0000 0000
 09:28:28.696073 68.90.226.250>256.256.30.255: icmp: echo request (DF)  
        4500 001c c015 4000 1e01 95cf 445a e2fa         
        c0a8 1eff 0800 f7ff 0000 0000 3136 3803         
        3133 3503 3137 3907 696e 2d61 6464
 09:28:28.726073 138.98.10.247>256.256.30.255:  icmp: echo request (DF)         
        4500 001c c016 4000 1e01 27ca 8a62 0af7         
        c0a8 1eff 0800 f7ff 0000 0000 0332 3236         
        3938 0331 3638 0769 6e2d 6164 6472
 09:28:28.756073 130.113.202.100 > 256.256.30.255: icmp: echo request (DF)      
        4500 001c c017 4000 1e01 704c 8271ca64  
        c0a8 1eff 0800 f7ff 0000 0000 0231 3002         
        3938 0331 3338 0769 6e2d 6164 6472
        ...
Seit l�ngerer Zeit gibt es auch noch DDoS-Attacken (Distributed Denial of Service). Wie der Name schon sagt, handelt es sich hier um verteilte/vernetzte DoS-Attacken. Der Angreifer (Client) sucht sich andere Rechner/Netzwerke, die man leicht exploiten kann, diese ersten infizierten Rechner sind dann die sogenannten Handler. Von den Handlern aus werden weitere Rechner / Netzwerke infiziert, diese infizierten Rechner werden dann Agenten genannt, d.h. bildlich dargestellt: 
                ---------
                | YOU   |
                ---------
                     |
        ---------------------------------
        |               |               |
     Handler         Handler         Handler                                    
        |               |               |
    ------        -------------------        ------------               
    |    |        |                 |        |          |       
  Agent  Agent      Agent           Agent  Agent     Agent
Sp�ter k�nnen dann die Angriffe von den Agenten...aus, ausgef�hrt werden.

Das war der erste Teil dieser Serie. Es geht weiter in der n�chsten Ausgabe von LinuxFocus.