fail2ban verbietet ssh bruteforce nicht aber regex funktioniert

Question

Ich habe gerade einen ssh bruteforce auf meinem Server bemerkt, der eigentlich von fail2ban hätte verbannt werden sollen, aber aus irgendeinem Grund verbietet er es nicht. Die meisten Leute, die Probleme mit fail2ban haben, scheinen Probleme mit ihrer Regex zu haben, was hier gut zu sein scheint.

Teil jail.conf

[ssh] 
enabled = true 
port  = ssh 
filter = sshd 
logpath = /var/log/auth.log 
maxretry = 6 
findtime = 6000 
bantime = 86400 

fail2ban-Client-Status SSH

Status for the jail: ssh 
|- filter 
| |- File list: /var/log/auth.log 
| |- Currently failed: 0 
| `- Total failed: 0 
`- action 
    |- Currently banned: 0 
    | `- IP list: 
    `- Total banned: 0 

fail2ban-regex /var/log/auth.log/etc/fail2ban/Filter .d/sshd.conf

Running tests 
============= 

Use regex file : /etc/fail2ban/filter.d/sshd.conf 
Use log file : /var/log/auth.log 


Results 
======= 

Failregex 
|- Regular expressions: 
| [1] ^\s*(?:\S+)?(?:kernel: \[\d+\.\d+\])?(?:@vserver_\S+)?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S 
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*(?:error: PAM:)?Authentication failure for .* from <HOST>\s*$ 
| [2] ^\s*(?:\S+)?(?:kernel: \[\d+\.\d+\])?(?:@vserver_\S+)?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S 
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*(?:error: PAM:)?User not known to the underlying authentication module for .* from <HOST>\s*$ 
| [3] ^\s*(?:\S+)?(?:kernel: \[\d+\.\d+\])?(?:@vserver_\S+)?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S 
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*Failed (?:password|publickey) for .* from <HOST>(?: port \d*)?(?: ssh\d*)?$ 
| [4] ^\s*(?:\S+)?(?:kernel: \[\d+\.\d+\])?(?:@vserver_\S+)?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S 
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*ROOT LOGIN REFUSED.* FROM <HOST>\s*$ 
| [5] ^\s*(?:\S+)?(?:kernel: \[\d+\.\d+\])?(?:@vserver_\S+)?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S 
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*[iI](?:llegal|nvalid) user .* from <HOST>\s*$ 
| [6] ^\s*(?:\S+)?(?:kernel: \[\d+\.\d+\])?(?:@vserver_\S+)?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S 
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*User .+ from <HOST> not allowed because not listed in AllowUsers$ 
| [7] ^\s*(?:\S+)?(?:kernel: \[\d+\.\d+\])?(?:@vserver_\S+)?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S 
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*authentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=<HOST>(?:\s+user=.*)?\s*$ 
| [8] ^\s*(?:\S+)?(?:kernel: \[\d+\.\d+\])?(?:@vserver_\S+)?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S 
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*refused connect from \S+ \(<HOST>\)\s*$ 
| [9] ^\s*(?:\S+)?(?:kernel: \[\d+\.\d+\])?(?:@vserver_\S+)?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S 
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*Address <HOST> .* POSSIBLE BREAK-IN ATTEMPT!*\s*$ 
| [10] ^\s*(?:\S+)?(?:kernel: \[\d+\.\d+\])?(?:@vserver_\S+)?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\ 
S+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*User .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$ 
| 
`- Number of matches: 
    [1] 0 match(es) 
    [2] 0 match(es) 
    [3] 380 match(es) 
    [4] 0 match(es) 
    [5] 353 match(es) 
    [6] 26 match(es) 
    [7] 0 match(es) 
    [8] 0 match(es) 
    [9] 0 match(es) 
    [10] 0 match(es) 

Ignoreregex 
|- Regular expressions: 
| 
`- Number of matches: 

Summary 
======= 

Addresses found: 
[1] 
[2] 
[3] 
    198.245.50.151 (Sat Dec 21 15:18:12 2013) 
    198.245.50.151 (Sat Dec 21 15:18:15 2013) 
    198.245.50.151 (Sat Dec 21 15:18:18 2013) 
    198.245.50.151 (Sat Dec 21 15:18:21 2013) 
    198.245.50.151 (Sat Dec 21 15:18:24 2013) 
.................. 
Date template hits: 
23379 hit(s): MONTH Day Hour:Minute:Second 
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year 
.................. 

Success, the total number of match is 759 

Irgendwelche Ideen, warum fail2ban nicht verbietet, auch wenn ich viele Regex-Matches habe?

Grüße, Fisch

Answer 1

oft, wenn ich diese Probleme habe (auf Debian-Boxen), es ist etwas zu tzdata und falsche Zeit bezogen. Wenn die Regexp funktioniert (und es funktioniert), sind die einzigen Dinge, die Fai2Ban verhindern können, etwas mit Datum/Zeit verschraubt. Versuchen Sie, ntp zu installieren und synchronisieren Sie Ihr Datum.

Answer 2

Ich hatte ein ähnliches Verhalten auf einer Ubuntu raring (13.04) Box. Fail2ban konnte Änderungen in der /var/log/auth.log Datei nicht bemerken. Ändern der backend Wert in der jail.conf Datei hat nichts geändert.

