Andy Warren points to a TechNet article about Security by Obscurity and wanted me to post some notes. Let's start with the example they used.

Rename the Administrator account:

I agree with Roger's take. We intentionally rename the administrator account because it does stop the malware and scripts. We intentionally rename the administrator account because it allows us to alert easier. We see a hit against administrator, and we know 99% of the time it's not legitimate. That allows our reaction to be quicker.

This doesn't mitigate the need for strong passwords. They still must be there. And the argument that a GPO applies the same administrator rename is only partially true. If you segment your systems in different OUs or you use WMI filtering or you security groups to determine which computers can apply a GPO, you can have multiple GPOs with multiple renames.

What Security By Obscurity Gets You:

Security by obscurity gets you an advantage against automated scripts. Security by obscurity gets you a time delay against an attacker intending to break in. Depending on how the system is obscured (for instance, if you move the HTTP port, the attacker must do a port scan first... which, depending ont he environment, may be detectable). Security by obscurity can get you early notice. For instance, if you don't use administrator anywhere and you start getting audit failures against administrator, you know one of three possibilities is true:

1. You have someone legitimately trying to log on but who doesn't know the right account, such as a new system administrator.

2. You have an application or system configured wrong

3. You have a legitimate attack

Any of those three you want to know about.

Why It Isn't Where We Should Stop:

But security by obscurity doesn't absolve you of responsibility for taking all appropriate security measures. For instance, if you rename the administrator account but you still have a weak password, the account is still weak from anyone who can browse the system. Therefore, you still secure the password.

Let's apply this to SQL Server.

• Block UDP/1434. This is the SQL Server listener service port. If you can't access this port, you can't automatically determine the port for named instances.

• Move SQL Server off of 1433 for default instances.

A script or the worms we've seen will not be able to get to your SQL Server. But assume you have a blank sa password (a complete reliance on security by obscurity). You've stopped the easy stuff. But then you've got that one internal guy who knows the sa password is blank. Even if he doesn't know the port on SQL Server, if he can access the server, he can try a port scan, such as with Nmap. Most of these tools (Nmap falls into this list) allow a very slow rate of fire, meaning they won't get picked up on alerting. Once he finds the port, he can get in. And if this server contains data that's worth some money, he can afford to wait until he finds the port. And then the guy gets in, gets the data, and likely you have no audit trail. Not good.

Therefore, certainly hide your systems; make 'em harder to find. But don't neglect the other aspects of security.