Suricata/Regeln: Unterschied zwischen den Versionen

Versionsgeschichte interaktiv durchsuchen

VisuellWikitext

Aktuelle Version vom 30. Mai 2023, 22:28 Uhr

topic - Kurzbeschreibung

Beschreibung

Regelwerk

Signaturen spielen in Suricata eine wichtige Rolle

Aktualität
Genauigkeit

Bestehende Regelsätze

Installation von Regelsätzen

https://suricata.readthedocs.io/en/suricata-6.0.0/rule-management/suricata-update.html

Frei verfügbaren Regelwerken

emergingthreats.net

Kommerzieller Anbieter

aktueller
besondere Bereiche

/etc/suricata/rules

Suricata sucht die Regeln standardmäßig in /etc/suricata/rules

Regeln thematisch zu Suricata zusammengefasst

snort kompatibel

Auch, wenn es möglich ist, neue Regeln manuell zu installieren, gibt es einfachere Wege

Suricata-Regeln sind snort kompatibel

so lassen sich bestehende Werkzeuge zur Regelaktualisierung nutzen

Regelaktualisierung

Automatisieren

oinkmaster

# oinkmaster -i -u http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz -o /etc/suricata/rules

oinkmaster

lädt ein Archiv des Regelwerks von der angegebenen URL herunter
speichert sie in rules-Dateien im Verzeichnis /etc/suricata/rules/

Dabei werden eventuell vorhandene rules-Dateien überschrieben

Damit dennoch lokale Änderungen vorgenommen werden können und nicht überschrieben werden, verfügt jede einzelne Regel über eine (hoffentlich eindeutige) ID
Diese können über die enablesid, disablesid und modifysid in der Datei /etc/oinkmaster.conf bekannt gemacht werden
Wurde etwa eine ID über disablesid deaktiviert, so sorgt oinkmaster beim Update dafür, dass sie nicht wieder aktiviert wird

Aktuell finden sich im frei verfügbaren Open Ruleset von Emerging Threats mehr als 80.000 Regeln, die sich auf unterschiedliche Bereiche aufteilen

Kommunikation mit Bot-Netzen und deren Infrastruktur
Verbindungen, die aus unterschiedlichsten Gründen unerwünscht sein können (IP reputation database)
Unerwünschte Web-Inhalte (ActiveX, Chat, Java-Applets)
Antworten auf (erfolgreich durchgeführte) Angriffe
Protokoll-spezifische Angriffsmuster (z. B. DNS, FTP, ICMP, POP3, RPC, SNMP, SQL, VoIP)
DOS-Attacken
Angriffe auf bekannte Sicherheitslücken und Standard-Kennwörter
Kommunikation von Spyware-Software und Trojanern
Kommunikation mit Tauschbörsen und Peer-to-Peer Netzwerken
Kommunikation mit bekannten Security-Scannern (Portscans, automatisierte SQL-Injection-Tests, metasploit-Scans)
Verschlüsselte Kommunikation (Tor-Netzwerkverkehr)

Anhang

Siehe auch

Sicherheit

Dokumentation

Links

Projekt

Weblinks

@@ Zeile 1: / Zeile 1: @@
+'''topic''' - Kurzbeschreibung
+== Beschreibung ==
 == Regelwerk ==
