Probleme Snort als IPS

1. offizieller Beitrag

    Hallo,
    ich betreibe seit einiger Zeit eine Efw in der Version 2.4.1 (Community). Alle Updates sind eingespielt. Bis jetzt habe ich Snort immer nur im IDS Modus mitlaufen lassen.

    Leider hat mir irgendein Spambot in der letzten Woche ca. 200.000 Mails über einen gehackten Useraccoount auf meinen Mailserver eingeliefert. Die Mails sind von meinem Mailserver glücklicherweise aber nicht ausgeliefert worden, da dort noch ein Spamfilter dahinter hängt. Snort hat das Einliefern auch bemerkt und auch brav gelogged.

    Jetzt dachte ich, es wäre eine gute Idee, Snort auch in den IPS Mode zu versetzen, um solche Angriffe in Zukunft zu verhindern.

    Also habe ich bei der entsprechenden Regel (2002087 ET POLICY Inbound Frequent Emails - Possible Spambot Inbound), den Shield aktiviert.

    Leider werden dann aber sofort alle Maileinlieferungen geblockt.

    Ich habe den SMTP Dialog mal von Hand durchgespielt. Sobald das "mail from" kommt, macht Snort zu, schon beim ersten Versuch.

    Ähnliches ist mir bei der Regel 2001219 ET SCAN Potential SSH Scan aufgefallen, auch da blockt Snort schon bei dem ersten SSH Versuch.

    Habt Ihr ne Idee dazu?

    Ich probiere da schon drei Tage rum, finde aber nirgends einen Hinweis dazu.

    Danke

    Gruß Wolfgang

    • Offizieller Beitrag

    Leider ist Snort so eine Sache für sich . . . .
    Bei mir bleiben auch hier und da immer mal wieder " Sachen " im IDS- System hängen . . . besonders bei RDP . . . .

    Das Update der regel Funktioniert auch nicht immer so wie es soll . . .

    EFW Version im Einsatz:
    2 x Endian UTM Enterprise Software Appliance 3.0.5
    1 x Endian Community 3.2.4
    2 x 2.5.1
    8 x 2.2 Final

    Hallo,
    ja irgendwie ist das schon komisch. Solange die Regeln auf Alert stehen, meldet Snort das auch erst nach einer entsprechenden Anzahl von Versuchen, sobald da Drop steht, haut es die Pakete beim ersten Versuch in die Tonne. Das steht dann auch nirgends gelogged.

    BTW Kann ich eigentlich irgendwie an eine Liste der Blocks kommen?

    Gruß Wolfgang

    • Offizieller Beitrag

    Du kannst auch mal neue Rules runterladen und die auf die Endian kopieren . . . .
    Man kann auch versuchen die mit der Hand zu bearbeiten . . . . wenn nichts mehr geht . .

    http://rules.emergingthreats.net/blockrules/

    Da habe ich mich wohl missverständlich ausgedrückt. Ich meinte die Liste der von Endian/Snort im Moment geblockten Dienste.

    Ich habe auch schon versucht, die entsprechende Regel von Hand zu editieren, auch leider ohne Erfolg.

    emerging-policy.rules:alert tcp !$HOME_NET any -> $HOME_NET 25 (msg:"ET POLICY Inbound Frequent Emails - Possible Spambot Inbound"; flow:established; content:"mail from|3a|"; nocase; threshold: type threshold, track by_src, count 10, seconds 60; reference:url,http://doc.emergingthreats.net/2002087; classtype:misc-activity; sid:2002087; rev:10;)

    Diese Rule lese ich ja so, das von einer IP 10 Versuche in 60 Sekunden zu machen sind. Bei reinem Loggen klappt das ja auch, nur beim Drop halt nicht.

    komisch.

    Gruß Wolfgang

    • Offizieller Beitrag

    Das lese ich auch so, wenn er gleich blockt würde ich mal versuchen die Versuche noch oben zustellen, also 30 Versuche pro 60 second . . . . vielleicht kann man sich da ja ran tasten.

    Gruß Sabine

    Ich habe gerade einen ersten Erfolg gehabt. Quick and dirty habe ich auf der Konsole mal die entsprechende Regel in processed.rules geändert und den snort neu gestartet.

    Die Regel lautet jetzt.
    drop tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"ET SCAN Potential SSH Scan"; flags:S,12; detection_filter: track by_src, count 5, seconds 120; reference:url,http://en.wikipedia.org/wiki/Brute_force_attack; reference:url,http://doc.emergingthreats.net/2001219; classtype:attempted-recon; sid:2001219; rev:18;)

    und siehe da, es geht. Man kann sich normal konnekten, aber bei 5 schnellen Versuchen ist Feierabend.

    Anscheinend wird die threshold Geschichte in den Rules nicht mehr richtig ausgewertet. Der Parameter wurde ja durch detection_filter ersetzt.

    Jetzt muss ich das "nur" noch schön machen und die Regel unter den Custom Regeln einpflegen.

    Ich bleibe dran.

    Gruß Wolfgang

    Ich nutze den Zugang selbst von dynamischen IPs aus, von daher kann nicht übe die IPs blocken.

    Ich habe das jetzt nochmal genauer untersucht und es sind wirklich die Threshold Parameter in den Regeln. Wenn man diese entsprechend ersetzt, dann funktioniert es so, wie es soll.

    Gruß Wolfgang