Top 10 Windows Security Configurations

[LEFT][CODE]http://www.windowsecurity.com/articles/Top-10-Windows-Security-Configurations-Where-How-Part1.html[/CODE][B][SIZE=3]

PART-1 [/SIZE][/B]

[B]Introduction[/B]

There are always top 10 lists that grab your attention; and this one should be no different. Windows provides many settings, options, and areas of configuration. In reality, this might be a Top 100 list, but there is only room for 10. This list is created from years of educating and asking myself questions like, “what do administrators do and not do when it comes to security?” This list seems to be where administrators fail to look and setup security. It also includes a few settings that are not all that well known, but certainly have huge rewards for securing your Windows environment. I have tried to include references to other articles that go deeper into the topic, in case you want to read more about the security setting being suggested.
[CENTER][B][URL="http://www.amazon.com/exec/obidos/ASIN/073562514X/isaserver1-20/"]
[/URL][/B][/CENTER]
[B]1. Service Account Restricting Workstation Logon[/B]

Since service accounts are designed to support services running on only a limited number of computers, it makes sense to limit the scope as to where the service can logon. This will help with overall security attack surface and will also narrow the attacks to just the computers where the service account is allowed to logon when being attacked by the service account itself.
The setting to restrict the workstations where the service account can logon is located where the user is configured, which is Active Directory Users and Computers within Active Directory. When you find the service account, right-click on it and select properties. Then, maneuver over to the Account tab. From there, select the Log On To button, which will display the Logon Workstations dialog box, shown in Figure 1.
[IMG]http://www.windowsecurity.com/img/upl/image0021249909053183.jpg[/IMG]
[B]Figure 1:[/B] This configuration allows the administrator to restrict where the service account can logon
For more info on service accounts, follow this [URL="http://www.windowsecurity.com/articles/Controlling-Service-Security-Windows-Server-2008.html"]link[/URL].
[B]2. Administrator Can Not Access Computer from Network[/B]

This depends on the way you have been taught to use the Administrator account. If you were taught by me or another security professional, you should know not to use this account unless you are performing a disaster recovery. So, in that instance, you will be logging in to the box to perform the recovery, not over the network. If you can log on over the network, you should be using your admin account. A security option example is to limit the Administrator account to only have the ability to logon locally, not over the network.
This setting is in a GPO, and of course, all GPO linking and application rules apply. You will want to edit your GPO linked to the appropriate organizational unit, then open up the GPO to the following path; Computer Configuration|Windows Settings|Security Settings|Local Policies|User Rights Assignment|Deny access to this computer from the network, which can be seen in Figure 2.
[IMG]http://www.windowsecurity.com/img/upl/image0041249909053198.jpg[/IMG]
[B]Figure 2:[/B] You can limit the Administrator account to only have the ability to logon locally to your servers
For more information on this topic take a look at this [URL="http://www.windowsecurity.com/articles/Protecting-Administrator-Account.html"]article on www.WindowSecurity.com[/URL].
[B]3. Ensure Membership in Local Administrators Group[/B]

When you provide a user the ability to have administrative control over a server or their desktop, strange things might happen. For the most part, these are usually internet security risks. The solution? Remove the Domain Admins and local Administrator from the local Administrators group.
To ensure that both of the accounts have membership in the local Administrators group, in every server and desktop, you can use Group Policy. You will need to access the Group Policy Preferences and open the Group Policy Object to the following node: Computer Configuration\Preferences\Control Panel Settings\Local Users and Groups\New\Local Group, which is shown in Figure 3.
[IMG]http://www.windowsecurity.com/img/upl/image0051249909053198.jpg[/IMG]
[B]Figure 3:[/B] Ensure membership in the local Administrators group is secure
For more info on this topic, check the following [URL="http://www.windowsecurity.com/articles/Securing-Local-Administrators-Group-Every-Desktop.html"]link[/URL] out.
[B]4. Reset Local Administrator Password[/B]

