"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?
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.
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...
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).
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
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.]
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.
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.
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.
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
- 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!
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.
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.
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.
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).
[+] [-] mikestew|12 years ago|reply
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?
[+] [-] sucuri2|12 years ago|reply
thanks,
[+] [-] peterwwillis|12 years ago|reply
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.
[+] [-] cenhyperion|12 years ago|reply
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.
[+] [-] swinglock|12 years ago|reply
[+] [-] Osmium|12 years ago|reply
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...
[+] [-] voidlogic|12 years ago|reply
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).
[+] [-] erhardm|12 years ago|reply
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
[+] [-] andrewcooke|12 years ago|reply
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.]
[+] [-] JshWright|12 years ago|reply
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.
[+] [-] wglb|12 years ago|reply
I think it is a good idea.
It is the expectation that this is enough that is the bad idea.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] Father|12 years ago|reply
[1]http://www.cipherdyne.org/fwknop/docs/faq.html#fwknop
[+] [-] antocv|12 years ago|reply
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.
[+] [-] astrodust|12 years ago|reply
[+] [-] rsync|12 years ago|reply
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|12 years ago|reply
Would it fairly secure to setup a VPN service, connect via VPN, and then SSH in over the VPN connection?
[+] [-] Hello71|12 years ago|reply
Sounds familiar.
[+] [-] D9u|12 years ago|reply
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|12 years ago|reply
[+] [-] conformal|12 years ago|reply
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|12 years ago|reply
What happen when you lose your key? How do you backup your key?
[+] [-] Hello71|12 years ago|reply
(Oh, and PasswordAuthentication is off too.)
[+] [-] tacoman|12 years ago|reply
[+] [-] bentcorner|12 years ago|reply
[+] [-] pbsdp|12 years ago|reply
- 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|12 years ago|reply
[+] [-] mikegioia|12 years ago|reply
[+] [-] rogerbinns|12 years ago|reply
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.
[+] [-] tcoppi|12 years ago|reply
[+] [-] JoachimSchipper|12 years ago|reply
[+] [-] gwu78|12 years ago|reply