Observations from two weeks of SSH brute force attacks

http://www.lightbluetouchpaper.org/2012/01/25/observations-from-two-weeks-of-ssh-brute-force-attacks/

by bensummers • 14 years ago

132 53 14 years ago

rlvesco72• 14 years ago

I've been running a similar experiment. And noticed similar things as the author.

However, I decided to run an additional experiment to contact Amazon since the IP was originating from an EC2 instance. Amazon contacted me after I filed an abuse report and said they were investigating.

A week goes by and I'm still getting hammered. So I email Amazon and asked when it will be resolved. No response. So I email again, again, and again. I finally get a response saying they have resolved it, but I'm still getting hammered from the same IP address.

So I email them once more asking - what is it exactly you have resolved?

No response.

I presume it is not in Amazon's best interest to resolve such issues as long as people are paying for their instances....

etherealG• 14 years ago

while that might be true, what's happening I'm quite sure can be proven to be malicious in court.

I don't like the idea that companies can turn a blind eye to illegal activity just cause they're getting a cut of the resulting profits.

lbotos• 14 years ago

It upsets me to hear this. I always wondered how Amazon handled abuse on EC2 as it's an insanely large service. At some point it has to become an issue? Does anyone have any experience with other types of abuse on EC2?

munin• 14 years ago

this has been a problem with AWS/EC2 for the last four/five years (since its creation): http://www.gossamer-threads.com/lists/nanog/users/105399

jacobcruze• 14 years ago

That is always the most difficult part for me when trying to get these issues resolved - the legal side is complicated and I don't have the bankroll to get lawyers..

param• 14 years ago

One of my linode servers was compromised and was used to originate such attacks. Linode proactively shut down the machine after a 24 hr notice period.

Unfortunately, I wasn't expecting this, so I missed their email and only realized the problem once my linode was offline.

I wouldn't be thrilled about either linode OR amazon

aptwebapps• 14 years ago

The Internet at large, on the other hand, would be quite happy with Linode in this particular instance.

Was there some other way they should have contacted you?

radimm2• 14 years ago

Just move your SSH off the port 22, hide it behind another instance and/or use fail2ban. 99% of problems with SSH scans/attacks sorted

yock• 14 years ago

Or just disable password-based authentication. These "attacks" are little more than log spam and are meant to prey on systems that host novice users with weakpasswords. Require PKI and the log spam goes away.

radimm2• 14 years ago

sure, I hope nobody is using password based authentication for SSH anyway :)

roqetman• 14 years ago

I agree - I did this a long time ago; while it's fun to go through logs sometimes, I prefer to weed-out the general bombardment. My hits dropped from about 90 a day to 0 (after 6 months).

nvarsj• 14 years ago

Or better yet, don't run SSH at all. Leave it to the pros.

I had an experience about a year ago on one of my home servers that convinced me of this. It was a Debian machine that I kept religiously up to date (daily cronjob and manual checking). It only had an external SSH port, I used log2ban, and disabled all logins except for one non-root user.

I got the common ssh brute force spam. Then one day I happened to be checking logs, and noticed rootkit logs in the /root directory. My server had been hacked! Fortunately whoever had broken in had completely botched it and left traces all over the system. It looked like they had given up at some point, despite having root access.

I later discovered that the attacker had used a 0-day openssh exploit that had been released that very morning. For that time period of 24-48 hours between release and fix, my server had been hacked. I only wonder how many other servers were hacked by skilled people that didn't leave evidence behind.

So morale of the story - you can't secure anything that is publicly facing on the internet. And if you really need to do it, it requires constant vigilance, DMZs, and all that other stuff that is not worth it unless you're being paid.

hackermom2• 14 years ago

In your specific case, this wouldn't have happened if your SSHd had listened to something else than port 22.

fjarlq• 14 years ago

What exploit was it specifically?

sehugg• 14 years ago

You could also set up your security group such that incoming 22 is denied by default, and open it up to individual IPs on-demand using a script like this:

  MYIP=`curl http://automation.whatismyip.com/n09230945.asp`
  ec2-authorize $SECGROUP -P tcp -p 22 -s $MYIP/32

flpmor2• 14 years ago

I think that a more reasonable explanation could be that the attackers were careless about building the dictionary. If it's built by parsing files and you feed the wrong file or the parser does not work correctly you end up with a dictionary with lots of bogus entries. That seems a simpler explanation than:

"The best guess is that these passwords were collected from an unhashed password database, or from a trojaned SSH server or client."

"This might be due to the brute force tool not properly interpreting comments in the dictionary file, or the attacker not understanding the comment notation"

khafra• 14 years ago

Interesting idea. Assuming competence on the part of your attacker isn't as dangerous as assuming incompetence, but it can be just as mistaken.

flpmor2• 14 years ago

It could be more haste than incompetence. Anyway, if you think about massive brute force attacks like this, they are 'silly' easy no-brain attacks more likely to come from script kiddies who downloaded a tool someone else wrote than real attackers.

rdtsc• 14 years ago

What is with Romanians? Most of the metadata sent (see at the bottom) is in Romanian.

peterwwillis• 14 years ago

A long time ago I used to have a general purpose server on a DSL line with port 22 open. I thought everything was fairly secure, patched up, etc... I never thought brute forcers would be able to guess one of my accounts (which was a friend's account actually). The kicker? The password was the username. I found out about the rootkit a few days after they got in. I tell ya, kids these days just don't know how to hide a backdoor.

A really good port knocker is your best defense against rogue attackers of an external service (because there is no defense against a 0-day). For an iptables-supported system I recommend Knockknock by Moxie Marlinspike (http://www.thoughtcrime.org/software/knockknock/).

lloeki• 14 years ago

For brute forcing, without resorting to port knocking, fail2ban works well and has a pluggable system to handle more than ssh.

rlvesco72• 14 years ago

Does fail2ban work against brute force distributed attacks?

I've noticed a few attacks that seem to be orchestrated from the same people but using different IPs.

acdha3• 14 years ago

Or use only public-key authentication. I've run many internet-exposed servers for years without problems or kludgy obscurity measures like port knocking simply by disabling all forms of password authentication. This is faster, easier and has the advantages of not requiring non-standard client software, being observable by an attacker on the same network, and avoids the sort of rote password entry which causes mistakes and discourages long, complex passwords.

Nick_C• 14 years ago

With public key only authentication, how does a user get their public key on to the server in the first place?

I ask because I have two servers, one I am a client at DreamHost and I can't configure their sshd daemon, the second is my own VPS where I am root.

hackermom2• 14 years ago

Sheesh! Let your SSHd listen to something else than the standard port already!

olalonde• 14 years ago

Or don't use password based authentication...

mhitza• 14 years ago

Heh, those passwords are in Romanian

TiganilAFloriNTeleormaN - Gypsies at Florin in Teleorman

Fum4tulP0@t3Uc1d3R4uD3T0t - Smoking can kill awfully bad

Observations from two weeks of SSH brute force attacks

Related Stories