Mittwoch, 22. August 2007
IDS - Intrusion Detection Systeme
Wer mehr über IDS erfahren möchte, dem erklärt es Socma jetzt.
--------------------------------------------------------------------------- IDS - Intrusion Detection System - Version 1.1 - written by Socma - Email: Socma@gmx.net http://www.ultimate-science.de --------------------------------------------------------------------------- 1. Einleitung 2. IDS - Übersicht 2.1. Host Based Intrusion Detection 2.2. Network Intrusion Detection 2.3. Network Node Intrusion Detection 2.4. Application Based Intrusion Detection 2.5. Stack Based Intrusion Detection 2.6. Honeypot 2.7. Padded Cell Systems 3. Angriffsarten 4. Analysemöglichkeiten 5. Signaturen 5.1. Konzept 5.2. Schwächen 6. Response 6.1. Active 6.2. Passive 7. Filter 8. Standards 8.1. CVE 9. Beispiele 9.1. Snort 9.2. bofh 9.3. LIDS 9.4. COLOID 10. Abschließende Worte -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 1. 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's 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 : - false positive = Falscher Alarm, also ein Alarm das ein Angriff stattgefunden hat, obwohl dies nicht der Fall war - false negative = Das IDS erkennt einen Angriff nicht als solchen und filtert ihn nicht Sollten irgendwelche Wünsche bezüglich des Inhalts bestehen, stehe ich gerne zur Verfügung. Bei Fehlern, Lob, Anregungen, .... Mail an mich: Socma@gmx.net. Grundsätzliche Kenntnisse von Linux und TCP/IP werden vorausgesetzt. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 2.IDS-Übersicht Sinn dieses Kapitels ist, die verschiedenen Arten von Intrusion Detection Systems vorzustellen, gleichzeitig auch ihre Vor - und Nachteile. Vorab aber erstmal ein paar einleitende Worte zum Sinn u. Zweck von Intrusion Detection Systems. Ein IDS beobachtet sozusagen die Vorgänge die auf dem jeweiligen Rechner oder im jeweiligen Netzwerk vorgehen, anhand von verschieden Methoden, die ich hier vorstellen werde, wird versucht heraus zu finden 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 spezifieren: - Information Sources - Response - Analysis Response und Analysis werden später nochmals genauer behandelt (Response in Kapitel 6 und Analysis in Kapitel 4), die verschiedenen Arten der "Information Sources" gleich. Aufgrund der umfassenden Möglichkeiten einen PC / ein Netzwerk "anzugreifen" , gibts auch verschiedene Arten von IDSs , (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): 2.1. Host - Based Intrusion Detection Host - Based Intrusion Detection Systems 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 IDSs 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 aller wichtigsten 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: - ihr "seht" die Auswirkungen eines Angriffs und könnt daher besser darauf reagieren - ihr könnt Trojanische Pferde .... besser erkennen, da die zur Verfügung stehenden Informationen / Möglichkeiten sehr groß sind - können Attacken erkennen, die Network Based IDSs nicht erkennen, da dort der Verkehr oft verschlüsselt ist - man kann Vorgänge auf seinem Rechner exakt verfolgen Nachteile: - sie können schlechter Scans erkennen - sind anfälliger gegenüber DoS Attacken - Die Analyse der Operating System audit trails ist aufgrund ihrer Größe sehr zeitaufwendig - Sie strapazieren die Rechnerleistung des jeweiligen PCs (teilweise) immens Beispiele: -Tripwire [http://www.tripwire.com/products/index.cfml] -SWATCH [http://freshmeat.net/redir/swatch/10125/url_homepage/swatch] -DragonSquire [http://www.enterasys.com/ids/squire/] -Tiger [http://freshmeat.net/redir/tiger-audit/30581/url_homepage/tiger] -Security Manager [http://www.netiq.com/products/sm/default.asp] 2.2. Network Intrusion Detection (NIDS) Hauptaufgabe eines Network IDSs 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 gegebenfalls Alarm auszulösen. Da dies ihre einzige Aufgabe ist, besteht die Möglichkeit diese Sensoren besser zu schützen . In diesem Zusammenhang taucht auch öfters der sogen. "Stealth Mode" auf, also das 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 Modus (vereinfacht gesagt, der Modus in dem das Netzwerkgerät den gesamten Verkehr des Netzwerks mitliesst) und besitzt keine eigene IP, dadurch soll es dem Angreifer möglichst schwer gemacht werden, den Sensor zu lokalisieren. Dieser Zustand wird übrigens von Packet-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 das 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 geschuetzt wird. Wenn die Sensoren innerhalb der Firewall sitzen, ist es für sie besser möglich festzustellen, ob evtl. 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 plaziert 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 plaziert. 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 plaziert, ist noch nicht garantiert das wirklich alle Angriffe gefiltert u. erkannt werden, z.B. bei TCP Attacken. In diesem Fall würde man versuchen die Attacke zu erkennen, in dem man sog. 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 Firewall...) ausgeübt werden, zu protokollieren und analysieren, dadurch kann der Admin sehen, wo er evtl. die Konfiguration der Firewall umstellen sollte. Sensoren die außerhalb der Firewall plaziert 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 u. Innerhalb der Firewall Nun, diese Variante verbindet die beiden zuvor genannten Varianten. Allerdings ist hier die Gefahr groß , dass man die Sensoren u. oder 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: -Die Sensoren können gut geschützt werden, da sie "nur" den Verkehr überwachen -man kann besser Scans erkennen -Anhand von Signaturen...kann man den Verkehr "filtern" (naja das es nicht immer so ist wird noch gezeigt) Nachteile: - Die Wahrscheinlichkeit von sog. false negatives (also Angriffen die nicht als Angriffe entarnt werden) ist hoch, da es schwierig ist das gesamte Netzwerk zu kontrollieren - meistens müssen sie auf verschlüsselter ebene operieren, wodurch die Analyse der Pakete erschwert wird - im Gegensatz zum Host- Based IDS sehen sie nicht die Auswirkungen eines Angriffs Beispiele: -NetRanger [http://www.cisco.com] -Dragon [http://www.securitywizards.com] -NFR [http://www.nfr.net] -Snort [http://www.snort.org] -DTK [http://all.net/dtk/dtk.html] -ISS RealSecure [http://www.uh.edu/infotech/ software/unix/realsecure/index.html] Obwohl ich hier zwischen HIDSs und NIDSs unterscheide, wird der Unterschied zwischen beiden ID-Systemen immer geringer, da mittlerweile auch HIDSs die Grundfunktionalität eines NIDS haben. Bekannte ID-Systeme wie ISS RealSecure bezeichnen sich auch nicht nur als NIDSs , 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"). 2.3. Network Node Intrusion Detection (NNIDS) Grundsätzlich arbeitet dieser neue Typ (NNIDS) so wie die typischen NIDSs, 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, das NIDSs im Promiscuous Mode laufen, während NNIDSs nicht im Promiscuous Mode laufen. Dadurch das 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. 2.4. Application Based Intrusion Detection Application Based IDSs sind eine Untergruppe der Host - Based IDSs, 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: - man arbeitet auf unverschlüsselter Ebene, im Gegensatz zu z.B. Network Based IDSs , dadurch ist Analyse besser möglich - man kann "auffällige" kommandos die der user auf/mit dem Programm ausüben will, schnell erkennen und verhindern Nachteile: - kein Schutz und nur wenig Möglichkeiten z.B. Trojanische Pferde zu erkennen (da man nicht im Kernelspace agiert) - Die von dieser Art der IDSs erzeugten Log-Files sind leichte Angriffsziele für "Angreifer" und nicht so sicher wie z.B. Operating System audit trails 2.5. Stack Based Intrusion Detection Auch eine neuere Art der IDSs ist das sog. 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. In einer der zukünftigen Versionen dieses Papers folgt sicherlich die Beschreibung.... 2.6. Honeypot Für Honeypots gibts 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 das 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 (DeMilitarizedZone) plaziert 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 das eine Attacke vorliegt (möglichst auch Lokalisiernung des Angreifers, was für ein Angriff, welche Dienste 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 /das IDS macht, wie man auf einen Angriff reagiert. Später werden die verschiedenen Response-Options von IDSs 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 v.a. 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 plaziert, um evtl. Scans aufs 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. jmd. 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 wenig Ä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, Logging der Aktivitäten, .... Ein Ansatz von dem ich schon öfters 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 gucken, 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 das Honeypots nicht ganz legal sind , bzw. müsst ihr aufpassen bei der Verwendung von Honeypots. Das Problem besteht darin , dass der Honeypot als "Einladung zum Angriff" aufgefasst werden könnte, und wenn man merkt das 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 das 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....) 2.7. 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, "Scheinumgebung" ist. Wichtig dabei ist, dass diese Umgebung so realistisch wie möglich dargestellt werden muss, bzw. der Angreifer muss denken das der Angriff erfolgreich war (sozusagen). In diesem padded cell host besteht die Möglichkeit jegliche Aktivität des Angreifers zu protokollieren, 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 evtl. entsprechende Gegen-Aktionen des IDS als "Angriff" empfunden werden könnten, obwohl sie nur dem Sammeln von Informationen über den richtigen Angreifer dienen). Vorteile: -einmal in dem padded cell host, können die Angreifer keinen Schaden mehr anrichten , da es nur ein "Scheinumgebung" ist -der Admin kann die Aktionen des Angreifers direkt verfolgen / protokollieren, um mehr Informationen zur Attacke und dem Ziel der Attacke zu bekommen , somit ist es auch leichter Gegenmaßnahmen einzuleiten Nachteile: -evtl. könnte die Verwendung von Padded Cell Systems nicht legal sein (hier gilt widerrum das gleiche wie für Honeypots, in Europa sollte es eigentlich kein Problem sein) -die Umsetzung eines solchen Systems ist sehr schwer und erfordet einiges an können , schließlich muss die gesamte Umgebung richtig simuliert werden. Sollte der Admin irgendwo einen kleinen Fehler gemacht haben, könnte dieses System durchaus weitere Sicherheitslücken eröffnen -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 3.Angriffsarten Bevor man ein IDS entwickelt oder benutzt , sollte man die potentiellen Gefahren spezifieren, also auch welchen 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 das sich die Vertrauensverhältnisse gegenüber dem bestimmten User (meist zu seinen Gunstengeändert haben, also z.B. das man sich nicht mehr authentifierzen muss, gegenüber einem bestimmten Prog.... Solche Fälle werden auch noch heute missbraucht, z.B. wenn zwischen zwei PCs ein "Vertrauensverhältnis" besteht, d.h. der User des einen PC's kann sich beim anderen einloggen ohne Passworteingabe (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 gibts 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 das bestimmte User sich überhaupt einloggen dürfen oder das 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, das es einem Angreifer natürlich auch die anderen 3 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 zaehlen zu den Host-Based-IDSs, zu der Aufgabe eines Integrity Checkers gehoert es die Integritaet diverser Dateien zu ueberpruefen und gegebenfalls eine Warnung auszugeben, wenn man Aenderungen an einer Datei erkennt. Das Vorgehen bei der Verwendung von Integrity Checkern ist meist das gleiche, daher ist die Beschreibung eines best. Integrity Checkers wohl nicht notwendig... 1) Erstellen einer Datenbank Der erste Schritt nach der Installation eines Integrity Checker's 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 fragwuerdig ist. Erstellt man eine Datenbank zu einem spaeteren Zeitpunkt (und der Angreifer hat vielleicht schon bestehende Binaries ersetzt), wuerde die Verwendung eines Integrity Checkers den eigentlichen Sinn nicht erfuellen. In einem solchen Fall wuerden die ersetzen Binaries als "Originale" betrachtet werden, sollte der Admin spaeter diese Binaries wiederrum durch die eigentlichen "Orignale" ersetzen, wuerde ein Alarm ausgeloest... Die meisten Tools bieten umfangreiche Moeglichkeiten die Dateien / Verzeichnisse zu spezifizieren, von denen man eine Hashsumme... erstellen moechte. Man koennte also vereinfacht ausgedrueckt sagen, dass ein Fingerabdruck vom System angefertigt wird. (Der Modus heisst uebrigens bei Tripwire Database Initialization Mode) 2) Checken der Integritaet Nachdem der Admin eine Datenbank (bzw. den Fingerabdruck) des Systems hat, kann er zu jeder Zeit sein System erneut ueberpruefen. 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 Moeglichkeiten, lest dafuer einfach mal die manpage zu Tripwire oder eine zugehoerige Dokumentation. Diese beiden Schritte sind eigentlich beim Umgang mit den meisten Integrity Checkern vorzufinden. Tripwire bietet noch die Moeglichkeit die Datenbank zu aktualisieren (man hat neue Tools installiert...) oder die Policyfile 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 das 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 das man per Konfigurationsdatei einstellen kann, von welchen Dateien die Integrität überprüft werden soll. Doch was, wenn der Angreifer diese Konfig- urationsdatei lesen/beschreiben kann ? Er könnte die "Suchpfade" ändern, so dass das Verzeichnis mit den geänderten Binaries gar nicht erst durchscannt wird. Am besten lasst ihr also die Konfig auch nicht auf der Platte und packt sie wiederrum 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 Benutzer- freundlichkeit ist ja, das 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 sog. 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 gegebenfalls 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 IDSs 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/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 v.a. also folgendes herausfinden: - welches Betriebssystem ? - welche Versionen von bestimmten Programmen laufen - welche Services laufen die man evtl. "angreifen" kann - welche Ports offen sind -...... 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's): 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 wurden. Ich habe absichtlich keine Änderungen (an der Konfig) 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
(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 (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 u. 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, das 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, 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 das 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 (v.a. 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. IDSs sollten auf jeden Fall in der Lage sein diese Anormalitäten (Xmas und NULL) zu erkennen... FTP Bounce: In manchen FTPD's kann das PORT Kommando dazu missbraucht werden, eine beliebige Verbindung vom ftp server zu einer anderen Maschine herzustellen. Doch ersteinmal ein kleiner Überblick wie das ganze "normalerweise" abläuft. Zuerst stellt der Klient eine Verbindung zum Ftp Server (port 21) her, der FTP Server "erstellt" eine zweite Verbindung zurück zum Klient (damit er auch Daten zurücksenden kann). Für diese zweite Verbindung wird das PORT Kommando verwendet. Das interessante hierran ist, dass das Kommando sowohl IP als auch Port (den es zu öffnen gilt) des Klients 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 spezifiert wurde. Der Angriffspunkt ist nun das PORT Kommando, bei dem man die IP und den Port des (angeblichen) Klients 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 das der spezifierte 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 Unix) genannt. Die fragmentierten Datagramme werden am Ende des Knotens wieder zusammengesetzt... Dieses Verhalten kann aber auch ausgenutzt werden. Nicht jedes 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, das die angesprungene Firewall/IDS Probleme bei der Zusammensetzung der Fragmente hat. Diese Probleme können sich auf verschiedenste Art und Weisen ä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 das 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: Vorraussetzung zum Dumb Scanning ist der sog. ---------- -------------- ---------- | 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 reply's 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 Addresse die von dem 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 Hosts 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 spezifieren welche Ports offen sind (bei TARGET), die Wahrscheinlichkeit das 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 (s.o)...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, das sich die Betriebssysteme in (den manchmal kleinsten) Dingen unterscheiden (welch Erkenntnis
Trackbacks
Trackback für spezifische URI dieses Eintrags
Keine Trackbacks
