Security is an increasingly important topic for network
administrators. It’s an ongoing battle to make sure you’ve installed all of the
latest updates along with keeping up to date with all of the developing
threats. Properly securing server begins with planning. When you’re deploying
Windows Server 2003, you can use these tips to make sure you’ve done so while
properly securing it.

Author’s Note

Entire books have been written on the subject of hardening
Windows Server 2003 deployments. There is no way that I can even begin to
scratch the surface of the topic within a 2500 word article. That being the
case, I decided to focus this article on some of the lesser known hardening
techniques. These techniques are no substitute for the basics, but when
combined with standard security techniques they can help you to build a very
secure network. For information on the essentials, I recommend checking out
Microsoft’s Windows Server 2003 Security Guide. You can download it for free at
Microsoft’s
Web site.

Protect your authentication mechanisms

There’s an old proverb stating that a chain is only as
strong as its weakest link. That saying is especially true when you are talking
about a network’s chain of security mechanisms. I know a lot of people who
spend countless hours making sure that every packet flowing across the network
is authenticated and encrypted, and that all of the files on the server’s hard
disk have the proper permissions assigned to them. Such measures are important,
but the fact is that the vast majority of hacks are perpetrated by using
legitimate user accounts.

User IDs and passwords

In most networks, the user accounts themselves are by far
the weakest part of the network’s entire security infrastructure. A hacker only
needs to know two pieces of information (a user name and a password) to be able
to access anything on your entire network. Sure, encrypting all of the packets
as they flow across the wire will help to prevent a hacker from sniffing
passwords, but there are plenty of other ways that hackers can acquire
passwords.

One of the oldest password acquisition methods still works
to this day. That’s a brute force crack. Like I said, a hacker must have a
username and a password in order to gain full access to your network resources.
Of course, Microsoft was kind enough to provide the hackers with the user name
for you; Administrator. That means that hackers only need to figure out the
Administrator’s password in order to gain access to your network.

Microsoft has long recommended that you change the name of
the Administrator account so that hackers won’t know what it is. The problem is
that even if you change the account name, the account’s SID remains the same.
Since Microsoft uses a specific SID for the Administrator account, it’s fairly
easy to figure out what the account has been renamed to, just by examining the
SIDs. In fact, there are even GUI utilities that can automatically tell you what
name the Administrator’s account is using.

Although this is the case, I still recommend renaming the
Administrator account, because doing so may deter less sophisticated hackers.
Besides, your other security mechanisms, such as your firewall, and packet
level encryption, may help prevent such utilities from functioning correctly.

Let’s assume for a moment that a hacker knows what they are
doing and they are able to quickly determine the name of your Administrator
account. They would then simply need to figure out the password. This is where
the brute force crack that I mentioned earlier comes into play. Windows is
designed so that the Administrator account can’t be locked out. This means that
a hacker is free to perform a brute force crack against the password without
fear of locking out the account.

Normally, your defenses against such an attack are frequent
password changes and reviews of the audit logs. The idea is that it takes so
long to crack a complex password that you change the password before the hacker
has the chance to try every possible password. If you’ve got auditing enabled,
you would also notice a very high number of unsuccessful login attempts.

Renaming Administrator

What a lot of people don’t realize though is that there is
another way of defending yourself against this type of attack. However, the
method that I am about to show you can be very dangerous, and you need to
carefully consider its impact before attempting this.

Unlike other versions of Windows Server, Windows Server 2003
allows you to manually disable the Administrator account. You can therefore set
other users up with administrative privileges and then disable the Administrator
account. That way, if a hacker does figure out the name of the Administrator’s
account, it is useless because the account is disabled.

The reason why this technique is so dangerous is because if
you don’t set up your alternate administrative accounts just right, you may
find yourself permanently unable to perform essential tasks. You must also keep
in mind that your alternate accounts can be locked out by incorrect password
attempts. Someone could lock you completely out of your network by purposely
entering incorrect passwords for your alternate administrative accounts. If
that happened, the only way that you could get back into your network would be
to perform an authoritative Active Directory restore, and you might not even be
able to do that if your backup software requires authentication.

SAM

While I am on the subject of stolen passwords, there is
another technique that hackers can use to steal a password. If a server is to
authenticate user’s logins, the server must know the user’s password so that it
can compare the password that has been entered against the stored password. Any
computer that’s running Windows 2000, XP, or 2003 stores user’s passwords
within the Security Accounts Manager.

Technically, the SAM doesn’t contain the passwords
themselves. The password is hashed, and then the hash is encrypted and stored
within the SAM. When you first read about the way that Windows stores
passwords, it sounds fairly secure. There are a couple of problems with the
storage method. For starters, the encryption key is stored on the server right
along with the hashes that the key encrypts. To make matters worse, the hashing
algorithm is fairly well known. In fact, there are several utilities available
off the shelf that will allow anyone who has physical access to the machine to
reset a password without knowing supplying any sort of login credentials. There
are also a few “password recovery utilities” that are allegedly able
to retrieve passwords directly from the SAM database.

