Suricata: Unterschied zwischen den Versionen
Zeile 152: | Zeile 152: | ||
; systemd service configuration | ; systemd service configuration | ||
To start Suricata automatically at system boot, enable suricata.service | To start Suricata automatically at system boot, enable suricata.service | ||
== 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. | |||
; Suricata unterscheidet dabei zwischen vier Multithread-fähigen Vorgängen: | |||
* Paketempfang, Paketdekodierung, Paketanalyse und 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. | |||
[[Image:Bild3.png|top|alt="Multithreading-Standardeinstellungen bei 4 CPUs"]] | |||
; Multithreading-Standardeinstellungen bei 4 CPUs | |||
; Folgende Begriffe werden dabei verwendet | |||
* Empfang | |||
* Pakete werden vom Netzwerk gelesen. | |||
* Decodierung | |||
* Pakete werden auf TCP-Ebene decodiert und der Original-Datenstrom wird restauriert. | |||
* Analyse | |||
* Der Datenstrom wird mit den hinterlegten Signaturen verglichen. | |||
* Output | |||
Evtl. auftretene Alarmierungen und Ereignisse werden verarbeitet. | |||
== 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 <tt>PF_RING</tt> an | |||
* Dafür ist jedoch das Kernel-Modul <tt>pf_ring</tt> erforderlich und Suricata muss mit <tt>--enable-pfring</tt> 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 (<tt>NFQUEUE</tt>) 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 <tt>NFQUEUE</tt>-Warteschlangen zu starten, lautet: | |||
# suricata -q0 -q1 | |||
; Über <tt>NFQUEUE</tt> 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 <tt>NFQUEUE</tt> 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, <tt>ACCEPT</tt>-Regeln, die vor obiger <tt>NFQUEUE</tt>-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 <tt>NFQUEUE</tt>-Prozess, der für ein Paket nur zwei Möglichkeiten hat: <tt>NF_DROP</tt> oder <tt>NF_ACCEPT</tt>. | |||
* 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 <tt>NF_REPEAT</tt> 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 <tt>FORWARD</tt>-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 <tt>NFQUEUEs</tt> 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 <tt>0</tt> sein. | |||
== Siehe auch == | == Siehe auch == |
Version vom 2. März 2023, 22:42 Uhr
Suricata ist ein Network Intrusion Detection System (NIDS)
Beschreibung
- Suricata ist ein Network Intrusion Detection System (NIDS)
- Durch die Open Information Security Foundation (OISF) entwickelt und betreut
- Freie Software (GPLv2)
- Auch als Network Intrusion Prevention System (NIPS) einsetzbar
- (in Datenverkehr eingreift und Pakete blockieren)
- Anwendung
Freie Firewall-Distributionen
Kommerzielle Anbieter
- Übersicht
Hersteller | Open Information Security Foundation |
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
- Funktionen
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 |
- Systeme zur Erkennung und Abwehr von Angriffen auf eine IT-Infrastruktur können auf Netzwerkebene den ein- und ausgehenden Datenverkehr auf verdächtige Muster überprüfen.
- So kann der Systemadministrator bei Unregelmäßigkeiten informiert werden oder über eine Rückschaltung zur Firewall die unerwünschte Kommunikation gänzlich unterbunden werden.
- Im Folgenden soll die grundlegende Funktionalität von Suricata, einem signaturbasierten Intrusion Detection System (IDS) beschrieben werden.
- 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.
Suricata is a high performance Network IDS, IPS and Network Security Monitoring engine. Open Source and owned by a community run non-profit foundation, the Open Information Security Foundation (OISF). Suricata is developed by the OISF and its supporting vendors.
Fazit
- Suricata ist ein leistungsfähiges Intrusion Detection und Intrusion Prevention System, das sich auf vielfältige Weise an den jeweiligen Einsatzzweck anpassen lässt.
- Über den NFQUEUE-Mechanismus gibt es eine sehr leistungsfähige und flexible Anbindung an die Linux-Firewall »Netfilter«.
- Bei allen Möglichkeiten, die Suricata bietet, darf man aber nicht vergessen, dass ein IDS/IPS nicht vor (unbekannten) Sicherheitslücken schützen kann.
- Suricata kann und muss nur ein Baustein in einem globaleren Sicherheitskonzept sein.
Installation
# apt install suricata
Konfiguration
- Die Konfiguration von Suricata erfolgt im Verzeichnis /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
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.
- Suricata unterscheidet dabei zwischen vier Multithread-fähigen Vorgängen
- Paketempfang, Paketdekodierung, Paketanalyse und 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
- Folgende Begriffe werden dabei verwendet
- Empfang
- Pakete werden vom Netzwerk gelesen.
- Decodierung
- Pakete werden auf TCP-Ebene decodiert und der Original-Datenstrom wird restauriert.
- Analyse
- Der Datenstrom wird mit den hinterlegten Signaturen verglichen.
- Output
Evtl. auftretene Alarmierungen und Ereignisse werden verarbeitet.
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.
Siehe auch
Dokumentation
- https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Installation
- https://suricata.readthedocs.io/en/latest/index.html
RFC
Man-Pages
Info-Pages
Links
Projekt
Weblinks
- OISF – Foundation hinter Suricata
- emergingthreats.net – Community für Suricata Signaturen
- http://suricata-ids.org/
- https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Ubuntu_Installation_from_GIT
- http://www.emergingthreats.net/
- http://oinkmaster.sourceforge.net/
- http://www.hosfeld.de/
- http://www.freiesmagazin.de/20150201-februarausgabe-erschienen
- https://www.pro-linux.de/artikel/2/1751/6,ausgabe-und-alarmierung.html
Einzelnachweise
Testfragen
Testfrage 1
Testfrage 2
Testfrage 3
Testfrage 4
Testfrage 5