Brute force SSH attack confounds defenders

[xor]

Source San News Bites:

Sounds Serious:

ATTACKS
--SSH Brute Force Attack Uses Botnet to Target Specific Servers
(December 5 & 8, 2008)
After noting a spike in failed SSH logins in October, researchers
identified an ongoing brute-force attack that involves multiple machines
that have been compromised with bot software. The attacks target
specific servers. Researchers have not been able to obtain a sample of
the botnet code used in the attack.
http://www.theregister.co.uk/2008/12...ce_ssh_attack/
http://www.heise-online.co.uk/securi...--/news/112174

xor

[Greyhatter]

Re: Brute force SSH attack confounds defenders

Short Easterners again?

[code08]

Re: Brute force SSH attack confounds defenders

No don't you know? It's always the Russians.

[shrdlu]

Re: Brute force SSH attack confounds defenders

Source San News Bites:

Sounds Serious:

ATTACKS
--SSH Brute Force Attack Uses Botnet to Target Specific Servers
(December 5 & 8, 2008)
After noting a spike in failed SSH logins in October, researchers
identified an ongoing brute-force attack that involves multiple machines
that have been compromised with bot software. The attacks target
specific servers. Researchers have not been able to obtain a sample of
the botnet code used in the attack.

Actually, I was on the receiving end for this, as one of the very first attackees. I took sshd down for a day, and then for a few days, and then for a week. No dice. Within two minutes of it being back up, the attacks would repeat. I gave up, and moved ssh to a different port, something I thought I would never do.

I saw the originating scan, and initially two windows machines were involved in the attack as well (I'd guess because the silly windows firewall doesn't allow responses to pings by default). The *only* machine to continue being attacked was a freebsd machine, running (from memory) release 6.1, and probably no patches. If I weren't busy doing other things, I might have resurrected a honeypot, and put it at that IP, but I'm lazy, and I didn't.

I counted over 7000 unique IPs before I got bored with it.

[0x58]

Re: Brute force SSH attack confounds defenders

I was at the receiving end for this little bot as well, I saw almost 3000 unique's hitting the machine at the same time. I have a small script set up, try to crack 3 wrong user accounts, and the IP gets blacklisted from the server by being added to the firewall. PF also makes sure that any connecting party does not go over a certain connections per second limit, so most of them hit that and were also added to the same ban list. After just 10 minutes (looking at logs) almost all of the IP's participating were blocked.

Every so often I still see attempts from new IP's, but not nearly enough to cause worry.

[shrdlu]

Re: Brute force SSH attack confounds defenders

I was at the receiving end for this little bot as well, I saw almost 3000 unique's hitting the machine at the same time...PF also makes sure that any connecting party does not go over a certain connections per second limit, so most of them hit that and were also added to the same ban list...

This sounds like you are also running a BSD. Care to say which?

[0x58]

Re: Brute force SSH attack confounds defenders

This sounds like you are also running a BSD. Care to say which?

Sure.

# uname -mrs
FreeBSD 6.2-RELEASE-p2 i386

Yeah, it is a little dated, but there are no remote root exploits for it, which is what I care about. Have not yet had the chance to grab a copy of the entire system, run it within a VM and do a test upgrade from 6.x to 7.x to make sure I don't run into any weird issues.

I set the extra version key for SSH to something entirely random, to throw people off. nmap for example fails to properly identify the OS when scanning it.

telnet breached 22
Trying 10.10.10.11...
Connected to breached.network.lan.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.5p1 Breached

Is an example of this. Instead of showing the default:

SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110

[shrdlu]

Re: Brute force SSH attack confounds defenders

Sure.

# uname -mrs
FreeBSD 6.2-RELEASE-p2 i386

Yeah, it is a little dated, but there are no remote root exploits for it, which is what I care about.

I don't have a lot of datapoints, but what's interesting is that it seems to be freebsd 6.1 or 6.2 that is getting the serious hammering. I saw the initial scan come in, and it flat ignored my FreeBSD 4.4 (yeah, yeah, I know, I know), and all the OpenBSD machines, and anything Linux. It tried two window machines for the first day, but then those dropped off too.

I set the extra version key for SSH to something entirely random, to throw people off. nmap for example fails to properly identify the OS when scanning it.

I haven't bothered yet with changing any default stuff with openssh, and am not sure it'll help in this case. Although one of the articles quoted in the thread suggested that even a different port was only a stopgap, it's seemed to work for me, for now.

SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110

I'm not sure that the version of openssh matters (but I'm running the one that goes with freebsd 6.1, which is 4.2p1). I think that the attackers appear to be looking for something specific. I've never had a freebsd machine as part of a honeypot, which means that I'd have to start from the beginning, if I wanted to set something up. Two weeks later, though, and allowing ssh in on 22 had attacks going within a minute, so it's still there and waiting. I may just go for it in a week or two...

[The Dark Tangent]

Re: Brute force SSH attack confounds defenders

