Skript/Suricata

Einführung

Suricata ist ein Network Intrusion Detection System (NIDS)

Beschreibung

Hochleistungsfähiges Netzwerk-IDS, IPS und Network Security Monitoring engine

Suricata mit Echtzeit-Analyse und grafischer Oberfläche

Network Intrusion Detection System (NIDS)

• Auch als Network Intrusion Prevention System (NIPS) einsetzbar

in Datenverkehr eingreift und Pakete blockieren

Suricata ist ein Intrusion Detection und Intrusion Prevention System

• Kann auf vielfältige Weise an verschiedene Einsatzzwecke angepasst werden
• Über den NFQUEUE-Mechanismus gibt es eine leistungsfähige und flexible Anbindung an die Linux-Firewall Netfilter

Lizenz

• GPL
• Suricata wird von der OISF und den sie unterstützenden Anbietern entwickelt
• Open Source
• Im Besitz einer gemeinschaftlich geführten gemeinnützigen Stiftung
• Open Information Security Foundation (OISF)

Anwendung

Freie Firewall-Distributionen

• IPFire
• pfSense
• OPNsense
• SecurityOnion

Kommerzielle Anbieter

• FireEye

Übersicht

Betriebssystem	FreeBSD, Linux, Unix, macOS, Windows
Kategorie	Intrusion Detection System
Programmiersprache	C, Rust
Lizenz	GPL
Website	suricata.io

Entwicklung

• seit 2008 durch Matt Jonkman, Will Metcalf und Victor Julien

Sicherheit

Ein IDS/IPS kann nur vor bekannten Angriffen und Sicherheitslücken schützen!

• nicht vor unbekannten

Daher kann ein IDS/IPS nur ein Baustein in einem Sicherheitskonzept sein

Funktionen

System zur Erkennung und Abwehr von Angriffen auf IT-Infrastrukturen

Auf Netzwerkebene

• Ein- und ausgehenden Datenverkehr auf verdächtige Muster überprüfen

Aktionen

• Information über Unregelmäßigkeiten
• Unerwünschte Kommunikation unterbinden
  • über eine Rückschaltung zur Firewall

Suricata beschreibt sich selbst als Next-Generation IDS

• da es neben der Erkennung und Abwehr von netzwerkbasierten Angriffsmustern zusätzlich über Möglichkeiten verfügt, Protokolle wie HTTP oder DNS auf Anwendungsebene zu überwachen und zu protokollieren.
• Durch Funktionen wie Multithreading, Scripting und High Performance Detection hat sich Suricata mittlerweile fest als Alternative zu snort, dem bisherigen IDS-Platzhirsch, etabliert.

Funktion	Beschreibung
Multithreading
PCAP-Analyse
IPv6-Support
Automatische Protokollerkennung
Protokoll-Parser
HTTP-Engine (libhtp)
PCRE-Support
Lua-Skripte
Intel-Hyperscan
Eve JSON-Log-Ausgabe
Redis
Datei-Extrahierung
High-Performance-Packetaufzeichnung
AF_PACKET
PF_RING
NETMAP
IP-Reputation

Multithreading

• Ein wesentliches Merkmal, das Suricata auszeichnet und von anderen bekannten IDS/IPS unterscheidet, ist die Möglichkeit des Multithreadings und der dadurch gewonnene Performancegewinn.
• So können bei einer aktuellen Multicore-CPU die Analyseaufgaben auf mehrere gleichzeitig laufende Prozesse aufgeteilt werden, was eine parallele Paketverarbeitung ermöglicht.

Multithread-fähige Vorgänge

• Paketempfang
• Paketdekodierung
• Paketanalyse
• Paketverarbeitung

Jeder dieser Vorgänge kann nicht nur individuell auf eine oder mehrere CPUs aufgeteilt, sondern auch zusätzlich noch priorisiert werden.

• In den Standardeinstellungen nutzt Suricata für den rechenintensivsten Prozess, die Paketanalyse, einen Thread pro CPU.

"Multithreading-Standardeinstellungen bei 4 CPUs"

Multithreading-Standardeinstellungen bei 4 CPUs

Begriffe

Begriff	Beschreibung
Empfang	Pakete vom Netzwerk lesen
Decodierung	Pakete auf TCP-Ebene decodieren und Original-Datenstrom restaurieren
Analyse	Datenstrom mit aktivierten Signaturen vergleichen
Output	Alarmierungen und Ereignisse verarbeiten

Installation

topic - Kurzbeschreibung

Beschreibung

Debian

# apt install suricata

OPNsense

siehe OPNsense/IDS/Installation

Konfiguration

topic - Kurzbeschreibung

Konfiguration

/etc/suricata/

