To avoid this exploit, you can disable the PMTU-discovery process. You control PMTU discovery with the \Tcpip\Parameters subkey's EnablePMTUDiscovery entry. The value is of type REG_DWORD and can have a value of 0 (false) or 1 (true). By default, PMTU discovery is enabled.
Judiciously applied, disabling PMTU discovery prevents malicious users from setting the MTU, and thus the PMTU, to a ridiculously small size. However, it also eliminates an important network optimization algorithm. If you implement this hardening technique on a system that's responsible for routing network messages, you restrict the packet size for all destination subnets outside the local subnet to 576 bytes, which is slightly more than one-third of the standard 1500-byte Ethernet packet.
4. Protect Against Generic DoS Attacks
A system that initiates a TCP connection with another system periodically sends a KeepAlive packet, which is simply an ACK message, to the target system to verify that an idle connection is still operational. If the target system is still online, it replies with an ACK. If the target system is no longer online, it doesn't reply, and the sending system ultimately terminates the connection. Win2K disables TCP's KeepAlive feature by default because the algorithm introduces significant overhead, especially when a server must query hundreds or thousands of potentially idle connections.
You might consider enabling the KeepAlive feature on systems that provide resources or connections to a limited number of users. Two \Tcpip\Parameters value entriesKeepAliveTime and KeepAliveIntervalcontrol the KeepAlive probes.
When you enable a system's KeepAlive feature, that system sends an ACK to a target system after the source system's connection with the target system has been idle for the amount of time defined in the KeepAliveTime entry. KeepAliveTime defaults to 7,200,000 milliseconds (ms2 hours). If the remote system replies to the KeepAlive but the connection is otherwise idle, the source system sends another ACK after 2 more hours.
If the source system doesn't receive a reply, it resends the ACK at the interval defined in KeepAliveInterval. The default value for KeepAliveInterval is 1000ms (1 second). The source system queries the remote system once per second, up to five times (the \Tcpip\Parameters entry TCPMaxDataRetransmissions defines the retry count). If the remote system doesn't respond after the maximum number of attempts, the source system closes the connection.
You can reduce the KeepAliveTime value from the default of 2 hours to perhaps 30 or 45 minutes to disconnect idle TCP connections and free connection resources for other users more quickly. Remember that this setting affects all TCP connections, including local connections, so when you adjust this value, you must monitor the results closely. Microsoft recommends that you set KeepAliveTime to 300,000ms (5 minutes) when defending against DoS attacks. Unless your circumstances are unusual, use the KeepAliveInterval default value of 1 second.
5. Prevent NetBT Name-Release Attacks
By design, NetBIOS over TCP/IP (NetBT) messages aren't subject to authentication, which means that any system, including a rogue system, can send valid NetBT packets to any other system on a network. The name-release exploit leverages a logic error in how Win2K manages NetBIOS name conflicts. Typically, Win2K and Windows NT 4.0 systems discover name conflicts when the machine registers its name on the network after booting. When a conflict occurs, the OS disables networking on the system attempting to register the duplicate NetBIOS name.
The logic error lets a malicious user send a name-service datagram to a system that has already successfully registered its NetBIOS name. The name-service datagram informs the system that a name conflict exists. Upon receiving the datagram, the receiving system issues a pop-up message, releases its NetBIOS name, and stops responding to NetBIOS name queries. When a system releases its registered NetBIOS name, it loses all NetBIOS functionality, which prevents you from using NetBIOS names to browse or access systems. The name-service exploit doesn't affect TCP/IP functionality when you contact systems by DNS name or TCP/IP address.
You can use the Nbstat-n command to check whether a name conflict really exists. This command displays currently registered NetBIOS names with the word "Conflict" next to any names in conflict.
Win2K stores NetBT configuration data in the HKEY_LOCAL_MACHINE\CurrentControlSet\Services\NetBT\Parameters subkey. The NoNameReleaseOnDemand entry controls NetBIOS name-release behavior. Microsoft documentation states that Win2K Server Service Pack 2 (SP2) adds this entry, but the entry doesn't appear by default in the \NetBT\Parameters subkey. You must add it.
NoNameReleaseOnDemand has the type REG_DWORD. The default value, 0, directs the system to release its name whenever it receives a name-service datagram. If you set NoNameReleaseOnDemand to 1, the system releases its NetBIOS name only when a conflict occurs during the name-registration process. If you enable this feature, you can deter or prevent name-release attacks. If you've already disabled NetBIOS over TCP/IP on the adapter that connects to the Internet, you can skip this technique. You can only implement this deterrent on Win2K SP2 and NT 4.0 systems running the SP6a security rollup.
Microsoft Security Bulletin MS00-047 (Patch Available for "NetBIOS Name Server Protocol Spoofing" Vulnerability) cautions that enabling NoNameReleaseOnDemand causes NetBT to write multiple messages with event ID 4320 to the event log. The system will log a message with this event ID each time it receives a broadcast name-release request for common group names. These requests come from systems that previously registered the group names and are releasing these names as part of the standard shutdown process. You can safely ignore these messages.
Maximum Security
The techniques I've described are most appropriate for special-purpose, highly sensitive systems. You can use the techniques I've presented to make your systems more resilient to attacks, but the methods might negatively impact network speed or functionality.
To help you modify the registry, Web Table 2 (http://www.secadministrator.com, InstantDoc ID 25027) summarizes the relevant subkeys and entry values. Remember to reboot after you make each modification to ensure that Win2K correctly implements the change. For more information, see "Related Microsoft Articles" on the Security Administrator Web site (http://www.secadministrator.com, InstantDoc ID 25027).
End of Article
Prev. page
1
2
[3]
next page -->