8 ms·

Observations from two weeks of SSH brute force attacks

132 points by bensummers 15y ago

rlvesco7 15y 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 15y 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 15y 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 15y 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 http://www.gossamer-threads.com/lists/nanog/users/105399
- jacobcruze 15y 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 15y 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 15y 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?
radimm 15y 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 15y 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.
  - radimm 15y ago
    sure, I hope nobody is using password based authentication for SSH anyway :)
    - pbhjpbhj 15y ago
      Is there an active exploit? Or are you just saying that this is the weakest form of auth for SSH?
      - bwarp 15y ago
        password is the weakest form of authentication on open systems i.e. ones which you have to hand over to monkey grade users. If you have a reasonable password policy yourself, I very much doubt it will cause you any problems. I've been attacked by these for 10 years, probably totalling millions of attempts and I have a user name in their databases but due to a sensible password, nothing has got in. I tend to use PKI and keyboard interactive logins though.
    - mike-cardwell 15y ago
      And I hope nobody is using key based authentication for SSH without storing the private part of their SSH key on an external smart card only, which is unlocked by an external hardware pin pad. I was being pedantic of course. Password based SSH authentication is fine for 99% of the cases, as long as they use a "secure" password and don't leak it by writing it down or reusing it elsewhere.
flpmor 15y 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." 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 15y 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.
  - flpmor 15y 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 15y ago
What is with Romanians? Most of the metadata sent (see at the bottom) is in Romanian.
peterwwillis 15y 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/ http://www.thoughtcrime.org/software/knockknock/).
- lloeki 15y ago
  For brute forcing, without resorting to port knocking, fail2ban works well and has a pluggable system to handle more than ssh.
  - rlvesco7 15y 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.
    - nuclear_eclipse 15y ago
      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.
- acdha 15y 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.
hackermom 15y ago
Sheesh! Let your SSHd listen to something else than the standard port already!
- olalonde 15y ago
  Or don't use password based authentication...
mhitza 15y ago
Heh, those passwords are in Romanian TiganilAFloriNTeleormaN - Gypsies at Florin in Teleorman Fum4tulP0@t3Uc1d3R4uD3T0t - Smoking can kill awfully bad

132 points by bensummers 15y 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 15y 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 15y 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 15y 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 http://www.gossamer-threads.com/lists/nanog/users/105399
jacobcruze 15y 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 15y 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 15y 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?

radimm 15y 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 15y 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.
- radimm 15y ago
  sure, I hope nobody is using password based authentication for SSH anyway :)
  - pbhjpbhj 15y ago
    Is there an active exploit? Or are you just saying that this is the weakest form of auth for SSH?
    - bwarp 15y ago
      password is the weakest form of authentication on open systems i.e. ones which you have to hand over to monkey grade users. If you have a reasonable password policy yourself, I very much doubt it will cause you any problems. I've been attacked by these for 10 years, probably totalling millions of attempts and I have a user name in their databases but due to a sensible password, nothing has got in. I tend to use PKI and keyboard interactive logins though.
  - mike-cardwell 15y ago
    And I hope nobody is using key based authentication for SSH without storing the private part of their SSH key on an external smart card only, which is unlocked by an external hardware pin pad. I was being pedantic of course. Password based SSH authentication is fine for 99% of the cases, as long as they use a "secure" password and don't leak it by writing it down or reusing it elsewhere.

flpmor 15y 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." 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 15y 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.
- flpmor 15y 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 15y ago

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

peterwwillis 15y 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/ http://www.thoughtcrime.org/software/knockknock/).

lloeki 15y ago
For brute forcing, without resorting to port knocking, fail2ban works well and has a pluggable system to handle more than ssh.
- rlvesco7 15y 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.
  - nuclear_eclipse 15y ago
    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.
acdha 15y 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.

hackermom 15y ago

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

olalonde 15y ago
Or don't use password based authentication...

mhitza 15y ago

Heh, those passwords are in Romanian TiganilAFloriNTeleormaN - Gypsies at Florin in Teleorman Fum4tulP0@t3Uc1d3R4uD3T0t - Smoking can kill awfully bad