Netzwerk Intrusion Detection mit Snort in schnellen Netzen

Zusammenfassung

Edin Dizdarevic zeigte auf den Chemnitzer Linux-Tagen 2003, wie das freie Network Intrusion Detection System Snort arbeitet und wie es in schnellen Netzen zuverlässig läuft. Snort liest den Netzwerkverkehr mit, vergleicht ihn mit Regeln für bekannte Angriffsmuster und meldet Treffer als Alarm. Kern des Vortrags war „Weniger ist mehr“: wenige, passend gewählte Regeln und Präprozessoren statt aller verfügbaren Funktionen.

Was ist Snort?

Snort ist ein Network Intrusion Detection System, kurz NIDS. Martin Roesch veröffentlichte es 1998 als freie Software unter der GPL. Snort setzt auf libpcap auf, liest also wie tcpdump die Pakete einer Netzwerkschnittstelle mit, und kann in drei Betriebsarten laufen: als reiner Paketmitschnitt, als Paketlogger und als Erkennungssystem.

Im Erkennungsbetrieb prüft Snort jedes Paket gegen Regeln. Eine Regel beschreibt Protokoll, Adressen und Ports und dazu typische Merkmale eines Angriffs, etwa eine bestimmte Bytefolge im Inhalt. Präprozessoren setzen vorher zerstückelte Pakete und TCP-Datenströme wieder zusammen, damit sich Angriffe nicht einfach auf mehrere Pakete verteilen lassen.

Warum braucht man das?

Eine Firewall entscheidet, welche Verbindungen erlaubt sind. Was innerhalb einer erlaubten Verbindung passiert, sieht sie nicht. Ein NIDS schaut genau dort hin: Es erkennt, wenn über einen offenen Webport ein bekannter Exploit läuft, wenn ein Rechner im Netz scannt oder wenn ein interner Server plötzlich nach außen funkt.

2003 war das besonders aktuell. Würmer wie Code Red und Nimda hatten 2001 Tausende Server befallen, im Januar 2003 legte SQL Slammer innerhalb von Minuten Teile des Internets lahm. Wer wissen wollte, ob das eigene Netz betroffen war, brauchte Sicht auf den Verkehr.

Der Mehrwert des Vortrags

Snort zu installieren ist leicht, es sinnvoll zu betreiben nicht. Der Vortrag ging die Phasen Planung, Übersetzen, Regeloptimierung und Speicherung der Alarme durch: Wo sitzt der Sensor, welches Netz gilt als eigenes, welche Präprozessoren und Regeln braucht man wirklich?

In schnellen Netzen kostet jede zusätzliche Regel Rechenzeit. Ist der Sensor überlastet, verwirft er Pakete, und genau dort kann der Angriff stecken. Zu viele Regeln erzeugen außerdem Fehlalarme, die echte Treffer verdecken. Die Testergebnisse im Vortrag stützten deshalb eine schlanke Konfiguration.

Ideen

• Ein NIDS ergänzt die Firewall, indem es den Inhalt erlaubter Verbindungen prüft.
• Regeln beschreiben bekannte Angriffsmuster über Protokoll, Ports und Inhalt.
• Präprozessoren setzen Fragmente und TCP-Datenströme vor der Prüfung zusammen.
• Die Position des Sensors entscheidet, welchen Verkehr er überhaupt sieht.

Einsichten

• Ein überlasteter Sensor verliert Pakete und damit genau die Angriffe, die er finden soll.
• Fehlalarme sind kein Schönheitsfehler: Sie machen echte Treffer unsichtbar.
• Signaturbasierte Erkennung findet Bekanntes zuverlässig, neue Angriffe aber nur mit gepflegten Regeln.

Fakten

• Snort erschien 1998, entwickelt von Martin Roesch, als freie Software unter der GPL.
• Roesch gründete 2001 die Firma Sourcefire, die Snort weiterentwickelte und kommerzielle Produkte darauf aufbaute.
• Snort 2.0 erschien 2003 mit einer überarbeiteten, schnelleren Erkennungsengine.
• Der Vortrag lief am Sonntag im Sicherheitsblock der Chemnitzer Linux-Tage 2003.

Referenzen

• CLT: Netzwerk Intrusion Detection mit Snort in schnellen Netzen

Bemerkungen

• Cisco übernahm Sourcefire 2013; Snort 3 erschien 2021 mit neuer Architektur. Als freie Alternative etablierte sich später Suricata, das Regeln im Snort-Format versteht und mehrere CPU-Kerne nutzt.
• Der Titel dieses Beitrags lautete zuvor frei umschrieben „Angriffe im Netz mit Snort erkennen“; er gibt jetzt den tatsächlichen Vortragstitel wieder.

Empfehlungen

• Platziere einen Sensor dort, wo der zu schützende Verkehr gebündelt vorbeikommt, etwa hinter der Firewall vor den Servern.
• Aktiviere nur Regeln für Dienste, die im Netz tatsächlich laufen, und miss danach Paketverluste und Fehlalarme.
• Pflege Regelsätze regelmäßig; ein NIDS ohne aktuelle Regeln erkennt nur alte Angriffe.

Programmpunkt öffnen →

Im Webarchiv suchen

Links zur Originalquelle und zum Webarchiv öffnen einen neuen Tab.