Using Resource Obfuscation to Reduce Risk of Mass SQL Injection
devcentral.f5.com
devcentral.f5.com
It seems to me like it might be wise to have a standardized qualifications test for the web - something that tells employers "this guy won't put security holes in my program"
The first trick, in particular, seems pretty useless, unless I'm missing something. The second one is probably slightly more useful, but won't stop a determined black hat (it doesn't feel right to say 'hacker' on HN, even in context).
If someone is dedicated to gaining access to your machine, and has the skill and knowledge to do so, then, in general, a little extra obfuscation will annoy them but not stop them. The only potential benefit of this kind of obfuscation that I can see is that it could shut down script kiddies who don't really know what they're doing. But if you want reliable, provable security, don't rely on tricks like this.
One thing that security-through-obscurity can help with is what is outlined here; moving off of the common ports and common extensions means you can't be trivially scanned and attacked. Attacks which shouldn't be successful, but can still be expensive (if nothing else, a determined web attack also functions as a DoS, after all).
For my personal host, I use ssh in certificate-only mode, because that's the most secure mode and SSH is a significant part of my attack surface. That's security. But I also moved my SSH off of port 22, which is "obscurity", just so my logs didn't get filled with pointless scanning attacks, which significantly increases the value of my logs. A determined scanner can still find my SSH port, but few people are that determined.
I like the idea of not transmitting any information about what software your site is running. I already do pretty much what the post says, plus other things like using generic and unguessable directory names for admin apps.