Sheesh! Let your SSHd listen to something else than the standard port already!
Observations from two weeks of SSH brute force attacks
31–40 of 55 posts
Re: Observations from two weeks of SSH brute force attacks
#32Just 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 ch…
In your specific case, this wouldn't have happened if your SSHd had listened to something else than port 22.
Re: Observations from two weeks of SSH brute force attacks
#33Earlier 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.
I personally stand there with them (or over Skype) and ask them to show me how they manage their keys.
Most devs know how to use ssh-agent. Those who don't are really excited to learn that they can increase security without an increase in effort.
Password uniqueness, on the other hand, is something that requires continuous effort. There's an ongoing temptation to reuse the strong password that they've memorized for my server in other locations.
Like most things in security, it's a matter of layering and balance. You layer your security, and you stop at the point where the added effort doesn't justify the added security. I view the progression like this
OK: Strong passwords
Better: SSH-key authentication (much harder to brute force, not susceptible to disclosure through third-party security disclosure)
Best: SSH-key authentication with passphrase (prevents unauthorized use of private key if stolen)
Insane: SSH-key stored on external drive with imaginary super-encryption
Re: Observations from two weeks of SSH brute force attacks
#34Sheesh! Let your SSHd listen to something else than the standard port already!
Or don't use password based authentication...
Re: Observations from two weeks of SSH brute force attacks
#35A 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…
For brute forcing, without resorting to port knocking, fail2ban works well and has a pluggable system to handle more than ssh.
Re: Observations from two weeks of SSH brute force attacks
#36Earlier quoted context omitted.
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 wi…
The weak point is you still don't know what you're signing, who or what you're authenticating, etc. if you don't have a trusted display and do the entire transaction on trusted hardware. (your host may be compromised, and could show arbitrary data, proxy connections, etc.) Protecting the key does go a long way, but even with a secure passphrase input and smartcard key operations, there is risk.
The ideal, IMO, would be some secondary hardware with a limited, secure OS which lets you put specific limits on how the key is used, showing a hash or identifying details of each transaction on the secure display, prompting you to verify each. E.g. to send a payment, the amount and payee (and date/sequence number) are shown on the secure display to verify before authorizing.
Re: Observations from two weeks of SSH brute force attacks
#37Earlier 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…
"Why of course I've picked a strong password, Mr. Sysadmin!" (password is "p4ssw0rd")
"Why of course I used a passphrase with my SSH key, Mr. Sysadmin!" (nope)
Re: Observations from two weeks of SSH brute force attacks
#38Earlier quoted context omitted.
No .. but it would damn cool if such hardware existed. Does it?
Yes it does. And it's pretty cheap too. I have an OpenPGP v2 smart card and an SPR-532 smart card reader. I will be writing up how I did it on my blog at https://grepular.com/blog/ probably next week. Need to find an hour or two to write the thing up.
I picked up an OpenPGP card and reader a few months ago and love the technology. My only beef is that the reliability of the software that talks to the smartcards is awful on the Mac.
Right now, it's definitely an approach to take if you are crypto nerd -- it's not ready for regular humans.
Re: Observations from two weeks of SSH brute force attacks
#39Heh, those passwords are in Romanian
TiganilAFloriNTeleormaN - Gypsies at Florin in Teleorman
Fum4tulP0@t3Uc1d3R4uD3T0t - Smoking can kill awfully bad
Re: Observations from two weeks of SSH brute force attacks
#40Earlier 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…
"Why of course I've picked a strong password, Mr. Sysadmin!" (password is "p4ssw0rd") "Why of course I used a passphrase with my SSH key, Mr. Sysadmin!" (nope)
I'd still prefer ssh keys over a strong password. I don't know anyone who is perfect with regard to password sharing. Once you've memorized a wicked good password, there's a strong temptation to use it.
Say you've committed a really strong password to memory. One day, you find yourself setting up an account for some related service that you want to be super secure, but you're going to have to access it regularly. You decide to use your strong password. A year goes by and some hacker gains access to the said service's user database. Your super-strong password is now useless.
The great thing about ssh-keys is that the private key should be on your computer only. Generalized attacks don't go after single private keys, because you're only getting one set of credentials. If you're under focused attack, there are much easier attack vectors than trying to swipe a priv key from a dev's machine. If you can convince your dev to use passphrases on their ssh keys, you mitigate that attack vector as well.
Neither is perfectly enforceable, but using a passphrase with ssh-keys and ssh-agent is trivial. It's not perfect, but it's better than password auth.