-; Mit der Aktualität und Genauigkeit des von Suricata genutzten Regelwerks steht und fällt die Wirksamkeit des Gesamtsystems.
+; Signaturen spielen in [[Suricata]] eine wichtige Rolle
-* Neben frei verfügbaren Regelwerken, die z.B. auf '''emergingthreats.net[3]''' heruntergeladen werden können, gibt es mehrere Anbieter kommerzieller Regeln, die meist aktueller sind oder besondere Bereiche abdecken.
+* Aktualität
-* Suricata sucht die Regeln standardmäßig in '''/etc/suricata/rules'''.
+* Genauigkeit
-* Dort sind mehrere Regeln thematisch zu '''rules'''-Dateien zusammengefasst, die so in die Suricata-Konfigurationsdatei eingebunden werden können.
-* Auch wenn es theoretisch möglich ist, neue Regeln manuell zu installieren, gibt es einfachere Wege.
-* Denn die Suricata-Regeln sind glücklicherweise mit denen von snort kompatibel, sodass sich bestehende Werkzeuge zur Regelaktualisierung nutzen lassen.
-== oinkmaster ==
+=== Bestehende Regelsätze ===
-; Bei der automatisierten Regelaktualisierung sei zum Beispiel '''oinkmaster[4]''' genannt, mit dessen Hilfe das Regelwerk aktuell gehalten werden kann:
+; Installation von Regelsätzen
+* https://suricata.readthedocs.io/en/suricata-6.0.0/rule-management/suricata-update.html
+; Frei verfügbaren Regelwerken
+* emergingthreats.net
+; Kommerzieller Anbieter
+* aktueller
+* besondere Bereiche
+; /etc/suricata/rules
+* Suricata sucht die Regeln standardmäßig in ''/etc/suricata/rules''
+; Regeln thematisch zu Suricata zusammengefasst
+* snort kompatibel
+; Auch, wenn es möglich ist, neue Regeln manuell zu installieren, gibt es einfachere Wege
+; Suricata-Regeln sind snort kompatibel
+* so lassen sich bestehende Werkzeuge zur Regelaktualisierung nutzen
+== Regelaktualisierung ==
+; Automatisieren
+=== oinkmaster ===
   # oinkmaster -i -u http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz -o /etc/suricata/rules
-; oinkmaster lädt so ein Archiv des Regelwerks von der angegebenen URL herunter und speichert sie in '''rules'''-Dateien im Verzeichnis '''/etc/suricata/rules/'''.
+; oinkmaster
-* Dabei werden eventuell vorhandene '''rules'''-Dateien überschrieben.
+* lädt ein Archiv des Regelwerks von der angegebenen URL herunter
-* Damit dennoch lokale Änderungen vorgenommen werden können und nicht überschrieben werden, verfügt jede einzelne Regel über eine (hoffentlich eindeutige) ID.
+* speichert sie in '''rules'''-Dateien im Verzeichnis '''/etc/suricata/rules/'''
-* Diese können über die <tt>enablesid</tt>, <tt>disablesid</tt> und <tt>modifysid</tt> in der Datei '''/etc/oinkmaster.conf''' bekannt gemacht werden.
-* Wurde beispielsweise eine ID über <tt>disablesid</tt> deaktiviert, so sorgt oinkmaster beim Update dafür, dass sie nicht wieder aktiviert wird.
-; Aktuell finden sich im frei verfügbaren Open Ruleset von Emerging Threats mehr als 80.000 Regeln, die sich auf unterschiedliche Bereiche aufteilen:
+; Dabei werden eventuell vorhandene '''rules'''-Dateien überschrieben
+* Damit dennoch lokale Änderungen vorgenommen werden können und nicht überschrieben werden, verfügt jede einzelne Regel über eine (hoffentlich eindeutige) ID
+* Diese können über die <tt>enablesid</tt>, <tt>disablesid</tt> und <tt>modifysid</tt> in der Datei '''/etc/oinkmaster.conf''' bekannt gemacht werden
+* Wurde etwa eine ID über <tt>disablesid</tt> deaktiviert, so sorgt oinkmaster beim Update dafür, dass sie nicht wieder aktiviert wird
+; Aktuell finden sich im frei verfügbaren Open Ruleset von Emerging Threats mehr als 80.000 Regeln, die sich auf unterschiedliche Bereiche aufteilen
 * Kommunikation mit Bot-Netzen und deren Infrastruktur
 * Verbindungen, die aus unterschiedlichsten Gründen unerwünscht sein können (IP reputation database)
 * Unerwünschte Web-Inhalte (ActiveX, Chat, Java-Applets)
 * Antworten auf (erfolgreich durchgeführte) Angriffe
