\[Editor's Note: Do you have a security-related question about Windows NT 4.0? Send it to [email protected], and you might see the answer in this column!\]
My company's demilitarized zone (DMZ) hosts several NT 4.0-and Microsoft Internet Information Server (IIS) 4.0-based Web servers, which all run Service Pack 6 (SP6) and have the latest security hotfixes. To run regular security audits and apply security settings on these systems, I'd like to use the Security Configuration Editor (SCE), but I don't want to open a potential security hole by installing SCE on the Web servers in my DMZ. How can I leverage SCE's functionality without installing it?
Let's start with a short introduction to SCE, which is a security-management utility that ships with SP4. You can use SCE to analyze and change security settings on NT systems. To use SCE, use the Microsoft Management Console (MMC) Security Configuration Editor snap-in or the secedit.exe command-prompt executable. You define the SCE's security settings in template files (i.e., .inf files). You can modify the templates with the MMC Security Templates snap-in or with a simple text editor. The templates' default location is the \%systemroot%\winnt\security\templates folder. To store its configuration information and analysis results, SCE uses a dedicated Joint Engine Technology (JET)-based database. The database's name is secedit.sdb, and its default location is the \%systemroot%\winnt\security\database folder. If you've never run SCE on a system, the database won't exist on that system.
You don't need to install the SCE to use it; you can run it from a 3.5" disk. The disk must contain the following files (which you can obtain from a system running SP4 or later that has SCE installed): secedit.exe (the SCE command-prompt executable), scedll.dll, esent.dll, and the template (e.g., myhost.inf) you want to use. Scedll.dll provides the SCE's core functions. Esent.dll contains the SCE's database logic and provides access to the SCE database. If you're running SCE on a pre-SP4 system, you also need to copy wldap32.dll to the 3.5" disk.
To use the disk to run an SCE analysis on a system, insert the disk in the system's 3.5" drive. At a command prompt, switch to that drive letter and type
secedit /analyze /cfg myhost.inf /db %temp%\myhost.sdb /verbose /log %temp%\scelog.txt
where myhost.inf is the template file you want to use for your analysis, %temp%\myhost.sdb is the location and name of the SCE database, and %temp%\scelog.txt is the location and name of the SCE log file. The /analyze switch tells SCE to analyze your system's security settings. The /cfg switch specifies the template file you want to use for your analysis. The /db switch specifies the location and name of the SCE database (if no database is available, SCE creates one). The /verbose switch adds detailed progress information to the tool's log file. The /log switch specifies the location and name of the SCE log file.
After the SCE runs, your system's temporary folder (by default, this folder is in \%systemroot%\temp) will contain the SCE database (myhost.sdb) and log file (scelog.txt). Because both files contain security-related information, after you review them, delete them from the machines in your DMZ.
To use the SCE to configure a DMZ system from a 3.5" disk, replace the /analyze switch in the preceding command with /configure. SCE then configures the system according to the settings you specified in the template file. If you didn't delete the log file after the analysis, SCE appends the configuration log data to the log file.
I work in the IT department of a large car manufacturer with an important, NT-server-based Web presence. The company's upper-management personnel are worried about the damage that Denial of Service (DoS) attacks can cause, and they want IT to take protective measures. What can I do at an OS level to protect against DoS attacks?
A DoS attack is an attack on the availability of a computer system. In a DoS attack, an attacker keeps a machine or service from performing its usual tasks (i.e., delivering a set of services to legitimate users). Many DoS attacks exploit features of the TCP/IP network stack. A common DoS attack in this category is TCP SYN flooding, which the Web-exclusive sidebar "What's a TCP SYN Flooding DoS Attack?" explains.
NT provides a set of registry parameters that you can use to harden the TCP/IP and NetBIOS protocols against DoS attacks. Table 1 lists the registry parameters, which I explain in the following paragraphs.
As its name implies, the SynAttackProtect registry parameter protects against SYN flooding DoS attacks. When you enable this parameter, NT automatically adjusts the number of SYN/ACK retransmissions. Although enabling this parameter might cause connections to time out more quickly, it frees up resources that other requests can use. Don't enable this parameter on servers connected to their users with bad communications links (e.g., a link with high transmission latency), because you might block legitimate users' access to the server because of timeout problems. The Microsoft article "Internet Server Unavailable Because of Malicious SYN Attacks" (http://support.microsoft.com/support/kb/articles/q142/6/41.asp) documents the SynAttackProtect registry parameter and the other registry parameters SynAttackProtect affects.
The EnableDeadGWDetect registry parameter, which NT enables by default, lets the TCP/IP stack automatically switch to another default gateway when one isn't available. For dead gateway detection to work properly, you need to specify more than one default gateway in the advanced properties of your machine's TCP/IP configuration. Attackers can misuse dead gateway detection to redirect NT to less powerful gateways. As a side effect, the server that made the switch will appear less responsive to its legitimate users. Although from a security standpoint you should disable this parameter, doing so will make your systems less fault tolerant on the IP level. The Microsoft article "Dead Gateway Detection in TCP/IP for Windows NT" (http://support.microsoft.com/support/kb/articles/q128/9/78.asp) documents this parameter.
Another TCP/IP-stack-related feature that attackers can exploit is Internet Control Message Protocol (ICMP) message redirects. ICMP message redirects cause a machine to update its routing table. Too many ICMP redirect messages in too short a period might cause a machine to spend too much time updating its routing table. As a consequence, the machine might stop responding to requests. Attackers could also misuse ICMP message redirects to point the routing table to less powerful machines. You can make your machine ignore ICMP message redirects by setting the EnableICMPRedirects registry parameter to 0. The Microsoft article "ICMP Redirect Attack Causes Windows NT Server and Workstation to Hang" (http://support.microsoft.com/support/kb/articles/q225/3/44.asp) documents this parameter.
The EnablePMTUDiscovery registry parameter controls TCP/IP Path MTU (PMTU) discovery. To limit using small packets, the NT TCP/IP stack always tries to discover the MTU (i.e., maximum packet size) that it can use on the path to another machine. Generating small packets negatively affects a server's performance. Attackers can force a system to use small packet sizes by misusing PMTU discovery and sending fake ICMP messages. For example, an attacker could send a fake ICMP message telling the system that a particular destination is unreachable because the packet size the system initially used was too big.
When you enable PMTU discovery (which is the default setting), the system automatically adapts its packet size. Disabling PMTU discovery makes the system keep its default packet size (576 bytes), even when it receives an ICMP request asking it to change its packet size. Disabling PMTU discovery might make some remote systems unreachable, because if intermediate systems on the path to the remote system can't support the default packet size, the system will ignore their requests to make the packets smaller.
The KeepAliveTime registry parameter controls when NT terminates idle connections. Too many open idle connections can leave you vulnerable to DoS attacks. I suggest setting the parameter to 5 minutes. Some realtime applications (e.g, RealNetworks' streaming-media products), however, require that idle connections stay open longer than usual.
Although you've probably disabled the NetBIOS protocol on your company's Web servers, you need to understand what a NetBIOS-based DoS attack is and how you can protect your servers from it. Companies usually don't like using NetBIOS in their DMZ, because it's an unauthenticated broadcast protocol that uses a flat namespace, and protocols such as this are hard to control. Because NetBIOS is an unauthenticated protocol, anybody can send a name-conflict datagram to a particular computer. The computer that received the datagram releases its name and stops responding to NetBIOS queries that use this name. NT includes a registry parameter that, when you enable it, protects against a NetBIOS-based DoS attack: NoNameReleaseOnDemand, which unlike the other parameters I discuss in this article, you set on the network-interface level. The Microsoft article "NetBIOS Vulnerability May Cause Duplicate Name on the Network Conflicts" (http://support.microsoft.com/support/kb/articles/q269/2/39.asp) describes this parameter.
A while ago, I read something about NT's built-in packet-filter capabilities. I have an NT-based SMTP gateway on which I'd like to reject all incoming traffic except for SMTP messages. How can I use the NT packet-filter features to set this up?
NT ships with a built-in static packet filter, TCP/IP security, that lets an administrator allow or deny certain types of TCP/IP traffic. A packet filter offers firewall services on layer three (network) and layer four (transport) of the Open System Interconnection (OSI) model. (For more information about OSI, see Tao Zhou's Windows 2000 Magazine article, "ISO/OSI, IEEE 802.2, and TCP/IP," May 1997.) A packet filter also selectively controls the flow of data to and from a network by allowing or blocking incoming and outgoing packets. In NT, TCP/IP security applies only to incoming packets. Most firewall products also include a packet-filtering feature.
To configure TCP/IP security, right-click Network Neighborhood on your desktop, choose Properties, click the Protocols tab, then right-click TCP/IP Protocol in the Network Protocols dialog box to bring up the TCP/IP protocol's properties. Click the IP Address tab, click Advanced, select the Enable Security check box, then click Configure to bring up the TCP/IP Security dialog box, which Figure 1 shows.
In the TCP/IP Security dialog box, you can control the incoming TCP and UDP ports (layer four of the OSI model) and the incoming IP protocols (layer three of the OSI model). An interesting sidenote about the IP Protocols list is that adding TCP (protocol 6), UDP (protocol 17), or ICMP (protocol 1) to it doesn't alter the packet filter's behavior. You can't block ICMP, and the only way to block TCP and UDP is to select Permit Only in the TCP Ports and UDP Ports lists, then leave their port lists empty. Also not apparent in the GUI is the fact that the TCP/IP security settings apply to all network adapters.
To allow only incoming SMTP traffic on your SMTP gateway, select Permit Only in the TCP ports area of the TCP/IP Security dialog box, click Add, then fill in TCP port 25, which is the port number the SMTP protocol uses. (Don't change the UDP ports and IP protocols lists.) To apply the change, you must restart the machine. If you've installed dedicated firewall software on your SMTP gateway, you should use the firewall's packet-filter features instead of NT's TCP/IP security to set up the SMTP filtering. Dedicated firewall software generally provides more-advanced firewall features than NT's built-in packet-filtering features.
Recently our company's IT managers decided to switch from Netscape Navigator to Microsoft Internet Explorer (IE) as the corporate standard for Internet-browser software. Over the years, our users have obtained Web authentication certificates from GlobalSign or other commercial Certificate Authorities (CAs), and they want to use the certificates in IE. How can I port certificates between Netscape and IE?
Before I explain how to port the certificates to IE, let me give you a little background information. You can't use a Netscape-installed certificate in IE (even if you use both browsers on the same machine), because the browsers use a different certificate and private-key storage system. Netscape stores them in its certificate database; IE stores them in the certificate store, which is a protected part of the user's profile. You can, however, export certificates and private keys from the Netscape certificate database and import them into the IE certificate store. Both browsers support a common certificate and private-key interchange format, Public-Key Cryptography Standards (PKCS) #12. (More information about PKCS #12 is available from RSA Security at http://www.rsasecurity.com/rsalabs/pkcs/pkcs-12/index.html.)
You can export your certificate and private key from the Netscape certificate database as follows (these instructions refer to Netscape Navigator 4.5):
- Open Netscape, and select Security Info from the Window menu.
- In the frame in the left pane, click Yours (under Certificates) to bring up the screen that Figure 2 shows.
- Select the certificate that you want to port to IE, then click Export.
- Netscape prompts you for your certificate database password. Enter the password, and click OK.
- The next dialog box prompts you for a PKCS #12 password. PKCS #12 needs a password to encrypt the certificate and private key you're exporting (note that this password is different from the one you entered in the previous dialog box). Enter it, then click OK.
- At the prompt to reconfirm this password, reenter the password and click OK.
- At the prompt, enter a name for the PKCS #12 file, then click Save. If the export process is successful, Netscape displays the message Your certificates have been successfully exported.
To import your certificate and private key into the IE certificate store, follow these steps (these instructions refer to IE 4.0):
- Start the Certificate Manager Import Wizard by double-clicking the PKCS #12 file you exported. Figure 3 shows the Certificate Manager Import Wizard. Click Next to see the path to the PKCS #12 file that you created when you exported your certificate and private key from Netscape (i.e., the file that you double-clicked to start the wizard).
- Enter your PKCS #12 password at the prompt.
- On the same wizard screen, you can select whether you want to enable strong private key protection and whether you want to mark the private key as exportable, as Figure 4 shows. Select Enable strong private key protection, and click Next.
- The dialog box prompts you for another password (this time to protect the private key in the IE certificate store). Enter one, and click Next.
- Fill in where you'd like to store this certificate (the default storage place is in your personal certificate store), and click Finish to end the import wizard. If the import process is successful, the wizard displays the message The import was successful.
For other versions of Netscape and IE, minor differences exist in the way the transfer works, but the general approach I explain here remains the same.
I manage an NT domain that includes several domain controllers (DCs) in different geographical locations. The central hub site that's hosting the PDC is in Paris. Every remote location has at least one BDC that connects to the hub site over a RAS link. When I monitor the secure-channel traffic between the PDC in the hub site and the BDCs in the remote locations, I notice that every time a RAS connection occurs, a full SAM database replication occurs between the central PDC and the remote BDC. How can I force the PDC to initiate only a partial replication instead of a full replication?
In the scenario you describe, when the central PDC and the remote BDC connect and the PDC initiates a security database replication, the number of changes that have occurred since the last replication is bigger than the number of changes that the PDC's Change log can hold. So, the Netlogon service initiates a full replication instead of a partial one. You can modify the Change log size with the ChangeLogSize entry of type REG_DWORD in the HKEY_LOCAL_MACHINE\SERVICES\Netlogon\Parameters registry subkey of your PDC. The default Change log size is 65,536 bytes (64KB). The maximum value is 4,194,304 bytes (4MB). With 64KB of space, the log can hold approximately 2000 security database changes. With 4MB of space, the log can hold approximately 130,000 changes. To apply the new Change log size you set, you must restart your PDC. For a review of how NT security database replication works, see the Web-exclusive sidebar "Understanding the NT Security Database Replication Model."
