Regelkatalog. Bruno Blumenthal und Roger Meyer. 17. Juli Zusammenfassung

Transkript

1 Regelkatalog Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Der Regelkatalog soll eine Zusammenstellung der wichtigsten Regeln für das NetWACS Projekt enthalten. Als Grundlage dienen die Marktanalyse und die Use- Case Analyse. Der Regel-Katalog definiert auch die Softwareanforderungen und wird als Basis für die Systemarchitektur benutzt. 1

2 Inhaltsverzeichnis 2

3 1 Einführung Die Regeln sind die Kernfunktion für das Projekt NetWACS. Sie entscheiden was mit den gesammelten Daten gemacht wird. Die Regeln korrelieren die Logs von verschiedenen Quellen, Services und Maschinen. Sie werden entscheiden, welche s generiert werden, welche weiteren Schritte und Regeln ausgeführt werden und wie die Reports aussehen werden. 2 Sources NetWACS beschränkt sich grundsätzlich auf die folgenden drei Quellen, wobei jedoch weitere mit nicht allzuviel Aufwand hinzugefügt werden könnten: Syslog, Firewall Logs (iptables, Cisco Router logs, usw.) und IDS Systeme (Snort). Alle Quellen werden direkt in eine Datenbank (hier mysql) auf dem Logserver gespeichert. Es gibt pro Quelle eine Datenbank, wobei es zum Beispiel bei Firewall Logs mehrere Datenbanken braucht, weil das Format von iptables und Router Logs nicht dasselbe sind. Hier gibt es auch Ausnahmen, wie zum Beispiel die Cisco Router Logs, die via Schnittstelle in die DB eingetragen werden können. Somit gibt es eine Syslog DB, vielleicht mehrere Firewall DB s und eine Snort DB. 3 Log analysis Für die Analyse von Log-Files kann man, ähnlich wie bei den heutigen IDS Systemen, zwei Ansätze verfolgen. 3.1 Misuse Detection Logfile nach bekannten Daten durchsuchen Bekannte Muster können LOGIN FAILIURE oder andere verdächtige Logeinträge sein. Diese Liste wird von Natur aus nie komplett sein, weil sich die Umstände konstant verändern. Diese Art erkennt nur bekannte Probleme, dies ist auch die grosse Schwäche dieser Analyse. 3

4 3.2 Anomaly Detection Eine Liste von normalem Verhalten aufstellen - alles andere ist verdächtig Diese Liste wird zum Beispiel Daten enthalten wie Verbindungen von bekannten Hosts, Cron jobs, Log rotation, usw.; diese werden ignoriert. Alle anderen Einträge sind von aussergewöhnlich und sollten genauer untersucht werden. Diese Technik wird auch artificial ignorance genannt. Wenn man die normalen Daten immer wieder anpasst, sagt man dem adaptive learning. Um optimale Ergebnisse zu erhalten sollten beide Methoden angewendet werden. 4 Rules Nach diversen Brainstormings haben wir erst einmal drei Ober-Kategorien für die Regeln definiert. Diese unterscheiden sich in erster Linie durch die Parameter ihrer Definition. Repetition Rules Asset-DB Rules Anomaly Rules Diese Liste ist nicht abschliessend, es können sehrwohl Regeln Sinn machen, welche nicht in eine dieser Kategorien passen. Da wir im Rahmen dieses Projektes aber nur einen beschränken Umfang an Regeln implementieren und testen können, haben wir uns entschlossen, uns auf diese drei Kategorien zu beschränken. Beim Software-Design soll jedoch darauf geachtet werden, dass weitere Kategorien im System integriert werden können. 4.1 Repetition Rules Die Regeln in dieser Kategorie befassen sich mit Wiederholungen von Log Einträgen. Dabei wird überprüft ob ein bestimmter Log-Eintrag in einem Zeitfenster mehrmals vorkommt. Die Definition einer solchen Regel umfasst folgende Punkte: 4

