OPNsense Forum
International Forums => German - Deutsch => Topic started by: aquaman on August 25, 2017, 02:47:38 pm
-
Hallo zusammen,
ich habe versucht das IDS zu triggern. Ein paar andere Meldungen stehen bereits in der Alarmliste.
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.
Das IDS lauscht auf LAN und WAN, aber in der Alarmliste kommt nichts an. IPS ist nicht aktiviert.
Sagt mir bitte bescheid, welche Infos/Logs ihr benoetigt.
Vielen Dank im Voraus,
Grueße aquaman
-
Hallöchen,
Welches Netz hat das WAN bzw. der Web-Server, welches LAN? Falls beides private Ranges sind könnte es sein, dass das IDS gar nicht weiß dass es ins/aus dem WAN funkt.
Grüsse
Franco
-
Hallo Franco,
es handelt sich tatsächlich um ein privates B und ein privates C Netzwerk.
Ein paar ungewollte IDS-Einträge sind auch aufgetaucht, allerdings nicht der erwartete Eintrag.
Danke & Grüße,
aquaman
-
Ja, etwas Lärm hat es immer.
Die Regel ist:
http://doc.emergingthreats.net/bin/view/Main/2017808
Also...
alert http $EXTERNAL_NET any -> $HOME_NET
Wir setzen...
HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]"
EXTERNAL_NET: "!$HOME_NET"
Vom WAN zu DMZ geht es... aber eben nur alles was nicht HOME_NET ist.
Grüsse
Franco
-
Hi,
gibt es in der GUI eine Konfigurationsmöglichkeit für $HOME_NET?
Nicht, dass ein Upgrade die Konfiguration zerlegt.
Danke & Grüße,
aquaman
-
Aktuell kann man nur händisch die /usr/local/opnsense/service/templates/OPNsense/IDS/suricata.yaml editieren. Dann kann man weiter über die GUI konfigurieren, aber bei jedem 17.7.x Update verschwindet dies.
Einen Feature-Request können wir gern diskutieren über:
https://github.com/opnsense/core/issues
Grüsse
Franco
-
Hi,
habe einen Feature-Request eröffnet: https://github.com/opnsense/core/issues/1793 (https://github.com/opnsense/core/issues/1793)
Danke & Grüße,
aquaman
-
Super, danke, ich markiere als [GELÖST] was die Frage betrifft.
Grüsse
Franco
-
Hallo zusammen,
das Feature ist jetzt im neuen Release.
Das IDS erkennt den oben gennanten Angriff immernoch nicht.
Konfiguration:
IDS Home-Networks: 192.168.0.0/16
IDS Interface: LAN (ist ein 192.168.0.0/24)
Das externe Netzwerk ist ein 172.16.0.0/24
Zugriff auf ein System in 172.16.0.0/24 mit HTTP (kein HTTPS!):
http://172.16.0.1/foo.php?id=-1%20union%20select%201,table_name,3%20from%20information_schema.tables--%20-
PS: Sobald ich WAN und LAN als IDS Interface angebe, lädt der "Anwenden"-Button ewig/unendlich lange.
Danke+Grüße,
aquaman
-
Ich habe auch das Gefühl das bei meiner Installation über die ausgehenden AIRVPN Verbindungen nichts gemeldet wird. Dort werden auch private IPs genutzt. Keine Ahnung ob es daran liegt. Ich bekomme lediglich vereinzelt STREAM invalid * auf dem WAN Interface, jegliche Rules auf dem VPN Interfaces geben keine Alerts.
HOMENET ist ebenfalls nur auf das 192er gesetzt.
-
/usr/local/etc/suricata/suricata.yaml sollte passen: HOME_NET: "[192.168.0.0/16]"
Suricata wird auch mit dem richtigen Interface und Config gestartet:
/usr/local/bin/suricata -D --pcap=xxx0 --pidfile /var/run/suricata.pid -c /usr/local/etc/suricata/suricata.yaml
In den Logs von Suricata (auch ganz interessant):
26/9/2017 -- 03:13:37 - <Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "¾Ÿ Ïê.Ù««îZeb·“r$]" from file /usr/local/etc/suricata/opnsense.rules/abuse.ch.sslblacklist.rules at line 91
Mehrmals die Fehlermeldungen "error parsing signature" aber alle von "abuse.ch.sslblacklist.rules".
Habe das IDS-Interface kurz auf WAN gestellt, dann bekomme ich nur jede Menge "SURICATA zero length padN option" Alerts. Habe den HTTP-Request von außen an Port 80 geschickt (Port-Weiterleitung an WAN-Adresse:80 -> LAN-Adresse:80), die SQL-Attacke bleibt auch dort verborgen.
-
ist das vielleicht das Problem, gerade wo du speziell abuse.ch nennst.
https://forum.opnsense.org/index.php?topic=5932.msg24683
-
Ich hoffe doch nicht, dass ein einzelner Signatur-Provider das IDS lahmlegen kann. :o Die Signatur die ich prüfen möchte ist von Emerging Threats.
-
ist das vielleicht das Problem, gerade wo du speziell abuse.ch nennst.
https://forum.opnsense.org/index.php?topic=5932.msg24683
also, wie im genannten Post gesagt, wurde das bereits gefixed!
--> hast Du die letzten Updates installiert?
Grüße, Stephan
-
Ich hoffe doch nicht, dass ein einzelner Signatur-Provider das IDS lahmlegen kann. :o Die Signatur die ich prüfen möchte ist von Emerging Threats.
also, die 'unleserlichen' (weil komprimierten) Dateien von abuse.ch haben nicht alles lahmgelegt, aber es konnten halt keine Abfragen bezüglich dieser Regeln gemacht werden...
-
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).
-
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
-
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
-
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 (https://rules.emergingthreats.net/open/suricata/rules/emerging-web_server.rules) kann ich das nicht finden...hast Du das selber gebastelt?^^
-
oO Nein, ist genau daher.
Zeile 943/1214
-
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...
content:"information_schema";
-
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
-
Ok, wollte es mal testen - aber das is mir grad zu aufwändig^^ - sorry
eine Bedingung ist ja $EXTERNAL_NET any -> $HOME_NET any oder
$EXTERNAL_NET any -> $HTTP_SERVERS anyund außerdem
flow:to_server,established;
also eine Bestehende Verbindung und der Befehl kommt dann von außen...
-
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.
-
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.
-
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
-
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 :)
-
Das IDS startet mittlerweile überhaupt nicht mehr (rotes Play-Icon).
Weiß jemand, wie ich das Problem lösen kann?
-
# 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