Dokumentation FHBB AI Diplomarbeit 01 2004 / 2005 Dozent: R. Ebener Auftraggeber: M. Künzli Version 1.0 Muttenz / Basel Dezember 2004
Vorwort Die Diplomarbeit ist die Abschlussarbeit meines Studiums angewandte Informatik an der Fachhochschule beider Basel, FHBB. In einem angenehmen Umfeld durfte ich für die FHBB eine Webapplikation entwickeln, welche für den Benutzer des Network Intrusion Detection Systems SNORT eine komfortable Unterstützung bietet. Für die Unterstützung und Betreuung während meiner zehnwöchigen Arbeit möchte ich mich bei meinem Dozenten Herrn R. Ebener sowie dem stellvertretenden IT-Verantwortlichen der FHBB Muttenz, Herr M. Künzli bedanken. Erklärung zur Dokumentation Die Dokumentation enthält Codeteile und Kommandozeilenbefehle. Diese werden grau unterlegt dargestellt und enthalten eine Zeilennummerierung. Kommandozeilenbefehle beginnen mit einem # (Sharp). Mit [...] wird mitgeteilt, dass ein Codeausschnitt aus einem File dargestellt wird. Beispiel: 1 # dies ist eine Kommandozeile 2 3 [...] 4 echo Dies ist ein Codeausschnitt aus einem PHP-File ; 5 [...] Auftraggeber: M. Künzli, FHBB 2 23.12.2004
Abstract Das Intrusion Detection System SNORT dient zur Überwachung des Netzwerkverkehrs. Neben dem Erkennen von Angriffen und verdächtigen Aktivitäten können SNORT-Daten zum Auffinden von Sicherheitslücken und Schwachstellen verwendet werden. Die IT-Abteilung der Fachhochschule beider Basel (FHBB) möchte SNORT auf eine für den Administrator möglichst übersichtliche und effiziente Art und Weise anwenden. Mit der Diplomarbeit wird dem Auftraggeber (FHBB) eine benutzerfreundliche Oberfläche für die Regelverwaltung geboten. Die während der Diplomarbeit erstellte Webapplikation Admintool für SNORT erfüllt die vom Auftraggeber gewünschten Funktionalitäten der Regelverwaltung und Handhabung verschiedener Tools, welche das Arbeiten mit SNORT erleichtert. Auftraggeber: M. Künzli, FHBB 3 23.12.2004
Management Summary Der Diplomand Philipp Sick entwickelt im Rahmen der Diplomarbeiten 04/05 die Webapplikation Admintool für SNORT für die Fachhochschule beider Basel, FHBB. Die Webapplikation dient der vereinfachten Administration des Intrusion Detection Systems SNORT. Der Auftraggeber, Herr M. Künzli der IT-Abteilung FHBB, setzt SNORT ein und benötigt ein Administrationstool zur Verwaltung der SNORT-Regeln. Das Admintool für SNORT erlaubt das Verwalten und Bearbeiten der SNORT-Regeln in angenehmer Art und Weise. Die textbasierenden Regeln werden in eine Datenbank eingelesen und im Browser übersichtlich dargestellt (siehe Bild). Die Funktionalität der Regelverwaltung konzentriert sich auf das Aktualisieren, Suchen, Editieren und Erstellen von Regeln. Das Arbeiten via Browser löst das unübersichtliche Verwalten der Regeln in den Regelfiles Ausschnitt Übersicht SNORT - Regeln ab. Das Admintool beinhalten die Analyse Console for Intrusion Database (ACID), welche zum Durchsuchen und Analysieren der von SNORT generierten Daten dient. Ein Alarmierungssystem soll in einem weiteren Schritt in die Webapplikation eingebunden werden. Die Webapplikation ist erweiterbar und basiert auf der OpenSource Kombination LAMP (Linux, Apache, MySQL, PHP). Das Ziel, ein Admintool für SNORT zu erstellen, wurde erreicht. Dem Auftraggeber steht eine Webapplikation zu Verfügung, welche das Verwalten der Regeln ermöglich. Neben der Entwicklung der Webapplikation erhielt der Diplomand einen vertieften Einblick in die Funktionsweise von Intrusion Detection Systemen. Die Diplomarbeit verbindet Netzwerksicherheit und Internet Engineering zu einem spannenden Arbeitsumfeld. Auftraggeber: M. Künzli, FHBB 4 23.12.2004
Inhaltsverzeichnis 1 Definitionsphase...9 1.1 Auftrag...9 1.2 Einsatzgebiet...9 1.3 Herausforderung...10 1.4 Voraussetzung...10 1.5 Einschränkung...10 1.6 Risiken...11 1.7 Rahmenbedingungen...11 1.8 Zeitmanagement...11 1.9 Quellen...12 2 Grundlagen SNORT...13 2.1 SNORT Überblick...13 2.1.1 Intrusion Detection...13 2.2 Mögliche Platzierung von SNORT im Netzwerk...14 2.3 Funktionsweise von SNORT...14 2.4 Betriebsarten von SNORT...16 2.5 Regeln...17 2.5.1 Verbundliste...17 2.5.2 Regelfiles...17 2.5.3 Regelaufbau...18 2.5.3.1 Regel-Header...18 2.5.3.2 Regel-Option...20 2.5.4 Regeln erstellen...20 2.5.5 Deaktivieren von Regeln...21 2.5.6 Aktualisieren der Regeln...21 2.6 Output Plugins von SNORT...21 2.6.1 Exkurs Barnyard...22 2.7 SNORT Sicherheit...22 3 Konzeptphase...23 3.1 Ist Zustand...23 3.2 Soll Zustand...23 3.3 Aufbau...24 3.4 Systemanforderungen...25 Auftraggeber: M. Künzli, FHBB 5 23.12.2004
3.4.1 Hardware...25 3.4.1.1 Erklärung promiskurer Modus...26 3.4.2 Software...26 3.4.2.1 Betriebssystem...26 3.4.2.2 Webserver...27 3.4.2.3 Datenbank...27 3.4.2.4 Programmiersprache...27 3.4.2.5 SNORT...27 3.4.2.6 Network Time Protocol...27 4 Realisierungsphase Admintool...28 4.1 Programmierung...29 4.2 Benutzerhandbuch...29 4.3 Layout und Browser...29 4.4 Regeladmin...30 4.4.1 SNORT Source...30 4.4.1.1 Beispiel Source Import...31 4.4.1.2 Erklärung Sudo...31 4.4.2 Backup...32 4.4.3 SNORT Regeln herunterladen...33 4.4.3.1 Erklärung Shell-Script updatesnortrules.sh...33 4.4.4 Erstellen der Datenbank für das Regeladmintool...34 4.4.4.1 Erstellen der Datenbank regeladmin in MySQL...35 4.4.4.2 Das ER-Modell...35 4.4.4.3 Beschreibung der Attribute von rule / updaterule...38 4.4.5 Einfügen der SNORT-Regeln in die Datenbank...39 4.4.5.1 Voraussetzung...39 4.4.5.2 Formatierung der Regeln...40 4.4.5.3 Regel SID...40 4.4.5.4 Regelfiles...41 4.4.5.5 Erkennen von Kommentar und Regel...42 4.4.5.6 Lesen und Einfügen von Regelfile und Regel in die Datenbank...43 4.4.5.7 Bestehende Probleme...44 4.4.6 Regelarten...45 4.4.6.1 Einfügen der bestehenden Regeln in die Datenbank...45 Auftraggeber: M. Künzli, FHBB 6 23.12.2004
4.4.6.2 Einfügen neuer Regeln in die Datenbank...45 4.4.7 Abgleich bestehender und neuer Regeln...46 4.4.8 Bearbeiten von Regeln...46 4.4.9 Erstellen und Kopieren von Regeln...47 4.4.10 Bestehende Probleme...47 4.4.10.1 Kommentar...47 4.4.10.2 Regel SID...48 4.4.10.3 Backup...48 4.5 Alarmierung...48 4.5.1 SNORT Alert Monitor (SAM)...49 4.6 ACID...49 4.7 Tutorial und Benutzerhandbuch...50 4.8 Erweiterbarkeit...51 4.8.1 Snort Alert Monitor (SAM)...51 4.8.2 Oinkmaster...51 5 Anhang...52 5.1 Zeitmanagement...52 5.2 SQL...57 5.3 Struktur, Programmierung...58 5.3.1 main.php...60 5.3.2 regeluebersicht.php...60 5.3.3 regelneu.php...61 5.3.4 regelinsert.php...61 5.3.5 regelinout.php...62 5.3.6 regelaendern.php...62 5.3.7 regelupdate.php und functionupdate.php...63 5.3.8 regeladmin.php...63 5.3.9 snortconf.php...64 5.3.10 home.php...64 5.3.11 alarmierung.php...64 5.3.12 tutorial.php...64 5.3.13 constants.php...64 5.3.14 includes.php...64 5.3.15 dbconnect.php...65 Auftraggeber: M. Künzli, FHBB 7 23.12.2004
5.4 Test - Einfügen der Regeln in die Datenbank...65 5.5 Test - Vergleich bestehender und neuer Regeln...67 5.6 Test - Bearbeiten des Regelfiles...70 6 Quellenangabe...71 7 Index...72 8 Ehrlichkeitserklärung...73 Auftraggeber: M. Künzli, FHBB 8 23.12.2004
1 Definitionsphase Das Intrusion Detection System SNORT dient zur Überwachung des Netzwerkverkehrs. Neben dem Erkennen von Angriffen und verdächtigen Aktivitäten können SNORT-Daten zum Auffinden von Sicherheitslücken und Schwachstellen im Netzwerk verwendet werden. 1.1 Auftrag Die Diplomarbeit hat das Ziel, eine Webapplikation für die IT-Abteilung der Fachhochschule beider Basel, FHBB Muttenz zu entwickeln, welche dem SNORT-Benutzer die Handhabung der Regelverwaltung vereinfacht. Der Auftrag beinhaltet folgende Ziele: - Eine Datenbank dient zum Verwalten der SNORT Regeln - Die SNORT-Regeln können in der Webapplikation eingesehen und bearbeitet werden - Das SNORT-Konfigurationsfile sowie die Regelfiles werden aus den Daten der Datenbank erstellt - Analyse Console for Intrusion Database (ACID) soll ein Bestandteil des Admintools sein - Konzept eines Alarmierungssystems für SNORT - Erstellen eines Benutzerhandbuchs für die Webapplikation Admintool für SNORT 1.2 Einsatzgebiet Die Webapplikation Admintool für SNORT wird an der IT-Abteilung der FHBB eingesetzt und dient dem Netzwerkadministrator zur komfortablen Handhabung des Intrusion Detection Systems. Die Anforderungen entsprechen den Vorstellungen und Wünschen des Auftraggebers. Das Admintool für SNORT ist erweiterbar und kann bestehende SNORT- Tools integrieren. Nach erfolgreichem Einsatz an der FHBB kann die Webapplikation ohne weiteres in anderen Unternehmen zum Einsatz kommen. In ferner Zukunft kann das Admintool für SNORT als Open Source Applikation freigegeben werden. Auftraggeber: M. Künzli, FHBB 9 23.12.2004
1.3 Herausforderung Die SNORT Detection Engine (siehe 2.3 Funktionsweise von SNORT) arbeitet mit Regeln (siehe 2.5 Regeln), welche auf die gesnifften Netzwerkpakete ansprechen. Die Regeln sind textbasierend und werden in Regelgruppen verwaltet. Die Funktionalität des zu entwickelnden Admintool für SNORT besteht darin, - die Regeln (bestehend aus Regel-Header und Regel-Option) datenbankfähig aufzubereiten und zur Bearbeitung via Webapplikation in eine Datenbank einzufügen. Das Einbinden der Regeln in die Datenbank wird in Kapitel 4.4.5 Einfügen der SNORT-Regeln in die Datenbank beschrieben. Nach Bearbeiten der Regeln im Admintool für SNORT sollen die Regelfiles und Regeln aus der Datenbank neu erstellt werden. - dem Benutzer ein bedienerfreundliches Werkzeug zur effizienten und transparenten Verwaltung der SNORT Regeln zur Verfügung zu stellen. 1.4 Voraussetzung Der Diplomand benötigt fundierte Kenntnisse über die Funktionsweise der Intrusion Detection; im Speziellen im Bereich der SNORT-Regeln. Neben den Kenntnissen über die Intrusion Detection wird der Umgang mit dem Konzept LAMP (Linux, Apache, MySQL, PHP) vorausgesetzt. Der Diplomand bringt die nötigen IT-Kenntnisse aus seinem Studium mit. Insbesondere in den Bereichen Betriebssystem Linux, Webverwaltung, Internetprogrammierung und Datenbanken. 1.5 Einschränkung Die Diplomarbeit mit den Zielsetzungen - Regeladministration - Alarmierungssystem ist grundsätzlich für ein Team von zwei Personen ausgelegt. Beim Kick-off Meeting wurde mit dem Dozenten, Auftraggeber und Experten vereinbart, dass in erster Priorität die Regeladministration realisiert werden soll. Während der Diplomarbeit wird das Alarmierungssystem grob analysiert, Vorschläge erarbeitet und Lösungsansätze aufgezeigt. Auftraggeber: M. Künzli, FHBB 10 23.12.2004
1.6 Risiken Der Diplomand strebt eine fristgerechte Abgabe der Diplomarbeit an. Allfällige Risiken beschränken sich auf Krankheit oder Komplikationen im sozialen Umfeld des Diplomanden. 1.7 Rahmenbedingungen Die Diplomarbeit wird vom begleitenden Dozenten, Herrn Roger Ebener beaufsichtigt. Festgelegte Meetings dienen zum Informationsaustausch. Der Diplomand steht in Kontakt zum Auftraggeber, Herr Markus Künzli, um die zu entwickelnde Webapplikation bestmöglich an die Bedürfnisse des Auftraggebers anzupassen. Die Beurteilung der Diplomarbeit erfolgt durch den betreuenden Dozenten, den Auftraggeber sowie den Experten, Herrn Wolfgang Kayser. Der Diplomand hält sich an die festgelegten Arbeitszeiten und strebt eine Einhaltung der Milestones an (gemäss Zeitmanagement). 1.8 Zeitmanagement Die Diplomarbeit beginnt am 18. Oktober 2004 und endet am 23. Dezember 2004. Die Terminplanung der Abteilung Informatik ist einzuhalten. Für das Zeitmanagement wird MSProject verwendet. Im Anhang, Kapitel 5.1 Zeitmanagement ist der Zeitplan abgedruckt. Der Zeitplan wird bis auf wenige Ausnahmen gegen Ende der Diplomarbeit (zwei Tagesausfälle wegen Krankheit) eingehalten. Die Pilotphase, welche die Inbetriebnahme des SNORT-Rechners und der Webapplikation beim Auftraggeber beinhaltet, muss aus Zeitgründen auf Ende der Diplomarbeit verschoben werden. Diese Zeit wird für das Erstellen der Dokumentation und des Handbuches benötigt. Die Milestones und Meetings mit dem Dozenten dienen der Kontrolle des Zeitplans und der Diskussion des weiteren Vorgehens gemäss Zeitplan. Zur Selbstkontrolle hat der Diplomand für jeden Arbeitstag ein Protokoll erstellt. Die Protokolle sind während der Diplomarbeit auf dem Netzwerk der Abteilung Informatik abgelegt und geben dem Dozenten und Auftraggeber einen Einblick in den aktuellen Stand der Arbeiten. Neben dem Arbeitsrapport werden Probleme und wichtige Informationen vermerkt. Auftraggeber: M. Künzli, FHBB 11 23.12.2004
Aus den Protokollen können Informationen zu Lösungsansätzen, Problemen und Tests bezogen werden. Die Protokolle werden als Annex zu diesem Dokument abgegeben und befinden sich ebenfalls auf der Diplomarbeit-CD im Verzeichnis /protokolle. 1.9 Quellen Der Diplomand bezieht die wesentlichen Informationen zum Thema Intrusion Detection und SNORT aus Büchern und dem Internet (Online-Books). Die Quellenangaben befinden sich im Anhang, Kapitel 6 Quellenangabe. Auftraggeber: M. Künzli, FHBB 12 23.12.2004
2 Grundlagen SNORT 2.1 SNORT Überblick SNORT ist ein Einbrucherkennungssystem, welches von Marty Roesch entwickelt wurde und seit 1998 zur Verfügung steht. SNORT arbeitet im Wesentlichen als Intrusion Detection System (IDS). Der Name SNORT stammt aus dem Englischen und kann als sniffen oder schnüffeln übersetzt werden. Mit dem Schnüffeln wird auf die Funktionalität, das Durchschnüffeln von Netzwerkpaketen hingewiesen. Das SNORT-Logo ( Schweinlein mit einer grossen Schnauze, siehe Titelseite), knüpft an die Idee des Schnüffelns an. SNORT nimmt Pakete aus dem Netzwerk auf und kann mit diesen verschiedene Aktionen ausführen. Die Pakete können beobachtet werden (Packet-Sniffer), sie können geloggt werden (Packet-Logging) oder werden mit dem IDS bearbeitet. SNORT ist ein auf Signaturen basierendes IDS, welches das Netzwerk mit Hilfe von Regeln auf abweichende Pakete überprüft. Unter einer Regel wird ein Satz von Anforderungen verstanden, der bei Abweichungen einen Alarm auslösen kann. 2.1.1 Intrusion Detection Unter Intrusion wird das Eindringen in einen Ort ohne Berechtigung verstanden. Der Begriff Intrusion Detection bezieht sich auf das Aufdecken oder Erkennen eines unbefugten Eindringens durch einen Computer in ein Netzwerk. Ein Intrusion Detection System (IDS) ist ein Einbruchserkennungssystem, welches Netzwerkzugänge überwacht. Das IDS deckt nicht berechtigte Zugriffe auf ein System oder Netzwerk auf und dient der Erkennung und anschliessenden Verhinderung solcher Angriffe. Ein IDS übernimmt in einem Netzwerk die Aufgabe, welches eine Antiviren Software analog in Dateien übernimmt. Es untersucht die Inhalte des Netzwerkverkehrs, um mögliche Angriffe zu erkennen und abzuwenden, genau so, wie ein Virenschutzpaket die Inhalte eingehender Dateien überprüft, um Virensignaturen oder böswillige Aktionen zu erkennen. Ein IDS ersetzt keine Firewall. Firewalls führen eine beschränkte Paketüberprüfung durch, um den Zugriff auf das Netzwerk zu bestimmen. Das IDS untersucht das gesamte Paket auf Inhalte und informiert, wenn etwas verdächtiges entdeckt wird. Auftraggeber: M. Künzli, FHBB 13 23.12.2004
2.2 Mögliche Platzierung von SNORT im Netzwerk SNORT kann an verschiedenen Orten in einem Netzwerk platziert werden und unterschiedliche Aufgabenbereiche wahrnehmen. Abbildung 2.1 www Hub Switch Firewall Server / Clients SNORT Abbildung 2.1 zeigt als Beispiel ein einfaches Netzwerk mit einem SNORT System. Rechts von der Firewall befindet sich das interne Netzwerk. Der SNORT Rechner wird an einen Hub gehängt und das restliche interne Netzwerk an einen 2.3 Funktionsweise von SNORT Die SNORT Architektur lässt sich in folgende Basiskomponenten aufteilen: - Sniffer - Preprocessor - Detection Engine - Ausgabe / Alert / Logging SNORT ist ein Packet Sniffer der darauf ausgerichtet ist, Pakete aus dem Netzwerk aufzunehmen (sniffen) und diese durch den Preprocessor zu verarbeiten. Danach werden die Pakete mit der Detection-Engine von den Regeln geprüft und geloggt. Abbildung 2.2 gibt einen Überblick über die Basiskomponenten der SNORT Architektur. Abbildung 2.2 Netzwerk Sniffer Preprocessor Detection Engine Alert / Logging Packets Switch. Der Traffic, welcher im internen Netz besteht wird somit nicht vom SNORT-Sensor berücksichtigt. Nur die Daten, welche von und zum Internet gehen, werden vom SNORT- Sensor empfangen. Dieser Lösungsansatz ist sinnvoll, sofern das interne Netz als sicher eingestuft werden kann. Ausgabe- Plugin Log Files / Database Rulesets Der Packet-Sniffer schnüffelt nach allen Paketen im Netzwerk und speichert sie für die spätere Verarbeitung ab. Auftraggeber: M. Künzli, FHBB 14 23.12.2004
Der Preprocessor nimmt die Pakete, welche vom Sniffer gefunden werden und prüft diese auf bestimmte Plugins (zum Beispiel ein RPC-Plugin oder ein Portscan-Plugin). Die Plugins überprüfen die Pakete auf ein bestimmtes Verhalten. Tritt ein bestimmter Verhaltenstyp ein, wird das Paket an die Detection Engine weitergeleitet. Die Detection Engine ist der eigentliche Kern der Intrusion Detection von SNORT. Die Detection Engine übernimmt die Daten, die vom Preprocessor kommen. Diese werden auf eine Reihe von Regeln geprüft. Entsprechen die Daten dem Paket, werden diese an den Alarmprozess weitergeleitet. Die Regeln sind in Regelgruppen (Rulesets) nach Kategorien gruppiert (zum Beispiel Ruleset FTP). Die Regeln selbst bestehen aus zwei Teilen, einem Regel-Header und einer Regel-Option. Der Regel-Header enthält die auszuführende Aktion (zum Beispiel Alarmierung), den Typ des Netzwerkpaketes (zum Beispiel TCP, IP), Quellund Zieladresse sowie Quell- und Zielport. Die Regel-Option enthält den Paketinhalt. Ausführliche Informationen zum Aufbau der Regeln in Kapitel 2.5.3 Regelaufbau. Nachdem die SNORT Daten die Detection-Engine durchlaufen haben werden diese weitergeleitet. Entsprechen die Daten einer in der Detection-Engine hinterlegten Regel, wird ein Alarm ausgelöst. Alarme können in einer Log-Datei oder in einer Datenbank gespeichert. werden. Weitere Informationen zur Ausgabe der Daten unter Kapitel 2.6 Output Plugins von SNORT. Zum besseren Verständnis kann die SNORT Architektur auch mit einem mechanischen Münzsortiersystem verglichen werden: - Zuerst werden alle Münzen gesammelt und aufgenommen (entspricht dem Sniffen der Pakete) - Danach sendet das Münzsortiersystem die Münzen durch eine Art Schüttelsieb mit verschieden grossen Löchern, um zu bestimmen, ob es sich um Münzen handelt. (Preprocessor) - Die Münzen fallen gemäss den Bedingungen des Schüttelsiebs in verschiedene Behälter und werden sortiert. Die verschiedenen Münztypen werden erkannt (zum Beispiel 10 Rappen, 50 Rappen etc. (Dies entspricht der Detection Engine von SNORT) - Am Schluss werden die Münzen verarbeitet (zu Münzrollen gerollt) und abgelegt. (Logging und Datenbankspeicherung) Auftraggeber: M. Künzli, FHBB 15 23.12.2004
2.4 Betriebsarten von SNORT SNORT kann unterteilt werden in die Betriebsarten - Packet-Sniffer - Packet Logger - Network Intrusion Detection System Die Betriebsarten stehen in Beziehung zu einander. SNORT wird mit folgender Anweisung als Packet-Sniffer betrieben: 1 #snort v d e Die Option v versetzt SNORT in den Packet-Sniffer-Modus (nur TCP-Header). Mit der Option d und e werden zusätzlich die Header aller übrigen Netzwerkschichten eingebunden. Beim Ausführen des oben aufgeführten Befehls läuft SNORT und gibt Resultate auf der Konsole aus. Mit Ctrl+C wird SNORT gestoppt. Es wird eine Ausgabeübersicht angezeigt, welche die von SNORT gesammelten Pakete, Netzwerktypen und Verbindungsinformationen zusammenfasst. Die gesammelten Daten können in einer Datei abgelegt werden. Dafür ist der SNORT Packet-Logger zuständig, mit welchem die Daten abgespeichert werden. Einsatz des Packet-Loggers, welcher die Daten in das Verzeichnis /tmp/snort loggt. 1 # snort dev l /tmp/snort Die Performance von SNORT kann gesteigert werden, wenn die Ausgabe nicht in ein lesbares Format umgewandelt werden muss, sondern binär ausgegeben wird (Das Sammeln von Daten gewinnt an Geschwindigkeit.) Binäre Ausgabe mit der Option b L in ein Log-file: 1 # snort b L {log-file} Um SNORT als Network Intrusion Detection System auszuführen, muss der Funktion des Packet-Loggers eine weitere Komponente, das Konfigurationsfile snort.conf, hinzugefügt werden. 1 # snort dev l /tmp/snort c /etc/snort/snort.conf Die SNORT-Regeln, welche vom IDS benötigt werden, sind im Konfigurationsfile eingebettet. Diese Regeln sind für die Alarmierung zuständig. Auftraggeber: M. Künzli, FHBB 16 23.12.2004
2.5 Regeln In diesem Kapitel wird beschrieben, wie die Regeln von SNORT aufgebaut und benutzt werden. 2.5.1 Verbundliste SNORT-Regeln sind textbasierend und in den Regelfiles abgelegt. Beim Starten von SNORT liest SNORT alle Regelfiles und erstellt eine dreidimensionale Verbundliste. SNORT vergleicht die empfangenen Pakete mit dieser Liste, um Einbrüche in das Sicherheitssystem zu erkennen. Beim Start von SNORT wird das Konfigurationsfile snort.conf mit den aktivierten Regelfiles gelesen. In jeder dieser Regelfiles befinden sich die Regeln, welche aufbereitet werden. Danach wird die Verbundlist erstellt, mit welcher SNORT arbeitet. Die Detection-Engine arbeitet den Regel-Header und die Regel-Option (Begriffe siehe 2.5.3 Regelaufbau) unterschiedlich ab und erstellt die Verbundliste. 2.5.2 Regelfiles Die Regelfiles werden in einem eigenen Verzeichnis namens rules abgelegt. Die aktuelle SNORT-Version beinhalten knapp fünfzig Regelfiles. Eigene Regelfiles können jederzeit erstellt werden. Die Regelfiles sind in verschiedenen Gruppen kategorisiert. Zum Beispiel enthält das Regelfile ftp.rules eine Auswahl von Regeln, welche sich auf FTP-Angriffe beziehen. Folgender Auszug aus dem Konfigurationsfile snort.conf zeigt, wie die Regelfiles eingebettet sind. Ist ein include mit einem vorangehenden # (Sharp, entspricht einer auskommentierten Zeile) versehen, wird das Regelfile nicht von SNORT bearbeitet. 1 [ ] 2 include $RULE_PATH/local.rules 3 include $RULE_PATH/bad-traffic.rules 4 include $RULE_PATH/exploit.rules 5 include $RULE_PATH/scan.rules 6 include $RULE_PATH/finger.rules 7 include $RULE_PATH/ftp.rules 8 include $RULE_PATH/telnet.rules 9 include $RULE_PATH/rpc.rules 10 include $RULE_PATH/rservices.rules 11 include $RULE_PATH/dos.rules 12 #include $RULE_PATH/ddos.rules 13 #include $RULE_PATH/dns.rules 14 #include $RULE_PATH/tftp.rules 15 [ ] Auftraggeber: M. Künzli, FHBB 17 23.12.2004
2.5.3 Regelaufbau Die aktuelle SNORT-Version arbeitet mit zirka 2300 Regeln, welche in den Regelfiles abgelegt sind. Neue Regeln können selbst erstellt werden (siehe 2.5.4 Regeln erstellen ). Anhand einer FTP-Regel wird der Aufbau der SNORT-Regeln erklärt. SNORT-Regeln werden in Textformat und zeilenweise erfasst. Eine Regel lässt sich in die beiden Bereiche Regel-Header und Regel-Option unterteilen. Beispiel: Ansicht der Regel 2344 aus der Regelgruppe FTP: 1 alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"ftp XCWD overflow attempt"; flow:to_server,established; content:"xcwd"; nocase; isdataat:100,relative; pcre:"/^xcwd\s[^\n]{100}/smi"; reference:bugtraq,8704; reference:bugtraq,11542; classtype:attempted-admin; sid:2344; rev:2;) 2.5.3.1 Regel-Header Der Regel-Header ist der Hauptbestandteil der Regel. Der Header legt fest, was erfolgen soll, wenn eine Regel zutrifft, welches Protokoll und welche Quell- und Ziel-Adresse sowie Quell- und Ziel-Port verwendet werden soll. Der Regel-Header der oben aufgeführten Regel sieht wie folgt aus: 1 alert tcp $EXTERNAL_NET any -> $HOME_NET 21 Abbildung 2.3 zeigt die Bestandteile eines Regel-Headers. Abbildung 2.3 e a Regelkette b Protokoll c Quell-Adresse d Quell-Port c Ziel-Adresse d Ziel-Port alert tcp $EXTERNAL_NET any $HOME_NET 21 Beschreibung des Regel-Headers: a) Regelkette: Unter der Regelkette wird das verwendete Ausgabeformat verstanden. Folgende Optionen kann die Regelkette annehmen: - alert: Generieren eines Alarms und anschliessendes Protokollieren des Pakets - pass: Ignorieren des Pakets - log: Protokollieren des Traffics (kein Alarm) - Activation: Alarm und Aktivieren einer dynamischen Regel - Dynamic: Protokollieren des Traffics, wenn ein Aufruf durch eine Activation-Regel erfolgt Die Regelkette ist der erste Eintrag des Regel-Headers. Wird eine Regel in einem Regelfile deaktiviert, entspricht dies dem Auskommentieren der Zeile mittels # (Sharp). Demzufolge sind alle Regeln, welche in einem Regelfile mit einem #[Regelkette] Auftraggeber: M. Künzli, FHBB 18 23.12.2004
beginnen, als deaktiviert zu betrachten und werden beim Ausführen von SNORT nicht berücksichtigt. b) Protokoll: Dieser Teil steht für das verwendete Protokoll, im Beispiel TCP. Andere Optionen für das Protokoll sind: UDP, IP und ICMP. c) Quell-Adresse / Ziel-Adresse: Quell- und Ziel-Adresse werden angegeben. Im Beispiel sind $EXTERNAL_NET und $HOME_NET systemabhängige Variablen, welche im Konfigurationsfile snort.conf gesetzt werden. $EXTERNAL_NET definiert den externen Bereich des Interfaces, $HOME_NET den internen Bereich. Andere Optionen sind fixe Adressen oder any. Unter any wird jedes beliebige Netzwerk verstanden. d) Quell-Port / Ziel-Port: Benutzt gleiche Optionen wie unter Punkt c) beschrieben, wobei es sich jeweils um den Port handelt. Im obigen Beispiel ist der Ziel-Port auf 21 gesetzt, was dem Port von FTP entspricht. Dies bedeutet, dass nach potentiellen Angriffen auf Port 21 Ausschau gehalten wird. e) Verbindungsrichtung: Die Verbindungsrichtung teilt SNORT die korrekte Art zum Lesen der Regeln mit. Es gibt die beiden Verbindungsrichtungen -> und <> (die Verbindungsrichtung <- wird nicht unterstützt, da diese der Umkehrung der Regel -> entsprechen würde). Die Verbindungsrichtung -> definiert, dass sich die Quell- Information auf der linken Seite und die Ziel-Information auf der rechten Seite befindet. Die Verbindungsrichtung <> teilt SNORT mit, dass die Regel in beide Richtungen anwendbar ist (Quell-Information zu Ziel-Information und umgekehrt). Diese Verbindungsrichtung ist aus Performancegründen zu vermeiden. Soll eine Regel in beide Richtungen anwendbar sein, kann die Regel in zwei Regeln mit der Verbindungsrichtung -> aufgesplittet werden. Von den zirka 2300 aktuellen SNORT-Regeln benutzen nur deren 22 die Verbindungsrichtung <>, was weniger als 1 Prozent entspricht. Auftraggeber: M. Künzli, FHBB 19 23.12.2004
2.5.3.2 Regel-Option Die Regel-Option der oben aufgeführten Regel sieht wie folgt aus: 1 (msg:"ftp XCWD overflow attempt"; flow:to_server,established; content:"xcwd"; nocase; isdataat:100,relative; pcre:"/^xcwd\s[^\n]{100}/smi"; reference:bugtraq,8704; reference:bugtraq,11542; classtype:attempted-admin; sid:2344; rev:2;) Die Regel-Option enthält mehrere Parameter, welche nach einem Doppelpunkt die Einstellungen beinhalten. Die Parameter können variieren und sind von Regel zu Regel unterschiedlich. Erwähnenswert sind die folgende Parameter: - msg : Enthält den Text, der bei einer Alarmierung ausgegeben wird. - sid : Die Regel-SID ist eine Nummer welche genau auf eine Regel zutrifft. Im Beispiel handelt es sich um die Regel mit der Nummer 2344. Diese Nummer wird vom Admintool verwendet, um die Regel eindeutig zu identifizieren. - rev : Die Revisionsnummer gibt an, in welcher Version die Regel vorliegt. 2.5.4 Regeln erstellen Regeln können selbst erstellt werden. Eine neue Regel wird in dem Regelfile erstellt, zu dessen Regelgruppe sie passt. Als Beispiel wird eine Regel erstellt welche sehr einfach ist und für den Gebrauch von SNORT keinen Sinn macht. Sie dient eher dafür, SNORT auf die korrekte Funktionsweise zu testen. Da die Regel neu erstellt wird und keinen wirkliche Nutzen aufweist, wird ebenfalls ein eigenes Regelfile erstellt. Im Konfigurationsfile snort.conf wird am Ende der Regelfile-Includes ein neues Regelfile erstellt, welches nonsense.rules genannt wird: 1 [...] 2 # include $RULE_PATH/p2p.rules 3 include $RULE_PATH/experimental.rules 4 include $RULE_PATH/nonsense.rules Im Verzeichnis, in welchem sich die Regelfiles befinden ([snort]/rules) wird ein neues Regelfile mit Namen nonsense.rules erstellt. In diesem File wird die neue Regel eingetragen: 1 alert ip any any -> any any (msg: IP Packet detected ;) Sobald die Regel auf ein Packet mit dem Protokoll ip anspricht wird ein Alert mit der Message: IP Packet detected ausgegeben. Auftraggeber: M. Künzli, FHBB 20 23.12.2004
Das Erstellen von eigenen Regeln ist im Admintool möglich und erspart das Schreiben der Regeln in den Regelfiles (4.4.9 Erstellen und Kopieren von Regeln ). Weiterführende Informationen können von der Snort-Website bezogen werden: http://www.snort.org/snort-db/ 2.5.5 Deaktivieren von Regeln Das Deaktivieren von Regeln ist ebenso wichtig wie das Erstellen oder Bearbeiten von Regeln. Nicht benötigte Regeln sollten deaktiviert werden, um Speicherplatz (generieren der Log-Files) und Ressourcen zu sparen. Es gibt zwei Methoden um Regeln zu deaktivieren. - Eine ganze Regelgruppe wird deaktiviert. Das heisst, ein Regelfile (zum Beispiel ftp.rules) wird nicht benötigt und deshalb im Konfigurationsfile snort.conf auskommentiert. - Die Regel wird im Regelfile auskommentiert, indem vor die Regel ein # (Sharp) gesetzt wird. Falls die Regel wieder aktiviert werden soll, muss das # (Sharp) entfernt werden. 2.5.6 Aktualisieren der Regeln Das Ändern der Regeln ist ein wichtiger Bestandteil eines IDS. Neue Regeln kommen hinzu oder Änderungen an bestehenden Regeln werden vorgenommen. Die Regeln werden auf dem System up to date gehalten, indem die aktuellsten Regelgruppen und Regeln von der SNORT-Website http://www.snort.org/dl/rules heruntergeladen werden. Die Regeln auf der SNORT-Website werden von den SNORT- Entwicklern bearbeitet. Jeder hat die Möglichkeit, eigene Regeln beizutragen. Die aktuellsten Regeln werden heruntergeladen und auf das System gebracht. Die neuen Regeln müssen im SNORT-Verzeichnis durch die alten ersetzt werden, damit SNORT Zugriff auf die neuen Regeln erhält. (siehe Kapitel 4.4.3 SNORT Regeln herunterladen ) 2.6 Output Plugins von SNORT Die Output-Plugins sind für das Erzeugen der Alarmierung zuständig. Mehrere Output- Plugins können gleichzeitig verwendet werden, zum Beispiel in Form eines Log-Files und einer Datenbank. Beste Performance wird mit einer Ausgabe der SNORT-Resultate in ein unified-format-file erreicht. SNORT benötigt dadurch kaum Ressourcen für die Ausgabe Auftraggeber: M. Künzli, FHBB 21 23.12.2004
und kann sich auf die Kernaufgaben konzentrieren. In einem zweiten Schritt kann das unified-format-file von einem Programm namens Barnyard weiterverarbeitet werden zum Beispiel der Eintrag in eine Datenbank. 2.6.1 Exkurs Barnyard Barnyard kann Daten aus dem von SNORT erstellten unified-format-file auswerten und diese Daten an die Datenbank senden. Barnyard nutzt die binäre Log-Ausgabe von SNORT. Ohne Barnyard sendet SNORT die Daten zum Beispiel direkt an die MySQL Datenbank. Barnyard koppelt das Ausgabestadium von SNORT, was sich positiv auf die Performance und Zuverlässigkeit auswirkt. Beispiel: Während SNORT mit dem ressourcen-verbrauchenden Prozess (Ausgabe der Daten in die Datenbank) beschäftigt ist, arbeitet das Netzwerk weiter. Der SNORT Sensor kann dann Probleme bei der Datensammlung bekommen (analysieren jedes Pakets). Der SNORT-Sensor kann Pakete verlieren, wenn er zur selben Zeit Datenbankschreibvorgänge ausführen muss. Wird Barnyard dazwischen gekoppelt, kann dies verhindert werden. SNORT muss die Daten mit der Verwendung von Barnyard nicht in ein lesbares Format konvertieren und kann sich auf das Auswerten der Daten konzentrieren. 2.7 SNORT Sicherheit Die Sicherheit eines SNORT Systems ist Bestandteil einer guten Systemadministration. Dazu gehört eine saubere Konfiguration, die Deaktivierung nicht benötigter Dienste, regelmässige Updates und die Verschlüsselung von sensiblen Daten. SNORT sollte unter einem eigenen Benutzer snort/snort (userid/group) betrieben werden, damit nur Rechte von Benutzer snort (und nicht z.b. root ) gelten. Auftraggeber: M. Künzli, FHBB 22 23.12.2004
3 Konzeptphase 3.1 Ist Zustand Ohne die Regelverwaltung des Admintool für SNORT muss der SNORT-Benutzer die Regeln in den Regelfiles (Textdateien) suchen und bearbeiten. Dies ist unkomfortabel, unübersichtlich und mühsam. Nachfolgend wird als Beispiel ein Auszug aus dem Regelfile multimedia.rules mit einigen Regeln gezeigt (Zeile 1 bis 8 ist Kommentar, Zeile 9,10 und 11 sind je eine Regel). 1 # (C) Copyright 2001-2004, Martin Roesch, Brian Caswell, et al. 2 # All rights reserved. 3 # $Id: multimedia.rules,v 1.9.2.2 2004/08/10 13:52:06 bmc Exp $ 4 #------------- 5 # MULTIMEDIA RULES 6 #------------- 7 # These signatures look for people using streaming multimedia technologies. 8 # Using streaming media may be a violation of corporate policies. 9 alert tcp $EXTERNAL_NET 80 -> $HOME_NET any (msg:"multimedia Windows Media download"; flow:from_server,established; content:"content-type 3A "; nocase; pcre:"/^content- Type\x3a\s*(?=[av])(video\/x\-ms\-(w[vm]x asf) a(udio\/x\-ms\-w(m[av] ax) pplication\/x\- ms\-wm[zd]))/smi"; classtype:policy-violation; sid:1437; rev:6;) 10 alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"multimedia Quicktime User Agent access"; flow:to_server,established; content:"user-agent 3A Quicktime"; nocase; classtype:policy-violation; sid:1436; rev:5;) 11 alert tcp $EXTERNAL_NET 80 -> $HOME_NET any (msg:"multimedia Shoutcast playlist redirection"; flow:from_server,established; content:"content-type 3A audio/x-scpls"; nocase; content:" 0A "; within:2; classtype:policy-violation; sid:1439; rev:5;) Unter Anwendung des Admintool für SNORT ist das Bearbeitet der Regelverwaltung in den Textdateien (Regelfiles) nicht mehr nötig. 3.2 Soll Zustand Dem SNORT-Benutzer wird das Verwalten der Regeln mit dem Admintool für SNORT erleichtert. Folgende Funktionen stehen ihm zur Verfügung: - Regelübersicht - Regel aktivieren / deaktivieren - Aktuelle Regeln downloaden - Regel bearbeiten - Regel kopieren - Regel neu erstellen - Regel löschen - Status der Regelfiles ändern Auftraggeber: M. Künzli, FHBB 23 23.12.2004
Die Regeln werden in der Datenbank verwaltet, in welcher die Regeldaten bearbeitet werden können. Nach dem Arbeiten mit den Regeln werden die Regeln aus der Datenbank neu erstellt. 3.3 Aufbau Der Aufbau des Admintool für SNORT knüpft an das Schema der Analyse Console for Intrusion Database (ACID) an. Die Abbildung 3.1 zeigt den Aufbau eines Network Intrusion Detection Systems mit einer Datenbank als Output-Plugin und ACID zur Visualisierung der Daten. Abbildung 3.1 Eindringling Snort Sensor Datenbank MySQL WebServer ACID, PHP Browser SNORT - Admin Die Netzwerkpakete werden von SNORT analysiert (die einzelnen Komponenten sind zusammengefasst als SNORT-Sensor). SNORT wird so konfiguriert, dass es als Output- Plugin die Datenbank MySQL verwendet. Der Webserver (Apache) ermöglicht dem SNORT- Administrator via Browser auf die Daten zuzugreifen, welche von ACID (basierend auf PHP) dargestellt werden. Das Admintool für SNORT benutzt ebenfalls eine Datenbank. Das Admintool läuft wie ACID auf dem Webserver und kann vom Browser aus bedient werden (Abbildung 3.2). Abbildung 3.2 Eindringling Snort Sensor Datenbank MySQL WebServer ACID, PHP Browser SNORT - Admin Admintool Auftraggeber: M. Künzli, FHBB 24 23.12.2004
3.4 Systemanforderungen SNORT stellt keine speziellen Ansprüche an die Hardware und Software. 3.4.1 Hardware Aktuelle Standardhardware ist für den Betrieb von SNORT ausreichend. Es werden jedoch mindestens 128MB Arbeitsspeicher sowie 40GB-Speicher empfohlen. Die Netzwerkkarte sollte auf 100Mbps ausgelegt sein. In der Entwicklungsphase des Admintools wird auf einem Rechner mit folgenden Komponenten gearbeitet: - 1.8 GHz Prozessor - 256MB Arbeitsspeicher - 40 GB Festplatte Vom Auftraggeber der Diplomarbeit wird ein Rechner mit folgenden Komponenten bereitgestellt: - 2 GHz Prozessor - 512MB Arbeitsspeicher - 80 GB Festplatte Für den Auftraggeber wird dieser Rechner mit LAMP, SNORT und dem Admintool für SNORT aufgesetzt. Wenn SNORT als IDS verwendet wird, ist eine grosse Festplatte empfehlenswert, da die SNORT-Daten in Log-Dateien oder einer Datenbank aufgezeichnet werden und Speicherplatz benötigt. Des Weiteren wird eine zweite Netzwerkkarte (Ethernet Schnittstelle) eingebaut. Eine Netzwerkkarte wird für die typischen Netzwerkverbindung (Web-Service usw.) benötigt, die zweite Netzwerkkarte für das Sniffen von SNORT. Die Ethernet Schnittstelle, auf welcher das Sniffen ausgeführt wird, wird als SNORT Sensor bezeichnet. Die zweite Netzwerkkarte wird optimalerweise im promiskuren Modus betrieben. Auftraggeber: M. Künzli, FHBB 25 23.12.2004
3.4.1.1 Erklärung promiskurer Modus Erklärung des Betriebsmodus promiskur einer Netzwerkkarte. Wenn eine Netzwerkkarte ein Paket empfängt, welches an ein anderes Device adressiert ist, wird das Paket verworfen. Dies nennt man nicht promiskuren Modus. Im promiskuren Modus wird das Paket angenommen, auch wenn es nicht an dieses Interface adressiert ist. Für ein Intrusion Detection System sollte die Netzwerkkarte im promiskuren Modus laufen. Wird die Netzwerkkarte im promiskuren Modus betrieben, wird jeder Traffic - auch der, welcher nicht an das Interface gerichtet ist - durch den Kernel geleitet. Mit folgendem Befehl kann die Netzwerkkarte eth0 unter SuSE in den promiskuren Modus gesetzten werden: 1 # ifconfig eth0 promisc 3.4.2 Software Die eingesetzte Software kann unter dem Schlagwort LAMP zusammengefasst werden. LAMP steht für Linux, Apache, MySQL und PHP, eine optimale und weitverbreitete Kombination für einen Webserver im OpenSource Bereich. Die wichtigsten Softwarekomponenten werden im folgenden beschrieben. 3.4.2.1 Betriebssystem SNORT läuft auf jedem modernen Betriebsystem (Windows, Linux, FreeBSD, OpenBSD, MacOS und weitere) und stellt keine spezifischen Anforderungen an die Software. Zur engeren Auswahl für die Diplomarbeit stehen Linux SuSE und RedHat. RedHat und SuSE unterscheiden sich im Kern (Kernel etc.) nur noch geringfügig 1. Für Netzwerke soll RedHat besser geeignet sein als SuSE. RedHat wird weltweit häufiger eingesetzt als SuSE, wohingegen SuSE im deutschsprachigen Raum dominiert. Die IT-Abteilung der FHBB (Auftraggeber) benötigt in ihrem Umfeld Linux SuSE. Es ist am sinnvollsten, eine vertraute Umgebung einzusetzen, welche sich in das bestehende Netzwerkadministrationskonzept integriert. Aus diesem Grund wird das Betriebssystem SuSE gewählt. 1 Quelle: http://www.linuxnetmag.com/de/issue9/printm9rh_suse1.html Auftraggeber: M. Künzli, FHBB 26 23.12.2004
Auf der Testumgebung wird mit SuSE 9.0 gearbeitet. Der Rechner für den Auftraggeber wird mit der aktuellsten Version SuSE 9.2 aufgesetzt. 3.4.2.2 Webserver Für das Admintool wird ein Webserver eingerichtet. Der Open Source Webserver Apache wird als Webserver für das Admintool verwendet. Apache ist einfach zu administrieren und ein weltweiter Standard. Er liegt zur Zeit in der Version 2.0 vor. 3.4.2.3 Datenbank Das Admintool benötigt sowohl für die Regeladministration als auch für ACID eine Datenbank. Als Datenbank wird MySQL in der Version 4.0.15 eingesetzt. Als Alternative zu MySQL wird PostgreSQL empfohlen. 3.4.2.4 Programmiersprache Die Programmiersprache für das Admintool ist PHP (Version 4). Zusätzlich wird HTML, JavaScript und CSS sowie Bash-Programmierung eingesetzt. 3.4.2.5 SNORT Während der Diplomarbeit wird mit der SNORT-Version 2.0 gearbeitet. SNORT steht in der Version 2.2 zur Verfügung. Für die Entwicklung des Admintools ist die SNORT Version nicht relevant. 3.4.2.6 Network Time Protocol Das Network Time Protocol NTP wird eingesetzt, um stets eine korrekte Systemzeit zu gewährleisten. Dies ist für das Erstellen der Backups im Admintool und der Verwaltung der Log-Files von SNORT wichtig. Das NTP garantiert identische Zeitangaben. Auftraggeber: M. Künzli, FHBB 27 23.12.2004
4 Realisierungsphase Admintool Das Admintool ist eine Webapplikation, welche Zusatztools für SNORT zur Verfügung stellt. Das Admintool besteht aus den Hauptkomponenten - Regeladmin - Alarmierung - ACID und ist für beliebige Tools, welche als Webapplikation zur Verfügung gestellt werden, erweiterbar. Hauptbestandteil der Diplomarbeit ist der Bereich Regeladmin. Die Abbildung 4.1 zeigt das Organigramm des Admintools mit seinen Hauptkomponenten und den Unterbereichen der Regeladministration. Abbildung 4.1 Snort Intrusion Detection :: SNORT-Admintool :: Regeladmin Alarmierung ACID.. Regelübersicht Regel aktivieren / deaktivieren Regel editieren, neu erstellen, kopieren aktuelle Regeln downloaden.. Die rot eingefärbten Bereiche bestehen bereits (oder teilweise), die schwarzen Bereiche werden währen der Diplomarbeit erstellt. Ausgangssituation ist SNORT. Das Admintool ist webbasierend und beinhaltet die oben erwähnten Hauptkomponenten. Das SNORT Admintool (blau eingefärbt) zeigt den Einstieg in die Webapplikation. Die Webapplikation arbeitet mit den Daten von SNORT und stellt die im Organigramm dargestellten Tools und Funktionen zur Verfügung. Auftraggeber: M. Künzli, FHBB 28 23.12.2004
4.1 Programmierung Die Webapplikation wird mit PHP programmiert. PHP ( PHP Hypertext Preprocessor ) ist eine Scriptsprache, die auf der Serverseite eine HTML Seite dynamisch generieren und anpassen kann. Die Website kann auf einer Datenbank basieren. Kompatibilitätsprobleme können ausgeschlossen werden, da auf der Benutzerseite reiner HTML-Code angezeigt wird. Im Anhang 5.3 Struktur, Programmierung wird der Aufbau der Webapplikation erläutert. Ein Kollaborationsdiagramm zeigt die Zusammenhänge der einzelnen Funktionen und Files. Einsicht in den Code gibt die Beilage Admintool für SNORT Programmierung. Der gesamte Quellcode befindet sich auf der Diplomarbeit-CD. 4.2 Benutzerhandbuch Die Anwendung des Admintools für SNORT, im Speziellen die Regeladministration, ist dem beiliegenden Benutzerhandbuch zu entnehmen. Die nächsten Kapitel beziehen sich hauptsächlich auf die Funktionalität und weniger auf die Handhabung der Webapplikation. Das Benutzerhandbuch befindet sich ebenfalls auf der Diplomarbeit-CD. 4.3 Layout und Browser Die Applikation wurde für eine Bildschirmauflösung von mindestens 1280 x 1024 Pixel entwickelt. Eine tiefere Auflösung ist möglich, jedoch nicht empfehlenswert, da Navigation und Inhalt nicht auf einer Seite dargestellt werden können. Die Webapplikation läuft unter den gängigen Browsern - Internet Explorer 6.x - FireFox 1.0 - Opera 7.5x - Netscape 7.x Empfohlen werden die Browser Internet Explorer und FireFox, welche vom Auftraggeber verwendet werden. Auftraggeber: M. Künzli, FHBB 29 23.12.2004
4.4 Regeladmin Die Kernaufgabe der Diplomarbeit und des Admintool für SNORT ist die Entwicklung des Bereichs Regeladmin, welche die Regelverwaltung beinhaltet. Die Hauptmerkmale der Regelverwaltung werden im Folgenden beschrieben. Für die Handhabung und Abbildungen des Tools wird auf das Benutzerhandbuch verwiesen. 4.4.1 SNORT Source Unter Source wird das Konfigurationsfile snort.conf sowie die Regelfiles mit den Regeln verstanden. Das Admintool für SNORT befindet sich im Webverzeichnis des Systems (unter SuSE /srv/www/htdocs); der Source von SNORT im Verzeichnis /etc/snort (unter SUSE). Die Regeladministration kann den Source via Browser bearbeiten, das heisst, der Source wird zum Lesen und Schreiben geöffnet. Zudem werden aus der Regeladministration Backups erstellt. Ein Webuser hat keine Berechtigung im Verzeichnis /etc Daten zu manipulieren. Deshalb arbeitet das Admintool für SNORT mit einer Kopie des Source, welches im Webverzeichnis abgelegt ist. Wie Abbildung 4.2 zeigt, muss der Source von /etc/snort nach /srv/www/htdocs/regeladmin/snort kopiert werden. Nachdem der Source bearbeitet wurde, muss er in das Verzeichnis von SNORT zurückkopiert werden. Abbildung 4.2 Bearbeiteter Source Admintool SNORT SNORT /etc/snort Admintool /srv/www/htdocs/ regeladmin/snort Backup Aktueller Source SNORT Admintool Auftraggeber: M. Künzli, FHBB 30 23.12.2004
Das Kopieren des Source wird mit Shell-Skripts gelöst. Aus dem PHP File werden die Shell- Skript gestartet. 4.4.1.1 Beispiel Source Import Unter Import wird das Kopieren des Source vom SNORT-Verzeichnis in das Admintool- Verzeichnis verstanden. Als Beispiel wird ein Auszug aus dem Shell-Skript importsnort.sh angezeigt, welches den aktuellen Source vom SNORT-Verzeichnis in das Verzeichnis des Admintools kopiert. 1 [...] 2 #Damit ich sicher im richtigen Verzeichnis bin 3 cd /etc/snort 4 #snort.conf vom snort verzeichnis ins regeladmin verzeichnis kopieren 5 cp snort.conf -f /srv/www/htdocs/regeladmin/snort 6 7 #regelfiles vom snort verzeichnis ins regeladmin verzeichnis kopieren 8 cp rules -rf /srv/www/htdocs/regeladmin/snort 9 10 cd /srv/www/htdocs/regeladmin/snort 11 [ ] importsnort.sh wird aus dem PHP File regeladmin.php mit Hilfe von Sudo aufgerufen: 1 [...] 2 exec('sudo./importsnort.sh'); 3 [...] 4.4.1.2 Erklärung Sudo Sudo ist ein Programm, welches bestimmten Benutzern Berechtigungen erteilen kann, zum Beispiel um auf einem bestimmten Rechner einzelne Kommandos als root (oder unter einer anderen User-ID) auszuführen. Dies ist mit oder ohne Eingabe des persönlichen Passwortes möglich. Im README von Sudo steht: ``The basic philosophy is to give as few privileges as possible but still allow people to get their work done.'' (Quelle zu Sudo: http://www.courtesan.com/sudo/man/sudo.html ) Mit Sudo besteht die Möglichkeit, als Benutzer ohne root-rechte Kommandos mit root- Berechtigung auszuführen. Im konkreten Beispiel wird dem Webbenutzer mittels root-berechtigung das Kopieren des Source aus dem Verzeichnis /etc/snort ermöglicht. Mit dem Kommandobefehl #visudo kann das Konfigurationsfile sudoers von sudo angepasst werden. Im File sudoers werden die Berechtigungen und Pfade gesetzt, mit welchen Sudo arbeitet. Informationen zur Handhabung von Sudo sind dem Link http://www.courtesan.com/sudo/man/sudo.html zu entnehmen. Auftraggeber: M. Künzli, FHBB 31 23.12.2004
Ausschnitt aus dem File sudoers: 1 [ ] 2 # See the sudoers man page for the details on how to write a sudoers file. 3 # Host alias specification 4 Host_Alias SERVER = localhost 5 6 # User alias specification 7 User_Alias USER = www, wwwrun, snort 8 9 # Cmnd alias specification 10 #Cmnd_Alias FOO =./etc/snort/updatesnortrules.sh 11 12 # Defaults specification 13 Defaults targetpw 14 %users ALL=(ALL) ALL 15 16 # User privilege specification 17 root ALL=(ALL) ALL 18 #www localhost=/etc/snort/updatesnortrules.sh 19 USER ALL=NOPASSWD:/etc/snort/updatesnortrules.sh 20 21 # Uncomment to allow people in group wheel to run all commands 22 # %wheel ALL=(ALL) ALL 23 24 # Same thing without a password 25 # %wheel ALL=(ALL) NOPASSWD: ALL 26 27 # Samples 28 # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom 29 # %users localhost=/sbin/shutdown -h now 4.4.2 Backup Wie aus Abbildung 4.2 ersichtlich, werden im Verzeichnis der Webapplikation Backups erstellt. Der SNORT-Source wird vor der Bearbeitung durch das Admintool für SNORT als Sicherungskopie abgespeichert. Bei fehlerhafter Regeladministration kann somit jederzeit die letzte lauffähige Version geladen werden. Die Backups werden im selben Verzeichnis angelegt, in welchem sich der Source befindet. Die Backup-Files und Verzeichnisse erhalten hinter dem eigentlichen Namen zusätzlich eine Datumsangabe. Es wird zum Beispiel das Konfigurationsfile snort.conf abgeändert. Das Backupfile erhält folgenden Namen: snort.conf_yyyymmddhh (Y = Jahr, M = Monat, D = Tag, H = Stunde). Stündliche Backups werden zur Verfügung gestellt. Benötigt der Benutzer Backups im Minutenbereich, muss die Backup-Funktion entsprechend angepasst werden. Ein stündliches Backup sollte gemäss Erfahrung genügen. Folgende Backups werden erstellt. - Konfigurationsfile snort.conf, Backup mit Datumsangabe Auftraggeber: M. Künzli, FHBB 32 23.12.2004
- Regelfiles im Verzeichnis /rules, Backup mit Datumsangabe - Regeln welche von der SNORT-Website zum Update heruntergeladen werden. Die aktuell bestehenden Regeln aus dem Verzeichnis /downrules werden nach /downrulesback verschoben, bevor die neusten Regeln von der Website bezogen werden. Der Benutzer der Webapplikation ist verantwortlich für das Verwalten der Backups. Die Backups bleiben im Webverzeichnis bestehen und müssen manuell entfernt oder kopiert werden. 4.4.3 SNORT Regeln herunterladen Die aktuellen SNORT-Regeln werden mit der Aktion Regel download von der SNORT- Website heruntergeladen. (weitere Informationen im Benutzerhandbuch Kapitel 4.2.4.1 Regeln downloaden ). Die Download-Aktion startet das Shell-Skritpt updatesnortrules.sh, welches sich im Verzeichnis [Webverzeichnis]/regeladmin/snort befindet. Das Shell-Skript ist für den Download der aktuell verfügbaren Regeln zuständig. Nach dem Herunterladen der Regeln werden diese entpackt und in das Verzeichnis downrules verschoben. Zuvor wird sicherheitshalber ein Backup der bestehenden heruntergeladenen Regeln erstellt (vom Verzeichnis downrules nach downrulesback). 4.4.3.1 Erklärung Shell-Script updatesnortrules.sh Das Shell-Skript verwendet das Programm wget. Die Funktionalität von wget ist mit einem Webbrowser zu vergleichen. Wget empfängt Files über das HTTP Protokoll. Mit #rpm q wget kann überprüft werden, ob wget auf dem System installiert ist. Falls wget nicht auf dem System installiert ist, kann es unter SuSE YaST nachinstalliert werden. Im Folgenden ist das Shell-Skript abgebildet. 1 #!/bin/sh 2 ########################################################################### 3 #Title: SNORT-Regeladmintool # 4 #Date: Dezember 2004 # 5 #Author: FHBB - Ph.S. # 6 #Content: Dieses Shell-Script lädt die aktuellen SNORT-Regeln herunter und# 7 # kopiert sie in den gewünschten Ordner. # 8 ########################################################################### 9 10 #Pfad für downgeloadete Regeln 11 RULESDIR=/etc/snort/downrules 12 13 #Pfad für Backup von RULESDIR Auftraggeber: M. Künzli, FHBB 33 23.12.2004
14 RULESDIRBAK=/etc/snort/downrulesback 15 16 #Pfad, von Programm wget 17 WGETPATH=/usr/bin 18 19 #SNORT-Regeln download von der URI: 20 #-->SNORT-Version beachten 21 RULESURI=http://www.snort.org/dl/rules/snortrules-snapshot-2_0.tar.gz 22 23 #wechsle in das Verzeichnis /tmp 24 #entferne den Ordner mit namen rules (falls existent) 25 cd /tmp 26 rm -rf rules 27 28 #herunterladen der neuen Regeln, Entpacken und entfernen des gz-files 29 $WGETPATH/wget $RULESURI 30 31 tar -zxf snortrules-snapshot-2_0.tar.gz 32 rm -f snortrules-snapshot-2_0.tar.gz 33 34 #Backup der bestehenden heruntergeladenen Regeln erstellen. 35 mv $RULESDIR/*.rules $RULESDIRBAK 36 37 #kopieren der neuen Regeln nach /downrules 38 mv /tmp/rules/*.rules $RULESDIR Wichtige Einstellungen sind die Pfadangaben, in welchem die Regeln abgespeichert werden. Zeile 21 gibt den Link an, von wo die SNORT-Regeln heruntergeladen werden. Zu berücksichtigen ist, dass die SNORT-Regeln der verwendeten SNORT-Version entsprechen müssen. In diesem Beispiel wird die SNORT-Version 2.0 angegeben. (weitere Informationen im Benutzerhandbuch Kapitel 4.2.4.1 Regeln downloaden ). 4.4.4 Erstellen der Datenbank für das Regeladmintool Die Datenbank regeladmin dient der Verwaltung der Regeln im Regeladmintool. Die Datenbank besteht aus folgenden Tabellen: Tabellenname: Beschreibung: - rule Enthält sämtliche Regeln, welche in Gebrauch sind - rulefile Enthält sämtliche Regelfiles, welche in Gebrauch sind - updaterule Enthält die neuen Regeln, welche heruntergeladen werden - updaterulefile Enthält die neuen Regelfiles, welche heruntergeladen werden - q1 Hilfstabelle für den Vergleich der Regeln - q2 Hilfstabelle für den Vergleich der Regeln - q3 Hilfstabelle für den Vergleich der Regeln - t1 Hilfstabelle für den Vergleich der Regelfiles - t2 Hilfstabelle für den Vergleich der Regelfiles - t3 Hilfstabelle für den Vergleich der Regelfiles Auftraggeber: M. Künzli, FHBB 34 23.12.2004