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.
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,
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
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 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
|Table 1. Password
Policy defaults and recommendations
|Maximum Password Age
||29 days and only when prompted
|Minimum Password Length
||seven characters for domain
|Passwords must meet complexity
||Enabled, but admins should write
their own filters
|Table 2. Account
Lockout Policy defaults and recommendations
|Account Lockout Duration
|Account Lockout Threshold
||10 invalid attempts
Local Polices include Audit Policy, User Rights and Security options.
Let’s look at each in turn.
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
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
|Table 3. Defaults
and recommended audit settings
|Audit Account Management
||Success and failure
|Audit Object access
||Success and failure
|Audit Policy change
||Success and failure
|Audit Privilege use
||Success and failure
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 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
Warning: Some default security settings may
cause problems for legacy systems. Always test settings before deploying
them in your network.
Increase the size of the security Event Log to ensure adequate space for
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
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
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
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.