Learn to Frustrate the Intruders

Have you ever listened to someone who had been fallen victim to a burglary, someone whose home had been broken into by a criminal, entirely ignoring his privacy, snooping around in his personal belongings and making a total mess of everything coming across his way? It is nearly impossible not to feel the pain yourself this person has been through.

And in the online world things are not that different. After all the effort you've put in to getting a Virtual Private (!) Server going, and after furnishing it with something you think is valuable and worth protecting, you can easily get into a similar rage about people starting to break into your VPS the minute you have finished to make it a venerable target for those careless and often thoughtless digital scumbags on the Internet.

A brief look at the file "/var/log/security" shows how your virtual home is under attack right at the moment.



I sincerely welcome any and all attempts possible to counter the disgusting actions of those, who in most cases are not even remotely aware of or capable to understand, what the software does they are (ab)using.

Statistics of a Break-In Attack

Let's have a look at such an attempt to abuse the ssh service at my VPS. It is recorded in the very first hours this machine became visible on the Internet.

During the best part of an hour the attacker had tried 583 passwords to break into my digital home, nearly every 4 seconds a failed ssh connection was recorded in my logfiles, not unsurprisingly targeting the root account. As it turned out, the IP address was not bound to a registered domain name, so it could even be a innocent user's PC taken-over by the attacker.

Counter-Measures

Some people have suggested trying to play "hide and seek" with the culprits by switching the native port 22 which is used by SSH to something like 51679. Even though that may reduce the rate of attacks, it surely won't deter those who use port scanners to find the port used for SSH.

Others rely on periodically updating their "/etc/hosts.deny" file blocking access from IP-addresses that have proven to be suspicious. This may solve the problem for those attacks that always start at the same hosts, but attackers changing their base frequently will still enjoy an open door, once they are using a freshly taken-over host machine.

I have been taking a different approach, namely to change the response of my firewall to incoming ssh requests. I changed the rules so that only 3 attempts per 2 minute period are being served. This reduced my server's susceptibility greatly, as the automated attacks tend to break off after very few tries and don't return.

The following lines added to my firewall script did the job: