Dealing With Unwanted SSH Bruteforcing

Published: 2010-01-01. Last Updated: 2010-01-01 15:19:47 UTC
by G. N. White (Version: 1)
12 comment(s)

A common question I get from individuals who use Internet-accessible SSH
to manage their network devices concerns how do deal with all the unwanted
Bruteforcing activity that is usually attracted.

While changing the default SSH listening port number and/or implementing a
Source-IP based Access Control List would seem like common sense solutions,
there are still situations where it is either not possible to move the SSH
listening port or not practical to implement an Access Control List if the
application involves providing access from dynamic Internet address space.

I recently became aware of an interesting initiative at http://www.sshbl.org
where a collection of SSH Bruteforcing attempts by source IP is being maintained.

The next step (of course) was to solicit logs from a few colleagues who monitor
and deal with this nefarious activity, and it was quite amazing to see a significant
amount of overlap with the sshbl.org statistics.

A final step of experimenting with an Access Control List to block SSH activity from
the sshbl.org SSH bruteforce IP list is still in the works, but will nevertheless be
an interesting exercise.

Do you have a favourite source of statistics regarding SSH Bruteforcing activity?
If there's enough interest, I'll post a summary at the end of my shift.

Best wishes for 2010 to all our readers!

G.N. White
Handler on Duty
 

Keywords: SSH bruteforce
12 comment(s)

Comments

I wouldn't call changing the listen port 'common sense' -- even if it helps in the short-term -- since it only makes you a less obvious target until the bots start doing any portscanning. SSH services are easily identified from the greeting after opening a TCP connection.

I'm also reluctant to do IP-based anything, in case a host at a whitelisted IP becomes compromised. (These days it seems that even browser plugins can make TCP connections without your permission).

I accidentally discovered that the SSH bruteforcing bots only implement certain ciphers at the moment, so you could change your SSH servers to accept only something like aes256-ctr,aes128-ctr. Since doing this some months back I haven't noticed a single bruteforce attempt -- the clients just disconnect immediately (but shhh, don't tell anyone).

Any of these approaches give a false sense of security in case of a *targetted* attack though, and the bots will also learn new tricks over time no doubt.

I was rate-limiting login attempts by IP (with fail2ban) but I think this is only a short-term fix also. I began to see distributed attacks that would co-ordinate a dictionary attack across many source IPs at once, allowing many more attempts to be made before any banning occurred. This attack only becomes more efficient as the botnets become larger.

So I'm looking to find a more definitive solution. I think I may have to disable password authentication entirely and require host keys. I'm assuming it would take many years to brute-force 1024-bit keys (a 'good' 8-character password might have only 30 bits of entropy anyway).

That may be difficult for some sites to implement, especially something like a campus, but it seems like the only way to go. What's needed are good tools for giving people keys (as many as they want), keeping track of them, and maybe expiring them periodically.

As for all those little devices with embedded SSH daemons -- unless you set very good passwords, trust you vendors, and keep the devices patched -- I propose trying to put them on a private LAN (or better, separate tagged VLANs) attached to a locked-down SSH host that acts as a gateway.

Happy 2010!

Steven Chamberlain

Jan 1st 2010
1 decade ago

What do you guys think of using something like fwknop? Never used it personally, but seems like it, along with some host keys, but a good solution (security through obscurity and security by design). Or is that too perfect world and naive?

Joshua Smith

Jan 1st 2010
1 decade ago

fwknop just looks like a dynamic variety of an IP-based ACL to me, with most of the same drawbacks. Either way you should be able to avoid the random scans and bruteforce attacks that way.

But fwknop requires that clients install / know how to use it, in which case I suppose they could just as easily connect to a private VPN in order to get access.

If fwknop works by simply opening up access to the 'knocking' source IP address, surely that's not safe to do from unfriendly network, because for 10 seconds the port would be open to potential attacks. It may be enough time for someone who can sniff this in real-time to exploit the server you'd been lazy about patching (because you had fwknop installed and didn't think it important any more). In that unlikely scenario I imagine a VPN would be better, as the access control runs from end-to-end.

Although how would you prevent access to a VPN from being bruteforced? Surely with host/client keys or certificates? In fact even fwknop relies on asymmetric crypto.

So I guess public-facing password prompts are just 'out' for 2010 (fingers crossed). Bring on keys/certificates/smartcards.

Steven Chamberlain

Jan 1st 2010
1 decade ago

I implemented keys, but bruteforce attempts kept polluting my log files, so I added a couple iptables rules to keep them down;

#Anti-Bruteforce for SSH
iptables -N SSHSCAN
iptables -A INPUT -i eth2 -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 3600 --hitcount 5 --name SSH -j DROP
iptables -A SSHSCAN -m recent --update --seconds 3600 --hitcount 5 --name SSH -j LOG --log-level info --log-prefix "Anti SSH-Bruteforce: "

Just, don't try to open more than 5 ssh connections to the box within an hour, or it'll cut you off :)

Jeff

Jan 2nd 2010
1 decade ago

Ah, that explains why I don't see _anything_ in the logfiles about bruteforce attempts, I moved the DROP above the LOG. Heh.

If you want to actually see log messages, move the DROP line to below the LOG line.

Jeff

Jan 2nd 2010
1 decade ago

this RBL sounds like a kickass idea, how does one go about using it?

joeblow

Jan 2nd 2010
1 decade ago

Of course http://denyhosts.sourceforge.net/ is already a popular RBL (70,000+ contributors)... but an RBL is unlikely to help you against a dedicated attacker (ie. someone whose source IP[s] won't already appear on an RBL, because you're the only target).

Steven Chamberlain

Jan 2nd 2010
1 decade ago

My server is running multiple services, so I use OSSEC to blacklist people trying to abuse ssh, ftp or others.

I started a small phpbb to discuss what I'm doing, how I do it and things, and there is the stats for my BLACKLIST table:

http://www.gobinjf.be/phpbb/viewtopic.php?f=8&t=2

Jean

Jean

Jan 3rd 2010
1 decade ago

I think there are actually two issues related to changing the SSH port. Of course, it does not actually help in a security sense - the port can be easily found and scanned. However in many cases a host with SSH open will only have a few users, all of who have sufficiently strong passwords anyway - but still the incessant scanning on port 22 will cause a lot of log to be written and the hard drive to clatter irritatingly. Changing the port is a quick fix to this annoyance. This was what I did after I for one reason or another just could not get some pam-based bruteforce preventer tool to work properly on my Debian box.

IL

Jan 4th 2010
1 decade ago

I run a BL across our site. We had a couple of spikes before Christmas
http://trweb.triumf.ca/triumf_nodeinfo/block/block-ssh-log.png

(out of curiosity, I have a hacked sshd on one machine that logs unsuccessful passwords. Some of these are really "strong" and I presume were found to work across multiple machines somewhere:
http://andrew.triumf.ca/ssh_pass_file2.html

Andrew

Jan 5th 2010
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives