SSH Brute Force – The 10 Year Old Attack That Still Persists

http://blog.sucuri.net/2013/07/ssh-brute-force-the-10-year-old-attack-that-still-persists.html

by cubictwo • 13 years ago

61 63 13 years ago

blog.sucuri.net

astrodust• 13 years ago

What sane person would allow password authentication on their servers? Turn it off.

Osmium2• 13 years ago

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

erhardm2• 13 years ago

I still think that it's a good idea to change the default port for sshd, even if you don't let root to login and use public key auth and fail2ban. Why? Because this "obscurity" helps keeping false possitives to a reasonable low number, so you can actually see if there's a tageted attack or not.

If I see a auth failure "root"-"123456" I instantly know that's not a targeted attack, it will unnecessary fill my log files that will add with time and become a burden to audit my systems, which at some point I either don't do it thoroughly or any at all.

SELinux takes care of controling which application could open outbound ports, so if your box is properly configured, there are other ways to reduce the impact if the box is exploited

andrewcooke5• 13 years ago

do (can?) auth failures display passwords? if so, is that a good idea? people (ie me) sometimes enter the wrong, but valid password. having that logged somewhere seems like a bad idea.

voidlogic• 13 years ago

I agree that changing the port is not a great security measure in theory and I think it should be last of a large number of things a person does to secure SSH.

BUT- I worked at a company a while back that had fail2ban notify us when by E-mail when it banned people. Changing the SSH ports dropped the bans per 6 month from 80-60 to 1-2. So while its certainly not the only thing you should do, there is something to be said for obscurity (in addition to existing real security of course).

bradleyland2• 13 years ago

Not to mention the hardware resources. Prior to changing our SSH port, the fail2ban process was #3-5 in terms of CPU time on many of our boxes. Changing the SSH port puts it out of contention for even the top 10.

wglb• 13 years ago

Changing the port number can boost security if it makes it easier to scan the log for attempts.

I think it is a good idea.

It is the expectation that this is enough that is the bad idea.

andrewcooke5• 13 years ago

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 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.]

Osmium2• 13 years ago

Huh. I hadn't actually thought that the protocol itself could protect you (I only left my comment based on what I'd read elsewhere; I don't know anything about it otherwise).

So hypothetically speaking, if the protocol did protect your password from being stolen, what would be the actual threat of a piece of malware specifically pretending to be SSH?

Hello716• 13 years ago

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.

prutschman• 13 years ago

There exist ways for a client and server to convince each other they share a secret (such as a password) without giving an adversary enough information to infer the secret. Here is one such: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Dylan16807• 13 years ago

Even if it's not possible to improve the security of a single-server system, there is definite room for improvement in the real world.

Assume for a moment that you have to transmit the password to the server instead of using proof of knowledge algorithms. This makes the server a potential point for stealing the password. This is of negligible risk in theory, because the server has access to itself by definition. But in the real world people reuse passwords. So in the real world you can improve security by hashing what the user types with server-specific data (public key?) and using that as the server-specific password. Then someone that can capture the password can only log on to that specific server.

Father• 13 years ago

Additionally you could also use something like fwknop[1]. It opens the ssh port for your ip when you need it and closes it after a preset time has passed.

[1]http://www.cipherdyne.org/fwknop/docs/faq.html#fwknop

JshWright2• 13 years ago

Changing the port is still a worthwhile thing to do in many cases.

Military tanks aren't painted green because green paint is more bulletproof, they use green because hot pink tanks get shot at more.

Changing the port isn't armor, it's camouflage. Camouflage is still a useful thing.

Your point about not using a port north of 1024 is solid advice.

antocv2• 13 years ago

above port 1024 malware...

Im using this https://github.com/stealth/sshttp to run it on port 443.

The other port it actually runs on is firewalled off from outside.

pbsdp4• 13 years ago

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!

sucuri22• 13 years ago

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• 13 years ago

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).

pbsdp4• 13 years ago

The difference is that exposing OpenVPN code allows you to separate remote access from your production services, both reducing the total attack surface and providing defense-in-depth.

On top of which, OpenVPN has actually had fewer security vulnerabilities released than OpenSSH, and HMAC validation enormously restricts the surface area of exposed code as compared to OpenSSH.