For a while now my favorite question has been; “When was the last time you reset the local Administrator password on every desktop?” Every time I seem to get the same answers. “During installation”, “three years ago”, “never”, which are all unacceptable! This is a key configuration and one that should be addressed on a monthly to quarterly basis. You do not want worms, viruses, and attackers having that much time against your local computers by not resetting the local Administrator password. With Group Policy Preferences this has become increasingly easy!
To configure this setting you will need to expand a Group Policy Object that understands Group Policy Preferences.
[B]Note:
[/B]Like the previous setting, this must be done on a computer running Windows Sever 2008 or Vista SP1, but is backwards compatible to Windows XP SP2 and Windows Server 2003 SP1. Follow this [URL="http://www.windowsecurity.com/articles/Group-Policy-related-changes-Windows-Server-2008-Part3.html"]link[/URL] for more info on this topic.

If you open the GPO in the editor to Configuration\Preferences\Control Panel Settings\Local Users and Groups\New\Local User, as seen in Figure 4.
[IMG]http://www.windowsecurity.com/img/upl/image0061249909053214.jpg[/IMG]
[B]Figure 4:[/B] You can reset the local Administrator password on each desktop from a single GPO
For more information on this topic, [URL="http://www.windowsecurity.com/articles/Group-Policy-related-changes-Windows-Server-2008-Part3.html"]click here[/URL].
[B]5. Enable UAC for Administrators[/B]

I know, I know… you do not like UAC. However, you owe it to your company to not only install Vista/7, but to enable UAC for the most secure level. There is of course no time to go into the nitty gritty details here, but trust me, UAC is awesome for administrators.
To configure this setting you will need to get into a Group Policy Object in edit mode. From there, you will open up the following node: Computer Configuration|Windows Settings|Security Settings|Local Policies|Security Options|User Account Control: Admin Approval Mode for Built-in Administrator account AND User Account Control. Behavior of the elevation prompt for administrators in Admin Approval Mode is shown in Figure 5.
[IMG]http://www.windowsecurity.com/img/upl/image0081249909053214.jpg[/IMG]
[B]Figure 5:[/B] UAC has two settings that control how administrators will use the feature
If you would like more information on the topic, take a look at this [URL="http://www.windowsecurity.com/articles/Understanding-User-Account-Control-Vista.html"]article[/URL].
[B]Summary[/B]

Even though many in the IT industry like to slam Microsoft for not being secure, it can be secured if the administrators take the time to do so. This article tackles some of the most under configured and hard to reach (and understand) security settings within Windows. Each security setting adds just that much more for security to your Windows environment. Here, we tackled settings related to the service accounts running on key servers, as well as the local Administrators group and local Administrator account on every desktop and server in the organization. That is powerful configuration! In the next installment, we will tackle more security settings that are a must for configuration to help protect your Windows environment to the level that it deserves and you owe to your company!

[/LEFT]

[LEFT][CODE]http://www.windowsecurity.com/articles/Top-10-Windows-Security-Configurations-Where-How-Part2.html[/CODE]

[B][SIZE=3]PART-2[/SIZE][/B]

[B]Introduction[/B]

Now, on with the countdown! In my last installment, I covered 5 of the most important security settings that you need to set for your Windows environment. Those were great and important, but to be honest, I like these 5 even more. If you feel confident in certain security technologies by Microsoft, some of these might change your mind! I travel around the world educating admins and auditors on Windows security, and in turn, their comments and debates always make for interesting discussions. Trust me, this is the best place to understand how the technology works. Let us dive straight into it.
[B]Note:
[/B]If you want to see the first 5 configurations from the previous installment, you can find them [URL="http://www.windowsecurity.com/articles/Top-10-Windows-Security-Configurations-Where-How-Part1.html"]here[/URL].
[CENTER][B][URL="http://www.amazon.com/exec/obidos/ASIN/073562514X/isaserver1-20/"]
[/URL][/B][/CENTER]
[B]6. Remove LanManager use[/B]

