Technologieführer

IPS (Intrusion Prevention System) auf Fedora 17 einrichten

5 min read IT-Sicherheit Aktualisiert 24 Sep 2025
IPS auf Fedora 17 mit Suricata & Vuurmuur
IPS auf Fedora 17 mit Suricata & Vuurmuur

Dieser Leitfaden zeigt, wie Sie mit den Fedora-Paketen Suricata (IDS/IPS) und Vuurmuur (Firewall-Manager) ein funktionales IPS auf Fedora 17 einrichten. Zuerst testen Sie Suricata im passiven IDS-Modus, dann leiten Sie den Verkehr per nfqueue an Suricata weiter und aktivieren Drop-Regeln.

Kurzüberblick: Werkzeuge und Begriffe

  • Vuurmuur: Ein Linux-Firewall-Manager, der eine menschenlesbare Regelsyntax in iptables/Netfilter-Befehle übersetzt. Unterstützt Log-Ansicht, Traffic-Shaping und mehr.
  • Suricata: Multithreaded Network IDS/IPS mit Unterstützung für IDS- und IPS-Modus, HTTP-Dateiextraktion und leistungsorientierter Verarbeitung.
  • IDS vs. IPS: IDS erkennt und meldet, IPS kann aktiv Verkehr blockieren (Drop).

Vorbereitung: Pakete installieren

Installieren Sie Vuurmuur und Suricata aus den Fedora-Repositories mit yum:

yum install suricata Vuurmuur-daemon Vuurmuur-tui

Suricata zuerst im IDS-Modus testen

Weil ein IPS bei Fehlkonfigurationen Verkehr blockieren kann, starten Sie mit dem passiven IDS-Modus.

Laden Sie die freien Emerging Threats Regeln (für Suricata optimiert) und legen Sie sie unter /etc/suricata/rules/ ab:

cd /etc/suricata/  
curl -O https://rules.emergingthreatspro.com/open/suricata/emerging.rules.tar.gz  
tar xzvf emerging.rules.tar.gz  
ln -s /etc/suricata/rules/reference.config /etc/suricata/reference.config  
ln -s /etc/suricata/rules/classification.config /etc/suricata/classification.config  
cp /etc/suricata/rules/suricata-1.2-prior-open.yaml /etc/suricata/suricata.yaml

Testen Sie Suricata manuell gegen ein Interface (z. B. eth0):

suricata -c /etc/suricata/suricata.yaml -i eth0

Lassen Sie Suricata einige Minuten laufen und prüfen Sie /var/log/suricata/stats.log und /var/log/suricata/http.log, während Sie Traffic erzeugen (z. B. Browser öffnen).

Suricata im IPS-Modus betreiben (Traffic an Suricata übergeben)

Damit Suricata aktiv Verkehr inspiziert und blockiert, muss Netfilter so konfiguriert sein, dass Pakete an Suricata über nfqueue weitergereicht werden. Wir verwenden Vuurmuur zur Verwaltung der Firewallregeln.

  1. Öffnen Sie das Vuurmuur-Konfigurationswerkzeug (vuurmuur_conf), wechseln Sie zu “Rules” und fügen Sie eine neue Regel hinzu:
accept service any from any to any log

Das sieht in der GUI etwa so aus:

Vuurmuur-Regel-Editor mit einer

  1. Damit der Vuurmuur-Dienst gestartet werden kann, fügen Sie ein Interface hinzu (z. B. eth0). In der GUI: “Interfaces” → neues Interface → Device: “eth0”.

Vuurmuur: Interface-Eintrag mit Device eth0

  1. Für korrektes Logging passen Sie rsyslog an: Öffnen Sie /etc/rsyslog.conf und fügen Sie folgendes hinzu:
*.debug /var/log/debug

Starten Sie rsyslog neu:

service rsyslog restart
  1. Starten Sie Vuurmuur und aktivieren Sie den Dienst für den Bootvorgang:
service vuurmuur start
systemctl enable vuurmuur.service

Prüfen Sie im Vuurmuur-Logviewer, ob Traffic vorbei läuft:

