Suricata: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
 
(90 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 2: Zeile 2:


== Beschreibung ==
== Beschreibung ==
[[Datei:Suricata IDS.png|mini|400px]]
; Hochleistungsfähiges Netzwerk-IDS, IPS und Network Security Monitoring engine
; ''Suricata'' ist ein [[Intrusion Detection System#Netzwerk-basierte IDS|Network Intrusion Detection System]] (NIDS)
[[Datei:Suricata IDS.png|mini|400px | Suricata mit Echtzeit-Analyse und grafischer Oberfläche]]
* Durch die [[Open Information Security Foundation]] (OISF) entwickelt und betreut
; [[Intrusion Detection System#Netzwerk-basierte IDS|Network Intrusion Detection System]] (NIDS)
* Freie Software (GPLv2)
* Auch als [[Intrusion Prevention System|Network Intrusion Prevention System]] (NIPS) einsetzbar
* Auch als [[Intrusion Prevention System|Network Intrusion Prevention System]] (NIPS) einsetzbar
: (in den Datenverkehr eingreift und Pakete blockieren)
: 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
* [[GNU General Public License|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
; Anwendung
Zeile 21: Zeile 32:
{| class="wikitable sortable options"
{| class="wikitable sortable options"
|-
|-
|Hersteller || [https://oisf.net/ Open Information Security Foundation]
 
|-
|-
|Betriebssystem || [[FreeBSD]], [[Linux]], [[Unix]], [[macOS]], [[Microsoft Windows|Windows]]
|Betriebssystem || [[FreeBSD]], [[Linux]], [[Unix]], [[macOS]], [[Microsoft Windows|Windows]]
Zeile 35: Zeile 46:


; Entwicklung
; Entwicklung
* 2008 durch Matt Jonkman, Will Metcalf und Victor Julien
* seit 2008 durch Matt Jonkman, Will Metcalf und Victor Julien
Suricata-Konferenz (SuriCon)
 
* 2015 in Barcelona
; Sicherheit
* 2016 in Washington D.C.
; Ein IDS/IPS kann nur vor bekannten Angriffen und Sicherheitslücken schützen!
* 2017 in Prag
* nicht vor unbekannten
* 2018 in Vancouver
 
* 2019 in Amsterdam
; 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.


; Funktionen
{| class="wikitable sortable options"
{| class="wikitable sortable options"
|-
|-
Zeile 61: Zeile 86:
| [[HTTP]]-Engine (libhtp) ||  
| [[HTTP]]-Engine (libhtp) ||  
|-
|-
| PCRE-Support ||  
| [[PCRE]]-Support ||  
|-
|-
| [[Lua]]-Skripte ||  
| [[Lua]]-Skripte ||  
Zeile 84: Zeile 109:
|}
|}


== Installation ==
=== 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.
== Siehe auch ==
* So können bei einer aktuellen Multicore-CPU die Analyseaufgaben auf mehrere gleichzeitig laufende Prozesse aufgeteilt werden, was eine parallele Paketverarbeitung ermöglicht.
# [[Stateful Packet Inspection]]
# [[Snort]]


=== Dokumentation ===
; Multithread-fähige Vorgänge
* Paketempfang
* Paketdekodierung
* Paketanalyse
* Paketverarbeitung


# https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Installation
Jeder dieser Vorgänge kann nicht nur individuell auf eine oder mehrere CPUs aufgeteilt, sondern auch zusätzlich noch priorisiert werden.  
# https://suricata.readthedocs.io/en/latest/index.html
 
==== RFC ====
==== Man-Pages ====
==== Info-Pages ====
=== Links ===
==== Projekt ====
# [https://suricata.io/ Offizielle Website]
 
==== Weblinks ====
# [http://oisf.net/ OISF] – Foundation hinter Suricata
# [http://www.emergingthreats.net/ emergingthreats.net] – Community für Suricata Signaturen
 
==== Einzelnachweise ====
<references />
 
== Testfragen ==
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 1''
<div class="mw-collapsible-content">'''Antwort1'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 2''
<div class="mw-collapsible-content">'''Antwort2'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 3''
<div class="mw-collapsible-content">'''Antwort3'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 4''
<div class="mw-collapsible-content">'''Antwort4'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 5''
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>
 
[[Kategorie:Entwurf]]
[[Kategorie:Unix-Software]]
[[Kategorie:OPNsense/IDS]]
[[Kategorie:IDS]]
 
= TMP =
; 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.
 
== Installation ==
; Suricata lässt sich bei den meisten Linux-Distributionen bequem über die Paketverwaltung installieren.
* Natürlich ist auch der Bezug des Quellcodes über die '''Suricata-Homepage[1]''' möglich.
* Dann kann Suricata mit dem bekannten Dreigespann <tt>configure && make && make install</tt> installiert werden.
 
; Je nach Einsatzzweck erfordert Suricata verschiedene Bibliotheken, die bei Bedarf vorher installiert sein müssen.
* Soll etwa CUDA, eine spezielle Technik zur Einbindung der GPU bei rechenintensiven Berechnungen, genutzt werden, so sind entsprechende configure-Flags zu setzen.
* Einzelheiten zur Installation und spezielle Installationsbeschreibungen sind im '''Suricata-Wiki[2]''' zu finden.
 
== 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.
* In den Standardeinstellungen nutzt Suricata für den rechenintensivsten Prozess, die Paketanalyse, einen Thread pro CPU.


Zeile 164: Zeile 126:
; Multithreading-Standardeinstellungen bei 4 CPUs
; Multithreading-Standardeinstellungen bei 4 CPUs


; Folgende Begriffe werden dabei verwendet
; Begriffe
* Empfang  
{| class="wikitable options"
* Pakete werden vom Netzwerk gelesen.
|-
* Decodierung  
! Begriff !! Beschreibung
* Pakete werden auf TCP-Ebene decodiert und der Original-Datenstrom wird restauriert.
|-
* Analyse  
| Empfang || Pakete vom Netzwerk lesen
* Der Datenstrom wird mit den hinterlegten Signaturen verglichen.
|-
* Output  
| Decodierung || Pakete auf TCP-Ebene decodieren und Original-Datenstrom restaurieren
|-
| Analyse || Datenstrom mit aktivierten Signaturen vergleichen
|-
| Output || Alarmierungen und Ereignisse verarbeiten
|}


Evtl. auftretene Alarmierungen und Ereignisse werden verarbeitet.
<noinclude>


== Konfiguration ==
== Anhang ==
Die Konfiguration von Suricata erfolgt im Verzeichnis '''/etc/suricata/'''.
=== Siehe auch ===
* Dort sollte mindestens die Datei '''suricata.yaml''' zu finden sein, die die Hauptkonfiguration beinhaltet.
{{Special:PrefixIndex/Suricata}}
* 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'''.
# [[Stateful Packet Inspection]]
* Hier lässt sich nicht nur das Regelwerk und die Einbindung von Netzwerkschnittstellen konfigurieren, sondern auch die Paketanalyse steuern.
# [[Snort]]


; 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.  
==== Sicherheit ====
* 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.
==== Dokumentation ====
# https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Installation
# https://suricata.readthedocs.io/en/latest/index.html


; Allen voran ist hier die wichtigste Variable <tt>HOME_NET</tt> zu nennen.
==== Links ====
* Diese Variable gibt den Adressbereich an, der durch das IDS geschützt werden soll, und kann eine einzelne IP-Adresse oder ein Netzwerkbereich sein.
===== Projekt =====
* In einer üblichen kleineren Netzwerktopologie wird man hier in der Praxis das LAN und vielleicht eine externe IP-Adresse finden.  
# [https://suricata.io/ Offizielle Website]
* Also z.B. <tt>HOME_NET: "[192.168.0.0/16,1.2.3.4]"</tt>.
# [https://oisf.net/ Open Information Security Foundation]
* 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 <tt>HOME_NET</tt> aufgenommen werden, da aufgrund von SNAT-Techniken (IP-Maskierung) sonst einige Angriffsmuster nicht als solche erkannt werden.


; Die Variable <tt>EXTERNAL_NET</tt> gibt an, welche IP-Adressen nicht zum lokalen Netzwerk gehören.
===== Weblinks =====
* Die Standardeinstellung ist auf <tt>EXTERNAL_NET: "!$HOME_NET"</tt> vorgegeben.
# [http://oisf.net/ OISF] – Foundation hinter Suricata
* Demnach wird alles als extern und potentiell böswillig angesehen, was nicht zum internen Netz gehört.
# [http://www.emergingthreats.net/ emergingthreats.net] – Community für Suricata Signaturen
 
; Neben <tt>HOME_NET</tt> und <tt>EXTERNAL_NET</tt> 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 <tt>*_CLIENT</nowiki></tt>- und <tt><nowiki>*_PORTS</tt>-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.
 
== Betrieb ==
; Suricata lässt sich prinzipiell in zwei verschiedenen 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.
 
== Regelwerk ==
; Mit der Aktualität und Genauigkeit des von Suricata genutzten Regelwerks steht und fällt die Wirksamkeit des Gesamtsystems.
* Neben frei verfügbaren Regelwerken, die z.B. auf '''emergingthreats.net[3]''' heruntergeladen werden können, gibt es mehrere Anbieter kommerzieller Regeln, die meist aktueller sind oder besondere Bereiche abdecken.
* Suricata sucht die Regeln standardmäßig in '''/etc/suricata/rules'''.
* Dort sind mehrere Regeln thematisch zu '''rules'''-Dateien zusammengefasst, die so in die Suricata-Konfigurationsdatei eingebunden werden können.
* Auch wenn es theoretisch möglich ist, neue Regeln manuell zu installieren, gibt es einfachere Wege.
* Denn die Suricata-Regeln sind glücklicherweise mit denen von snort kompatibel, sodass sich bestehende Werkzeuge zur Regelaktualisierung nutzen lassen.
 
== oinkmaster ==
; Bei der automatisierten Regelaktualisierung sei zum Beispiel '''oinkmaster[4]''' genannt, mit dessen Hilfe das Regelwerk aktuell gehalten werden kann:
# oinkmaster -i -u http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz -o /etc/suricata/rules
 
; oinkmaster lädt so ein Archiv des Regelwerks von der angegebenen URL herunter und 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 <tt>enablesid</tt>, <tt>disablesid</tt> und <tt>modifysid</tt> in der Datei '''/etc/oinkmaster.conf''' bekannt gemacht werden.
* Wurde beispielsweise eine ID über <tt>disablesid</tt> 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 ==
; Nun aber ein Blick auf den Aufbau einer einzelnen 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?
* 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 <tt>ALERT</tt>-Aktion zulässig.
* Eine Filterung über <tt>PASS</tt>, <tt>DROP</tt> oder <tt>REJECT</tt> ist nur im Inline-Modus möglich.
* Der Unterschied zwischen <tt>DROP</tt> und <tt>REJECT</tt> liegt in der Art, wie die Verbindung abgelehnt und beendet wird.
* Bei <tt>REJECT</tt> 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 <tt>$HOME_NET</tt> 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:
* <tt>msg</tt>: Die Meldung, die im Erfolgsfall ausgegeben und geloggt werden soll: »Communication to CnC«.
* <tt>reference</tt>: 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.
* <tt>sid</tt> und <tt>rev</tt>: Jede einzelne Regel wird mit einer eindeutigen Signature-ID (<tt>sid</tt>) in Verbindung mit der Revision des Regelwerks (<tt>rev</tt>) versehen.
* Dies ermöglicht z.B. eine automatisierte Pflege des Regelwerks, da jede Regel individuell über die <tt>sid</tt> angesprochen werden kann.
* <tt>classtype</tt>: Eine grobe Klassifikation, die die Relevanz des Regelverstoßes einordnet.
* Der hier spezifizierte <tt>classtype</tt> muss in der Datei <tt>/etc/suricata/classification.rules</tt> näher beschrieben werden und reicht von leichten Verstößen, wie nicht zuzuordnender Netzwerkverkehr, bis hin zu schwerwiegenderen Ereignissen, wie z.B. Einbruchsversuchen.
* <tt>priority</tt>: Überschreibt die aus der <tt>classtype</tt> abgeleitete Priorität.
* <tt>content</tt>: Analysiert den Datenbereich eines Pakets.
* Hier sind umfangreiche Abfragen bis hin zu regulären Ausdrücken möglich.
* <tt>flowbits</tt>: 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.
* <tt>flow</tt>: Ermöglicht Einschränkungen bezüglich der Verbindung, z.B. ob eine TCP-Verbindung tatsächlich vollständig aufgebaut wurde.
* <tt>vthreshold</tt>: 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.
* <tt>luajit</tt>: 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.
 
[[Image:.png|thumb|right|top|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.
 
== 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.
 
== Links ==
# http://suricata-ids.org/
# http://suricata-ids.org/
# https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Ubuntu_Installation_from_GIT
# https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Ubuntu_Installation_from_GIT
Zeile 383: Zeile 169:
# http://www.freiesmagazin.de/20150201-februarausgabe-erschienen
# http://www.freiesmagazin.de/20150201-februarausgabe-erschienen
# https://www.pro-linux.de/artikel/2/1751/6,ausgabe-und-alarmierung.html
# https://www.pro-linux.de/artikel/2/1751/6,ausgabe-und-alarmierung.html
[[Kategorie:OPNsense/IDS]]
[[Kategorie:Suricata]]
</noinclude>

Aktuelle Version vom 30. Mai 2023, 22:49 Uhr

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


Anwendung

Freie Firewall-Distributionen

Kommerzielle Anbieter

Ü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


Anhang

Siehe auch

  1. Stateful Packet Inspection
  2. Snort

Sicherheit

Dokumentation

  1. https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Installation
  2. https://suricata.readthedocs.io/en/latest/index.html

Links

Projekt
  1. Offizielle Website
  2. Open Information Security Foundation
Weblinks
  1. OISF – Foundation hinter Suricata
  2. emergingthreats.net – Community für Suricata Signaturen
  3. http://suricata-ids.org/
  4. https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Ubuntu_Installation_from_GIT
  5. http://www.emergingthreats.net/
  6. http://oinkmaster.sourceforge.net/
  7. http://www.hosfeld.de/
  8. http://www.freiesmagazin.de/20150201-februarausgabe-erschienen
  9. https://www.pro-linux.de/artikel/2/1751/6,ausgabe-und-alarmierung.html


Abgerufen von „https://wiki.foxtom.de/index.php?title=Suricata&oldid=72088“