When you consider the all around security features for Windows, you have to keep in mind the days when authentication was handled by LanManager, or LM as it is sometimes referred to. Or do you? Well, unfortunately, Microsoft does still support LM in many of the operating systems, which can lead to a significant “hole” in your security wall against attackers. LM has to be one of the worst authentication protocols ever built, simply because of the way that it attempts to protect the password hash. Therefore, you need to take all precautions to protect your Windows environment from using it.
There will be two different settings that you want to configure in order to protect against the use of LM. The first protects against LM hashes, sent across the network. The second protects against LM hashes that are stored in the accounts database.
To protect the first portion of LM, you can configure a Group Policy Object policy. To set the policy, which I suggest you place in a GPO linked to the domain node, go to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options. Here you will find the LAN Manager Authentication Level policy, seen in Figure 1.
[IMG]http://www.windowsecurity.com/img/upl/image0021254833949388.jpg[/IMG]
[B]Figure 1:[/B] LAN Manager authentication levels can be set using Group Policy
Notice that in Figure 1 the policy is set to Send NTLMv2 response only. This is level 3 out of 6 levels (in our case it is actually level 4, but level 1 is named level 0, due to the Registry value that is configured when you select it. You can also argue that they refer to it as level 0 because it provides “zero” security!) You can see the 6 levels, level 0-5, in Figure 2.
[IMG]http://www.windowsecurity.com/img/upl/image0041254833949388.jpg[/IMG]
[B]Figure 2:[/B] The 6 levels of LAN Manager authentication levels
Ideally, you will want to configure this to level 5, Send NTLMv2 response only, Refuse LM and NTLM, but you might find that some legacy clients and/or legacy software have issues with this setting. You will need to test before you implement it in a company environment.
The second setting that you will want to set in order to protect LM is in the same GPO path. This setting, not configured on most versions of Windows and Active Directory, helps protect the LM hash as it sits in the Active Directory database or the local Security Accounts Manager (SAM) on servers and desktops. The setting, [I]do not store LAN Manager hash value on next password change[/I], can be seen in Figure 3.
[IMG]http://www.windowsecurity.com/img/upl/image0061254833949388.jpg[/IMG]
[B]Figure 3:[/B] The storage of the LAN Manager hash can be controlled with Group Policy
This setting has only two options for you: Enabled or Disabled. Ideally, you want this setting to be [I]enabled. [/I]Like this, it will not store the LAN Manager hash value in the database the next time the user changes password.
[B]7. Set fine grained passwords for administrators[/B]

This is possibly what everyone reading this article is waiting for. I know for a fact that 90% of all Windows administrators wanted this technology for years, and now it is here! The technology is called “[I]fine grained password policies[/I]” (FGPP) and it allows for multiple password policies in the same Active Directory domain. Yes, this means that IT admins can have a minimum password length of 20 characters! Finance users can have a minimum password length of 15 characters, and executives can have a minimum password length of 2 characters (which is about all they can handle! Just kidding!).
Here is the trick… this is NOT configured using Group Policy! That’s right; you configure FGPP in the raw AD database. The best way to do this is to use ADSIEdit.msc, but there are other companies that have solutions with much simpler settings for you to set these up (Specopssoft’s [URL="http://www.specopssoft.com/wiki/index.php/SpecopsPasswordPolicybasic/SpecopsPasswordPolicybasic/"]Password Policy Basic[/URL] tool for example). For more information on FGPP, check out [URL="http://www.windowsecurity.com/articles/Configuring-Granular-Password-Settings-Windows-Server-2008.html"]Jakob Heidelberg’s article[/URL] on WindowSecurity.com.
However, I want to at least give you the run down on what you need to get these running:



