44	NETWORK SECURITY

There are two modes in which IPsec operates; transport mode and tunnel mode. Transport mode operates exclusively between two hosts. Since the IPsec header is located between the IP header and the Layer 4 header (TCP, UDP, etc.), with ESP in transport mode, only the Layer 4 header and beyond are protected. With AH, protection is extended into part of the IP header.

Tunnel mode is effectively a secured IP tunnel. If either end of the SA is a gateway, the SA must be operated in tunnel mode. The only exception to this is if the ultimate destination of the data is the gateway, in which case the gateway is operating as a host. In this case, it is permissible to operate the SA in transport mode. With tunnel mode there are two IP headers. The IPsec header is located between the first and second IP header and affords protection to the entire tunneled IP packet irrespective of whether the SA is an ESP SA or an AH SA.

IPsec supports a variety of user authentication mechanisms ranging from simple username and password pairs through to full, PKI-based certificate exchange.

IPsec is widely used to provide VPN functionality both between two fixed devices (e.g. branch office to central office) and between mobile devices and a central fixed device (e.g. remote workers connecting back to the office). It is entirely capable of providing secure connections between two mobile devices. However, this is not currently a widely used application of IPsec. In order to have the necessary trust to set up and maintain an SA between two mobile devices, it would be almost essential to use a certificate exchange to authenticate the two devices/users to each other.

Scaling IPsec is a serious challenge. As mentioned previously, it is possible for host- to-host IPsec SAs to be established so that all communication between any arbitrary pair of hosts is protected. However, the number of SAs this would require on each host would present a computational burden on the hosts. In addition, in order to make host-to-host IPsec a realistic option, it would be necessary to have a PKI-based authentication system. The exchange and maintenance of certificates between each pair of hosts would add to the overheads associated with any host-to-host exchange. However, assuming that the exchange between the hosts is non-trivial, the extra overheads will not be significant. The administrative overhead of obtaining, signing, maintaining and distributing all the certificates may well be a very significant extra overhead in a host-to-host model. So, if we look at the alternative, where one or both ends of the SA are gateways, then we have the problem that, as the number of remote locations to which any individual gateway must connect grows, in order to sustain the SAs required to protect communications, there is a significant amount of state to maintain. The maintenance of state is always a constraint upon scaling. The maintenance of all these SAs involves a significant amount of memory and processing. Since the gateway is effectively a throttle point, it is also necessary for these devices to have significant packet forwarding capability.

4.2.5 ACCESS CONTROL LISTS

An Access Control List, in its most generic sense, is any mechanism that provides a means to filter packets or routing information based on any of the attributes of the routing

4.2 SECURING ACCESS TO THE NETWORK INFRASTRUCTURE

45

or routed protocols. This is an almost universally implemented mechanism; however, the syntax, functionality and flexibility of the various implementations differ widely.

Unfortunately, in some devices, particularly those with a software-based routing and forwarding function, the application of access control lists can cause a dramatic performance impact on the router. Generally, if the access control lists are not implemented in hardware, all packets have to be analysed in the CPU. This starves the CPU of cycles for other tasks (route calculation, running the CLI, etc.).

In JUNOS software, access lists are implemented using routing policy and firewall filters.

4.2.5.1Preventing and Rate Limiting Access at the Ingress to the Network

The first line of defence for your network is the edge routers. Intuitively, it is clear that this is the best place to apply filters to protect your network. By preventing ‘spurious’ traffic from ever entering your network, there is inherently less risk (note: there is still some risk) to each of your individual network devices. It is arguable that in applying filters at the edge of the network, you remove the need for any filters on all non-edge devices. I feel that taking it to this extreme would be foolhardy since there are still threats originating within your network (e.g. unauthorized users, disgruntled employees) against which filters can provide effective protection.

4.2.5.2Preventing and Rate Limiting Access to Certain Hosts/Networks

This is one of the most common uses for access control lists. Basic access control mechanisms allow the filtering (either outright blocking or rate limiting) of packets destined for or sourced from particular hosts or networks.

4.2.5.3Preventing and Rate Limiting Access to Particular Protocols/Processes

In addition to filtering all packets either destined to or sourced from particular hosts or networks, it is possible to further refine filters based on the protocol and/or port of the source/destination.

4.2.6RFC 1918 ADDRESSES

