Threats Against the Core

This section discusses security from the service provider's point of view, when securing its own core network. Security threats against VPNs are, of course, also indirectly of concern to the service provider, but here the focus is on the core as a zone of trust and threats against it.

There are different architectural options for building an MPLS core network. It can be a single autonomous system (AS) forming a monolithic core under one administrative control. There are also various options for connecting several autonomous systems in an Inter-AS architecture and in Carrier's Carrier (CsC) topologies. All the multi-AS architectures (Inter-AS and CsC) have in common that the core is itself divided into several different zones of trust. (Refer to Figure 1-11 for an illustration of this.) In all those cases, the threats are not only coming from VPNs or the Internet, but from a new threat vector?other parts of the core, in most cases under the control of another service provider.

The service provider's network operations center (NOC) can be seen as a logical part of the core, in the sense that it must be protected from attack as well as the core and probably forms a single zone of trust with the core. Therefore, the NOC is included as a separate section in the following threat model against the core.

This section discusses the threat models for these various types of core architectures, as seen from the core network.

Monolithic Core

The monolithic core refers to the standard MPLS VPN architecture as defined in RFC 2547, "BGP/MPLS VPNs." One single AS defines the core network, and all VPN sites connect to this single AS. The threats against a monolithic core are

• Intrusions from the outside, such as attached VPNs or the Internet.

• DoS from the outside, such as attached VPNs or the Internet.

• Internal threats?Operator errors or deliberate misconfigurations can cause security problems on the core or on a connected VPN. As opposed to internal threats to the VPNs, which are not considered here, internal threats to the core might have an impact on the VPNs as well. Therefore, they must be taken into consideration.

Intrusions

Intrusions can first be targeted at core equipment such as routers. The technical scope of this threat and the protection against it is comparable to normal Internet core networks. However, the potential business risk is higher in the MPLS VPN case because security of connected VPNs depends on the correct operation of the core, whereas sites connected to the Internet mostly do not rely on security of the service provider network.

MPLS core routers are not accessible from connected VPNs or the Internet. The only exceptions are protocols that a PE uses to communicate to the "outside," because on the corresponding ports for each protocol the PE must accept packets. It is important to minimize the number of protocols used to the outside and to secure those protocols specifically. Chapter 5 gives examples on how this can be done.

Intrusions can also target the NOC and NOC equipment, such as AAA servers, TFTP and FTP servers, and management stations. The associated risk is high for both the core itself and for the connected VPNs. For example, a maliciously modified PE configuration can allow external sites to access a targeted VPN. Therefore, the threat of intrusions into the core or NOC carries a high business risk, typically 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, managing users securely through AAA, firewalling, etc. This is discussed in detail in Chapter 5, "Security Recommendations."

DoS Attacks

The threat of a DoS attack against the core is technically equivalent to the threat of a DoS attack 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: usually, VPN contracts have significantly higher service level guarantees than Internet services. Any part of the MPLS core is potentially vulnerable against a DoS attack from a VPN or from the Internet, unless that part has been appropriately secured and designed. In a correctly configured MPLS core, it is impossible from the outside (that is, from VPNs or the Internet) to send traffic directly to a piece of core equipment. While this prevents intrusions completely (as discussed in the previous section), it is still theoretically possible to overload routers with transit traffic and thus cause a DoS attack.

The solution against a DoS attack threat is to design the core network appropriately: the routers and lines have to be correctly dimensioned; that 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. This is discussed in detail in Chapter 5, "Security Recommendations."

Internal Threats

The last threat against MPLS core networks is insider attacks. This category contains all errors or deliberate misconfigurations made by internal service provider staff. The threat is relevant to the core and to VPNs because such misconfigurations might also affect the security of connected VPNs.

A relatively simple misconfiguration of a route target could have potentially serious security consequences. For example, if all the sites of the VPN of a bank use a certain route target for import and export of routes, and if this route target is accidentally added to another VRF, the connected sites of this VRF are effectively part of the other VPN.

Example 2-1 shows a correct configuration on a PE router. There are two VRFs configured, each with its own route target. CEs are 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 will be kept in their respective VRFs.

