IT-Sicherheitsmanagement. Teil 6: Intrusion Detection Systeme

Transkript

1 IT-Sicherheitsmanagement Teil 6: Intrusion Detection Systeme

2 Literatur [6-1] Spenneberg, Ralf: Intrusion Detection für Linux-Server. Markt&Technik, 2003 [6-2] Plötner, Johannes; Wendzel, Steffen: Netzwerk-Sicherheit. Galileo- Computing, 2005 [6-3] Jones, K.; Shema, M.; Johnson, B.: Das Anti-Hacker-Toolkit. mitp, 2003 [6-4] Hatch, B.; Lee, J.; Kurtz, G.: Das Anti-Hacker-Buch für LINUX. mitp, 2001 [6-5] anonymous: linux hacker's guide. Markt&Technik, 2000 [6-6] [6-7] [6-8] Sicherheit/Themen/Sicherheitskomponenten/IntrusionDetectionSyste meids/intrusiondetectionsystemeids_node.html 2

3 Begriffe II Intrusion Detection System = IDS = Software, die einen aktuellen Angriff sowie früher erfolgte Angriffe feststellt und behandelt Intrusion Prevention System = Software, die einen Angriff unmittelbar erkennt und stoppt sowie im Vorfeld jeden Angriff verhindert Ein derartiges System ist wohl der Traum! Aber wohl nicht zu realisieren... Nüchtern betrachtet gehört dieser Begriff ins Marketing. 3

4 Aufgaben I Feststellen Erkennen aktuell laufender Angriffe Erkennen früher erfolgter Angriffe Feststellen von nicht erlaubten Modifikationen und Zugriffen Analyse der Probleme und deren Einschätzung Reagieren "Unterbrechen" betroffener Verbindungen, Abschotten Beenden betroffener Prozesse, z. B. Ausloggen und Sperren des betreffenden Logins Berichten bzw. Melden Zusammenfassung verschiedener Datenbestände Erstellung Berichte unterschiedlicher Detailliertheit Versenden von Alarm-Nachrichten, z.b. Mail, SMS 4

5 Aufgaben II Zum Feststellen eines Problems gehört (eigentlich): 1. Was wurde wie modifiziert? 2. Wer hat die Modifikation durchgeführt? 3. Warum wurde gerade dies so modifiziert? 4. Was passierte anschließend? 5. Welche sonstigen Auswirkungen hatte der Vorfall? 6. Wie kann dies in Zukunft verhindert werden? Es ist klar, dass nur die Punkte 1. und 4. von einer Maschine geklärt werden können, eventuell noch 2. aber den Rest kann nur ein Mensch leisten, der allerdings mit den notwendigen Daten versorgt werden muss. 5

6 Anforderungen an ein IDS Jede Analyse muss (gerichtlich) nachvollziehbar sein. Für jeden Alarm müssen die Rohdaten gespeichert bleiben. Berichte bzw. Zusammenfassungen sind Interpretationen, die falsch sein können. Es müssen dazu auch die Konfigurationen genau aus der betreffenden Situation gespeichert sein. Alarmierungsschwellen sowie Filter müssen konfigurierbar sein. Vertraulichkeit der Daten muss realisiert sein, insbesondere bei Bezug auf Personen, z. B. durch Pseudonymisierung. Das IDS darf nicht als Mittel für einen DoS-Angriff benutzt werden können. Kein heutiges IDS erfüllt diese Anforderungen vollständig. 6

7 Computer Forensik Forensik = engl. forensics = Fachgebiet zur Erforschung von Verfahren zur Beweissicherung bei gerichtlich/strafrechtlich relevanten Vorgängen Forensische Werkzeuge werden meist nach Feststellen eines Schadenfalls, aber auch während eines Angriffs angewendet. Dies ist ein Nebengebiet der IDS, wobei weitere bestimmte Bedingungen eingehalten werden müssen: Erfassen von relevanten "Spuren" Beweis der Originalität der Spuren, d.h. dass Spuren nicht nachträglich verändert oder geschaffen wurden Nachweis der Herkunft der Spuren 7

