Security Advisor
Security, List By List
Security checklists are valuable—but only if you use them. Follow along on Microsoft’s list and harden a server.
- By Roberta Bragg
- 09/01/2002
I’ve gained and lost hundreds of pounds in my lifetime, quit smoking
a dozen-plus times, tried weightlifting, tai chi, yoga, religion, vegetarianism
and other assorted physical and mental improvement paths more times than
I can count. One time, I lost so many pounds that I was shunned by normal
women as one of those thin people who didn’t have to worry about her weight.
Another time I couldn’t don my leather jacket or find blue jeans that
fit—not because I got fat but because bulging thigh and arm muscles just
wouldn’t fit into “female” clothes.
Oh, I’ve made successful (how long-term is successful?) changes in my
behavior. I haven’t smoked in more than 10 years; I’ve exercised daily
(if running up the aisle of the airplane to beat someone else to the restroom
counts); and severely limited my exposure to brain-cell-assassinating
substances of any kind. But my experience with almost every self-improvement
regime has always been fraught with the pain of withdrawal, boredom and
backsliding into routines that are more comfortable. Yet I still search
for solutions to my bad habits like there’s some magic path to redemption.
The difference now is that when I find a new self-help program, I just
read the book, visualize myself as a successful practitioner and then
put it up on the shelf. No pain, no gain, no loss. It’s like I’ve learned
how to avoid the middleman.
I often chalk up my failures to regimens that were too difficult to follow,
too hard to continue long-term, and those that lacked a supportive environment
in which to start and continue my path to enlightenment. Sound familiar?
So Many Checklists, So Little Time
Surely you’ve noticed similar problems with the implementation
of security regimens. It’s easy for me to tell you to follow a checklist
from Microsoft, NSA or me. It’s not so simple for you to put it into practice
and even harder to keep it going. For example, all the checklists tell
you to disable services not needed, but for the most part, they’re obtuse
about which ones to disable and when to disable them. We tell you to lock
down files using NTFS permissions but rarely give you good advice on which
files or specifically how to do this.
Nowadays, a quick Internet search can locate at least a dozen security
checklists. Have you implemented any of them? I’d like to know how these
checklists hold up long-term in a normal production environment.
Meanwhile, I thought I’d do some research of my own. Starting this month,
I’ll take a checklist and implement it on a small network. I’ll let you
know the ins and outs of why I’m doing what I’m doing and fill you in
on the mistakes I make along the way. I’ll test it by adding the applications
I use, and then see what breaks and figure out the solution. And, yes,
while I’ll implement it first as a test, my plans are to adopt it as my
production network. Like most of you, I’ve applied security but haven’t
fully implemented some of the more restrictive resource permissions or
service disablements. Granted, that’s only a couple of dozen machines
in my case, but think of my excursion as your chance to play the voyeur.
My goal here is to have you develop your own personal lockdown lists.
Do you have a test network? Would you like to better understand security
in a Windows network? Are you busily adapting a checklist for your own
environment? Join me. Follow along or do your own project. Let me know
how you’re making out. I don’t know if we’ll all be successful, but like
making healthcare changes, joint effort sure beats working alone. This
month, I’ll explain the basics and concentrate on server security. I’ll
leave securing domain controllers, application servers and desktops for
future columns.
From the Horse’s Mouth
The first decision is to choose the list. I decided to use the
Microsoft Security Operations Guide, which you can find at www.microsoft.com/technet/
treeview/default.asp?url=/technet/security/prodtech/windows/windows2000/
staysecure/.
Part of my rationale was that I wanted to test this relatively new checklist
(straight from the horse’s mouth, as it were.) The other reasons:
- It doesn’t just list things you should change in configuration, but
also hits on risk analysis, patch maintenance, auditing, intrusion detection
and incident response.
- It goes beyond merely locking down a server to building security
baselines per server role.
- It provides some tools, hints and explanations and includes help
on the sticky subject of “What do I break if I do this?”
There are things missing from the guide, such as how to modify the baseline
server to run Exchange, and how to securely run an SQL Server. Also absent
is advice on network design best practices—in other words, where to put
Internet Information Server (IIS) and the backend database with which
it must communicate.
Nevertheless, it’s a good start, so let’s begin.
Considering the Risks
The first step is risk analysis, which I covered in my September
2001 cover story. Examine the threats to your network and the probability
that they’ll actually happen. The cost of mitigating each plausible risk
is then weighed against the recovery cost if you take no action. This
information helps you decide which security measures should be put into
place and how much money is available to use on the solution. For example,
you might not feel that the same amount of money should be spent to secure
a server storing publicly available data as one holding customer credit
card numbers.
Let’s assume that the network I’ll be protecting has a firewall and knowledgeable
people to configure it and that we’re a typical network, not a military
or financial institution. We do have, or will have, an e-commerce server,
intranet server, Exchange server, SQL Server and Windows 2000 and XP Professional
desktops and laptops. We’re going to go for the full panoply of hardening
steps but not invest in third-party software at this time. We also want
to consider that the application is becoming the network—that our perimeter
security, while valuable, isn’t a panacea.
Determining Computer Roles and Assigning Baseline
Policies
This is the easy part. What’s the computer used for? Mail server?
Database? Desktop? We want a baseline security policy for each computer.
The Operations Guide provides several. It even offers security templates
to implement the policy. It provides solutions for:
- Domain Controller Base. baselinedc.inf
- Server Base. baseline.inf (an alteration of the default hisecws.inf)
Server roles for which incremental policies are provided include:
- Infrastructure Incremental.inf
- IIS Incremental.inf
- File and Print Incremental.inf
The server baseline serves as the starting point, and the incremental
baselines can be applied to adapt the locked-down server for a particular
role. Noticeably absent are incremental baselines for application server
roles. (This is the first release of this project, though. More to come!)
Nevertheless, we have enough to get started. My first step was to review
the server baseline to see if it needed adjustment to meet current security
policy. I’m talking about the written policy of the organization. If,
for example, your policy specifies a three-character password, that’s
what should be implemented rather than guideline specifications. In my
case, I’m the boss, so I’ll leave the baseline alone for now. You’ll want
to use the policy of your company.
To examine the baseline, add it to your test machine, then open a console
(Start | Run mmc) and add the snap-ins “Security Configuration and Analysis”
and “Security Templates.” If you add the new templates to the old folder
(%systemroot%\Security\Templates), you’ll see them when you expand the
Security Templates container. If you placed them in their own folder,
use the tool to add that container to your console. Before you go any
further, save the console, so you can use it again. While your company
policy may differ from the baseline we’ll be studying, you’ll be able
to tell where to make the implementation changes. I’ll also spend some
time talking about areas where policies are likely to differ and why.
Server Baseline
The server baseline template makes many changes to the default
settings established when the server is installed. Changes to Security
Options and the large number of services disabled are significant. Many
changes are listed in the Security Operations Guide, but not all the rationale
for each change is defined. Table 1 summarizes the changes and points
out a few issues with the changes made (click
here to view it). Note that while most baseline modifications
are entered into the template, some baseline changes discussed in the
operations guide aren’t implemented directly in the template. It’s left
to you to do so by making changes to the template or elsewhere.
| Table 1. Security
Administration Guide recommendations for Windows 2000 Server security
baseline. Comments inform you of sections where the provided template
does not match the recommndations or where items cannot be seen in
the GUI, but are present. |
| [click
here to view table 1.] |
You should spend time becoming familiar with the changes and what they
do. When you work with the incremental templates or develop your own,
it’ll be important. If you know what service has been disabled, for example,
you may be able to more quickly provide a functional template that maintains
security while allowing a complex application to run. Remember, these
templates are meant as a convenience for you—not as an excuse not to learn
security.
Dream—Or Nightmare?
Tables 2 and 3 indicate the enabled and disabled services. By enabling
only those services necessary for minimal operation, the baseline template
is either your fondest dream or your worst nightmare. In order to do much
of anything, you’re going to have to understand what you’re doing. Now,
to be sure, many of the services are never enabled and don’t need to be
on most servers. If you compare the list in Table 1 to the standard default
selection of services loaded, you’ll notice many you don’t recognize.
The reason for including them here is twofold: 1) You can see that they’re
not needed for operation; 2) You can’t just load the software.
| Table 2. These
services are enabled in the baseline. Note that some are automatically
enabled, whereas others must be manually started. Remember that a
program can start those services. |
| Enabled
Services |
Manual |
Auto |
| COM_ Event System |
X |
x |
| DHCP Client |
x |
X |
| Distributed Link Tracking Client
|
x |
X |
| DNS Client |
x |
X |
| Event Log |
x |
X |
| IPSEC Policy Agent |
x |
X |
| Logical Disk Manager |
x |
X |
| Logical Disk Manager Administrator
|
X |
x |
| Net Logon |
x |
X |
| Network Connections |
X |
x |
| Performance Logs and Alerts
|
X |
x |
| Plug and Play |
x |
X |
| Protected Storage |
x |
X |
| Remote Procedure Call (RPC)
|
x |
X |
| Remote Registry Service |
x |
X |
| Security Accounts Manager |
x |
X |
| Server |
x |
X |
| System Event Notification |
x |
X |
| TCP/IP NetBIOS Helper Service
|
x |
X |
| Windows Management Instrumentation
Driver Extensions |
X |
x |
| Windows Time |
x |
|
| Workstation |
x |
X |
|
|
| Table 3. These
services are disabled in the baseline. Remember to review your requirments.
Should you need one of these services for an application to work,
by all means enable the service in your baseline template before applying
it to the server. |
| Disabled
Services |
| Alerter |
| Application management |
| BINLSVC |
| Certsvc |
| Clipbook |
| ClusSvc |
| Computer Browser |
| DHCPServer |
| Distributed File System |
| Distributed Link
Tracking Service |
| Distributed Transaction Coordinator
|
| DNS Server |
| Fax Service |
| File Replication Service |
| Groveler |
| IAS |
| IISADMIN |
| Indexing Service |
| Internet Connection Sharing
|
| Intersite Messaging |
| Kerberos Key Distribution Center
|
| LDAPSVCX |
| Licensing Logging Service |
| LPDSVC |
| MacFile |
| MacPrint |
| Messenger |
| MSFTPSVC |
| MSMQ |
| NetMeeting Remote Desktop |
| Network DDE |
| Network DDE DSDM |
| NntpSvc |
| NSLService |
| Nsmonitor |
| Nsprogram |
| Nsstation |
| Nsunicast |
| NTLM Security Support Provider |
| NWCWorkstation |
| NwSapAgent |
| Print Spooler |
| QoS RSVP |
| Remote Access Auto Connection
|
| Remote Access Connection |
| Remote Procedure Call ( RPC)
Locator |
| Remote_Storage_Engine |
| Remote_Storage_File_System |
| Remote_Storage_Subsystem |
| Remote_Storage_User_Link |
| Removable storage |
| Routing and Remote Access |
| RunAs Service |
| SimpTcp |
| Smart Card |
| Smart Card Helper |
| SMTPSVC |
| SNMP |
| SNMPTRAP |
| Task Scheduler |
| Telephony |
| Telnet |
| Terminal Services |
| TermServLicensing |
| TFTPD |
| Uninterruptible Power Supply
|
| Utility Manager |
| W3SVC |
| Windows Installer |
| Windows Management Instrumentation |
WINS |
|
Since the necessary service is disabled, the installation program will
fail or will cease to run once installed. Enabling the service may be
all you need to do, but you are in control of the process. If you’re monitoring
your events, you’ll have early warning that someone’s attempting to load
unauthorized software. (An authorized load would enable the services before
attempting installation.) Many services are disabled. Here are a few you
might need to enable in your environment, or for which I disagree with
the guide:
- SNMP Service (disabled). This may be required by management
applications in your environment. Make sure, if you enable it, that
it’s required on every server and that you follow procedures for implementing
it securely. Note the recent vulnerabilities announced for almost all
implementations of SNMP, not just Microsoft’s. Apply vendor-provided
patches.
- WMI Services (disabled). Windows Management Instrumentation
is required by many tools and applications. Investigate your environment
to determine if you need to enable this service. One example is the
management of logical disks via the Computer Management console.
- Messenger Service and Alert Service (disabled). Both are required
to send administrative alerts. Performance Logs and Alerts, if used
to trigger alerts, will require these services.
- Netlogon (enabled). On the typical server, you’ll get an error
message that this isn’t a domain controller and doesn’t need to be enabled.
You can disable this service.
- Remote Registry Service (enabled). I’d feel a lot safer with
this disabled, as it’s an obvious attack vector. However, the use of
hfnetchk or other patch-scanning tools requires this service to be enabled,
and the ability to use them to help keep systems updated mitigates a
lot of risk.
- Spooler (enabled). The print spooler is required if this server
will be a print server and if any printing will be initialized from
this server. Be aware and adjust accordingly.
If you need to enable additional services, don’t forget their dependencies.
Some services require other services to be running before they’ll start.
You’ll spend a lot of time troubleshooting if you don’t learn this beforehand.
Dependencies are documented in the Dependencies page of the Properties
for the service. An excellent guide to the starting order, services required
and their dependencies can be found at www.microsoft.com/technet/treeview/
default.asp?url=/TechNet/prodtechnol/winntas/support/advtshoot/
x0e_file.asp.
Don’t Panic!
Don’t let this concept of minimalism distress you. The operations
guide includes some templates that will help you move from minimal server
to file server, Web server or infrastructure server. Also, support papers
currently in development will step you through moving from a secure server
to a secure application server. (Domain controllers, by the way, rate
their own template. We’ll discuss that another time.)
Implementing and Testing the Server Baseline
Before implementing the server baseline, I wanted to have a clean,
hardened install. I typically make sure the drive is cleanly formatted,
so no resident viruses or sensitive data remains to trouble the new server.
Next, I connected the system to my test network—not the production one.
I don’t want the system compromised during installation. Like a baby,
your new system is unprotected and requires a sheltered life until you
can get it ready for the cruel world. I always strip out the accessories,
uncheck the box that would install IIS, and never, ever, ever install
anything I don’t have to. After the install, I removed things that were
installed anyway or things I forgot to uncheck, like Notepad, Freecell
and Image Viewer. Then I loaded service packs and all hotfixes.
It was then time to prepare and test the base template. Here are the
steps:
- I copied it to the default template location, the %windir%\security\templates
folder.
- I could have used the secedit command to apply the template, but
I wanted to make some adjustments. So, I loaded an MMC with the Security
Configuration and Analysis and Security Templates snap-ins.
- I right-clicked on the baseline.inf template and saved it to a new
template by appending “RB” to the beginning of the file name. This saves
the original, unmodified template, and marks this as the one with the
changes.
- I entered the password and account lock-out policy as recommended,
changed names on administrator and guest accounts, and entered my warning
logon text.
- Then I saved the modified template.
- I right-clicked on the Security Configuration and Analysis root and
selected, “Open database…”, giving it the name, “Rbbaseline,” and imported
the Rbbaseline.inf template.
- I right-clicked the template and selected, “Configure Computer now…”
Template Testing
Applying the template may make you feel like you’ve just finished
the first week of a new fitness plan. Even though you’ve completed the
first round of circuit training, you need to submit to a few tests to
make sure you’re doing it right; there are also a few caveats.
The best way to ferret out potential problems is to download and use
the Microsoft Baseline Security Analyzer tool. This tool runs a few vulnerability
checks, which you should pass with flying colors. More importantly, it
checks to see if your system is up-to-date on its patches. In my case,
it found that even though I’d loaded all current patches before using
the baseline, a new one had been released. Thanks, MSBA.
Use netstat to check the ports the new server is listening on (netstat
–a –n shows the port numbers, netstat –a the services.) You’ll find that
only the NetBIOS name server, session, datagram and RPC endpoint mapper
are open.
Many MMC tools can’t be used for remote administration. You can manage
shared folders, local users and groups, most storage management tools,
device manager, and event view. If you need to manage other items remotely,
you may want to enable WMI.
Moving on Up
We have a locked-down server—so what? Our goal is to have the entire network
ready for prime time. Like changing your habits or your body, hardening
a network isn’t a quick, one-time effort. You have to be in it for the
long haul, because there’s a lot more to learn. Now that you’ve gotten
one server ready, it’s time to move on. In upcoming columns, we’ll harden
the domain controller and set up group policy to harden our servers and
workstations. Meanwhile, your assignment is to try this template on your
Win2K or XP Pro systems. What changes do you have to make to get your
applications to run? You did this on a test system, right? In the meantime,
share your thoughts and experiences with me, and I’ll share the tips in
a future column. Now, enough of this exercise. I’m heading for the chocolate.