Naturally, your first line of defense against such an
exploit is to make sure that your servers are kept behind a locked door to
prevent anyone from gaining physical access. If controlling physical access is
impossible where you work, or if you just want to provide an extra level of
security, then there is a technique that you can use to move the encryption key
off of the server.

Before I explain how to accomplish this, I need to warn you
that this is another dangerous operation. When you lock down the encryption
key, you have two options. Your first option is to export the encryption key to
a floppy disk. The reason why this is dangerous is because when you boot the
server it will ask for the floppy disk. If you lose the disk or if the disk
becomes damaged or unreadable, the server will be rendered unbootable. The
other down side to using this method is that you lose the ability to remotely
reboot the server because you can’t boot the server without physically
inserting a disk.

The other option that you have is to encrypt the encryption
key. This method involves assigning a password to the encryption key. When you
boot the server, you will be prompted to enter the password. Upon doing so,
Windows decrypts the encryption key, which allows Windows to access the SAM
database. In my opinion, this technique is a little safer than exporting the
encryption key to a floppy disk, but the technique still has risks. If you were
to forget the password, the server will be unbootable. Likewise, you could
potentially lose the ability to remotely reboot the server depending on how
your remote control software works. If you decide that you want to protect the
encryption key, the Microsoft
Knowledgebase contains an excellent article that explains how to go about
doing so.

One other thing that you can do to help secure the
authentication process is to use multiple authentication methods. There are
three things that can be used to authenticate a person’s identity. You can use
something that the person is, something the person has, or something that the
person knows. An out of the box Windows deployment typically uses only one of the
three authentication tests. The test used by Windows is something that the
person knows, which is of course a username / password combination.

Dual authentication

You can achieve much greater security by using at least two
authentication methods for users. Since Windows already uses something that the
user knows, you might add something that the user is (biometrics) or something
that the user has (such as a smart card).

Granting privileges

Up to this point, I have talked primarily about various
techniques that you can use to enhance the security associated with user’s
passwords. When designing a secure network, you must also consider what a user
should and should not have access to once they log in.

The current standard for user rights is that users should
have the lowest possible set of privileges that will permit them to do their
jobs. The most effective way to assign these permissions is almost always
through security groups. For example, suppose that you had some users who
needed access to the company’s payroll database. Rather than granting the
individual users permission at the NTFS level, you should create a group for
the users who will need access to the payroll database and assign permissions
to that group. Doing so makes network management a lot easier. If someone were
to ask you which users have access to the payroll database, you could simply
check the group membership rather than tracking down a bunch of individual
permissions.

As you plan your network’s security structure, I recommend
creating groups and designing the server’s folder structure in such a way that
there are no overlaps. Imagine for example that everyone in the finance
department needs access to the payroll database, but that there are a few people
from outside of finance that also need payroll access. You could theoretically
create a folder called finance and then grant the finance group permissions to
it. You could then place the payroll folder beneath the finance folder and
create a payroll group. By doing so, everyone in the payroll group and in the
finance group would have access to the payroll.

Although this arrangement would technically work, it isn’t a
good idea to configure your folder structure in this way because as the network
grows, management becomes difficult. If someone asked you who had access to
payroll, you would have to check the payroll group and the finance group,
rather than being able to check one single group. It isn’t always possible to
avoid overlapping permissions, especially when different people need different
levels of access to a folder, but your life will be a lot easier if you avoid
overlapping permissions whenever possible.

Active Directory

There is one last security trick that I want to show you.
Throughout this article, I have talked about ways that authentications can be
compromised and how groups can be configured for optimal security. All of this
information is maintained within the Active Directory. I’ll admit that the
Active Directory isn’t the easiest thing in the world to hack, but the Active
Directory database does make a tempting target because it consists of easily
recognizable files (NTDS.DIT, EDB.LOG, and TEMP.EDB) and those files reside in
a predictable location (usually C:\Windows\NTDS).

What a lot of people don’t realize is that you can make a
hacker’s job just a little bit more difficult by moving the Active Directory
database to an unexpected location. If your domain controller happens to have a
RAID array, then the array makes an excellent choice because the database is
protected from drive failure and because array’s offer better performance than
a standalone hard disk.

Moving the databases is simple, although it does require a
server reboot. Boot the machine into Active Directory Restore mode and then
enter the NTDSUTIL command followed by the Files command. Now, just use the
MOVE DB TO or MOVE LOGS To command to move the database and its log files to
the new location.

Do the basics

Although there are a lot of standard techniques for deploying
a secure network, it is often better to throw the hackers a few curve balls
than to do everything by the book. In this article, I have shown you several
security techniques that you can use to make your Windows deployment more
secure.