Ask Us About... Security, March 2001

by Joel Scambray

Spring is in the air as we embark upon another Q&A session on Microsoft security features and factoids. I'll do my best to keep my hay fever at bay as I answer the burning questions sent to my mailbox over the last month. But first, a report from an important event that I attended in mid-February.

On This Page

Black Hat Report

Black Hat Report

The Black Hat Briefings is an annual conference dedicated to a "meeting of the minds" between hackers and the IT community. It occurs each July in Las Vegas, Nevada, U.S.A. Since its inception over three years ago, it has become so popular that additional venues have been created. One of those venues was a conference dedicated solely to Windows 2000 security in Las Vegas on February 14-15, 2001. I was there before, during, and after the conference as a trainer and as an attendee, and the value of the information presented was so great that I thought I would share some of it with readers.

First of all, I want to note that Microsoft is a platinum sponsor of both the Black Hat Briefings and the Black Hat Windows 2000 forums, and they should be congratulated for supporting this open and frank discussion of security issues. Such discussions are not always flattering, and Microsoft's continued support and the presence of key personnel at the show indicates that they are committed to an ongoing dialogue with the security community.

On to the highlights of the show! (I should emphasize that this is my perspective of "highlights." I was unable to attend each session since they overlapped, so my apologies to other presenters for great presentations that I missed.) I spent a lot of time during day one of the conference in "IPSec in a Windows World," which featured co-presenter William Dixon, Program Manager for Windows Networking at Microsoft. William discussed Windows 2000-specific IPSec deployment issues ranging from Group Policy integration, firewall traversal, performance maximization, and various authentication scenarios (including Kerberos and certificates).

My favorite discussions from day two of the conference were a presentation by Eric Schultze and David LeBlanc of Microsoft on "defense in depth," and an overview of SQL Server security problems and solutions from Chip Andrews of SQLSecurity.com. Eric and David pointed out some simple changes to access control lists (ACLs) on system executables and directories that can prevent many debilitating attacks. Chip reminded the crowd that the omnipresent sa account with a null password is still wreaking havoc, along with other bad SQL Server development practices.

Although they weren't posted at the time of this writing, Black Hat maintains a media server where these presentations may be available for download at a future date. I highly recommend checking them out. Chip's presentation is available on the SQLSecurity.com. site.

OK, end of conference report. Shall we answer some reader questions?

Recovering Office passwords

Q: I'm creating a document using Microsoft Word that may potentially contain sensitive information. I note that Word has a password protection feature (under Tools/Protect Document). How strong is the security surrounding this feature?

A: I get a lot of mail asking about the strength of passwords for Office documents. As was demonstrated in an analysis of the Microsoft Office password protection system presented by ElcomSoft at Black Hat (see above), the password-protection features of these programs were not designed to be invincible. Indeed, nothing really can be made impervious to the user sitting at the keyboard, given the right skills and debugging tools. However, I know that due to the convenience of these built-in document protection features, they will continue to be used. Folks that use these features should be aware of two things:

1. Software is readily available on the Internet for extracting such passwords.

2. Don't think for a minute that password protection of a document solely via these built-in methods will protect its contents from a determined adversary.

If you want much better protection, use professional-grade encryption like PGP or Encrypting File System that comes with Windows 2000, as discussed at length in previous columns.

Windows 2000 domain controller hardening

Q: We are planning to use Active Directory™ to implement Internet-based applications. This will be a separate forest from their internal Active Directory. We are wondering if there are some best practices in securing Active Directory domain controllers in a DMZ type environment.

A: Right off the bat, I would question the wisdom of putting domain controllers in a DMZ at all. After all, the "demilitarized zone," as it is called, is supposed to demarcate a semi-trusted network (at best). It is typically a place where Web servers and other systems with heavy public interaction are kept separate from internal networks that house highly sensitive information. It is essentially a "buffer zone" between the outside and the inside. You should assume that there is a high probability that one or all of the systems in the DMZ will be compromised at some point during their existence.

Since a Windows 2000-based domain controller holds the organization's "keys to the kingdom" (account names and password hashes), it has no business in a semi-trusted environment like the DMZ, where it might potentially be compromised by an outsider. However, I note that you have already planned this forest separate from the internal corporate infrastructure. A separate forest may make for more management hassle, but it presents one of the best security options in my book. Folks interested in learning more about planning an Internet-facing Windows 2000 forest can see my January column.

Of course, there are advantages to deploying Active Directory domain controllers in the DMZ: applications built around Windows 2000 domains and Active Directory can offer a much more robust set of features, including Kerberos authentication, shared accounts, and so on. So there is a strong motivation for deploying Active Directory to the DMZ, as long as it is designed and managed securely, of course.

