Suricata/Regeln/Syntax

Suricata Signaturen - verstehen, anpassen, erstellen

topic - Kurzbeschreibung

Beschreibung

Aufbau einer Regel

Beispiel

Netzwerkverkehr auf Verbindungsversuche zu einem Kommando-Server eines Bot-Netzes überwachen

• Solche Verbindungen sind ein starkes Indiz dafür, dass ein Rechner aus dem lokalen (zu schützenden) Netzwerk eine Schadsoftware installiert hat, die eine Fernsteuerung ermöglicht.
• Die Kommando-Server, die ein solches Bot-Netzwerk steuern, sind in diesem Fall unter den beiden IP-Adressen 69.60.114.5 und 69.64.52.243 erreichbar.

alert ip $HOME_NET any -> [69.60.114.5,69.64.52.243] any (msg:"Communication to CnC";
reference:url,www.shadowserver.org;
threshold: type limit, track by_src, seconds 3600, count 1;
flowbits:set,ET.BotccIP;
classtype:trojan-activity;
sid:2404032; rev:3548;)

Aktionen

Wie soll mit dem Paket weiter verfahren werden?

Option	Beschreibung
PASS	Das Paket wird nicht weiter analysiert und zur weiteren Verarbeitung an den Paketfilter weitergereicht. Über die Aktion können einzelne Regeln übersprungen werden, ohne diese komplett deaktivieren zu müssen.
DROP	Das Paket wird stillschweigend verworfen.
REJECT	Das Paket wird abgelehnt.
ALERT PASS	Das Paket wird nicht weiter analysiert und zur weiteren Verarbeitung an den Paketfilter weitergereicht. Über die Aktion können einzelne Regeln übersprungen werden, ohne diese komplett deaktivieren zu müssen.
DROP	Das Paket wird stillschweigend verworfen.
REJECT	Das Paket wird abgelehnt.
ALERT	Es wird eine Warnung erzeugt und z.B. zur weiteren Analyse in eine Logdatei gespeichert.

Im IDS-Modus ist stets nur die passive ALERT-Aktion zulässig.

• Eine Filterung über PASS, DROP oder REJECT ist nur im Inline-Modus möglich.
• Der Unterschied zwischen DROP und REJECT liegt in der Art, wie die Verbindung abgelehnt und beendet wird.
• Bei REJECT wird der Absender über die Ablehnung informiert (z.B.
• mit einem TCP-RST Paket), während bei einem DROP der Verbindungsaufbau in einem Timeout endet.

Protokoll

Es folgt das Protokoll, das entweder namentlich auf Transportebene (ip, tcp, udp, icmp) oder auf Anwendungsebene (http, tls, ftp, smb) angegeben wird.

• Auf Anwendungsebene versucht Suricata das eingesetzte Protokoll unabhängig vom Port zu erkennen und kann daher eigenständig auch z.B.
• eine HTTP-Kommunikation auf nicht-Standard-Ports erkennen und überwachen.

Quelle/Ziel

Anschließend müssen noch die IP-Adressen und TCP-Ports von Absender und Empfänger angegeben werden.

• Dabei kann zur Unterstützung auf Variablen wie zum Beispiel $HOME_NET zurückgegriffen werden:

$HOME_NET any -> [69.60.114.5,69.64.52.243] any

überwacht alle Verbindungen aus dem zu schützenden Netz auf die beiden IP-Adressen 69.60.114.5 und 69.64.52.243.

Parameter

In Klammern folgen weitere optionale Parameter

Parameter	Beschreibung
msg	Die Meldung, die im Erfolgsfall ausgegeben und geloggt werden soll: »Communication to CnC«.
reference	Hier können weitere Informationen wie URLs angegeben werden, die ein Output-Plugin verarbeiten kann. Viele existierende Regeln verweisen hier z.B. auf externe Angriffidentifizierungssysteme, wie bugtraq oder CVE.
sid und rev	Jede einzelne Regel wird mit einer eindeutigen Signature-ID (sid) in Verbindung mit der Revision des Regelwerks (rev) versehen. Dies ermöglicht z.B. eine automatisierte Pflege des Regelwerks, da jede Regel individuell über die sid angesprochen werden kann.
classtype	Eine grobe Klassifikation, die die Relevanz des Regelverstoßes einordnet. Der hier spezifizierte classtype muss in der Datei /etc/suricata/classification.rules näher beschrieben werden und reicht von leichten Verstößen, wie nicht zuzuordnender Netzwerkverkehr, bis hin zu schwerwiegenderen Ereignissen, wie z.B. Einbruchsversuchen.
priority	Überschreibt die aus der classtype abgeleitete Priorität.
content	Analysiert den Datenbereich eines Pakets. Hier sind umfangreiche Abfragen bis hin zu regulären Ausdrücken möglich.
flowbits	Ermöglicht die Analyse von zusammenhängenden Paketen, sodass eine Regel nur dann zutrifft, wenn auch andere zutreffen. So lässt sich z.B. ein Alarm wegen Übermittlung eines Passworts auf eine vorhergehende Login-Abfrage beschränken.
flow	Ermöglicht Einschränkungen bezüglich der Verbindung, z.B. ob eine TCP-Verbindung tatsächlich vollständig aufgebaut wurde.
vthreshold	Es können Schwellenwerte definiert werden und erst nach Überschreitung wird ein Alarm ausgelöst. So können z.B. fehlerhafte Login-Versuche als Brute Force erkannt werden, wenn innerhalb von 30 Sekunden mehr als 10 Versuche unternommen wurden, sich per SSH auf einem Rechner einzuloggen.
luajit	Wurde Suricata mit Unterstützung für den Just-In-Time Compiler für LUA kompiliert, kann für eine sehr komplexe Regel ein LUA-Skript herangezogen werden.

Ausgabe und Alarmierung

Suricata mit Echtzeit-Analyse und grafischer Oberfläche

Wird ein Alarm ausgelöst, gibt es viele Möglichkeiten, wie die Protokollierung erfolgen kann und wie die Regelverstöße auswertet werden können.

• Die einfachste Methode wäre ein »fastlog«, das jeden IDS-Alarm in einer Zeile einer Logdatei festhält und z.B. über ein eigenes Skript aufbereitet werden kann.
• Bis zum komplexen Logging und einem (u.U. datenbankgestützten) JSON-basierten Format EVE, das durch ElasticSearch, Logstash und Kibana aufbereitet und analysiert werden kann, sind viele Zwischenstufen denkbar.

Testfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5