Have you ever repeated a fact over and over for years only to learn that what you believed was true actually wasn"t? I"m still slightly begrudging my mom for cheating my younger self out of sunny pool time with warnings that entering any body of water within 30 minutes of eating lunch would result in severe cramps and certain death. Years ago, a Reader"s Digest article revealed that warning wasn"t true.

Seeing as I"ve owned a pool most of my adult life, and none of my kids, neighbors, or loved ones have ever suffered a cramp in my pool after eating, the news shouldn"t have been such a surprise. I ignored the evidence right in front of me the entire time.

Security by obscurity is a lot like that. Almost every computer security "expert" alive repeats the mantra that security by obscurity is no security at all, despite overwhelming evidence to the contrary. I propose that it should be a valid part of any computer defense plan, and in fact, can be one of your best defenses.

Before writing angry hate mail to your new security columnist, let me explain further. First, I didn"t say security by obscurity was the only defense technique someone should use. I didn"t even say it was real security, but I am saying that it should be an important part of most computer defense strategies.

Security by obscurity can be accomplished several ways, but basically it means getting out of the default habit and taking certain steps:

-- Rename highly privileged admin accounts to less notable names.

-- Name servers with names that are not obvious to their support roles.  

-- Run server services on non-default ports whenever possible.

-- Install high-risk software (such as Internet-facing Web servers) to nondefault directories.

-- Rename configuration files to nondefault names, if possible.

The idea is that if something doesn"t have to be installed to the worldwide known default name or location, don"t do it. Why give malicious hackers and automated malware a leg up on your environment?

For example, Windows administrators should rename their Administrator account to something less than obvious, such as PeterC. The Exchange Administrator account shouldn"t be called ExchangeAdmin and your tape backup service account should not be called Tapebackup.

Security experts will respond that in the Windows world, the Administrator account can always be easily identified by its well known SID (security identifier) number of 500, and that"s true. The reality, however, is that most attacks are automated and none of them have ever done SID enumeration. Hackers can do SID enumeration, but most of them don"t.

Think of how security by obscurity could have helped avoid the SQL Slammer worm. If you got compromised by Slammer, it meant you did three things wrong. First, your SQL box was unpatched, even though the patch had been out for more than half a year. Second, you connected your SQL to the dangerous world of the Internet without a protective VPN. Third, your SQL servers were running on the default port of 1434.

It"s not easy to fix all of those problems. Keeping patches up-to-date can be hard in a large enterprise, especially when trying to thoroughly test a mission-critical application. And VPNs can be one of the most difficult things to establish between multiple points.

The easiest solution of the three is to move your SQL ports to some other TCP/IP, maybe 43143 or the like. You can modify the default ports during a new install and simply update a registry entry for existing clients and servers.

Here"s where security by obscurity can work, and it"s only one of hundreds of examples I could give you: I run almost a dozen honeypots attached to the Internet. Two of them are SQL server honeypots; one runs on port 1434, the other runs on 1435. The first gets attacked hundreds of times a day. The latter has never had a single SQL probe on port 1435 in more than a year from either automated malware or hackers. Hackers could find the second SQL server honeypot (the SQL password is blank on the second box, by the way), but so far, the simple port change is doing a fine job of obscuring its location.

Unix/Linux administrators seem even more resistant to changing defaults than Windows admins. Recommend that they change default RPC program numbers, which many malicious scripts depend on, and you"ll get imagined stories of all the things it will break. Mention renaming the root account and you"ll get stares. Ask if renaming the root account could possibly hurt their system and they"ll say no (after a little thought). Why not rename the root account, create an unprivileged bogus root account in its place and see what happens to your security exposure risk? It won"t increase.

So, instead of repeating the mantra of how security by obscurity doesn"t work, learn to think for yourself. Me, I"m going to go eat my lunch in the pool.