
SSH Brute Force – The 10 Year Old Attack That Still Persists - cubictwo
http://blog.sucuri.net/2013/07/ssh-brute-force-the-10-year-old-attack-that-still-persists.html
======
mikestew
"As for protecting your self against these, you need to use strong and good
passwords..."

I went back to the top to see when this was posted...today. I'm no expert on
securing a server, but I thought the common thinking now was to just turn off
password auth. The post itself says that all it takes is one weak password to
be compromised.

Using keys is ever-so-slightly less convenient at setup, but negligibly so.
Works on any device I have. Is there a reason one would continue to use
passwords?

~~~
cenhyperion
>Using keys is ever-so-slightly less convenient at setup

And it's easier once it's setup. I don't have punch in a password any time I
need to make a server change.

~~~
finnw
Don't forget that makes you more vulnerable to malware on the client, which
now has easy access to your keys, and your known_hosts file (which gives the
attacker a convenient list of servers to attempt to log into using those
keys.)

~~~
mjn
Yes, this is why having a passphrase on your key is recommended. The idea is
not to use keys _instead_ of passwords, but _in addition to_ : the password
protects the private key locally, which is used to authenticate to the server.
However that seems to be uncommon practice.

------
Osmium
There are lots of good guides online on how to protect yourself from this
(disable password-based auth, or use 2-factor auth, Fail2ban etc.), but
there's one piece of advice that crops up a lot that is probably a bad idea,
and that's changing the SSH port. This can give (at best) a false sense of
security and (at worst) actually reduce security if you choose a port number
above 1024, because then malware could pose as SSH without requiring root
access and then steal your password once you've entered it.

Just thought it was worth mentioning because I recently went through all this
myself to try and secure a Raspberry Pi and it was news to me...

~~~
andrewcooke
_steal your password_

i had always assumed that the protocol somehow protected your password, but
reading the spec at
[http://www.ietf.org/rfc/rfc4252.txt](http://www.ietf.org/rfc/rfc4252.txt)
that's not the case (and i've pretty much convinced myself it's not possible
to do better).

learn something new every day...

[apart from the reference above, someone else here claims to be logging these
things.]

~~~
Hello71
With "password" authentication method, the password is not transmitted to the
remote server. (AFAIK)

However, all modern sshds (AFAIK, at least OpenSSH) default to (publickey,
keyboard-interactive). As the name says, keyboard-interactive sends your
keystrokes, one at a time (bar buffering) to the remote server.

This is required, for example, when using PAM, as PAM requires the actual
authentication key.

~~~
andrewcooke
about password auth - you're wrong (AFAIK). i even gave a reference in my
original post. didn't you bother to check it?

~~~
Hello71
I am wrong. No.

------
astrodust
What sane person would allow password authentication on their servers? Turn it
_off_.

------
rsync
I am very surprised that the OP, and nobody in this thread, has mentioned port
knocking.

You are absolutely better off / more secure, with port knocking enabled. The
scans never touch your sshd, because your server does not even answer port 22.
As far as the outside world is concerned, you _don 't_ run an sshd.

On my own systems, I set up port knocking, I delete the allow rule for the IPs
I knocked from every 24 hours (so fresh knocking is needed every day, and I
don't leave a trail of "open" IPs as I travel the world) and my .login script
spits back at me the current days list of "knocking IPs" so I can immediately
note if someone else is knocking.

~~~
Osiris
The problem is that it's harder to setup and is less convenient to use. Can
you point to any guides that make it simple to set up port knocking?

Would it fairly secure to setup a VPN service, connect via VPN, and then SSH
in over the VPN connection?

~~~
antocv
Its easier to go the VPN route than port knocking, but the vpn then ssh is too
tinfoil hat for even my taste.

As someone else mentioned, just run it on another port than 22, like 53 or
109, and youll get 99% less brute forcing attempts, and dont use passwords as
those in the list, and disable user root to authenticate at all.

If you're still paranoid about the minor brute forcing attempts left then add
the iptables rule to limit connection attempts to 1/min. You're still
paranoid? For what really? Port knocking wont help out at this level of
paranoia. Hrm, security awareness. Its just not worth the hassle.

If you already have OpenVPN setup, then its easy to put the ssh to listen only
on the tun interface the vpn server has opened.

------
D9u
I usually just limit SSH connections to one of my own static IP addresses, as
well as disable password authentication and implement PSK.

At first I was shocked by the amount of intrusion attempts my servers were
logging, but as time goes on I see that no attempts have yet been successful,
so these sorts of intrusion attempts have probably made me complacent. (never
a good thing)

That said, I found the article to be lacking in listing mitigation
alternatives, such as those posted here in the comments.

------
macNchz
It's amazing how quickly the brute force attempts start rolling in if you turn
on SSH with password authentication. Last year I had it on for a bit on my
home computer and logged thousands of attempts with the username 'initech'.
Thank god I went to work for Intertrode!
[http://i.imgur.com/6lqXa.png](http://i.imgur.com/6lqXa.png)

------
conformal
seriously, password-based auth... have ppl not heard of public key
authentication?

allowing password-based auth in sshd is plain stupid. _always_ use pubkey
auth, it's a 1-line change in /etc/ssh/sshd_config.

~~~
dwild
Can they really bruteforce a 12 characters password? I don't think so...

What happen when you lose your key? How do you backup your key?

~~~
MattJ100
The same way you back up all your other important and private files? That is,
frequently and securely.

Also note that you can have multiple keys, potentially one per device (useful
in case a device could get stolen).

------
Hello71

      ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh limit: up to 1/min burst 2 mode srcip
    

Have fun brute forcing at 1 connection per minute.

(Oh, and PasswordAuthentication is off too.)

~~~
tacoman
Can you paste the config line that adds this to your iptables?

~~~
Hello71

      -A PORTS -p tcp -m tcp --dport 22 -m hashlimit --hashlimit-upto 1/min --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name ip4-ssh-brute -j ACCEPT

------
pbsdp
What sane person exposes SSH externally?

\- OpenVPN takes only minutes to set up

\- There are easy to use GUI clients for all major desktops (Windows, Mac OS
X, Linux) and phones (Android, iOS)

\- It supports running with zero privileges (chroot+setuid) since it only
needs to forward packets to /dev/(tun|tap), which does not require privileges
after the device has been opened.

\- It limits your compromise exposure to only one edge gateway (you can put
any number of machines behind a single dedicated gateway). If the gateway is
pwned, you still have the defense-in-depth of internal SSH, internal encrypted
comms, etc.

\- Supports HMAC validation of incoming data to avoid any complex processing
(and thus exposure of bugs) of packets from users that don't have the shared
HMAC key. This means that _only_ the HMAC code is exposed to untrusted users.

\- Supports public key +/ password authentication.

There's _no_ reason to expose SSH to the public internet when you can run a
gateway that handles _only_ VPN traffic and greatly limits your attack
surface. Defense in depth!

~~~
sucuri2
You would be surprised. But to say the truth, I trust the OpenSSH code a lot
more than any VPN software that you can install to prevent direct access to
it.

~~~
achillean
It's fairly common actually, at least around 12,860,698 devices have their SSH
open to the public
([http://www.shodanhq.com/?q=port:22](http://www.shodanhq.com/?q=port:22)).