RFC 1918 describes three ranges of IP addresses that are designated for private use within non-Internet connected networks. I am sometimes asked if using RFC 1918 addresses within the core of your network will assist in the protection of your core devices. In theory, RFC 1918 addresses should not be advertised outside any autonomous system (nor accepted by any neighbour), so it should not be possible for any device outside your

46	NETWORK SECURITY

network to reach a core device numbered from RFC 1918 address space. However, it is possible to force the routing of packets via a particular edge device on your network from which the RFC 1918 addressed host is reachable. This is known as source routing and should always be disabled on all routers. There is little justification for enabling source routing anywhere in an operator’s network.

It is also important to note that this provides no protection against the misbehaviour of your own customers. A significant number of your customers will have a default route towards your network so they will be able to reach all your RFC 1918 addressed nodes (and your nodes will be able to reply).

In addition, when communicating with a host, many client applications attempt to resolve the address of the host to a name using the domain name system (DNS). In general, most people have not created entries on their local name servers for the resolution of all RFC 1918 addresses to a dummy name. Since they have no local entry, the name servers are forced to attempt to resolve the addresses through the standard DNS processes. Thus, the root servers will receive vast numbers of queries from clients trying to resolve RFC 1918 addresses. This places an exceptional load upon the root name servers. In fact, the operators of some of the root name servers have resorted to placing a firewall in front of the name servers to block all requests for resolution of RFC 1918 addresses.

Therefore, when asked, I advise people that the use of RFC 1918 addresses in your core provides scant protection for your network and places an unreasonable load upon critical shared network infrastructure. Don’t do it!

4.2.7PREVENTING AND TRACING DENIAL OF SERVICE (DOS) ATTACKS

Denial-of-service attacks are a growing problem for which there appears to be no single long-term solution. Putting in place measures to prevent and mitigate the effects of DoS attacks and to trace the source of the attack can mean the difference between providing the service which your customers expect and failing to meet your SLAs.

The wide variety of potential DoS attacks means that a number of strategies are required to combat them. In some cases, simple filtering can stop the attacks. In others, the effects of the attack can only be limited by rate limiting particular traffic types or patterns. In general, DoS attacks fall into several categories:

•Sending packets, either malformed or in such quantities, that cause the CPU of a device to become overwhelmed and incapable of performing other tasks.

•Sending malformed packets, which are incorrectly handled by the operating system causing the system to either crash or provide uncontrolled access to unauthorized users with which those users can disrupt service.

•Sending packets in such volume that links are over-subscribed, preventing the transport of valid customer traffic.

4.3 PROTECTING YOUR OWN AND OTHERS’ NETWORK DEVICES

47

Over subscribing a CPU is less of an issue with modern routers in which the routing module is separated from the packet forwarding module. Since fewer packets are, by default, sent to the routing module, it is harder to select a packet that can be subverted but that still gets transferred to the routing module. Also, it is quite common to rate limit packets through the link from the packet forwarding module to the routing module. This protection is normally left on to mitigate the effects of a full-scale attack. In the event of an ongoing attack, it is essential that filtering and rate-limiting be applied at the borders of your network.

Sending malformed packets that cause software to fail is an attack that can normally only be overcome by patching the software. The effects of some of this type of attack can be mitigated by filtering or rate-limiting particular types or patterns of traffic. However, this can impact valid traffic so it is often preferable to use this kind of measure only as a temporary measure to limit the effect until a patch can be applied to the software.

Sending packets in large volumes is often achieved by creating a distributed attack. An attacker places a piece of code on a very large number of poorly protected hosts. Each of those hosts is then remotely configured (or may be configured as part of the malicious code) to attack a particular host or network. Although each host may only be able to contribute a few tens or hundreds of kilobits per second, if hundreds or thousands of these vulnerable hosts are coordinated to start transmitting simultaneously, the effect can be quite catastrophic at the target network. The best defence against this kind of attack is to apply filters at the borders of your network and leave them in place indefinitely. If this is not possible due to the architecture of your network devices, then it is important to have the filters configured and ready to be applied at very short notice.

4.3PROTECTING YOUR OWN AND OTHERS’ NETWORK DEVICES

In addition to the protection of your network devices, it is important to be able to make use of your network devices to protect other devices that are reached via your network (e.g. your customers’ networks, managed servers, etc.). In many cases, the same functionality described above in relation to access to your network devices can be used to provide controlled access to resources via your network. The benefits and constraints associated with each of the protocols when used to access your network devices apply just as much to access via your network.