8 Policy I Die schriftliche Festlegung einer Politik (Policy) ist ein sehr wichtiger Schritt, denn ohne Vereinbarungen ist unklar, was eigentlich unsicher ist oder was nicht erlaubt ist: Policy = Politik = Sicherheitsrichtlinie oder Regelsystem, das den Umgang mit der EDV aus dem Blickwinkel der Sicherheit festlegt Eine Policy definiert u.a.: was ein Angriff ist, wie der Schutz vor Angriffen gestaltet werden soll, wer was tun darf bzw. muss (Rechte/Pflichten) Dies betrifft häufig Rollen innerhalb von Organisationen. Organisatorische Aspekte der Sicherheit, z.b. Aufgaben des Sicherheitsbeauftragten 8

9 Policy II - Beispiele Folgende Themen sollten durch Richtlinien behandelt sein (Beispiele): Physikalische Sicherheit: Schlüssel zu Räumen, Anweisung immer sofort abzuschließen Authentifizierung: Passwörter und deren Länge, Dauer der Benutzung, Benutzung von Token Akzeptierte Benutzung: Ist das Installieren von Software durch Mitarbeiter erlaubt? Zugriff auf USB Behandlung externer Medien: Erlaubnis zum Mount? Fernzugriffe: Einloggen von Zuhause? Prävention: Bewusstsein der Mitarbeiter Policies haben im Wortlaut und in der Bedeutung verschiedene Ebenen: Geschäftsführung, Top-Level-Management Abteilungs-/Bereichsleitung, Mittleres Management Technische Ebene (Beispiele von oben) 9

10 Policy III - Prävention (Beispiele) Abschalten ungenutzter Modem-/ISDN-Zugänge von außen Abhängen ungenutzter (Patch-)Dosen Physikalischer Schutz von Kabeln Abschalten ungenutzter Dienste bzw. Server Aber auch: Ausbildung des Personals in Sachen Social Engineering Gute Bezahlung von Administratoren Gute Qualifikation 10

11 Feststellen von Anomalien I Anomalie = außergewöhnliches Verhalten (von Software) Anormal ist ein Verhalten, das sich vom "Durchschnitt" wesentlich unterscheidet. Eine heuristische Funktion eines IDS ist die Feststellung von Anomalien, Vorgehen: 1. "Lernen" des Normalzustandes 2. Feststellen von erheblichen Abweichungen vom Normalzustand Aber: Das sind nur Indizien. Jede gewollte Reaktion auf geänderte Umweltbedingungen führt zur Feststellung von Anomalien, jedenfalls wenn das Verhalten sich dadurch ändert. 11

12 Feststellen von Anomalien II Beispiele von Anomalien: Ein verreister Mitarbeiter loggt sich ein. Eine lang schläfrige Mitarbeiterin loggt sich um 7.00 Uhr ein. Auf Daten, die kaum jemanden interessieren, wird häufig zugegriffen. Nicht verfügbare Dienste werden geprüft (Port Scanns). Zugriff auf Daten aus Backups Auf üblicherweise nicht genutzte Zugänge von Außen wird zugegriffen. Häufige Probleme beim Zugang, z.b. falsche Passwörter werden eingegeben, Loginnamen sind falsch 12

13 Techniken zur Einbruchserkennung Analyse von Dateien und Daten während Übertragung Scannen von Dateien mit Mustererkennung Bibliothek von Positiv- und Negativ-Fällen Positiv: Alle zutreffenden Fälle lösen Alarm aus Negativ: Alle zutreffenden Fälle werden ignoriert Integritätstest Anlegen eines Schnappschusses der Dateisysteme Vergleich des aktuellen Zustands mit dem Schnappschuss Echtzeitanalyse der Systemaufrufe der Dateizugriffe des Kommunikationsverhaltens Das IDS wird hier meist innerhalb des Kernels realisiert. Das Festgestellte muss protokolliert werden (Logfiles). 13

14 Problemfälle Falsch-positiv = Fehlalarm = Eine ungefährliche Situation wird als gefährlich eingestuft Viele Fehlalarme führen zu nervigen Problemen Aber auch: Fehlalarme können provoziert werden (DoS-Angriff) Falsch-negativ = Eine gefährliche Situation wird als ungefährlich eingestuft (ignoriert) Wichtig: Die Daten des IDS dürfen nicht kompromittiert sein! Das ist sicherzustellen. 14

