|
|
(66 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 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 37: |
Zeile 48: |
| * seit 2008 durch Matt Jonkman, Will Metcalf und Victor Julien | | * seit 2008 durch Matt Jonkman, Will Metcalf und Victor Julien |
|
| |
|
| ; Funktionen | | ; 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. |
| | |
| {| class="wikitable sortable options" | | {| class="wikitable sortable options" |
| |- | | |- |
Zeile 55: |
Zeile 86: |
| | [[HTTP]]-Engine (libhtp) || | | | [[HTTP]]-Engine (libhtp) || |
| |- | | |- |
| | PCRE-Support || | | | [[PCRE]]-Support || |
| |- | | |- |
| | [[Lua]]-Skripte || | | | [[Lua]]-Skripte || |
Zeile 78: |
Zeile 109: |
| |} | | |} |
|
| |
|
| | === 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. |
|
| |
|
| ; 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. | | ; Multithread-fähige Vorgänge |
| * So kann der Systemadministrator bei Unregelmäßigkeiten informiert werden oder über eine Rückschaltung zur Firewall die unerwünschte Kommunikation gänzlich unterbunden werden. | | * Paketempfang |
| * Im Folgenden soll die grundlegende Funktionalität von Suricata, einem signaturbasierten Intrusion Detection System (IDS) beschrieben werden. | | * Paketdekodierung |
| | * Paketanalyse |
| | * Paketverarbeitung |
|
| |
|
| ; 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.
| | Jeder dieser Vorgänge kann nicht nur individuell auf eine oder mehrere CPUs aufgeteilt, sondern auch zusätzlich noch priorisiert werden. |
| * Durch Funktionen wie Multithreading, Scripting und High Performance Detection hat sich Suricata mittlerweile fest als Alternative zu snort, dem bisherigen IDS-Platzhirsch, etabliert. | | * 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"]] |
|
| |
|
| 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.
| | ; Multithreading-Standardeinstellungen bei 4 CPUs |
|
| |
|
| == Installation ==
| | ; Begriffe |
| # '''apt install suricata'''
| | {| class="wikitable options" |
| | | |- |
| == Konfiguration == | | ! Begriff !! Beschreibung |
| ; Die Konfiguration von Suricata erfolgt im Verzeichnis ''/etc/suricata/''
| | |- |
| * Dort sollte mindestens die Datei ''suricata.yaml'' zu finden sein, die die Hauptkonfiguration beinhaltet
| | | Empfang || Pakete vom Netzwerk lesen |
| * 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''
| | | Decodierung || Pakete auf TCP-Ebene decodieren und Original-Datenstrom restaurieren |
| * Hier lässt sich nicht nur das Regelwerk und die Einbindung von Netzwerkschnittstellen konfigurieren, sondern auch die Paketanalyse steuern
| | |- |
| | | | Analyse || Datenstrom mit aktivierten Signaturen vergleichen |
| ; 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?
| | | Output || Alarmierungen und Ereignisse verarbeiten |
| * Es geht also darum, Suricata das zu schützende Netz möglichst genau zu beschreiben.
| | |} |
| | |
| ; Allen voran ist hier die wichtigste Variable <tt>HOME_NET</tt> 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. <tt>HOME_NET: "[192.168.0.0/16,1.2.3.4]"</tt>.
| |
| * 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.
| |
| * Die Standardeinstellung ist auf <tt>EXTERNAL_NET: "!$HOME_NET"</tt> vorgegeben.
| |
| * Demnach wird alles als extern und potentiell böswillig angesehen, was nicht zum internen Netz gehört.
| |
| | |
| ; 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
| | <noinclude> |
| Je genauer diese sind, desto performanter ist der Analyse-Prozess und desto weniger falsch-positive Meldungen treten auf.
| |
|
| |
|
| === Dateien === | | == Anhang == |
| ; The main configuration file is /etc/suricata/suricata.yaml
| | === Siehe auch === |
| | | {{Special:PrefixIndex/Suricata}} |
| ; 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
| |
| | |
| == Siehe auch ==
| |
| # [[Stateful Packet Inspection]] | | # [[Stateful Packet Inspection]] |
| # [[Snort]] | | # [[Snort]] |
|
| |
|
| === Dokumentation === | | ==== Sicherheit ==== |
| | ==== Dokumentation ==== |
| # https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Installation | | # https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Installation |
| # https://suricata.readthedocs.io/en/latest/index.html | | # https://suricata.readthedocs.io/en/latest/index.html |
|
| |
|
| ==== RFC ==== | | ==== Links ==== |
| ==== Man-Pages ==== | | ===== Projekt ===== |
| ==== Info-Pages ====
| |
| === Links ===
| |
| | |
| ==== Projekt ====
| |
| # [https://suricata.io/ Offizielle Website] | | # [https://suricata.io/ Offizielle Website] |
| | # [https://oisf.net/ Open Information Security Foundation] |
|
| |
|
| ==== Weblinks ==== | | ===== Weblinks ===== |
| # [http://oisf.net/ OISF] – Foundation hinter Suricata | | # [http://oisf.net/ OISF] – Foundation hinter Suricata |
| # [http://www.emergingthreats.net/ emergingthreats.net] – Community für Suricata Signaturen | | # [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]]
| |
|
| |
| = Archwiki =
| |
|
| |
|
| |
| == 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
| |
|
| |
| = TMP =
| |
| == 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 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.
| |
|
| |
| == 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 366: |
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> |