Identifying vulnerabilities in Windows Server 2003 is not a simple task considering the new operating system is much more secure than its predecessors. Sure, security may be weakened by poor configurations and missing patches, but running Windows Update will help you fix most patch-related vulnerabilities, right? So what security issues should you worry about in Windows Server 2003? Here's a list of its weakest links and solutions for...
Weak link #1: Relying on Windows Update
Windows Update is probably the number one security vulnerability in Windows Server 2003. Don't get me wrong, I think that Windows Update is an absolutely fantastic feature. But it tends to give people a false sense of security. It does not update other server products that might be installed, such as Exchange Server or SQL Server -- and Exchange Server is one of the most frequent targets of attack.
Soon Microsoft will release the Windows Update Service (WUS) to keep other products up to date. In the meantime, be aware that Windows Update will not patch everything. Use a more comprehensive patch management solution or make manual updates until WUS becomes available.
Weak link #2: Failing to rename Administrator account
Other major security vulnerabilities can be blamed on configuration. For instance, Microsoft recommends disabling the Guest account and renaming the Administrator account, both standard in Windows since NT was released. In Windows Server 2003, the Guest account is finally disabled by default -- a good step -- but there are still some problems with the Administrator account.
Many Web sites tell administrators not to bother renaming the Administrator account. They believe doing so is futile because the Administrator account can be easily identified by its SID, which can't be changed. I tend to disagree with this theory. Renaming the Administrator account may foil less sophisticated hackers, and it makes it easier to monitor network security since no legitimate user will try to log in as Administrator.
Not only should you rename the Administrator account, but you should take it a step or two further on your member servers. Remember that each member server has a local Administrator account. I recommend renaming the Administrator account to something different on each member server, and giving each server a unique Administrator password. Then if someone happens to crack one member server, security won't be compromised on the others because you don't have a single set of valid administrative credentials for multiple member servers.
Weak link #3: Running services with a user account
Service accounts seldom expire or have their passwords changed; doing so means having to modify an entry in the Service Control Manager to reflect the new settings. Of course, this leads to weak security, especially when you consider that service accounts often have administrative privileges.
In Windows Server 2003, you can specify services to log on by using the Local System Account rather than a user account. This is great, but some programs (and some administrators) insist on using a user account instead. If you are forced to run a service with a user account, there are some guidelines that you can follow to make the server more secure.
1. Never use the Administrator account to run a service even if the service requires administrative privileges.
2. Never use a domain account as a service account. If the service account is compromised, you don't want to give the hacker access to the entire domain. Use a local user account instead.
3. Deny access to anything that the service account doesn't specifically require access to. Even if the service account requires administrative privileges, there are probably some files or folders that you can deny access to.
For More Information
Checklist: Hardening user passwords
Topics: Windows Server 2003 security