What is the anti-brute ssh tool of choice? I know there are several scripts and packages that let you configure how many attempts a second, etc. before they are added to the pf or ipfw deny list. Just curious what happens when your ipfw rule set has 10k IPs in the deny list.

[0x58]

Re: Brute force SSH attack confounds defenders

Mine is a hacked together perl script that reads /var/log/security using a tail -F :P If a user account exists, 10 attempts are allowed, unless the username is root (yeah, root logins are on, yes I know, and no I can't change it.). If the username does not exist they have 3 tries for that IP. After that I just add it to a table for pf and i am set. [Old version of script available at: http://trac.svn.0x58.com/projects/bs...ts/auditban.pl , have not yet had the chance to finish the modifications I have made to it, and commit them]

I don't use ipfw so I have no idea how it handles when you have 10k IP's in the deny lists.

pfctl -T show -t accountout | wc -l
    12600

I have not noticed any slowdowns or any adverse effects because of it.

The PF rule that stops floods of incoming attacks is this:

pass in quick log on $ext_if proto tcp to port $tcploginports keep state (max-src-conn 15, max-src-conn-rate 5/3, overload <accountout> flush)

This basically says 5 max connections per IP every 3 seconds. Max of 15 connections from any single IP, otherwise we add them to the accountout table, and flush all the connections so that they all get closed.

block in quick on $ext_if proto tcp from <accountout> to port 22

Off course is added above the pass in lines, so that any IP's in the accountout table is immediately dropped. We still allow them access to our other open IP's (port 80), just not 22. Which is enough for most attackers since they don't care much about http.

[xor]

Re: Brute force SSH attack confounds defenders

What is the anti-brute ssh tool of choice? I know there are several scripts and packages that let you configure how many attempts a second, etc. before they are added to the pf or ipfw deny list. Just curious what happens when your ipfw rule set has 10k IPs in the deny list.

Source Heise Online

According Heise Online

"Tools like DenyHosts, BruteForceBlocker or fail2ban for preventing attacks on SSH servers usually count the number of failed log-in attempts from one IP address and enter addresses that exceed a given threshold on a blacklist (usually /etc/hosts.deny) or as a rule in the firewall. The system subsequently blocks any further log-in attempts from blacklisted remote IP addresses.

The distributed method prevents the tools from flagging attackers after only a few log-in attempts. Depending on the scale of the distributed attack, several thousand attempts to log into an account can be made. The attacks are suspected to be carried out by botnets.

One measure to prevent the attacks is to reassign the SSH port. However, it can't be ruled out that attackers may perform a port scan and redirect the bots to the reassigned port before launching future attacks. As an alternative, users should consider cryptographic keys for SSH authentication. "

On my PLUG listed people seemed to list each of the anti-brute force SSH tools listed above pretty equally even though the article stated that they weren't all that effective.

No expert, but you would definitely have to watch the file size, network utilization, and the cpu usage and place some cleaning & some upper bounds on them with something like tripwire. Otherwise the brute force attack might turn into a DDOS.


xor

[Gadsden]

Re: Brute force SSH attack confounds defenders

Any combo of a program such as Fail2Ban, DenyHosts, etc, moving the port, firewall rules, and using keys should take care of most of the problems from bots. Targeted attacks are a different story.. but at least they will be noisy enough that you will know someone is actually targeting you.

[valkyrie]

Re: Brute force SSH attack confounds defenders

Any combo of a program such as Fail2Ban, DenyHosts, etc, moving the port, firewall rules, and using keys should take care of most of the problems from bots. Targeted attacks are a different story.. but at least they will be noisy enough that you will know someone is actually targeting you.

Nice catch Che.

Targeted attacks can only be dealt with by being attentive and putting them on a ban list...
It's called human intervention.

Regards,

valkyrie
__________________________________________________ ________________
sapere aude

[xor]

Re: Brute force SSH attack confounds defenders

I've done some further reading on this subject and would also like to summarize what I've read here as well as other places:

Effective Steps To Prevent Distributed Brute Force SSH Attacks:

Use Public Key Distribution with DNSSEC.
Change Default Ports.
Strong Passwords.
Program such as Fail2Ban, DenyHosts, etc,
Strong Firewall & Response Rules
Log/System Vigilance

Everyone agree or care to add...?

xor

[shrdlu]

Re: Brute force SSH attack confounds defenders

I've done some further reading on this subject and would also like to summarize what I've read here as well as other places:

Effective Steps To Prevent Distributed Brute Force SSH Attacks:

Use Public Key Distribution with DNSSEC.
Change Default Ports.
Strong Passwords.
Program such as Fail2Ban, DenyHosts, etc,
Strong Firewall & Response Rules
Log/System Vigilance

Everyone agree or care to add...?

I certainly don't agree. While DNSSEC is important, and is something that should happen, it has absolutely nothing whatsoever to do with any SSH attacks, whether distributed, brute force, or kid down the street. Changing the default port is a stop gap measure, and will only slow down attackers. Strong passwords will keep the account from being compromised, but have nothing to do with stopping the attacks.

Until botnets are brought down, this will continue to be a problem.