Suricata/Regeln/Syntax: Unterschied zwischen den Versionen
Zeile 55: | Zeile 55: | ||
; Beispiel | ; Beispiel | ||
<span style="color:red">'''drop'''</span> tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "ET TROJAN Likely Bot Nick in IRC (USA +..)"; flow:established,to_server; flowbits:isset,is_proto_irc; content: "NICK "; pcre:"/NICK . *USA.*[0-9]{3,}/i"; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;) | |||
; Im IDS-Modus ist nur die passive <tt>ALERT</tt>-Aktion zulässig | ; Im IDS-Modus ist nur die passive <tt>ALERT</tt>-Aktion zulässig |
Version vom 30. Mai 2023, 22:08 Uhr
Suricata Signaturen - verstehen, anpassen, erstellen
Beschreibung
Aufbau einer Regel
- Bestandteile einer Regel/Signatur
Option | Beschreibung |
---|---|
Aktion | was passieren soll, wenn Signatur passt |
Header | Protokoll, IP-Adressen, Ports, Richtung |
Parameter | Besonderheiten der Regel |
- Beispiel
Signatur 2008124 aus der Datenbank von Emerging Threats
- drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "ET TROJAN Likely Bot Nick in IRC (USA +..)"; flow:established,to_server; flowbits:isset,is_proto_irc; content: "NICK "; pcre:"/NICK . *USA.*[0-9]{3,}/i"; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;)
- 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 verfahren werden?
Aktion | Beschreibung |
---|---|
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. |
alert | Es wird eine Warnung erzeugt und z. B. zur weiteren Analyse in eine Logdatei gespeichert. |
drop | Das Paket wird stillschweigend verworfen. Verwerfen und Warnung erzeugen |
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. Stoppt die weitere Untersuchung |
reject | Das Paket wird abgelehnt. Sendet RST/ICMP unreach error an den Absender des passenden Pakets |
rejectboth | Sendet RST/ICMP-Fehlerpakete an beide Seiten der Konversation |
rejectdst | Sendet ein RST/ICMP-Fehler-Paket an den Empfänger des passenden Pakets |
rejectsrc | wie reject |
- Beispiel
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "ET TROJAN Likely Bot Nick in IRC (USA +..)"; flow:established,to_server; flowbits:isset,is_proto_irc; content: "NICK "; pcre:"/NICK . *USA.*[0-9]{3,}/i"; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;)
- Im IDS-Modus ist 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
- Hinweis
- Im IPS-Modus aktiviert die Verwendung einer der reject-Aktionen auch drop
- Weitere Informationen
Header
Protokoll
- Zu untersuchendes Protokoll
- Transportebene (ip, tcp, udp, icmp)
- Anwendungsebene (http, tls, ftp, smb)
- Beispiel
- drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "ET TROJAN Likely Bot Nick in IRC (USA +..)"; flow:established,to_server; flowbits:isset,is_proto_irc; content: "NICK "; pcre:"/NICK . *USA.*[0-9]{3,}/i"; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;)
- Grundprotokolle
Protokoll | Beschreibung |
---|---|
tcp | tcp-Verkehr |
udp | |
icmp | |
ip | ip steht für 'all' oder 'any' |
- Anwendungsprotokolle
Auf Anwendungsebene versucht Suricata das eingesetzte Protokoll unabhängig vom Port zu erkennen
- kann daher eigenständig auch z. B. eine HTTP-Kommunikation auf nicht-Standard-Ports erkennen und überwachen
- Die Verfügbarkeit der Protokolle hängt von der Konfiguration in suricata.yaml ab
Protokoll | Verfügbarkeit |
---|---|
http | |
ftp | |
tls/ssl | |
smb | |
dns | |
dcerpc | |
ssh | |
smtp | |
imap | |
modbus | deaktiviert |
dnp3 | deaktiviert |
enip | deaktiviert |
nfs | |
ikev2 | |
krb5 | |
ntp | |
dhcp | |
rfb | |
rdp | |
snmp | |
tftp | |
sip | |
http2 |
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.
- Quelle und Ziel
- drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "ET TROJAN Likely Bot Nick in IRC (USA +..)"; flow:established,to_server; flowbits:isset,is_proto_irc; content: "NICK "; pcre:"/NICK . *USA.*[0-9]{3,}/i"; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;)
- Der erste hervorgehobene Teil ist die Quelle
- der zweite das Ziel
- beachten Sie die Richtung des Richtungspfeils
Mit Quelle und Ziel geben Sie die Quelle des Datenverkehrs bzw. das Ziel des Datenverkehrs an.
Sie können IP-Adressen (sowohl IPv4 als auch IPv6 werden unterstützt) und IP-Bereiche zuweisen.
Diese können mit Operatoren kombiniert werden:
Operator | Beschreibung |
---|---|
../.. | IP ranges (CIDR notation) |
! | exception/negation |
[.., ..] | grouping |
Normalerweise würden Sie auch Variablen verwenden, wie z. B.
$HOME_NET and $EXTERNAL_NET
Die Konfigurationsdatei gibt die IP-Adressen an, die diese betreffen, und diese Einstellungen werden anstelle der Variablen in Ihren Regeln verwendet. Siehe Rule-vars für weitere Informationen.
- Beispiel
Example | Meaning |
---|---|
! 1.1.1.1 | Every IP address but 1.1.1.1 |
![1.1.1.1, 1.1.1.2] | Every IP address but 1.1.1.1 and 1.1.1.2 |
$HOME_NET | Your setting of HOME_NET in yaml |
[$EXTERNAL_NET, !$HOME_NET] | EXTERNAL_NET and not HOME_NET |
[10.0.0.0/24, !10.0.0.5] | 10.0.0.0/24 except for 10.0.0.5 |
[…, [….]] | |
[…, ![…..]] | Normally, you would also make use of variables, such as . The configuration file specifies the IP addresses these concern, and these settings will be used in place of the variables in you rules. See Rule-vars for more information. For example: |
- Warning
- If you set your configuration to something like this:
HOME_NET: any EXTERNAL_NET: ! $HOME_NET
You can not write a signature using $EXTERNAL_NET because it stands for ‘not any’. This is an invalid setting.
Ports (Quelle und Ziel)
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "ET TROJAN Likely Bot Nick in IRC (USA +..)"; flow:established,to_server; flowbits:isset,is_proto_irc; content: "NICK "; pcre:"/NICK . *USA.*[0-9]{3,}/i"; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;)
Der erste hervorgehobene Teil ist die Quelle, der zweite ist das Ziel (beachten Sie die Richtung des Richtungspfeils).
Der Verkehr kommt über Ports herein und geht über sie hinaus. Verschiedene Ports haben unterschiedliche Portnummern. Der Standard-Port für HTTP ist zum Beispiel 80, während 443 normalerweise der Port für HTTPS ist. Beachten Sie jedoch, dass der Port nicht vorgibt, welches Protokoll in der Kommunikation verwendet wird. Vielmehr bestimmt er, welche Anwendung die Daten empfängt.
Die oben genannten Ports sind in der Regel die Zielports. Quell-Ports, d. h. die Anwendung, die das Paket gesendet hat, wird normalerweise vom Betriebssystem ein zufälliger Port zugewiesen. Wenn Sie eine Regel für Ihren eigenen HTTP-Dienst schreiben, würden Sie in der Regel schreiben any -> 80. Das würde bedeuten, dass jedes Paket, das von einem beliebigen Quellport zu Ihrer HTTP-Anwendung (die auf Port 80 läuft) gesendet wird, geprüft wird.
Beim Setzen von Ports können Sie auch spezielle Operatoren verwenden, wie oben beschrieben.
Operator | Description |
---|---|
: | port ranges |
! | exception/negation |
[.., ..] | grouping |
- Example
Example | Meaning |
---|---|
[80, 81, 82] | port 80, 81 and 82 |
[80: 82] | Range from 80 till 82 |
[1024: ] | From 1024 till the highest port-number |
!80 | Every port but 80 |
[80:100,!99] | Range from 80 till 100 but 99 excluded |
[1:80,![2,4]] | Range from 1-80, except ports 2 and 4 |
[.., [..,..]] |
Direction
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "ET TROJAN Likely Bot Nick in IRC (USA +..)"; flow:established,to_server; flowbits:isset,is_proto_irc; content: "NICK "; pcre:"/NICK . *USA.*[0-9]{3,}/i"; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;)
The direction tells in which way the signature has to match. Nearly every signature has an arrow to the right (->). This means that only packets with the same direction can match. However, it is also possible to have a rule match both ways (<>):
source -> destination source <> destination (both directions)
- Warning
- There is no ‘reverse’ style direction, i.e. there is no <-.
The following example illustrates this. Say, there is a client with IP address 1.2.3.4 and port 1024, and a server with IP address 5.6.7.8, listening on port 80 (typically HTTP). The client sends a message to the server, and the server replies with its answer.
Now, let’s say we have a rule with the following header:
alert tcp 1.2.3.4 1024 -> 5.6.7.8 80
Only the first packet will be matched by this rule, as the direction specifies that we do not match on the response packet.
Parameter
- In Klammern folgen weitere optionale Parameter
- Optionen der Regel
- Der Rest der Regel besteht aus Optionen.
- Diese werden durch Klammern eingeschlossen und durch Semikolons getrennt.
- Einige Optionen haben Einstellungen (z. B. msg), die durch das Schlüsselwort der Option angegeben werden, gefolgt von einem Doppelpunkt, gefolgt von den Einstellungen.
- Andere Optionen haben keine Einstellungen und bestehen lediglich aus dem Schlüsselwort (z. B. nocase):
<keyword>: <settings>; <keyword>;
Regeloptionen haben eine bestimmte Reihenfolge, und eine Änderung ihrer Reihenfolge würde die Bedeutung der Regel verändern.
- Hinweis
- Die Zeichen ; und " haben in der Suricata-Regelsprache eine besondere Bedeutung und müssen bei Verwendung in einem Regeloptionswert escaped werden.
- Beispiel
msg:"Message with semicolon\;";
- Infolgedessen müssen Sie auch den Backslash entschlüsseln, da er als Escape-Zeichen fungiert
- Im weiteren Verlauf dieses Kapitels der Dokumentation wird die Verwendung der verschiedenen Schlüsselwörter beschrieben
- Es folgen einige allgemeine Details zu den Schlüsselwörtern
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. |
Modifiers
- Einige Schlüsselwörter fungieren als Modifikatoren. Es gibt zwei Arten von Modifikatoren.
- Die älteren content modifiers schauen in der Regel zurück
alert http any any -> any any (content:"index.php"; http_uri; sid:1;)
Im obigen Beispiel wird das Muster "index.php" geändert, um den HTTP-URI-Puffer zu untersuchen.
- Der neuere Typ wird als "sticky buffer" bezeichnet.
Der Name des Puffers steht an erster Stelle, und alle folgenden Schlüsselwörter beziehen sich beispielsweise auf diesen Puffer:
alert http any any -> any any (http_response_line; content:"403 Forbidden"; sid:1;)
Im obigen Beispiel wird das Muster 403 Forbidden anhand der HTTP-Antwortzeile überprüft, da es auf das Schlüsselwort http_response_line folgt.
Normalisierte Puffer
Ein Paket besteht aus Rohdaten. HTTP und Reassembly erstellen eine Kopie dieser Art von Paketdaten. Sie löschen anomale Inhalte, fassen Pakete zusammen und so weiter. Was übrig bleibt, ist der so genannte "normalisierte Puffer":
Da die Daten normalisiert werden, sind sie nicht mehr das, was sie einmal waren; sie sind eine Interpretation. Normalisierte Puffer sind: alle HTTP-Schlüsselwörter, reassemblierte Streams, TLS-, SSL-, SSH-, FTP- und dcerpc-Puffer.
Beachten Sie, dass es einige Ausnahmen gibt, z. B. das http_raw_uri Schlüsselwort. Siehe http.uri und http.uri.raw für weitere Informationen.
"../_images/normalization1.png"