Security is a top concern for network administrators. Deploying a new operating system like Windows Server 2003 requires learning some new security tricks. Brien Posey gives you a list of his favorites in this article.
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.
Source:techrepublic.com
No comments:
Post a Comment