The Low-Intensity, Brute-Force Zombies Are Back

Peter N. M. Hansteen writes "In real life, zombies feed off both weak minds and the weak passwords they choose. When the distributed brute-force attempts stopped abruptly after a couple of months of futile pounding on ssh servers, most of us thought they had seen sense and given up. Now, it seems that they have not; they are back. 'This can only mean that there were enough successful attempts at guessing people's weak passwords in the last round that our unknown perpetrators found it worthwhile to start another round. For all I know they may have been at it all along, probing other parts of the Internet ...' The article has some analysis and links to fresh log data."

Comments

why are passwords even allowed?

[rcpitt]

None of my systems allow passwords via ssh - and I run log-guardian.pl to "3 strikes - you're out" the idiots who do the brute-forces by putting them into iptables

Anyone with passwords turned on is not secure IMHO

Poor Odds

[Nerdfest]

The odds of them getting into a system like this must be quite low, but I guess they're after the low-hanging fruit. Running your services on a high port rather than the default reduces this, as does disabling password login and using 2-factor authentication. Quite easy to do, and very, very secure.

How-to

[Nerdfest]

Sorry, should have posted this with the original. Instructions for Linux 2 factor authentication

Oh...

[Perseid]

...you mean zombie PROGRAMS. Damn.

[puts shotgun down]

Protect yourself

[Matt Perry]

Use SSH keys in addition to passwords. Disable ssh root logins. Use the AllowUsers command in sshd_config to restrict what accounts can log in with ssh. Edit /etc/hosts.deny and add IP ranges for where you are unlikely to login from. Use iptables rules to block people who are hammering your ssh server from the same address. Use tools like Fail2ban and DenyHosts to block other abusers and share abuser information with other victims.

SPA / PORT KNOCKING - Bye Bye Brute

[myspace-cn]

Roll out SPA / Port knocking, their IP shouldn't be touching your sensitive ports without a rule, table, or chain specifically allowing access. FORGET THE PASSWORD!

Not So Shameless Plug

[value_added]

For those already familiar with Peter Hansteen's website, I'll offer a Thumbs Up recommendation for his Book of PF.

There's already been several stories on Slashdot either submitted by or about him, and I don't recall any mention of his book. I'd say his efforts if not his humility deserve some kind of reward, and the reduced sale price of $19.77 is a bargain.

In all seriousness

[actionbastard]

This has been going on for years. Really. I've been seeing this crap in my logs since we started running an Internet-facing SSH host nearly ten years ago. It's always the same password based login attempts with the same dictionary/script used in the attacks. This is probably just some training exercise for Chinese hackers at some state-run school to see who can break into the running-dog Yankee Imperialist's computers the fastest.

I'm safe...

[hoytak]

I've now changed my password from Thomas to ThomasX, where X is a digit that I'm not telling.

Re:I'm safe...

[spartacus_prime]

I tried to make my password "penis," but it said it wasn't long enough. :(

Goodness.

[geekboy642]

There sure are a lot of people who didn't bother to read the article.
The point of these attacks are that it's a coordinated botnet attack. Meaning if you block any single IP, or even a large subnet, you've cost the attacker nothing. Fail2ban, denyhosts, all of these won't even slow these attacks down.

iptables goodness

[grasshoppa]

Once again, we have a built in linux goody which helps us out;
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --set --name sshattack --rsource
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j LOG --log-prefix "SSH Drop: "
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

The above allows three connections in a 5 minute period to port 22. After that it rejects any further connection attempts until the 5 minute timer is up.

My Solution

[ironicsky]

I was having similar brute force attacks.
I've made some alterations to protect my server from brute force SSH attempts.

1) Moved SSH to another random port
2) Bound the SSHD to an IP address that is not used for Web/Mail/FTP, etc.. So the IP should generally see less traffic
3) Disable Password Authentication, Users who are given SSH access must use a password protected key file
4) Disabled Root SSH Login
5) Setup the system that 3 failed logins add the entire IP Subnet(X.X.X.0-X.X.X.255) for 15 minutes, 5 failed attempts 1 week, anything else is a never ending ban. (iptables and hosts.deny, just in case)