5 Als erstes muss definiert werden welche Datenquelle verwendet werden soll. (, logs, firewall...) 1..n Regular Expression, fix Dies ist das primäre Vergleichsmuster, dabei wird auf ein Feld der Datenquelle eine Regular Expression angewendet und mit einem Fixen String verglichen. z.b. LOGIN FAILURE in einer Message. Die Regel wird nur angewandt wenn dieses Kriterium erfüllt ist. Es können mehrere solche Regeln existieren, so dass es möglich ist, z.b. LOGIN FAILURE nur auf einem bestimmten host beachtet wird. Die einzelnen RegEx können Logisch-UND oder Logisch-ODER verknüpft sein. 0..n Regular Expression, variable Auch diese Regular Expression wird auf ein Feld der Datenquelle angewendet. Im Unterschied zur vorhergehenden Regel wir das Resultat nicht mit einem fixen String verglichen, sondern es wird mit anderen Log-s verglichen, die auf das selbe primäre Vergleichsmuster passen. z.b. mehrmaliges LOGIN FAILURE von der gleichen Source-IP oder vom selben Username. Es kann kein oder mehrere solcher Muster geben. Die Muster sind immer Logisch- UND verknüpft. Repetitions Wie oft müssen die Muster passen, damit das Rule- ausgelöst wird. Die Regel muss im Zeitrahmen der Gültigkeit mindestens (min), maximal (max) oder genau (exact) soviel Male zutreffen. Timeframe Das Timeout bestimmt das Zeitfenster in dem die Wiederholungen gemessen werden. Die Zeit wird mit dem ersten Auftreffen der Regel gestartet. Rule- Das Rule- bestimmt was zu tun ist, wenn diese Regel greift. Dies kann ein einfacher sein oder auch das generieren eines ausführlicheren Berichts. Welche Priorität hat das Rule- dieser Regel. 4.2 Asset-DB Rules Die Asset-DB Rules vergleichen Informationen aus einem Log-Eintrag mit Daten in einer Asset Datenbank. Die Asset-DB kann Informationen über Server und Services, Netzwerktopologien und User beinhalten. Eine solche Datenbank kann sehr viel zur Analyse von Log-Daten beitragen. Das Problem ist in der Praxis eine solche Datenbank zu unterhalten. Wenn die Daten in der DB nicht ganz akkurat mit der Security-Policy des Unternehmens und der effektiven Situation im Netzwerk übereinstimmt, kann es sehr leicht zu fehlerhaften Analysen führen. Mit einer korrekten und ausführlichen Asset-DB 5

6 kann jedoch sehr viel erreicht werden. Aus diesem Grund haben wir uns entschlossen, diese in unserem System vorzusehen. Das Management und den Abgleich mit bestehenden Datenbanken und Network Management Systemen wäre in einer echten produktiven Umgebung unverzichtbar, muss jedoch von Fall zu Fall betrachtet werden, weshalb wir dies hier nicht genauer untersuchen wollen. Die Asset-DB Regeln sind sehr einfach zu definieren und sind von den verfügbaren Daten in der Asset-DB abhängig. Als erstes muss definiert werden welche Datenquelle verwendet werden soll. (, logs, firewall...) Eine Boolean Wert welche definiert ob dies eine ist welche auf jedes angewandt wird oder eine Successor-Rule welche durch eine andere Regel ausgelöst wird. 1..n Regular Expression, fix Dies ist das primäre Vergleichsmuster, dabei wird auf ein Feld der Datenquelle eine Regular Expression angewendet und mit einem Fixen String verglichen. z.b. su in einer Message. Die Regel wird nur angewandt wenn dieses Kriterium erfüllt ist. Regular Expression Auch diese Regular Expression wird auf ein Feld der Datenquelle angewendet. Das Resultat dieser RegEx wird im SQL-Statement verwendet um es mit einem Eintrag in der DB zu vergleichen. SQL-Statement Das SQL-Statement, das auf der DB-Ausgeführt werden soll. Das Resultat des Statements wird als boolean interpretiert. 0, keine Records oder False als Rückgabe werden als FALSE interpretiert alles andere ist TRUE. Es kann definiert werden ob TRUE oder FALSE das Rule- auslösen. Rule- Das Rule- bestimmt was zu tun ist, wenn diese Regel greift. Dies kann ein einfacher sein oder auch das generieren eines Ausführlicheren Berichts. Welche Priorität hat das Rule- dieser Regel. Successor Hier kann eine Folgeregel definiert werden, welche nur ausgeführt wird, wenn diese Regel nicht gegriffen hat. 4.3 Anomaly Rules Bei den bisherigen Regeln haben wir nach bekannten Muster gesucht, die wir als gefährlich einstufen. Mit den Anomaly Rules versuchen wir Dinge zu detektieren die nicht normal 6

