Cisco and Level 3 team up to squash brute force server hijackers

Cisco and service provider Level 3 have teamed up take down netblocks linked to brute-force hack kingpins SSHPsychos, severely degrading (but not destroying) the group's potential to hack servers in the process. Hacker collective SSHPsychos (AKA Group 93) has been running SSH brute force attacks on an industrial scale since …

[Lee D]

Don't leave SSH ports open to the Internet and demand public-key authentication for all users.

I thought this was standard practice?

(That said, I used port-knocking for my servers just to stop this junk... there is no POP3/IMAP/SSH/etc. port to contact on the server at all until you "knock" the server, and then they are only open for your IP and no others... the space and hassle saved on logs, connection limiting, etc. are worth the "apt-get install knockd" and the one-file setup alone, and I don't need to worry about IP whitelists, what happens if I come in on a foreign IP, and even my smartphone has port-knocking apps that tie into ConnectBot so you can still SSH in with one click yourself anyway. No more "secure", technically, but just a lot more closed-off from public view preventing brute-force attempts entirely and filling my logs with spam).

[Gerhard Mack]

Great plan.. unless you have a user who needs to read their email or have a user that needs to shell (bonus points if they have old software)

A far less obnoxious approach is something like fail2ban. I have mine set a 1 hour ban after 6 bad attempts in 5 minutes.. (root is ssh key only) It reliably nails the botnets without bothering legitimate users who make.the odd password mistake.

[Tom Chiverton 1]

I also found geoblocking with iptables helpful in stopping the fail2ban lists from getting huge. Just remember to add the destination before going on holiday...

[Lee D]

It might get individual attackers but entire botnets? No.

I've seen co-ordinated attacks from botnets where hundreds of separate and geographically-disparate systems will coordinate on the same username list to brute force the password.

For my systems, SSH is administrative use only, so it got put behind port-knocking. Mail collection from that machine is administrative only, so it got put behind port-knocking. Users who need it can be bundled with a port-knocking utility that runs on logon quite easily.

I'm not suggesting it for mass-email servers, but those should be managed properly anyway. However, for all those other servers that are offering SSH for administrative purposes, hiding them behind either a different port number or port knocking cuts out brute-force attempts immediately.

Your solution relies a single attacker only ever coming from a single IP. Even with your rate-limiting, a botnet of anywhere near decent size could still perform several million attempts a day just by handing off portions of a brute force task to a few thousands of its machines. And the chances of you picking up on it are even less, and the chances of blocking it (without affecting legitimate users) are near-zero.

I'm fast moving all external provided services to be behind the VPN for known users. There are few devices these days that can't handle VPN'ing in to get a job done. For public-facing services (website HTTP, SMTP) rate-limiting is all you have and only keeps the most stupid of brute-forcing idiots away. However, for my use (where my personal server is only logged into by me, but potentially from multiple locations unknown beforehand) I find port-knocking the middle-ground that stops all brute-forcing while allowing me - with one extra click - to get everything I need access to. At work, anything critical is behind the VPN and the VPN is certificate-managed and rate-limited.

[theloon]

buzzzz buzzzz

swat that fly... 'yahhh'

later.......

buzz buzz......'oh crap'

[naive]

Use pam to put a wait time between logins

Pam offers a way to create a wait time between failed ssh login attempts. This effectively makes brute force logins impossible:

See http://unix.stackexchange.com/questions/105553/how-to-provide-login-delay-in-ssh

Disallowing password authentication for known accounts like root, oracle, etc.. is mandatory anyway...

[Lee D]

Re: Use pam to put a wait time between logins

Only if they stay on the same IP address?

When I do log packets for debugging, I see thousands of hosts all co-operating to try different sections of the same username list simultaneously. They are obviously compromised machines (loads of dynamic IP's and web-servers etc.) taking part in a co-ordinated botnet much as the article describes. The same is true for HTTP, POP3, IMAP, SMTP and SSH brute-forces and you can see the same set of attempted usernames/passwords go past sometimes.

The only way to stop THAT is to block access to unknown IP's (stupid, counter-productive) or allow your own users to be DoS'd because there's been X thousands attempts in the last hour from the rest of the world.

This kind of rate-limiting is fine for individual, sole workstations attacking you but is ineffective against any kind of co-ordinated botnet. Hell, just the IP range of something like Amazon Cloud can be so huge that you could end up with millions of attempts even with all your rate-limiting.

[Anonymous Coward]

Honeypot

For a laugh I set up a fake ssh daemon on a VM on its own VLAN for obvious reasons. I gave it an external IP that we'd never used before and waited. After a day, nothing. I then pinged a few addresses (OK quite a few) from my firewall logger. Bang: 7000 attempts within a few hours.

Then it went berserk. I now have a huge blacklist for passwords. I also have a username blacklist but that is harder to enforce but my service/daemon accounts are different nowadays 8) I'll do it again in a while and update my password blacklist.

For the record: port 22 only from whitelisted addresses. Dynamic IP? you'll need a VPN then. End of chat.

Cheers

Jon

[Kevin McMurtrie]

Too many bad networks for a Cisco product

This is for everybody owning a Cisco small business firewall that only supports 50 rules.