Windows Server 2003 Hardening List (Part 1)
In this article we look at your first steps after a basic install such as locking down key accounts, implementing NTFS and making sure your data on the system is secure. This is Part I of a multipart article. It's my intention to make this "Hardening List" a guide that never stops growing on this site. Here is the first part of many, lets lock these systems down!
"For a complete guide to security, check out 'Security + Study Guide and DVD Training System' from Amazon.com"
After the Install
Once you have installed Windows Server 2003, you need to begin the lockdown process. Any default installation of any operating system or platform needs to be analyzed and addressed for security now more than ever. With such an emphasis placed on security these days, each install you do needs to be addressed and it's no different with Windows Server 2003. After you complete a basic install, you should start a checklist of items that you want to lock down, remove and audit or at least 'know' about to keep yourself and your systems safe from threat.
After you basically install the system, you need to address a few issues pertaining to the installation itself. First, remember that when an operating system is installed, most times, there are commonalities that exist between each system. The first common issue for Windows based systems is the Guest and Administrator account. Not only can a hacker try to expose a weakness here, but also malware based attacks use the administrator account that was built in to the system as a potential starting point to gain entry to or compromise your system. This is very common these days, many of the Virus attacks I see on most corporate networks revolve around this weakness.
Windows Server 2003 has many built in accounts that you can use by default. You can see this in figure 1. This is after an installation of the system, you can see without adding too much, there is already a great many accounts with different levels of security.
Because of how this is set up, you have a common thread for attack - the attacker already knows what half the credentials are to crack into a system, as they would only need the password now. When you keep default accounts in your server... you are totally asking for trouble. Any password attack known to humans today is based on knowing 2 things, the username and the password. If you have half the equation, then all you need is a good password cracking tool, a huge dictionary file and some time. I still can't believe it today when I see project plans for deploying Windows Sever 2003 and Active Directory, and a much needed task is not on the task list... 'Change default accounts'.
Another option is to totally set those accounts up as an early alert system that someone is knocking on your door. If you get an account lockout (if you set it up), on the default accounts, then you can pretty much be sure that you are under attack. You forfeit this whole scenario when you leave default accounts in your design. Since many of the default accounts cannot be deleted you will have the option to rename them. Accounts in Windows Server 2003 that are highly common (and built in of course) are the Guest and Administrator accounts.
The Guest account (as seen in figure 2) is easily locked down because by default it is not operational. The account is disabled by default on member servers and domain controllers. This is good because you really don't have to worry about it being exploited unless someone enables it. It is important that you check to make sure that the guest count is not active, or does not become active.
The Administrator account (as seen in figure 3) is a totally different story. This account is very important for you to know about and deal with immediately.
The Administrator account should be locked down immediately after your basic install. The best way to do this is to either make it a trap (like a honeypot), or to rename the account totally with Group Policy, either way, lock it down. Normally, in smaller organizations, it's easier to just rename the account, and then set it up as a trap but that is your option and choice.
Always try to create a backup administrator account and use that one instead, but never lock yourself out of the system so make sure you make a note as to what the new account will be and secure that information.
Once you rename the account also never forget to change or delete the 'description' as seen in figure 4 to remove the possibility that someone local to the machine can figure out what the administrator account is now.
Auditing the activity on key accounts is also important. Since Auditing for Windows 2003 warrants its own article, stay tuned for that one in the future.
Now that you have altered the Administrator account for security reasons, you should make note of a few more items. First, you should never use a blanket account especially in a large organization. The problem with this is, if one system is compromised, then they can all be potentially compromised. I generally come up with a password scheme that allows me to keep different Administrator accounts, but all with different passwords, but again, this is for the highly paranoid. Also, when you record this information about these new Administrator accounts, make sure the documentation is secured as well, otherwise everything you planned out is worthless when the password list has been tapped, stolen or compromised itself.
I can't emphasize this enough... I have seen it happen so many times... try not to use general accounts like shopuser or something like that because the account can't be tracked in your security logs. If you audit login, you will see 'shopuser', and that doesn't tell you much when the login took place at 3 AM on a Sunday night when the building was closed.
NTFS stands for New Technology File System, and although it's not very new anymore, it is still tops when it comes to implementing security on your file system. This makes it possible to implement security at the file and folder levels. This support is not available with the file allocation table (FAT), FAT32 or any version of FAT whatsoever. NTFS is in a class by itself. You can view a file with NTFS immediately as seen in figure 5.
Think of NTFS as a big Access Control List (ACL) that either allows or disallows you access to data based on your identity. Without NTFS, anyone could easily access your files and folders to see your data. You really should never have to use anything but NTFS when you install your server, so if you have not installed NTFS, you can use the convert utility to do so - and it will do so without destroying your file system! Either way, make sure you are using it for advanced security on your Windows Server 2003 system.
The convert utility we just mentioned will not destroy your data, but it will leave it vulnerable, as it will set the ACLs for the converted drive to 'Everyone' with 'Full Control'.
Nothing is worse than investing a ton of money and time into locking a system down only to have the attacker who exploits it walk right up to the system console to do so. Yes, it is true, many systems have been hacked simply by the hacker walking directly up to the console and finding an unlocked console. I mention this here and now because a Hacker with physical access to the console can get past NTFS. All it takes is a bootable disk, or a parallel install to get to your system's data so you really need to make sure that you have implemented proper physical access on your system or all the time and work you put into configuring permissions with NTFS, will be completely worthless.
Disk Segmentation is a security process of keeping specific data on your server on separate physical disks for added security. In figure 6, you can see 4 disk drives where I have separated the operating system files, the swap file, the user accessible data and the installed applications all on different physical disks in the server. Once only done to increase performance, it also adds a massive gain in your security posture. Locking down your system in the fashion will keep your data secure on your system from directory traversal attacks.
If you are unfamiliar with this type of attack, just think of NIMDA. NIMDA and Code Red worms both used an attack that would exploit IIS so that it could traverse the Web site directory trees to gain access to and remotely use the cmd.exe utility. You really need to separate your data in this manner if you would like to remove threats of this kind from exposing your systems.
In sum, we have looked at a few options to harden your new Windows Server 2003 server. This is only part 1, so stay tuned to quite a few more parts coming your way so you can lock down, harden and secure your new Windows Server 2003 system.
If you would like to be notified when Robert Shimonski releases Part 2 click here to sign up to our Real-time Article Update.