[LIST=1][*]Every domain controller must be running Windows Server 2008 or greater[*]The domain must be at Windows Server 2008 functional level[*]You must have all users within a department located in a group, which is how the permissions work for FGPP[/LIST]
There are alternatives to using the built-in Microsoft password policies in Group Policy or the fine grained password policy solution. These solutions require a third party installation, but they do not just replace what Microsoft provides, they also give you much more granular control over passwords. Every admin knows that basic password controls do not help with advanced password cracking technologies. So, solutions like Specops Password Policy gives you control over what Microsoft does, plus:

[LIST][*]Including a dictionary list of words that users can use[*]Forcing 4 out of 4 characters in the password[*]Going above the 14 character limit for a password[*]Creating custom rules for password formatting[*]Better communication with end user for when they are trying to input a complex password, telling them where they are close and how they need to configure the password to meet the requirements[/LIST]
[B]Summary[/B]

Taking care of LAN Manager can go a long way. Consider the fact that if an attacker gains access to even a single admin level user, the entire network is compromised. Therefore, taking the precautions and making the configurations that I suggest in this article are essential. You need to cover both basis for LAN Manager: over the network interception and the storage of the LAN Manger hash in Active Directory and the local SAM on every desktop and server. Establishing a good, in-depth password policy is essential, which is why Microsoft gave you the ability to setup fine grained password policies. The ability for the company to have different password policies for a single Active Directory domain should immediately allow better security, more granular control, and an overall cost savings. All this of course, saving you from having to purchase a third party solution in order to install multiple Active Directory domains. In the final installment of this series, I will cover some technologies that most admins are not even aware of!

[/LEFT]

[LEFT][CODE]http://www.windowsecurity.com/articles/Top-10-Windows-Security-Configurations-Where-How-Part3.html[/CODE]

[B][SIZE=3]PART-3[/SIZE][/B]

[B]Introduction[/B]

For my last installment in this series of articles, I am going to cover three additional settings that many of you might not know about. If you do know about them, there is a chance you might not be aware of the amazing security benefits that come with implementing them in your Windows environment. I will first cover how Protected Mode with Internet Explorer 7/8 helps protect your computer and in essence, the entire network. Then, we will go over access based enumeration (ABE), which is a technology that has helped more than one company meet compliance regulations. Finally, those pesky anonymous connections must be protected, especially for your older systems, but it is always good to check and ensure they are not allowed for your newer systems too. To read the first two installments of this series, all you need to do is click [URL="http://www.windowsecurity.com/articles/Top-10-Windows-Security-Configurations-Where-How-Part1.html"]here[/URL] for Part 1 and [URL="http://www.windowsecurity.com/articles/Top-10-Windows-Security-Configurations-Where-How-Part2.html"]here[/URL] for Part 2!
[CENTER][B][URL="http://www.amazon.com/exec/obidos/ASIN/073562514X/isaserver1-20/"]
[/URL][/B][/CENTER]
[B]8. Configure IE security for Protected Mode[/B]

Windows Internet Explorer version 7 and 8 come with a great security feature, which is named Protected Mode. Protected Mode is more than just a setting that “hopes” to actually protect you whilst browsing on the Internet, it works well, and I am living proof of it!
In order to configure IE 7/8 for Protected Mode, you will need to be running Windows Vista or Windows 7. Windows XP can not utilize Protected Mode, due to the fact that UAC (User Account Control) does not run on this operating system. If you open up the Internet Options from within IE and select the Security tab, you will be able to toggle Protected Mode on/off, as seen in Figure 1.
[IMG]http://www.windowsecurity.com/img/upl/image0021256991755031.jpg[/IMG]
[B]Figure 1:[/B] Protected Mode is a check box in the Security tab for your Internet Explorer Settings
As I just stated, this is only valid on Windows Vista and 7, as they are the only versions of Windows that support UAC. Logic will prevail here, in that UAC also needs to be configured! All of the great benefits that UAC provides for the local applications and OS features, will apply to protect you while on the Internet.
Protected Mode also provides security for you with the use of integrity levels. Integrity levels are new for Vista (and beyond), and control which level of the OS the application runs within. There are 4 levels: low, medium, high, system. IE 7/8 runs in low, which means it can only communicate with other applications running in low. Nearly all other applications run in medium! So, anything nasty from the Internet can not jump to another application, because low applications can’t communicate with medium applications.
[B]9. Use ABE for Shared Folders[/B]

