If obscurity is useless, then why does the Army camouflage tanks? Why not just paint them blazing orange/pink and let them stand on their own defenses? There is a place for obscurity in security and the endless parroting of "security through obscurity is useless" should stop.
It seems like the argument against security through obscurity is similar to the argument that T(n) = 10,000n^2 is equivalent to T(n) = 10n^2, as both are O(n^2) even though they have vastly different coefficients.
At the end of the day, they have the same Big-O notation, but one of them is a thousand times better than the other.
Sometimes the coefficients matter. Obscurity in security is like the 'lost' coefficient in Big-O notation: it's not the first thing you should focus on, but it can really help.
It's not that obscurity is useless, it's that it often inconveniences the legitimate user as much as the attacker. "Often," in this case, scales with the size of the organization. Changing the ssh port on your home server might not be overly inconvenient. Changing the ssh port in a 1.4 million person organization puts you on the wrong side of the cost/benefit curve.
Obscurity isn't useless in all situations, but in this case it's important to realize that changing the port number is really only effective in preventing scanning attacks.
For a targeted attacker, finding the new port is trivial. (There are only 65k of them...)
Comparing service discovery with maintaining a fog of war isn't really an apt comparison.
How about using "password" as a password if security is so good? Or do you suggest people keep track of 255 UTF-8 characters for a password?
An attacker would still need to go through all 65k ports. I would assume by even false scanning 5 ports, the attacker gets immediately null-routed and still get no response. I would also hope such programs have a paranoid sense of security that they would deny user/password if either are false by not even providing a response as if the program didn't exist.
Due to lack of feedback, users will get inconvenience and confusion why ssh doesn't work. Much like passwords example, there's a trade off between usability vs security with varying obscurity levels.
> I would assume by even false scanning 5 ports, the attacker gets immediately null-routed and still get no response.
So run the scan using a botnet. Each machine makes one attempt (there are some really big botnets out there). There's no way for the machine to prevent the attacker from finding the port being used, unless the machine notices that lots of requests are coming in from unknown machines and starts refusing all requests - of course, refusing requests from unknown machines is a good thing to do if you're being paranoid. Use a whitelist of allowed machines, not a blacklist of disallowed machines.
Is there really no way for the machine to prevent private ports from being be known without a specific call? It seems to me that machines are designed to follow the standard to be nice and respond back [0]. Even with a whitelist, I have concerns that the machine is opening itself for a DDoS SYN attack by simply replying back rejections.
Tanks don't have camouflage for defensive protection from attacks - they have it to reduce the likelihood of detection.
This is exactly the same as how a computer system attacker will attempt to disguise their attacks as legitimate traffic, and how honeypot system disguise themselves as real targets to attempt to detect attackers.
Security is a subtle field. "Security through obscurity is useless" is a useful starting point, but - as with most things - you need to understand what it means.
This is true, but it has advantages. For example, system log files are much smaller. :) When I adopted this policy on my own systems, it was to help me change my worry profile from "noise from every random bot on the net" to "targeted attack".
For a long while I ran a tricky firewall chain that would allow you to connect to port 22 only 3 times before it would lock out your IP for 30 minutes. My ssh port was at something like 2022 so I (almost) never got caught in this, but an unsuspecting scan bot would get stuck on it (http://en.wikipedia.org/wiki/Tarpit_(networking)#The_origina...).
> That's not security, that's obscurity. If your ssh is secure, you don't need to change your port number.
It's also a mild performance hack. Bouncing a connection to a closed port is faster than waking up the SSH daemon to bounce the same connection. Port 22 gets a lot of traffic.
There is another reason to do this as well, when at Lockheed - we changed all SSH ports as we were scanned literally continuously in real-time from chinese IP blocks.
Port knocking can be automated. Hopefully everyone that needs ssh access is either experienced enough to install the port knocking script themselves, or under IT's supervision so they don't even have to know the port knocking script exists.
Scripting something with port knocking, when you don't actually have the compiler available, or nothing user-writeable is executable is not nice. ssh on a standard port will just work and users don't have to figure out how to activate it. Changed port will take some explaining, but could be used for advanced people.
40 character passwords, along with host-based firewalls that /dev/null you after 10 failed attempts are just as effective as keys. In case you are wondering, the passwords are pasted, not typed.
...Until someone hacks your system and manages to grab the password. The nice thing about keys is you don't have to reveal your secret, just prove you have it.
Sadly the revered secret is usually stored as safely as the password in plain text on the compromised server. I would any day recommend someone to use 40 character random passwords locked down on the client, available through pasting, than have them fumble around with improper key exchanging.
It's pretty typical to audit all your destination servers (which may number in the thousands) to ensure that they don't have private keys (the id_rsa) - in theory all they need is your id_rsa.pub.
Then, you only need to worry about securing your clients - and, it's typically difficult to wholesale (a) hack into all the clients, and then (b) yank the encrypted id_rsa off of them (as compared to hacking into a destination server, and then just wholesale waiting for people to login and grab their password). It's next to impossible in a secure environment (financial/medical/utility) where they have hardware dongles which contain their id_rsa. (Or, they move into a new class of secure, and use One Time Passwords, RSA Tokens)
Net-Net - multi-use static passwords are not used in secure environments.
