Security Advisor

A 12-Step Plan for File Server Security

Securely bringing a Windows file server on the network may not sound difficult. But when it's running Windows Server 2003, there's a lot you need to know to do it right.

• By Roberta Bragg
• 07/01/2003

In the May issue, I wrote about hardening the first domain controller in the first domain in a new Windows Server 2003 forest. This month, I’m going to talk about hardening a typical Windows 2003 file server. But wait: Isn’t Windows 2003 secure right out of the box? Well, it is locked down, but it’s not locked down as much as it can be. Instead, it’s locked down enough so those who don’t think about security—who simply do a default install—can build a reasonably secure server and put it on the production line.

Why a mundane file server? Well, Windows servers are most commonly used as file servers or as file and print servers. A file server is also likely to be your first production Windows 2003 system. If you’ve invested heavily in Windows 2000, or are just easing your way away from Windows NT 4.0, bringing up a file server is a pretty painless way to begin the move and start reaping the benefits of Windows 2003.

So, grab your evaluation disk (get one if you don’t have one already, at www.microsoft.com/windowsserver2003/evaluation/trial/default.mspx), do a default install and follow these 12 steps.

Caution! These steps, if used to harden your production servers, may break something. That’s right; if you lock the doors too tight, nothing can get out or get in, and that’s probably not what you want. I’ll try to steer you away from common pitfalls, but you know your networks and business needs best.

1. Configure and Populate the Operator Group
Rather than use the default Administrators group, create a group of approved operators and give them the rights needed to secure and/or maintain the server. Reserve the Administrators group as a last resort or as the ultimate authority. There are some duties you may not want day-to-day administrators to perform, and having a separate group with narrowly defined rights allows this. If, for example, you want to allow some administrators to work with users, groups and object permissions, and others to be responsible for system-wide operations such as modifying security settings, it’ll be easier to do with separate groups.

If this server will be part of a domain, consider the permission settings on the Organizational Unit (OU) within which this server will lie, as you may want to change them. Open the OU properties and clear the “allow inheritable permissions from parent to propagate to this object and all child objects” button. Then, remove all unnecessary groups. Next, add an Operators group. At minimum, retain Domain Administrators and give both groups Full Control.

2. Prepare a Security Template
If you haven’t started using security templates to secure your Windows systems, shame on you! Templates are compilations of security settings and can be used in either domain or standalone environments. They’re a great way to consolidate security configuration, enforce written security policy and provide a repeatable, auditable strategy for security. You can develop as many templates as needed. Create one for each type of system in your network or hierarchical systems, which, when imported into Group Policy, can apply security across large numbers of systems without additional work.

Window 2003 has numerous de-fault settings that make it singularly more secure than Win2K. Using a security template can help ensure those settings don’t change, as well as provide a means to further tighten security.

Templates are divided into seven major sections. All are relevant to securing file servers, and most are relevant to all servers. Plan on having two templates: one that can be applied to all servers and an incremental one just for file servers. Both templates can be applied to the file server. Where settings don’t conflict, they’ll be merged; and where they do conflict, the last template applied will win. Make sure to apply the file server template second. In a domain, of course, an OU for servers can have a Group Policy into which the basic server template can be imported, and a child OU for file servers will use the specific file server template in its GPO.

Some security settings can be hardened beyond the defaults. In the list that follows, I don’t specify the default security settings with which I agree. Many of these default settings are enormous improvements over Win2K defaults.

To see baseline settings for a domain of Windows 2003 servers, download and examine the “Windows 2003 Security Guide,” http://go.microsoft.com/fwlink/?LinkId=14845.

Included with this document are a number of pre-configured templates that match the settings discussed in the document.

Account Policies
Account Policies consist of Password Policy, Account Lockout and Kerberos Policy. Kerberos Policy is only applicable at the domain level and, thus, won’t be addressed here. Nor is this a discussion about how to set domain account policies, though you might apply some of this thought process when developing those policies. These settings, whether applied in the baseline template or a specific file server template, apply to only local accounts on the file server.

If your Windows 2003 file server is standalone, these local accounts are the ones that must be used to access resources on this server and administer it. If the server is part of a domain, it still has a local account database, and you need to address security for those accounts and groups. You may also decide to use local administrative accounts for managing some servers, especially to limit the administrative reach of these accounts within the domain. Tables 1 and 2 list the Password and Account Lockout settings that should be tightened.

