7 Überwachungs- und Alarmsysteme

Transkript

1 7 Überwachungs- und Alarmsysteme Automatische Protokollierung sicherheitsrelevanter Ereignisse ermöglicht Entdeckung/Rekonstruktion von erfolgreichen - und erfolglosen - Angriffen, ermöglicht eventuell, den Angreifer auf frischer Tat zu erwischen, ist sinnvoll, weil hohe Sicherheit unverhältnismäßig teuer sein kann, ist sinnvoll, weil 100% Sicherheit unmöglich ist, ist empfehlenswert bei allen sicherheitskritischen Systemen

2 7.1 Protokollierung (auditing, security auditing) Betriebssystem protokolliert Ereignisse - zu Abrechnungszwecken, - zu Sicherheitszwecken Sicherheitsrelevante Ereignisse sind verzeichnet - teils in den Abrechnungsprotokollen, - teils in zusätzlichen Sicherheitsprotokollen. (audit logs, audit trails, audit data,... audit = Buchprüfung )

3 Aspekte der Protokollierung: was soll protokolliert werden? lokales Ein/Ausloggen, Zugang übers Netz, sicherheitsbezogene Systemaufrufe,... wie viel soll protokolliert werden? wenig unzureichende Information viel Informationsüberflutung wo kann das Protokoll sicher abgelegt werden? - schreibgeschützte Datei - andere Maschine, evtl. besonders gesichert (loghost) - Papier/sicherer Drucker! (physisch sichern)

4 Problematische Aspekte der Protokollierung: wie können die Daten sinnvoll ausgewertet werden? verstößt die Protokollierung gegen den Datenschutz? (aktuelle Forschung: pseudonymisierte Protokollierung mit Aufdeckung der Pseudonyme bei hinreichendem Verdacht)

5 7.1.1 Protokollierung in Unix wird wenig unterstützt - für Abrechnung, - für Systemverwaltung, - für Fehlerverfolgung, - in Ermangelung eines besseren auch für Sicherheitsüberwachung Was, wie viel, wo? Aufruf der Bibliotheksroutine syslog veranlaßt Nachricht an Systemprozeß syslogd, der die Protokollierung übernimmt. Verhalten von syslogd wird durch /etc/syslog.conf bestimmt:

6 jefe: m /etc/syslog.conf #ident "@(#)syslog.conf /12/14 SMI" /* SunOS 5.0 */ # # Copyright (c) by Sun Microsystems, Inc. # All rights reserved. # # syslog configuration file. # # This file is processed by m4 so be careful to quote (`') names # that match m4 reserved words. Also, within ifdef's, arguments # containing commas must be quoted. # *.err; kern.notice; auth.notice /dev/sysmsg *.err; kern.debug; daemon.notice; mail.crit /var/adm/messages *.alert; kern.err; daemon.err operator *.alert root *.emerg *... usf. facilities : user, kern, mail, auth, daemon,... level : emerg, alert, err,... (von syslog) action : Datei/Gerät oder Benutzer (falls aktiv) oder loghost

7 Typische Dateien (viele Variationen bei Unix-Varianten!): /var/log/syslog /authlog /... /var/adm/utmp /wtmp Benutzungszeiten, anzeigbar mit Befehl last /messages Nachrichten für Systemverwalter /lastlog /... /var/audit/...

8 Beispiel Benutzungszeiten: jefe: last more lohr pts/2 lohr.dialup.fu-b Sun Jun 9 14:35 still logged in lohr pts/2 lohr.dialup.fu-b Sun Jun 9 13:10-14:07 (00:57) schweppe pts/2 tarent.icsi.berk Thu Jun 6 17:51-17:52 (00:00) idys pts/2 darwin Thu Jun 6 11:28-11:28 (00:00) schweppe pts/2 fondue.icsi.berk Wed Jun 5 21:39-21:53 (00:14) schweppe pts/2 fondue.icsi.berk Wed Jun 5 21:20-21:22 (00:02) schweppe pts/2 fondue.icsi.berk Wed Jun 5 20:28-20:33 (00:05) schweppe pts/2 fondue.icsi.berk Wed Jun 5 19:55-20:13 (00:18) schweppe pts/2 fondue.icsi.berk Wed Jun 5 19:01-19:18 (00:16) idys pts/2 i40s12.ipd.uni-k Tue Jun 4 14:35-14:35 (00:00) oracle pts/2 elfe Mon Jun 3 12:40-12:41 (00:01) koenig pts/2 orakel Mon Jun 3 12:39-12:39 (00:00) lohr pts/2 lohr.dialup.fu-b Sat Jun 1 20:07-22:31 (02:23) lichtblu pts/2 troll Sat Jun 1 15:21-15:21 (00:00) root pts/2 stucki Fri May 31 19:41-19:41 (00:00) root pts/2 bombadil Fri May 31 13:05-13:31 (00:25) schweppe pts/2 pd9e6aa49.dip.t- Fri May 31 07:39-07:39 (00:00) voges pts/6 server9.gameserv Thu May 30 15:24-15:24 (00:00) schweppe pts/6 pd9e6b258.dip.t- Thu May 30 07:38-07:41 (00:02) schweppe pts/6 pd9e6b7c9.dip.t- Wed May 29 08:17-08:19 (00:01) lohr pts/6 lohr.dialup.fu-b Tue May 28 13:21-15:20 (01:59)

