Customizing a Network Using the Registry
It's impossible to provide a complete reference for all of Windows NT, Windows 2000,
Windows XP, and Windows Server 2003 networking in a single chapter (for example, the
Resource Kits usually include a comprehensive volume entitled "Windows NT
Networking"). This topic certainly deserves a separate book. However, I hope that this
chapter helps you to understand how network settings are stored in the registry, and how
these settings are related to the data displayed by Control Panel applets. This topic is one
of the most interesting ones, and if you explore it, you'll make many discoveries and
invent many new ways of customizing network settings.
The remaining sections of this chapter will describe various methods of customizing
network settings using the registry.
Securing DNS Servers against DoS Attacks
During the last few years, Denial of Service (DoS) and, especially, Distributed Denial of
Service (DDoS) attacks have become the most serious threats to corporate networks. The
number of such attacks is growing steadily with time, and currently no one can feel safe
and absolutely secure from encountering this threat. Of course, the tips provided here also
won't guarantee absolute security against attacks on DNS servers. However, they will
serve as good add-ons to your security policy.

Note Before introducing the registry modifications described below into the
configuration of your production servers, it is recommended that you test them in
your lab environment.
All registry settings described in this section are located under the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
registry key (Fig. 8.28
). Notice that if specific parameters are missing from your registry,
this means that the system considers them to be set to default values.

Figure 8.28: The
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
registry key


The client confirms the reception of the SYN-ACK message by sending an
acknowledgement (ACK message).
If your server became a target for a SYN Flood attack, it will receive a flood of
connection requests, which will gradually prevent it from receiving acknowledgements
from clients. Thus, legitimate users will be unable to establish connections. The
recommended value for this parameter is 2 (you can also set this value to 1, but this
configuration is less efficient).
Securing Terminal Services Connections
Materials provided in this section will certainly prove useful for those who want to
improve security when using Remote Desktop for Administration in Windows Server
2003. As was already mentioned earlier in this chapter, this facility is automatically
installed on all servers running Windows Server 2003. However, remote administration
with this tool is not enabled by default. After it is enabled (see Fig. 8.22
), you can use
Group Policy or the Terminal Services Configuration tool to further configure Terminal
Services. By default, only members of the Administrators group have permission to
connect in administrative mode (but they can only connect two at a time). This default
security setting is useful. However, there are several additional settings and tools that can
be used to improve security, including Group Policy, the local Terminal Server
configuration tool, local client settings and, of course, registry editing.

Note In addition to advice and tips provided here, don't forget about regular system
hardening practices and security policies adopted by your company. More detailed
information on this topic will be provided in Chapter 9
. Furthermore, carefully
weigh the benefits provided by enabling remote access for administrative purposes
to potential dangers of exposing the system to additional risks.
To modify the default settings for Remote Desktop, proceed as follows:
1. Open the Control Panel, start Administrative Tools, then select the Terminal

administration tasks are running and a connection is broken as a result of network
problems. The task will continue to run while the session is in a disconnected
state, and the administrator can reconnect. The alternative, End session, would
stop the running process with unpredictable results. Figure the values for Active
session limit and Idle session limit parameters according to the usage of these
sessions. Limiting active sessions is probably not a good idea, as it will prevent
some administrative chores from getting done. Limiting an idle session is useful. If
you are engaged in a session and leave your computer, anyone could use the open
session to the server — a session open with administrative privileges. Setting an
idle time-out may prevent such an occurrence; at least it will limit exposure. This
setting will also help in situations where multiple administrators want to connect.
If two administrators are connected yet not using the session, the third
administrator cannot connect.