A.9. Communications Security

Communications security is an ever-expanding branch of IT security and one that is often not given the respect and attention it truly deserves. Communications security encompasses all the means by which data can enter or leave your otherwise private LAN. Even with a strongly secured LAN, weak communications security can bring it all crashing down. Each pathway by which data can move is yet another route through which malware can gain entry and intrusions can take place. In the realm of remote access, several areas fall in this category and demand specific attention: dial-up, remote control/remote shell, and VPN.

Remote access is the broad collection of mechanisms that allow external entities to interact with an internal closed environment. These can vary greatly in regard to speed and breadth of access. But even a trickle of data can be used to infiltrate an apparent fortress. Consider how the Grand Canyon was carved through solid rock by just running water. You need to be aware of every flow of data that penetrates the boundaries of your private LAN and fully control each and every bit of data moving across such a gateway.

One of the most important steps in securing your LAN against malicious events performed over remote access links is to erect a first-stage defense. A first-stage remote access defense is a separate authentication system for remote access that preauthenticates all connections before they are allowed to interact with the LAN itself. These preauthentication systems serve as domain controllers for remote access connections. Thus, if the remote access user fails to properly authenticate to the first-stage defense barrier, they cannot even approach the internal domain controllers or servers on the LAN.

These preauthentication systems make full network attacks from remote links much more difficult. Without them, a remote access attack can directly affect any aspect of the internal LAN. Thus, a successful remote-access-based attack can affect all users. However, with a preauthentication system, most attacks, even initially successful ones, are prevented from gaining access to the private LAN. If the preauthentication system is disabled, then no communication is allowed from any remote access link. The preauthentication system serves as a dead-man switch for all remote access links. It protects the core private LAN. Keep in mind that it is better to lose remote access capabilities than it is to lose the entire private LAN.

You can use preauthentication systems for any form of remote access that connects into a private LAN. These systems include dial-up, broadband, VPN, wireless, satellite, remote control, and remote shell. You need to know what forms of remote access are needed and how to deploy a preauthentication system to provide that additional layer of protection for the rest of your LAN.

Preauthentication systems can sometimes offer connection filtering. Connection filtering allows for restrictions to be placed on remote access links. These can include the type of OS used, the protocols supported, the user accounts involved, the time of day, the logical addressing of the client, the LAN systems the remote client is allowed to communicate with, and even the content of the communication. The use of connection filtering can reduce an otherwise full-network-access remote link to a limited-functionality, single-purpose link. This filtering greatly reduces the potential for exploitation.

Another important aspect of remote access to consider is that even with the best security on the remote access link itself, if the remote client is compromised, it could lead to the compromise of the LAN. Remote clients can be compromised by malware, theft, or physical intrusion of their storage location. In most cases, the locations where remote access clients reside is much less secure than the physical location of the LAN. Remote access clients also typically use the same system for personal activities and Internet access. These are risky behaviors that can lead to security breaches. You should use a remote access client only to connect securely to the LAN. You should not use a remote access client for any other purpose—especially not for personal Internet access.

A.9.1. Dial-Up

Any form of remote access can serve as a means to bypass the network's security policies and filtering devices, but dial-up links are the most notorious for this. This notoriety is due to their ease of use and their existence on nearly every computer. Modems are rarely used for business purposes in today's broadband, high-speed-access world. But from time to time, your organization might need to interact with a legacy service that still supports only telephone line modem dial-up connections.

If possible, modems should be barred from your private LAN except on those systems that absolutely require them. If the modem cannot be removed from the computer, then create a hardware profile that disables the modem when the computer is connected to the LAN. You might also consider disabling it through the computer's CMOS or BIOS.

All unused phone connection ports should be disabled. If a Private Branch Exchange (PBX) system is used, configure it to detect and block all computer communication calls. Regularly inspect every device in the building for improper cabling, especially telephone lines connected to modems that should not even be present anyway.

Impose callback security and caller ID verification whenever possible on inbound calls. Don't use phone numbers for dial-in modems that are in the same prefix range as your company's voice numbers as it makes discovery of your dial-in modem lines too easy. A single war dialer could discover them in minutes.

A.9.2. Remote Control/Remote Shell

Remote control is the ability to manipulate a remote computer system without having to be physically present at its keyboard. This allows your local keyboard, monitor, and mouse to be used as the interface I/O devices for the remotely controlled system. This mechanism greatly eases administration because numerous systems can be managed from a single workstation. However, it also generally reduces security. Your ability to control a system remotely means that a hijacker or intruder can do so as well.

Remote shell tools are similar to remote control tools except that they are limited to command-line or text-only interaction. Common examples of this include Telnet and Secure Shell (SSH). Telnet should be avoided completely because it offers no security or encryption. Telnet can be deployed securely within a Secure Sockets Layer (SSL) tunnel, but doing so is often too involved for most situations, especially since SSH can be easily installed and offers greater protection than Telnet via SSL. SSH provides encryption for both authentication and data communications.

If you will be using remote control/remote shells tools, enable and require any and all security features available for the product employed. Limit the use of remote control tools over the Internet. Limit who can use these tools, and monitor when and why they are used.

A.9.3. Virtual Private Networks

Using virtual private networks (VPNs) is usually a more secure option for remote access than dial-up connections. However, to support VPNs you need an Internet connection on your LAN. If the Internet connection is controlled so that it is only used for VPN links, most of the security issues with Internet connectivity are eliminated. However, if both VPN and general Internet communications are to be supported, a more extensive security solution is required.

VPN security is usually a factor of solution selection and configuration. There are three widely used VPN protocols: Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), and Internet Protocol Security (IPSec). PPTP is often considered a default to use if you are communicating with systems that don't support L2TP or IPSec. If you don't need it for this purpose, PPTP should be avoided due to the vulnerabilities and weak encryption it employs. You should use L2TP alone (without IPSec) when a dial-up link is involved in the VPN, which usually means the remote client is connecting to an ISP via dial-up, and then establish the VPN link across the resultant pathway. IPSec should be employed if broadband connections are present throughout the pathway between the LAN VPN server and the remote client.

Always enable only the strongest authentication and data encryption supported; avoid preshared keys and relying on unique session keys and certificates. While the client is connected to the VPN, prevent any other form of communication from occurring over the Internet link. Force periodic reauthentication during the VPN session to check for and prevent hijacking.