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
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
Hier ist meine sshd.conf:
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision: 728 $
#
[INCLUDES]
# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf
[Definition]
_daemon = sshd
# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
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*$
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
Alles anzeigen
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 :
sollte ja auch bei meinen Beispielen zutreffen.
ich habe auch schon das Loglevel auf 4 gestellt und einen Debug durchgeführt:
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
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:
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