
Observations from two weeks of SSH brute force attacks - bensummers
http://www.lightbluetouchpaper.org/2012/01/25/observations-from-two-weeks-of-ssh-brute-force-attacks/
======
rlvesco7
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....

~~~
param
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
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?

------
radimm
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

~~~
nvarsj
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.

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

~~~
Florin_Andrei
s/wouldn't have happened/would've been much less likely/

------
peterwwillis
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
For brute forcing, without resorting to port knocking, fail2ban works well and
has a pluggable system to handle more than ssh.

~~~
rlvesco7
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.

~~~
nuclear_eclipse
It doesn't specifically target distributed attacks, but I'm not really sure
how something like that could know whether incoming requests are part of a
botnet or ligitimate logins.

------
flpmor
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."

or

"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
Interesting idea. Assuming competence on the part of your attacker isn't as
dangerous as assuming incompetence, but it can be just as mistaken.

~~~
flpmor
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.

------
mhitza
Heh, those passwords are in Romanian

TiganilAFloriNTeleormaN - Gypsies at Florin in Teleorman

Fum4tulP0@t3Uc1d3R4uD3T0t - Smoking can kill awfully bad

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

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

~~~
olalonde
Or don't use password based authentication...

