Three locks for your SSH door
ibm.com
ibm.com
On one hand, it is clearly going to be harder for a random zombie machine to find your ssh on a non-standard port that requires knocking and a particular less usual username.
On the other hand, you're breaking from your distribution's standard installation. You increase the risk of breaking on a future upgrade. You could lock yourself out, perhaps, and there's a cost associated with this. In the worst case a distribution upgrade will fix a security hole and you'll be left with it (say for example because you modded the config file, dpkg queried it, you rushed through the prompts and it got left alone).
I accept my scenario is unlikely, but it is also unlikely that someone will crack your up-to-date machine using distribution standard ssh, a secure root password and public keys for day-to-day access.
It is far more likely that someone will access your secure machine from an insecure place with a keylogger running and get cracked that way.
2. your point about "using distribution standard ssh, a secure root password and public keys" is a little moot in light of the debian ssh keygen bug? in this case you would have been better off with building ssh yourself (and keeping it up to date).
3. in any case, you are at most risk from your users. if they are compromised, you are also (public key or not).
My ~/.ssh/config basically looks like https://gist.github.com/78ec014f31c8a06f656b
…which allows me to just use "ssh server1.example.com" and "git clone foo@server1.example.com:blah/project" to access those resources without explicitly defining the port number.
---
Edit: The standard msysgit installer for Windows may look in the same place too — I haven't tried.
I only recently realized I could abbreviate hostnames in .ssh/config.
Not sure why but the idea of port knocking always seems over complex for little benefit.
http://www.fail2ban.org/wiki/index.php/Main_Page
http://denyhosts.sourceforge.net/
denyhosts has the difference that it synchronises this data amongst many hosts.
But if I'm being honest, back when I signed up with them keypairs would have been a little more difficult than working out that option for rsync.
At worst, the internet will just keep filling your logs with access attempts, none of which will actually accomplish anything.
I did recently decide to start using fail2ban though, not because I'm worried about someone hacking ssh, but because I wanted a centralized system that would monitor various forms of abuse (including obvious spammers).
It requires a little bit of kludging to do this though. :-( As packaged, it's not much more useful than a hacky shell script.
Do not allow password logins. Do. Not.
Have a method to redact keys quickly. The advice of the article becomes irrelevant. If someone gets hold of an unencrypted/crackable private key, they'll likely also have access to the secret portnumber, knock sequence and username, so nothing much gained there.
Consider the Debian PRNG flaw from a couple years ago. As I understand it, most SSH/SSL keys generated on Debian and Debian-derived boxes over a period of about two years were (rather) easily guessable. Even if you were able to redact any compromised keys as soon as this was publicly revealed, who knows how long malicious attackers may have known about it before it was made public. If your server had port knocking enabled you would have had a bit of insulation from this attack.
OpenVPN is capable of providing a much, much smaller attack surface than OpenSSH (see http://news.ycombinator.com/item?id=1665773), and can be run entirely chroot'd and setuid such that even if an attacker does compromise OpenVPN, they can not necessarily gain further access.
There seems to be a prevailing lack of understanding that bad passwords are not the only concern when using SSH. The daemon itself may be vulnerable to exploit (and in the past, it has been).
http://danielmiessler.com/study/security_and_obscurity/
Hint: Why do we camouflage tanks?
If you're just opening up SSH on your personal computer, you don't need every advantage you can get. Just make sure that your authentication is strong, and you'll be fine.
It costs something to use a port knocker. It costs something to use a nonstandard port. If you have strong authentication (say, using 2048-bit ssh certificates), it's probably not worth paying those costs. Maybe it is if you're a bank, but probably not if it's the server that hosts your blog. If you don't have that strength of authentication, it would be better to pay for the better authentication than for the port knocker and nonstandard port.
We could continue raping that metaphor, or we could just discuss whether or not putting ssh on a different port actually accomplishes anything useful.
For example: it's generally a pretty safe assumption that most remote servers have ssh running on them somewhere. If you are running scripts to find vulnerable or misconfigured ssh hosts, then it makes sense to scan the standard port and try stupid logins. In that case, if the sysadmin moves ssh to a different port, then they "protect" themselves from the various scripts out there, but then again simply having reasonable password policy accomplishes the same thing and without the hassle of having to locate ssh on a different port.
On the other hand, if you're a dedicated attacker and you want to compromise a particular system, then moving ssh to another port does squat; nmap will find it easily enough. Port knocking and/or denyhosts and/or iptables or pf will stop that easily enough, but then again, a dedicated attacker probably won't try ssh first anyway, since that's hard. Attacking something else like your web app or any of your other services, would make a lot more sense.
So, either way, running ssh on a different port is completely superfluous. While you haven't "made the armor any weaker", you also haven't made it any stronger. At all.
Because ssh is not a tank.
Difference between using usual 22 and "unusual" 24 port, 18000 attempts vs. 5 attempts over one weekend.
Seems to weed out script kiddies quite quickly.
Personally, I don't see anything wrong with having 3 locks on the door:
ACl
port knocking
nonstandard port
Of course, one still wants to have a difficult to pick key after all that.
Is 3 really that necessary? Are there often cases where an up-to-date ssh daemon gets cracked even though it is on a high port and allowing only public key logins of specified users with a small number of retries?
Do not under estimate the zerg. Although ssh servers on different ports are "harder" to find, they are still not invisible. Try changing your banner, using 'port knocking', TCIP fingerprint spoofing, and other obfuscation techniques. Nothing is 100%, but you can still have really secure boxes. Proper admins are your best line of defense.
This whole post got me thinking about ways to sniff out proxies. I am usually behind on this kind of thing, but bare with me please :).
Using PHP and Javascript I think you could weed out the majority of proxy users; avoid IP spoofing, protect sensitive places a little better. Use php to get the users IP address. Find location of that IP. Find timezone/time of that ip. Have a range set up to catch errors. Now use JavaScript to get the time.
Javascript will return the time specific to the system. If the two times do not match up then you possibly have someone using a proxy.
There are some issues with this type of system, traveling business man, but it could be useful at some point.
For instance, instead of this irregular "knock" routine, which is a fuss to implement, why can't there be a standard protocol for requesting firewall access? There's a standard for punching holes in local firewalls to open external ports, so why can't the same thing be applied in reverse to remote hosts?
With a proper access control mechanism, ssh-key driven, LDAP-backed or otherwise, it should be possible to send a packet to the remote firewall with enough information to verify identity and open the port as required. That would prevent scan attacks from working because none of the probes would be properly signed and the host port would appear closed.
Now I get to drive out to the datacenter. Whoops.
It's awesome, gets rid of a bunch of brute forcing ips that you see in your secure.log.
Once the correct port is located, you're in precisely the same situation that you are if you hadn't moved ssh.
No, it doesn't. Running a port scan and finding your "hidden" SSH port takes very little time.
Placing your SSH port behind a hosts.allow restriction ensures that you've reduced your attack surface to only the hosts (or networks) you've permitted.
Better still, set up OpenVPN, use its HMAC[1] support to stop unknown users early, and don't expose any other daemons to the internet.
[1] http://openvpn.net/index.php/open-source/documentation/manua... (See --tls-auth file option).
To quote:
The rationale for this feature is as follows. TLS requires a multi-packet exchange before it is able to authenticate a peer. During this time before authentication, OpenVPN is allocating resources (memory and CPU) to this potential peer. The potential peer is also exposing many parts of OpenVPN and the OpenSSL library to the packets it is sending. Most successful network attacks today seek to either exploit bugs in programs (such as buffer overflow attacks) or force a program to consume so many resources that it becomes unusable. Of course the first line of defense is always to produce clean, well-audited code. OpenVPN has been written with buffer overflow attack prevention as a top priority. But as history has shown, many of the most widely used network applications have, from time to time, fallen to buffer overflow attacks.
So as a second line of defense, OpenVPN offers this special layer of authentication on top of the TLS control channel so that every packet on the control channel is authenticated by an HMAC signature and a unique ID for replay protection. This signature will also help protect against DoS (Denial of Service) attacks. An important rule of thumb in reducing vulnerability to DoS attacks is to minimize the amount of resources a potential, but as yet unauthenticated, client is able to consume.
--tls-auth does this by signing every TLS control channel packet with an HMAC signature, including packets which are sent before the TLS level has had a chance to authenticate the peer. The result is that packets without the correct signature can be dropped immediately upon reception, before they have a chance to consume additional system resources such as by initiating a TLS handshake.
The point I'm making, though, is that every instance of someone running a dictionary attack against one of my servers was a script kiddie running a tool against a range of IP addresses. Changing the port ssh runs on to something high eliminates this entirely.
Those are the attacks you see. The script kiddie with a 0-day would be much less obvious.
There are straight-forward ways to architect your infrastructure such that you solve the dictionary attack problem AND the 0-day problem, none of which require the hand-waving security (and user annoyance) of moving SSH to a non-standard port.
The security provided by a non-standard port is laughable -- it's like putting a child-proof lock on your front door.
If you're worried about dictionary attacks, turn off password authentication. If you're worried about 0-day vulnerabilities in SSH, leverage defense-in-depth (require well-secured VPN connectivity before allowing SSH access). If you're worried about user's machines being compromised and their keys stolen, leverage two-factor auth.
nmap -sV -p1-65000 ip
Do you have a username/password or username+certificate that a script kiddy is likely to hit in their first 10,000 attempts?
If yes, you have a much larger problem that can't be solved by port knocking or moving ssh to a different port.
If not, then you're trying to solve a problem which doesn't exist anyway.
http://danielmiessler.com/study/security_and_obscurity/
Ask yourself why, if obscurity is worthless, does every military put camouflage on its tanks?
I thumbs downed the article because as a security professional we try to stress the importance of actual security rather than obscuring the problem for long term success.
Take port knocking for example, interesting idea but what a pain in the ass... just disable root and set a strong password.
Changing the port from 22 will prevent all of the automated botnet driven SSH brute force attacks, which do little more than messy up your log directories.
Best thing you can do is use SSH brute force blocking script which reports attackers back to a webapp which the security community can use to track infected hosts. example: http://danger.rulez.sk/projects/bruteforceblocker/blist.php
Fail2ban is a nice one too as it supports many services including http-auth.
also, everyone keeps talking up these scripts to stop brute forcing... two iptables rules will do this for you.