Beiträge von heaschmann

    Hier ist meine sshd.conf:



    ich habe auch schon einen regex test durchgeführt. Dieser hat ca. 12000 Hits ergeben und es hat alles soweit gepasst, was darauf schließen lässt, dass auch die conf Datei für sshd funktioniert.


    Der regex mit :

    Code
    ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$


    sollte ja auch bei meinen Beispielen zutreffen.


    ich habe auch schon das Loglevel auf 4 gestellt und einen Debug durchgeführt:


    Code
    tail -n500 /var/log/fail2ban.log


    ich nutze mittlerweile das ActionScript von n/x ...dieses habe ich ebenfalls ausprobiert und es setzt mit im vcp die richtigen Einträge in die Firewall.
    Das habe ich mit beispielhaften IPs durchprobiert.


    Das Problem muss also irgendwo anderes liegen. Mit fällt es im Moment allerdings schwer herauszufinden, wo das Problem liegen kann.


    1)Fail2Ban läuft
    2)die regex sind korrekt
    3)das Action Script läuft korrekt
    4)ssh jail startet korrekt
    5)auth.log wurde als log Datei für die Überprüfung korrekt von Fail2Ban eingebunden


    viele Grüße

    Hier ein kleiner Auszug aus meiner auth.log


    Code
    Apr 13 13:17:50 v2201204121697882 sshd[21312]: Invalid user oyakata from 72.252.2.236Apr 13 13:17:51 v2201204121697882 sshd[28904]: Invalid user operardor from 72.252.2.236Apr 13 13:17:52 v2201204121697882 sshd[4510]: Invalid user akaibashi from 72.252.2.236Apr 13 13:17:54 v2201204121697882 sshd[12153]: Invalid user crickn from 72.252.2.236Apr 13 13:17:55 v2201204121697882 sshd[20109]: Invalid user kumada from 72.252.2.236Apr 13 13:17:56 v2201204121697882 sshd[27994]: Invalid user drillbits from 72.252.2.236Apr 13 13:17:58 v2201204121697882 sshd[3654]: Invalid user usefeel from 72.252.2.236Apr 13 13:17:59 v2201204121697882 sshd[11384]: Invalid user pgsql from 72.252.2.236Apr 13 13:18:00 v2201204121697882 sshd[19412]: Invalid user crawler from 72.252.2.236Apr 13 13:18:02 v2201204121697882 sshd[27518]: Invalid user cactusman from 72.252.2.236Apr 13 13:18:03 v2201204121697882 sshd[1797]: Invalid user sato from 72.252.2.236Apr 13 13:18:04 v2201204121697882 sshd[9030]: Invalid user suzuki from 72.252.2.236Apr 13 13:18:05 v2201204121697882 sshd[17191]: Invalid user takahashi from 72.252.2.236Apr 13 13:18:07 v2201204121697882 sshd[25160]: Invalid user tanaka from 72.252.2.236Apr 13 13:18:08 v2201204121697882 sshd[569]: Invalid user watanabe from 72.252.2.236Apr 13 13:18:09 v2201204121697882 sshd[8766]: Invalid user ito from 72.252.2.236Apr 13 13:18:11 v2201204121697882 sshd[16765]: Invalid user yamamoto from 72.252.2.236Apr 13 13:18:12 v2201204121697882 sshd[24247]: Invalid user nakamura from 72.252.2.236Apr 13 13:18:13 v2201204121697882 sshd[31306]: Invalid user ohayashi from 72.252.2.236Apr 13 13:18:14 v2201204121697882 sshd[6260]: Invalid user kobayashi from 72.252.2.236Apr 13 13:18:16 v2201204121697882 sshd[13257]: Invalid user kato from 72.252.2.236Apr 13 13:18:17 v2201204121697882 sshd[20427]: Invalid user kichida from 72.252.2.236Apr 13 13:18:18 v2201204121697882 sshd[27984]: Invalid user yamada from 72.252.2.236Apr 13 13:18:20 v2201204121697882 sshd[3557]: Invalid user sasaki from 72.252.2.236Apr 13 13:18:21 v2201204121697882 sshd[10894]: Invalid user yamaguchi from 72.252.2.236Apr 13 13:18:22 v2201204121697882 sshd[18642]: Invalid user tetsuo from 72.252.2.236Apr 13 13:18:24 v2201204121697882 sshd[26004]: Invalid user ssl from 72.252.2.236Apr 13 13:18:25 v2201204121697882 sshd[1495]: Invalid user sugiyama from 72.252.2.236Apr 13 13:18:26 v2201204121697882 sshd[9157]: Invalid user hagat from 72.252.2.236Apr 13 13:18:27 v2201204121697882 sshd[17335]: Invalid user matsumoto from 72.252.2.236


    Die Bruteforce Angriffe haben ja alle die selbe Form.
    Nachfolgend ein Ausschnitt meiner sshd.conf von Fail2Ban:


    Code
    failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from <HOST>\s*$				^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$			 	^%(__prefix_line)sFailed (?:password|publickey) for .* from <HOST>(?: port \d*)?(?: ssh\d*)?$ 				^%(__prefix_line)sROOT LOGIN REFUSED.* FROM <HOST>\s*$ ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$ 				^%(__prefix_line)sUser .+ from <HOST> not allowed because not listed in AllowUsers$ 				^%(__prefix_line)sauthentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=<HOST>(?:\s+user=.*)?\s*$ 				^%(__prefix_line)srefused connect from \S+ \(<HOST>\)\s*$ 				^%(__prefix_line)sAddress <HOST> .* POSSIBLE BREAK-IN ATTEMPT!*\s*$ 				^%(__prefix_line)sUser .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$


    (Laut diesen failregex Statements sollten die Logs passen)



    wenn Fail2Ban nur in die Log Dateien reinschaut und diese nach wiederholt auftretenden Signaturen überprüft (was ja genau dem DETECTION MODULE eines IPS entspricht), dann sollte es ja zumindest erkennen, dass es sich hierbei um einen Angriff handelt - egal ob man nun bis zum Loginprompt kommt oder nicht - da ja den Angriff in der auth.log verzeichnet wird.


    Gehe ich gerade falsch in der Annahme, dass Fail2Ban wirklich nur die Log Dateien überprüft?


    Grüße

    Komischerweise funktioniert genau dieses Szenario auf anderen Servern sehr gut.


    Dort wurde ebenfalls der UserLogin komplett deaktiviert und lediglich die PublickeyAuthentication aktiviert/zugelassen.


    Und Fail2Ban logt trotzdem die "Versuche" und bannt diese IP auch. Kann man dann ggf. in der Fail2Ban config irgendwas drehen, dass besagte IP Adressen gebannt werden. Meine auth.log füllt sich immer weiter und bläht sich auf bis in´s Unermessliche.
    Dies galt es meinerseits zu vermeiden, was ja bis zur Umstellung auf Keys sehr gut geklappt hat.


    vll. hat ja jemand schon das selbe Problem gehabt und eine passende Lösung parat.


    Vielen Dank schon mal im Voraus

    PW Anmeldung komplett deaktiviert. Login nur noch mit Key.


    Vorher war aber nur Userlogin aktiv und root Login deaktiviert. Somit lässt der SSHd ja auch keine root Logins durch --> Diese wurden trotzdem in der auth.log mitgeloggt und entsprechend in der fail2ban.log gebannt.


    Deine Logik macht schon sinn, dieser Logik bin ich zuerst auch nachgegangen. Ich dachte aber auch, dass das Action Script für den TCP-Wrapper nur in die auth.log reinschaut und seine Entscheidungen für einen Ban oder keinen Ban basieren auf diesen Logging-Einträgen trifft.


    Wenn n Brute Force Angriff mit root gestartet wurde, wurde dieser ja ja auch mitgeloggt (obwohl root Login deaktiviert war) und die IP von Fail2Ban gebannt.


    Sollte nun nicht also trotzdem schon alleine der Versuch eines unerlaubten Logins gebannt werden (oder ist meine Logik jetzt quatsch;))

    Hallo zusammen,


    Ich nutze schon eine Weile Fail2Ban mit SSH-TCPWrapper, nicht mit IPTabels. Funktionierte auch immer ganz gut.
    Fail2Ban hat mir die IP Adressen von allen Bruteforce Attacken gebannt.


    Seit ein paar Tagen habe ich dann vom User Login mit SSH auf Public Key Verfahren umgeschwenkt. Schien für mich komfortabler.


    Leider bannt Fail2Ban nun keine einzige IP mehr.


    Hat hier jemand schon einmal das selbe Problem gehabt, oder Erfahrungen mit einem derartigen Bug?


    Viele Grüße