7 sind. Dabei werden die Logs mit einer Datenbank von bekannten Mustern verglichen. Kennt das System das Muster nicht, wir ein generiert. Dieses System könnte mit einer automatischen Lernfunktion ausgerüstet werden, welhe mit der Zeit automatisch neue Muster aufnimmt. Da dies jedoch eine sehr komplexe Aufgabe ist, die nur mit einer gewissen künstlichen Intelligenz zu erledigen ist, werden wir in unserem System das lehren dem Administrator überlassen. Das heisst wenn eine unbekanntes eintrifft wird die dem Administrator zu Überprüfung angezeigt. Er kann dann entscheiden ob dies als normal zu taxieren ist und ein entsprechendes Muster in der DB erstellt werden soll. So wird das System mit der Zeit immer mehr Muster kennen und immer weniger False- Positives anzeigen. Datensource Als erstes muss definiert werden welche Datenquelle verwendet werden soll. (, logs, firewall...) 1..n Das eigentliche Muster mit dem Verglichen werden soll. Es handelt sich dabei um eine Regular Expression die auf eine bestimmtes Feld des s angewandt wird. Es können für die Felder Date, Time, Host, Msg definiert werden. Wenn für ein kein Treffer in den Regeln gefunden wird, wird ein entsprechender ausgelöst. 5 Rules defined 5.1 Repetition Rules Die Login Regeln müssen auf den Daemon abgestimmt werden. So sieht zum Beispiel der Eintrag für ein fehlgeschlagenes Login von einem SSH und telnet daemon komplett verschieden aus. Eine andere Möglichkeit wäre, eine eigene Log Datenbank aufzubauen, welche die korrelierten Logs beinhaltet. Beispiel: ein FAILED LOGIN von telnetd und Failed password von SSHd würden dann in einen gleich aussehenden Eintrag in unsere DB eingetragen. Welche Lösung schlussendlich zum Zug kommt wird zu einem späteren Zeitpunkt entschieden (Dokument Systemarchitektur). Die folgenden Regeln sollten somit möglichst unabhängig gestaltet werden. 7

8 Beschreibung: minimum 3 gleiche Login failures von der gleichen source IP. Fix msg: /(Failed password) (FAILED LOGIN) (FTP LOGIN FAILED)/ Variable msg: /from (.+) / Repetitions min. 3 Timeframe 1 Minute medium Beschreibung: minimum 3 Login failures auf dem selben Host Fix msg: /(Failed password) (FAILED LOGIN) (FTP LOGIN FAILED)/ Variable host: /(.+)/ Repetitions min. 3 Zeitfenster 1 Minute low Beschreibung: minimum 3 Login failures vom gleichen User auf einer oder verschiedenen Maschinen Fix msg: /(Failed password) (FAILED LOGIN) (FTP LOGIN FAILED)/ Variable msg: /for (.+) / Repetitions min. 3 Timeframe 1 Minute low 8

9 Beschreibung: Login eines inexistenten Users von der gleichen source IP. Fix msg: /Illegal user/ Variable msg: /from (.+) / Repetitions min. 3 Timeframe 1 Minute Beschreibung: Report every non-root su attempt Fix msg: /ˆsu.* ˆ(root)$/ Variable - Repetitions - Timeframe - medium Beschreibung: Report every su attempt to root Fix msg: /ˆsu.* root$/ Variable - Repetitions - Timeframe - Beschreibung: IPTables: minimum 5 packets from the same src IP within one minute Fix msg: /ˆIPTABLES:/ Variable msg: /SRC=(\d*\.*) / Repetitions min. 5 Timeframe 1 Minute low 9

