Fail2Ban

Fail2Ban works by scanning through log files and reacting to offending actions such as repeated failed login attempts, by using iptables to generate blocking-rules for any defined (listening) protocols / services, aimed at specific offending IP-addresses.

I used to utilize DenyHosts, but as the project was discontinued I had to adapt. And so I also had to retract all my recommendations of DenyHosts and update them all to endorse Fail2Ban instead.

If using Ubuntu or Linux Mint, setting up and using Fail2Ban is easy.

It comes pre-configured (on Ubuntu) to detect malicious SSH-activity with basic notification action,

Firstly, you just have to apt-get it:

sudo apt-get install fail2ban

Then, you just copy over the standard (Ubuntu) "skeleton"-config:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

 Then stop and (re-)start Fail2Ban to load and run the config:

sudo service fail2ban stop && \
sudo service fail2ban start

It can be customized to send e-mail alerts to designated addresses, and various other "actions_".

Protocols and / or services are easily added to the config-file if they aren't already present. Fail2Bans config-file uses an easy syntax (layout-format) for somebody with basic networking- and logging-knowledge.

I tend to also enable the "ssh-ddos" detection, since these days we're seeing more and more distributed attacks. There are more SSH-specific detection's, but they're not necessary.

gethostbyname()

The last few years (2010-2015), I have been using a command line log-compiler tool I made, called "sshlog", to monitor incoming SSH-logins, both accepted and failed.

It is basically a crude administration-tool (server-side) for remote use on mobile devices and tablets. In combination with "DenyHosts" (python-program for blocking IPs that carry out repetitive and malicious ssh-bruteforce attempts), it proved to be a very solid security-framework.

That is, until January this year.

Suddenly sshlog reported that there weren't made any malicious ssh-connections the last month, and, DenyHosts did not add any new IPs since december last year. Weird...

While log-surfing and manually executing my sshlog-algorithm on my system-logs, I noticed there HAD been malicious ssh-bruteforcing (like usual)... but none of the offending addresses had been added to the blacklist because 'auth.log' was full of warnings about unresolvable hostnames in '/etc/hosts.deny'.

After checking out /etc/hosts.deny, it became apparent that DenyHosts had been adding random canonical hostnames (which, in turn, requires DNS resolving of the IP-addresses) instead of legitimate IP-addresses.

I made my discovery thanks to this repeating error in /etc/hosts.deny:

warning: /etc/hosts.deny, line xxxx: can't verify hostname: getaddrinfo(<some-dynamic-ip>, AF_INET)

*SIGH*
Firstly, I had to stop DenyHosts, then I had to manually 'sed' all the IP-addresses that had been added as canonical hostnames from the DenyHosts config-files, then from /etc/hosts.deny and lastly start DenyHosts up again...

The whole ordeal was apparently caused by none other than... myself -_-

I had enabled DenyHosts to do hostname-lookups for blocked IP-addresses :P *Doh!* which in turn forced DenyHosts to add dynamic hostnames to /etc/hosts.deny, no matter if they were legitimate addresses or not.

Fact is; many of these malicious SSH auto-dialers use dynamic IP-addresses that won't resolve as legitimate addresses in DNS (no registered reverse-lookup, or similar), thus, they are added to '/etc/hosts.deny' with (invalid) canonical hostnames that don't correspond to legitimate MAC and IP-address pairs.