Unconventional Defenses

Here are some unconventional recommendations not covered in detail elsewhere in this book.

Rename Admin and Highly Privileged Accounts

Dedicated hackers and malicious software attempts to compromise the Administrator user account. You can make it harder to accomplish that by renaming the Administrator and other highly privileged accounts to names that don't suggest their function. Use a naming convention that is easy to remember and well known to your IT staff, but wouldn't be as obvious to a hacker. For example, if your user account names are first initial, last name, rename your Administrator account to BLovell. Rename the Guest account to RLovell. Rename other administrator accounts to SLovell, KLovell, and MLovell. One of my clients names his administrators after members of the rock group Kiss. Anything you and your staff can remember easily works. Be sure to change the name and description fields from their original defaults. The Built-in account for administering the computer/domain should not be left. Renaming the local Administrator and Guest accounts can be accomplished using group policy.

Now, create replacement bogus accounts. Create a new user account called Administrator (this must be done after the original is renamed). Give it the original Administrator's description. Create a long and complex password; it will never be used so there is no need to write it down or remember it. Then, using NTFS permissions or group policy, highly restrict this account. Make sure that it has Full Control-Deny permissions to all computer resources. Using group policy (Chapter 14), remove any normal special privileges and highly restrict any remaining rights. This can be accomplished more easily using a specially created group (see Chapter 3). The idea is that if by chance the hacker cracks the bogus account, then the access they receive is severely restricted. They would love to get Guest access rather than what this bogus Administrator account will give them. Repeat the process for your other highly privileged accounts, and rename the originals and create bogus placeholder accounts.

Note 

All highly privileged accounts should have long (15 characters or longer), complex passwords.

Then enable Logon and Account Logon auditing. Nobody legitimate in your environment should be trying to use the bogus Administrator account. It's fake. If you see logon messages associated with the Administrator account, you know that a malicious hacker or program is trying to hack your computer systems. Starting with Windows XP Pro SP2 and Windows Server 2003 SP1, Microsoft added a Per-User auditing feature (www.windowsitpro.com/Article/ArticleID/46625/46625.html). Using it you can enable logon auditing for just the bogus accounts if you are worried about the noise generated from enabling the normal logon auditing feature. And Per-User auditing doesn't show up in the normal auditing configuration areas. If the hacker uses a tool to query your current audit policy, the Per-User settings will not show up.

Protect Other Highly Privileged Accounts

You need to take similar protections on any of your highly privileged accounts. Other highly privileged accounts include:

• Local or domain Administrators

• Directory Services Restore Mode account (i.e., local Administrator on a domain controller)

• Any account that is a member of the Administrators group

• Any account that is a member of the Domain Admins group

• Any account that is a member of the Enterprise Admins or Schema Admins groups

• Any account that is a member of the Power Users group

• Any account designated as a Data Recovery Agent (DRA) or Key Recovery Agent (KRA)

• Any account that is a member of the Account Operators or Server Operators groups

• Any account that is a member of the Group Policy Creator Owners group

• Accounts with delegated permissions

• Accounts with elevated Full Control permissions beyond the normal end user

Because these accounts are often normal user accounts, they usually don't have to be renamed. However, if any of them are named after their official role (e.g., DRA_Admin or ExchangeAdmin), you should rename them to something less notable. Consider instituting Logon and Account Logon auditing for any of these accounts.

SID EnumerationMany security experts argue that hackers can simply do SID enumeration to discover the true Administrator accounts. Every security resource in Windows is given a Security Identifier (SID) number. Built-in entities, such as the Administrator, the Guest, and the Everyone group, are given well-known SIDs, meaning they are the same across all Windows desktops. For instance, the Administrator always has a SID of 500. The Guest account's SID is 501. The Everyone group is a 1. The Domain Admins group is 512. Normal users and computers start at number 1000 and up, so the theory is that any hackers worth their salt will not trust the Administrator account name and will always enumerate the SID and discover the real accounts. The save to this potentially dangerous problem is that most hackers don't do SID enumeration, and certainly no automated malware ever has. Since 99% of your threats are automated, it means 99% of the "hackers" will not do SID enumeration. Even most malicious hackers don't do SID enumeration. They could, but they usually don't. They look for the Administrator account and if they find it, they don't look anymore.