10 Beschreibung: Snort: Backdoor access to exactly one host (precise access) Fix signature: /BACKDOOR/ Variable dst addr: (.*) Repetitions max. 1 Timeframe - Beschreibung: Snort: Backdoor access to more than one host (-> random scan) Fix signature: /BACKDOOR/ Variable dst addr: (.*) Repetitions min. 2 Timeframe - medium Beschreibung: known Exploit against one of our machines Fix signature: /EXPLOIT/ Variable - Repetitions - Timeframe - Beschreibung: massive ICMP messages mean network troubles Fix signature: /ICMP/ Variable - Repetitions min. 50 Timeframe 5 Minuten 10

11 Beschreibung: DDoS and DoS attacks Fix signature: /ˆ(DDOS) (DOS)/ Variable - Repetitions - Timeframe - Beschreibung: FTP problems/attacks Fix signature: /ˆFTP/ Variable - Repetitions - Timeframe Asset-DB Rules Wie bereits weiter oben erwähnt, ist eine Asset-DB eine mächtiges Werkzeug bei der Analyse von Log-Daten. Es ist jedoch sehr wichtig, dass die Daten akkurat und vollständig sind. Wir haben für unsere Anwendung eine einfache DB beschränkt welche sich hauptsächlich auf Informationen betreffend Services beschränkt, dies Informationen sollten in jedem Unternehmen, als Bestandteil der Security Policy, vorhanden sein. Wir haben auch einige User bezogenen Informationen in unserer Asset-DB. Abbildung?? zeigt das DB-Design welches wir als Grundlage für die folgenden Regeln benutzten. 11

12 Abbildung 1: Die Asset-DB Regeln beziehen sich auf diese DB 12

13 Beschreibung: Bei einem Login auf einen FTP Server soll geprüft werden ob dieser Server legitim ist. Fix msg: /(FTP LOGIN)/ SQL-Expression (logvalue) host: /(.+)/ SQL-Statement SELECT * FROM hosts WHERE ip = logvalue AND ftp IS NOT NULL; false Rule- Beschreibung: Bei einem Anonymous-Login soll geprüft werden ob dies auf diesem Server legitim ist. Fix msg: /(FTP LOGIN ANONYMOUS)/ SQL-Expression (logvalue) host: /(.+)/ SQL-Statement SELECT anonymous FROM ftp, hosts WHERE ftp.id = hosts.ftp AND hosts.ip = logvalue; false Rule- Beschreibung: Bei einem FTP-GET Server soll geprüft werden ob dies auf diesem Server legitim ist. Fix msg: /(FTP GET)/ SQL-Expression (logvalue) host: /(.+)/ SQL-Statement SELECT get FROM ftp, hosts WHERE ftp.id = hosts.ftp AND hosts.ip = logvalue; false Rule- 13

14 Beschreibung: Bei einem FTP-PUT Server soll geprüft werden ob dies auf diesem Server legitim ist. Fix msg: /(FTP PUT)/ SQL-Expression (logvalue) host: /(.+)/ SQL-Statement SELECT put FROM ftp, hosts WHERE ftp.id = hosts.ftp AND hosts.ip = logvalue; false Rule- Beschreibung: Wenn eine su zu root Rechten gemacht wird soll geprüft werden ob dieser User dies darf. Fix msg: /ˆsu.* ˆ(root)$/ SQL-Expression (logvalue) msg: username regex SQL-Statement SELECT suroot FROM users WHERE username = logvalue; false Rule- medium Beschreibung: Bei einem Snort allgemeinen WEB wir geprüft ob auf dem entsprechenden Host ein Web-Server läuft. Fix msg: /ˆWEB/ SQL-Expression (logvalue) dst-ip: /(.+)/ SQL-Statement SELECT * FROM hosts WHERE ip = logvalue AND web IS NOT NULL; Rule- medium 14

