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

Re:why are passwords even allowed?

[miknix]

IMHO if the passwords are strong enough there is nothing to worry about, unless you get pissed off with flooded log files and the waste of bandwidth.

None of my systems allow passwords via ssh

Exactly, using public key authentication and disabling PAM/Password authentication solves the problem.

and I run log-guardian.pl to "3 strikes - you're out" the idiots who do the brute-forces by putting them into iptables

sshguard is nice too, they will be firewalled in no time. (watch out for DoSs though)

However, it is not just ssh. Http and servers also suffer a lot from automated breakin attempts.
Anyway.. I'm glad services running on port 22 are not in the same security level of services in 23,137 and 138. Otherwise it would be the holocaust!!

Re:why are passwords even allowed?

[palegray.net]

I don't allow password-based logins either (SSH keys only), allow SSH only from specific IP addresses, and I use fail2ban across all services that involve any kind of authentication (mail, ftp, http auth, etc). I've got it set to "two strikes and you're out"; every day I still get hundreds (some days thousands) of IPs banned in the logs. It's pretty sad.

Re:why are passwords even allowed?

[timmarhy]

passwords are still the most portable lightweigth authentication method out there, that's why. I had a system that got caught by this when a user with shell access set a weakish password. the user was sandboxed with only a limited whitelist of applications they could execute, so no harm done, but i did log all of the bot's attempts and the IRC channel it connected to along with passwords to other bots. it was very interesting to take the attack a part, at it's core it runs a simple dictionary attack and once it's in attempts to launches the same attack on the root password (no chance mine is 9+ random characters), plants a trojan in /temp (which failed in my case) and then connects to an IRC channel and awaits instructions which were pharsed using a simple perl script (which also failed). it then starts scanning for other victims using another perl script.

the activity on the channel indicated brazilian hackers. the thing that suprised me the most though was the amaturish and fragile nature of the process, instead of insulating the whole package so it could operate in a sandbox it atcually relied heavily on installed dependancies which i suspect means it was targeting the default install of one linux distro.

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

Re:Oh...

[MichaelSmith]

[puts shotgun down]

Don't be so hasty. There are real people herding the zombies.

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.

Re:Protect yourself

[GaryOlson]

Use VPN. Although it may seem redundant, SSH thru a VPN tunnel does provide a secondary access method which is secure.

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.

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.

Re:iptables goodness

[wytcld]

Which means this won't work, since what I see in the logs (at least in the last go-round with this stuff) is one attempt per remote IP, yet a coordinated distributed dictionary attack. What we need is a ruleset that properly spots this attack pattern, then locks down port 22 entirely except for defined, fixed-IP administrative exceptions, just if there is any pattern of failed attempts over a longer period.

In a slightly-different recent case, I saw someone get ahold of an ftp login. The uses of that login were one-off per remote IP. The IPs were in Ukraine, Russia, China, Texas ... with hours between successive attacks. From what was attempted on the logins, it was obviously a generic attack, not well-directed at the particular server. Quite likely an infected client system divulged the login to the botnet that infected it, and the botnet then focused the distributed attack. As with ftp, so with ssh. They don't want you to even notice it in the logs. Each IP will be used for one transaction attempt with you, spaced hours apart.

We need tools to spot these slow-moving distributed attacks. The single bad login attempt needs to be correlated with others from completely different IPs, over a span of days, not just minutes.

Post your banlist

[UnRDJ]

I get about 5 of these a day, on a relatively small site. I wrote a small shell script out of sheer boredom that parses hosts.deny and gives me country and hostname info. Here's the output from the past week or so. It seems to confirm that most of these are from public isps overseas.

