Suricata/Betrieb: Unterschied zwischen den Versionen

Aus Foxwiki
K Textersetzung - „z.B.“ durch „z. B. “
Keine Bearbeitungszusammenfassung
 
Zeile 1: Zeile 1:
'''topic''' - Kurzbeschreibung
== Beschreibung ==
== Betrieb ==
== Betrieb ==
; Suricata lässt sich in zwei Modi betreiben
; Suricata lässt sich in zwei Modi betreiben
Zeile 58: Zeile 60:
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).  
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.
* Im Idealfall sollten also beide Zahlen <tt>0</tt> sein.
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Sicherheit ====
==== Dokumentation ====
==== Links ====
===== Projekt =====
===== Weblinks =====
[[Kategorie:Suricata]]
[[Kategorie:Suricata]]
</noinclude>

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

topic - Kurzbeschreibung

Beschreibung

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.


Anhang

Siehe auch

Sicherheit

Dokumentation

Links

Projekt
Weblinks