Dieser Beitrag wird Ihnen helfen, effektive Snort-Regeln zu schreiben, um Ihre Sicherheitslage wesentlich zu verbessern. Wir beginnen mit einer Aufschlüsselung, wie eine Regel aufgebaut ist, und erkunden dann Best Practices mit Beispielen, um so viele bösartige Aktivitäten wie möglich zu erfassen und dabei so wenige Regeln wie möglich zu verwenden.
Snort ist ein Open-Source-Netzwerk-Intrusion-Detection-System (NIDS), das eine Echtzeit-Paketanalyse bietet und Teil der Coralogix STA-Lösung ist. Wenn Sie ein Coralogix STA-Kunde sind, lesen Sie bitte auch meinen früheren Beitrag über die Bearbeitung von Snort-Regeln in STA.
Anatomie von Snort-Regeln
Bevor wir in die verschiedenen Strategien zum Schreiben Ihrer besten Snort-Regeln eintauchen, lassen Sie uns mit der Analyse einer Beispiel-Snort-Regel beginnen:
alert: weist Snort an, dieses Verhalten als Alarm zu melden (es ist obligatorisch in Regeln, die für STA erstellt werden).
tcp: bedeutet, dass diese Regel nur für TCP-Verkehr gilt.
any: bedeutet in diesem Zusammenhang „von jedem Quellport“, dann gibt es einen Pfeil ‚->‘, der „eine Verbindung zu“ bedeutet (es gibt keinen ‚<-‚-Operator, aber Sie können die Argumente einfach um den Operator herum drehen. Sie können den Operator ‚<>‘ verwenden, um anzugeben, dass die Verbindungsrichtung für diese Regel irrelevant ist), dann einen IP-Bereich, der die Ziel-IP-Adresse angibt, und dann den Port. Sie können einen Portbereich mit einem Doppelpunkt angeben, z. B. 0:1024, was 0-1024 bedeutet.
msg: ist eine Direktive, die einfach die Nachricht festlegt, die gesendet wird (im STA-Fall an Coralogix), falls ein übereinstimmender Datenverkehr entdeckt wird.
flow: ist eine Direktive, die angibt, ob der Inhalt, den wir als unsere Signatur definieren, in der Kommunikation zum Server („to_server“) oder zum Client („to_client“) erscheinen muss. Dies kann sehr nützlich sein, wenn wir z.B. die Antwort des Servers erkennen wollen, die anzeigt, dass er verletzt wurde.
established: ist eine Direktive, die Snort veranlasst, die Suche nach Paketen, die dieser Signatur entsprechen, auf Pakete zu beschränken, die Teil einer bestehenden Verbindung sind. Dies ist nützlich, um die Last auf Snort zu minimieren.
uricontent: ist eine Direktive, die Snort anweist, nach einem bestimmten Text im normalisierten HTTP-URI-Inhalt zu suchen. In diesem Beispiel suchen wir nach einer URL, die genau den Text „/root.exe“ enthält.
nocase: ist eine Direktive, die angibt, dass Snort eine Suche ohne Berücksichtigung der Groß- und Kleinschreibung durchführen soll.
classtype: ist eine Direktive, die ein Metadaten-Attribut ist, das angibt, welche Art von Aktivität diese Regel erkennt.
reference: ist eine Direktive, die ein Metadaten-Attribut ist, das auf ein anderes System für weitere Informationen verweist. In unserem Beispiel verweist der Wert url,<https://….> auf eine URL im Internet.
sid: ist eine Direktive, die ein Metadatenattribut ist und die Signatur-ID angibt. Wenn Sie Ihre eigene Signatur erstellen (auch wenn Sie nur eine eingebaute Regel ersetzen), verwenden Sie einen Wert über 9.000.000, um eine Kollision mit einer anderen bereits vorhandenen Regel zu vermeiden.
rev: ist eine Direktive, die die Version der Regel angibt.
Es gibt noch viel mehr über Snort-Regeln zu lernen, die RegEx-Parsing, protokollspezifisches Parsing (genau wie uricontent für HTTP), die Suche nach binären (nicht-textuellen) Daten unter Verwendung von Byte-Hex-Werten und vieles mehr unterstützen. Wenn Sie mehr wissen möchten, können Sie hier beginnen.
Best Practices to Writing Effective Snort Rules
- Target the vulnerability, not the exploit – Vermeiden Sie es, Regeln für die Erkennung eines bestimmten Exploit-Kits zu schreiben, denn es gibt unzählige Exploits für dieselbe Schwachstelle und wir können sicher sein, dass neue geschrieben werden, während Sie dies lesen. Zum Beispiel sahen viele der frühen Signaturen zur Erkennung von Pufferüberlauf-Angriffen so aus:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")
Der Grund dafür ist natürlich, dass der Angreifer, um einen erfolgreichen Pufferüberlauf-Angriff zu starten, den Puffer einer bestimmten Variable füllen und seine bösartige Nutzlast am Ende hinzufügen muss, damit sie ausführbar wird. Die Zeichen, die er zum Füllen des Puffers verwendet, sind völlig unbedeutend, und in der Tat haben nach dem Auftauchen solcher Signaturen viele Angriffs-Toolkits einfach einen oder mehrere andere Buchstaben zum Füllen des Puffers verwendet und sind so der Erkennung dieser Art von Signaturen vollständig entgangen. Ein viel besserer Weg wäre es, zu versuchen, diese Art von Angriffen zu erkennen, indem man falsche Eingaben in Felder auf der Grundlage ihres Typs und ihrer Länge erkennt.
- Ihre Besonderheit ist Ihr bestes Kapital, also nutzen Sie es – Jede Organisation hat Dinge, die sie einzigartig machen. Viele davon können sehr nützlich sein, wenn Sie versuchen, bösartige Aktivitäten in Ihrer Organisation zu erkennen – sowohl externe als auch interne. Indem Sie dieses tiefe interne Wissen zu Ihrem Vorteil nutzen, verwandeln Sie das Problem von einem technologischen in ein rein nachrichtendienstliches Problem alter Schule und zwingen die Angreifer dazu, Ihre Organisation viel besser zu verstehen, um ihre Spuren effektiv zu verwischen. Diese Dinge können technologischer Natur sein oder auf den besonderen Arbeitsgewohnheiten und internen Richtlinien Ihrer Organisation beruhen. Hier sind einige Beispiele:
- Typische Arbeitszeiten: In einigen Organisationen, in denen ich gearbeitet habe, war es den Mitarbeitern überhaupt nicht gestattet, von zu Hause aus zu arbeiten, und die meisten Mitarbeiter hatten das Büro bereits um 19.00 Uhr verlassen. In solchen Unternehmen wäre es sinnvoll, einen Alarm einzurichten, der Sie über Verbindungen aus dem Büro nach einer bestimmten Uhrzeit informiert. Ein Angreifer, der in Ihrer Organisation Schadsoftware installieren würde, müsste dieses Verhalten kennen und seine Schadsoftware so einstellen, dass sie mit ihren Command & Control-Servern genau zu dieser Zeit kommuniziert, damit eine solche Kommunikation unbemerkt bleibt.
- Typischer Browser: Angenommen, Ihr Unternehmen hat beschlossen, den Brave-Browser als Hauptbrowser zu verwenden, und er wird automatisch auf jedem neuen Firmen-Laptop installiert, und Sie haben die Desktop-Verknüpfungen zum IE/Edge-Browser von allen Firmen-Laptops entfernt. Wenn dies der Fall ist, sollte eine Verbindung von der Organisation, sowohl zu einer internen als auch zu einer externen Adresse, die einen anderen Browser wie IE/Edge verwendet, so konfiguriert werden, dass ein Alarm ausgelöst wird.
- IP-Bereiche auf der Grundlage von Rollen: Wenn es Ihnen möglich ist, verschiedenen Servern je nach ihrer Rolle unterschiedliche IP-Bereiche zuzuweisen, z. B. alle DB-Server auf 192.168.0.0/24, die Webserver auf 192.168.1.0/24 usw., dann wäre es möglich und sogar einfach, clevere Regeln auf der Grundlage des erwarteten Verhaltens Ihrer Server je nach ihrer Rolle aufzustellen. Zum Beispiel stellen Datenbankserver normalerweise keine Verbindung zu anderen Servern her, Drucker versuchen nicht, eine Verbindung zu Ihren Domänencontrollern herzustellen, usw.
- Ungewöhnliche Verbindungsversuche: Viele Unternehmen verwenden eine öffentliche Freigabe auf einem Dateiserver, damit ihre Benutzer Dateien gemeinsam nutzen können, und verwenden netzwerkfähige Drucker, damit ihre Benutzer direkt von ihren Computern aus drucken können. Das bedeutet, dass Client-Computer keine Verbindung zueinander herstellen sollten, selbst wenn Sie (klugerweise) entschieden haben, einen solchen Zugriff in einer Firewall oder am Switch zu blockieren. Schon der Versuch, eine Verbindung von einem Client-Computer zu einem anderen Client-Computer herzustellen, sollte einen Alarm auslösen und gründlich untersucht werden.
- Ungewöhnliche Ports: Einige Organisationen verwenden eine spezielle Bibliothek zur Optimierung der Kommunikation zwischen Diensten, so dass die gesamte HTTP-Kommunikation zwischen Servern einen anderen Port als die üblichen verwendet (z. B. 80, 443, 8080 usw.). In diesem Fall ist es eine gute Idee, eine Regel zu erstellen, die bei jeder Kommunikation über diese normalerweise üblichen Ports ausgelöst wird.
- Honeytokens – In einem Schlachtfeld wie dem Internet, in dem jeder so ziemlich jeder sein kann, funktioniert die Täuschung für die Verteidiger genauso gut wie für die Angreifer, wenn nicht sogar besser. Tricks wie die Umbenennung des eingebauten Administratorkontos in einen anderen, weniger attraktiven Namen und die Erstellung eines neuen Kontos mit dem Namen „Administrator“, das Sie nie benutzen werden, sowie die Erstellung einer Snort-Regel zur Erkennung, ob dieser Benutzername, diese E-Mail oder dieses Passwort jemals im Netzwerk verwendet werden. Für Angreifer wäre es nahezu unmöglich, zu bemerken, dass Snort ihre Versuche, den gefälschten Administrator-Benutzer zu verwenden, erkannt hat. Ein weiteres Beispiel ist die Erstellung von gefälschten Produkten, Kunden, Benutzern und Kreditkartendatensätzen in der Datenbank und die Anpassung von Snort-Regeln, um diese im Netzwerkverkehr zu erkennen.
Wir hoffen, dass Sie diese Informationen hilfreich fanden. Weitere Informationen über die Coralogix STA finden Sie in den neuesten Funktionen, die wir kürzlich veröffentlicht haben.