15 Arten von IDS Host-basierte IDS = HIDS = IDS zur Überwachung eines Systems, wobei das IDS auf diesem System auch arbeitet Netzwerk-basierte IDS = NIDS = IDS zur Überwachung von Netzwerkverbindungen Orte: vor einer Firewall ("draußen") hinter einer Firewall in der DMZ in Netzsegmenten des Innenbereichs 15

16 Sonderform: Honeypots Honeypot = Spezielles System, das absichtlich Angriffe zulässt, um die Art und Technik der Angriffe studieren zu können Ziele (Soziologisches) Studium von Hackern oder Hackergruppen Studieren neuer Angriffstechniken, z. B. Feststellen von typischen oder neuen Angriffsarten Prüfung des bestehenden Schutz Sammeln von Viren oder sonstiger Malware Konsequenterweise können auch Netze aus Honeypots aufgebaut werden: Honeynets. [H1] [H2] [H3] [H4] pagecontent=site/research.menu/theses.page/finished+projects.pa ge/client-side+honeypots.page&uin=&show=true 16

17 Hostbasierte IDS (HIDS) Andere Namen für diese IDS sind: System Integrity Verifier (SIV) File Integrity Assessment (FIA) Hier behandelte HIDS: tripwire 17

18 Tripwire an der Purdue University entwickelt Der Klassiker unter den Host-basierten IDS Kommerzielle Version: Offene Version: 18

19 Aufbau Aufbau Zwei Konfigurationsdateien Konfiguration: twcfg.txt Policy: twpol.txt jeweils in ASCII und binärer und verschlüsselter Form Datenbank Ort wird in twcfg.txt festgelegt Vier Programme: tripwire, twadmin, twprint, siggen Dateien werden mit einem Schlüssel unterschrieben und verschlüsselt (El Gamal, 1024 bit). 19

20 Richtlinien - Einfachster Fall I Regelaufbau: Objekt -> Eigenschaften; Jede Regel endet mit einem Semikolon. Objekt ist Unterbaum mit rekursiven Ordnern innerhalb des Dateisystems von Objekt, d.h. das Dateisystem wird nicht verlassen Datei Makros als Kürzel Eigenschaften (zu überprüfen): Makros als Kürzel Explizite Angabe 20

21 Richtlinien - Einfachster Fall II (Auszug) Eigenschaft p i n u g t s d r b m c M S Erläuterung Dateirechte (Permissions) Inodenummer Anzahl der harten Links (Referenzzähler) User-ID Group-ID Typ der Datei Größe der Datei Gerätenummer, auf welche die Inodes liegen Gerätenummer, auf welche die Inodes zeigen Anzahl der allokatierten Blöcke Zeitpunkt der Modifikation Zeitpunkt der Entstehung MD5-Summe SHA-1-Summe 21

22 Richtlinien - Einfachster Fall IV Makroname Inhalt Erläuterung $(ReadOnly) +pinugsmtdbcm-raclsh $(Dynamic) +pinugtd-rsacmblcmsh Häufige Änderungen $(Growing) +pinugtdl-rsacmbcmsh Für Logfiles ohne Rotate $(IgnoreAll) -pinusgamctdrblcmsh Nur Existenz der Datei $(IgnoreNone) +pinusgamctdrblcmsh Alles wird überwacht $(Device) +pugsdr-intlbamccmsh tripwire öffnet nicht diese Datei Hinweise: Eigenschaft a (Access time) oder c beißt sich mit einer Prüfsumme. In den Makros/Variablen dürfen keine Operatoren benutzt werden. 22

23 Beispiele # Beispiel 1 User = /home; Lesend = +pinugtsm; # /etc -> $(Lesend); $(User) -> $(Lesend)-M+S; # Beispiel 2 # /etc -> $(ReadOnly); /var -> $(Dynamic); 23

24 Richtlinien - Attribute I Die Attribute können auch in der Regel stehen, z.b.: /etc -> $(ReadOnly) ( to=root@blabla.com); /tmp -> $(IgnoreAll) (recurse=0); Werte für recurse: Wert Erläuterung -1 Beliebig tief 0 keine Rekursion N Rekursion bis zum N. geschachtelten Verzeichnis 24

