4

Environment: *CentOS 6.5 *Fail2Ban 0.8.14-1 *date outputs the correct date

Behavior: Fail2ban starts successfully, but does not create iptables blocks after bad SSH login attempts. I'm only concerned with SSH at this point. I attempted to reinstall using this guide: https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-centos-6

Fail2Ban used to work - but through system updates, it appears to have stopped working. If I run

sudo service fail2ban restart

I get an email saying that the jail has stopped and another email saying the jail has started, so it seems that fail2ban is running and functional.

My /etc/fail2ban/jail.local file includes the entry:

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
       sendmail-whois[name=SSH, [email protected], [email protected], sendername="Fail2Ban"]
logpath  = /var/log/secure
maxretry = 5

My IP address is not listed in the ignoreip delcaration. I'm using standard bantime of 600, findtime of 600, and maxretry of 3.

When I look at /var/log/secure, I see plenty of failed attempts:

Sep 30 00:17:02 nebo unix_chkpwd[3796]: password check failed for user (root)
Sep 30 00:17:02 nebo sshd[3794]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.173.26.189  user=root

iptables -L seems to report that fail2ban does have a chain:

Chain fail2ban-SSH (2 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

My current best guest is that the action for sshd in actions.d/sshd.conf is using a regular expression to look through the log file, but it doesn't match the current syntax of the CentOS log for a banned attempt.

Time is insync per: Why isn't fail2ban blocking failures?

Ran fail2ban-regex to test my theory, and it looks like I may be on the right track:

[isdept@nebo action.d]$ sudo fail2ban-regex /var/log/secure /etc/fail2ban/filter.d/sshd.conf 

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

Use   failregex file : /etc/fail2ban/filter.d/sshd.conf
Use         log file : /var/log/secure


Results
=======

Failregex: 0 total

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [22655] MONTH Day Hour:Minute:Second
`-

Lines: 22655 lines, 0 ignored, 0 matched, 22655 missed
Missed line(s): too many to print.  Use --print-all-missed to print all 22655 lines

I'm not totally sure how to modify the regex patterns to fix this (if this is the issue), but I am surprised to find that I haven't found an easy fix since CentOS is common. I'd be happy to provide any additional info. Thanks for any tips or pointers you can give!

For safety - I'm currently disabling public access to this host.

5
  • Well, then your regex (in filter.d/sshd.conf) does not match. Compare it with examples from the docs at the internet, and try to fix it yourself. If this does not work out for you, you can ask it at this site.
    – sebix
    Oct 5, 2014 at 8:51
  • 1
    Thanks for the comment Sebix! I agree that the regex is probably to blame. What makes me second guess this is that this regex isn't modified - it ships with fail2ban and hasn't been touched, so it matches the docs exactly. Since CentOS is fairly popular, I'm a little surprised that the provided regex might not work "out-of-the-box".
    – SteadH
    Oct 5, 2014 at 14:29
  • Before criticizing the Fail2ban maintainer for CentOS, first look which events are filtered. Then look how the regex is parsed by your setup, there are relevant differences.
    – sebix
    Oct 5, 2014 at 14:34
  • 1
    Sorry - I maybe wasn't clear. I'm not criticizing anyone but my own set up and hoping to understand what doesn't work. I can attempt to work on the regex.
    – SteadH
    Oct 8, 2014 at 22:18
  • i've also been having trouble with fail2ban, i guess i was not testing it properly. i kept using a username of root and hammering away using invalid certificate, never got banned. finally i tried a different username and then whaddyaknow, i got banned after 3 tries. it seems weird that it won't ban me if i use the username root and the wrong cert. i checked the logs and yeah it probably wasn't hitting a match, based on what i saw in filters.d/sshd.conf or w/e that sshd filter file is.
    – Randy L
    May 16, 2016 at 17:22

4 Answers 4

3

Well, I'm no regex master (or even novice), but I did manage to get it to work by adding:

^.*authentication failure;.*rhost=<HOST>

to filters.d/sshd.conf. This did it and I've successfully banned my first host. If any regex experts would like to chime in, I'd be greatly appreciative. I'm sure there's a case that I'm missing in this short expression that would fail in a certain case.

Thanks!

2

@SteadH In your initial post you have this:

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
       sendmail-whois[name=SSH, [email protected], [email protected], sendername="Fail2Ban"]
logpath  = /var/log/secure
maxretry = 5

[ssh-iptables] : being the filter name/reference and

filter = sshd : being the file with the regex filter in /filter.d (sshd.conf)

Then your last post you are making edits to the sshd-iptables.conf? You did your fail2ban-regex check on sshd.conf? Which file are your using? and which one exists or do both exist. I can help you with a regex pattern but I need to make sure Im looking at the right pattern to match.

2
  • Thanks for that davatnull! That was an unfortunate typo. It should have read filter.d/sshd.conf. I'd be happy to provide logs for testing patterns against, or any other info needed.
    – SteadH
    Oct 14, 2014 at 3:56
  • Sorry just seen this comment, If you still need help post the patterns from the log you want to match.
    – devatnull
    Nov 3, 2014 at 14:22
1

i'm working on the same problem today, also on centos 6.5.

in my case the distro file is named filters.d/sshd.conf, not filters.d/sshd-iptables.conf as you wrote. not sure why yours and mine would be different. but in any case i believe the problem is identical.

an example entry from my secure.log is this:

Oct 11 11:11:11 myhostname sshd[12345]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=1.2.3.4

the closest matching failregex in the distro filters.d/sshd.conf is this one:

^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error) for .* from <HOST>( via \S+)?\s*$

that's clearly not going to match the example above because of the "from" and "via" strings and no "rhost=" string. my attempts at fixing this are listed below.

  • first mod, did not match:

    ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error); .* rhost=<HOST> .*$
    
  • second mod, did not match:

    ^%(__prefix_line)[aA]uthentication (?:failure|error); .* rhost=<HOST> .*$
    
  • third mod, matched:

    [aA]uthentication (?:failure|error); .* rhost=<HOST> .*$
    

the __prefix_line regex subexpression comes from filters.d/common.conf and is a great attempt to try to match every possible permutation of known linux log entry prefix formats, but unfortunately it needs some tweaking for our particular centos 6.5 situation. i may take a crack at that but a first glance at the regexes in common.conf makes my head hurt. the less complex regex without __prefix_line may be sufficient.

0

@SteadH based on your solution, I discovered the root of the problem. The sshd filters all end with '$' (dollar) which matches to end of line, in some regexes (I noticed your fix didn't). Well, I deleted the dollars, and viola! it started working! I think there might be some misconfig somewhere in the guts of this which causes the '$' to not work. In any case, try that fix.

1
  • 1
    Are the $s in the default sshd filters? I don't see them in OP's post.
    – Will
    Feb 23, 2016 at 22:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .