Setting up fail2ban on a new server...

I've configured sshd for no root login, a single allowed user, pub key auth only, plus installed fail2ban with the 'ssh-iptables' jail running. Logs indicate this jail is up and running successfully.

>>Is this the correct/best jail to run for ssh? After glancing at the regex for the ssh, is the default sshd filter sufficient, or are tweaks recommended?

>>What other jails would be appropriate to start up right away beyond ssh-iptables?

Sounds like you are on the right track. I would also turn on privledge seperation in /etc/ssh/sshd_config. It makes the authentication part of ssh chrooted so if someone exploits one of the actual authentication methods themselves, they don't have access to your filesystem.

nomb

Is this as simple as:

UsePrivilegeSeparation yes
StrcitModes yes

in sshd_config?

Yep exactly right.

The default for both of those maybe yes already. I know they are for Archlinux but not sure for CentOS.

Yes, both are defaults on CentOS also...just checked.

Just stating the obvious but on Centos "StrictModes yes" and "UsePrivilegeSeparation yes" are commented out as they are (software?/)distribution defaults.
Other points of attention in sshd_config could be:
"Protocol 2": no fallback to Protocol 1 (if you require SSHv1 for like b0rken clients you would already know),
"PermitRootLogin no" (as you configured it already),
"MaxAuthTries 3" (wrt bruteforcing, defaults to 6 IIRC),
"PubkeyAuthentication yes" and "PasswordAuthentication no": no usage of or fallback to using passwords.

Thanks that was already confirmed.

Last time I used fail2ban, it blocked the IP after 3 failed attempts by default. Not connections but failed password attempts. So even if you had MaxAuthTries at 10, wouldn't fail2ban still block the IP after 3?

Or, does fail2ban now use the values from the /etc/sshd_config?

nomb

I gotta check the Protocol level, had changed the MaxAuthTries same. With these changes it is amazing how much lower the secure and messages log activity is...once fail2ban kicks in on sshd, it is going to be dream come true compared to the prior system I had.

RE: sshd filter for f2b--this defaults to monitoring /var/log/sshd.log (not how sshd logs by default on CentOS)...I didn't catch this right away, which means if you don't edit this config, then f2b starts up without warning and is doing nothing since that log file doesn't exist.

So, I changed it to monitor /var/log/secure--is this the best way to go, or better to setup sshd to log to its own file and monitor that? I'm assuming leaving it at /var/log/secure is better for running higher-level log analysis tools since all activity gets consolidated there???

OK, here is one of today's douchebags (oops, can I say that in here? he's from the cortesuprema...oooooo):

Oct 6 09:37:47 centos514899 sshd[18167]: User root from www.cortesuprema.gov.ec not allowed because not listed in AllowUsers
Oct 6 09:37:47 centos514899 sshd[18168]: input_userauth_request: invalid user root
Oct 6 09:37:47 centos514899 sshd[18168]: Received disconnect from 190.152.14.6: 11: Bye Bye
Oct 6 09:37:53 centos514899 sshd[18169]: User root from www.cortesuprema.gov.ec not allowed because not listed in AllowUsers
Oct 6 09:37:53 centos514899 sshd[18170]: input_userauth_request: invalid user root
Oct 6 09:37:53 centos514899 sshd[18170]: Received disconnect from 190.152.14.6: 11: Bye Bye
Oct 6 09:37:54 centos514899 sshd[18171]: User root from www.cortesuprema.gov.ec not allowed because not listed in AllowUsers
Oct 6 09:37:54 centos514899 sshd[18172]: input_userauth_request: invalid user root
Oct 6 09:37:54 centos514899 sshd[18172]: Received disconnect from 190.152.14.6: 11: Bye Bye
Oct 6 09:37:57 centos514899 sshd[18173]: User root from www.cortesuprema.gov.ec not allowed because not listed in AllowUsers
Oct 6 09:37:57 centos514899 sshd[18174]: input_userauth_request: invalid user root
Oct 6 09:37:58 centos514899 sshd[18174]: Received disconnect from 190.152.14.6: 11: Bye Bye
Oct 6 09:38:00 centos514899 sshd[18176]: User root from www.cortesuprema.gov.ec not allowed because not listed in AllowUsers
Oct 6 09:38:00 centos514899 sshd[18177]: input_userauth_request: invalid user root
Oct 6 09:38:00 centos514899 sshd[18177]: Received disconnect from 190.152.14.6: 11: Bye Bye

Fail2Ban isn't catching this guy in the sshd-iptables jail...I have maxRetry set to 3 and here the guy is attempting at least 5 entries in 15 secs. Here is the default filter for sshd-iptables--looks like line 5/6 should be catching the "invalid user root" and "AllowUsers" log entries no problem:

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 (?assword|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 \S+ 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 \S+ from <HOST> not allowed because none of user's groups are listed in AllowGroups$

I think Fail2Ban polls the log files every so often, it doesn't monitor them in real time. It is likely that Fail2Ban DOES block the offending IP address after 3 blocks, but sometimes the attacker will get a few extra tries in before the log files are polled again.

Could add the iptables "recent" module on the SSH port to set a SYN threshold.

Yes, but MaxAuthTries is OpenSSH's way to prevent an unlimited amount of login attempts in a single connection. What I mean is that protecting the complete stack should be to first set up users properly (like chage'ing accounts to ensure timely lockout) and user pubkey auth, then harden OpenSSH service settings and user options like AllowGroups, AllowUsers, then network restrictions in tcp wrappers or network restrictions in the firewall (whichever manages easier) and then fail2ban or equivalent.

Gotcha, you were speaking from an overall best-practice standpoint.
Which makes sense.

nomb

OK, so f2b did ban an address for the first time this am...I may have failed to reload the config prior to the last attempt:

2009-10-07 10:00:11,229 fail2ban.actions: WARNING [ssh-iptables] Ban 210.71.51.66
2009-10-07 10:10:11,559 fail2ban.actions: WARNING [ssh-iptables] Unban 210.71.51.66

What is strange is that I had/have MaxAuthTries 2, yet clearly here is the log showing 3 attempts in under 10 secs:

Oct 7 10:00:06 centos514899 sshd[27121]: Invalid user master from 210.71.51.66
Oct 7 10:00:07 centos514899 sshd[27122]: input_userauth_request: invalid user master
Oct 7 10:00:07 centos514899 sshd[27122]: Received disconnect from 210.71.51.66: 11: Bye Bye
Oct 7 10:00:09 centos514899 sshd[27123]: Invalid user adobe from 210.71.51.66
Oct 7 10:00:09 centos514899 sshd[27124]: input_userauth_request: invalid user adobe
Oct 7 10:00:09 centos514899 sshd[27124]: Received disconnect from 210.71.51.66: 11: Bye Bye
Oct 7 10:00:10 centos514899 sshd[27125]: Invalid user alisia from 210.71.51.66
Oct 7 10:00:10 centos514899 sshd[27126]: input_userauth_request: invalid user alisia
Oct 7 10:00:10 centos514899 sshd[27126]: Received disconnect from 210.71.51.66: 11: Bye Bye

Is this due to the disconnect between each attempt, and/or the fact that the cracker is trying a different user each time?

Also would be nice/better for f2b to log bans in secure log to see it working alongside the entry attempts...may change that.

The way f2b works is it blocks the ip address of X number of logins, in X amount of time. So in that example you provided, it blocked that IP as it should have. The default number of login attempts for ssh on f2b is 3 so that is right.

MaxAuthTries is strictly an sshd option that specifies how many invalid passwords you can try before the ssh service drops your connection. When you are logging in, you can't change your user name. So since each attempt has a different username, that shows it is 3 seperate connections and wouldn't get caught by MaxAuthTries. However your f2b worked as it should.

Have you thought about changing your ssh port? It doesn't provide any real additional security, however it does get rid of a lot of failed password attempts created by bots looking for week ssh accounts/passwords running on port 22.

Also, if you feel up to it, and think it is a feasable option, you can generate yourself a private/public key pair to use with ssh and use keys to login and turn off password authentication.
You will see your failed login attempts drop to almost nothing.

The other benifit of this is you can use ssh-agent to store an unlocked key in memory. So you can then ssh to the box w/o having to enter any password. (Don't use a key without a password on it. Just bad practice. Better to use ssh-agent.)

nomb