Vuurmuur Logviewer mit Live-Traffic-Anzeige

  1. Um Pakete an Suricata weiterzugeben, ändern Sie in Vuurmuur die vorherige Regel auf:
nfqueue service any from any to any

Die Regel in der GUI sieht so aus:

Vuurmuur-Regel-Editor mit

Wählen Sie “apply changes” in vuurmuur_conf — Vuurmuur aktualisiert automatisch die Firewall. Der Logviewer sollte nun nfqueue-Einträge zeigen:

Vuurmuur Logviewer zeigt nfqueue-Traffic

  1. Starten Sie Suricata im Hintergrund mit nfqueue-Unterstützung:
suricata -c /etc/suricata/suricata.yaml -q0

Öffnen Sie den Browser und prüfen Sie erneut /var/log/suricata/stats.log und /var/log/suricata/http.log, um zu bestätigen, dass Suricata den Verkehr verarbeitet.

Beispielauszug aus stats.log (gekürzt):

-------------------------------------------------------------------
Date: 10/8/2012 -- 17:20:08 (uptime: 0d, 01h 39m 02s)
-------------------------------------------------------------------
Counter                   | TM Name                   | Value
-------------------------------------------------------------------
decoder.pkts              | Decode1                   | 3147
... 
detect.alert              | Detect                    | 0

Beispielauszug aus http.log:

10/08/2012-17:24:02.447292 www.howtoforge.com [] / [] Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1 [] 192.168.122.48:48396 -> 188.40.16.205:80
  1. Um Suricata als Daemon zu betreiben, beenden Sie den interaktiven Prozess und bearbeiten Sie /etc/sysconfig/suricata. Setzen Sie OPTIONS wie folgt:
OPTIONS="-q 0 -D --pidfile /var/run/suricata.pid"

Starten und aktivieren Sie Suricata als Service:

service suricata start
systemctl enable suricata.service

Traffic gezielt blockieren (Drop-Regeln)

Bis hierhin meldet Suricata nur (alert). Um aktiv zu blocken, müssen Sie Suricata so konfigurieren, dass es inline/stream-aware arbeitet, und Drop-Regeln anlegen.

  1. Öffnen Sie /etc/suricata/suricata.yaml und setzen Sie im Abschnitt stream “inline” auf “yes”:
stream:
  memcap: 32mb
  checksum_validation: yes      # reject wrong csums
  inline: yes
  1. Stellen Sie sicher, dass die rule-files in suricata.yaml lokale Regeln laden, z. B.:
default-rule-path: /etc/suricata/rules/
rule-files:
 - local.rules
 - emerging-ftp.rules
 - emerging-policy.rules
  1. Erstellen Sie /etc/suricata/rules/local.rules mit einer Drop-Regel. Beispiel — Facebook blockieren:
drop tcp any any -> any any (msg:"facebook is blocked"; content:"facebook.com"; http_header; nocase; classtype:policy-violation; sid:1;)
  1. Starten Sie Suricata neu:
service suricata restart
  1. Test: Rufen Sie http://www.facebook.com/ auf — die Verbindung sollte abbrechen (Timeout). Das Log /var/log/suricata/fast.log zeigt Drop-Einträge:
