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
• September 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:

1. I copied it to the default template location, the %windir%\security\templates folder.
2. 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.
3. 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.
4. I entered the password and account lock-out policy as recommended, changed names on administrator and guest accounts, and entered my warning logon text.
5. Then I saved the modified template.
6. 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.
7. 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.