Example 2-1. Correct Configuration of Two VRFs with Correct Route Targets on a Singe PE Router

ip vrf bank_A

  rd 1234:10

  route-target both 1234:33



ip vrf bank_B

  rd 1234:11

  route-target both 1234:34



interface serial 0/1

  ip vrf forwarding bank_A

interface serial 0/3

  ip vrf forwarding bank_B

Assume now that an operator accidentally typed the wrong route target. Example 2-2 shows the new configuration. Here, the routes from bank B will be exported with a route target that belongs to bank A, and vice versa.

Example 2-2. Incorrect Configuration: Wrong Route Target in the Second VRF

ip vrf bank_A

  rd 1234:10

  route-target both 1234:33



ip vrf bank_B

  rd 1234:11

  route-target both 1234:33  <--- ERROR: 33 instead of 34



interface serial 0/1

  ip vrf forwarding bank_A

interface serial 0/3

  ip vrf forwarding bank_B

The effect of this simple error is that all sites of bank B connected to this PE router will 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 overall, and this is not necessarily the case in an accidental misconfiguration.

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 easily. 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 discover quickly that its site is not connected correctly, because many operations like connecting to intranet sites (www.bank_B.com, for example) would fail while its site is logically connected to bank A.

So a simple misconfiguration on a PE router can connect one or several VPN sites to a wrong VPN, thus breaking VPN separation.

Therefore, if this misconfiguration was made accidentally, the security exposure of bank A is probably limited because staff in this particular site of bank B probably would not notice which VPN they are connected to. Viruses and worms, of course, or peer-to-peer applications would now spread freely between bank A and the wrongly connected site of bank B.

However, if an operator of the service provider deliberately made this type of malfunction, 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: the threat here is from the inside (from the people designing the solution). An analogy might be an operator configuring a firewall: the operator is controlling the security device and therefore automatically has the power also to subvert security by opening additional ports.

In practice, many service providers use automated provisioning tools, which make such misconfigurations unlikely. So the more realistic threat is coming from deliberate misconfigurations of an operator. On the other hand, operational tools control running configurations and compare them against a correct configuration, such that even malicious changes would normally be detected.

More details on how to secure the operation of an MPLS core network can be found in Chapter 8, "Secure Operation and Maintenance of an MPLS Core."

Inter-AS: A Multi-AS Core

In the case of a monolithic core, there is only one service provider, and the threats come from the VPNs or the Internet. If a core consists of several autonomous systems and, with that, possibly several service providers, there is an additional threat to be taken into account: attacks from one part of the MPLS core to another part. Figure 2-4 shows a schematic Inter-AS architecture with two core autonomous systems.

Figure 2-4. Schematic Inter-AS Architecture

[View full size image]

The Inter-AS architecture is described in RFC 2547bis. It allows an MPLS core to contain several autonomous systems, connected in different ways. If those autonomous systems are under the control of one single service provider, there is no difference between the threats against a monolithic core and an Inter-AS core.

However, in many implementations, the Inter-AS architecture is chosen to provide a transparent MPLS VPN service across several provider networks. In all those cases, there is the additional threat coming from the other AS.

As in previously discussed zones of trust, the threats are intrusions into an AS from another AS, and DoS attacks from one AS to another.

RFC 2547bis describes three basic ways to interconnect autonomous systems with the purpose of forming an overall MPLS core. These cases are referred to as case (or type) A, B, or C. The security exposure varies with each model, but the overall threats remain the same for all three models. The threats affect the connected VPNs and the other autonomous systems.

The details are explained in Chapter 4, but to summarize here:

• Model A is the most restrictive model and does not increase the exposure significantly.

• Models B and C allow for more interaction between autonomous systems and thus increase the risk of intrusions and DoS attacks from the other autonomous systems.

There is a difference in exposure for VPNs depending on whether or not they are shared over several autonomous systems. If a VPN is shared (that is, each service provider has sites of that VPN), the exposure is higher than if the VPN is present only on a single service provider network.

Depending on the model chosen (case A, B, or C), the threats in an Inter-AS architecture are

• For each shared VPN, each AS can introduce new sites with new addressing into the VPN, and these sites will be fully connected to the VPN. This can be used to intrude into a shared VPN or to attempt a DoS attack against it.

