SSH brute force password guessing AKA SShellPhishing

SSH brute force password guessing AKA SShellPhishing
A coworker (Matt) and I wanted a shorter name for ssh brute force password guessing and we combined ssh shell and phishing into SShellPhishing. We continue to see ssh brute force password guessing attempts. Occasionally we see large increases. We have seen the attacks switch from one host attempting lots of passwords to lots of hosts that appear to share a dictionary attempting a few password username combinations (coordinated and distributed). That was the direct result of limiting the number of times an ip could attempt to login (fail2ban, bruteforceblocker, denyhosts, sshdfilter, pam_abi, ...). So the cyberwar arm’s race continues with the bad guys developing tools and methods to get around common mitigation methods. I recently wanted to validate some SShellPhishing reports I received. One of the validation steps I used was to check those reported ip addresses against this SShellPhishing blacklist run by Daniel Gerzo. It has nearly 3k entries. http://danger.rulez.sk/index.php/bruteforceblocker/ I spot checked about 40 IP addresses with other SShellPhishing lists also but every ip I checked also appears on Daniel’s list. So while I didn’t get a chance to validate his work in my previous diary https://isc.sans.org/diary.html?storyid=3529 I am now willing to say that I believe Daniel’s list has a very low false positive rate. I saw no false positives so the percentage has to be near 0%. If anyone else has the time and wishes to validate portions of his list I would appreciate any feedback. This diary had a fairly large list ssh brute force password guessing mitigations and tools. http://isc.sans.org/diary.html?storyid=846 Combining some of those mitigation recommendations for a defense in depth approach is a good idea. I recommend moving your ssh from port 22 as we have yet to see a single report of SShellPhishing against a port other then 22. For those of you that think that is simply security via obscurity I would agree with the following caveat forcing the bad guys to scan all 64k ports on a system prior to attacking to find the ssh port adds to the time it takes to compromise systems. It buys system owners time to react potentially preventing compromise. It buys ISPs time to notify compromised customers and it is fairly noisy.	donald 206 Posts ISC Handler
Subscribe	Sep 16th 2008 1 decade ago
Security through obscurity is not necessarily a bad thing as long as it is not the only layer in your defense. The way I see it, password guessing, or forcing, are attempts to break your existing security through obscurity - the password itself.	Jerry 12 Posts
Quote	Sep 16th 2008 1 decade ago
I've been using a script - log-guardian.pl - http://www.tifaware.com/perl/log-guardian/ for a couple of years now - one of my systems has over 191000 unique IPs it has identified over this time. You're right - now most of the scans are below the "3 strikes you're out" level I've set - am looking at ways to allow for my several systems to easily share real-time data on this. Have been considering something like the RBL for bad e-mail hosts	Anonymous
Quote	Sep 16th 2008 1 decade ago
add to previous - note that I also use the same script to guard against dictionary attacks on smtp and many of the recent additions to the IP list are for that reason. Same script can be made to watch for FTP and other ports with fairly minimal changes - uses iptables firewall rules but can be made to use something else	Anonymous
Quote	Sep 16th 2008 1 decade ago
I actually pull out connection attempts from the syslog output from all my network equipment. I restrict access to their VTYs with a common ACL. Any connection attempts to the VTYs from anywhere not on the list gets logged. I don't wait for them to connect and guess userids & passwords. Merely connecting is enough for me to drop them in my RTBH. I also use fail2ban but like most of the other readers, it doesn't help mitigate abusers making only a single attempt. My ACLs don't have that problem.	Anonymous
Quote	Sep 16th 2008 1 decade ago
I compared my list of bad hosts from my RTBH to the BruteForceBlocker list to see how many common entries we have between us. Most of my list about 90% hosts hitting us on tcp/22. However I didn't have a single match in common between my list and their list. I would have at least expected some reasonable percentage in common, say around 50%. Does anyone else find that odd?	Anonymous
Quote	Sep 17th 2008 1 decade ago

A coworker (Matt) and I wanted a shorter name for ssh brute force password guessing and we combined ssh shell and phishing into SShellPhishing.

We continue to see ssh brute force password guessing attempts. Occasionally we see large increases. We have seen the attacks switch from one host attempting lots of passwords to lots of hosts that appear to share a dictionary attempting a few password username combinations (coordinated and distributed).
That was the direct result of limiting the number of times an ip could attempt to login
(fail2ban, bruteforceblocker, denyhosts, sshdfilter, pam_abi, ...).
So the cyberwar arm’s race continues with the bad guys developing tools and methods to get around common mitigation methods.

I recently wanted to validate some SShellPhishing reports I received.
One of the validation steps I used was to check those reported ip addresses against this SShellPhishing blacklist run by Daniel Gerzo. It has nearly 3k entries.
http://danger.rulez.sk/index.php/bruteforceblocker/
I spot checked about 40 IP addresses with other SShellPhishing lists also but every ip I checked also appears on Daniel’s list. So while I didn’t get a chance to validate his work in my previous diary https://isc.sans.org/diary.html?storyid=3529
I am now willing to say that I believe Daniel’s list has a very low false positive rate. I saw no false positives so the percentage has to be near 0%. If anyone else has the time and wishes to validate portions of his list I would appreciate any feedback.

This diary had a fairly large list ssh brute force password guessing mitigations and tools.
http://isc.sans.org/diary.html?storyid=846
Combining some of those mitigation recommendations for a defense in depth approach is a good idea.
I recommend moving your ssh from port 22 as we have yet to see a single report of SShellPhishing against a port other then 22. For those of you that think that is simply security via obscurity I would agree with the following caveat forcing the bad guys to scan all 64k ports on a system prior to attacking to find the ssh port adds to the time it takes to compromise systems. It buys system owners time to react potentially preventing compromise. It buys ISPs time to notify compromised customers and it is fairly noisy.

donald

206 Posts
ISC Handler

Security through obscurity is not necessarily a bad thing as long as it is not the only layer in your defense. The way I see it, password guessing, or forcing, are attempts to break your existing security through obscurity - the password itself.

Jerry

12 Posts

I've been using a script - log-guardian.pl - http://www.tifaware.com/perl/log-guardian/
for a couple of years now - one of my systems has over 191000 unique IPs it has identified over this time.

You're right - now most of the scans are below the "3 strikes you're out" level I've set - am looking at ways to allow for my several systems to easily share real-time data on this. Have been considering something like the RBL for bad e-mail hosts

Anonymous

add to previous - note that I also use the same script to guard against dictionary attacks on smtp and many of the recent additions to the IP list are for that reason. Same script can be made to watch for FTP and other ports with fairly minimal changes - uses iptables firewall rules but can be made to use something else

Anonymous

I actually pull out connection attempts from the syslog output from all my network equipment. I restrict access to their VTYs with a common ACL. Any connection attempts to the VTYs from anywhere not on the list gets logged. I don't wait for them to connect and guess userids & passwords. Merely connecting is enough for me to drop them in my RTBH. I also use fail2ban but like most of the other readers, it doesn't help mitigate abusers making only a single attempt. My ACLs don't have that problem.

Anonymous

I compared my list of bad hosts from my RTBH to the BruteForceBlocker list to see how many common entries we have between us. Most of my list about 90% hosts hitting us on tcp/22. However I didn't have a single match in common between my list and their list. I would have at least expected some reasonable percentage in common, say around 50%. Does anyone else find that odd?

Anonymous