mikegioia• 13 years ago

I don't understand how OpenVPN/PKI is any better than running SSH externally on a different port and strictly using key based auth.

pbsdp4• 13 years ago

OpenVPN:

- Exposes less code to attack

- Can be run on a single machine, distinct from your production systems, where compromise will only result in a compromise of VPN communications, not of an actual production machine on which your production data/processes exist.

tcoppi• 13 years ago

One thing you should keep in mind when doing this is all traffic will be routed through the gateway, so if you say had a home desktop connected with a VPS running as the OpenVPN server, connections routed to the home desktop will go through the VPS first. This can be a significant bandwidth/latency addition, depending on your needs. Obviously much less significant if everything will be physically colocated.

DavidHogue2• 13 years ago

OpenVPN can be set to route only certain IP blocks to the tunnel. I sometimes do prefer to route everything over the vpn though, especially at coffee shops that filter specific ports.

rogerbinns• 13 years ago

You can (and probably should) setup ssh on one edge gateway and then ssh from that machine to further internal machines. ssh config files make it easy to make multiple steps transparent.

I expose ssh externally on the edge gateway (but can't provide evidence for sanity). The major attractions over a vpn is a limit in what traffic gets sent on the ssh connection - by default just the shell, and whatever port forwards are needed. vpns end up forwarding DNS traffic and a bunch of other gunk. They can also expose the client machines to unintended traffic from the remote end.

JoachimSchipper2• 13 years ago

I have considerably less faith in OpenVPN than you do. The "bastion host" concept is fine, but you can do this with SSH, near-transparently even (using ProxyCommand).

pbsdp4• 13 years ago

Can you expand on why? OpenVPN has long been an example of solid development (and crypto) practices.

As far as the bastion host, you need an actual VPN to do more than forward SSH connections. For instance, connectivity to your LDAP server, internal web services, etc.

Port forwarding gets you part of the way there, but it's inconvenient to use with SSL, requires using weird local port numbers when connecting to services, etc.

SSH does have VPN support via tun/tap, but it's not nearly as functionally complete as OpenVPN, and you still have the entire SSH authentication path exposed to the world.

gwu78• 13 years ago

Is OpenVPN, both the clients and the server, fully open source? Can we look at each and every line of code?

mikestew• 13 years ago

"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?

sucuri22• 13 years ago

Yes, SSH keys is the recommended option. The post has been updated there to state that.

thanks,

cenhyperion• 13 years ago

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.

Argorak• 13 years ago

More importantly, it is far easier to revoke on a person-to-person basis even on the same account.

If you use password auth and some accounts have a password that is shared knowledge (root, anyone?), you have to change all passwords once one persons permissions change.

In practice, revoking public keys is a problem for many companies already as I found out when my private key was stolen a while ago. (on an encrypted drive, but paranoia is paranoia)

finnw• 13 years ago

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.)

swinglock2• 13 years ago

Still, any password that isn't very weak will do just fine, especially if root can't log in directly.

peterwwillis• 13 years ago

When you're traveling or just for convenience's sake. You might not always have your key on hand, or may use devices/apps or computers that make it difficult to load one.

If your password is strong enough and isn't reused, most attacks are prevented. You could in theory eyeball a really long complex password but it would be quite difficult. Keys are mostly useful for multiple-device identity management and passwordless login using an agent.

Hello716• 13 years ago

  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• 13 years ago

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

Hello716• 13 years ago

  -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

bentcorner• 13 years ago

Is this per IP or for all incoming connections?

Hello716• 13 years ago

"srcip"

conformal• 13 years ago

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• 13 years ago

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?

JshWright2• 13 years ago

For most cases, gpg encrypt it and stick it in Dropbox.

If you're super paranoid, copy it to some physical media that you can store securely.

MattJ100• 13 years ago

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).

macNchz• 13 years ago

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

rsync• 13 years ago

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• 13 years ago

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?

antocv2• 13 years ago

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.

Hello716• 13 years ago

Port knocking: sending a stream of special packets to verify that the user is trusted.

Sounds familiar.

D9u• 13 years ago

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.

SSH Brute Force – The 10 Year Old Attack That Still Persists

Related Stories