Fail2Ban und SSH PubKey Authentication

    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

    Hast du die Passwortanmeldung noch aktiviert? Oder nur die Anmeldung per Key? Weil wenn zweiteres der Fall ist, dann lässt der SSHd ja keinen mehr durch, der nicht sagt, er hätte einen Key. Ergo braucht f2b ja auch nichts bannen, oder ist meine Logik falsch?

    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;))

    Zitat von heaschmann

    Vorher war aber nur Userlogin aktiv und root Login deaktiviert. Somit lässt der SSHd ja auch keine root Logins durch


    Bei der Methode kommst du aber bis zur Loginshell vor, und hast die Möglichkeit, sachen falsch einzutippen. Mit dem Keyverfahren kommst du ja ohne Schlüssel nichtmal zum Loginprompt, weil ja alles schon vorher abgewiesen wird.


    Zitat

    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.


    Siehe oben. Früher kam man soweit, zu sagen: "Ich habe ein Passwort und will mit als root anmelden.", SSHd: "Darfst du zwar nicht, aber du kannst es gerne probieren, ich zähl' sogar mit, wie oft du das versuchst.". Mit Key sagt man ja: "Ich habe ein Pass..", SSHd: "Nö.".


    Bei mir loggt er auch nichtmal mit, wer das gerade beschriebene Versucht, aber das ist sicher eine Einstellungs-Sache. Wenn das wieder aufzeichnet wird, kann man da bestimmt auch f2b drauf ansetzen.

    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

    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

    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

    Server neu gestartet und es läuft :)...


    Naja darauf hätte ich auch selbst kommen könne...aber warum sollte man auch darauf kommen dass man n ganzen Server neu starten muss?!


    Vielen Dank trotzdem für eure Hilfe

    http-authentifizierung-von-nginx-mit-fail2ban-verknupfen Nicht nur an den SSH Port denken, auch an Froxlor, myphpadmin , etc via http auf dem WebServer :)


    fail2ban einfach nachinstallieren und dann wie http://www.root-on-fire.com/20…r-mit-fail2ban-absichern/ in "alles" mit nano jail.conf auf true setzen .. Hinweis: der MTA zum Versenden der Email nach Attacken ist sendmail. Es gibt auch ein Postfix sendmail, welches schon bei euch sowieso laufen sollte. Man muss nicht dpkg -s sendmail nachinstallieren ABER: /etc/init.d/fail2ban restart nicht vergessen!! Teste mit fail2ban-client status -> sieht mal wieviele Filter auf true nun sind..

    vServer Light NETCup Kunde mit Debian Squeeze 64Bit :)
    (Drupal CMS Fan.)

    3 Mal editiert, zuletzt von MegaBite ()