25 Hinweise Die ASCII-Versionen der Konfigurationsdatei und Policy-Datei müsen gelöscht werden (sie können jederzeit rekonstruiert werden). Tripwire setzt initial einen sicheren Zustand voraus. Alle drei wichtigen Dateien (Pol-/Cfg- und Datenbank) sollten auf ein extra Medium kopiert werden. Diese drei Dateien auf CD brennen und diese nutzen hat den Nachteil, dass nicht sichergestellt werden kann, dass auch wirklich die CD-Version benutzt wird. Einen weiteren Stolperdraht aufspannen: Mit Absicht eine zufällige Verletzung produzieren. Wenn plötzlich Tripwire diese nicht mehr meldet... 25

26 Tripwire-Bericht (Auszug) I Report generated by: root Report created on: Thu Feb 1 11:30: Database last updated on: Mon Jan 29 09:07: =============================================================================== Report Summary: =============================================================================== Host name: Castor Host IP address: Host ID: None Policy file used: /etc/tripwire/tw.pol Configuration file used: /etc/tripwire/site.cfg Database file used: /var/lib/tripwire/dbfile/castor.twd Command line used: tripwire --check -c site.cfg -M =============================================================================== Rule Summary: =============================================================================== Section: Unix File System Rule Name Severity Level Added Removed Modified * Configuration Programs * root

27 Tripwire-Bericht (Auszug) II Total objects scanned: Total violations found: 8 =============================================================================== Object Detail: =============================================================================== Section: Unix File System Rule Name: Configuration (/etc) Severity Level: Modified Objects: Modified object name: /etc Property: Expected Observed * Modify Time Mon Jan 29 09:07: Thu Feb 1 11:30: * Change Time Mon Jan 29 09:07: Thu Feb 1 11:30:

