What is with Romanians? Most of the metadata sent (see at the bottom) is in Romanian.
Observations from two weeks of SSH brute force attacks
21–30 of 55 posts
Re: Observations from two weeks of SSH brute force attacks
#22Earlier quoted context omitted.
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.
"as long as they..." See, that's exactly why we don't allow password based authentication. While you can enforce strong passwords, you can't enforce that the user choose a password that is unique to your system, because you cannot know where else they may use this password. The recent Dreamhost security disclosure is a great example. What are the chances that a contractor is using the same password for a Dreamhost sh…
How do you "require" that they use a pass phrase with their key? You can tell them to do it, but it's up to them if they actually do.
Re: Observations from two weeks of SSH brute force attacks
#23Just move your SSH off the port 22, hide it behind another instance and/or use fail2ban. 99% of problems with SSH scans/attacks sorted
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.
Re: Observations from two weeks of SSH brute force attacks
#24Earlier quoted context omitted.
"as long as they..." See, that's exactly why we don't allow password based authentication. While you can enforce strong passwords, you can't enforce that the user choose a password that is unique to your system, because you cannot know where else they may use this password. The recent Dreamhost security disclosure is a great example. What are the chances that a contractor is using the same password for a Dreamhost sh…
How do you "require" that they use a pass phrase with their key? You can tell them to do it, but it's up to them if they actually do.
Why, it's simple! They just send him their private key along with the passphrase, and he tests it to make sure it works!
(I've heard worse.)
Re: Observations from two weeks of SSH brute force attacks
#25Earlier quoted context omitted.
No .. but it would damn cool if such hardware existed. Does it?
Not to my knowledge, but similar approaches have existed for a long time now e.g. RSA SecurID [0]. One day I'm going to set up my Yubikey to perform a similar purpose, but my motivation levels correlate with my paranoia :) [0] http://www.rsa.com/node.aspx?id=1156
I have a yubikey myself. The smart card method is much better though. When using a smart card, it is impossible even for the owner (who knows the access pin) to read the actual key. The crypto operations involved in the authentication take place on the card it's self. The smart card is protected by a pin, and will wipe it's self if the pin is entered incorrectly too many times. You can even use a smart card reader with a hardware pin pad built in so neither soft nor hard keyloggers can intercept it.
Re: Observations from two weeks of SSH brute force attacks
#26Earlier quoted context omitted.
How do you "require" that they use a pass phrase with their key? You can tell them to do it, but it's up to them if they actually do.
Why, it's simple! They just send him their private key along with the passphrase, and he tests it to make sure it works! (I've heard worse.)
For the sake of those who may not realise: You can take a password protected ssh key and remove it's password protection (if you know the password). And do the opposite of course (adding a password to a key without one)
Re: Observations from two weeks of SSH brute force attacks
#27Earlier quoted context omitted.
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.
No .. but it would damn cool if such hardware existed. Does it?
Our new national ID cards (called 'citizen card') here in Portugal work like that.
They have a keypair and the private part is never transmitted out of if: the card itself can (when plugged in a reader) sign and encrypt data sent to it. So it's secure even when using a public (not trusted) machine; I mean, it can spy on your connection, but it can't clone the key.
The certificate can be used in browsers to login to websites that support it or any other applications that implement the right PKCS standard.
Re: Observations from two weeks of SSH brute force attacks
#28Just move your SSH off the port 22, hide it behind another instance and/or use fail2ban. 99% of problems with SSH scans/attacks sorted
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/32Re: Observations from two weeks of SSH brute force attacks
#29A 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/).
Re: Observations from two weeks of SSH brute force attacks
#30I'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, ag…
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..