117.21.249.75 CN, China
121.166.163.142 KR, Korea, Republic of
122.128.36.3 KR, Korea, Republic of
189.19.245.182 BR, Brazil 189-19-245-182.dsl.telesp.net.br.
200.111.157.187 CL, Chile
201.6.124.155 BR, Brazil c9067c9b.static.spo.virtua.com.br.
202.229.120.74 JP, Japan
203.125.51.23 SG, Singapore
207.5.149.188 US, United States 149-188.suscom-maine.net.
211.87.224.190 CN, China
211.99.203.168 CN, China
216.164.162.155 US, United States 216-164-162-155.pa.subnet.cable.rcn.com.
217.219.67.86 IR, Iran, Islamic Republic of
218.241.177.241 CN, China
219.121.10.35 JP, Japan m010035.ppp.asahi-net.or.jp.
221.3.131.110 CN, China
61.184.136.164 CN, China
61.191.53.99 CN, China 99.53.191.61.broad.static.hf.ah.cndata.com.
77.79.88.247 TR, Turkey reverse-77-79-88-247.grid.com.tr.
80.179.149.122 IL, Israel 122.sharatim.co.il.
82.165.27.220 DE, Germany p15173261.pureserver.info.
83.19.20.66 PL, Poland byq66.internetdsl.tpnet.pl.
84.53.78.183 NL, Netherlands 84-53-78-183.wxdsl.nl.
87.197.110.47 SK, Slovakia static-dsl-47.87-197-110.telecom.sk.
99.53.191.61 --, N/A adsl-99-53-191-61.dsl.mtry01.sbcglobal.net.
200.219.194.74 BR, Brazil static.200.219.194.74.datacenter1.com.br.
202.190.177.144 MY, Malaysia
164.77.195.60 CL, Chile
89.119.5.106 IT, Italy 89-119-5-106-static.albacom.net.
221.154.206.233 KR, Korea, Republic of
218.208.91.111 MY, Malaysia
65.120.74.22 US, United States
210.185.64.195 AU, Australia 210-185-64-195.intrapower.net.au.
202.168.58.111 AU, Australia 111.58.168.202.static.comindico.com.au.
85.25.71.36 DE, Germany loft1551.serverloft.de.
193.136.39.26 PT, Portugal genid.dcc.fc.up.pt.
150.146.40.173 IT, Italy mspasiano.cedrc.cnr.it.
221.194.128.66 CN, China
82.135.192.72 LT, Lithuania 82-135-192-72.static.zebra.lt.
80.10.250.17 FR, France
207.28.220.1 US, United States voyager.iavalley.cc.ia.us.
164.77.208.198 CL, Chile
38.107.141.131 US, United States host-38-107-141-131.mtl.net.vexxhost.com.
222.218.156.41 CN, China

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)

Re:My server got attacked last Thursday

[RzUpAnmsCwrds]

Um. You realize, of course, that remote desktop is a lot less secure than ssh, right?

Remote Desktop uses TLS and X.509 certificates, so it's not exactly trivial to crack. It's easily as secure as SSH using password-based authentication. It's definitely *more* secure if your users never bother to actually check unknown server keys.

Now, compared to SSH using only key-based authentication, Remote Desktop isn't as secure. Unless you use smart cards for authentication with Remote Desktop, which are probably more secure than having your private key stored on your computer. Unless it's encrypted with a strong passphrase. Unless your computer has been rooted and has a keylogger.

Bottom line? Both systems can be plenty secure. It's all in how you configure and use them.

Passwords are a terrible idea

[betterunixthanunix]

"IMHO if the passwords are strong enough there is nothing to worry about"

The problem is that most users are not capable of choosing a strong password. Even when you try to enforce policies about minimum password strength, users will manage to choose weak passwords; aside from the world's most common password (password1), there are plenty of people who use their own username as a password -- and requiring non-alphanumeric symbols won't stop them: jane123 will just becomes j@ne123. Minimum password lengths won't do it either, since the users will either write their password down (not an issue for botnets, but certainly an issue for high profile targets) or just come up with something that is easily guessed (abc123abc123).

Public key authentication is better but not by much. The real issue with it is that users do things like not having a passphrase for their private key (which is even more convenient than a weak password) and making copies of that key everywhere that they want to log in from (some might even carry the key around on a thumb drive). Public key authentication will solve the problem of distributed brute force attacks, but it does not really solve the problem of users having their accounts compromised by a determined adversary.

Assuming that your system is high profile enough to be worth the expense, you would really want to use a one-time password device. If the device is stolen, you have a problem, but beyond that there is not much an adversary can do. You can even mitigate the problem by requiring check-ins -- a user must login at a certain time, so if their device was stolen they will be forced to call helpdesk and report the problem.

Of course, it really depends on your security needs. None of the systems I administrate are high profile enough that I am worried about anything other than a distributed brute force attack, so public key authentication is good enough (an attacker who wanted to take over some Linux servers for his nefarious deeds could find an easier target with equal computing power, and the data on the disks is just academic research which will be published anyway).