10/06/2012-11:40:49.018377  [Drop] [] [1:1:0] facebook is blocked [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 192.168.122.48:57113 -> 173.252.100.16:80

Wichtig: Regeln, die Drop verwenden, können produktive Dienste beeinflussen. Testen Sie Regeln sorgfältig in einer Staging-Umgebung.

Sicherheits- und Betriebs-Hinweise

  • Backup: Sichern Sie /etc/suricata/ und Ihre Vuurmuur-Konfiguration vor Änderungen.
  • Testen Sie jede Regel zunächst als “alert” bevor Sie sie auf “drop” setzen.
  • Performance: Suricata ist multithreaded — beobachten Sie CPU- und Speicherverbrauch und justieren Sie memcap/Thread-Anzahl.
  • Fail-open vs. Fail-closed: Entscheiden Sie, ob beim IPS-Ausfall der Verkehr weitergereicht (fail-open) oder blockiert (fail-closed) werden soll.

Hinweis: Das Logging kann personenbezogene Daten enthalten. Prüfen Sie Aufbewahrungsfristen und Datenschutzeinstellungen entsprechend DSGVO.

Regelmanagement & Pflege

  • Regelquellen: Emerging Threats, kommerzielle Feeds oder eigene lokale Regeln.
  • Automatisierung: Werkzeuge wie oinkmaster oder pulledpork helfen beim Aktualisieren von Regeln und der SID-Verwaltung.
  • Änderungsprozess: Versionieren Sie Regeln (Git), testen Sie in Staging, dann rollen Sie in Produktion aus.

Maturity-Modelle / Reifegrad eines IPS-Betriebs (Kurz):

  • Level 1 — Deployment: Suricata läuft im IDS-Modus, Logs werden gesammelt.
  • Level 2 — Monitoring: Alerts untersucht, Priorisierung etabliert.
  • Level 3 — IPS: Selektive Drop-Regeln, SLA für False-Positives.
  • Level 4 — Automatisierung: Regel-Updates, Rollback-Prozesse, Performance-Tuning.

Entscheidungs-Checkliste vor Aktivierung von Drop-Regeln

  • Backup der Konfiguration erstellt
  • Suricata im IDS-Modus mindestens 24–72 Stunden getestet
  • Metriken (CPU, RAM, Latenz) überwacht
  • Eskalations- und Rollback-Prozedur dokumentiert
  • Stakeholder über mögliche Seiteneffekte informiert

Schnelles Rollback / Incident-Runbook (Kurz)

  1. Falls massives Blocking auftritt: Deaktivieren Sie die nfqueue-Regel in Vuurmuur (ersetzen Sie nfqueue durch accept) und “apply changes”.
  2. Stoppen Sie Suricata: service suricata stop
  3. Reaktivieren Sie vorherige Firewall-Policy oder laden Sie ein Backup der Vuurmuur-Konfiguration.
  4. Analysieren Sie die Logs (/var/log/suricata/fast.log, /var/log/suricata/stats.log) und identifizieren Sie die fehlerhafte Regel(sid).
  5. Korrigieren, testen als alert und wieder in production setzen.

Kurzer Glossar (1‑Zeiler)

  • NFQUEUE: Netfilter-Mechanismus zum Weiterleiten von Paketen an Userspace-Programme.
  • SID: Regel-ID (Suricata/IDS Signatur ID).
  • inline stream reassembly: TCP-Stream-Zusammenbau, damit IPS auf Anwendungsebene treffen kann.

Weiterführende Literatur

  • Suricata User Guide
  • Regelverwaltung mit oinkmaster / pulledpork
  • Vuurmuur Benutzerhandbuch

Zusammenfassung

Dieser Leitfaden führt Sie Schritt für Schritt von der Installation über das Testen im IDS-Modus bis hin zum produktiven IPS-Betrieb mit Drop-Regeln. Testen Sie Regeln sorgfältig, beobachten Sie Performance und definieren Sie klare Rollback-Prozeduren, bevor Sie Drop-Regeln in Produktion übernehmen.

Autor
Redaktion

Ähnliche Materialien

Podman auf Debian 11 installieren und nutzen
DevOps

Podman auf Debian 11 installieren und nutzen

Apt-Pinning: Kurze Einführung für Debian
Systemadministration

Apt-Pinning: Kurze Einführung für Debian

FSR 4 in jedem Spiel mit OptiScaler
Grafikkarten

FSR 4 in jedem Spiel mit OptiScaler

DansGuardian + Squid (NTLM) auf Debian Etch installieren
Netzwerk

DansGuardian + Squid (NTLM) auf Debian Etch installieren

App-Installationsfehler auf SD-Karte (Error -18) beheben
Android

App-Installationsfehler auf SD-Karte (Error -18) beheben

Netzwerkordner mit KNetAttach in KDE
Linux Netzwerk

Netzwerkordner mit KNetAttach in KDE