Friday, December 17, 2010
Anu
Security is a top concern for network administrators. Deploying a newoperating system like Windows Server 2003 requires learning some newsecurity tricks.
Security is an increasingly important topic for networkadministrators. It's an ongoing battle to make sure you've installed all of thelatest updates along with keeping up to date with all of the developingthreats. Properly securing server begins with planning. When you're deployingWindows Server 2003, you can use these tips to make sure you've done so whileproperly securing it.That being thecase, I decided to focus this article on some of the lesser known hardeningtechniques. These techniques are no substitute for the basics, but whencombined with standard security techniques they can help you to build a verysecure network. For information on the essentials, I recommend checking outMicrosoft's Windows Server 2003 Security Guide. You can download it for free atMicrosoft'sWeb site.
Protect your authentication mechanisms
There's an old proverb stating that a chain is only asstrong as its weakest link. That saying is especially true when you are talkingabout a network's chain of security mechanisms. I know a lot of people whospend countless hours making sure that every packet flowing across the networkis authenticated and encrypted, and that all of the files on the server's harddisk have the proper permissions assigned to them. Such measures are important,but the fact is that the vast majority of hacks are perpetrated by usinglegitimate user accounts.User IDs and passwords
In most networks, the user accounts themselves are by farthe weakest part of the network's entire security infrastructure. A hacker onlyneeds to know two pieces of information (a user name and a password) to be ableto access anything on your entire network. Sure, encrypting all of the packetsas they flow across the wire will help to prevent a hacker from sniffingpasswords, but there are plenty of other ways that hackers can acquirepasswords.One of the oldest password acquisition methods still worksto this day. That's a brute force crack. Like I said, a hacker must have ausername 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 namefor you; Administrator. That means that hackers only need to figure out theAdministrator's password in order to gain access to your network.
Microsoft has long recommended that you change the name ofthe Administrator account so that hackers won't know what it is. The problem isthat 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 fairlyeasy to figure out what the account has been renamed to, just by examining theSIDs. In fact, there are even GUI utilities that can automatically tell you whatname the Administrator's account is using.
Although this is the case, I still recommend renaming theAdministrator account, because doing so may deter less sophisticated hackers.Besides, your other security mechanisms, such as your firewall, and packetlevel encryption, may help prevent such utilities from functioning correctly.
Let's assume for a moment that a hacker knows what they aredoing and they are able to quickly determine the name of your Administratoraccount. They would then simply need to figure out the password. This is wherethe brute force crack that I mentioned earlier comes into play. Windows isdesigned so that the Administrator account can't be locked out. This means thata hacker is free to perform a brute force crack against the password withoutfear of locking out the account.
Normally, your defenses against such an attack are frequentpassword changes and reviews of the audit logs. The idea is that it takes solong to crack a complex password that you change the password before the hackerhas 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 isanother way of defending yourself against this type of attack. However, themethod that I am about to show you can be very dangerous, and you need tocarefully consider its impact before attempting this.Unlike other versions of Windows Server, Windows Server 2003allows you to manually disable the Administrator account. You can therefore setother users up with administrative privileges and then disable the Administratoraccount. That way, if a hacker does figure out the name of the Administrator'saccount, it is useless because the account is disabled.
The reason why this technique is so dangerous is because ifyou don't set up your alternate administrative accounts just right, you mayfind yourself permanently unable to perform essential tasks. You must also keepin mind that your alternate accounts can be locked out by incorrect passwordattempts. Someone could lock you completely out of your network by purposelyentering incorrect passwords for your alternate administrative accounts. Ifthat happened, the only way that you could get back into your network would beto perform an authoritative Active Directory restore, and you might not even beable to do that if your backup software requires authentication.
SAM
While I am on the subject of stolen passwords, there isanother technique that hackers can use to steal a password. If a server is toauthenticate user's logins, the server must know the user's password so that itcan compare the password that has been entered against the stored password. Anycomputer that's running Windows 2000, XP, or 2003 stores user's passwordswithin the Security Accounts Manager.Technically, the SAM doesn't contain the passwordsthemselves. The password is hashed, and then the hash is encrypted and storedwithin the SAM. When you first read about the way that Windows storespasswords, it sounds fairly secure. There are a couple of problems with thestorage method. For starters, the encryption key is stored on the server rightalong with the hashes that the key encrypts. To make matters worse, the hashingalgorithm is fairly well known. In fact, there are several utilities availableoff the shelf that will allow anyone who has physical access to the machine toreset a password without knowing supplying any sort of login credentials. Thereare also a few "password recovery utilities" that are allegedly ableto retrieve passwords directly from the SAM database.
Naturally, your first line of defense against such anexploit is to make sure that your servers are kept behind a locked door toprevent anyone from gaining physical access. If controlling physical access isimpossible where you work, or if you just want to provide an extra level ofsecurity, then there is a technique that you can use to move the encryption keyoff of the server.
Before I explain how to accomplish this, I need to warn youthat this is another dangerous operation. When you lock down the encryptionkey, you have two options. Your first option is to export the encryption key toa floppy disk. The reason why this is dangerous is because when you boot theserver it will ask for the floppy disk. If you lose the disk or if the diskbecomes damaged or unreadable, the server will be rendered unbootable. Theother down side to using this method is that you lose the ability to remotelyreboot the server because you can't boot the server without physicallyinserting a disk.
The other option that you have is to encrypt the encryptionkey. This method involves assigning a password to the encryption key. When youboot the server, you will be prompted to enter the password. Upon doing so,Windows decrypts the encryption key, which allows Windows to access the SAMdatabase. In my opinion, this technique is a little safer than exporting theencryption key to a floppy disk, but the technique still has risks. If you wereto forget the password, the server will be unbootable. Likewise, you couldpotentially lose the ability to remotely reboot the server depending on howyour remote control software works. If you decide that you want to protect theencryption key, the MicrosoftKnowledgebase contains an excellent article that explains how to go aboutdoing so.
One other thing that you can do to help secure theauthentication process is to use multiple authentication methods. There arethree things that can be used to authenticate a person's identity. You can usesomething that the person is, something the person has, or something that theperson knows. An out of the box Windows deployment typically uses only one of thethree authentication tests. The test used by Windows is something that theperson knows, which is of course a username / password combination.
Dual authentication
You can achieve much greater security by using at least twoauthentication methods for users. Since Windows already uses something that theuser knows, you might add something that the user is (biometrics) or somethingthat the user has (such as a smart card).Granting privileges
Up to this point, I have talked primarily about varioustechniques that you can use to enhance the security associated with user'spasswords. When designing a secure network, you must also consider what a usershould and should not have access to once they log in.The current standard for user rights is that users shouldhave the lowest possible set of privileges that will permit them to do theirjobs. The most effective way to assign these permissions is almost alwaysthrough security groups. For example, suppose that you had some users whoneeded access to the company's payroll database. Rather than granting theindividual users permission at the NTFS level, you should create a group forthe users who will need access to the payroll database and assign permissionsto that group. Doing so makes network management a lot easier. If someone wereto ask you which users have access to the payroll database, you could simplycheck the group membership rather than tracking down a bunch of individualpermissions.
As you plan your network's security structure, I recommendcreating groups and designing the server's folder structure in such a way thatthere are no overlaps. Imagine for example that everyone in the financedepartment needs access to the payroll database, but that there are a few peoplefrom outside of finance that also need payroll access. You could theoreticallycreate a folder called finance and then grant the finance group permissions toit. You could then place the payroll folder beneath the finance folder andcreate a payroll group. By doing so, everyone in the payroll group and in thefinance group would have access to the payroll.
Although this arrangement would technically work, it isn't agood idea to configure your folder structure in this way because as the networkgrows, management becomes difficult. If someone asked you who had access topayroll, 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 toavoid overlapping permissions, especially when different people need differentlevels of access to a folder, but your life will be a lot easier if you avoidoverlapping 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 becompromised and how groups can be configured for optimal security. All of thisinformation is maintained within the Active Directory. I'll admit that theActive Directory isn't the easiest thing in the world to hack, but the ActiveDirectory database does make a tempting target because it consists of easilyrecognizable files (NTDS.DIT, EDB.LOG, and TEMP.EDB) and those files reside ina predictable location (usually C:\Windows\NTDS).What a lot of people don't realize is that you can make ahacker's job just a little bit more difficult by moving the Active Directorydatabase to an unexpected location. If your domain controller happens to have aRAID array, then the array makes an excellent choice because the database isprotected from drive failure and because array's offer better performance thana standalone hard disk.
Moving the databases is simple, although it does require aserver reboot. Boot the machine into Active Directory Restore mode and thenenter the NTDSUTIL command followed by the Files command. Now, just use theMOVE DB TO or MOVE LOGS To command to move the database and its log files tothe new location.
Do the basics
Although there are a lot of standard techniques for deployinga secure network, it is often better to throw the hackers a few curve ballsthan to do everything by the book. In this article, I have shown you severalsecurity techniques that you can use to make your Windows deployment moresecure.Thanks....
Posted in
0 comments:
Post a Comment