39360.zip
Das skalierbare und effiziente Open-Source Network Intrusion Detection System (NIDS) Snort verwendet eine Reihe genau definierter Regeln, um anomale Pakete in Ihrem Netzwerk zu erkennen. Die Pflege dieser Regelsätze verbessert die Effektivität des Systems erheblich. Einige Techniken zur Regelverwaltung können Ihnen bei der Wartung Ihres Snort IDS helfen. Erstens können Sie eine Überlastung mit Alarmen verhindern, indem Sie die Variablendefinitionen straffen und Ihre Snort-Regeln pflegen. Außerdem können Sie Ihre benutzerdefinierten Regeln über Regelsatz-Upgrades hinweg beibehalten. Schließlich können Sie eine Regel dekonstruieren, um zu verstehen, wie Sie die Regeln an Ihre Umgebung anpassen können.
Standardmäßig enthält Snort mehr als 1900 Standardregeln in einer Reihe von fast 50 Textdateien, die nach Typ geordnet sind, wie Abbildung 1 zeigt. Diese Regeln definieren Reaktionsauslöser für viele bekannte Schwachstellenausnutzungen in Bezug auf Windows, UNIX und weit verbreitete Anwendungen wie Microsoft IIS, Apache, Microsoft SQL Server und Oracle SQL. Die Regeln helfen Snort auch dabei, Aufklärungsdaten und mögliche Konfigurationswarnungen bereitzustellen, um Sie vor Netzwerk-Scans oder einem Rechner zu warnen, der z. B. einen SNMP-Standard-Community-String sendet. Wie Sie sich vielleicht vorstellen können, kann Snort eine enorme Anzahl von Warnungen erzeugen. Um das Rauschen der Bestandsregeln zu reduzieren, sind in der Standardkonfiguration von Snort nur etwa 1300 der Regeln standardmäßig aktiviert und ganze Regeltypen, wie z. B. Policy, Chat und Virus, standardmäßig deaktiviert. (Ein Regeltyp ist in der Regel in einer eigenen Textdatei enthalten, so dass Regeln des Typs Virus in der Datei virus.rules enthalten sind). Überprüfen Sie alle deaktivierten Regelgruppen und aktivieren Sie alle, die auf Ihre Umgebung zutreffen könnten.
Beschneiden Sie Ihre Regeln
Auch mit den vielen Regeln, die Snort standardmäßig deaktiviert, wird Ihr Snort IDS-System wahrscheinlich viele Alarme erzeugen. Wenn Sie sich durch all diese Warnungen quälen, kann es sein, dass Ihre Sinne für wirklich verdächtigen Datenverkehr abgestumpft sind. Nachdem Sie Snort in Ihrer Umgebung installiert haben, sollten Sie die Regeln beschneiden, um diejenigen zu entfernen, die sich nicht auf Ihre Umgebung beziehen oder die Sie nicht betreffen. Wenn Sie zum Beispiel nicht über die in HTML eingebettete Skriptsprache PHP verfügen: Hypertext Preprocessor (PHP) in Ihrer Umgebung nicht installiert haben, können Sie die Regeldatei web-php.rules deaktivieren. Bei der Entscheidung, welche Regeln deaktiviert werden sollen, sollten Sie jedoch berücksichtigen, dass auf den Rechnern der Benutzer verschiedene Software installiert sein könnte. Zum Beispiel könnte einer Ihrer Snort-Sensoren verdächtige Pakete von einem kompromittierten Heimcomputer über eine VPN-Verbindung auffangen. Um das vorherige Beispiel fortzusetzen: Selbst wenn Sie auf keinem Ihrer Firmencomputer PHP installiert haben, könnte einer Ihrer Endbenutzer es zu Hause installiert haben. Wenn dieser Heimcomputer durch eine PHP-Schwachstelle kompromittiert würde, könnte der Angreifer auf Ihr Unternehmensnetzwerk zugreifen, während der kompromittierte Computer mit dem Unternehmensnetzwerk verbunden ist (z. B. über eine VPN-Verbindung).
Die meisten Warn- und Berichtssysteme zeigen den Namen und die SID für jede Regel an, damit Sie sie leicht finden können. Um die Liste der aktivierten Regeln weiter zu reduzieren, überwachen Sie Ihre Systeme, notieren Sie sich die Namen oder SIDs nicht benötigter Regeln und deaktivieren Sie diese Regeln dann. Um eine Snort-Regel manuell zu deaktivieren, öffnen Sie die Regeldatei und fügen Sie ein Pfundzeichen (#) vor der Regel ein. Um eine ganze Klasse von Regeln zu deaktivieren, fügen Sie in der Snort-Konfigurationsdatei ein Ordnungszeichen vor dem Dateinamen der Regel ein. Sie müssen Snort neu starten, um die geänderten Regeln zu laden.
Wenn Sie Ihre Regeln regelmäßig überprüfen und diejenigen, die nicht auf Ihr Netzwerk zutreffen, weiterhin eliminieren, wird die Anzahl der von Snort generierten Warnungen drastisch reduziert, wodurch es einfacher wird, wirklich verdächtige Pakete zu erkennen und zu identifizieren. Und denken Sie daran, Regeln bei Bedarf wieder zu aktivieren, wenn Sie neue Technologien einführen, die durch deaktivierte Regeln geschützt werden könnten.
Regeln aktuell halten
Snort.org stellt zwei Versionen von Snort-Regeln bereit: snortrules-stable und snortrules-current, die mit Snort 2.0x bzw. Snort 1.9x funktionieren. Die neueren Regeln enthalten zusätzliche Signaturen und Aktualisierungen bestehender Regeln, um die erweiterten Variablen zu nutzen. So werden in den Regeln der Version 2.0.0 Variablen definiert, die bestimmte Maschinenfunktionen beschreiben (z. B. charakterisieren die Variablen HTTP_SERVERS und HTTP_PORTS Computer, die Webdienste ausführen und anfällig für Webdienstangriffe sein könnten). Diese neuen Variablen werden in den neuen Regeln verwendet, um eingehende Angriffe weiter zu filtern. Eine alte Regel könnte Sie auf eine verdächtige HTTP-Anfrage aufmerksam machen, die für einen beliebigen Computer in Ihrem Netzwerk bestimmt ist. Die neue Regel sucht jedoch nur dann nach demselben Angriff, wenn er für einen Webserver bestimmt ist, der durch die Variable HTTP_SERVERS definiert ist. Dieser Klassifizierungsprozess trägt dazu bei, Fehlalarme zu reduzieren.
Snort.org aktualisiert die Regelsätze häufig, um mit neuen Entdeckungen von Angriffen auf dem Laufenden zu bleiben. Um auf dem neuesten Stand zu bleiben, sollten Sie regelmäßig nach neuen Regeln suchen, diese herunterladen und anwenden, die in Ihrer Umgebung nützlich sein könnten. Beachten Sie jedoch, dass jedes Mal, wenn Sie einen Satz neuer Regeln herunterladen, die Textdateien, die die neuen Regeln enthalten, diejenigen überschreiben, die die alten Regeln enthalten. Sie werden schnell feststellen, dass es mühsam ist, jedes Mal, wenn Sie Ihre Regeldateien aktualisieren, alle unbenutzten Regeln auszukommentieren.
Oinkmaster zur Rettung
Glücklicherweise gibt es mehrere Open-Source-Tools, die Ihnen helfen können, dieses Problem zu lösen. Ein Perl-Skriptprogramm namens Oinkmaster, das Sie von http://www.algonet.se/~nitzer/oinkmaster herunterladen können, automatisiert den Download neuer Regeln und verwaltet deaktivierte oder geänderte Regeln. Das Perl-Skript ist auf UNIX-Systeme zugeschnitten und verwendet die Tools wget, tar und gzip, um neue Regeln zu holen und zu erweitern, sobald das Skript ausgeführt wird. Die meisten dieser Tools sind auf UNIX-Systemen installiert, aber Sie können die Tools auch für Windows herunterladen. Denken Sie daran, dass für Open-Source-Lösungen nur ein begrenzter Support zur Verfügung steht (wenn überhaupt), suchen Sie also online nach Lösungen für Probleme oder Fragen, die Sie haben könnten. Die Open-Source-Software-Community (OSS) bietet eine Fülle nützlicher Informationen. Ein guter Anfang ist das Abonnieren einer der Snort-Mailinglisten, für die Sie sich unter http://www.snort.org/lists.html.
anmelden können. Beachten Sie unbedingt die README-Datei für detaillierte Installationsanweisungen für Ihre Plattform. Das grundlegende Oinkmaster-Installationsverfahren besteht darin, die Dateien oinkmaster.pl und oinkmaster.conf in Ihr Snort-Verzeichnis (oder ein von Ihnen angegebenes Verzeichnis) zu erweitern und dann oinkmaster.conf zu verwenden, um Oinkmaster zu konfigurieren.
Öffnen Sie oinkmaster.conf und folgen Sie den Inline-Kommentaren, um das Tool zu konfigurieren. Bestätigen Sie zunächst den Speicherort der aktualisierten Regeln als Webadresse (z. B. http://www.snort.org/dl/signatures/snortrules.tar.gz). Achten Sie darauf, dass Oinkmaster auf eine vertrauenswürdige und seriöse Website verweist, insbesondere wenn Sie die Regeln automatisch herunterladen und installieren möchten. Andernfalls laufen Sie Gefahr, beschädigte (oder schlimmer noch, manipulierte) Regeln herunterzuladen, die Ihr IDS gefährden könnten.
Als Nächstes geben Sie die Dateien an, die übersprungen, geändert und deaktiviert werden sollen. Standardmäßig verarbeitet Oinkmaster die Dateien local.rules und snort.conf nicht (d.h. es überspringt sie).
Mit der Funktion modifysid des Skripts können Sie neu heruntergeladene Regeln ändern; stellen Sie sich modifysid als eine Funktion zum Suchen und Ersetzen einer bestimmten Regel vor, die Sie anhand der SID identifizieren. Mit diesem Befehl können Sie den Text einer bestimmten Regel ändern. So können Sie beispielsweise mit modifysid eine Regel aktivieren, die standardmäßig deaktiviert ist. Fügen Sie dazu einen neuen modifysid-Befehl hinzu, der die Regel identifiziert, die Sie aktivieren möchten, und weisen Sie ihn an, das Kommentarzeichen (#) zu entfernen. Jedes Mal, wenn ein neuer Regelsatz heruntergeladen wird, wird dieses Kommentarzeichen entfernt, wenn Oinkmaster diese Regel analysiert. Sie können auch modifysid verwenden, um den Aktionstyp einer Regel zu erhöhen. Zum Beispiel erhöht der Befehl
modifysid 2003 "alert" | "sev1"
den Alarm mit einer SID von 2003 auf einen benutzerdefinierten Aktionstyp von sev1. Oinkmaster tut dies, indem es nach „alert“ sucht und es durch „sev1“ ersetzt. Und ja, es werden mehrere Ersetzungen vorgenommen, also verwenden Sie es mit Vorsicht.
Die letzte und beliebteste Funktion von Oinkmaster, disablesid, lässt Sie ausgewählte Regeln deaktivieren. Geben Sie die SIDs aller Regeln an, die deaktiviert bleiben sollen. Um beispielsweise die Alarmierung bei Netzwerk-Scans zu deaktivieren, könnten Sie mit einem Eintrag ähnlich wie
disablesid 469, 615, 618, 620
beginnen. Nachdem ein neuer Satz von Regeln heruntergeladen und analysiert wurde, sucht Oinkmaster nach den angegebenen SIDs und kommentiert die Regeln aus. Solange Oinkmaster Ihre Regeln verwaltet, bleiben die Regeln deaktiviert, auch bei Aktualisierungen des Regelsatzes.
Führen Sie das Skript manuell aus, wenn Sie Ihre Regeln aktualisieren möchten. Wenn Sie es sich zutrauen, können Sie das Skript so planen, dass es in regelmäßigen Abständen ausgeführt und die Regeln aktualisiert werden. Oinkmaster holt die Regeln, erweitert sie und kopiert sie in das Regelverzeichnis Ihres Sensors. Wie bei den meisten OSS sollten Sie Oinkmaster mit Bedacht einsetzen und sich zunächst darüber informieren, was es tut und wie es sich auf Ihre Umgebung auswirken wird. Testen Sie z. B. einen neuen Satz von Regeln, indem Sie Snort im Selbsttestmodus ausführen (indem Sie snort -T und Ihre anderen Parameter verwenden), bevor Sie die Regeln in Ihrer Produktionsumgebung einsetzen.
Oinkmaster lässt Sie die Risiken des Herunterladens zweifelhafter Updates vermeiden, indem es Ihnen die Möglichkeit gibt, alte Regeln zu sichern und ein Protokoll seiner Aktionen an die Konsole zu liefern. Überprüfen Sie diese Ausgabe, die entfernte Regeln, geänderte aktive Regeln, Revisionen von Nicht-Regeln und neue Dateien anzeigt, um zu bestätigen, dass Oinkmaster seine Aufgaben erfolgreich abgeschlossen hat und um die Regeln zu bestätigen, die Oinkmaster geändert hat. Wenn Sie die automatische Ausführung von Oinkmaster planen, sollten Sie in Erwägung ziehen, die Ergebnisse per E-Mail zu versenden, um die Überprüfung zu erleichtern, wie in Abbildung 2 dargestellt. Das folgende Beispiel zeigt, wie Sie Oinkmaster mit dem Linux-Befehl crontab (crontab ermöglicht die Planung von Aufträgen unter Linux) für die tägliche Ausführung um 6:15 Uhr einplanen können:
15 6 * * * /home/snort/oinkmaster.pl -o /home/snort/rules -b /home/snort/backup 2>&1 | mail -s "Oinkmaster"
Die Oinkmaster-Parameter geben das Regelverzeichnis (-o), das Verzeichnis für die Sicherungsregeln (-b) und einen Befehl für die Übermittlung der Ergebnisse per E-Mail an den Eigentümer an. Der Befehl 2>&1 sendet die StdErr-Ausgabe an StdOut (die Konsole), bevor sie an die E-Mail-Anwendung gesendet wird.
Betrachten Sie eine Snort-Regel
Neben der Deaktivierung oder grundlegenden Änderung der Standardregeln können Sie auch eigene Regeln erstellen und die Snort-Regeln direkt an Ihre Umgebung anpassen. Nehmen wir zum Beispiel einen Sensoreinsatz, der den Verkehr innerhalb und außerhalb Ihrer Firewall überwacht. Auch wenn es Sie vielleicht interessiert, wie viele Wurmangriffe Ihre Firewall abwehrt, so wird es Sie wahrscheinlich noch mehr interessieren, ob einer dieser Angriffe von innerhalb Ihres Netzwerks ausgegangen ist. In letzter Zeit wurden die Snort-Regeln um „abgestimmte“ Regeln wie das obige Beispiel erweitert, aber es gibt noch viele andere Regeln, die Sie vielleicht in ähnlicher Weise anpassen möchten. Listing 1 zeigt eine Standardregel, die Sie warnt, wenn sie den SQL Slammer (auch bekannt als Sapphire) Wurm entdeckt. Lassen Sie uns diese Regel schnell dekonstruieren. (Detaillierte Informationen zu allen verfügbaren Parametern, die die Regeln definieren, finden Sie in der ausführlichen Snort-Regeldokumentation unter http://www.snort.org/docs/writing_rules/chap2.html#tth_sec2.3.26.)
Alle Regeln müssen in einer Zeile stehen und mit einer Regelaktion beginnen, die in diesem Fall lautet:
alert
Die Regelaktion definiert, wie Snort auf die Regel reagiert, wenn sie ausgelöst wird. Sie können den Regeltyp ändern (z. B. in eine Zeichenkette wie „sev1“), um eine benutzerdefinierte Behandlung zu ermöglichen, z. B. um die Aktion im Falle einer Übereinstimmung zu eskalieren. Dieser Schritt unterscheidet sich vom vorherigen Beispiel, in dem wir Oinkmaster verwendet haben, um den Alarmtyp einer bestehenden Regel zu ändern; in diesem Beispiel erstellen wir eine neue Regel, indem wir eine bestehende Regel als Vorlage verwenden.
Der Parametersatz
udp $EXTERNAL_NET any -> $HOME_NET 1434
gibt das Protokoll, die IP-Adresse, die Portinformationen und die Verkehrsrichtung für die Regel an. Diese Regel weist Snort an, jedes UDP-Paket von einer Netzwerkquelle (die durch die Variable $EXTERNAL_NET definiert ist) zu finden, das versucht, an die Variable $HOME_NET an Port 1434 zu gehen. Die meisten Standardregeln verwenden hauptsächlich die Variablen $EXTERNAL_NET und $HOME_NET. Einige Regeln verwenden jedoch auch spezifischere Variablen. Zum Beispiel verwenden die Regeln, die sich auf DNS-Server beziehen (in der Datei dns.rules), die Variable $DNS_SERVERS. Definieren Sie diese Variablen in der Snort-Konfigurationsdatei (normalerweise snort.conf). Optional können Sie Ihre eigenen Variablen erstellen, um Ihre Topologie widerzuspiegeln (z. B. $MAIL_SERVERS) und für die Verwendung in benutzerdefinierten Regeln. Definieren Sie eine Variable mit ihrem Namen (z. B. var MAIL_SERVERS= 192.168.0.20/30) und referenzieren Sie die Variable mit einem vorangestellten Dollarzeichen ($ – z. B. $MAIL_SERVERS). Die Regelaktion und diese Parameter bilden den Regelkopf.
Die Regeloptionen verfeinern die Regel weiter, so dass ein verdächtiges Paket (und nur ein verdächtiges Paket) eine Antwort auslösen wird. Wie Sie sich denken können, können diese Signaturen sehr detailliert werden und weit über den einfachen Portabgleich hinausgehen. Stellen Sie sich zum Beispiel die Fehlalarme vor, die entstehen würden, wenn diese Slammer-Regel Sie einfach nur vor jeglichem Verkehr über den UDP-Port 1434 warnen würde.
Die Option msg
msg:"MS-SQL Worm propagation attempt"
liefert eine einfache Beschreibung des Alarms für die Verwendung bei Alarmierungs- und Berichtsaktivitäten. Die Option content
content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";content:"sock"; content:"send";
enthält die Zeichenkette für den Abgleich des Nutzdatenmusters unter Berücksichtigung der Groß- und Kleinschreibung, entweder in ASCII- oder Hexadezimalwerten (Hex-Werte mit dem Pipe-Zeichen einschließen -|). Sie können mehrere Inhaltsoptionen angeben. Die Option depth folgt jeder Inhaltsoption und gibt an, wie viele Bytes in der Nutzlast nach dem angegebenen Inhalt gesucht werden soll. In diesem Beispiel löst ein Paket eine Antwort aus, wenn es den Hex-Wert 04 im ersten Byte oder den restlichen Inhalt irgendwo in der Nutzlast enthält.
Die heruntergeladenen Regeln enthalten oft Verweise auf detaillierte Informationen über den verdächtigen Exploit oder den Grund für die Erstellung der Regel. Einige Meldesysteme unterstützen die Referenzoption, indem sie direkte Links zu diesen Informationen bereitstellen:
reference:bugtraq,5310; reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm;
Snort ordnet die Regeln Klassen zu und weist diesen Klassen eine hohe, mittlere oder niedrige Priorität zu. Derzeit gibt es mehr als 30 Klassifizierungen, darunter attempted-admin, trojan-activity, attempted denial of service und network-scan. In unserem Beispiel lautet die Klassifizierung
classtype:misc-attack
Snort zeichnet die Antwortpriorität für erkannte Eindringlinge auf. Sie können ein externes Tool oder Skript verwenden, um diese Priorität weiter zu analysieren und mit Ihrer Berichtsanwendung Maßnahmen zu ergreifen.
Im letzten Segment
sid:2003; rev:2;
sid stellt eine eindeutige Snort-Regel dar, und rev bezeichnet die Revisionsnummer. Diese Eigenschaften identifizieren die Regel eindeutig.
Anpassen der Regel
Untersuchen wir nun, wie diese Regel angepasst werden kann, um eine eskalierte Warnung zu liefern, wenn sie intern infizierte Hosts entdeckt. Da wir es mit demselben Exploit wie bei der ursprünglichen Regel zu tun haben, bleibt die Inhaltsdefinition der Regel gleich. Wir müssen nur die IP-Adressen und die Richtung des Datenverkehrs ändern. Ändern wir die Quell-IP-Adresse in $HOME_NET wie folgt:
udp $HOME_NET any -> $EXTERNAL_NET 1434
Snort.conf definiert $EXTERNAL_NET als „any“, so dass diese Regel immer noch beschädigte Pakete abfängt, die auf interne Hosts abzielen (wie die ursprüngliche Regel). Da wir nun jedoch eine spezielle Regel haben, die nur interne Quell-IP-Adressen verfolgt, können wir den Aktionstyp in einen benutzerdefinierten Aktionstyp ändern, der einen eskalierten Alarm auslöst.
Die aktuellen Snort-Regeln enthalten diese Regel zur Erkennung ausgehender Slammer-Würmer im Standard-Regelsatz. Wenn sich jedoch ein neuer Wurm, Virus oder ein anderer Exploit zu verbreiten beginnt, sollten Sie in Erwägung ziehen, neue Regeln zu erstellen, die auf bestimmte Eindringlinge hinweisen.
Erstellen Sie Ihre Regeln
Zusätzlich zu bestehenden oder benutzerdefinierten Regeln, die Sie ändern oder erstellen können, sollten Sie auch Regeln einbeziehen, die Sie aus anderen Quellen erhalten. Wenn zum Beispiel ein neuer Wurm im Internet auftaucht, werden auf Sicherheitsseiten und in Newsgroups schnell einmalige Snort-Regeln veröffentlicht, die den neuen Wurm erkennen können. Fügen Sie diese neuen Regeln in die Datei local.rules ein und starten Sie Snort neu, damit die neuen Regeln wirksam werden.
Snort bietet den Rahmen für ein kostengünstiges und anpassbares IDS. Unterstützt durch einen von der Community unterstützten Regelsatz bleibt Snort ein flexibles und effektives System. Wenn Sie Ihre Regeln auf dem neuesten Stand halten, erhöhen Sie Ihre Wachsamkeit und verringern das Rauschen, das durch unwirksame Warnungen entsteht. Wie bei jedem Open-Source-Projekt sollten Sie sich die Zeit nehmen, um die Funktionsweise zu verstehen und sich mit den von der Community entwickelten Add-Ons vertraut zu machen, damit Sie sich mit dem System besser zurechtfinden und seine Wirksamkeit in Ihrer Umgebung erhöhen können.