On to the meat of your question: how does one secure Active Directory domain controllers in a DMZ environment? There are two things you must consider: network and host-level controls.

Network level controls are outside of the scope of this column, but I will recommend in brief that all access to and from the domain controller in the DMZ be tightly restricted at the border router/firewall (s). The domain controller should only be accessible by machines that require its services, i.e., the application servers in the DMZ. All other access should be seriously scrutinized, if allowed at all. If you are planning on deploying Active Directory in the DMZ in order to export it directly to the outside world, then stop reading right now and reconsider. This is not a good idea.

At the host level, Windows 2000 should be configured as securely as possible, while allowing necessary services to function. This task is sometimes called "hardening" for obvious reasons. An easy way to harden Windows 2000 deployments is to use the Security Templates that are included with Windows 2000. Security Templates are pre-designed configuration files that can be applied to a system using the command-line Secedit tool. The templates provide an interface to configure the following:

As you can see, there is very little that you cannot configure with security templates. So much flexibility can be overwhelming, however. Fortunately, the predefined templates can help out here. (Tip: an additional and highly restrictive template called hisecweb is available from Microsoft's Secure Internet Information Services 5 Checklist.)

Of course, even the most robust template will need custom tailoring to individual environments. I strongly recommend that readers test these prepackaged configurations before deploying them on production networks to ensure that compatibility and functionality is not disrupted. Conversely, some readers may find that the configurations included in the templates are not aggressive enough from a security standpoint and may want to bump up some specific settings.

Creating and editing your own custom templates is easily accomplished via the Security Templates Microsoft Management Console (MMC) snap-in. You can also edit templates manually by opening them in a text editor from %systemroot%\security\templates, but the MMC interface is much easier. Also, it may seem that once you have committed to a template, there is no way to back out. However, the "basic" series templates contain default configuration settings for fresh installs; so this provides a way to back out of settings if they break functionality.

To apply a security template, use the command-line Secedit utility like so:

secedit /configure /db <file_name> /cfg c:\winnt\security\templates\hisecdc.inf

where <file_name> is an arbitrary name for the database file created to store the template. (Secedit won't work with templates directly.)

In a high-security environment like a DMZ, you will want to make sure that everything is locked down as tightly as possible. Probably the best template to start with in this situation is the hisecdc template that ships with Windows 2000. It provides the most robust security of all the templates, assuming that you start with a clean install of a Windows 2000 domain controller. Even still, there are a few additional things to consider beyond what is offered via hisecdc. The critical things to examine are available services, account policy, and system patches.

A classic security rule of thumb is "Deny all services not explicitly allowed." In our scenario, this means that everything not central to the functionality provided by the domain controller should be shut off. The basic functionality provided by a domain controller is DNS, LDAP, Global Catalog, and Kerberos. Most everything else can be shut off. Use good judgment, and test on pre-production environments to ensure that you don't disable something that breaks your applications. And remember, you can configure service startup behavior using Security Templates.

One critical service to disable (if it is not being used) is Server Message Block (SMB). This is the file sharing protocol used by Windows NT and Windows 2000; and under Windows 2000, it appears in two different places: over NetBIOS, via TCP port 139, and over raw TCP port 445. To disable both of these interfaces, open the Network and Dial-up Connections in Control Panel and select Advanced/Advanced Settings, and then deselect "File and Printer Sharing for Microsoft Networks." This will disable connectivity via TCP 139 and 445. No reboot is required for this change to take effect. Also, please don't run any Internet services on a domain controller!

You may also consider using IPSec filters to restrict access to necessary services so that only specific DMZ hosts can get to them. See a previous column for a discussion of setting up IPsec filters for these purposes.

From an account perspective, the hisecdc template should automatically configure the server to use complex passwords, set a lockout threshold, log failed logons, and other good security best practices. Of course, if you have disabled SMB, as discussed earlier, the risk of account compromise is much less to begin with.

Last but not least, keep up with security patches! Even the most tightly configured system can harbor a code-level flaw that renders all of the above configurations meaningless. This is a general security best practice that should be applied across all systems within an organization, and even though it seems obvious, I can't emphasize it enough. Just one slightly under-patched system can be your undoing!

I hope this discussion has helped set you on the right path to domain controller in the DMZ security. What you are attempting is complex, but by taking some simple security precautions, I think your risk will be significantly lowered.

Here's one last tip to tide you over until next month: Security Templates can be made even more powerful by applying them throughout a domain using Group Policy. (You can even push IPSec filters out this way.) Until next month!

Joel Scambray is a Principal of Foundstone. He is co-author of Hacking Exposed: Network Security Secrets & Solutions, from Osborne-McGraw Hill.

Send your Security questions to the Ask Us About Security mailbox. If your question is selected, you will see your answer in a forthcoming column.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.