9 Beispiel Warn- und Fehlermeldungen: jefe: more messages.3 May 13 11:14:50 jefe bootpd[28515]: [ID daemon.notice] IP address May 13 11:14:53 jefe last message repeated 1 time May 14 10:08:59 jefe bootpd[15814]: [ID daemon.notice] IP address May 14 10:09:03 jefe last message repeated 1 time May 14 16:27:11 jefe ufs: [ID kern.notice] NOTICE: alloc: /export/ May 14 16:28:19 jefe last message repeated 17 times May 14 19:07:28 jefe afpd[19008]: [ID daemon.error] afp_flushfork: May 15 13:40:35 jefe bootpd[19585]: [ID daemon.notice] IP address May 15 13:40:39 jefe last message repeated 1 time May 15 18:59:36 jefe /usr/dt/bin/ttsession[29901]: [ID daemon.erro May 16 17:12:17 jefe ufs: [ID kern.notice] NOTICE: alloc: /export: IP address not found: IP address not found: NOTICE: alloc: /export/home: file system full afp_flushfork: of_find: No such file or directory IP address not found: child (29937) exited due to signal 1 NOTICE: alloc: /export: file system full

10 7.1.2 Sicherheits-Protokollierung in Solaris beim Einsatz des Basic Security Module (BSM) (Alle BSM-Daten findet man unter dem Verzeichnis /etc/security) Was, wie viel, wo? Obligatorische Protokollierung durch Betriebssystem-Kern über Audit Daemon auditd gemäß den Angaben in /etc/security/audit_control - was soll protokolliert werden? /etc/security/audit_data - wo soll protokolliert werden?

11 Typischer Inhalt von /etc/security/audit_control : dir: /etc/security/audit/localhost dir: /etc/security/audit.aux/localhost flags: lo,ad,-all,^-fm naflags: lo,ad Ereignisklassen mit Präfixen Typischer Inhalt von /etc/security/audit_data : 64:/etc/security/audit/elfe/ not_terminated.elfe Audit Daemon current audit log file Inhalt eines audit log file: binär codierte Ereignisdaten siehe audit.log(4)

12 Ereignisklassen (/etc/security/audit_class): no no_class null value for turning off event preselection fr file_read Read of data, open for reading, etc. fw file_write Write of data, open for writing, etc. fa file_attr_acc Access of object attributes: stat, pathconf, etc fm file_attr_mod Change of object attributes: chown, flock, etc. fc file_creation Creation of object fd file_deletion Deletion of object cl file_close close(2) system call pc process Process operations: fork, exec, exit, etc. nt network Network events: bind, connect, accept, etc. ip ipc System V IPC operations na non_attrib non-attributable events ad administrative administrative actions: mount, exportfs, etc. lo login_logout Login and logout events ap application Application auditing io ioctl ioctl(2) system call ex exec exec(2) system call ot other Everything else all all All flags set

13 Präfixe von Ereignisklassen: + erfolgreiche Operationen protokollieren - abgewiesene Operationen protokollieren (ohne) ^ erfolgreiche und abgewiesene Op. protokollieren... nicht protokollieren naflags (non-attributable flags): für Ereignisse, die keinem bestimmten Benutzer zugeordnet werden können

14 Ereignisse (/etc/security/audit_class): Nummer : Name : Ereignis : Ereignisklasse(n) 0:AUE_NULL:indir system call:no 1:AUE_EXIT:exit(2):pc 2:AUE_FORK:fork(2):pc 3:AUE_OPEN:open(2) - place holder:fa 4:AUE_CREAT:creat(2):fc 5:AUE_LINK:link(2):fc 6:AUE_UNLINK:unlink(2):fd 7:AUE_EXEC:exec(2):pc,ex 8:AUE_CHDIR:chdir(2):pc 9:AUE_MKNOD:mknod(2):fc 10:AUE_CHMOD:chmod(2):fm 11:AUE_CHOWN:chown(2):fm 12:AUE_UMOUNT:umount(2) - old version:ad 13:AUE_JUNK:junk:no 14:AUE_ACCESS:access(2):fa 15:AUE_KILL:kill(2):pc 16:AUE_STAT:stat(2):fa... usw.

15 Befehle audit, auditon, auditcontrol, auditconfig,... (nur für Systemverwalter) : audit -s konfiguriert den Audit Daemon gemäß audit_control audit n veranlaßt den Audit Daemon, mit neu erzeugter Protokoll-Datei weiterzuarbeiten audit t veranlaßt den Audit Daemon, die aktuelle Protokolldatei zu schließen und das Protokollieren einzustellen

16 Verarbeitung der protokollierten Daten: auditreduce hat Filter-Funktion praudit produziert lesbare Version Beispiele: (Verarbeitung aller Daten aus /etc/security/audit/server/files/*) % auditreduce -d u lorenz -c lo praudit day user class after before user % auditreduce -a b u lorenz -m AUE_CHDIR praudit event

17 7.1.3 Protokollierung in Windows 3 Protokolle werden geführt: Systemprotokoll für allgemeine Ereignisse Sicherheitsprotokoll für sicherheitsrelevante Ereignisse Anwendungsprotokoll für anwendungsbezogene Ereignisse Start Einstellungen Systemsteuerung Verwaltung - Ereignisanzeige

18 z.b. Systemprotokoll:

19 Eigenschaften eines Ereignisses abfragen: Ereignistypen sind 1. Fehler (sicherheitsrelevant:) 2. Warnung 4. Erfolgsüberwachung 3. Informationen 5. Fehlerüberwachung

20 Sicherheitsprotokoll ist nur für Systemverwalter einsehbar:

21 Steuerung der Protokollierung sicherheitsrelevanter Ereignisse (durch den Systemverwalter): Start Einstellungen Systemsteuerung Verwaltung Lokale Sicherheitsrichtlinie Überwachungsrichtlinien

22 Systemverwalter kann Überwachung dateispezifisch steuern: Eigenschaften - Sicherheitseinstellungen der Datei (vgl )

23 Eintrag Alles Jeder Eintrag Fehl... Jeder

24 7.2 Angriffsentdeckung (intrusion detection) mittels automatischer On-line-Auswertung der Protokolle: Entdeckung bestimmter Verhaltensmuster Sicherheitsadministrator alarmieren Anomalie-Erkennung (anomaly detection): Anomalien gegenüber den normalen Abläufen entdecken - schwierig (z.b. Einsatz neuronaler Netze), - typisches Problem falscher Alarm versus Nichterkennung Mißbrauchs-Erkennung (misuse detection): vorgegebene unzulässige oder verdächtige Muster entdecken - mit regelbasierten Systemen gut handhabbar, - aber man muß die Angriffe kennen!

25 7.2.1 Angriffssprachen für Mißbrauchs-Erkennung (attack languages) erlauben Beschreibung von Mustern (signatures) mißbräuchlicher oder verdächtiger Benutzung Beispiel 1: Muster: nach login 3-mal falsches Paßwort eingegeben Beispiel 2: Vor.: ~lohr/private hat Schutzstatus rwx--x--x Muster: wiederholter Versuch von ls -l ~lohr/private/test mit verschiedenen test

26 Beispiel 3: Vor.: ~alt/hosts enthält den Text elfe.inf.fu-berlin.de alt Muster: elfe:alt% cp hosts ~lohr/.rhosts elfe:alt% rlogin l lohr elfe (ermöglicht im Standard-Unix Einloggen als lohr ohne Angabe eines Paßworts) Beispiel 4: Angriff über setuid Shell script, siehe 5.3.2, Beispiel 3

27 Angriffssprache STATL (Kemmerer et al. 2000) (State Transition Analysis Technique Language): 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 BSM (7.1.2), gemäß den mit STATL formulierten Vorgaben, die nach Übersetzung als Plugins hinzugefügt werden

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

29 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 enter (s0 -> s1) nonconsuming { Voraussetzung: [WRITE w] : (w.euid!=0) && (w.owner!=w.ruid) Buchführung: { inode = w.inode; } } state s1 { } (nächste Seite)

30 ..... 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); } }

31 ... und zahlreiche weitere Intrusion-Detection-Systeme, auch kommerziell oder Open Source, insbesondere für Network Intrusion Detection, z.b. Snort ( analysiert übers Netz eintreffende Datenpakete (packet sniffing) Vorteil: Paketinhalt detailliert analysierbar Nachteil: zustandslos