== Suricata: Einbruchserkennung mit dem Erdmännchen ==
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.
Von [mailto:info@hosfeld.de Alexander Hosfeld]
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.
[[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.
== 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 <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: 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.
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
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 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)
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.
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 configure && make && make install 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.
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.
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:
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 PF_RING an. Dafür ist jedoch das Kernel-Modul pf_ring erforderlich und Suricata muss mit --enable-pfring kompiliert worden sein.
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
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.
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 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 enablesid, disablesid und modifysid in der Datei /etc/oinkmaster.conf bekannt gemacht werden. Wurde beispielsweise 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)
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 ALERT-Aktion zulässig. Eine Filterung über PASS, DROP oder REJECT ist nur im Inline-Modus möglich. Der Unterschied zwischen DROP und REJECT liegt in der Art, wie die Verbindung abgelehnt und beendet wird. Bei REJECT wird der Absender über die Ablehnung informiert (z.B. mit einem TCP-RST Paket), während bei einem DROP der Verbindungsaufbau in einem Timeout endet.
Es folgt das Protokoll, das entweder namentlich auf Transportebene (ip, tcp, udp, icmp) oder auf Anwendungsebene (http, tls, ftp, smb) angegeben wird. Auf Anwendungsebene versucht Suricata das eingesetzte Protokoll unabhängig vom Port zu erkennen und kann daher eigenständig auch z.B. eine HTTP-Kommunikation auf nicht-Standard-Ports erkennen und überwachen.
Anschließend müssen noch die IP-Adressen und TCP-Ports von Absender und Empfänger angegeben werden. Dabei kann zur Unterstützung auf Variablen wie zum Beispiel $HOME_NET zurückgegriffen werden:
$HOME_NET any -> [69.60.114.5,69.64.52.243] any
überwacht alle Verbindungen aus dem zu schützenden Netz auf die beiden IP-Adressen 69.60.114.5 und 69.64.52.243.
In Klammern folgen weitere optionale Parameter:
msg: Die Meldung, die im Erfolgsfall ausgegeben und geloggt werden soll: »Communication to CnC«.
reference: Hier können weitere Informationen wie URLs angegeben werden, die ein Output-Plugin verarbeiten kann. Viele existierende Regeln verweisen hier z.B. auf externe Angriffidentifizierungssysteme, wie bugtraq oder CVE.
sid und rev: Jede einzelne Regel wird mit einer eindeutigen Signature-ID (sid) in Verbindung mit der Revision des Regelwerks (rev) versehen. Dies ermöglicht z.B. eine automatisierte Pflege des Regelwerks, da jede Regel individuell über die sid angesprochen werden kann.
classtype: Eine grobe Klassifikation, die die Relevanz des Regelverstoßes einordnet. Der hier spezifizierte classtype muss in der Datei /etc/suricata/classification.rules näher beschrieben werden und reicht von leichten Verstößen, wie nicht zuzuordnender Netzwerkverkehr, bis hin zu schwerwiegenderen Ereignissen, wie z.B. Einbruchsversuchen.
priority: Überschreibt die aus der classtype abgeleitete Priorität.
content: Analysiert den Datenbereich eines Pakets. Hier sind umfangreiche Abfragen bis hin zu regulären Ausdrücken möglich.
flowbits: Ermöglicht die Analyse von zusammenhängenden Paketen, sodass eine Regel nur dann zutrifft, wenn auch andere zutreffen. So lässt sich z.B. ein Alarm wegen Übermittlung eines Passworts auf eine vorhergehende Login-Abfrage beschränken.
flow: Ermöglicht Einschränkungen bezüglich der Verbindung, z.B. ob eine TCP-Verbindung tatsächlich vollständig aufgebaut wurde.
vthreshold: Es können Schwellenwerte definiert werden und erst nach Überschreitung wird ein Alarm ausgelöst. So können z.B. fehlerhafte Login-Versuche als Brute Force erkannt werden, wenn innerhalb von 30 Sekunden mehr als 10 Versuche unternommen wurden, sich per SSH auf einem Rechner einzuloggen.
luajit: Wurde Suricata mit Unterstützung für den Just-In-Time Compiler für LUA kompiliert, kann für eine sehr komplexe Regel ein LUA-Skript herangezogen werden.
Datei:.pngAlexander Hosfeld Volle Ausbaustufe: Suricata mit Echtzeit-Analyse und grafischer OberflächeAusgabe 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.