-* Protokoll-spezifische Angriffsmuster (z.B. DNS, FTP, ICMP, POP3, RPC, SNMP, SQL, VoIP)
+* Protokoll-spezifische Angriffsmuster (z.&nbsp;B.&nbsp; DNS, FTP, ICMP, POP3, RPC, SNMP, SQL, VoIP)
 * DOS-Attacken
 * Angriffe auf bekannte Sicherheitslücken und Standard-Kennwörter
@@ Zeile 29: / Zeile 55: @@
 * Kommunikation mit bekannten Security-Scannern (Portscans, automatisierte SQL-Injection-Tests, metasploit-Scans)
 * Verschlüsselte Kommunikation (Tor-Netzwerkverkehr)
+<noinclude>
+== Anhang ==
+=== Siehe auch ===
+{{Special:PrefixIndex/{{BASEPAGENAME}}}}
+==== Sicherheit ====
+==== Dokumentation ====
+==== Links ====
+===== Projekt =====
+===== Weblinks =====
+[[Kategorie:Suricata]]
-== Regelsyntax ==
+</noinclude>
-; Nun aber ein Blick auf den Aufbau einer einzelnen Regel.
-* Am Beispiel soll der Netzwerkverkehr auf Verbindungsversuche zu einem Kommando-Server eines Bot-Netzes überwacht werden.
-* 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;)
-; Jede Regel fängt man mit der wichtigsten Frage an: Wie soll mit dem Paket weiter verfahren werden?
-* 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 <tt>ALERT</tt>-Aktion zulässig.
-* Eine Filterung über <tt>PASS</tt>, <tt>DROP</tt> oder <tt>REJECT</tt> ist nur im Inline-Modus möglich.
-* Der Unterschied zwischen <tt>DROP</tt> und <tt>REJECT</tt> liegt in der Art, wie die Verbindung abgelehnt und beendet wird.
-* Bei <tt>REJECT</tt> 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.
-; 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.
-; 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 <tt>$HOME_NET</tt> 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.
-; In Klammern folgen weitere optionale Parameter:
-* <tt>msg</tt>: Die Meldung, die im Erfolgsfall ausgegeben und geloggt werden soll: »Communication to CnC«.
-* <tt>reference</tt>: 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.
-* <tt>sid</tt> und <tt>rev</tt>: Jede einzelne Regel wird mit einer eindeutigen Signature-ID (<tt>sid</tt>) in Verbindung mit der Revision des Regelwerks (<tt>rev</tt>) versehen.
-* Dies ermöglicht z.B. eine automatisierte Pflege des Regelwerks, da jede Regel individuell über die <tt>sid</tt> angesprochen werden kann.
-* <tt>classtype</tt>: Eine grobe Klassifikation, die die Relevanz des Regelverstoßes einordnet.
-* Der hier spezifizierte <tt>classtype</tt> muss in der Datei <tt>/etc/suricata/classification.rules</tt> näher beschrieben werden und reicht von leichten Verstößen, wie nicht zuzuordnender Netzwerkverkehr, bis hin zu schwerwiegenderen Ereignissen, wie z.B. Einbruchsversuchen.
-* <tt>priority</tt>: Überschreibt die aus der <tt>classtype</tt> abgeleitete Priorität.
-* <tt>content</tt>: Analysiert den Datenbereich eines Pakets.
-* Hier sind umfangreiche Abfragen bis hin zu regulären Ausdrücken möglich.
-* <tt>flowbits</tt>: 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.
-* <tt>flow</tt>: Ermöglicht Einschränkungen bezüglich der Verbindung, z.B. ob eine TCP-Verbindung tatsächlich vollständig aufgebaut wurde.
-* <tt>vthreshold</tt>: 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.
-* <tt>luajit</tt>: 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.
-[[Image:.png|thumb|right|top|Alexander Hosfeld Volle Ausbaustufe: Suricata mit Echtzeit-Analyse und grafischer Oberfläche]]Ausgabe und Alarmierung
-; 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.