Note 

SIDs will be covered in more detail in Chapter 3.

Added to this proclamation is the fact that anonymous SID enumeration (which is what most hackers would try initially anyway) doesn't work on XP Pro and above computers, unless they are domain controllers. By default, domain controllers must allow anonymous SID enumeration. It is the way they work. But Windows XP Pro, Windows Server 2003 stand-alone, workgroup, and domain member computers don't allow anonymous SID enumeration. In each case, the hacker would have to previously compromise the network with another legitimate account in order to do SID enumeration. Even then, most dedicated hackers find it easier to add their existing exploited account to the Administrators group than to directly attack the Administrator account. All in all, renaming the Administrator and other highly privileged accounts is a significant way to secure your Windows computers.

Note 

If you are interested in more details about designing and protecting Administrator accounts, be sure to download and read Microsoft's The Administrator Accounts Security Planning Guide (www.microsoft.com/technet/security/topics/serversecurity/administratoraccounts/default.mspx).

Run Services on Non-Default Ports!

When I found out that some of the world's largest banks got hit by the Slammer SQL worm, I was aghast. Not only did that mean that a financial institution's database servers were unpatched, and that they were placing mission-critical infrastructure on the untrusted Internet, they were also using default ports that take literally a registry entry to change. Lesson learned, whenever possible, install server software to non-default ports. For instance, I never run RDP or Terminal Services on TCP port 3389. I run PC Anywhere on any port but port 5132. I run my HTTPS servers on something other than 443. My FTP servers don't run on port 21 and I certainly don't run my SQL servers on ports 1433 or 1434.

If the service doesn't need to be on a default port, throw it somewhere else, preferably randomly high where port scanners won't readily find it or know what to do with it. For example, although RDP hasn't been exposed to a publicly announced exploit (since 2002), I run it where it can't be easily found. If an exploit does come out, it will usually be thrown in a worm and hit every possible victim in a few hours or days. I won't be found so easily.

I frequently change even public web servers to non-default ports. For example, I have a lot of health-care clients who exchange financial and patient data over the Internet using HTTPS. Besides using encrypted communications, I move the web server's default port to something random and high. Then all participating parties are told to connect to the non-default port. It's as simple as sending the link in e-mail (ex: https://www.example.com:38093). We tell them to save it as a shortcut on their desktop. Legitimate users have no problem gaining access, and web worms are frustrated.

Install High-Risk Software (i.e., IIS) to Non-Default Folders

Along the same lines, whenever possible, install the OS and any software to non-default folders. Install Windows to C:\Windows or applications to C:\Program Files. Most Internet attacks are automated with predefined paths to access when the exploit is successful. Yes, there are ways for hackers and malware to check for the correct paths, but most don't. If you use IIS, change the default path to something other than C:\Inetpub. If you use IM software, install the software to a non-default folder and rename the default configuration file if you can. IM worms almost always only work if the default pathways are present.

Windows Vista

One of the biggest changes in the upcoming Windows client, Windows Vista, will be an extension of the Limited User Account (also called the Limited-Privileged User Account). Here are some of the features being discussed (remember that no feature is final until the product is released):

• To begin with the quasi-admin group, the Power Users group is finally going away. Microsoft has been trying to kill this group and its members since Windows 2000.

• Even if a user is logged in with administrative privileges, most programs will run in a non-admin context. For example, if the Administrator opens Internet Explorer, it will not be running in the Administrator's context. In order to do something administrative, Windows Vista will prompt the user for the admin credentials (again). This is a most welcome addition to the Windows OS, and it should stop a fair amount of traditional malware from automatically installing.

• Vista-compatible applications will contain a "manifest" file detailing who will need what permissions in order for the application to be installed and in order for it to run.

• Another big feature is the ability of a LUA to install a program to a folder location named My Programs instead of to the shared Program Files or System32 directories.

• Applications trying to write to protected areas of the file system and registry will be given "virtual" copies that they can manipulate, but that will not control the entire system.

• An excellent blog discussion from a Microsoft employee can be found at http://blogs.msdn.com/embedded/archive/2005/04/07/406412.aspx.