Suricata/Regeln/Syntax

Suricata Signaturen - lesen, anpassen, erstellen

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

Aktion

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	Description
../..	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 (source and destination)

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 first emphasized part is the source, the second is the destination (note the direction of the directional arrow).

Traffic comes in and goes out through ports. Different ports have different port numbers. For example, the default port for HTTP is 80 while 443 is typically the port for HTTPS. Note, however, that the port does not dictate which protocol is used in the communication. Rather, it determines which application is receiving the data.

The ports mentioned above are typically the destination ports. Source ports, i.e. the application that sent the packet, typically get assigned a random port by the operating system. When writing a rule for your own HTTP service, you would typically write any -> 80, since that would mean any packet from any source port to your HTTP application (running on port 80) is matched.

In setting ports you can make use of special operators as well, like described above.

Signs like:

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.

Modifier Keywords

Some keywords function act as modifiers. There are two types of modifiers.

• The older style ‘content modifiers’ look back in the rule, e.g.:
  alert http any any -> any any (content:"index.php"; http_uri; sid:1;)
  In the above example the pattern ‘index.php’ is modified to inspect the HTTP uri buffer.
• The more recent type is called the ‘sticky buffer’. It places the buffer name first and all keywords following it apply to that buffer, for instance:
  alert http any any -> any any (http_response_line; content:"403 Forbidden"; sid:1;)
  In the above example the pattern ‘403 Forbidden’ is inspected against the HTTP response line because it follows the http_response_line keyword.

Normalized Buffers

A packet consists of raw data. HTTP and reassembly make a copy of those kinds of packets data. They erase anomalous content, combine packets etcetera. What remains is a called the ‘normalized buffer’:

"../_images/normalization1.png"

Because the data is being normalized, it is not what it used to be; it is an interpretation. Normalized buffers are: all HTTP-keywords, reassembled streams, TLS-, SSL-, SSH-, FTP- and dcerpc-buffers.

Note that there are some exceptions, e.g. the http_raw_uri keyword. See http.uri and http.uri.raw for more information.

Regelsyntax

Aufbau einer 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?

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.

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

In Klammern folgen weitere optionale Parameter

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

Datei:.png

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.