- 1 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 2 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 3 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 4 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
- 5 Docker Reaches Across Universes at Dockercon EU
Tip of the Trade: Fail2Ban
Anyone who leaves a port open for remote SSH logins, especially port 22, is familiar with logfiles that quickly get clogged with failed brute-force intrusion attempts:
|Ward off SSH attacks and other brute force maneuvers with this log-based
Jul 30 11:18:56 server1 sshd: Failed password for root from xxx.174.25.221 port 2528 ssh2 Jul 30 17:24:57 server1 sshd: Failed password for invalid user aaa from xxx.174.25.221 port 3158 ssh2 Jul 30 11:25:07 server1 sshd: Failed password for invalid user aaaa from xxx.174.25.221 port 3477 ssh2 Jul 30 17:25:12 server1 sshd: Failed password for invalid user aaaaa from xxx.174.25.221 port 3609 ssh2 Jul 30 11:25:22 server1 sshd: Failed password for invalid user aaaaaa from xxx.174.25.221 port 3944 ssh2
This particular example is amusing for its odd implementation of a dictionary attack. Even if your SSH server is immune to this sort of attack because you have disabled password authentication, it's still nice to head it off at the firewall. And Fail2ban is just the tool for this job.
Fail2ban is a nice log-based brute force blocker. Using it to head off SSH attacks is probably the most common way to use it, but it works for as many services as you want. It reads whatever logfiles you tell it to, then writes iptables rules in response to attacks. Or, you may use tcpwrappers, which means it will write entries to /etc/hosts.deny. No muss, no fuss, and Fail2ban does all the work. It bans offending hosts for whatever interval you like, from a few minutes to permanently.
Fail2ban runs as both a daemon and from the command line for testing and giggles. You can monitor its activity on the console and watch as attackers are cut off with no intervention on your part. It installs with ssh protection enabled by default. The default /etc/fail2ban.conf contains examples for many different services and is well-commented, so it's easy to set it up for your own needs. The Fail2ban logfile looks like this, and is easy to parse and analyze:
2006-07-18 11:22:30,388 WARNING: SMTP: Ban xxx.25.82.125 2006-07-18 11:59:01,295 WARNING: SMTP: Ban xxx.25.118.110 2006-07-18 12:17:41,183 WARNING: SMTP: Unban xxx.46.82.221 2006-07-18 14:11:54,530 WARNING: SMTP: Unban xxx.87.118.002 2006-07-18 18:07:22,086 WARNING: SSH: Ban xxx.234.60.033 2006-07-18 19:47:11,833 WARNING: SSH: Unban xxx.321.60.164
From here, you might want to track and record offending source IPs to substantiate complaints to upstream providers or build a colorful world map showing where the attacks are originating.
Get downloads and lots of good documentation at Fail2ban.sourceforge.net.