Probleme Snort als IPS

  • 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

  • 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

  • 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,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

  • 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

    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

  • 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,en.wikipedia.org/wiki/Brute_force_attack; reference:url,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

  • Wenn das ganze immer von der gleichen IP kommt und du die nicht brachst . . . . dann kannst du die auch mit der Firewall blocken . . .


    Aber so ist das natürlich eleganter . .

    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

  • 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