The Remote-User Problem | CCSP CSI Exam Cram 2 (Exam Cram 642-541)

The Remote- User Problem

Securing remote users is clearly both a priority and a problem whose solution depends on people who often do not understand IT procedures or reasons for doing things a certain way (a justification for no Administrator rights). The SAFE SMR Blueprint offers the same four solutions (called options) as the SAFE VPN Blueprint. Because they are alternative solutions to one overall problem, we look at the problem from the same four angles used in the previous two chapters. Then we look at how each of the options (the design alternatives) solves the problem, as much as it can be " solved ." The four angles are as follows :

Assets to be protected
Threats to those assets
Devices used and their implementation and configuration
Threats mitigated

The remote-user network assumes a need for communication between physically separated entities, the headend and the remote user. Their communications must be as much as possible like the communications that would occur if they were located on the same campus and were working in the same LAN. Subject to bandwidth limitations, of course, that is your goal, provided that the communication is secure. Security comes first; after that, make it as much like it would be inside the LAN as you can.

The remote user (or userswe just use the generic term user even when referring to a site-to-site connection) typically connects to the headend to access corporate resourcesemail, databases, documents, spreadsheets, and so forth. These files travel across a public infrastructure, reside locally, are manipulated, and return (when being saved) to the headend via the same public infrastructure.

At the same time, because people multitask, the user might need or want to browse the Web, exchange personal email, engage in IM chats (which might or might not be work related ), check on newsgroups, and do many other typical online activities. Engaging in these activities while the connection to the corporate LAN is open provides a vector for malicious software or an unknown connection to piggyback its way in.

The remote-user model therefore has to concern itself with two separate but related problems:

The security of the connection between the two endpoints
The security of the remote hosts (the uncontrolled endpoint), lest those hosts provide an ingress path for trouble

Protecting both of these is necessary.

Assets

As mentioned, the solo remote user might have locally stored copies of corporate information as well as temporary files, which could be recovered with a little patience and access (not necessarily local access) to the hard drive. In a branch office connected via a site-to-site LAN, there will be hosts and a network connectivity device (of some sort ), and there might be local servers with email, financial, and other business files stored on them. In other words, the assets to be secured are hosts, possibly servers, and networking devices. That is essentially the same situation in the small business network, except that the numbers might be smaller.

Threats

The remote-user network faces a somewhat different set of threats than the small and midsize models:

IP spoofing
Man-in-the-middle attacks
Network reconnaissance
Virus and trojan horse attacks
Unauthorized access

You could argue that denial of service (DoS) also belongs in this list, but there is little that anyone at the headend or the remote location can do about it. Only action by the ISP upstream of either can have any effect on DoS blocking the VPN. The SAFE Blueprints are practical; DoS mitigation in this instance is not practical, so it is not included.

As for the threats that were included, they principally reflect the public infrastructure character of the communications. At any point between the headend and the remote user, a hacker can interpose himself. A hacker can gain access to either end of the connection via IP spoofingpresenting an address that will be accepted because "of course it's ours." Man-in-the-middle attacks require the capability to interpose a system into the communications path; although this is difficult, with access to a compromised ISP (for instance), it can be done. Network reconnaissance can start with observing the existence of the VPN; if there is encrypted traffic between these two endpoints (a sniffer somewhere between them will facilitate that discovery), there must be something going on worth probing. The reconnaissance now has the two endpoints known and can attempt to probe whichever seems weaker (almost certainly the remote-user end instead of the headend).

Virus and trojan horse attacks are always a threat. As I write this, on my home network, my firewall logs show an increasing number of probes on port 17300, which is the port used by a particular trojan (sometimes known as Milkit) that exploits the back doors left by two other well-known trojans. My home network is essentially stealthed: It responds to external probes on no ports (any that I can't specifically disable are redirected to a bit bucket). Yet my public IP is routinely probed on known trojan ports; your remote-user network will be probed as well. Viruses arrive via email, of course, but also (increasingly) via IRC and IM message exchanges. It is not unreasonable to expect them to arrive via any kind of communication (one of the concerns with converged networks, if you recall, was the cross-connection vector pathviruses and other malware intended for one network type can enter via the other).

Finally, unauthorized access remains a problem wherever a host of any sort is located, physically or logically. Because physical control of a remote host is more easily lost than that of a host inside the headend, it is important to have the capability to readily disable any remote host's access to the headend at any time. You can lose control of the remote host in any number of ways, from compromise via its interconnection to another network (a teleworker who also has a home network), to laptop theft. You must not allow that loss to create an opening for anyone to access the headend.

Devices and Implementation

In the headend of whatever size, the following functionalities are present in some form:

A firewall and/or router for traffic filtering
A switch to direct traffic to the correct host
A means of authenticating traffic flows
Isolation of public- facing hosts from internal traffic

You need to replicate those functionalities in your remote-user network to secure the hosts and the communications path. Therefore, you need to provide firewalling/traffic filtering, traffic direction (to the appropriate host), authentication, and segregation of Internet or other public-network access from the path between the remote user and the headend. Depending on the situation at the remote end, several technology combinations can accomplish this. We address them in each of the options.

Threats Mitigated

As in previous chapters, we have already listed the threats. Table 12.1 lists the threats and the technologies used to mitigate them, to help you pair them up. A smaller network is used in this model, so we need only match the threats and their mitigations (we need not note to which part of the network a threat applies).

Table 12.1. Remote-User Network Threats and Their Mitigation

Threat	Mitigated By
IP spoofing	RFC 2827 and RFC 1918 filtering at headend ingress and at remote site ingress
Man-in-the-middle attacks	Traffic encryption and content integrity validation
Network reconnaissance	Protocol filtering at the remote site
Virus and trojan horse attacks	Antivirus on every host
Unauthorized access	Filtering at the ingress router/firewall or personal firewall software on the host

Mitigation in the remote-user network is a little different from that of the headend, especially when it comes to protecting against unauthorized access. AAA at the headend protects hosts and services there from unauthorized access via interposition in the connection (a man-in-the-middle attack), but it does not necessarily protect the network if the host at the remote end of the tunnel is compromised. (Remember, most user logons offer the username; the person attempting to log on need only enter the associated password.) That's why the remote-user model must focus so strongly on the remote hosts and the device that filters traffic at their end.