Started some days back, the flood of co-ordinated, distributed but slow brute-force attempts on my
sshd (and possibly others) was evident in my logs. Over a few days, my logs swelled into megabytes, many times over the usual kilobytes.
The attack, I have to say, was rather intelligent. The attacker(s) used many machines, each trying a name starting from a, in concerted succession, alternating one after another. This way, my usual brute-force detection systems fail to kick in as they are seen to be a few invalid logins from each host, when view in a per-host isolated context.
In clearer terms, let’s say there are 1 to 1+n hosts. Host 1 tries to login as a. Fails, wait 1 second. Host 2 tries as b. Fails, waits x seconds, where x < 10 seconds. Host 3 tries as c. Rinse and repeat until the whole dictionary is visited. Innocent as each individual login might seem, when view from the context of an attacker, it’s simply brilliant.
Believe it or not, eventually, it’ll enter my machine if my defences aren’t stepped up to at least trigger a reaction to these events.
Days before, I’ve already implemented login tallies, whereby whenever an user account has experience 3 consecutive failed logins, the user account is locked, regardless of the password supplied. This way, I get to control when the accounts are re-enabled, allowing me to keep a closer eye on the situation.
Coincidentally, while the attacks are going on, one of my friends told me about his account which is always being locked out. As I was away from home, except to sleep, for the large part of that week, I hardly had the time to investigate.
Two days ago, in a bid to improve security, I came across this great defence mechanism,
Fail2Ban. It works for multiple services and can flexibly do anything whenever too many failed connections are detected.