Security – How to block all root login attempts using denyhosts and or fail2ban

denyhostsfail2banSecurityubuntu-10.04

I currently block all ssh logins using root. But I wanted to go the extra mile and block the ip address of the client who tried to login as root. I currently have denyhosts and fail2ban setup and working, can I use denyhosts and or fail2ban to block the ip addresses of those who try to login as root?

Best Answer

Depending on your distribution, edit /etc/fail2ban/jail.conf Update the [ssh] section to show something like this

[ssh]

enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
bantime = 3600
maxretry = 3

Change the parameters as required. It won't specifically block root, but every attempt that fails. Be careful with maxretry and the bantime. If you fail with your own password, while maxtretry set to low, you block yourself for the bantime. Restart fail2ban.

I wouldn't try to block the IP forever as a lot of attempts come from dynamic IPs which could block some legitim users at a later point of time.

(Some distributions offer a jail.options file for your modifications. This is the preferred place to put your changes to as it shouldn't be affected by updates overwriting the conf.)

Related Solutions

Ssh – How to prevent denyhosts from adding the same host to the denied file over and over

Sounds to me like denyhosts is checking one file for its lists of hosts being denied (/etc/hosts.deny maybe?) but writing out newly denied hosts to /etc/hosts.deniedssh ; since they're not the same, it never 'realizes' that they've already been added so it keeps re-adding them.

How did you get it to write to /etc/hosts.deniedssh?

Security – Is It Worth Blocking Failed Login Attempts?

Rate limiting login attempts is an easy way to prevent some of the high speed password guessing attacks. However, it's hard to limit distributed attacks and many run at a low pace over weeks or months. I personally prefer to avoid using automated response tools like fail2ban. And this is for two reasons:

Legitimate users sometimes forget their passwords. I don't want to ban legitimate users from my server, forcing me to manually enable their accounts again (or worse, try to figure out which of the 100/1000 banned IP addresses is theirs).
An IP address is not a good identifier for a user. If you have multiple users behind a single IP (for example, a school that runs NAT on 500 student machines) a single user making a few bad guesses can land you in a world of pain. At the same time the majority of the password guessing attempts I see are distributed.

Therefore I don't consider fail2ban (and similar automated response tools) a very good approach to securing a server against brute force attacks. A simple IPTables rules set to cut down on the log spam (which I have on most of my linux servers) is something like this:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

It prevents more than 4 connection attempts from a single IP to ssh in any 60 second period. The rest can be handled by ensuring passwords are reasonably strong. On high security servers forcing the users to use public key authentication is another way to stop guessing.

Best Answer

Related Solutions

Ssh – How to prevent denyhosts from adding the same host to the denied file over and over

Security – Is It Worth Blocking Failed Login Attempts?

Related Topic