- Ein IDS (Intrusion Detection System) erkennt Angriffe und alarmiert. Ein IPS (Intrusion Prevention System) erkennt Angriffe und blockiert sie aktiv. Die meisten modernen Systeme kombinieren beide Funktionen.
- Signaturbasierte Erkennung identifiziert bekannte Angriffsmuster. Verhaltensbasierte Erkennung (Anomalieerkennung) identifiziert Abweichungen vom Normalverhalten und kann auch unbekannte Angriffe erkennen.
- Für KMU ist die IPS-Funktion der Next-Generation-Firewall oft der pragmatischste Einstieg. Sie erfordert keine zusätzliche Hardware und ist in den meisten NGFW-Lizenzen enthalten.
- Dedizierte IDS/IPS-Systeme wie Suricata oder Snort bieten mehr Flexibilität und tiefere Analysemöglichkeiten, erfordern aber mehr Know-how im Betrieb.
- Ein IDS/IPS ohne Tuning produziert Massen von Fehlalarmen (False Positives) und wird schnell ignoriert. Regelmäßiges Tuning und die Anpassung an die eigene Umgebung sind Pflicht.
Was IDS und IPS leisten
Firewalls kontrollieren, welcher Datenverkehr passieren darf. IDS und IPS gehen einen Schritt weiter: Sie analysieren den erlaubten Datenverkehr auf bösartige Inhalte. Eine Firewall erlaubt HTTPS-Verkehr auf Port 443. Das IDS/IPS prüft, ob dieser HTTPS-Verkehr eine SQL-Injection enthält, ob er einem bekannten Exploit-Muster entspricht oder ob er verdächtige Verhaltensmuster aufweist.
Der Unterschied zwischen IDS und IPS liegt in der Reaktion:
IDS (Intrusion Detection System): Erkennt verdächtigen Datenverkehr und generiert einen Alarm. Der Datenverkehr wird nicht unterbrochen. Das IDS ist ein passives Überwachungssystem, vergleichbar mit einer Alarmanlage, die einen Einbruch meldet, aber die Tür nicht verriegelt.
IPS (Intrusion Prevention System): Erkennt verdächtigen Datenverkehr und blockiert ihn in Echtzeit. Das IPS sitzt inline im Datenpfad und kann einzelne Pakete oder ganze Verbindungen verwerfen. Es ist die Alarmanlage, die gleichzeitig die Tür verriegelt.
In der Praxis verschwimmt die Grenze: Die meisten modernen Systeme bieten beide Modi und können pro Regel konfiguriert werden, ob sie nur alarmieren oder aktiv blockieren.
Erkennungsmethoden
Signaturbasierte Erkennung
Die Grundlage jedes IDS/IPS. Signaturen sind Muster, die bekannte Angriffe beschreiben: eine bestimmte Byte-Folge in einem HTTP-Request (SQL-Injection), ein bekannter Exploit-Payload (CVE-2024-xxxx), ein verdächtiger User-Agent-String (Metasploit, Cobalt Strike).
Vorteile:
- Zuverlässige Erkennung bekannter Angriffe mit geringer Fehlerrate
- Geringe Rechenleistung pro Signatur
- Jeder Alarm ist einem konkreten Angriffsmuster zugeordnet und damit leicht zu bewerten
Nachteile:
- Erkennt nur bekannte Angriffe (keine Zero-Days)
- Erfordert regelmäßige Signatur-Updates (täglich bis stündlich)
- Polymorpher oder verschleierter Schadcode kann Signaturen umgehen
Die Qualität eines signaturbasierten IDS/IPS steht und fällt mit der Qualität und Aktualität der Signaturen. Etablierte Regelwerke:
- ET (Emerging Threats) Open: Kostenlose Regeln, gute Abdeckung, Community-gepflegt
- ET Pro: Kostenpflichtige Erweiterung mit schnelleren Updates und zusätzlichen Regeln
- Snort Community Rules: Kostenlose Basis-Regeln für Snort
- Snort Subscriber Rules: Kostenpflichtige Regeln mit schnelleren Updates (Cisco Talos)
Verhaltensbasierte Erkennung (Anomalieerkennung)
Statt nach bekannten Angriffsmustern zu suchen, lernt ein verhaltensbasiertes System das "normale" Verhalten im Netzwerk und alarmiert bei Abweichungen. Beispiele:
- Ein Server, der normalerweise nur HTTPS-Anfragen beantwortet, sendet plötzlich große Datenmengen über DNS (mögliche Exfiltration)
- Ein Client-PC baut Verbindungen zu hunderten verschiedenen IP-Adressen auf (mögliche Malware-Aktivität oder Port-Scanning, ein typisches Szenario eines kompromittierten Accounts)
- Ein Nutzer greift außerhalb der Arbeitszeiten auf Systeme zu, die er normalerweise nicht nutzt (möglicher kompromittierter Account)
Vorteile:
- Kann unbekannte Angriffe erkennen (Zero-Days)
- Erkennt Insider-Threats und kompromittierte Accounts
- Keine Signatur-Updates erforderlich
Nachteile:
- Hohe Rate von False Positives (Fehlalarmen), insbesondere nach Veränderungen im Netzwerk
- Erfordert eine Lernphase, in der das System das Normalverhalten erfasst
- Rechenintensiver als signaturbasierte Erkennung
- Schwieriger zu konfigurieren und zu tunen
Hybride Erkennung
Die meisten modernen IDS/IPS-Systeme kombinieren beide Methoden: Signaturbasierte Erkennung für bekannte Angriffe und verhaltensbasierte Erkennung für Anomalien. Diese Kombination bietet den besten Schutz, erfordert aber auch den höchsten Konfigurationsaufwand.
Deployment-Optionen für KMU
Option 1: IPS in der Next-Generation-Firewall
Die einfachste Option für KMU. Die meisten NGFWs (Fortinet, Sophos, Palo Alto, WatchGuard) haben ein integriertes IPS, das mit einem Klick aktiviert werden kann.
Vorteile:
- Keine zusätzliche Hardware erforderlich
- Zentrale Verwaltung über die Firewall-Oberfläche
- Automatische Signatur-Updates über den Hersteller
- IPS-Regeln können direkt mit Firewall-Regeln kombiniert werden
Nachteile:
- Performance-Einbußen auf der Firewall (insbesondere bei SSL-Inspektion + IPS)
- Weniger Flexibilität als ein dediziertes System
- Abhängigkeit vom Firewall-Hersteller für Signaturen und Updates
- Begrenzte Analysemöglichkeiten und Reporting
Empfehlung: Für KMU mit bis zu 200 Mitarbeitern ist das NGFW-integrierte IPS ein sehr guter Startpunkt. Stelle sicher, dass die Firewall für die zusätzliche IPS-Last dimensioniert ist (IPS + SSL-Inspektion kann den Durchsatz um 40 bis 60 % reduzieren).
Option 2: Dediziertes IDS/IPS mit Suricata oder Snort
Suricata und Snort sind die beiden führenden Open-Source-IDS/IPS-Engines.
Snort wurde 1998 von Martin Roesch entwickelt und ist der Pionier der netzwerkbasierten Intrusion Detection. Seit der Übernahme durch Cisco (2013) wird Snort als Grundlage für das Cisco Firepower IPS weiterentwickelt. Snort 3 ist die aktuelle Version mit verbesserter Performance und neuer Plugin-Architektur.
Suricata wurde 2009 von der Open Information Security Foundation (OISF) als Alternative zu Snort entwickelt. Suricata unterstützt Multi-Threading (bessere Performance auf modernen Servern), hat native Protokoll-Dekodierung für mehr als 40 Protokolle und integriert sich nahtlos in das Elastic Stack (ELK) für Analyse und Visualisierung.
Typisches Deployment:
- Suricata/Snort auf einem dedizierten Server oder einer virtuellen Maschine installieren
- Netzwerkverkehr über einen Mirror-Port (SPAN) am Switch oder über einen Network TAP zum IDS leiten
- Regelwerk (ET Open/Pro) laden und aktivieren
- Alerts an ein zentrales Log-Management oder SIEM weiterleiten (z. B. Elastic Stack, Graylog, Wazuh)
- Regelmäßig Tuning durchführen: False Positives supprimieren, fehlende Regeln ergänzen
Wann lohnt sich ein dediziertes System? Wenn du tiefere Analysen brauchst, wenn die NGFW-Performance nicht ausreicht, wenn du bestimmte Netzwerksegmente separat überwachen willst oder wenn du regulatorische Anforderungen hast, die ein dediziertes IDS vorschreiben.
Option 3: Host-basiertes IDS (HIDS)
Neben netzwerkbasierten Systemen gibt es host-basierte IDS, die auf den Endpunkten (Servern, Clients) laufen und dort verdächtige Aktivitäten erkennen: Dateiänderungen, Registry-Manipulationen, verdächtige Prozesse, Login-Anomalien.
OSSEC/Wazuh: Open-Source-HIDS mit Dateiintegritätsprüfung, Log-Analyse, Rootkit-Erkennung und Active Response. Wazuh ist der aktive Fork von OSSEC und bietet eine moderne Web-Oberfläche, Elastic-Integration und Cloud-Kompatibilität.
Empfehlung: Ein HIDS ergänzt ein netzwerkbasiertes IDS/IPS sinnvoll. Die Kombination aus NIDS (Suricata) und HIDS (Wazuh) bietet eine gute Erkennungstiefe für KMU.
Option 4: Managed IDS/IPS (MDR)
Wenn du nicht die Ressourcen hast, ein IDS/IPS selbst zu betreiben und zu tunen, kannst du einen Managed Detection and Response (MDR) Dienstleister beauftragen. Der MDR-Anbieter installiert Sensoren in deinem Netzwerk, überwacht die Alerts rund um die Uhr und eskaliert relevante Vorfälle an dich.
Vorteile: Professionelle Überwachung ohne eigenes SOC-Team, schnelle Reaktion, 24/7-Abdeckung. Nachteile: Laufende Kosten, Abhängigkeit vom Dienstleister, sensible Netzwerkdaten verlassen (teilweise) das Unternehmen.
Signatur-Tuning: Vom Alarm-Tsunami zur relevanten Meldung
Ein frisch installiertes IDS mit Default-Regeln produziert hunderte bis tausende Alarme pro Tag. Die meisten davon sind False Positives: legitimer Datenverkehr, der zufällig einem Angriffsmuster ähnelt, oder Regeln, die für deine spezifische Umgebung nicht relevant sind.
Wenn du das nicht tunst, passiert folgendes: Das zuständige Team wird von Alarmen überflutet, beginnt sie zu ignorieren, und wenn ein echter Angriff stattfindet, geht er in der Masse unter. Das ist schlimmer als gar kein IDS, weil es ein falsches Sicherheitsgefühl erzeugt.
Tuning-Prozess
Phase 1: Baseline erstellen (Woche 1 bis 2). Betreibe das IDS im reinen Detection-Modus (kein Blocking). Sammle alle Alerts und analysiere die häufigsten Meldungen.
Phase 2: False Positives identifizieren (Woche 2 bis 4). Gehe die häufigsten Alerts durch und prüfe, ob sie tatsächliche Bedrohungen oder False Positives sind. Häufige False Positives:
- DNS-Anfragen an legitime Dienste, die wie C2-Kommunikation aussehen
- HTTP-Anfragen mit speziellen Zeichen (die wie SQL-Injection aussehen, aber legitime Parameter sind)
- Interne Scans von Vulnerability-Scannern oder Monitoring-Tools
- Protokoll-Anomalien durch ältere Geräte oder proprietäre Protokolle
Phase 3: Regeln anpassen (laufend). Für bestätigte False Positives:
- Suppress-Regeln: Unterdrücke den Alert für bestimmte Quell- oder Ziel-IPs
- Threshold-Regeln: Alarmiere erst, wenn ein Muster n-mal innerhalb von x Sekunden auftritt
- Deaktivierung: Schalte Regeln ab, die für deine Umgebung nicht relevant sind (z. B. SCADA-Regeln, wenn du keine OT-Systeme hast)
Phase 4: Prevention aktivieren (ab Woche 4 bis 6). Wenn die False-Positive-Rate auf ein handhabbares Niveau gesunken ist, schalte kritische Regeln vom Detection- in den Prevention-Modus. Beginne mit den sichersten Regeln (bekannte Exploits, C2-Kommunikation zu bekannten Malware-Domains) und erweitere schrittweise.
Phase 5: Kontinuierliches Tuning (dauerhaft). Das Tuning ist nie abgeschlossen. Neue Dienste, neue Anwendungen, neue Netzwerksegmente erzeugen neue Alerts, die geprüft und bewertet werden müssen. Plane wöchentlich eine Stunde für die Auswertung der IDS-Alerts ein.
IDS/IPS und verschlüsselter Datenverkehr
Ein netzwerkbasiertes IDS/IPS kann nur unverschlüsselten Datenverkehr analysieren. In einer Welt, in der über 90 % des Webverkehrs verschlüsselt ist (HTTPS), hat ein IDS ohne SSL-Inspektion eine massive blinde Stelle.
Lösungsansätze
SSL-Inspektion auf der Firewall. Die NGFW entschlüsselt den HTTPS-Verkehr, inspiziert ihn (inkl. IPS-Prüfung) und verschlüsselt ihn wieder, bevor er an den Client weitergeleitet wird. Das erfordert die Installation eines internen CA-Zertifikats auf allen Clients.
SSL-Inspektion vor dem IDS. Ein SSL-Proxy (z. B. PolarProxy) entschlüsselt den Datenverkehr und leitet ihn an das IDS weiter. Das IDS analysiert den Klartext-Traffic.
Metadaten-Analyse. Auch ohne Entschlüsselung können IDS/IPS-Systeme die Metadaten verschlüsselter Verbindungen analysieren: JA3-Fingerprints (TLS-Client-Fingerprinting), Server Name Indication (SNI), Zertifikats-Details, Verbindungsmuster. Suricata hat umfangreiche TLS-Analyse-Funktionen.
Endpoint Detection. Als Ergänzung zum netzwerkbasierten IDS: EDR-Lösungen auf den Endpunkten analysieren den Datenverkehr nach der Entschlüsselung und erkennen bösartige Inhalte auf Betriebssystemebene.
ISO 27001 und NIS2: Anforderungen an IDS/IPS
ISO 27001 fordert in mehreren Controls die Erkennung und Behandlung von Sicherheitsvorfällen:
- A.8.16 (Monitoring activities): Netzwerke, Systeme und Anwendungen müssen auf anomales Verhalten überwacht werden – ein zentraler Baustein der Logging- und Monitoring-Strategie. Ein IDS/IPS ist eine direkte Umsetzung dieser Anforderung.
- A.8.20 (Network security): Netzwerke und Netzwerkdienste müssen abgesichert werden.
- A.5.25 (Assessment and decision on information security events): Sicherheitsereignisse müssen bewertet werden, um festzustellen, ob sie als Sicherheitsvorfall einzustufen sind.
NIS2 fordert in Art. 21 "Maßnahmen zum Umgang mit Sicherheitsvorfällen" und "Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Schwachstellenmanagement". Ein IDS/IPS ist eine angemessene technische Maßnahme zur Erfüllung dieser Anforderungen.
Praxisbeispiel: IDS/IPS für ein KMU mit 120 Mitarbeitern
Ausgangssituation: Mittelständisches Unternehmen, 120 Mitarbeiter, eine FortiGate 100F als Firewall, zwei Standorte mit Site-to-Site-VPN, 30 Mitarbeiter im Homeoffice.
Lösung:
-
IPS auf der FortiGate aktivieren: FortiGate IPS mit FortiGuard-Signaturen, Profil "Default" als Ausgangsbasis, SSL-Inspektion für ausgehenden Webverkehr.
-
Suricata auf einem dedizierten Server: Für tiefere Analyse und zusätzliche Erkennungsschicht. Netzwerkverkehr über SPAN-Port vom Core-Switch. ET Open als Regelwerk, ergänzt um eigene Suppress-Regeln.
-
Wazuh als HIDS: Auf den Servern (Domaincontroller, Dateiserver, ERP-Server). Dateiintegritätsprüfung, Log-Analyse, Rootkit-Erkennung.
-
Elastic Stack für zentrale Analyse: Suricata-Alerts, Wazuh-Alerts und FortiGate-Logs fließen in Elasticsearch. Kibana-Dashboards für Überblick und Drill-Down.
-
Wöchentliches Alert-Review: Ein IT-Mitarbeiter prüft wöchentlich die Top-Alerts, bewertet False Positives und passt die Regeln an. In ISMS Lite dokumentierst du das IDS/IPS als technische Maßnahme und trackst die Alert-Reviews als wiederkehrende Aufgabe im Maßnahmenplan.
Kosten: Hardware für den Suricata-Server (ca. 1.500 bis 2.000 Euro), FortiGate-IPS-Lizenz (in der UTM-Lizenz enthalten, ca. 800 Euro/Jahr), Suricata/Wazuh/Elastic sind Open Source (kostenlos). Personalaufwand: ca. 2 bis 4 Stunden pro Woche für Monitoring und Tuning.
Ergebnis nach drei Monaten: Die False-Positive-Rate ist von mehreren hundert Alerts pro Tag auf unter zehn relevante Meldungen pro Woche gesunken. Das IPS auf der FortiGate hat in den ersten 90 Tagen drei tatsächliche Angriffsversuche blockiert: einen Exploit-Versuch gegen eine bekannte Schwachstelle im Exchange-Server, einen Port-Scan aus einem osteuropäischen IP-Bereich und einen Command-and-Control-Kommunikationsversuch durch eine Malware-Infektion auf einem Client.
Weiterführende Artikel
- Firewall-Konfiguration für KMU: Regeln, Zonen und Best Practices
- DNS-Sicherheit: DNS-Filtering, DNSSEC und DNS over HTTPS
- Logging und Monitoring: Strategie für den Mittelstand
- Sicherheitsvorfall erkennen, bewerten und melden
- Reverse Proxy und WAF: Webanwendungen vor Angriffen schützen
Ein IDS/IPS ist kein Allheilmittel. Es erkennt nicht jeden Angriff, es produziert False Positives, und es erfordert kontinuierliche Pflege. Aber als Teil einer mehrschichtigen Sicherheitsarchitektur, zusammen mit Firewall, Segmentierung, Endpoint-Protection und Logging, schließt es eine kritische Lücke: die Erkennung von Angriffen, die alle anderen Maßnahmen überwunden haben.