• In cases B and C, each AS can send traffic into any VPN of another AS, whether this VPN is shared or not, although it cannot always receive return traffic. This can be used for DoS attacks or simple intrusions.

• Routing between autonomous systems potentially allows for a DoS attack from one AS to a PE router of the other AS.

From a VPN perspective, the fact that the core is provided by several service providers in an Inter-AS architecture does not add new threats to the already existing ones. However, the VPN user must trust all involved service providers because either of the service providers could endanger the security of its VPN.

From a service provider perspective, the Inter-AS architecture adds additional threats, depending on the type of interconnection model chosen.

Carrier's Carrier: A Hierarchical Core

In the Carrier's Carrier architecture, which is also described in RFC 2547bis, several service providers provide an overall MPLS core. However, in this case, the autonomous systems follow a hierarchical architecture?not a peer architecture, as in the Inter-AS model. Figure 2-5 depicts the schematic architecture of a Carrier's Carrier solution. Only the Carrier, AS 2 in Figure 2-5's example, has the information of the customer VPNs. The "Carrier's Carrier," here AS 1, treats everything coming from AS 2 as a VPN, and has essentially no visibility of the customer VPNs. From AS 1's point of view, there is only one VPN in this configuration, the VPN for AS 2.

Figure 2-5. Schematic Carrier's Carrier Architecture

[View full size image]

The data traffic on AS 1 consists of packets with the standard MPLS labels for AS 2. Only those two top labels have significance on AS 1; the rest of the packet is ignored on AS 1. This is equivalent to encapsulation of a VPN packet on a standard MPLS core, except that the VPN packet in this case is in turn an MPLS packet?the data packet as seen on AS 2. This one has in turn a VPN label and encapsulates a VPN packet. The VPN 1 data packet is in turn ignored on AS 2, which only works with the AS 2 VPN label. (See Figure 2-6.)

Figure 2-6. A Packet on the Carrier's Carrier Network, AS 1

This has a significant advantage from the security aspect: AS 1, the Carrier's Carrier, only sees VPN information on the first level, that is, AS 2. This means that AS 1 only needs to know the next hop within its network for the AS 2, and only needs to look at the first labels, as if it was a normal RFC 2547 network. However, because AS 1 does not even look deeper into the packet than the first two labels, it also cannot be attacked based on information there. This reduces the security problem seen from AS 1's point of view to the standard RFC 2547 issues, discussed previously.

RFC 2547bis states specifically for this case that a PE router does not accept labeled packets from a CE "unless it is known that such packets will leave the backbone before the IP header or any labels lower in the stack will be inspected." This condition is true here: essentially, AS 1 tunnels packets from one part of AS 2 to another part of that same AS. Therefore, there is no threat against AS 1 in this model. But note that AS 1 has the power to forge packets such that a VPN of AS 2 is affected. (This is, however, a threat against the VPN, not against AS 1.) As in all previous cases, a VPN user always has to trust the service provider(s).

Of course, AS 2 can still forge packets, do source address spoofing, or intend a DoS attack against AS 1. But all such attempts would stay within its own domain, or in the case of DoS, would be the same issue as in standard RFC 2547 networks. In other words, a higher-level provider can affect the security of a lower-level provider, or his VPNs, but not the other way around.

Threats Against a Network Operations Center

Generally, a network operations center (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 it needs to operate, and in most cases, there are also links to outside networks: the corporate intranet, the Internet, and possibly other networks. Figure 2-7 depicts how a NOC connects to its surrounding networks. Often a NOC also manages parts of a VPN, such as the CE routers. In this case, there are also connections between the NOC and the VPN, and these need to be secured.

Figure 2-7. Schematic View of a NOC

Threats from the Internet and other external networks include intrusions into the network management system and various other systems, such as FTP and 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 network operations, introduce fake sites into VPNs, or to join VPNs. Also, DoS attacks against any part of the network or its operations center are possible. Overall, from a security point of view, the NOC is the most important part of a network because the entire network can be controlled from it.

Copyright eTutorials.org 2008-2023. All rights reserved.