15 Beschreibung: Bei einem Snort WEB-IIS wir geprüft ob auf dem entsprechenden Host ein IIS läuft. Fix msg: /ˆWEB-IIS/ SQL-Expression (logvalue) dst: /(.+)/ SQL-Statement SELECT * FROM HOSTS, web, webtypes WHERE ip = logvalue AND hosts.web = web.id AND web.type = webtypes.id AND webtypes.name = ÏIS ; Rule- medium Beschreibung: Bei einem Snort WEB-PHP wir geprüft ob auf dem entsprechenden Host ein Web-Server mit PHP läuft. Fix msg: /ˆWEB-PHP/ SQL-Expression (logvalue) dst-ip: /(.+)/ SQL-Statement SELECT * FROM hosts, web, webextension, extension WHERE ip = logvalue AND hosts.web = web.id AND web.id = webid AND extid = extension.id AND extension.name = PHP ; Rule- medium 15

16 Beschreibung: Bei einem Snort WEB-CGI wir geprüft ob auf dem entsprechenden Host ein Web-Server mit CGI läuft. Fix msg: /ˆWEB-CGI/ SQL-Expression (logvalue) dst-ip: /(.+)/ SQL-Statement SELECT * FROM hosts, web, webextension, extension WHERE ip = logvalue AND hosts.web = web.id AND web.id = webid AND extid = extension.id AND extension.name = CGI ; Rule- medium Beschreibung: Bei einem Snort WEB-CGI wir geprüft ob auf dem entsprechenden Host ein Web-Server mit CGI läuft. Fix msg: /ˆWEB-CGI/ SQL-Expression (logvalue) dst-ip: /(.+)/ SQL-Statement SELECT * FROM hosts, web, webextension, extension WHERE ip = logvalue AND hosts.web = web.id AND web.id = webid AND extid = extension.id AND extension.name = CGI ; Rule- medium 5.3 Anomaly Rules Die Anomaly Regeln beinhalten alle bekannten und erlaubten Logeinträgen. Im folgenden werden einige Beispiele aufgeführt. Die Anomaly Regeln können nicht auf Snort Logs angewendet werden, nur auf, firewall und ähnliche Logs. Denn Snort generiert s nur auf bekannte Muster. Hier wollen wir aber abnormale und neue Logs erkennen. Diese Regeln müssen zu Beginn einer NetWACS Installation an die bestehende Umgebung angepasst werden, da sie stark von der Netzwerk-Konfiguration abhängt. 16

17 Die Regeln werden entweder in einer Tabelle (DB) angelegt oder in einer einfachen Datei gespeichert. Beschreibung: su to nobody from root, probably cronjob Msg: /(su)session opened for user nobody by (uid=0)/ Beschreibung: Every morning around 06.20, -ng is restarted for log file rotation Time: /06:2\d:\d2/ Msg: /-ng[\d0,5]: SIGHUP received, restarting -ng/ Beschreibung: Cronjob execution at Time: /06:25:\dd/ Msg: /USRSBINCRON/ Beschreibung: IPTables: Packets to port 80 are pretty common Msg: /IPTABLES:.*DPT=80/ Beschreibung: SSH login Msg:/sshd[\d0,5]: Accepted password/ Beschreibung: User login Msg: /PAM unix[\d0,5]:.* session opened/ 17

18 Beschreibung: User logout Msg: /PAM unix[\d0,5]:.* session closed/ Beschreibung: Login: authentication failure Msg: /PAM unix[\d0,5]: authentication failure/ Beschreibung: SU failure Msg: /su[\d0,5]:pam authenticate: Authentication failure/ Beschreibung: SU failure Msg: /su[\d0,5]: [-+].*/ 6 Schlussfolgerung Die Anzahl an Regeln ist beinahe unbeschränkt. Für jede denkbare Situation könnte man eine - oder Report-Regel erstellen. Die aufgeführten Regeln sind nur eine Auswahl. Zu Beginn sollen diese Regeln dazu dienen die Engines zu konstruieren. Das Tool soll schlussendlich eine einfache Möglichkeit bieten, um neue Regeln einfach zu erstellen. Die Regel-Kategorien sollen auch nicht abschliessend sein. Bei der Implementierung ist darauf zu achten, dass einfach weitere Regel-Kategorien Implementiert werden können. Dies soll zusammen mit der Möglichkeit, weitere Datenquellen zu implementieren, eine möglichst grosse Flexibilität bei der Erweiterung von NetWACS gewährleisten. 18