Linux is built to be inherently secure, and has a great track record of having superior security to its proprietary counterpart.<\/p>\n
However, in the world of server administration, paranoia is an asset. How else could someone get in? How can I prevent that? How can I be notified?<\/p>\n
One magnificent contribution to the security of Linux servers the world over is called fail2ban. Why should you care?<\/p>\n
From the Fail2ban main page:<\/p>\n
Fail2ban scans log files like \/var\/log\/pwdfail or \/var\/log\/apache\/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.<\/p>\n
So basically, it gives the finger to those mean people who are trying to brute-force your ssh server. And it blocks them at the packet level with iptables. No iptables knowledge necessary. (Though if you want a quickie, take a look at this short \u201cIptables for Linux\u201d intro).<\/p>\n
For openSUSE users, check to see if you have it available using zypper:<\/p>\n
[1049][root@laptop:~]$ zypper search fail2ban<\/p>\n
If you find it, use zypper install fail2ban to get it on your box.<\/p>\n
If you have trouble getting it installed, follow the seriously excellent advice on the fail2ban download page.<\/p>\n
When you get it installed, as root, edit your \/etc\/fail2ban\/jail.conf file.<\/p>\n
Put your ip addresses in the ignoreip list so you don\u2019t lock yourself out.<\/p>\n
bantime is in seconds. 1 hour is 1440 seconds. 24 hours is 86400. I put in at least 24 hours. Do what works for you.<\/p>\n
maxretry is how many tries a user gets before they\u2019re blocked for bantime seconds. 3 to 5 chances seems more than generous.<\/p>\n
Now to set up the notification.<\/p>\n
In the same file, look for the section called [ssh-iptables]. Change this section so it looks like this:<\/p>\n
[ssh-iptables]<\/p>\n
enabled = true
\nfilter = sshd
\naction = iptables[name=SSH, port=ssh, protocol=tcp]
\n sendmail-whois[name=SSH, dest=notrealemail@suseblog.com, sender=fail2ban@suseblog.com]
\nlogpath = \/var\/log\/messages
\nmaxretry = 3<\/p>\n
If you don\u2019t want the \u2018whois\u2019 info, take out the \u2018-whois\u2019 from the sendmail part. Change the dest email to your own, and set the sender to whatever you want. Maxretry will override the default that you set further up. In logpath, put in the system log, or wherever your sshd logs stuff. Mine happens to be what you see there.<\/p>\n
When it\u2019s set up as you like, save and quit.<\/p>\n
Now, fire that bad fool up:<\/p>\n
[1607][root@mail:\/etc\/fail2ban]$ fail2ban-client start
\n2009-11-27 16:07:46,554 fail2ban.server : INFO Starting Fail2ban v0.8.4
\n2009-11-27 16:07:46,555 fail2ban.server : INFO Starting in daemon mode
\n[1607][root@mail:\/etc\/fail2ban]$<\/p>\n
To make it run when the machine restarts, use chkconfig:<\/p>\n
[1607][root@mail:\/etc\/fail2ban]$ chkconfig -a fail2ban
\nfail2ban 0:off 1:off 2:off 3:on 4:off 5:on 6:off
\n[1610][root@mail:\/etc\/fail2ban]$ <\/p>\n
Within at least a few hours, you should get notifications. Or, you can have someone try and brute force your box and see if their IP gets banned.<\/p>\n
If you read through jail.conf, you\u2019ll see that fail2ban can do loads more than I\u2019ve covered here. But if you want a little more armor on ssh, your biggest target, slap fail2ban on your box.<\/p>\n","protected":false},"excerpt":{"rendered":"
Linux is built to be inherently secure, and has a great track record of having superior security to its proprietary counterpart. However, in the world of server administration, paranoia is an asset. How else could someone get in? How can I prevent that? How can I be notified? One magnificent contribution to the security of… <\/p>\n