Multi-user systems are security holes in and of
themselves. The simplest systems—those used by only one person—are the
easiest ones to secure because there's much less diversity and variance
of usage on the part of one person than there is on the part of many.
Unfortunately, most of our IT environments require multiple user
accounts, so the following section focuses on some prudent ways to lock
down Windows systems, including Windows Server 2003 machines and
associated client workstation operating systems.
1. Password Requirements
Long passwords are more
secure, period. As you might suspect, there are more permutations and
combinations to try when one is attempting to crack a machine via brute
force, and common English words, on which a dictionary attack can be
based, are generally shorter than eight characters in length. By the
same token, passwords that have not been changed in a long time are also
insecure. Although most users grudgingly change their passwords on a
regular basis when encouraged by administrators, some accounts—namely
the Administrator and Guest accounts—often have the same password for
life, which makes them an easy target for attack.
To counter these
threats, consider setting some basic requirements for passwords. To set
these restrictions on individual workstations and Windows Server 2003
member servers, follow these steps:
Open
the MMC and navigate to the Local Security Policy snap-in. You usually
access this by selecting Start → All Programs → Administrative Tools.
Navigate down the tree, through Security Settings, to Account Policies.
Enable the Passwords must meet complexity requirements setting.
Change
the Minimum password length to a decent length. I recommend eight
characters. (I must note here that I prefer passwords longer than 14
characters, but I predict that you will encounter serious user
resistance to such a move.)
Change the Maximum password age setting to a conservative setting. I recommend 90 days.
You can accomplish the
same through GP if you have a Windows domain by selecting an appropriate
GPO and loading the Group Policy Object Editor .
Keep in mind that changes to the domain password policy will affect all
machines within the scope of the GP. The configuration tree within the
Group Policy Object Editor remains the same.
One final note on passwords:
encourage your users to use passphrases and not just passwords. This is
a great way to enforce a 14-character minimum password length while
still making it easy for your users to remember their codes. For
example, suggest that they use something such as "My dog is named
Molly!" as a password instead of something such as "jsx8q6sv8qtr3r."
Tell your users to type their passwords in the password entry box as
though they were typing into Microsoft Word or another common word
processing program. Windows can accept it, and your users are more
likely to remember it.
2. Account Lockout Policies
Three old-fashioned methods of gaining unauthorized access to a system are to attempt authentication using the following:
A well-known username (e.g., administrator)
A username not known but derived logically (e.g., admin)
A different password for the username on each attempt, repeating as often as possible
Windows can thwart these styles of attack using an account lockout
policy, which will disable an account for a specified period after a certain number of unsuccessful logon attempts.
To set the account lockout policy, follow these steps:
Open the MMC and load the Group Policy Object Editor for an appropriate GPO, or navigate to the Local Security Policy snap-in.
Navigate down the tree, through Security Settings, to Account Policies.
Click Account Lockout Policy.
Set the Account lockout threshold to a reasonably small number. I recommend three bad login attempts.
Set
both the Account lockout duration and the Reset account lockout after
options to 15 minutes. This setting resists attack while not seriously
imposing on users who just suffer from "typo syndrome."
As with password policy, you can configure account lockout policy at the local
computer or domain level. However, because the password policies are
domain dependent, the "local" level is in affect only when the computer
is not logged onto the domain. |
|
3. Local Options
In addition to
securing local accounts, the newer Windows platforms give you the
ability to lock down certain rights and configurations on the local
computer in addition to any domain security policy that might be
configured. Several of the available options do little to thwart
attacks, so in this section I'll cover the six most effective changes
you can make to your local security policy.
You can enable all of the
hardening suggestions in this section through the Security Options
section of the Local Security Policy snap-in to the MMC. You usually can
find this snap-in under Start, All Programs, and Administrative Tools.
To get to the appropriate section, navigate the snap-in tree by
selecting Computer Configuration, Windows Settings, Security Settings,
and Local Policies. Then click Security Options, and the different
configuration switches will appear in the righthand pane.
The instructions in this section assume that you have already loaded the snap-in and navigated to the appropriate section.
3.1. Anonymous access
Windows allows access
by an anonymous user to many shares and files using a null user
account; this is a security hazard, of course. You still can enable
anonymous access
to files and directories by explicitly granting rights to the ANONYMOUS
USER account in Windows inside the appropriate ACL. This setting merely
disables that access by default, so you know exactly where connections
are being made.
To fix this hazard, set Additional Restrictions for Anonymous Connections to No access without explicit anonymous permissions.
3.2. Shutdown without logon
Windows 2000 and
Windows XP Professional machines come in a default configuration that
allows you to shut down the system using the Shutdown...button on the
logon screen, so you might be familiar with this feature. However,
Windows 2000 Server and Windows Server 2003 machines disable this out of
the box. Despite the convenience factor that this feature affords, it's
best to leave rebooting a machine to administrators.
Change Allow system to shut down without having to log on to Disabled to secure this.
3.3. Automatic logoff
Some users log on to the
network and then don't log off for months. This is a prominent security
hole, as when that user leaves her desk, she still is authenticated to
the network with her credentials. Malicious people can use this to do
destructive things: delete and transfer files, plant a "root kit" or
backdoor program, or change passwords.
You can make automatic logoff
work in two ways: first, each valid user needs to have a time when she
is not permitted to log on. This can be sometime in the early morning,
perhaps 3:00 to 3:30 a.m. Then, a change to the local security policy
needs to be made so that when the user's logon time expires, she is not
permitted to log on.
To set up a logon time restriction on a domain controller for an Active Directory-enabled domain, follow these steps:
Go to the Active Directory Users and Computers snap-in.
Expand the icon for your domain and click the Users container.
Right-click a user and select Properties.
Click the Account tab, and then click the Logon Hours...button.
Select
the appropriate region of time in the calendar block, and click the
radio buttons to the right to either permit or deny logons during that
time.
Click OK, and then OK once more to exit the user property sheet.
This option is available only for members of an Active Directory domain. |
|
Now, make the change
to the computer's local security policy. Inside the Local Computer
Policy snap-in, change Automatically log off users when logon time
expires to Enabled. If you do not have a domain, instead change
Automatically log off users when logon time expires (local) to Enabled.
This will work even if users have locked their workstations.
3.4. Digitally signing communication
It's a good idea these
days for a computer to authenticate itself to other computers during a
communication. Otherwise, a technique called "spoofing" can be used, and
a cracker's computer can pose as the remote end of a connection and
receive potentially sensitive information. You can prevent this by using
digital signatures
. However, these are not pervasive; Windows compensates for this limited
use by providing two options in the local policy: require it when
possible, or require it, period.
I recommend
requiring the signatures when possible on both ends of a connection (the
RPC protocol refers to the requesting end as the "client" and the
responding end as the "server," regardless of the systems' usual roles).
Unsigned transmissions should occur only when signatures are not
available, supported, or possible.
Be
aware that this setting probably will break communications between
Windows Server 2003 machines and older, less secure client operating
systems, including Windows 95, Windows 98, and Windows ME. The SCW will
set this policy for you and warn you of this. |
|
To require
digitally signed communication when possible, change "Digitally sign
client communication (when possible)" to Enabled and "Digitally sign
server communication (when possible)" to Enabled.
3.5. Requiring the three-keystroke salute at logon
The logon screen is one of
the most trusted aspects of a computer to a normal user. He trusts it
enough that he gives his password and username, and then the computer
trusts him, too, if all of that is correct and verified. A cracker can
take advantage of this mutual trust by writing a program that runs as a
system service—in other words, it doesn't need user privileges. The
program will mimic the logon box, grab the user's input, and do
something with it such as email the password to the cracker, save the
credentials to a backdoor program data file, or any number of other
nefarious things. However, pressing Ctrl-Alt-Del brings Windows to
attention, and you get the authentic Windows logon and not a shell of
one that a cracker creates. This easy step makes your system much more
secure.
To require this
keystroke to begin, change Disable CTRL+ALT+Delete requirement for logon
to Disabled. (Yes, that's right. Microsoft uses some questionable
terminology.)
3.6. Last username display
By default, Windows
displays the username of the last successfully authenticated person to
use that particular system on the logon screen. This is giving away
needless information, although some of your users are probably
accustomed to it.
To disable the last
username from being displayed, change the "Do not display last user name
in logon screen" setting to Enabled.
3.7. Password expiration prompt
Changing passwords is a problem for some users who'd
rather not be bothered with IS minutiae and simply would like to use
their computers to be productive. With this policy setting, you can tell
the system to automatically remind a user when his or her password will
expire and prompt him or her to change it. Setting this value to 14
days gives a user ample opportunity to change their password because
that is in excess of most scheduled vacations and business trips.
To enable the password expiration
prompt, change the Prompt user to change password before expiration setting to 14 days at minimum.
4. Network Options Via Group Policy
Windows Server 2003
and GP allow you to configure security options that reside inside GPOs
that will apply to groups of computers. GP can manage security settings
throughout an Active Directory environment in seven areas. They are
shown in Table 1.
Table 1. GP areas and descriptions
Area | Description |
---|
Account area | This
area applies security configuration to user accounts, including
passwords, account lockouts, and Kerberos ticket policies. Password and
account lockout policies apply to workstations and servers; Kerberos
ticket policies apply only to domain controllers. |
Local policies | This
area allows you to set auditing and event logging policies, user rights
assignments, and registry keys that directly affect system security.
Settings in this area apply to all Windows 2000 or later systems. |
Restricted groups | This
particularly useful group allows you to define policies regarding a
user's membership into security groups that allow elevated privileges.
It's simple to define a policy where domain users can never be a member
of the local Administrators group; other policies are equally easy. |
System services | Here you can set startup options for services and access controls on them. |
Registry | In this area, you can configure access permissions on specific keys in the registry. |
Public key policies | Here
you can establish settings for encrypted recovery agents for the
Windows EFS, certificate authorities for a specific Windows domain,
trusted certificate authorities, and other public cryptography options. |
IPSec policies on Active Directory | This area allows you to define IPSec configurations for any given unit in your Active Directory. |
4.1. Viewing the default domain policy
When you install
Windows Server 2003, a default domain security policy is created. The
default domain security policy is simply a set of configurations that
apply certain security settings to all members of the domain: these can
include security settings for displaying the username of the last user
that logged on to a system, how long a password should be, whether
workstations should digitally sign transmissions to and from a server,
and so on. It's a simple task to use this default policy as a base and
customize settings based on your individual implementation. Let's look
at this default policy first, and then work through customizing it.
To view the default domain security policy, follow these steps:
Open the Active Directory Users and Computers snap-in.
Expand the domain tree corresponding to your domain's name in the left pane.
Right-click the domain name and select Properties.
Click
the Group Policy tab, select Default Domain Policy in the details box,
and then click the Edit button. Windows opens the Group Policy Object
Editor window.
To
view each default domain policy, drill down through Computer
Configuration, Windows Settings, and Security Settings, and click
Account Policies.
Look
at the right pane. You'll see Password Policy, Account Lockout Policy,
and Kerberos Policy. By clicking each, you can view or change their
default configuration.
Figure 1 shows the default domain policy on a standard, out-of-the-box installation of Windows Server 2003.
4.2. Viewing the default domain controller security policies
The default domain
controller security policy, like the default domain security policy,
applies a common configuration to a group of computers, but this time
the focus is on only domain controllers. Domain controllers often have
special security considerations that ought to be addressed separately,
and this default policy does that. You will need to use the Group Policy
Object Editor MMC snap-in to look at the default security policy on the
Domain Controllers organizational unit. To do that, follow these steps:
In the left pane, drill down through Computer Configuration, Windows Settings, and Security Settings.
Click Account Policies. In the right pane, you'll see the possible security options for this organizational unit.
Figure 2 shows the default domain controller security policy on a standard, out-of-the-box installation of Windows Server 2003.
There is a special way in
which account policies are distributed to domain controllers which
deserves comment. All domain controllers in a specific domain will apply
security policies established at the domain level regardless of where
the actual computer
object for that domain
controller resides in Active Directory. This helps to ensure that
consistent account policies apply to any domain account. All other
policies are applied at the normal hierarchical level, both to domain
controllers and to other workstations and servers in the domain. Only
domain controllers are affected by this special exception. This is just a
tip to remember when you're planning account policy distribution among
your organizational units.
4.3. Viewing a domain controller's effective security policy
To view the effective security policy from a domain controller, complete the steps explained next.
Choose Start, click Run, and type GPEdit.msc. The Group Policy Object Editor will open.
In the left pane, drill down through Computer Configuration → Windows Settings → Security Settings, and click Local Policies.
Now you can view the
domain controller's effective security policy. When you're finished,
close the Group Policy/Local Computer Policy snap-in. (When prompted to
save console settings, click No, unless you've done something you want
to hold on to.)
4.4. Final words: organizing policy layout
With power comes
complexity, and GP is no exception. Windows administrators have
squandered away many hours of their lives on basic GP troubleshooting.
Answers to quandaries such as, "Why isn't this policy in effect on this
system?" or "I thought I turned off
IPSec!" can be difficult to track down if your Active Directory is full
of GPOs that are applied inconsistently, redundantly, and
inappropriately.
To curtail your security policies and make them easier to locate, disable, change, and apply, try to follow these guidelines:
Organize your policies logically and define boundaries to contain them.
Although your
Active Directory might be organized by geographic location, your system
management needs might revolve around a different paradigm: for
instance, you might need IPSec for all company executives' laptops, but
all of them might not be in your New York office. Or all middle managers
in your corporation might require a customized version of Internet
Explorer that doesn't lock them out from accessing the Internet, which
might be the default configuration for all computers in the domain. The
idea is to map out the kinds of restrictions you need, and then define
boundaries to which those policies apply. This will make it easier to
apply them to the target users and computers even if the geographical
and managerial boundaries do not match.
Inside those boundaries configure policies that represent common values in your organization.
Do you
usually configure workstations in your finance department to lock a
computer after three unsuccessful logon attempts? Does a particular
domain in your forest need additional desktop restrictions—should they
not be allowed to run the Control Panel, for instance? Change their
wallpaper? Install software on their own? These are the kinds of policy
sets that likely sound familiar. Group these together and create GPOs
for each of these like sets of policy settings.
Configure
organizational units inside Active Directory that contain machines
grouped according to similar roles or functions within an organization.
This gets further
into the granularity of your security policies. For example, Windows
comes by default with domain controllers residing in a separate
organizational unit in Active Directory. You might consider putting
desktops, laptops, and servers into their own organizational units,
which makes it easier to apply policies, such as requiring use of the
EFS, only to laptops.
Now I'll present an
understatement: it can require some work to configure GP correctly and
effectively. The most difficult parts of the process are planning and
laying out the policy settings; Windows takes care of the actual
deployment to client computers, which is one of the features that makes
GP a compelling management tool. This ease of deployment is a
double-edged sword, however: it is equally simple to misconfigure an ACL
or change a setting (anybody who has played with the "require signed
communications" settings knows this all too well) and wreak utter havoc
on your domain. The process also is made more difficult by the lack of
an API, so you can't write simple automation programs to help you out.
You have to go the long way.
Even more difficult
sometimes is getting the big picture. That is to say, it is hard to see
how your Active Directory layout and structure—which logically and
traditionally have likely mimicked your organization's hierarchical
personnel structure—can co-exist with GPOs, which seem to cross
hierarchy boundaries and rely on other scopes of application. With
careful planning, however, GP can overlay your existing directory
structure and complement it with its own management boundaries.