Hardening Communications - Protect WAN Communications
(Page 6 of 11 )
In addition to local area communications, secure remote communications from other networks. Connections with other networks can be secured in a number of ways, but to secure the data as it travels between networks requires additional devices and protocols. Four technologies are currently in use:
- Dial-up access servers have a long history. Many of the legacy systems provide weak authentication and do not encrypt data in flight; however, reliable, securable dial-up access can be implemented using Microsoft tools.
- Virtual private networks (VPNs) are designed to provide tunneled, encrypted, and authenticated communication channels either client-to-server or gateway-to-gateway. Two protocols, PPTP and L2TP/IPSec, are used in Microsoft VPNs.
- The Secure Sockets Layer (SSL) has long been a methodology for authentication and securing communications between client computers and web servers; it is now commonly used as a portal to entire networks.
- Remote access rules can be applied to secure wireless networks. Even though wireless networks are often established as additional internal networks, an intruder could access them from outside the building because no physical access is required to connect to the network. Therefore, wireless networks should be thought about and secured according to remote access rules.
Hardening remote communications consists of hardening servers, clients, devices, and communications streams.
Harden the Remote Access Server In addition to configuring secure remote access, harden the remote access server.
Harden Installation Follow standard precautions during installation, including performing the installation offline and applying all service packs and hotfixes before adding the server to the network. Provide two network interfaces and provide secure configuration before connecting to the network.
Harden External Network Interface The external network interface of the remote access server should provide only the basic connectivity required for the service. Two basic areas need configuration.
First, the external network interface should be configured to
- Remove File and Printer Sharing for Microsoft Networks by clicking to deselect it from the General Properties page of the connection.
- Disable NetBIOS over TCP/IP from the TCP/IP Advanced Properties, WINS tab as shown in Figure 11-2.
- Prevent attempts to dynamically register the network IP address in DNS from the TCP/IP Advanced Properties, DNS tab as shown in Figure 11-3. Attempts to dynamically register the network IP of this interface in an ISP’s DNS may not be welcome. In addition, connections from external hosts should be configured on these clients. There is no reason to be resolving the Internet address of the remote access server.
Second, the network interface should be firewalled, and as an extra precaution, the Windows 2000 and Windows Server 2003 RRAS server can be configured to filter all packets on the external interface that are not necessary for remote access. See the later section “Harden Windows Server 2000 and Windows Server 2003 RRAS Configuration.”
Restrict Services Never run additional services on the RRAS server. If the Windows security baseline templates (see Chapter 8) are in use, place RRAS servers in their own OU and configure a GPO and link it to the OU. Enable the RRAS service and/or IAS service as appropriate for servers in the OU.
Figure 11-2. Disable NetBIOS over TCP/IP on the external network interface.
Figure 11-3. Prevent dynamic DNS registration.
Configure Auditing In addition to auditing using the GPO, additional RAS and RRAS logs should be configured. In Windows NT 4.0, the ppp.log file is not created by default. This log can be created, and Point-to-Point Protocol (PPP) connections will be logged, by adding the Logging value and setting it to 1. The Logging value is of type REG_DWORD and should be added at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP
After the value is set, you must stop and start the RAS service before the file will be created and PPP connections are logged in the SYSTEM32\ppp.log file. Although the original intention of this log file was to provide troubleshooting information, it can serve as a record of PPP connections for your auditing efforts.
 This is from Hardening Windows Systems, by Roberta Bragg, (McGraw-Hill/Osborne, ISBN: 0072253541). Check it out at your favorite bookstore today. Buy this book now. |
Next: Harden NT 4.0 Remote Access Server Configuration >>
More Windows Security Articles
More By McGraw-Hill/Osborne
/ 4 