Ich habe dies endlich behoben, indem ich die neuste Version von Fail2ban installiert habe. Die Backport Builds sind von NeuroDebian erhältlich, wie auf der Fail2ban Website unter download page beschrieben.

Answer 3

Fail2ban nicht verbieten und regexp viel? Es ist wahrscheinlich, dass dein Gefängnis eine Verbotsaktion vermisst. Sie haben zwei Möglichkeiten:

Option 1) In Ihrem Gefängnis [ssh] umfassen

[ssh] 
enabled = true 
port  = ssh 
filter = sshd 
logpath = /var/log/auth.log 
action = %(action_mwl)s # <<== THIS IS FOR BANNING 
maxretry = 6 
findtime = 6000 
bantime = 86400 

Option 2) Fügen Sie eine globale Aktion für alle Gefängnisse nur das Schreiben dieses (Beispiel)

# Choose default action. To change, just override value of 'action' with the 
# interpolation to the chosen action shortcut (e.g. action_mw, action_mwl, etc) in jail.local 
# globally (section [DEFAULT]) or per specific section 
action = %(action_mwl)s 

[ssh] 
    enabled = true 
    port  = ssh 
    filter = sshd 
    logpath = /var/log/auth.log 
    maxretry = 6 
    findtime = 6000 
    bantime = 86400 

BTW, an der Spitze der jail.conf Ich kann eine Empfehlung für die Verwendung von jail.local anstelle von jail.conf lesen. sein kann es hilfreich sein könnte, um ihre Anweisungen zu befolgen:

To avoid merges during upgrades DO NOT MODIFY THIS FILE 
# and rather provide your changes in /etc/fail2ban/jail.local 

Answer 4

Ok, das ist keine offizielle Lösung, aber es funktioniert:

3 Monate gearbeitet perfekt bis fail2ban aktualisiert und gestoppt zu verbieten. Ich kann sagen, wie sehr ich untersucht habe, um dieses Problem zu lösen, und am Ende ist dies der einzige Weg, der funktioniert.

sollten Diese

arbeiten

sudo service fail2ban stop 
sudo service fail2ban start 

Diese nicht

sudo service fail2ban restart 

WICHTIG arbeiten: Test mit einem anderen Gerät (3G-Zelle) eine absichtliche ssh Protokollierung konnte nicht überprüft fail2ban funktioniert. Ist dies nicht der Fall, stoppen Sie den Service erneut. Manchmal werden einige Gefängnisse nicht korrekt geladen. Vertraue niemals!!!!!

EXTRA HINWEISE:

• Mit jail.local
• 4 Jails aktiviert: ssh, Dovecot, Apache und wootwoot
• Alle Gefängnisse als Charme arbeiten seit Monaten ohne Problem
• Ubuntu-Server 14.04
• fail2ban 0,9

Answer 5

Manchmal wird diese i s weil die __bsd_syslog_verbose falsch ist. fail2ban erwartet mit YYYY.MM.DD (dh: 2014.10.15) /var/log/auth.log starten noch die Protokolle lesen MMM DD (dh: 15. Oktober)

Um dies zu beheben müssen Sie Folgendes tun:

cp /etc/fail2ban/filter.d/common.conf /etc/fail2ban/filter.d/common.local 

bearbeiten common.local und setzen:

__bsd_syslog_verbose = (<[^.]+ [^.]+>) 

Restart fail2ban:

Ubuntu (nicht neu starten, verwenden):

sudo service fail2ban stop 
sudo service fail2ban start 

Answer 6

Ich habe versucht, alle Lösungen hier, bevor ich es wieder gegoogelt und fand die Antwort auf ServerFault:

Lauf service rsyslog restart alle war ich tun musste, und jetzt funktioniert es wie erwartet (natürlich gibt es die Möglichkeit, dass alle Lösungen hier waren auch notwendig ...). Im Gegensatz zum Poster dieser Frage habe ich die Protokolldatei nie gelöscht oder bearbeitet, also warum ist das die Lösung, die ich nicht kenne.

Answer 7

Ich habe gerade gefunden, dass es notwendig ist, meinen Server neu zu starten, bevor Änderungen am sshd-Port in Kraft traten ... das Ändern von Ports ist ziemlich effektiv und einfach.

Answer 8

Diese Frage ist ziemlich alt, aber ich stieß auf das gleiche Problem, und nach vielen vielen Suchen, endlich die Lösung gefunden.

Mein Problem war aufgrund einer Änderung an meiner Zeitzone: Vor einiger Zeit habe ich den folgenden Befehl verwendet, um meine korrekte Zeitzone einzustellen.

Meine Systemzeit war ok, aber die Zeiten der Einträge in auth.log wurden tatsächlich verschoben. Und das war das Problem für fail2ban: Es muss Einträge von auth.log vergleichen, um zu prüfen, ob es verbieten, behalten oder unban sein muss ... und geloggte Einträge wurden wegen falscher Zeit immer als zu alt angesehen.

Ich hatte gerade mit Syslog-Daemon neu zu starten:

sudo service rsyslog restart 

Dann Zeiten waren in auth.log nicht mehr verschoben und fail2ban erfolgreich seine Arbeit getan hat.

Ich hoffe, das wird helfen!