28 Weitere HIDS fwlogwatch Echtzeitprotokollanalyse logwatch - Protokollanalyse in Perl fcheck - System-Scanner in Perl integrit tripwire-variante another file integrity checker Samhain ( osiris - tripwire-variante für Windows/UNIX ftp://unix.hensa.ac.uk/sites/ftp.wiretapped.net/pub/security/hostintrusion-detection/osiris/ 28

29 Übersicht - NIDS Netzwerk-basierte IDS = NIDS = IDS zur Überwachung von bestimmten Netzwerkverbindungen (Kabel) Orte: Vor einer Firewall ("draußen") Hinter einer Firewall in der DMZ An Netzsegmenten im Innenbereich 29

30 An der Netzschnittstelle erkennbare Angriffe Beispiele 1. DoS-Angriffe durch Bufferoverflow 2. Ungültige, anormale Pakete, z. B. Ping of Death 3. Angriffe auf Applikationen, z.b. Web-Server: Cross Site Scripting 4. Informationsdiebstahl durch Mitschneiden der Kommunikation 5. Modifikation und Kopieren von Dateien per FTP 6. Fernsteuern über das Netz: Missbrauch eines Rechners als Bot 7. Eingeschränktes Feststellen des Spoofings 8. Benutzung fragwürdiger DNS-Server 9. Portscanns 30

31 snort Beginn der Entwicklung 1998, es gehört nun zu einem der besten NIDS Open Source, Autor: Martin Roesch und viele andere Version (Oktober 2014) Portierung auf Solaris, HP-UX, OpenBSD, FreeBSD, Win32 und LINUX Einsatz als Sniffer und vor allem als IDS Allerdings hat auch snort eine unangenehme Sicherheitsgeschichte: es gibt zahlreiche Angriffe. 31

32 Architektur Die Plugins sowie die Regeln werden über die Konfigurationsdatei /etc/snort/snort.conf gesteuert. 32

33 Einsatz als Sniffer (Beispiele) I snort -v Sniffer sehr ähnlich zu tcpdump snort -dev -d zeigt noch den Paketinhalt an, -e das Ethernet-Paket snort -devi eth0 Hier kann die Schnittstelle mit -i angegeben werden snort -devi eth0 icmp Zum Filtern lassen sich Filterbedingungen nach den Berkeley- Paketfilterregeln (BPF) angeben; es sind dieselben wie bei tcpdump 33

34 Einsatz als Sniffer (Beispiele) II snort -dev -l Ordner Im Ordner werden Unterverzeichnisse mit den Namen der betreffenden Kommunikationspartner angelegt. snort -dev -l Ordner -h Adresse/Maske Wenn das eigene Netzwerk, z.b /16, angegeben wird, tragen die Unterverzeichnisse die Namen der externen Kommunikationspartner. Problem: Es können sehr viele Dateien erzeugt werden. snort -dev -b -l Ordner -h Adresse/Maske Hier wird im libpcap-format protokolliert, das auch von tcpdump und wireshark gelesen werden kann snort -dev -r Datei Hier wird eine binäre Protokolldatei noch einmal eingelesen. 34

35 Einsatz als NIDS snort -de -l Ordner -h Adresse/Maske -c RulesFile Ausgabeformate und Reaktionen: Flag Erläuterung -b Binärformat (libpcap) -N Keine Protokollierung -A fast Schnellster Modus: Zeitstempel, Alarmmeldung, IP-Adressen -A full Standardmodus: Zeitstempel, Alarmmeldung, Paketheader -A unsock Sendet Alarmmeldung an einen Socket -A none Keine Alarmierung -s Alarmiert via Syslogd (Einträge in Logfiles) -M Alarmiert via WinPopUp (nur unter Windows) 35

36 Beispiele von Snort-Regeln I # # MYSQL RULES # alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 3306 (msg: root login attempt"; flow:to_server,established; content:" 0A "; classtype:protocol-command-decode; sid:1775; rev:1;) alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 3306 (msg:"mysql show databases attempt"; flow:to_server,established; content:" 0f show databases"; classtype:protocol-command-decode; sid:1776; rev:1;) 36

37 Beispiele von Snort-Regeln II # # ICMP RULES # alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"icmp PING NMAP"; dsize: 0; itype: 8; reference:arachnids,162; classtype:attempted-recon; sid:469; rev:1;) alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"icmp traceroute ipopts"; ipopts: rr; itype: 0; reference:arachnids,238; classtype:attempted-recon; sid:475; rev:1;) alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"icmp Source Quench"; itype: 4; icode: 0; classtype:bad-unknown; sid:477; rev:1;) alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"icmp Large ICMP Packet"; dsize: >800; reference:arachnids,246; classtype:bad-unknown; sid:499; rev:3;) 37

38 Beispiele von Snort-Regeln III # # EXPLOIT RULES # alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"exploit ssh CRC32 overflow /bin/sh"; flow:to_server,established; content:"/bin/sh"; reference:bugtraq,2347; reference:cve,cve ; classtype:shellcode-detect; sid:1324; rev:3;) alert tcp $EXTERNAL_NET 80 -> $HOME_NET any (msg:"exploit netscape 4.7 client overflow"; flow:to_client,established; content: " 33 C9 B1 10 3F E C FA C0 50 F7 D0 50 "; reference:cve,cve ; reference:bugtraq,822; reference:arachnids,215; classtype:attempted-user; sid:283; rev:5;) alert tcp $EXTERNAL_NET any -> $HOME_NET 139 (msg:"exploit x86 linux samba overflow"; flow:to_server,established; content: " eb2f 5feb 4a5e 89fb 893e 89f2 "; reference:bugtraq,1816; reference:cve,cve ; reference:cve,cve ; classtype:attempted-admin; sid:292; rev:4;) 38

39 Angriffe gegen snort Die "üblichen" Sicherheitsprobleme hatte snort, z. B. Bufferoverflows Werkzeug stick generiert anhand der (öffentlichen) snort- Regeln vorsätzlich Falsch-Positive Pakete, um systematisch falsche Alarme auszulösen. Snot Ftester

40 Weitere Werkzeuge Snarf: Berichtswerkzeug Analysis Console for Intrusion Databases (ACID) Logsnorter ftp://ftp.sbin.org/pub/admin/security/ids/snort/ 40

41 Nun wieder etwas entspannen... 41