SSH Brute Force – The 10 Year Old Attack That Still Persists
blog.sucuri.net
blog.sucuri.net
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?
thanks,
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.
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)
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.
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...
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
I would guess that if you enable debugging it will show some identifiable information, I never had to debug it.
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).
I think it is a good idea.
It is the expectation that this is enough that is the bad idea.
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.]
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?
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.
if this can be made to work for ssh when using system passwords that would be very cool. but to my (inexpert) eye it seems unlikely (without relying on a trusted client). do you have a description for that case?
the problem, in short, is that the password is not shared. the server does not know it - it only knows the hash. and the hash is not sufficient as a shared secret.
> SRP does not expose passwords to either passive or active network intruders, and it stores passwords as a "non-plaintext-equivalent" one-way hash on the server.
but i get the impression that still doesn't mean that ssh can be made to work with system passwords without transmitting them (over an encrypted channel). i don't understand why - maybe srp requires a particular kind of hash?
ah yes - this answer http://security.stackexchange.com/questions/23821/srp-can-th... gives some details.
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.
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.
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.
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.
Would it fairly secure to setup a VPN service, connect via VPN, and then SSH in over the VPN connection?
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.
Sounds familiar.
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.
allowing password-based auth in sshd is plain stupid. _always_ use pubkey auth, it's a 1-line change in /etc/ssh/sshd_config.
What happen when you lose your key? How do you backup your key?
If you're super paranoid, copy it to some physical media that you can store securely.
Also note that you can have multiple keys, potentially one per device (useful in case a device could get stolen).
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh limit: up to 1/min burst 2 mode srcip
(Oh, and PasswordAuthentication is off too.)
-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- 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!
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.
- 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.
[1]: http://www.daemonology.net/blog/2012-08-30-protecting-sshd-u...
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.
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.
That said, both are very good, and if you do want a full VPN there's a lot to recommend OpenVPN.