Snort-Regeln verstehen und eigene Signaturen erstellen

Nachdem wir im zweiten Teil die Installation und Grundkonfiguration von Snort behandelt haben, widmen wir uns nun dem Herzstück von Snort: den Regeln. Diese bestimmen, wie Snort den Netzwerkverkehr überwacht, welche Ereignisse erkannt werden und wann Alarme ausgelöst werden.

---

Aufbau einer Snort-Regel

Eine Snort-Regel besteht aus zwei Hauptbestandteilen:

1. Header: Definiert die Bedingungen, z. B. Protokoll, IP-Adressen, Ports
2. Optionen: Enthalten Details wie Meldungstexte, Muster oder Aktionen

Beispiel:

alert tcp any any -> 192.168.1.10 80 (msg:"HTTP-Zugriff erkannt"; sid:1000001; rev:1;)

• alert: Aktion (hier: Alarm auslösen)
• tcp: Protokoll
• any any: Beliebige Quelladresse und Port
• 192.168.1.10 80: Zieladresse und Port 80
• msg: Nachricht im Alarm-Log
• sid: Eindeutige Regel-ID
• rev: Revisionsnummer der Regel

---

Regelaktionen

Snort unterstützt verschiedene Aktionen:

• alert: Alarm auslösen
• log: Paket protokollieren
• pass: Verkehr ignorieren
• drop/reject: Paket im IPS-Modus blockieren

---

Optionen in Regeln

Optionen stehen in Klammern () und werden durch Semikolons getrennt:

• msg: Beschreibung der Regel
• content: Sucht nach Mustern im Paketinhalt
• sid: Eindeutige Regel-ID
• rev: Versionsnummer
• classtype: Kategorisierung des Alarms
• priority: Priorität für die Alarmbewertung

Beispiel mit Inhaltserkennung:

alert tcp any any -> any 80 (msg:"Verdächtiger HTTP-Request"; content:"/etc/passwd"; sid:1000002; rev:1;)

---

Regelquellen

• Community-Regeln: Kostenlos und von der Snort-Community gepflegt
• Talos-Regeln: Offiziell von Cisco bereitgestellt und regelmäßig aktualisiert
• Eigene Regeln: Individuell für interne Anwendungen und Netzwerke

Die Regeldateien befinden sich üblicherweise unter:

/etc/snort/rules/

---

Best Practices für Regelverwaltung

1. Regel-Updates automatisieren: z. B. mit PulledPork oder Oinkmaster
2. Eigene Regeln trennen: Benutzerdefinierte Regeln in separaten Dateien speichern
3. Performance beachten: Überflüssige Regeln deaktivieren, um Systemressourcen zu schonen
4. Regeln testen: Vor Produktiveinsatz in Testumgebungen prüfen