Suricata/Regeln/Syntax

Suricata Signaturen - verstehen, anpassen, erstellen

topic - Kurzbeschreibung

Testfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5

TMP

Aufbau

Bestandteile einer Regel/Signatur

Option	Beschreibung
Aktion	was passieren soll, wenn Signatur passt
Header	Protokoll, IP-Adressen, Ports, Richtung
Regeloptionen	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;)

Aktionen

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;)

Aktionen

Aktion	Beschreibung
alert	Warnung
pass	Stoppt die weitere Untersuchung
drop	Verwerfen und Warnung erzeugen
reject	Sendet RST/ICMP unreach error an den Absender des passenden Pakets
rejectsrc	wie reject
rejectdst	Sendet ein RST/ICMP-Fehler-Paket an den Empfänger des passenden Pakets
rejectboth	Sendet RST/ICMP-Fehlerpakete an beide Seiten der Konversation

Hinweis

Im IPS-Modus aktiviert die Verwendung einer der reject-Aktionen auch drop.

Weitere Informationen

• https://suricata.readthedocs.io/en/suricata-6.0.0/configuration/suricata-yaml.html#suricata-yaml-action-order

Protokoll

Zu untersuchendes welches Protokoll

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	Verfügbarkeit
tcp	tcp-Verkehr
udp
icmp
ip	ip steht für 'all' oder 'any'

Anwendungsprotokolle

Die Verfügbarkeit dieser Protokolle hängt davon ab, ob das Protokoll in der Konfigurationsdatei suricata.yaml aktiviert ist

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 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.

"../_images/TCP-session.png"

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.

Rule options

The rest of the rule consists of options. These are enclosed by parenthesis and separated by semicolons. Some options have settings (such as msg), which are specified by the keyword of the option, followed by a colon, followed by the settings. Others have no settings, and are simply the keyword (such as nocase):

<keyword>: <settings>;
<keyword>;

Rule options have a specific ordering and changing their order would change the meaning of the rule.

Note

The characters ; and " have special meaning in the Suricata rule language and must be escaped when used in a rule option value.

Example

msg:"Message with semicolon\;";

As a consequence, you must also escape the backslash, as it functions as an escape character.

The rest of this chapter in the documentation documents the use of the various keywords.

Some generic details about keywords follow.

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"