• Dort sollte mindestens die Datei suricata.yaml zu finden sein, die die Hauptkonfiguration beinhaltet

Je nach eingesetzter Distribution kann der Dateiname auch anders lauten

• Bei Debian und Ubuntu etwa findet man die Konfiguration in /etc/suricata/suricata-debian.yaml
• Hier lässt sich nicht nur das Regelwerk und die Einbindung von Netzwerkschnittstellen konfigurieren, sondern auch die Paketanalyse steuern

Suricata zieht zur Paketanalyse verschiedene Variablen heran und nutzt diese Informationen bei der Frage, welche Regeln für das aktuelle Paket überhaupt in Betracht kommen

• Wozu sollte man auch ein Paket auf eine Vielzahl von Angriffsmustern für Webserver analysieren, wenn auf der IP-Adresse gar kein Webserver horcht?
• Es geht also darum, Suricata das zu schützende Netz möglichst genau zu beschreiben

Allen voran ist hier die wichtigste Variable HOME_NET zu nennen

• Diese Variable gibt den Adressbereich an, der durch das IDS geschützt werden soll, und kann eine einzelne IP-Adresse oder ein Netzwerkbereich sein.
• In einer üblichen kleineren Netzwerktopologie wird man hier in der Praxis das LAN und vielleicht eine externe IP-Adresse finden.
• Also z. B.  HOME_NET: "[192.168.0.0/16,1.2.3.4]".
• Das Hinzufügen der externen IP-Adresse hat den Vorteil, dass potentielle Angriffe auf das Suricata-System selbst ebenfalls erkannt werden.
• Ist das Suricata-System auch das Gateway für das interne Netz, sollte die externe IP-Adresse auf jeden Fall in das HOME_NET aufgenommen werden, da aufgrund von SNAT-Techniken (IP-Maskierung) sonst einige Angriffsmuster nicht als solche erkannt werden.

Die Variable EXTERNAL_NET gibt an, welche IP-Adressen nicht zum lokalen Netzwerk gehören.

• Die Standardeinstellung ist auf EXTERNAL_NET: "!$HOME_NET" vorgegeben.
• Demnach wird alles als extern und potentiell böswillig angesehen, was nicht zum internen Netz gehört.

Neben HOME_NET und EXTERNAL_NET können eine Reihe weiterer Angaben gemacht werden, die eine noch gezieltere Auswertung möglich machen und z. B. 

• die Erkennung von protokollspezifischen Mustern auf einzelne IP-Adressen beschränkt.
• Wenn z. B.  bekannt ist, dass der einzige zu überwachende Webserver die IP-Adresse 192.168.1.100 hat, dann kann auch die Detektion von webbasierten Angriffen auf diese IP-Adresse beschränkt werden.
• Selbiges gilt entsprechend für DNS-, SQL-, Telnet-Server und analog für *_CLIENT</nowiki>- und <nowiki>*_PORTS-Variablen.
• Selbst der vom Betriebssystem abhängige Umgang mit fragmentierten Paketen lässt sich Suricata mitteilen – vorausgesetzt, der Adressbereich für verschiedene Betriebssysteme im lokalen Netz ist hinreichend stark fragmentiert:

host-os-policy:
 windows: [0.0.0.0/0]         # Default
 bsd: [192.168.1.1]           # Gateway 
 linux: [192.168.1.128/25, 192.168.1.100]    # Linux Webservers

Bei allen von Suricata genutzten Variablen gilt

Je genauer diese sind, desto performanter ist der Analyse-Prozess und desto weniger falsch-positive Meldungen treten auf.

Dateien

The main configuration file is /etc/suricata/suricata.yaml

You should change the following parts of the configuration in order to make it run

 default-log-dir: /var/log/suricata/     # where you want to store log files
 classification-file: /etc/suricata/classification.config
 reference-config-file: /etc/suricata/reference.config
 HOME_NET: "[10.0.0.0/8]"                # your local network
 host-os-policy:   ..                    # according to the OS running the ips
 magic-file: /usr/share/file/misc/magic.mgc

Starting Suricata

Manual startup

You may start the suricata service manually with:

# /usr/bin/suricata -c /etc/suricata/suricata.yaml -i eth0

systemd service configuration

To start Suricata automatically at system boot, enable suricata.service

Betrieb

topic - Kurzbeschreibung

Betrieb

Suricata lässt sich in zwei Modi betreiben

• Im normalen Modus hängt sich Suricata lauschend an eine (oder mehrere) Netzwerkschnittstellen und erlaubt so eine passive Analyse des Datenverkehrs und das Detektieren unerwünschter Kommunikation (Intrusion Detection)

In welchem Modus Suricata arbeiten soll, muss bereits beim Start-Kommando angegeben werden

