[UPDATE] IDS funktioniert nicht

[aquaman]

Nachdem ich die Logs gelöscht habe und die Regeln aktualisiert kamen keine neuen Logs mehr, waren wohl welche vor dem Update. Bin auf der neuesten Version (17.7.3).

[Stephan]

Um sicherzustellen, dass das IDS richtig funktioniert habe ich folgende Anfrage an einen Web-Server (Port 80 HTTP) geschickt: http://[external]/index.php?username=-1 union select 1,2,table_name FROM information_schema.tables-- -

Nun habe ich gehofft, dass die Regel sid=2017808 (ET WEB_SERVER Possible MySQL SQLi Attempt...) anschlägt. Die Regel ist aktiviert.

Hi, ich finde gerade die Regel nicht, welche Du genannt hast...
Könntest Du die mal rauskopieren oder die Datei + Zeilennummer nennen?

Schönen Gruß,

Stephan

[NilsS]

du brauchst doch nur unter rules danach zu suchen.
Details: http://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET WEB_SERVER Possible MySQL SQLi Attempt Information Schema Access"; flow:to_server,established; content:"information_schema"; nocase; http_uri; reference:url,pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet; classtype:web-application-attack; sid:2017808; rev:2; metadata:created_at 2013_12_06, updated_at 2013_12_06;)

https://rules.emergingthreats.net/open/suricata/rules/emerging-web_server.rules

[Stephan]

du brauchst doch nur unter rules danach zu suchen.
Details: http://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET WEB_SERVER Possible MySQL SQLi Attempt Information Schema Access"; flow:to_server,established; content:"information_schema"; nocase; http_uri; reference:url,pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet; classtype:web-application-attack; sid:2017808; rev:2; metadata:created_at 2013_12_06, updated_at 2013_12_06;)

https://rules.emergingthreats.net/open/suricata/rules/emerging-web_server.rules

Danke, genau das mein ich - unter https://rules.emergingthreats.net/open/suricata/rules/emerging-web_server.rules kann ich das nicht finden...hast Du das selber gebastelt?^^

[NilsS]

oO Nein, ist genau daher.

Zeile 943/1214

[Stephan]

Ok - sry - im Browser wurde es nicht angezeigt  ???

Allerdings werde ich aus dem nicht so ganz schlau, weil der content nun nicht wirklich aussagekräftig ist...

Code Select Expand

content:"information_schema";

[NilsS]

yep, das hatte ich auch gesehen. hatte gedacht ob es da wohl irgendwo ein Schema gibt oder ob die Regel mit Würfeln ausgewertet wird.

Dachte da müsste auch mehr Content rein. Müsste ich mich auch erst mal einlesen

[Stephan]

Ok, wollte es mal testen - aber das is mir grad zu aufwändig^^ - sorry
eine Bedingung ist ja

Code Select Expand

$EXTERNAL_NET any -> $HOME_NET any oder
$EXTERNAL_NET any -> $HTTP_SERVERS any
und außerdem

Code Select Expand

flow:to_server,established;


also eine Bestehende Verbindung und der Befehl kommt dann von außen...

[aquaman]

Lokal einfach einen HTTP Server starten. Dann die URL (von extern) eingeben und sich die 404 ansehen sollte reichen.
Die Verbindung ist ja sowieso "aufgebaut", da HTTP auf TCP aufbaut.

Aber generell ... ich bekomme nicht mal false-positives in der Alarmliste.

[aquaman]

Der EICAR Testvirus wird ebenfalls nicht immer erkannt. Von 20 Versuchen hat es jetzt 1 mal geklappt, dass eine Meldung in der Alarmliste auftaucht. Nach einer gewissen Laufzeit des IDS erkennt er das EICAR-File häufiger oder sogar immer. Eine andere Regel, welche ich aktiviert habe (http://doc.emergingthreats.net/2000419) wird überhaupt nicht erkannt. Zum Test für diese Regel hatte ich eine exe-Datei von 7zip heruntergeladen.

Hat sonst noch jemand irgendwelche Ratschläge, um dem Fehler auf den Grund zu gehen?

PS: Ein kleiner Bug: Wenn man auf der IDS-Seite auf einen anderen Reiter (außer Einstellungen und Zeitplan) wechselt und dann anschließend zu Zeitplan und diesen dann schließt, ist der Reiter für Zeitplan verschwunden. Scheinbar wird die "Berechtigung" nur auf der Hauptseite der IDS-Konfiguration neu ausgewertet.

[Stephan]

Was mir grad noch spontan einfällt: lädst Du die Testdateien über https und wenn ja, hast Du das im Squid aktiviert?
Also irgendwas muss ja bei der Konfiguration verquer sein, weil mit dem Eicar Test hatten wir noch nie Probleme - nur eben nicht mit https, weil wir das (noch?) nicht mit squid abfangen.

Gruß,

Stephan

[aquaman]

Scheinbar braucht man einfach geduld, bis das IDS funktioniert.
Sobald ich eine Änderung an den Einstellungen vornehme dauert es eine bestimmte Zeit (10-30 Minuten), bis das IDS wieder funktioniert.

Beispiel:
Das IDS läuft und erkennt alle EICAR-Testdateien (HTTP). Jetzt hakt man IPS an und klickt "Anwenden". Das IDS erkennt die EICAR-Testdateien nicht mehr (kein Eintrag in der Alarmliste mehr) und lässt sie zu. Der Ladebalken bei "Anwenden" ist aber bereits durchgelaufen. Jetzt warte ich 10-30 Minuten und dann werden die Dateien erst geblockt. Soll das so sein?

ET POLICY PE EXE or DLL Windows file download wird auch nicht erkannt.

So langsam habe ich das Gefühl, das IDS hat ne Macke  :)

[aquaman]

Das IDS startet mittlerweile überhaupt nicht mehr (rotes Play-Icon).
Weiß jemand, wie ich das Problem lösen kann?

[franco]

# rm /var/run/suricata.pid

Und dann sollte es wieder starten. Dafür gibt es einen FreeBSD Bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223052


Grüsse
Franco