4.3 Einbruchsentdeckung Intrusion Detection

4.3 Einbruchsentdeckung Intrusion Detection Firewall soll Einbruch verhindern. Bei schwacher (oder fehlender) Firewall ist Einbruch nicht auszuschließen - und soll dann wenigstens entdeckt werden. Ziele: Alarmierung der Verantwortlichen, Schließen der Sicherheitslücke, Identifizierung des Angreifers. Aber auch Angriffe, d.h. Einbruchsversuche, sollten rechtzeitig erkannt werden! Überwachung des Netzverkehrs erforderlich: "Sensoren" wie Paketfilter und spezielle ID-Werkzeuge. NS-1 1

Sensor vor der Firewall: Sensor hinter der Firewall: für Angriffserkennung für Einbruchsentdeckung Isolierte Betrachtung einzelner Pakete reicht nicht: bestimmte Muster im Datenverkehr müssen erkannt werden. Bei vermutetem Angriff/Einbruch u.u. sofortiger Alarm. Übliches Problem aller Warnsysteme: false negatives: Angriff/Einbruch wird nicht erkannt false positives: Fehlalarme NS-1 2

4.3.1 Typische Werkzeuge tcpdump portsentry snort für einfache ID einsetzbar überwacht Portscans beliebtes universelles ID-Werkzeug... sowie eine Vielzahl "intelligenter" Werkzeuge, meist noch im Laborbetrieb NS-1 3

4.3.1.1 Sentrytools http://sourceforge.net/projects/sentrytools/ für hostbasierte ID auf Unix-Systemen (vor allem Linux) portsentry überwacht Portscans, betreibt also keine ID, sondern entdeckt "verdächtige Aktivitäten" - und kann die Linux-Firewall steuern logcheck/logsentry überwachen Login-Versuche hostsentry Variante der obigen Werkzeuge * sentry = Wachposten NS-1 4

4.3.1.2 Snort www.snort.org snort ist das Standard-Werkzeug für ID, vielseitig einsetzbar Verwendbar in 4 verschiedenen Modi: sniffer mode: Pakete werden am Bildschirm gezeigt (vgl. tcpdump) logger mode: NIDS mode: inline mode: Pakete werden in Datei abgespeichert (vgl. tcpdump) (network intrusion detection system mode) veranlasst regelgesteuerte Aktionen Pakete können verworfen werden (wie Firewall) to snort: schnupfen, schnüffeln NS-1 5

sniffer mode: snort -v zeigt Paketköpfe der Schichten 3 und 4 -d + Daten -e + Schicht-2-Köpfe logger mode: snort -l logdir speichert Pakete hierarchisch strukturiert gemäß den IP-Adressen in den Paketen - oder -b im binären tcpdump-format (schließt -dev ein) -h homenet (z.b. 160.45.110.0/24) vermeidet die entsprechenden Adressen im logdir snort -r packet.log zeigt Inhalt einer Log-Datei am Bildschirm an, steuerbar mit -dev und zusätzlichen Optionen zur Auswahl bestimmter Paketarten NS-1 6

NIDS mode: snort -c snort.conf... Hier wird das Verhalten durch die Regeln (rules) in der angegebenen Konfigurationsdatei bestimmt. Gespeichert werden nur diejenigen Pakete (bzw. Teile davon), auf die eine Regel anwendbar ist. Typischer Einsatz: snort -vd -h 160.45.110.0/24 -c snort.conf -l logdir NS-1 7

Steuerung der Ausgabe von Warnmeldungen/Alarmen (alerts) (die in der Konfigurationsdatei vereinbart sind): snort -A alertmode... Typische alert modes: full fast vollständige Meldung mit allen relevanten Daten (Voreinstellung, falls kein alertmode angegeben) verkürzte Meldung console verkürzte Meldung an die Konsole... NS-1 8

Snort-Regeln in Konfigurationsdatei (z.b. snort.config): Syntax: rule : header [ ( options ) ] header : action protocol source -> destination options : { option ; }+ option : keyword : value Beispiel: alert tcp any any -> 192.168.1.0/24 111 (content:" 00 01 86 a5 "; msg:"mountd access";) Bedingung NS-1 9

Aktionen: alert log pass generate an alert using the selected alert method, and then log the packet log the packet ignore the packet activate alert and then turn on another dynamic rule dynamic remain idle until activated by an activate rule, then act as a log rule... und im inline mode: drop reject sdrop make iptables drop the packet and log the packet make iptables drop the packet, log it, and then send a TCP reset if the protocol is TCP or an ICMP port unreachable message if the protocol is UDP. make iptables drop the packet but does not log it. NS-1 10

