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.
Prev. page
1
[2]
3
next page 
