Get answers to your security-related NT questions
[Editor's Note: Do you have a security-related question about Windows NT 4.0? Send it to jan.declercq@compaq.com, 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.
Prev. page
[1]
2
3
next page 