Protokolle: ip, tcp, udp, icmp IP-Adressen: auch mit vorangestelltem! für "alle außer dieser"; auch Listen von Adressen in der Form [,,...]; auch any Portnummern: auch mit vorangestelltem! für "alle außer dieser"; auch Port-Bereiche in der Form "von : bis"; auch any... und statt -> kann auch <> verwendet werden (als Abkürzung für zwei entsprechende Regeln) NS-1 11

Aktionen activate und dynamic: dynamic-regel wird so lange ignoriert, wie sie nicht durch eine activate-regel aktiviert wird - dann wirkt sie wie eine log-regel. Beispiel (aus dem Snort Manual): activate tcp!$home_net any -> $HOME_NET 143 (flags: PA; content: " E8C0FFFFFF /bin"; activates: 1; msg: "IMAP buffer overflow!";) dynamic tcp!$home_net any -> $HOME_NET 143 (activated_by: 1; count: 50;) NS-1 12

Optionen in Regeln: meta-data: msg,... (keine Bedingungen!) payload: content, pcre,... non-payload: dsize, flags, seq, ack,... post-detection: logto,... (keine Bedingungen!) NS-1 13

Weitere Elemente der Konfigurationsdatei: Variablenvereinbarung und -belegung var <name> <value> var MY_NET 160.45.110.0/24 $MY_NET bezeichnet den Wert Konfigurierung (geändert durch Optionen auf Befehlszeile) config <directive> [ : <value> ] config alertfile: alerts config nolog... NS-1 14

4.3.2 Zustandsbehaftete Einbruchserkennung Anomalie-Erkennung (anomaly detection): Anomalien gegenüber den normalen Abläufen entdecken: - schwierig (z.b. Einsatz neuronaler Netze), - typisches Problem falscher Alarm versus Nichterkennung (false positives - false negatives) Missbrauchs-Erkennung (misuse detection): vorgegebene unzulässige oder verdächtige Muster entdecken: - mit regelbasierten Systemen gut handhabbar, - aber man muss die Angriffe kennen! NS-1 15

Angriffssprachen für Missbrauchs-Erkennung (attack languages) erlauben Beschreibung von Mustern (signatures) missbräuchlicher oder verdächtiger Benutzung Beispiel 1: Muster: nach login 3-mal falsches Passwort eingegeben Beispiel 2: Vor.: ~lohr/private hat Schutzstatus rwx--x--x Muster: wiederholter Versuch von ls -l ~lohr/private/test mit verschiedenen test NS-1 16

Beispiel 3: Vor.: Benutzer alt erstellt Datei hosts mit Inhalt elfe.inf.fu-berlin.de alt Muster: elfe:alt% cp hosts ~lohr/.rhosts elfe:alt% rlogin -l lohr elfe (ermöglicht im Standard-Unix das Einloggen als lohr ohne Angabe eines Passworts) Beispiel 4: Angriff über setuid Shell script (siehe Systemsicherheit 4.3.3, Beispiel 3) NS-1 17

Angriffssprache STATL [Kemmerer et al. 2000] (State Transition Analysis Technique Language) (für NIDS erweitert zu NETSTAT): Modellierung: endlicher Automat, als Diagramm graphisch darstellbar Zustandsübergang = sicherheitsrelevantes Ereignis Auszeichnung unerwünschter Zustände Alarm Erkennungssystem: verarbeitet die gemeldeten Ereignisse, z.b. von Snort, BSM,... gemäß den mit STATL formulierten Vorgaben, die nach Übersetzung als Plugins hinzugefügt werden NS-1 18

Obiges Beispiel 3: elfe:alt% cp hosts ~lohr/.rhosts elfe:alt% rlogin -l lohr elfe Modellierung des Angriffsmusters als Diagramm: create login readrhosts s0 s1 s2 s3 (da.rhosts vorhanden!) als STATL-Text: NS-1 19

als STATL-Text: use unix, bsm; Bezugnahme auf Bibliotheken scenario rhostsattack { int user; int pid; int inode; initial state s0 { } Buchführung über Daten Abstraktion eines BSM event type transition create (s0 -> s1) nonconsuming { Voraussetzung: [WRITE w] : (w.euid!=0) && (w.owner!=w.ruid) Buchführung: { inode = w.inode; } } state s1 { }......... (nächste Seite) NS-1 20

..... transition login (s1 -> s2) nonconsuming { [EXECUTE e] : match_name(e.objname, "login") { user = e.ruid; pid = e.pid; } } state s2 { } transition readrhosts (s2 -> s3) consuming { [READ r] : (r.pid == pid) && (r.inode ==inode) } state s3 { string username; userid2name(user,username); log("rhosts attack by %s", username); } } NS-1 21