• Der Start im normalen Modus (Intrusion Detection-Modus, IDS-Modus) über zwei Netzwerkschnittstellen erfolgt mit

# suricata -i eth0 -i eth1 

Zur Analyse von Netzwerkschnittstellen jenseits der 1 Gbit/s reicht die Rechenleistung u.U. nicht aus, um die Pakete mit der gleichen Geschwindigkeit zu analysieren

• Um einzelne, kurzzeitig auftretende Lastspitzen abzufangen, bietet Suricata die Unterstützung von PF_RING an
• Dafür ist jedoch das Kernel-Modul pf_ring erforderlich und Suricata muss mit --enable-pfring kompiliert worden sein

# suricata --pfring-int=eth0 --pfring-cluster-id=99 --pfring-cluster-type=cluster_flow

Inline-Modus (IPS)

Im inline-Modus werden die Pakete über das Netfilter-Queueing (NFQUEUE) an Suricata geleitet.

• Dabei kann Suricata aktiv in die Kommunikation eingreifen und einzelne Pakete verwerfen.
• So kann das Suricata-System als Firewall arbeiten und Angriffe direkt unterbinden (Intrusion Prevention).
• Pakete können zur Analyse per iptables an Suricata geleitet werden.
• Dies ermöglicht eine deutlich flexiblere Auswahl des zu analysierenden Netzwerkverkehrs, da man auf die umfangreichen Filtermöglichkeiten von iptables zurückgreifen kann.
• Außerdem erlangt man die Möglichkeit, unerwünschte Pakete zu filtern und eine Kommunikation zu blockieren (Intrusion Prevention).
• Der Befehl, um Suricata mit zwei NFQUEUE-Warteschlangen zu starten, lautet:

# suricata -q0 -q1

Über NFQUEUE gibt es eine praktische und einfach zu nutzende Möglichkeit, Filterprogramme im Userspace laufen zu lassen.

• Dazu leitet Netfilter (iptables) das Paket zur individuellen Analyse weiter.
• Somit lässt sich NFQUEUE wunderbar nutzen, um die für das IDS/IPS relevanten Pakete an Suricata zu leiten:

# iptables -A FORWARD -j NFQUEUE

Es gibt jedoch ein Problem

Die Entscheidungen, die von iptables getroffen werden, sind endgültig.

• Das heißt, ACCEPT-Regeln, die vor obiger NFQUEUE-Regel stehen, führen dazu, dass iptables die Abarbeitung der Regelkette schon vorher beendet und diese Pakete nicht mehr an Suricata leitet.
• Gleiches gilt für den NFQUEUE-Prozess, der für ein Paket nur zwei Möglichkeiten hat: NF_DROP oder NF_ACCEPT.
• In beiden Fällen ist iptables danach beendet und eventuell nachfolgende Regeln werden ignoriert.
• Solange das System nicht gleichzeitig als Paketfilter eingesetzt werden soll, stört das nicht und Suricata kann über eine Angabe in der Konfigurationsdatei suricata.yaml auf Durchzug geschaltet werden:

nfq:
  mode: accept

So werden alle Pakete erlaubt und es erfolgt keine weitere Filterung über iptables.

Soll Suricata aber in ein bestehendes Firewall-Regelwerk integriert werden, ist ein Trick notwendig. Über ein drittes Sprungziel NF_REPEAT durchläuft ein Paket die Firewallkette erneut und wird gleichzeitig markiert.

nfq:
  mode: repeat
  repeat_mark: 1
  repeat_mask: 1

So kann iptables genutzt werden, um nur neue, also nicht markierte, Pakete an Suricata zu leiten

# iptables -A FORWARD ! -m mark ! --mark 0x1/0x1 -j NFQUEUE 

Steht diese Regel am Anfang der FORWARD-Chain, haben bereits markierte Pakete das IDS schon durchlaufen und können danach wie üblich mit allen Möglichkeiten von iptables behandelt werden.

Läuft Suricata im Multithreading-Modus und wurde mit mehreren, z. B.  vier NFQUEUEs gestartet, kann iptables die Paketanalyse auf die verschiedenen Warteschlangen 0, 1, 2 und 3 aufteilen:

# iptables -A FORWARD ! -m mark ! --mark 0x1/0x1 -j NFQUEUE --queue-balance 0:3

Über

# cat /proc/net/netfilter/nfnetlink_queue | awk '{print $6,$7}'

kann überprüft werden, ob Pakete verworfen werden mussten, weil die Queue voll war (erste Zahl), bzw. ob Suricata die Pakete nicht korrekt verarbeiten konnte (zweite Zahl).

• Im Idealfall sollten also beide Zahlen 0 sein.

Regeln

topic - Kurzbeschreibung

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)

Regelsyntax

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

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

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.

"../_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.

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"