This should be uncontroversial. Anything that increases the amount of work needed to carry out a successful attack increases its security. The only concern is whether you end up being overall less secure because of a misplaced trust in the obscurity layer.
But obscuring may take away time from securing and it adds complexity to the system but systems with less complexity are easier to secure. So you at least have to be careful.
It is also important to consider the complexity too.
There is no such thing as "Security through unnecessary complexity", only the opposite.
The examples about changing port numbers are great, they are simple configuration changes, when people start wanting to add obscurity "features" they often wander down the path of complexity, inevitably adding vulnerabilities.
Going back to what I said, if you actually fully understand the concept, you wouldn't misplace your trust in the obscure layer. If you don't understand the basic concepts its game over, you have already failed.
Most attackers usually just go for the lowest of the low hanging fruit. Obscuring systems from them is not a bad thing.
> Anything that increases the amount of work needed to carry out a successful attack increases its security.
By this logic, any system which is more obscure is more secure. So for example, a 20 year old Sun server running telnet and has never been patched is more secure than a brand new server, because you might have to learn SPARC assembly or sniff the traffic/create a telnet parser. If you're trying to argue that added complexity equals security, that makes even less sense.
> Anything that increases the amount of work needed to carry out a successful attack increases its security.
Jesus christ this is a stupid statement.
Of course, if you use a tool in a stupid fashion, you get stupid results. In physical security terms, security is measured in the amount of time it would take for an attacker to penetrate the defense. This also works in terms of computer security. I'd carefully choose a bit of obscurity which would force an attacker to improvise on the fly, while under time constraint or working against a chance of discovery.
A good analogy would be a moat around a castle. A moat can be nothing more than an empty ditch. Just having an empty ditch surrounding a building would make for a rotten castle. However, having such a ditch just outside the walls interferes with the deployment of siege engines and ladders in exactly the place where one has to worry most about counterattack and so is worthwhile.
So in one sense, you are correct. You don't just put anything up without thinking about cost/benefit. Costs might be in the form of increased attack surface, or increased operating costs. The cost might even be in the form of reduced overall security.
So for example, a 20 year old Sun server running telnet and has never been patched is more secure than a brand new server
If looking up the old exploits is easier than finding the zero-days on the new server, then this is less obscure by definition. It's a badly thought out straw man.
Why don't I just put six different proxies in front of my webserver? That's six times the effort at least. Dang that must be secure.
Going back to cost/benefit, if the 6 proxies spoil your operating costs and latency, then it probably doesn't work out.
When I say work I meant more in the computational sense (although wall clock time also counts). If port numbers were on a 32 bit address space, using a random port for your service instead of the standard one would be a strong security benefit, precisely because of the amount of "work" needed to cross that barrier.
But no, there's no good way to justify using an outdated system because of the obscurity factor. It's the asymmetry of work that obscurity offers that provides the benefit. If you're making your own life miserable in the process you're doing it wrong.
