Attack Scenarios
| To be able to evaluate security of MPLS, you must define a threat model for the various zones of trust. This section uses the zones of trust defined in the chapter introduction and outlines the threats against those zones. A complete threat model (such as a security policy) must contain threats from outside as well as from inside a trusted zone because in practice many threats come from the inside. For example, a thief might come from outside an office building, but thefts actually are perpetrated in many enterprises much more frequently by internal trusted staff. Therefore, a complete threat model must take both internal and external threats into consideration. Physical threats, such as nonauthorized access to buildings, network operating centers, transmission links, and network infrastructure, also comprise the overall threat model. A network operations center (NOC) is the nerve center of a service provider and a large enterprise that deploys and manages services and networks because it applies OAM and security policies. For the analysis of MPLS VPNs, only threats from outside a trusted zone are relevant because you must assume that internal threats are independent on the VPN architecture. In the example of the office building, this means the following: When analyzing the security of the building itself, internal thefts can be ignored. Translated back to the networking world, someone executing attacks on a local area network (LAN) with tools, such as ARP spoofing, can do so regardless of whether the site he is in is connected via MPLS to the other VPN sites or via Frame Relay. However, in the case of an operational error, such as a label mismerging that results in traffic being directed from one VPN to another, the trusted zone administrator must be able to detect and respond to such a condition. Note that this example is analogous to a Frame Relay Data Link Connection Identifier (DLCI) virtual circuit being swapped from one VPN to another. This is an operational error that is not inherent on the technology architecture overall. This section discusses all the threats from the point of view of a VPN customer or user. Any VPN user, such as a bank that is using an MPLS VPN service, needs to analyze security based on the threats against its VPN. Threats that are potentially related to the MPLS VPN architecture include the following:
Figure 7-3 depicts locations from which threats might come into a specific VPN. Threats come primarily from other VPNs (1), the core itself (2), or the Internet (3). Intrusions give an outsider control over parts of the VPN, including network elements, servers, PCs, or other networking equipment. To execute an intrusion, you need to insert control traffic into the VPNin the simplest case a single IP packet to a destination in the VPN. Figure 7-3. Attack Scenarios Note Although most of today's intrusions use IPv4 packets, other data traffic can also be used to intrude into a network. This could be Layer 2 packets, IPv6 packets, or even the telephone system when dialing into a modem. Figure 7-4 shows the potential intrusion vectors into a VPN. Intrusions could potentially come from another VPN (1), the core itself (2), or the Internet (3). What they have in common is that they must directly target a piece of the infrastructure of the VPN. Therefore, to control intrusions into a trusted zone, it is sufficient to block all illegitimate data traffic into the zone. In traditional networks, this is being done using a firewall that controls traffic into a site and by separating the network from other outside networks, such as the telephone system. Figure 7-4. Summary of Attack Scenarios In the MPLS VPN environment, the same principles prevail: It is best to provide separation against outside networks and control of inbound traffic into a VPN. Where traffic is filtered by a firewall, this filtering is usually independent of the MPLS architecture. However, this assumes correct operation of the MPLS core network. If the engineer of the MPLS service provider misconfigures a PE router, an external site might become a member of the VPN, which enables intrusions from this external site. Another threat against a VPN is DoS attacks from the outside. This threat could come from the Internet, another VPN, or the core itself. However, a key difference exists between intrusions and DoS attacks. To execute an intrusion, a hacker needs to be able to send packets into the trusted zone of the VPN. Therefore, a VPN user can effectively protect herself by securing her own network edge. This assumes that the intrusion points are controllablethat is, that it has no hidden intrusion points. The threat model for a DoS attack against a VPN is different, though: A given VPN site might receive a DoS attack against its own networking infrastructurethat is, targeting parts of the VPN that are under the control of the VPN user. However, as opposed to an intrusion, a DoS attack can also affect a VPN user indirectly. For example, if a PE router is under a DoS attack, this might affect a given VPN connected to that PE, even though the attack is not directly against the VPN. The monolithic core refers to the standard MPLS VPN architecture as defined in RFC 4364, "BGP/MPLS VPNs." One single autonomous system (AS) defines the core network, and all VPN sites connect to this single AS. The threats against a monolithic core are the same as those listed previously as threats against MPLS VPN architecture:
Intrusions can first be targeted at core equipment, such as routers. The technical scope and the protection against this threat are comparable to those used for normal Internet core networks. However, the potential business risk is higher in the MPLS VPN case because the security of connected VPNs depends on the correct operation of the core, whereas sites connected to the Internet do not usually rely on the security of the service provider network. Intrusions can also target the NOC and NOC equipment, such as AAA servers, Trivial File Transfer Protocol (TFTP), or File Transfer Protocol (FTP) servers, or management stations. The associated risk is high for both the core itself as well as for the connected VPNs: For instance, a maliciously modified PE configuration can allow external sites to access a targeted VPN. An example of such a risk is extranet deployments in which external subsidiaries or corporate organizations present another threat to the service provider core. Therefore, the threat of intrusions into the core or NOC carries a high business risktypically higher than in normal IP service provider networks, but comparable to other VPN core networks, such as ATM or Frame Relay. Intrusions can be prevented with standard security measures, such as securing access to devices and secure user management through AAA, firewalling, and so on. The threat of a DoS attack against the core is often technically equivalent to the same threat in normal IP core networks. However, the business risk is potentially higher in MPLS VPN core networks, depending on the contracts with the VPN customers. Any part of the MPLS core is potentially vulnerable to a DoS attack from a VPN or the Internet, unless this part of the core has been appropriately secured and designed. In a correctly configured MPLS core, sending traffic directly to a piece of core equipment is impossible from the outside, VPNs, or the Internet. Although this completely prevents intrusions, overloading routers with transit traffic is still theoretically possible. This overloading results in resource starvation for other functions that the router or provide edge might be performing. However, mechanisms such as rate shaping at the edge mitigate against resource starvation. The solution to this threat is the appropriate design of the core network. The routers and lines have to be correctly dimensionedthat is, even if an attack from a VPN loads an access line of that VPN completely, with minimum size packets, the connected PE router must be able to handle all the received traffic. The same principle applies to core lines. Where the aggregate traffic might exceed the provisioned capacities, appropriate quality-of-service (QoS) measures need to be taken to ensure that transit traffic meets the required service level agreements (SLA). The last threat against MPLS core networks is insider attacks. This category contains all the errors or deliberate misconfigurations made by internal service provider staff. The threat is relevant to the core as well as to VPNs because such misconfigurations can also affect the security of connected VPNs. A relatively simple misconfiguration of a route target could have potentially serious security consequences. For instance, if all the sites of a bank's VPN use a certain route target for importing and exporting routes, and if this route target is accidentally added to another VPN routing and forwarding (VRF) instance, the connected sites of this VRF are effectively part of the other VPN. Example 7-1 shows a correct configuration on a PE router. The example uses Cisco commands and command line interface (CLI). Two VRFs are configured, each with its own route target. Customer edge equipment (CE) is connected to the VRFS on the PE through the serial interfaces, and the route targets in the VRFs define how the routes from a given VRF should be treated. Here there are different route targets, and the routes are kept in their respective VRFs. Example 1. Correct Configuration of Two VRFs with Correct Route Targets on a Singe PE-Router
Assume now that an operator accidentally typed the wrong route target. Example 7-2 shows the new configuration using Cisco commands and CLI. Here the routes from bank B are exported with a route target that belongs to bank A, and vice versa. Example 7-2. Incorrect Configuration: Wrong Route Target in the Second VRF
The effect of this simple error is that all the sites of bank B connected to this PE router belong logically to bank A and have full access to the entire VPN of bank A. For routing to work in this scenario, the address spaces of the two now "merged" banks would have to be unique, which is not necessarily the case in an accidental misconfiguration. Once again, MPLS VPN (BGP-VPN) permits address and data plane separation. With address separation, a service provider or large enterprise deploying BGP-VPN constructs can use private addressing for different VPNs that can overlap. In Example 7-2, we are referencing misconfiguration of route targets (RT). The danger in this type of situation is that bank A, which just suffered a potential intrusion from an outside site, might not even detect this. After all, the existing network of bank A is not affected by this move, unless there is now some address space overlap with potential connectivity problems. Bank B, on the other hand, would probably quickly discover that its site is not connected correctly because many operations (such as connecting to intranet sites, like www.bank-B.com) would fail while its site is logically connected to bank A. Therefore, if this misconfiguration was made accidentally, the security exposure of bank A would probably be limited because staff in this particular site of bank B would probably not notice where they are connected. Viruses and worms, or peer-to-peer applications, would now spread freely between bank A and the wrongly connected site of bank B. Although this example reflects an extreme case where RT manipulation permits a VPN leakage situation (albeit rare), it should be stated that when traffic from two VPNs is received on the ingress PE router/routers, two labels are imposed on each packet and forwarded toward the service provider (SP) core. The intermediate routers in the SP core do not process the Layer 3 contents (the IP destination address and so on) of the VPN packet, but base their forwarding decision only on the top MPLS label. When the traffic reaches the egress PE router, packets are forwarded toward the CE router after examining the bottom label that is unique for each VPN/VPN destination. No two prefixes belonging to two different VPN customers can have the same bottom label; thus, sending VPN-A traffic to VPN-B traffic is impossible unless explicitly allowed to do so. In addition, SPs can mitigate this further by using automated tools to assign unique VPN ID labels for each customer VPN. That further reduces any chance of unintentional assignment of the wrong site to a customer VPN. This virtually eliminates the possibility of an incorrect site receiving traffic not intended for it. However, if this type of misconfiguration is made deliberately by an operator of the service provider, the potential exposure is relatively high. In this case, the operator probably has enough knowledge to avoid overlapping address space, and bank A might not discover the intrusion. There are a number of such potential misconfigurations, all of which might have severe security implications for the connected VPNs, and some of which are hard to detect. It is important to understand that although in the previous threats the solution was based on design, here this does not work. Instead, the threat is coming from the inside, for example, from the people designing the solution. An analogy might be an operator configuring a firewall. He is controlling the security device, so he automatically has the power to also subvert security by opening additional ports. So, it is of paramount importance that service providers secure the architecture and the implementation as well as their operations, such that misconfigurations are at least detected and are prevented where possible. In practice, many service providers use automated provisioning tools where such misconfigurations are unlikely to occur. So, the more realistic threat comes from deliberate misconfigurations of an operator. In practice, operational tools control running configurations and compare them against a correct configuration, such that even malicious changes are usually detected. Generally, a NOC is logically separated from the core network. There might be more than a single NOC, in which case each NOC site can be treated as a standalone entity. A NOC needs connectivity to the network, and it needs to operate. In most cases, there are also links to outside networks: the corporate intranet, the Internet, and possibly others. Threats from the Internet and other external networks include intrusions into the network management system and the various other systems, such as FTP/TFTP servers, AAA servers, and so on. These threats are extremely serious because they might endanger the secure operations of the entire network. But they are the same as in any other NOC environment and not discussed here in detail. From the MPLS side, the same threats prevail in principle: intrusions into management systems with the potential to alter any type of the network operations, introduce fake sites into VPNs, or join VPNs. Additionally, DoS attacks against any part of the network or its operations center are possible. Overall, the NOC is the most important part from a security point of view because the entire network can be controlled from it. Internet/Extranet and MPLS SecurityThe Internet is usually positioned as the insecure part in any network deployment, so threats normally come from the Internet. Although this view is completely correct, it is not complete. In other parts of the Internet, other users require security, and from their point of view, the threat also comes from "the Internet," which now includes your own network. For any given service provider networkMPLS or notthis means that a threat is originating in this network toward the Internet. One could assert that threats may be 50 percent from the Internet and 50 percent from internal sites or hybrids of sites outside the trust zone. Some service providers take the view that security is unidirectional and that they have to secure their part of the Internet, including their customers, against the rest of the Internetbut not the other way round. There are at least two reasons this attitude is inappropriate in the global Internet. First, the Internet is a global system and requires all participants to do their share in securing access to it. Second, and more practically, an attack from a customer of a service provider often affects the service provider network as well, or other customers of that service provider. This can be observed where worms are spreading, with e-mail spam relays, and many other security incidents. For all these reasons, operators of networks that connect to the Internet must also secure the Internet from their customers, such as by applying source address spoofing prevention as described in RFC 2827 (BCP 38). In the specific context of MPLS VPNs, the threat originates from every VPN customer who has Internet connectivity through this MPLS VPN service. Customers who do not receive Internet connectivity from the MPLS provider can still be the source of security incidents through other paths, such as through other Internet service providers. The CIA has published a report that shows that the majority of security incidents occur on the inside of an enterprise. More generically speaking, this refers to a zone of trust. In many networks, the insider is more of a threat to the networks than the outsider. This principle applies in the same way to MPLS VPN deployments, for each zone of trust separately:
A number of potential security issues that originate in the same zone of trust exist and are thus not related to the fact that the underlying infrastructure is an MPLS network. Examples for such issues are as follows:
In summary, within a single zone of trust, or wherever connectivity between zones of trust has been specifically designed, security issues relating to such connectivity are outside the scope of this chapter. In these cases, traditional security solutions, such as firewalls, need to be used to separate the zones as required. To analyze security in any environment, a threat model is required and security requirements are then evaluated against it. This chapter has defined the threats against the various zones of trust in the MPLS VPN environment. Threats against VPNs include intrusions and DoS attacks from other VPNs, the Internet, or the MPLS core. Each other zone has similar threats. Threats that are not related to the MPLS architecture, such as internal threats within a zone of trust, are not considered in this chapter because they also exist in other VPN environments, such as ATM or Frame Relay. In network environments where both private network and Internet access are provided by one infrastructure, the security considerations applicable to the MPLS VPN assume the added significance of the Internet component's impact or potential impact on the service provider backbone and the customer edge connections. Not only are two corporate entities involved in the network services provisioning, but the Internet and its millions of connections and users are now closely coupled with the corporate data networks. This necessitates stringent adherence to service provider security best practices to ensure the security and reliability of the backbone. In addition, you must address network design issues to guarantee that corporate (once private network) data is not adversely impacted by the vagaries of the Internet data flows. Of course, high volumes of corporate data (for instance, large image transfers or data backups) could also impact the infrastructure to an extent that Internet traffic suffers. However, Internet traffic is typically viewed as best effort traffic with little or no expected service levels, and as such, as long as user performance is not unduly hindered, this should not be a major issue. As the usage profiles of the Internet change to support traffic that has more stringent latency or jitter restrictions, more attention might be required with respect to general traffic performance. Of greater import are intrusion-oriented security concerns and DoS attacks that are more likely to be sourced from the Internet than the corporate space and must be addressed to mitigate impact to the VPN traffic flows. At an overview level, there are three basic approaches to providing Internet and MPLS VPN services to a given set of customers. These are as follows:
Clearly, the provisioning of totally separate networks ensures that the only Internet-driven security vulnerabilities will be through the customer's own interconnect points within his network. This is a very costly approach for the service provider, though, and it will be reflected in the costs passed on to the consumer of such services. Clearly, there is an incentive for some sharing of resources with due consideration given to the degree of conjoined infrastructure that is prudent. In general, it is recommended that the VPN service network interconnects and the Internet access be run over separate links and to separate routers (not the VPN-supporting routers), rather than attempting to homogenize them over a single facility. That is, the service provider should provision separate PEs for VPN versus Internet access even if the backbone P routers are convergent. As well, the interconnections between the VPN and Internet PEs should be unique and preferably be terminated on separate CE routers. This allows for the greatest degree of configuration flexibility (thereby policy control) and reduces the concern that Internet-launched DoS attacks will have an immediate impact on the VPN performance. Internet traffic can be directed through DMZ facilities at centralized customer sites where firewall-based control and intrusion detection systems can be readily deployed. Internet access can then be provided to other sites through default routing propagated through the corporate VPN. The use of default routing to direct traffic through the DMZ ensures that corporate security policies are applied to traffic that traverses the Internet and provides a single connection point where problems can be identified and controlled. This approach also minimizes the memory usage on the PE and CE routers, which can be considerable if the entire Internet table is propagated. The third alternativesharing end-to-end resourcesensures that the network deployment costs are minimized, at least from a hardware and facilities perspective. However, this approach is fraught with considerable security risks. Both services (MPLS/VPN and Internet access) must be tightly controlled to avoid any adverse interactions. In this scenario, the SP backbone, the PE router, the interconnection facility between the CE and PE, and the CE router itself are shared resources with respect to both the VPN and Internet traffic flows. The CE router needs to implement some mechanism to groom VPN and Internet traffic into different channels. The Internet traffic must be directed through a firewall device before re-merging with the corporate traffic. Policy-based routing or multilite-VRF can be used to perform the traffic direction. Indeed, some security perspectives suggest the use of doubled firewalls to provide an additional level of protection. In addition, the use of IDSs is highly recommended to provide early warning and information leading to quicker resolution of Internet-driven attacks. Due to the inherently greater degree of control and security mechanisms available, static or eBGP routing should be used between PE and CE in this scenario. The recommended CE-PE routing mechanisms are discussed later in this chapter. Clearly, firewalling should be viewed as a necessary component of any Internet access, whether accomplished by any of the following means:
In addition, many current implementations of customer networks have been based on the use of private address space. Interconnecting to the Internet requires the use of global addresses that generally necessitate some form of network address translation (NAT). In addition to firewalls, this NAT functionality can be implemented either through shared services provided at a central customer site or by the SP. |
EAN: 2147483647
Pages: 162