Access Based Enumeration (ABE) is a technology that Microsoft released with Windows Server 2003 R2. To understand what ABE does for you, let me give you a scenario.
Imagine that you have a folder on a server, say the folder is named Patients. Of course, under the Patients folder you have additional folders with patient names. This would be the main source of documents used to manage patient information for your doctor office. The Patients folder has been shared, so when anyone types in \\server1\patients to their Run command, they see the full list of patient folders. The issue here is that this breaks HIPAA compliancy!
ABE is a technology that will allow the administrator to set up security on each of these types of folders, by just using the standard NTFS security access control list, but with ABE on top, only those users that have access to the contents will see the contents. In our example, now the patient folder names will not be visible to anyone, except those that have permissions to them!
The easiest way to set up ABE is to use Group Policy. If you have Group Policy Preferences configured for your enterprise, you will simply go into a GPO and expand the following path: Computer Configuration\Policies\Windows Settings\Network Shares. Right-click on the Network Shares and create a new Network Share. (If you do not have Group Policy Preferences yet, they are free and you can read [URL="http://www.windowsecurity.com/articles/Group-Policy-related-changes-Windows-Server-2008-Part3.html"]here[/URL] how to get them into your environment). A dialog box like that shown in Figure 2 will appear.
[IMG]http://www.windowsecurity.com/img/upl/image0041256991820109.jpg[/IMG]
[B]Figure 2:[/B] ABE is configurable via a Group Policy Object
All you need to do here is to configure the policy to share your folder, then, at the bottom of the dialog box for the policy, enable ABE! That is all you need to do.
[B]10. Ensure anonymous connections are denied [/B]

Anonymous connections are something that you need to concern yourself with, especially for older operating systems. For your newer Windows XP/2003 and greater systems, you just need to ensure that the correct Group Policy settings are configured. This is a quick check and even easier configuration.
To check that your computers (yes, this should be checked on each computer individually) are set up to protect against anonymous connections, you will run secpol.msc from either the Start-Run menu or a command prompt. Regardless, once you have the window open that secpol.msc launches, which can be seen in Figure 3, you will expand the following nodes: Local Policies\Security Options.
[IMG]http://www.windowsecurity.com/img/upl/image0061256991820109.jpg[/IMG]
[B]Figure 3:[/B] Secpol.msc opens up the local security settings on your computer
Notice that I have the key anonymous settings highlighted and the correct, best practice settings configured for each within the figure. These settings will help protect your computer from anonymous connections, users will not be able to get SIDs for user accounts, enumerate the list of users within the database (either local SAM or Active Directory), and will not be able to get a listing of the shares (normal, hidden, and hidden administrative shares) on the computer.
[B]Summary[/B]

This installment of our security settings for your Windows environment takes us to a full circle of amazing security settings that you need to include for all of your Windows computers. In this article, we have gone over how to secure Internet Explorer, help secure your shared folders, and then finally anonymous access. With IE, you need to be running the latest version, either 7 or 8. You also need to be running Windows Vista or 7, in order for Protected Mode (with UAC) to work effectively. With ABE, you are now able to restrict what a user can see in a browse list, completely based on the NTFS permissions that are already configured on the resource. This will help make you compliant with HIPAA, SOX, FDCC, and any other compliance that requires that resources should not be seen by users that do not have access to them. Finally, we looked at anonymous connections. Anonymous connections have been given some excellent control settings, but you need to ensure they are set properly. Of course, before you set them settings to the highest level of security, you need to test to ensure that “things” don’t break on your network with them at the highest levels. If you take all of the settings in all three of these articles in the series, you will be moving in a great direction to making your Windows network more secure

[/LEFT]