I recommend decreasing Maximum Password Age from 45 days to 29 days if the server is part of a domain. Because domain user accounts will be used to get data on the file server, settings made here will have no effect; but requiring more frequent password changes can strengthen the security of local Administrator accounts.

Likewise, changing the minimum password length of passwords to 15 will have no impact on ordinary user accounts in a domain environment, but it will affect how long it takes an attacker to crack the password of local accounts. In a standalone server environment, if you must reduce the password length, require administrators, by policy, to use longer passwords.

Account Lockout Duration is the length of time an account will be locked out. A setting of “0” locks out the user until an admin resets the password. By setting this to 30 minutes, fumble- fingered or stressed individuals can access their accounts without accidentally locking themselves out. It also prevents an attacker from waiting just a brief time for the lockout to be reset before trying more guesses.

Setting the Account Lockout Threshold to 10 invalid attempts gives nervous or clumsy users enough chances to get the password correct, while also preventing an attacker from compromising the account. It would take a rare attacker to deduce a password in fewer than 10 tries (of course, if weak passwords like “password” are allowed, 10 tries may be more than enough).

Table 1. Password Policy defaults and recommendations

Setting Default Robertra Recommends Maximum Password Age 45 days 29 days and only when prompted by system Minimum Password Length seven characters for domain members 15 characters Passwords must meet complexity requirements Enabled Enabled, but admins should write their own filters

 

Table 2. Account Lockout Policy defaults and recommendations

Setting Default Roberta Recommends Account Lockout Duration Not Defined 30 minutes Account Lockout Threshold 0 10 invalid attempts

Local Policies
Local Polices include Audit Policy, User Rights and Security options. Let’s look at each in turn.

Audit Policy
Turning on Audit Object Access doesn’t generate any events but does allow requiring events at the object level. You can’t generate events by setting object level access unless Audit Object Access is turned on (see Table 3). Turning on this Audit Policy means activity involving files, folders, Registry keys and printers can be tracked. You must, however, choose which objects to monitor and the type of monitoring to do. For example, one audit setting useful for tracking executable files is “Write and Append Data.” This tracks the replacement of or changes to files, which might alert you to viruses, worms and Trojan horse attacks, as well as rogue administrator action.

You should audit the use of Privileges. Auditing Privilege Use can generate a lot of extraneous records. How-ever, in a high-security environment, knowing who’s done what is almost as important as preventing people from doing things.

Table 3. Defaults and recommended audit settings

Setting Default Roberta Recommends Audit Account Management No auditing Success and failure Audit Object access No auditing Success and failure Audit Policy change Success Success and failure Audit Privilege use No auditing Success and failure

User Rights
User rights set in a domain override user rights set on a computer. However, if a local user account is used, then rights like password policies are determined by the local policy.

Revoke those rights that ordinary users shouldn’t have, such as, “Act as part of the operating system.” Be explicit: Remember that rights not explicitly given are implicitly denied.

Security Options
Security options represent a large number of settings that can be maximized in hardening servers. Table 5, in the online version of this article, contains new Windows 2003 settings and changes in the default settings from Win2K.

Warning: Some default security settings may cause problems for legacy systems. Always test settings before deploying them in your network.

Event Log
Increase the size of the security Event Log to ensure adequate space for events.

Services
Many services are disabled by default; others aren’t installed. This is a really good thing. However, for a specific server role, it’s possible to lock down the system even tighter.

Services not installed should be marked as Disabled in the template. This way, if the service is installed, it can’t run.

Permissions should be set on the services in the template. Restrict who can stop, start and disable services. Additional services can be safely disabled, as they’re not needed for the file server’s normal operation.

Two file-system-specific services should be disabled in certain circumstances: the Distributed File System (DFS) and the File Replication Service (NTFRS). DFS manages logical volumes distributed across a LAN or WAN. Disabling DFS requires the user to know the names of all servers and shares in order to access them, so it should be disabled in a high-security network. NTFRS enables automatic maintenance and copying of files on multiple servers. It’s required by Active Directory on domain controllers (and is often used with DFS) but not needed on a non-DC box like a file server.

