--------------------------------------------------------------------------- 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 Gunsten ;) geä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 ;). Da es zahlreiche Dokumente zu dieser Technik gibt ,werde ich mich hier kurz fassen 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äß rfc 793), 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 nen 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 ;) Win gibt nämlich die eigene Sequenznummer+1 zurück... -BOGUS Flag Test: Wird ein undefiniertes TCP Flag im TCP Header verwendet (in nem SYN Paket), übernehmen Linux Rechner < 2.0.35 diese Flageinstellungen. Andere OSs resetten beim Erhallten eines SYN+BOGUS Pakets... -TCP Initial Window: Die meisten Betriebssysteme verwenden (nahezu) konstante Fenstergroessen (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 enthaltenden 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, schauts euch mal an. Dieser kleine Teil sollte lediglich eine kleine Übersicht über weit-verbreitete 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 erwaehnten Echo-Reply / Request , stellt ICMP noch weitere Meldungstypen zur Verfuegung, durch deren Verwendung man durchaus noch weitere Informationen zum Netzwerk sammeln kann (sog. NON - ECHO - REQUESTS): ICMP Time Stamp Request / Reply (RFC 792): Eigentlicher Sinn eines Time Stamp Requests (Typ 13) ist es, die Uhrzeit - einstellungen eines remote Systems zu ermitteln. Empfaengt der remote Rechner einen Time Stamp Request, so sendet es einen Time Stamp Reply (Typ 14) zurueck . Erst einmal zum Aufbau eines Time Stamps (entsprechend der rfc's): --------------------------------------------------- | Typ | Code | Pruefsumme | --------------------------------------------------- | Bezeichner | Sequenz | --------------------------------------------------- | Absendezeit | --------------------------------------------------- | Empfangszeit | --------------------------------------------------- | Ruecksendezeit | --------------------------------------------------- Bevor ich auf den Nutzen eines Time Stamp Request's fuer einen Angreifer komme, erst einmal grundsaetzlich etwas zum Time Stamp. Fuer 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 des rfc's, ist der zurueckgegebene TimeStamp die Anzahl der Millisekunden die seit Mitternach UT (GMT) vergangen ist. Welchen Nutzen hat aber nun ein Time Stamp Request / Reply fuer uns ? Erhaelt man einen Time Stamp Reply zurueck, so wuesste man schonmal das der Host erreichbar ist , zum anderen kann man anhand der Absende - Empfangs und Ruecksendezeit Rueckschluesse auf die Belastung des Netzwerkes ziehen (Differenz von Ruecksendezeit u. 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 (RFC 792): "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 u. 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's als Destination IP des Reply's (oder vereinfacht ausgedrueckt: Man sendet den Reply an denjenigen der die Informationen angefordert hat). Als Source - IP des Reply's nimmt man sich die Destination IP des Request's.... Normalerweise ist es allerdings so, dass der Sender eines Information Request's als Destination Address 0 einsetzt (bedeutet dann soviel wie "dieses Netzwerk") . Es besteht allerdings auch die Moeglichkeit sowohl Destination , als auch Source IP (beim Absenden des Request's) auf 0 zu setzen, in diesem Fall wuerde 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's zurückgesendet. ------------------------------------------------------------------------- | Typ | Code | Pruefsumme | ------------------------------------------------------------------------- | Bezeichner | Sequenz | ------------------------------------------------------------------------- Es scheint als könnte man nur innerhalb des Netzwerkes 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 wiederrum 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 wurden, schaut fuer naehere Infos also im RFC 950 und nicht im RFC 792 nach. Sinn u. Zweck eines Address Mask Request's ist es, die Subnetmask des verbundenen Netzes zu ermitteln. Wenn ein Gateway einen solchen Request empfaengt sollte er die entsprechenden Informationen an den entsprechenden Knoten zuruecksenden (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 Moeglichkeiten hat Informationen ueber ein Netzwerk zu erhalten, und das man nicht immer auf das "normale" ping zurueckgreifen muss... In den entsprechenden RFC's sind meistens auch Hinweise enthalten, die beschreiben was man beachten sollte wenn man die verschiedenen Requests "unterstuetzen" moechte .... Entwickler von ("richtigen") IDSs muessen solche Dinge natuerlich auch beachten, wenn sie unterstuetzt werden sollen, muss darauf geachtet werden, dass dies richtig geschieht (s. RFC's). Doch auch hier ist noch nicht Schluss, wie ihr im naechsten Abschnitt nachlesen koennt... 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 sog. Firewall Modulen in IDS's ist mittlerweile haeufiger vorzufinden. Oft hat ein Angreifer gar nicht die Moeglichkeiten, einige der besprochenen Scans anzuwenden, da sie geblockt, gefiltert .... werden. Ziel dieses kleinen Abschnittes ist es, Moeglichkeiten aufzufuehren, mit denen ihr einige Filter-Rules / Firewall-Rules des Targets erarbeiten koennt. Das Prinzip hinter dieser Idee ist recht einfach, man versucht ICMP Fehler Meldungen hervor zu rufen, bzw. "illegale" Pakete zu versenden, anhand derer man schon die ersten Aussagen ueber 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 sog.Parameter Problem's (Typ 12). Wie man diesem Abschnitt entnehmen kann, kann ein Grund fuer die Meldung "Parameter Problem", ein falscher IP Header sein, d.h. wenn wir einem Rechner ein Paket mit falschem IP Header schicken wuerden, muessten wir eigentlich diese Fehlermeldung zurueckbekommmen. Diese Fehlermeldung hat noch einen weiteren Vorteil, die Unterstuetzung dieser Fehlermeldung wird naemlich 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 Moeglichkeit Hosts im Netzwerk zu erkennen (aus genannten Gruenden).... Ausserdem sei noch auf RFC1812 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 ueberpruefen, da es zwar schon mal dazu kommen kann, dass man ein Paket mit falschem Header erhaelt, dies sollte aber eigentlich seltener vorkommen. Ein Angreifer, der anhand dieser Methode ein ganzes Netzwerk "scannt" (oder sonst nen bestimmten IP - Range), weiss schonmal das die Firewall / Paketfilter .... diese Fehlermeldung nicht blockiert,filtert.., erhaelt man hingegen kein Parameter Problem zurueck, weiss man schon mal das diese Meldung blockiert wird. Diese Methode zur Feststellung des Ruleset's ist allerdings erst der erste Schritt (die Methode stellt v.a. eine Alternative zum "normalen" Ping da). Um eine moeglichst exakte Access-List (ACL) moeglicher Filtering / Firewall Software erstellen zu koennen , muessen wir noch weitere Informationen zur Topologie .... einholen. Um dies zu erreichen, koennte 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 fuer uns schon mal das der Host diesen ICMP Meldungstyp nicht filtert (und das der entsprechende Host erreichbar ist). Des weiteren bedeutet das fuer uns , dass der / die fehlerhaften Eintraege im IP Header nicht ueberprueft werden... Sollten wir kein Parameter Problem erhalten, so koennen wir auch daraus verschiedenste Schluesse ziehen. Zum einen waere es moeglich, dass ein Filter den ICMP Meldungstyp filtert/blockiert, des weiteren waere es durchaus denkbar das der Router .... den Header ueberprueft und diese Annormalitaet nicht zulaesst ... etc .... Wie ihr seht, kann man aus beiden Ergebnissen Rueckschluesse auf moegliche Filterregeln ziehen, letztendlich erhaelt man also schonmal eine grobe Vorstellung von dem was erlaubt ist u. was nicht. Weitere Moeglichkeiten koennten darin bestehen die verwendeten Protokolle (TCP,UDP...) zu variieren, so dass man weitere Regeln herausfinden koennte. Es bestuende z.B. die Moeglichkeit das ein best. Protokoll geblockt/gefiltert wird oder ein bestimmter Port (des Hosts) oder die bereits besprochenen Gruende, koennten der Grund dafuer sein, dass kein Parameter Problem zurueckgemeldet wird. Ich denke die Abhandlung zum Parameter Problem war jetzt ausreichend , so dass wir uns weiteren Fehlermeldungen zuwenden koennen. Der folgende Abschnitt ist wiederrum dem RFC1812 entnommen und beschreibt was ein Destination Unreachable Fehler ist und was der Grund fuer 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, dass 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, muesst ihr erst einmal wissen, welche Protokolle "zulaessig" sind, dies koennt ihr rausfinden, in dem ihr eure /etc/protocols oeffnet. 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 ------- ende von /etc/protocols -------------------------- Was, wenn der Host aber kein Protocol Unreachable zurueckgibt (obwohl man ein Protokoll verwendet hat, das es eigentlich nicht gibt) ? Dies kann nun zwei Ursachen haben, zum einen koennte es sein das ihr ne AIX, HP-UX oder Digital Unix Maschine erwischt habt oder aber das Ruleset des Rechners erlaubt den Zugriff auf diese Ports nicht. Stellt also erstmal sicher was fuer nen Rechner ihr scannt (u.a. mit OS Fingerprint Detection), ansonsten koennt ihr davon ausgehen das eben gefiltert/geblockt wird. Note : Die Erkennung einer solchen Attacke ist recht einfach (und gehoert uebrigens ins Gebiet der Protocol Anomaly Detection). Anomaly Detection wird im naechsten Kapitel (Analysemoeglichkeiten) besprochen, fuer jetzt reicht es zu wissen das der Verkehr nach "Anomalitaeten" durchsucht wird, die Verwendung eines nicht vorhandenen Protokolls gehoert zu diesen "Annormalitaeten". - 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 Resourcen 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 reply's). Da zusätzlich die IP des Angreifers meist noch gespoofed ist, bekommt nicht er die reply's , 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 ene 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 sog. 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ührliche/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 / Dest 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 Moeglichkeit 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 Unix) genannt. Bei dieser Attacke überlappen sich diese Fragmente, als Folge dieser Überlappung haben (hatten) viele OSs 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 wiederrum eine Rolle. Hier will ich allerdings etwas (nur etwas ;) genauer auf die Fragmentierung eingehen. Wie bereits gesagt bedeutet Fragmentierung das 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 > 65 535 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 reply's pro Sekunde eintreffen, also 10 000 000 ICMP echo reply's. 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 sog. 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. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 4.Analysemöglichkeiten Nun ist bereits besprochen wurden gegen welche Attacken sich IDSs schützen sollten und welche verschiedenen Systeme man unterscheidet. Jetzt aber zur Art und Weise der Analyse, also wie ein IDS bestimmt ob ein Angriff vorlag oder nicht, bzw. ob der Angriff erfolgreich war oder nicht. Grundsätzlich unterscheidet man hier Misuse Detection und Anomaly Detection. Bei der Misuse Detection werden bestimmte Muster definiert, die einen Angriff als solchen enttarnen. Diese Muster werden auch Signaturen genannt, und werden in einem extra Teil noch intensiver besprochen. Für jetzt reicht es zu wissen das man z.b. Signaturen definieren kann, die im Netwerk-Verkehr nach bestimmten Strings suchen (z.B. /etc/passwd) und gegebenfalls die "Anfrage" nach dieser Datei verbieten und Alarm auslösen. Der Vorteil der Misuse Detection besteht darin, dass die Wahrscheinlichkeit von false alarms relativ gering ist, da man anhand von Signaturen recht genau einstellen kann, nach welchen Dingen gesucht werden soll.... Der Nachteil ist allerdings auch recht offensichtlich, denn neue Attacken werden nicht sehr häufig erkannt ,da sie nicht definiert sind (siehe Kapitel über Signaturen). Die andere Möglichkeit stellt die sogenannte Anomaly Detection dar. Das bedeutet einfach nur, dass ein Profil von normalen Useraktivitäten erzeugt wurde und wenn das Verhalten des Users zu sehr von diesem Profil abweicht , ein Alarm ausgelöst wird. Erster Schritt bei dieser Analyse stellt also das Erstellen eines Profils (einer Datenbank) "normaler" Useraktivitäten dar. Hierbei können die verschiedensten Dinge protokolliert werden : Wie oft führt er bestimmte Kommandos aus ? Wann führt er bestimmte Kommandos aus ? Wie oft öffnet er bestimmte Dateien ? .... Hier ein kleines Beispiel : - User 'beispiel' führt durchschnittlich 3 mal täglich /bin/su aus (dieser Wert stünde im Profil) Nun kommt der User 'beispiel' und führt an einem Tag auf einmal 7 mal su aus, also mehr als doppelt so oft wie sonst. Anomaly Detection würde dieses "anormale" Verhalten enttarnen und den Admin warnen das User 'beispiel' plötzlich 7 mal su ausgeführt hat, dabei ist der protokollierte , "normale" Durchschnitt bei 3. Die Nachteile dieses Verfahrens wurde mir v.a. klar als ich selber mit der Umsetzung (siehe Beispiele am Ende - COLOID) begann, denn die Methode um eine Datenbank normaler Useraktivitäten zu erzeugen ist recht rechenintensiv. Beobachtet man z.B. wie oft der User 10 Dateien geöffnet hat, so müsste bei jedem open() überprüft werden ob es sich um eine der 10 Dateien handelt, und falls ja der entsprechende Counter hochgezählt werden. Dennoch stellt es eine sehr gute Möglichkeit dar auch neue Angriffstechniken aufzudecken, da diese wahrscheinlich als "anormal" gelten werden. Außerdem kann der Admin schließlich auch selbst definieren welche Abweichung als "anormal" gelten soll, z.B. ne Abweichung von 10% oder erst eine Abweichung von 75%.... Bei der Verwendung dieser Methode müsst ihr allerdings aufpassen, das die Erstellung des Userprofils in einem "sicheren" Netzwerk abläuft, da sonst das Verhalten des Angreifers als normal gilt und das Verhalten des richtigen Users als anormal. Allgemein umfasst die Anomaly Detection folgende Dinge: - Threshold Detection = dieser bereich benutzt v.a. Counter, die zählen wie oft was ausgeführt, geöffnet, gestartet ... wurde. Diese statische Analyse kann noch durch die sogenannte Heuristische Schwellenanalyse erweitert werden. - Rule-Based Detection = hier werden bestimmte Regeln definiert, sollte die Verwendung von diesen Regeln abweichen wird ein Alarm ausgelöst - -Static Measure = das Verhalten des Users/Systems entspricht einem Muster, das entweder vordefiniert wurde oder sonst wie erstellt wurde. Oft wird hier ein Programm/LKM... eingefügt das normale Benutzeraktivitäten protokolliert und so dass Muster definiert Heuristische Schwellenwertanalyse heisst hier, das der Counter (wie oft etwas ausgeführt werden darf) nicht von Anfang an statisch festgelegt wird, sondern dynamisch. Führt ein User normalerweise /bin/login 4 mal aus, so würde der Counter evtl. auf 5 gesetzt.... Eine Untergruppe der Anomaly Detection stellt die Protocol Anomaly Detection dar, eine relativ neue Technik, die vom Prinzip her genauso funktioniert wie die Anomaly Detection. Jedes Protokoll hat ein "vordefiniertes" Verhalten (siehe entsprechende) RFC's , Ziel der Protocol Anomaly Detection ist es festzustellen ob das Verhalten des Protokolls wie vordefiniert ist oder nicht. Es basieren mehr Angriffe auf Protocol Misuse als man vielleicht denken mag, daher ist diese Untergruppe durchaus wichtig für IDSs. Bei einem Blick zurück in den Teil über Scanning, lassen sich sicherlich einige Ansätze zur Protocol Anomaly Detection finden. U.a.: - Überprüfen ob kein Flag gesetzt ist (NULL Scan) - Überprüfen ob alle Flags gesetzt sind (XMas Scan) - Überprüfen ob "unsinnige" Kombinationen von Flags gesetzt sind, wie SF - ....... In den entsprechenden rfc's findet ihr die richtige Spezifizierungen, auch welches Verhalten nicht eintreten sollte, bzw. welches Verhaltenn bei einem bestimmten Ereignis auftreten sollte. Des weiteren gibt es noch die Application Anomaly Detection (eigentlich kommt es Application Based IDSs nahe ). In einigen Texten las ich Ansätze in diese Richtung, so dass ich mich auch damit beschäftigt habe. Natürlich hat auch ein Programm ein "normales" Verhalten, d.h. wie reagiert es auf Ereignis X .. Y , was macht es wenn der User eine fehlerhafte Eingabe macht, .... Oft werden bestehende Binaries (v.a. ps, netstat...) durch eigene ersetzt, um (im Falle von ps) bestimmte Prozesse zu verstecken. Mittels Application Anomaly Detection könnte man nun evtl. "anormales" Verhalten des Programms erkennen. Einige Application Based IDSs funktionieren sicherlich in diese Richtung, doch mit dieser Art der IDSs hab ich am wenigsten Erfahrung . Abschließend noch zu einer neuen Methode der ID-Systeme:Intrusion Prevention. Intrusion Prevention wird von einigen neuen ID-Systemen eingesetzt und unterscheidet sich von den bisher besprochenen Methoden der Intrusion Detection. Anstatt durch die Analyse von Logfiles / des Traffics.... Angriffe später zu entdecken, wird versucht Angriffe gar nicht erst zuzulassen. Im Gegensatz zu klassischen IDSs werden hier keine Signaturen benutzt um Angriffe zu erkennen. Im folgenden wird kurz erläutert was IPSs machen, die Funktionsweise sollte anhand von kleinen Beispielen verständlich sein: - Monitor application behavior - Create application rules - Alert on violations - Correlate with other events - System Call Interception - ...... 'Monitor application behavior' kommt den Application-Based-IDSs nahe,d.h. das Verhalten einer Applikation wird untersucht (und protokolliert), so z.B. auf welche Dateien es normalerweise zugreift, mit welchen Programmen es interagiert, auf welche Resourcen es zurückgreift....Ähnlich wie bei der Anomaly Detection wird also erst einmal versucht herauszufinden was ein Programm normalerweise macht ,bzw. was es machen darf. Der dritte Punkt ('Alert on violations') sollte eigentlich keiner Erklärung bedürfen, es heisst nämlich nur dass bei Abweichungen (sprich bei Erkennung einer Attacke) ein Alert ausgelöst werden kann. Dies kann bedeuten , dass einfach "nur" geloggt wird oder aber das Resourcen gesperrt werden.... Im zweiten Schritt ('Create application rules') wird auf den Informationen ,die auf den Recherchen in Teil 1 ( 'Monitor application behavior') beruhen, ein sogenanntes Application Ruleset aufgestellt. Dieses Ruleset gibt Auskunft darüber, was eine Applikation machen darf (auf welche Resourcen es zurückgreifen darf...) und daraus folgt dann auch was eine Applikation nicht machen darf. 'Correlate with other events' bedeutet, dass man andere Sensoren....über die Vorgänge informiert, durch das Zusammenarbeiten der Sensoren...kann so besser sichergestellt werden, dass Angriffe nicht zugelassen werden. Application | \/ Action | \/ --------------------- | Realtime decision | --------------------- / \ Deny Allow / \ Alert execute Action Dieses vereinfachte Schema soll lediglich noch einmal die Vorgänge verdeutlichen. Bevor eine Aktion durchgeführt wird, wird ersteinmal eine 'Realtime decision' durchgeführt (d.h. die Aktion mit dem Application Ruleset....verglichen). Sollte die Aktion nicht gestattet sein (z.B. weil das Programm auf Dateien zugreifen will / ändern will, obwohl es eigentlich gar nicht auf diese Systemdateien zugreifen darf), wird ein Alert erzeugt. In den meisten Fällen werden die anderen Sensoren (oder eine zentrale Konsole) davon auch noch informiert. Dadurch soll verhindert werden, dass andere Rechner im Netzwerk bestimmte Dateien ausführen/öffnen... Sollte die Aktion allerdings dem Ruleset entsprechen, wird es genehmigt und die entsprechende Aktion letztendlich ausgeführt... Nun aber zum vorerst letzten Punkt, der 'System call interception'. Manipulierte Systemaufrufe (durch z.B. sog. Rootkits) sind heutzutage immer öfter vorzufinden. Der Ansatz bei der Interception der Systemaufrufe ist recht einfach : Bevor ein Systemaufruf "zugelassen" wird, wird er ersteinmal genauer überprüft. Überprüfung heisst z.B. dass man folgende Fragen checkt (siehe auch [5]): - wer hat den Systemcall aufgerufen (welches Prog...) ? - unter welcher User - Autorität läuft der Prozess (root...) ? - auf was versucht der Systemcall zuzugreifen ? Somit kann auch hier kontrolliert werden, ob versucht wird wichtige Konfig/Systemdateien zu ändern...., da man "lediglich" überprüfen muss ob der Systemcall dem vordefinierten Ruleset entspricht oder nicht. Program | \/ System call | \/ System call Interception / \ Deny Allow | | do not call Kernel System call Intrusion Prevention ist verglichen mit anderen Methoden eine recht neue Methode, so dass es in Zukunft sicherlich auch noch mehr Informationsmaterial zum Thema geben wird. Zum Abschluss sei v.a. noch auf OKENA verwiesen, ein sehr leistungs- fähiges IPS. In der Whitepapers Sektion unter www.okena.com findet ihr zusätzliches Material zu StormWatch... Wer sich für die Schwächen von StormWatch interessiert, sollte [6] lesen. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 5.Signaturen Hier werden nun die Signaturen der IDSs behandelt, im zweiten Unterteil dann noch deren Schwächen... 5.1. Konzept Anhand von Signaturen können bekannte Angriffe erkannt werden, eine Signatur guckt also nach einem bestimmten Muster im Verkehr. Dieses Muster können verschiedenste Dinge sein, z.B. Strings oder auffällige Header (mit anormalen Flagkombinationen), Ports die dafür bekannt sind das sie von Trojanern benutzt werden.... Die meisten Angriffe haben gewisse Merkmale, z.B. das eben bestimmte Flags gesetzt sind oder das bestimmte Strings im Payload enthalten sind, durch Signaturen wird nun versucht anhand von diesen Merkmalen einen Angriff... zu entdecken. Beginnen möchte ich mit den sog. Payload Signaturen. Hier zur Anschauung einmal ein Teil des Payloads eines Pakets: 00 00 00 00 E9 FE FE FF FF E8 E9 FF FF FF E8 4F ............... 0 FE FF FF 2F 62 69 6E 2F 73 68 00 2D 63 00 FF FF .../bin/sh.-c... Wie ihr später in der Beschreibung zu den Snort-Rules sehen werdet, bestehen hier einige Möglichkeiten, was man machen kann. Häufig wird der Inhalt des Payloads nach bestimmten Strings durchsucht (in Snort mit 'content' oder 'content-list'), möchte jemand z.B. eine Passwortdatei (z.B. /etc/passwd) ziehen, so besteht die Möglichkeit den Payload zu durchsuchen (nach /etc/passwd) und falls das Paket diesen String enthält, Maßnahmen dagegen einzuleiten, z.B. so : alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 \ (msg:"WEB-MISC/etc/passwd";flags: A+; content:"/etc/passwd"; \ nocase;classtype:attempted-recon; sid:1122; rev:1;) Eine etwas andere Möglichkeit besteht darin, alle Pakete zu melden die nicht einen bestimmten String enthalten. Ein weiterer Ansatz besteht darin, die Größe der Pakete (an bestimmte Ports) zu überwachen , um vor möglichen Buffer Overflows zu schützen. Allgemein betrachtet besteht also die Möglichkeit den Source Port und Destination Port zu bestimmen und Zugriffe von bestimmten Ports, bzw. auf bestimmte Ports ganz zu unterbinden. Allgemein betrachtet, gehören string signatures zu den payload signatures. Bei den Payload Signatures handelt es sich um Signaturen, die den Payload eines Pakets untersuchen, wie z.B. bei den string signatures der Payload nach nem bestimmten String durchsucht wird. Doch was kann man noch anhand von Signaturen entdecken ? Nur den Payload nach bestimmten Strings durchsuchen ist sicherlich nicht immer das "berauschenste". Eine andere Möglichkeit besteht darin, die Signatur nach den Flagkombinationen des TCP Headers gucken zu lassen. Sollte in einem Paket sowohl das SYN als auch das FIN Bit gesetzt sein, so liegt hier eine Anormalität vor, die vom Angreifer dazu genutzt werden könnte bestimmte Eigenschaften des Betriebssystems herauszufinden (oder das Betriebssystem selbst herauszufinden). Wie anfangs bereits erwähnt gibt es auch bestimmte Ports , die dafür berühmt sind, das sie von Trojanern...genutzt werden. Beispiele für solche Ports wären 31337 oder 27374. Vielleicht wird es verständlicher wenn ich das ganze an einem Beispiel erkläre. Für dieses Beispiel schauen wir uns einmal typische Merkmale eines synscan-Angriffs an: - verschiedene Source IPs -TCP Src und Dest Port ist 21 - Type of service 0 - IP id 39426 - SF gesetzt (SYN und FIN) - verschiedene Sequenznummern gesetzt -verschiedene Acknowledgement Nummern gesetzt - TCP Window Größe von 1028 Ziel einer Signatur sollte es in einem solchen Falle sein, "normale" Merkmale einer Verbindung von "annormalen" zu unterscheiden. Manche IDSs besitzten auch extra Datenbanken, die eben solche Informationen wie oben gegeben enthalten, dann wird auf Übereinstimmung überprüft. Prinzipiell kann man für das synscan-Beispiel schon Anormalitäten feststellen, die sich per Signatur überprüfen lassen: - Source und Destination Port sind 21 (File Transfer Protocol - ftp) . - Gleiche Source und Destination Port Number bedeuten nicht zwangsläufig das eine Attacke vorliegt, nur ist es wahrscheinlich. - SF gesetzt, wie oben bereits gesagt dürfte dieses nicht vorkommen, da man keine Verbindung anfordern und direkt wieder beenden kann - Acknowledgement Nummer ist ungleich 0, obwohl nur SF und nicht ACK gesetzt. Wenn ACK nicht gesetzt ist, sollte die Acknowledgement-Nummer auf 0 stehen - IP ID ist immer 39426, obwohl (nach RFC) diese Nummer nicht konstant bleiben dürfte, muss aber nicht zwangsläufig auf einen synscan-Angriff hindeuten, genauso wie die konstante Window Größe... Bei der Entwicklung einer Signatur, zum Erkennen eines synscan-Angriffs, muss man nicht nur die oben genannten Merkmale des Angriffs beachten. Ziel der Signatur sollte es sein, sowohl alte Versionen , als auch zukünftige Versionen dieses Angriffs zu erkennen. Deshalb sollte man sowohl möglichst allgemeine Merkmale mit speziellen Merkmalen des Angriffs verbinden, so dass die Wahrscheinlichkeit einer Erkennung steigt. Zwar könnt ihr für jede neue Version eines Angriffs eine neue Signatur schreiben, allerdings wäre man dann wohl den ganzen Tag damit beschäftigt neue Signaturen zu schreiben, anstatt sich mit anderern, wichtigeren Dingen zu beschäftigen. Darum solltet ihr darauf achten, dass man mit der Signatur möglichst viele Angriffe (und Versionen) erkennt, ohne jedesmal die Signatur ändern zu müssen. Grundsätzlich sollte man sowohl Signaturen zur Erkennung von bestimmten Attacken, als auch allgemeine Signaturen (z.B. zur Erkennung von Anormalitäten) schreiben. Ein Beispiel für eine mögliche Signatur die einen speziellen Angriff entdeckt, könnt ihr oben sehen (oben war es der Angriff von synscan). Eine mögliche allgemeine Signatur könnte z.B. nach folgenden Dingen gucken: - acknowledgement nummer ungleich 0 obwohl ACK nicht gesetzt - anormale Flagkombinationen im TCP Header (SYN und FIN) oder andere (siehe Beschreibung der Scans) - .... Signaturen die allgemein nach Anormalitäten....von Protokollen suchen , werden im allgemeinen als Protocol analysis based signatures bezeichnet, während die andere Gruppe als "Packet Grepping" bekannt ist. 5.2. Schwächen Zwar scheint die Methode der Payload Signatures (also auch die der string signatures) recht "sicher" , allerdings gibt es Möglichkeiten diese zu umgehen. Evtl. schreibe ich mal ein Paper dazu, wie man Snort Rules umgehen kann, daher beschränke ich mich hier auf das Wesentliche. Eine Signatur, wie die die ihr dort oben sehen könnt, guckt nach "/etc/passwd", durch nocase wird Groß/Kleinschreibung nicht beachtet. Doch was ist wenn wir nicht auf direktem Wege die /etc/passwd saugen, sondern über einen Umweg ? Würde der Angreifer stattdessen '/etc/blabla/shit/../.././\passwd ' nehmen, würde die Signatur dann immer noch Alarm schlagen ? Nein, denn sie sucht, wie oben bereits erwähnt nur nach /etc/passwd (und anderen Groß/Klein geschriebenen Varianten). Ein weiteres Problem bei diesen Signaturen ist, dass sie meist nur bekannte Angriffe entdecken, nach bekannten Vulns suchen. Neuere Versionen bestimmter Attacken werden meistens nicht entdeckt.... Die anderen Signaturen, die sich auf spezielle Angriffe spezialisieren oder allgemeine Signaturen haben zwar den Vorteil, dass sie neue Angriffe eher entdecken, allerdings muss man bei der Formulierung seiner Signatur-Regeln "aufpassen". Eine Signatur die sich auf einen bestimmten Angriff spezialisiert (auf dessen Entdeckung), wird fehlschlagen bei der Entdeckung einer etwas veränderten Variante (anstatt einen konstanten IP ID Wert von 39426 zu haben, hat die neue Attacke einen variablen Wert....). Bei der Formulierung von allgemeinen (protocol analysis based signatures) Signaturen, muss man darauf achten, dass man die Regeln auch wirklich allgemein formuliert, d.h. die Regeln müssen auf Anormalitäten hinweisen, die so nicht auftreten können bzw. dürfen . Eine weitere Schwäche offenbart sich bei näherer Betrachtung der Unicode Attacke (siehe [4]). Beispielhaft hier die Beschreibung einer Sicherheitslücke im MS IIS,die durch die Unicode Attacke ermöglicht wird/wurde: "Synopsis: A flaw exists in Microsoft Internet Information Server (IIS) that may allow remote users to list directory contents, view files, delete files, and execute arbitrary commands. Attackers may use the Unicode character set to craft URLs to access resources via IIS that would normally be inaccessible. All recent versions of IIS are affected by this vulnerability. Exploitation of this vulnerability is trivial. ISS X-Force is aware of widespread exploitation of this vulnerability. " Das Problem für IDSs besteht darin, dass die Zeichen in UTF-8 verschiedene Codes haben, die doch im gleichen Zeichen resultieren. Z.B. "A": U+0041, U+0100, U+0102, U+0104, U+01CD, U+01DE, U+8721. Da MS ISS nicht auf Groß/Klein - schreibung achtet(e) , waren wiederrum mehrere Möglichkeiten vorhanden verschiedene Zeichen darzustellen (es existieren z.B. 83,060,640 verschiedene Möglichkeiten AEIOU darzustellen..). Ruft ein Angreifer nun z.B. "http://victim/../../winnt/system32/cmd.exe" würde IIS noch einen Fehler erzeugen, wenn man allerdings die Stelle "../.." durch ein UTF-8 Äquivalent ersetzt, wird kein Fehler erzeugt : "http://victim/..%C1%9C../winnt/system32 /cmd.exe". Außerdem können sog. unescape UTF-8 Codes dazu führen, dass man Seiten aufrufen kann, die man eigentlich nicht aufrufen darf. Ein NIDS hat es schwer diese Angriffe zu erkennen, da sich das ganze auf dem Application Layer abspielt , in einem solchen Fall wäre der Einsatz eines HIDSs sinnvoller. Verschlüsselung stellt im allgemeinen ein Problem für Sensoren da, diese Tatsache wird mittlerweile auch immer öfters ausgenutzt. Das Vorgehen einiger "IDS-Hersteller" zeigte auch deutlich die Grenzen der Signaturen, die verfügbaren Signaturen erkannten zwar einige bekannte Unicode-Attacken, bei kleinen Veränderungen des Angriffs wurde die Signatur allerdings wieder wertlos. Lediglich NetworkICE hat zur damaligen Zeit erfolgreich die Signaturen entwickelt, die diese Attacken entdeckten (Snort und ISS RealSecure entwickelten auch Signaturen, allerdings entdeckten diese wie gesagt nur die bekannten Unicode-Attacken). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 6.Response Wie bereits im Verlauf des Textes erwähnt wurde untersuchen IDSs die Vorgänge auf dem PC / im Netzwerk, doch was wäre ein IDS wenn es nichts machen würde um darauf aufmerksam zu machen / darauf zu reagieren ? Dann wäre ein IDS wohl nicht viel Wert, bzw. nur Verschwendung von Rechenperformance. Grundsätzlich unterscheidet man bei 'Response' einerseits Active Response und andererseits Passive Response. Im jeweiligen Abschnitt sollten die Unterschiede eigentlich deutlich werden... Dem interessierten Leser sei auf OPSEC (http://www.opsec.com) verwiesen. " 'Secured by Check Point' appliances are security solutions that integrate Check Point VPN-1/FireWall-1 technology onto our partners' hardware platforms. " Dieses System erlaubt es also bestehende Sicherheits-Systeme in die FireWall-1 zu integrieren. Ein zusätzlicher Vorteil liegt darin das es weltweit anerkannt wird (und ca. 300 Partner hat ). Wenn ihr einen Angriff entdeckt, könntet ihr die IP Adresse des Angreifers durch die Firewall "sperren" (nur als eine mögliche Response Option)... Solltet ihr an OPSEC interessiert sein, so solltet ihr euch "Deployment Platforms" durchlesen, dort stehen auch die Voraussetzungen um dem System "beizutreten" (Partner zu werden). 6.1. Active Response Active Response bedeutet das automatisch darauf reagiert wird, wenn das IDS einen Einbruch(sversuch) meldet. Je nachdem was für ein Angriff gemeldet wird (also auch abhängig davon wie schwerwiegend der Angriff war) bieten die meisten IDSs verschiedene Optionen um darauf zu reagieren: 1) Aktionen gegen den potentiellen Einbrecher einleiten 2) "Lediglich" zusätzliche Informationen sammeln (über den Angreifer und dessen Attacke, bzw. deren Auswirkungen) 3) Konfiguration....ändern Die erste mögliche Reaktion wäre hier Aktionen gegen den Einbrecher einzuleiten. Diese Aktionen können natürlich alles mögliche bedeuten, Zugriff für diese Person sperren oder gar Attacken gegen diesen Einbrecher einzuleiten. Wie allerdings schon bei Honeypots erwähnt, ist es oft nicht nur schwierig seinerseits Attacken gegen den Angreifer zu steuern , sondern oft auch illegal. In diesem Zusammenhang taucht öfters der sog. "Third Party Effect" auf. Was ist dieser Effekt eigentlich ? Anschaulich erklärt, ist ein Third Party Effect nichts anderes als z.B. so was : ------------ ------------ ------- | Intruder | ------------> | Innocent | ----------> | YOU | ------------ ------------ ------- Der Third Party Effect heisst also einfach, dass eine Unschuldige Person (ein unschuldiges Netzwerk) von dem Angreifer erfolgreich attackiert wurde, danach nutzt er dieses Netzwerk um von dort aus unser Netzwerk (und vielleicht auch andere) anzugreifen. Doch wo liegt hier das Problem ? Das Problem besteht nun darin, dass unser Netzwerk 'Innocent' als Angreifer enttarnen würde, anschließend würde es Attacken gegen 'Innocent' einleiten, obwohl 'Intruder' dieses Netzwerk attackiert hat um gegen uns Attacken ein zu leiten, und nicht 'Innocent' der eigentliche Täter war. Als Folge unseres Angriffs (mit der falschen Gewissheit wir würden "nur" den Angreifer attackieren) würde sicherlich nicht zu unterschätzender Schaden bei 'Innocent' entstehen. Wenn 'Intruder' noch geschickt genug war seine Spuren (also die Spuren seines eigentlichen Angriffs) zu verwischen, werden wir für diesen Schaden verantwortlich gemacht , nicht 'Intruder'. Die zweite Möglichkeit (also zusätzliche Informationen zu sammeln) ist da schon unproblematischer. Sollte ein möglicher Angriff/Einbruch festgestellt werden, werden nun "lediglich" zusätzliche Informationen über den User und dessen Attacke reingeholt. Wenn ein IDS feststellt das ein bestimmter User erfolgreich seine Rechte erweitert hat (oder sonst ein "Angriff" vorliegt) könnte dieser User in Folge dessen genauer observiert werden, z.B. protokollieren der eingegebenen Kommandos (falls nicht eingestellt), von wo aus hat sich der User eingeloggt, wie lange bleibt er angemeldet, wann hat er sich eingeloggt, wie oft (und wann) loggt er sich die nächsten Tage ein, probiert er irgendwelche bestimmten Binaries zu ftp'en ... , es wird so gesehen also ein Profil des Angreifers erstellt .Dies hat den Vorteil das man später die ausführlichen Logs genau analysieren kann um mögliche Schwachstellen in der Konfiguration...zu schließen, außerdem ist es eher möglich gerichtliche Schritte gegen den Angreifer einzuleiten. Als dritte Möglichkeit sehe ich die mögliche Änderung der bestehenden Konfigurationen des Systems, der Firewall etc. Wenn der Angreifer bestimmte IP Adressen benutzen sollte, so könnte man verbieten das sich ein User mit dieser IP mit dem Netzwerk connecten...darf. Natürlich könnte man auch sonstige Zugriffe die vom (vermuteten) Ort aus kommen, blocken (und auch protokollieren). In Ausnahmefällen könnte man vorerst auch einfach mal jeglichen Zugriff auf das eigene Netzwerk unterbinden (oder jeglichen Zugriff auf bestimmte Ports, von bestimmten Netzwerk Interfaces ....) Eine weitere Möglichkeit der Active Response stellt das Beenden einer TCP-Connection dar (TCP-Kill genannt). Um eine Verbindung zu einem anderen Rechner zu beenden, schickt man ihm ein RST (Reset-Flag), so dass die Session "gekillt wird". Normalerweise wird RST nur gesendet, wenn ein Fehler in der Verbindung aufgetreten ist ..., in diesem Fall kann es aber von einem IDS (wie z.B. ISS RealSecure) dazu "gebraucht" werden Sessions mit einem anderen Rechner zu schließen (es existiert auch ein gleichnamiges Tool , für Win-NT). " tcpkill - kill TCP connections on a LAN ....... tcpkill kills specified in-progress TCP connections (use- ful for libnids-based applications which require a full TCP 3-whs for TCB creation). " Dies ist ein Ausschnitt aus 'man tcpkill' .... Wie ihr seht besteht hier eine recht umfassende Möglichkeit auf Angriffe zu reagieren. Gegenattacken einzuleiten scheint zwar auf den ersten Blick verführerisch, sollte allerdings möglichst nicht angewandt werden. 6.2. Passive Response Im Unterschied zur Active Response, werden hier meist nur Warnungen... geloggt , die dann der Admin/User...kontrollieren muss. Hier bestehen folgende Möglichkeiten zu reagieren: 1) Warnungen , Hinweise ... loggen 2) Erzeugen von sog. Reports, die den Zustand des Systems über gewisse Zeit beobachten und so einen Bericht anfertigen. Nahezu jedes IDS besitzt die Möglichkeit Warnungen zu generieren oder Hinweise an User/Browser...zu verschicken. Wenn z.B. versucht wird eine wichtige Systemdatei zu löschen, bestimmte Services zu starten (deren Benutzung verboten sein sollte),...könnte eine Warnung erzeugt werden, die über den Vorfall informiert, wer daran beteiligt war und auch den Zeitpunkt. Mittlerweile besitzen auch immer mehr IDSs die Möglichkeit sog. Reports zu erzeugen. Der Zustand des Systems wird hier über einen längeren Zeitraum hin überwacht, Vorgänge protokolliert und dann ein Statusreport erzeugt. Die Möglichkeit der Passive Response bieten eigentliche alle IDSs... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 7.Filter Ein Filter wird dazu benutzt einen Angriff anhand seiner Signatur zu erkennen. Diese Signatur hat indirekt etwas mit den bereits besprochenen Signaturen zu tun , da auch hier typische Merkmale eines Angriffs (wie Dest/Src Ports, Dest/Src IPs...) untersucht werden. Im weiteren Teil dieses Kapitels , werde ich anhand von N-Code einige Beispiele für Filter gegen bekannte Attacken vorstellen und erklären, sollte euch N-Code unbekannt sein, so könnt ihr am Ende dieses Teils eine Seite finden (advanced users guide - nfr) die eine übersicht über N-Code liefert. land: # Dies ist ein Beispiel, wie man in N-Code eine land Attacke erkennen kann filter pptp ip () { if(ip.src == ip.dest) { record system.time, eth.src, ip.src, eth.dst, ip.dest to land_recdr; } } Da hier unbekannte Variablen verwendet wurden, hier kurz eine Erklärung : - ip.src = die Source-IP Adresse - ip.dest = die Destination-IP Adresse - eth.src = MAC Adresse der "Ziel-Machine" - eth.dst = MAC Adresse des "Source-PCs" - record system.time = protokolliert die Zeit (den Zeitpunkt) zu dem die Bedingung ip.src == ip.dest erfüllt war Wie ihr seht, kennt auch N-Code den Operator ==, wenn ihr euch den Advanced User's Guide durchlest, werdet ihr feststellen das auch andere Gemeinsamkeiten (mit Hochsprachen...) bestehen, z.B. kennt auch N-Code die Operatoren + , - , *... oder zusammengesetzte Operatoren wie >=, != .... oder wie oben ==. Xmas Scan: Wie ihr aus "Angriffsarten" wissen solltet, sind bei einem Xmas Scan alle Flags gesetzt. Daher scheint es plausibel zu überprüfen, ob denn nun alle gesetzt sind oder nicht. Dafür benötigt man allerdings noch die Werte der einzelnen, gesetzten Bits : Bit Wert -------------------------------------- F-FIN 1 S-SYN 2 R-RST 4 P-PSH 8 A-ACK 16 U-URG 32 --------------------------------------- filter xmas ip() { if(tcp.hdr) { $dabyte = byte(ip.blob,13); if(!($dabyte ^ 63)) { record system.time, ip.src,tcp.sport,ip.dest, \ tcp.dport, "UAPRSF" to xmas_recorder; return; } } } Auch hier kommen einige unbekannte Variablen vor, die ich erstmal erklären werde: - tcp.hdr = wenn tcp.hdr == 0, dann beinhaltet das Paket keinen gültigen TCP Header, bei tcp.hdr == 1 schon - tcp.dport = TCP Destination Port - tcp.sport = TCP Source Port - ip.blob = Inhalt des Payloads eines Pakets (ohne Header) - "UAPRSF" bedeutet das URG,ACK,PSH,RST,SYN und FIN gesetzt sind Bei $dabyte handelt es sich um eine lokale Variable, der byte(ip.blob,13) zugewiesen wird. Zur Erklärung des "byte-Ausdrucks" hier eine kleine Darstellung der TCP Code Bits: | Src Port | Dest Port | Seq Number | ACK Number | HDR Length | Flags |\ URG | ACK | PSH | RST | SYN | FIN | Win Size | Chksum | Urg Off | Opt | Nun erkennt man auch warum man hier 13 Bytes in byte() spezifiziert, denn 13 Bytes reichen aus, um die Flags zu erhalten. Bevor man verstehen kann, wie byte arbeitet, erst mal eine Anmerkung zu blobs. Wie ihr im Chapter 3 des Advanced User Guides nachlesen könnt ist ein blob eine "an arbitrarily sized sequence of bytes". 'byte' gibt ein Byte vom spezifierten Offset eines Blobs zurück, die allgemeine Syntax sieht so aus: byte (str blob_to_search, int offset); Durch das erste Argument wird der Blob spezifiert , der durchsucht werden soll (oben ip.blob) und das zweite Argument gibt den Offset (in 'blob_to_search') des gesuchten Bytes an. Durch 'if(!($dabyte ^ 63))' wird nun noch überprüft ob alle Flags gesetzt sind, man erhält 63 wenn man die Werte der Flags (32+16+8+4+2+1) addiert (sollte es jemanden interessieren, durch ^ wird ein bitweises XOR durchgeführt) Insgesamt bietet N-Code wirklich viele und umfassende Möglichkeiten, neben den bereits genannten. Z.B. ist auch noch möglich: -zu überprüfen ob es sich bei dem Paket um ein IP Paket handelt (ip.is) -die Länge des IP Paketes ermitteln (ip.len) - das verwendete Protokoll desIP Pakets (ICMP,TCP oder UDP) (ip.protocol) - die Checksumme eines ICMP Paketes zu ermitteln (icmp.cksum) - den Inhalt des Payloads der ICMP Pakete (als blob) zu ermitteln (mit icmp.blob) - zu testen ob das Paket einen gültigen ICMP header enthält (icmp.hdr) - zu testen ob das Paket überhaupt ein ICMP Paket ist (icmp.is) - den Typ des ICMP Paketes zu ermitteln, also Echo Reply, Destination unreachable.... - ..... etc ..... Weitere Informationen zu N-Code könnt ihr im Advanced User's Guide einholen: http://www.cs.columbia.edu/ids/HAUNT/doc/nfr-4.0/advanced/ advanced-htmlTOC.html In zukünftigen Versionen dieses Papers, werden wohl wesentlich mehr Filter beschrieben werden, also checkt mal regelmäßig nach neuen Releases dieses Papers ;) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 8. Standards In diesem Abschnitt werde ich euch verschiedene "Standards" vorstellen, also Listen/Vereinbarungen....die von vielen ools/"Experten".... gemeinsam verwendet werden. 8.1. CVE CVE steht für Common Vulnerabilities and Exposures und ist eigentlich nichts anderes als eine Liste , die Namen für vulnerabilites/exposures vorsieht. Dies mag sich zwar auf den ersten Blick komisch anhören, kann allerdings später wichtig werden. Verschiedene Tools benutzen meist verschiedene Ausdrücke für die gefundenen Vulnerabilites...., durch die Verwendung von CVE kann man so eine einheitliche Beschreibung verschiedenster Vulnerabilites/Exposures verwenden, die jeder versteht. Man ist also nicht mehr davon abhängig, dass der andere auch dieses Tool verwendet.... CVE stellt also einen Namen für eine bestimmte Vuln/Exposure bereit, zusätzlich aber auch noch eine Beschreibung, durch die einheitliche (und standardisierte) Beschreibung, tauchen weniger Missverständnisse zwischen Usern verschiedener Systeme auf. CVE definiert hierbei vulnerability als : "those problems that are normally regarded as vulnerabilities within the contect of all reasonable security policies" und exposures als "problems that are only violations of some reasonable security policies". Die Unterscheidung zwischen vulnerability und exposures ist elementar in CVE. Als Beispiel für eine vulnerability , lassen sich z.B. phf, world-writeable password files.... nennen, während ein Beispiel für exposures z.B. die Verwendung von Programmen (die man bekannterweise per Bruteforce angreifen kann) wäre, oder auch die Verwendung von Services , die im allgemeinen auch oft angegriffen werden. Durch die Defintion und diese Beispiele sollte es eigentlich möglich sein, zwischen vulnerabilites und exposures (in CVE) zu unterscheiden. Der grundsätzliche Unterschied besteht v.a. darin , dass vulnerabilites beinhalten das ein Angreifer Möglichkeiten besitzt Kommandos als anderer User auszuführen oder gar Dateien zu lesen/beschreiben, obwohl dies (aufgrund der file-permissions) nicht möglich sein sollte. Exposures hingegen beinhalten, dass ein User weitere Informationen über das System (und dessen Zustand) herausfinden kann, seine Aktivitäten dabei versteckt ablaufen.....Exposures entstehen also aufgrund von falschen Sicherheitseinstellungen, die man allerdings "beheben" kann. Als Vulnerability wird hingegen eher eine Sicherheitslücke verstanden, die unter den "gewöhnlichen" Sicherheitssystemen auftritt. Außerdem soll hier normalerweise auch die Möglichkeit gegeben sein, die Bedrohung durch potentielle Angreifer minimieren zu können (in dem man Permissions checkt....). Doch irgendwie muss die "Liste" auch aktuell bleiben, allerdings wird nicht jede vulnerability oder exposure sofort "aufgenommen". Wenn eine vulnerability / exposure gefunden wird, wird ihr zuerst eine "candidate number" zugewiesen (dies geschieht durch die CNA - Candidate Numbering Authority). Außerdem wird sie auf dem Board vorgeschlagen (vom CVE Editor) und danach drüber geredet ob man die vulnerability /exposure aufnehmen will. Sollte das Board zum Schluss kommen, dass man den Kandidaten (vorerst) nicht aufnehmen will, so wird auf ihrer Website noch der Grund angegeben. Sollte der Kandidat allerdings akkzeptiert werden, wird er in die Liste aufgenommen (und ist somit nun offiziell Teil von CVE). Nun sollte es auch verständlicher sein, das jeder (potentiellen) vulnerability.... erstmal ne "candidate number" zugewiesen wird, da erst danach darüber diskuttiert werden muss, ob der Kandidat aufgenommen werden soll oder nicht. Der vulnerability... wird hier erstmal eine 'candidate number' zugewiesen, damit man zwischen Kandidaten und offiziellen Einträgen in der Liste unterscheiden kann. Jeder Kandidat besitzt 3 grundlegende Felder (die ihn "identifizieren"): -Number -Description -References Die Nummer ist sogesehen der eigentliche Name des Kandidaten, wobei sich diese Nummer aus "Erscheinungsjahr" und einer weiteren Zahl zusammensetzt , die angibt der wievielte Kandidat es dieses Jahr war: CAN-JAHR-wievielter Kandidat des Jahres Wenn nun ein Kandidat vom Board akkzeptiert wird, wird er wie bereits gesagt in die Liste aufgenommen. Damit ist auch verbunden , dass aus 'CAN-YEAR-Candite number' ein 'CVE-YEAR-Candidate number' wird. D.h. an einem Beispiel: Existiert ein Kandidat mit 'CAN-2001-0078' und wird dieser Kandidat akkzeptiert, wird er in die Liste aufgenommen als 'CVE-2001-0078'. Soviel dazu, die offizielle Seite zu CVE ist http://cve.mitre.org/ , dort könnt ihr natürlich zusätzliche Informationen finden... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 9. Beispiele In diesem letzten Teil werden einige IDSs vorgestellt : 9.1. Snort Da Snort sehr weit verbreitet ist und viele Optionen bietet, werde ich es etwas ausführlicher als die anderen Beispiele beschreiben. Grundsätzlich kann sich Snort in drei Modes befinden : Sniffer, Packet Logger und Network Intrusion Detection System. Im Sniffer Modus gibt Snort Pakete auf der Konsole aus, im Packet Logger Modus loggt es sie auf der Festplatte... und im Network Intrusion Detection Modus können Pakete analysiert werden. Zwar gehe ich hauptsächlich auf den letzten Modus ein, aber dennoch hier kurz eine kleine Einführung in Sniffer u. Packet Logger Mode: Sniffer Mode: Im Sniffer Modus könnt ihr euch verschiedene Paketinformationen ausgeben lassen, z.B. TCP/IP Paket Header: [Socma]$ ./snort -v Als Ausgabe werdet ihr lediglich die IP/TCP/ICMP/UDP Headers ausgegeben bekommen. Es gibt eine Vielzahl von Optionen, von denen hier einige aufgezählt werden. -d = gibt auch noch die Paket-Daten aus -e = zeigt auch noch den Data Link Layer Packet Logger Mode: Im Unterschied zum Sniffer Mode, könnt ihr im Packet Logger Mode die Pakete auch auf der Festplatte protokollieren. Ihr müsst lediglich ein Verzeichnis angeben, in das Snort loggen soll und schon schaltet es automatisch in Paket Logger Modus: [Socma]$ ./snort -dev -l ./loggingdirectory #loggingdirectory muss existieren Bei Angabe von "-l" kann es manchmal passieren das Snort die Adresse des Remote-Computers als Verzeichnis holt (in das geloggt wird) und manchmal nimmt es die lokale Host Adresse. Um relativ zum Heimnetzwerk loggen zu können, müsst ihr auf der Kommandozeile spezifizieren, welches das Heimnetzwerk ist: [Socma]$ ./snort -dev -l ./loggingdirectory -h 192.168.1.0./24 Eine weitere Möglichkeit besteht darin, das ganze im TCP-DUMP Format zu loggen: [Socma]$ ./snort -l ./loggingdirectory -b Nun wird auch das gesamte Paket geloggt, nicht nur bestimmte Sektionen, dadurch fällt die Angabe von weiteren Optionen weg. Zwar kann man Programme wie tcpdump benutzen um die File wieder in ASCII -Text zu "übersetzen" , allerdings kann Snort dies auch erledigen: [Socma]$ ./snort -dv -r packetzumuntersuchen.log Network Intrusion Detection Mode: Um in den NIDS Modus zu schalten , könnt ihr ein Kommando wie das folgende verwenden: [Socma]$ ./snort -dev -l ./log -h 192.168.1.0/24 -c snort.conf In diesem Fall ist snort.conf die Konfigurationsdatei. Diese wird benötigt damit Snort weiss woher es seine "Regeln" herbekommt, also wann ein Angriff vorliegt oder nicht, ob eine Anfrage gestattet werden soll.... Die in snort.conf festgelegten Regeln werden dann auf die Pakete angewandt und analysiert. Wird kein Output-Verzeichnis festgelegt, wird standardmäßig /var/log/snort dazu verwendet. Die Ausgabe von Snort hängt auch von den Alert-Modes ab, je nachdem welchen Alert-Modus man verwendet bekommt man mehr oder schneller seine Informationen: -------------------------------------------------------------------------------- | Modus | wie/was wird ausgegeben | -------------------------------------------------------------------------------- | -A fast | Zeitpunkt, Source u. Destination IPs/ports, | | | die eigentliche Alert Nachricht | --------------------------------------------------------------------------------- | -A full | Standardeinstellung | --------------------------------------------------------------------------------- | -A unsock | sendet die Warnungen an einen UNIX | | | socket | --------------------------------------------------------------------------------- | -A none | stellt die Alerts ab | --------------------------------------------------------------------------------- Wie wir wissen kann durch -b im Binary Mode geloggt werden, durch -N wird Paket Logging ganz abgeschaltet. Doch das ist noch längst nicht alles, z.B. kann Snort auch Nachrichten an Syslog schicken. Standardeinstellung ist hier LOG_AUTHPRIV und LOG_ALERT. Zum Senden von Nachrichten an Syslog müsst ihr lediglich "-s" angeben, Beispiele dazu gleich. Des weiteren besteht die Möglichkeit auch Nachrichten an den smbclient oder WinPopUp Warnungen an einen Windows Rechner zu schicken. Um dieses "Feature" nutzen zu können müsst ihr bei der Konfiguration von Snort "-enable-smbalerts" angeben. [Socma]$ ./snort -c snort.conf -b -M MYWINWORKSTATION Oder hier ein Beispiel , das die Anwendung der Alert Modes zeigt: [Socma]$ ./snort -b -A fast -c snort.conf Neben den bereits gesagten Optionen gibt es noch einige, wie die folgenden: -D = starte Snort im Daemon Mode -u usersnort= starte Snort mit der UID 'usersnort' -g groupsnort = starte Snort mit der GID 'groupsnort' -d = protokolliere auch die Daten aus der Applikationsschicht mit Snort bietet viele Optionen, bei Problemen könnt ihr einfach mal "snort -h" eintippen oder in Mailinglisten danach gucken ob euer Problem nicht schon mal aufgetaucht ist. Der folgende Abschnitt handelt von den Snort-Rules, solltet ihr kein Interesse daran haben die bestehenden Rules zu verstehen oder gar eigene zu schreiben, so könnt ihr diesen Abschnitt überspringen. Wie ich am Ende (des Teils über Snort) nochmals erwähnen werde, könnt ihr das SnortUsersManual unter www.snort.org downloaden, dieses dient hier als eigentliche Quelle. Snort Rules: Zum besseren Verständnis von Snort ist auch ein Verständnis der Snort Rules notwendig. Snort benutzt manchmal bestimmte Variablen, die ihr durch Verwendung von 'var' definieren könnt: var: var MY_NET [192.168.1.0/24,10.1.1.0/24] alert tcp any any -> $MY_NET any (flags:S;msg: "SYN packet";) Es gibt allerdings mehrere Möglichkeiten den Variablennamen anzugeben: $variable = definiert die Meta Variable $(variable) = hier wird der Wert der Variable "variable" eingesetzt $(variable:-default) = wenn 'variable' definiert ist, wird hier der wert von 'variable' eingesetzt, ist 'variable' nicht definiert wird hier der Wert von 'default' eingesetzt $(variable:?msg) = setzte den Wert der Variable 'variable' ein oder (wenn nicht definiert) gib die Nachricht 'msg' aus Solltet ihr euch schon mal etwas mit Shellprogrammierung befasst haben, kommen euch diese Dinge sicherlich nicht fremd vor: [Socma]$ shelltest=we [Socma]$ echo hallo $shelltestlt hallo [Socma]$ echo hallo ${shelltest}lt hallo welt Hier ist also die Verwendung von $(variable) in Snort und ${variable} in der Shell gleichbedeutend. Auch für die anderen gibt es Äquivalente (oder ähnliche Ausdrücke) in der Shellprogrammierung: [Socma]$ shelltest = bash [Socma]$ echo ${shelltest:-nobash} bash [Socma]$ echo ${notdefined:-nobash} nobash Also auch die Verwendung des Ausdrucks $(variable:-default)' unterscheidet sich nur in der Tatsache das auf der Shell { und } anstatt ( und ) benutzt werden. Der letzte Ausdruck existiert auch auf der Shell: [Socma]$ shelltest = bash [Socma]$ echo ${shelltest:?"dann eben csh"} bash [Socma]$ echo ${nichtdefiniertevariable:?"nicht definiert oder null"} nicht definiert oder null Dieser kleine Exkurs sollte lediglich "Wissen verknüpfen", zumindest ich konnte mir die Schreibweisen in Snort so schneller einprägen, da ich einfach an die (mir bekannten) Dinge auf der Shell gedacht habe. Viele Kommandozeilenoptionen...können in der Konfigurationsdatei eingestellt werden. Hierzu wird 'config' verwendet : config [: ] Die wichtigsten 'directiven' wären : alertfile = ändert die Datei in die Alerts gespeichert werden daemon = Prozess als Daemon starten ( -D) reference_net = setzt das Heimnetzwerk (-h) logdir = setzt das Logging Verzeichnis (-l) nolog = Logging wird ausgeschaltet set_gid = ändert die GID (-g) chroot = chroot'ed in das angegebene Verzeichnis (-t) set_uid = setzt die UID (-U) Wenn ihr z.B. die alertfile ändert wollt in z.B. "mylogs", macht ihr das so: config alertfile : mylogs Nun aber zurück zu den eigentlichen Regeln (hier eine beispielhafte ftp.rules (Ausschnitt)): alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT overflow";\ flags: A+; content:"|5057 440A 2F69|";classtype:attempted-admin; sid:340;rev:1;) Grundsätzlich bestehen Snort-Rules aus zwei Teilen : dem rule header und den rule options. Hierbei gibt der rule header Auskunft über folgende Dinge: - Source u. Destination IP Adressen - Protokoll - die Aktionen die von der Regel eingeleitet werden In der obigen ftp-rule wäre der rule header der folgende Teil: Aktion source ip destination ip | | | alert tcp $EXTERNAL_NET any -> $HOME_NET 21 | | | Protokoll From any port Port Hier ran sieht man , dass der rule header bis zur ersten ( geht und danach die rule options beginnen. Es gibt mehrere mögliche Aktionen (in diesem Falle alert) die eingeleitet werden können, sollte die Snort-Rule etwas auffälliges feststellen: -alert = je nachdem welche alert-methode (s.o. - standard ist alert full) verwendet , wird ein Alert erzeugt und das entsprechende Paket geloggt -log = hierbei wird einfach nur das Paket geloggt -pass = führt dazu das das Paket ignoriert wird -activate = erzeugt einen Alert und kehrt dann zu einer anderen dynamischen Snort-Rule zurück (mehr dazu gleich) -dynamic = führt dazu, dass die Regel solange "inaktiv" bleibt , bis sie von einer anderen Regel aktiviert wurde, danach arbeitet es wie log (s.o.) Das zweite Feld (Protokoll - hier tcp) spezifiziet welches Protokoll "beobachtet" (analysiert) werden soll. Möglich sind hier : tcp ,udp , icmp und ip (allerdings ist es nicht unwahrscheinlich das in Zukunft auch andere wie ARP,GRE....verfügbar sind). Im Zusammenhang mit dem nächsten Feld (source ip) trifft man öfters auch auf den ! - Operator (Negationsoperator). alert tcp !$EXTERNAL_NET any -> $HOME_NET 21 Als Folge der Verwendung des Negationsoperators wird nun mehr jedes Paket das nicht von $EXTERNAL_NET kommt geloggt. Des weiteren besteht die Möglichkeiten mehrere IP Adressen anzugeben, also Listen von IP Adressen. Dafür müsst ihr lediglich die entsprechenden Adressen mit Komma voneinander trennen und mit [ ] umklammern. alert tcp ![ip adresse,ip adresse] any -> .... Eine weitere Alternative stellt die Verwendung von "any" dar, womit jede IP Adresse einbezogen ist. log tcp any any -> ... Der letzte Teil des rule headers ist die Spezifikation des Ports, im obigen Beispiel also ftp. Man kann nicht nur einen bestimmten Port ueberwachen, sondern auch bestimmte Bereiche (also auch mehrere Ports). Hier die verschiedenen Möglichkeiten: :portnumber -> alle ports kleiner gleich portnumber portnumber: -> alle ports größer gleich portnumber fromportnumber:toportnumber -> alle ports zwischen fromportnumber und toportnumber (und diese mit einbezogen) Natürlich lässt sich auch hier wieder der Negationsoperator angeben, was zur Folge hätte das alle außer die angegebenen Ports "überwacht" werden würden, z.B. !:21 -> alle ports die nicht kleiner gleich 21 sind Etwas was noch nicht direkt erläutert, die ganze Zeit aber verwendet wird, ist der Direktionsoperator "->". "Source" -> "Destination" Doch es gibt auch eine andere Variante, <> : "Source" <> "Destination" Dies führt dazu das Snort sowohl Source als auch Destination nach der Adresse.... durchsucht. Wie ich bereits eben gesagt habe, gibt es die Aktion 'activate' , die dazu führt das ein Alert erzeugt wird und dann zu einer anderen dynamischen Snort-Regel zurückkehrt. Sollte eine bestimmte Regel die jeweiligen Aktionen durchgeführt haben kann es eine andere aktivieren. Grundsätzlich unterscheiden sich normale Regeln und "activate rules" nur in der Tatsache das ein bestimmtes Feld bei activate rules angegeben werden muss : "activates". Dynamische Regeln hingegen arbeiten wie log (s.o.) nur das hier "activated_by" angegeben wird. Des weiteren existiert ein weiteres Feld, dass angegeben werden muss :"count". Wenn die "activate rule" ihre Arbeit getan hat, wird die dynamische regel "aufgerufen", allerdings nur für "count" Pakete (also wenn count = 40, dann für 40 Pakete). activate tcp !$HOME_NET any -> $HOME_NET 143 (flags : PA; \ content : "|E8C0FFFFFF|\bin|;activates : 1; msg : "IMAP buf!";) dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by : 1; \ count : 50;) Einige Optionen (also die rule options) sind noch nicht bekannt, daher werde ich jetzt auf diese eingehen, später erscheint euch diese Regel dann auch sinnvoller. Beachtet im obigen Beispiel bitte die Felder activates und bei der dynamischen Regel activated_by (und count). Die erste Regel ruft nach erledigter Arbeit die dynamische Regel auf , dies sieht man auch daran das in der dynamischen Regel activated_by : 1 steht. Nun aber zum zweiten Teil der Snort-Rules, den rule options. Nimmt man nochmals die erste ftp.rule: alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT overflow";flags: A+; content:"|5057 440A 2F69|";classtype:attempted-admin; sid:340; rev:1;) In diesem Falle wäre die rule option (der rule header geht wie gesagt nur bis zur ersten ")" ) : (msg:"FTP EXPLOIT overflow";flags: A+; content:"|5057 440A 2F69|";\ classtype:attempted-admin; sid:340; rev:1;) Zwar gibt es 34 Keywords, allerdings werde ich nur die (wichtigsten und/oder gebräuchlichsteen) erläutern. Derjenige der eine Übersicht über alle möglichen Keywords haben möchte, sollte ins SnortUsersManual schauen, dort stehen alle erklärt. msg - gibt die alert-messages aus und loggt die Meldungen im Paket Logger Modus logto - loggt die Pakete in einer bestimmten Datei dsize - vergleicht die Paketgröße mit einem anderen Wert flags - überprüft die TCP Flags nach bestimmten Werten content - sucht nach nem bestimmten Muster/String in einem Paket content-list - sucht nach mehreren Mustern/Strings in einem Paket nocase - Groß-Kleinschreibung des gesuchten Strings werden nicht beachtet react - aktive Response (blockt Webseiten) sid - Snort rule id classtype - teilt die potentiellen Angriff in bestimmte Gruppen von Angriffen ein priority - regelt die "Strenge" So weit so gut, doch was genau machen die einzelnen rule options ? msg: Auf 'msg' trifft man sehr häufig beim Durchstöbern der rules, da diese Option dafür verantwortlich ist, dass Alerts ausgegeben werden (oder auch das geloggt wird). msg:""; Hierbei ist "" die jeweilige Nachricht die in die alertfile geschrieben wird/ausgegeben wird..... logto: Jedes Paket, auf das die Rule zutrifft, wird in einer speziellen File geloggt. logto: ""; In diesem Falle ist "" die Datei, in die diese Paket geloggt werden. dsize: Hiermit wird die Größe des Pakets bestimmt. Wenn man weiss das ein bestimmter Service einen Buffer (einer bestimmten Größe) kann man diese Option verwenden, um möglichen Bufferoverflows entgegen zu wirken. Verglichen mit 'content' ... ist es um einiges schneller, daher wirds zum Testen von BufferOverflows auch eher benutzt. dsize: [>|<] ; Die beiden optionalen Operatoren > und < drücken aus, dass die Größe des Pakets kleiner,bzw. größer als dieser Wert sein sollte.. flags: Hiermit wird getestet welche Flags gesetzt sind. Momentan sind 9 Flags in Snort verfügbar: F FIN S SYN R RST P PSH A ACK U URG 2 Bit 2 reserviert 1 Bit 1 reserviert 0 keine TCP Flags gesetzt Daneben gibt es auch noch logische Operatoren, die zusätzliche Kriterien zum Testen der Flags spezifieren können: + ALL flag = Treffer bei allen spezifierten (und auch anderen) Flags * ANY flag = Treffer bei allen spezifierten Flags ! NOT flag = wenn die spezifierten Flags nicht gesetzt sind Allgemein wird das 'flags' Keyword so verwendet: flags: ; Die reservierten Bits können verwendet werden um ungewöhnliches Verhalten, wie z.B. IP stack fingerprinting Versuche zu erkennen. content: Einer der wohl (neben msg) am häufigsten gebrauchten Keywords ist 'content'. Hiermit kann der Payload Pakete nach bestimmten Inhalt durchsucht werden. Sollte der spezifiezierte Inhalt gefunden werden, werden bestimmte Aktionen gegen den User eingeleitet. Wenn der Inhalt (der nach content spezifiert wird) in dem Payload des Pakets vorkommt, wird der Rest der jeweiligen Snort-Rule ausgeführt. Ohne Angabe von nocase (s.u.) wird auch Groß/Kleinschreibung beachtet. Der Inhalt , nach dem der Payload durchsucht werden soll, kann sowohl binäre daten, als auch text enthalten. Binäre Daten werden durch | | eingeschlossen und als Bytecode dargestellt. Der Bytecode stellt die binären Informationen als hexadezimale Zahlen dar... Auch im Zusammenhang mit diesem Keyword kann man den Negationsoperator (!) geschickt anwenden, so dass man z.B. einen alert... ausgibt wenn ein Paket nicht einen bestimmten Text...enthält. content: [!] ""; Die Angabe von ! ist wie gesagt optional, also nicht zwingend. alert tcp any any -> 192.168.1.0/24 143 (content: "|90C8 C0FF FFFF|/bin/sh";\ msg: "IMAP buffer overflow";) Wie in dieser Regel zu sehen ist, werden die binären Daten durch die | | umschlossen (wie oben bereits erwähnt), danach lässt sich normaler Text spezifieren. Ihr solltet euch auch einmal die Beschreibung von 'offset' und 'depth' im SnortUsersManual anschauen, da diese auch öfters in Verbindung mit 'content' gebraucht werden. content-list: Dieses Keyword arbeitet so ähnlich wie 'content' mit dem Unterschied das man mehrere Strings.... angeben kann, nach denen das Paket durchsucht werden soll. Man schreibt die entsprechenden Hexazahlen,Strings.... in eine Datei und spezifiziert dann bei Verwendung von 'content-list' die Datei in der die Wörter stehen. Zu beachten ist hier, das die Strings ... untereinander (jeder String in einer Zeile) stehen muss, z.B. "kinderporno" "warez" ..... Danach kann man durch z.B. 'content-list: [!] "";' diese Datei "durchsuchen". Auch hier kann man natürlich optional ! angeben, hat aber auch die gleiche Wirkung wie bei 'content'. nocase: Diese rule option spielt eine wichtige Rolle im Zusammenhang mit 'content' keywords. Diese achten normalerweise auf Groß/Kleinschreibung, durch Verwendung von 'nocase' wird aber nicht mehr explizit auf Groß/Kleinschreibung kontrolliert: alert tcp any any -> 192.168.1.0/24 21 (content: "USER root";\ nocase; msg: "FTP root user access attempt";) Ohne Verwendung von 'nocase' würde nur nach 'USER root' durchsucht, da aber 'nocase' angegeben wurde zählt die Groß/Kleinschreibung nicht mehr... react: Wenn man ein Paket nach einem bestimmten Inhalt durchsucht (durch 'content' oder 'content_list') und einen Treffer feststellt, kann 'react' dazu verwendet werden darauf zu reagieren. Normalerweise werden z.B. bestimmte Seiten die ein User besuchen will geblockt (Pornoseiten...). Durch Flex Resp ist es möglich Verbindungen zu beenden oder Warnungen an den Browser zu schicken. Folgende Optionen sind möglich/gültig: block - schließt die Verbindung und sendet einen Hinweis raus warn - sendet eine sichtbare Warnung (bald verfügbar) Diese sog. 'basic arguments' können dann noch durch weitere Argumente (sog. 'additional modifiers') ergänzt werden: msg - der text der durch das Keyword 'msg' gesendet wird, wird in den Hinweis an den User einbezogen proxy : - hier wird der proxy port dazu verwendet den Hinweis zu versenden (auch bald verfügbar) react : ; Das 'react' Keyword wird am Ende der rule options eingefügt, und kann z.B. so verwendet werden: alert tcp any any <> 192.168.1.0/24 80 (content-list: "adults"; \ msg:"Diese Seite ist nicht für Kinder gedacht !"; react: block, msg;) sid: 'sid' oder ausformuliert Snort rules IDentification wird benutzt um "einzigartige" Snort rules zu identifizieren. Dadurch ist es "output plugins" erlaubt/möglich jede Regel leicht zu identifizieren. Allerdings gibt es verschiedene Bereiche von Sid's: < 100 = für die Zukunft reserviert 100-1 000 000 = Regeln die zusammen mit Snort "kommen" > 1 000 000 = wird für lokale Regeln verwendet sid-msg.map enthält ein mapping der msg tags zu sid's. Diese wird von post-processing benutzt um einer id eine Warnung zuzuordnen. sid: ; alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 \ (msg: "WEB-IIS file permission canonicalization"; uricontent:\ "/scripts"..%c1%9c../"; flags: A+;nocase;sid: 983;rev:1;) classtype: Durch 'classtype' könnt ihr die Attacken in diverse Gruppen von Attacken unterteilen. In den Regeln könnt ihr dann selbst bestimmen welche Priorität ein potientieller Angriff haben soll, bzw. zu welcher Gruppe der Attacken er gehört .Regeln die in der Konfigurationsfile eine Einstufung "haben", bekommen dort automatisch auch eine Standard-Priorität zugewiesen. classtype: ; Die Einstufungen der Regeln werden in der classification.config definiert. Dort gilt folgende Syntax: config classification: ,, Welche Gruppen von Attacken es gibt, könnt ihr im nächsten Teil sehen, der Beschreibung von 'priority'. priority: Durch dieses Keyword könnt ihr euren Regeln eine "Security-Stufe" zuweisen, wie schwer also ein potentieller Angriff sein würde. Je höher die Priorität der Regel, desto größer das potentielle Sicherheitsrisiko. Verbunden mit den bereits besprochenen 'class types' lassen sich die Prioritäten besser verstehen: Class type Beschreibung Priorität --------------------------------------------------------------------------------- not-suspicious - Jeglicher "unauffälliger" Verkehr 0 unknown - Unbekannter Verkehr 1 bad-unknown - Potentiell "schlechter" Verkehr 2 attempted-recon - Attempted Information Leak 3 successful-recon-limited - Information Leak 4 successful-recon-largescale - Large Scale Information Leak 5 attempted-dos - Versuchte DoS-Attacke 6 successful-dos - Erfolgreiche DoS-Attacke 7 attempted-user - Versuch User-Privilegien zu erhalten 8 unsuccessful-user - Nicht erfolgreicher Versuch 7 User-Privilegien zu erhalten successful-user - Erfolgreicher Versuch 9 User-Privilegien zu erhalten attempted-admin - Versuch Admin Rechte zu bekommen 10 successful-admin - Erfolgreicher Versuch Admin 11 Rechte zu bekommen --------------------------------------------------------------------------------- Wie bereits erwähnt bedeuten höhere Prioritäten auch höhere Sicherheitsrisiken, sollte es einem User gelingen Admin Rechte zu bekommen ist dies die schwerwiegenste Attacke. alert tcp any any -> any 80 (msg: "WEB-MISC phf Versuch";\ flags: A+;content: "/cgi-bin/bash";priority:10;) Das ganze Thema 'Rules' ist zugegebenermaßen sehr umfassend, doch nicht soo schwer. Schaut euch einfach diverse rules an, guckt im Manual oder hier nach was die einzelnen bedeuten und nach ner gewissen Zeit erscheinen euch auch die "Rulemonster" verständlich ;) Bezugsquelle für Snort und Dokumentationen findet ihr unter http://www.snort.org . Dort findet ihr einige interessante .pdfs , z.B. das Snort Users Manual, die Hauptquelle für diese Beschreibung von Snort. 9.2. bofh Leider ist momentan nur die Windows-Version verfügbar, so dass ich noch warte bis der Unix-Source verfügbar ist....... 9.3. LIDS Spätestens seit stealth's Paper (und Sources) und dem LIDS-Hacking-HOWTO wissen wir , dass LIDS nicht wirklich die Sicherheit auf dem Rechner erhöht, sondern in manchen Situationen eher ein Rootkit ist ;) Aber erst einmal zum Konzept und anschließend zu den (scheinbaren) Stärken und Schwächen von LIDS. Ursprünglich wurde es entwickelt um z.B. wichtige Systemdateien zu schützen und bestimmte Prozesse für die User unsichtbar zu machen. Außerdem sollte es nicht gestattet sein einfach so Module einzubinden, die notwendigen Module werden beim Starten des Systems eingebunden... Da es (wie schon gesagt) ein LIDS-Hacking-HOWTO u. Stealth's Paper gibt , die die Arbeitsweise und Schwächen von LIDS erläutern, werde ich hier nur kurz die wichtigsten Dinge erwähnen. Den Link zu den beiden Texten findet ihr am Ende dieses Abschnitts. Eine Hauptaufgabe von LIDS ist es, das Dateisystem zu schützen. Um (wichtige) Dateien schützen zu können, werden die entsprechenden Dateien / Verzeichnisse erst einmal in Gruppen unterteilt: -Read Only = Die Datei / das Verzeichnis ist nur lesbar, es sind keine Änderungen erlaubt -Append Only = In solchen Dateien....ist es nur erlaubt Inhalt "anzuhängen" -Exception = diese Dateien .... sind nicht geschützt -Protect (un)mounting = erlaubt / verbietet jemandem ein Dateisystem zu (un)mounten Um "wirklichen" Schutz bieten zu können, werden einige Systemaufrufe manipuliert, die sicherstellen das die Protections eingehalten werden. (z.B. sys_open(), sys_mknod(), ...) Desweiteren verhindert LIDS , dass bestimmte Prozesse gekillt werden können (oder sichtbar sind). Sinn u. Zweck des ganzen ist es zu verhindern, dass der Angreifer gewisse Prozesse sieht, die ihn möglicherweise beobachten könnten. Ein 'ps -ax..' Aufruf sollte also unsere Prozesse nicht anzeigen. Damit man den Prozess auch wirklich verstecken kann, wird er als 'PF_HIDDEN' markiert, wenn ps dabei ist die Informationen über die Prozesse auszugeben und sieht das ein Prozess mit 'PF_HIDDEN' markiert ist, wird es diesen Prozess nicht anzeigen. Doch das alleine genügt noch nicht um den Prozess wirklich zu verstecken, denn momentan hätte er immer noch einen Eintrag im Proc-Filesystem (/proc), also manipuliert LIDS auch diese "Funktion", damit der Prozess nicht im /proc Verzeichnis erscheint. Daneben besteht noch die Möglichkeit die Rechte eines Prozesses zu beschränken, anhand von Capatibilites. Wenn z.B. CAP_CHROOT auf 0 gesetzt ist, hat der Prozess nicht mehr die Möglichkeit chroot anzuwenden (siehe auch /usr/src/linux/include/linux/capatibilites.h). Außerdem besitzt LIDS die Möglichkeit in 2 Sicherheitsstufen zu laufen, 'security' und 'none_security'. Um zwischen 'security' und 'none_security' zu unterscheiden, gibt es die globale Variable 'lids_load'. Standardmäßig ist diese auf '1' voreingestellt, dies bedeutet das standardmäßig LIDS im 'security' Modus läuft, d.h. die Einschränkungen...gelten. Wenn man beim Start 'security=0' angibt (LILO-Prompt) so wird auf 'none_security' geschaltet, was bedeutet das jegliche Sicherheitsüberprüfungen, Einschränkungen....abgeschaltet sind. Mit lids_load == 0, läuft der Rechner also so, als wäre LIDS gar nicht installiert. Des weiteren besteht die Möglichkeit die Sicherheitsstufe durch 'lidsadm -S' online zu ändern , dann muss allerdings ein Passwort spezifiert werden. Doch LIDS bietet auch die Möglichkeit die Firewall Regeln zu schützen, man sollte dafür aber CONFIG_LIDS_ALLOW_CHANGE_ROUTES anschalten und CAP_NET_ADMIN "ausschalten". Möchte jemand die Firewall Regeln ändern, muss er zuerst CAP_NET_ADMIN wieder anschalten, dadurch wird verhindert das jeder die Regeln ändern kann. Zusätzlich besteht noch die Möglichkeit Sniffer "abzuschalten" und einen Port Scan detector im Kernel einzubauen. Auch LIDS bietet diverse "Response-Options" (siehe Kapitel über Response), z.B. die Benachrichtigung über den Pager, per SMS an den Administrator zu verschicken. Alles in allem sehr viele Möglichkeiten, doch Stealth hat in seinem Paper auch gezeigt wie man LIDS missbrauchen kann um es zu einem verfügbar: http://www.securitybugware.org/Linux/4997.html Das LIDS Howto könnt ihr hier runterladen : http://www.lids.org/lids-howto/lids-hacking-howto.html 9.4. COLOID COLOID ist die Abkürzung für Collection of LKMs for Intrusion Detection und wurde vor einiger Zeit von mir ins Leben gerufen. (Die folgenden Punkte beschreiben die Umsetzung des alten Konzepts von COLOID, ich stelle gerade das Konzept etwas um...) Nur was umfasst COLOID u. was ist noch geplant ? Momentan ist eigentlich nur prev_exec.c einigermaßen vorangeschritten, also besser gesagt entwickelt wurden. Dieses LKM verhindert die Ausführung von bestimmten Binaries (in meinem Source habe ich den Gnu C Compiler - GCC - genommen) zu bestimmten Zeiten. Es wird also im Source definiert wann die Ausführung verboten sein soll, wobei möglich ist auf Minuten genau den Zeitabschnitt anzugeben. Führt jetzt ein User GCC zu dieser Zeit aus, wird lediglich die Ausführung 'geblockt', d.h. GCC wird nicht ausgeführt. Sollte der User GCC zur "erlaubten" Zeit ausführen werden die Argumente überprüft und nach .c - Files durchsucht. Sinn u. Zweck des Ganzen ist es, den Source (den jemand kompilieren möchte) nach "gefährlichen Funktionen" zu durchsuchen. Voreingestellt sind hierbei 'scanf' und 'strcpy' , allerdings ist es auch möglich weitere Funktionen...hinzuzufügen. Wie bereits gesagt durchsucht nun das LKM den jeweiligen Source und sollte es auf eine der Funktionen treffen wird die Ausführung von GCC verhindert. Zusätzlich wird in eine Logfile geschrieben und ein 'beep' erzeugt . Um euch die Wirkungsweise von 'prev_exec' zu zeigen, hier ein beispielhaftes Szenario (vorrausgesetzt prev_exec ist schon geinsmodet): [Socma]$ pwd /root/c/devices [Socma]$ cat s.c /* hier ein sehr popeliges und schlecht programmiertes Beispiel das zeigen soll wie prev_exec funktioniert */ #include int main(void) { char so[10]; scanf("%s",so); return 0; } [Socma]$ gcc -Wall -ggdb s.c -o s /usr/bin/gcc: Keine Kind-Prozesse [Socma]$ #eben sollte Ton zu hören sein Eine mögliche Logfile (die als Resultat dieser Session erzeugt werden könnte) sieht momentan noch so aus: Incident: Usage of dangerous function More information: User tried to compile a source in which he used scanf Security Level : 1 File: /root/c/devices/s.c UID: 0 GID: 0 Time: 12:38 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Wie ihr seht wird ein Incident angegeben, also was der Grund dafür war das in die Logfile geschrieben wurde. More Information gibt momentan nur die Funktion an die zuerst gefunden wurde , im obigen Beispiel hat root also probiert 'scanf' zu verwenden. Des weiteren wird eine Sicherheitsstufe angegeben, wie schwerwiegend der Vorfall also war. Hier gilt ähnlich wie bei Snort das höhere Prioritäten auch höhere Sicherheitsrisiken bedeuten. Anschließend wird die Datei angegeben, die der User versucht hat zu kompilieren, in diesem Falle also /root/c/devices/s.c, evtl. erscheint hier auch nur s.c wenn der User z.B. 'gcc /root/c/devices/s.c ..." angegeben hat. UID und GID sollten eigentlich klar sein, also die User ID und Group ID des Users der versucht hat den Source zu kompilieren. Abschließend noch die Angabe des Zeitpunktes, dieser könnte natürlich auch noch verfeinert werden (Tag...). Allerdings kann der User nicht unbegrenzt oft GCC ausführen, sondern nur (beispielsweise wie im Source) 5 mal in der Stunde. Hier besteht also die Möglichkeit die Ausführung diverser Programme zu beschränken....Jeder weitere Versuch das Programm zu starten würde dazu führen, dass es schlicht und ergreifend nicht ausgeführt wird ;) Zwar funktioniert es, allerdings müssen hier noch einige Dinge verbessert werden, z.B. das unter 'more information' alle Funktionen aufgeführt werden, nicht nur die erste (der "gefährlichen") die gefunden wird. Außerdem gibt es noch einige (kleinere ?) Mängel, an diversen Punkten... In Planung ist momentan auch noch ein weiteres LKM 'anom_detection' , das die bereits erläuterte Anomaly Detection verwenden wird. Eigentlich sind es zwei LKMs die zu diesem Bereich gehören : 1) Anomaly_Detection.c das die Datenbank normaler Useraktivitäten erzeugt und 2) Misuse_Detect.c das später (mit der Datenbank als "Fundament") kontrolliert ob das Verhalten der User von dem normalen (in der Datenbank protokollierten) Verhalten abweicht. Geplant ist, dass dieses LKM folgende Dinge "überprüfen" wird: ------------ ------------ ------------ ------------ Wie oft hat der User die folgenden Programme/Kommandos ausgeführt : -su -login -chmod -chown -insmod -ps -lsmod -rm -last -lastlog -ftp Wann hat er die folgenden Programme/Kommandos gestartet: - login - su Bzw. wann hat er normalerweise den PC gestartet u. shutdown ausgeführt.... Sonstiges: Wie oft hat er (versucht) die folgenden Dateien zu öffnen: - /etc/passwd - /etc/group - /etc/shadow - /etc/ftpusers - /etc/ftpgroups - /etc/ftpaccess - /etc/hosts.allow - /etc/hosts.deny - /etc/inetd.conf -..... Wie oft hat er Programme ausgeführt, bei denen das SUID-Bit gesetzt war ? .... ------------ ------------ ------------ ------------ Aufpassen muss man hier nur bei der Spezifizierung welche Dateien man beobachten möchte (wie oft er sie geöffnet hat). Wählt man hier zu viele Dateien, so leidet die Rechnerperformance zu sehr, als dass ansatzweise vernünftiges arbeiten am PC kaum möglich wäre. Noch befindet sich dieses LKM in Entwicklung, bzw. die ersten Dinge sind zwar schon umgesetzt, allerdings dauert es bis es richtig funktionieren wird. Version 0.1 der static measures (anomaly detection) wurde online gestellt (Releases -> staticm)... Das gesamte Projekt befindet sich noch im Anfangsstadium, schaut einfach ab und zu mal auf meiner Seite vorbei, und seht ob ich evtl. in der Zwischenzeit neue Dinge releast hab. Die neusten Releases rund um COLOID findet ihr unter http://www.ultimate-science.de/Releases.htm. Solltet ihr daran interessiert sein, mitzuarbeiten, schreibt mir einfach ne Mail oder kommt in #Coloid (irc.euirc.net) , vielleicht bin ich zu dem Zeitpunkt ja auch gerade im Channel.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 10. Abschließende Worte Solltet ihr noch irgendwelche Ideen zum Inhalt des Papers ... haben, schreibt mir bitte ne Mail: Socma@gmx.net . Für weitere Anregungen, Lob, Kritik.... könnt ihr mich natürlich auch anschreiben. Wie bereits einmal im Paper erwähnt , existiert ein Channel (#Coloid) im irc.euirc.net, dort könnt ihr auch Fragen stellen (falls irgendwann jemals jemand diesen Channel besuchen sollte). Referenzen (neben denen, die bereits im Text erwähnt wurden): [1] http://online.securityfocus.com/infocus/1524 [2] http://online.securityfocus.com/infocus/1534 [3] http://online.securityfocus.com/infocus/1544 [4] http://online.securityfocus.com/infocus/1232 [5] http://www.entercept.com/products/entercept/whitepapers/ downloads/systemcall.pdf [6] http://www.computec.ch/dokumente/intrusion_detection/ angriffsmoeglichkeiten_auf_okenas_stormwatch/angriffsmoeglichkeiten_ auf_okenas_stormwatch.doc Thanx flying out to : - Baegsch (fürs Betalesen) - Svoern (fürs Betalesen und hilfreiche Anregungen) - marc ruef (hilfreiche Anregungen und Verbesserungen) - pr1 (fürs Betalesen) - Deknos (ebenfalls fürs Betalesen) Greetz going to: - UNF (esp. pr1 && Anthraxx) - csec (Baegsch,sticky_bit,bj, Gemfire....) - BS,maze,Beelzebub,zOrgXX ------------------------------------------------------------------------------- -Socma- Socma@gmx.net UIN = 123638295 Do not redistribute this article modified and give proper credit to Socma if you want to redistribute it. This "note" has to remain below the paper anyway. The newest version of this article can be found at http://www.ultimate-science.de