Never use a domain account as a service account. Service accounts often require administrative privileges, and their passwords are cached in the LSA secrets. If a computer is compromised, the attacker or rogue local administrator can obtain these secrets (using available attack tools) and use them to attack other domain computers.

3. Determine Repeatable Strategy for Applying the Template
Templates can be imported into domain and OU Group Policies. This allows them to be distributed across multiple computer accounts and periodically refreshed. Security templates can be applied to standalone computers by using the Security Configuration and Analysis tool or the secedit command. Batch files or scripts can be written to refresh the settings.

Store templates in a safe place, as they can be used to reapply policy settings or audit security on the file servers. If all copies of templates are stored publicly, they can be altered to match less restrictive settings.

Before reconfiguring settings through templates, do a complete backup—including the System State, which in-cludes Registry settings.

4. Set Restricted Groups
Use local Group Policy (or a GPO in the OU) to set restricted groups. Restrict the local Administrators group and any special Operators groups created. Add approved user accounts to the restricted group in the policy. Users and groups added to these groups in the normal manner will be automatically removed unless also added here. Restricting the administrators who can change these settings prevents unauthorized additions to the groups.

5. Write and Apply IPSec Policy
Hardening file servers is difficult, as they usually provide services requiring NetBIOS-related protocols. These protocols—Server Message Blocks (SMB) and Common Internet File System (CIFS)—can provide tidbits of attacker-useful information to unauthorized individuals.

You can restrict access to these and other protocols by configuring and assigning IPSec Policies. Set an IPSec rule that blocks all access to all ports, and then applies more specific rules/filters, enabling access from specific computers or to specific ports. Some examples of what can be done through IPSec include:

Allowing access from any source address to the file server for ports 445, 137, 138 and 139, but denying this kind of blanket access to other services.

Restricting access to terminal services (port 3389) by allowing access from specific computers only. This helps to compensate for the blocking of RPC traffic used by many management services.

Allowing all traffic to and from the file server and domain controllers.

Allowing traffic between the file server and Microsoft Operations Manager.

6. Ensure Correct Time
Time is critical for many reasons:

NTLMv2 authentication requires client and server clocks to be within 30 minutes of each other.

Kerberos only allows a five-minute difference.

Event correlations between computers won’t be possible if there are time differences.

Evidence must be correctly identified to be valid. The time recorded must be correct to use logs in proving hack attempts.

Windows 2003 domain members will time-synch with their domain. However, you must ensure correct configuration of the PDC emulator in the domain with an accurate time source. Standalone servers require their own configuration.

7. Set Specific Account Restrictions
Account restrictions can be set on individual accounts. You can limit logon hours, restrict domain workstations from which a user can log on, prevent accounts from being delegated and so on. In a domain, these settings are made from the Account page of the user properties.

8. Set Local Server Security Settings
In a domain, security templates can automate security settings for groups of computers. Some special settings, though, can’t be automated. For example, the Guest user account, the Guests group and the Support 388045a0 account all have unique SIDs, which means these accounts can’t be centrally set. Set local policies where necessary.

9. Monitor for Attack Indicators
Event 539 reads “Logon Failure, the account was locked out at the time the logon attempt was made.” Seeing a large number of these events in the log should be interpreted as a possible password-cracking attack. A large number of such indicators exists. I’ll examine these in a future column.

10. Use NTFS
You can’t set file ACLs and SACLs on FAT volumes. Security relies on the ability to set defense in depth. A large part of that is file permissions.

11. Use Administrative Template Settings
A number of security settings aren’t available in Security Templates. Instead, they can be set through the Administrative Templates area of Group Policy. (On a standalone file server, load the local Group Policy by using a custom MMC.)

One important setting to disable is Error Reporting, through Computer Configuration | Administrative Templates | System | Error Reporting. Error reporting can contain sensitive or confidential data. The data crosses the network in clear text, making it easy to intercept.

12. Document, Secure and Maintain Security Settings
If the security settings for the file server can be modified, the file server won’t be secure. Obvious, isn’t it? But you still must take steps to ensure that settings can’t be modified by unauthorized individuals. If, however, settings are modified, you have the ability to determine it. The security and audit settings mentioned previously can help. Another tool is Security Configuration and Analysis. Use it to verify that security is in compliance with agreed-upon template settings. Finally, store those templates in a secure place so that modifications to the online templates don’t skew the analysis of approved security policy.