Section 9.3. Designing for Security and Reliability

9.3. Designing for Security and Reliability

The bulk of this chapter focuses on features of and extensions to OSPF and IS-IS that contribute to security and reliability. However, the features and extensions examined here can protect your network only from the potentially negative influences that these two protocols can have. So many other things can go wrong that tightly securing your IGP while ignoring wider vulnerabilities is a bit like locking the door but leaving the windows wide open. Therefore, the remainder of this chapter provides an overview of wider factors to consider for ensuring a secure, reliable network. This section examines good design practices, and Section 9.4 examines good operational practices.

9.3.1. Redundancy

I recently boarded a flight in Taipei bound for Hong Kong. After a noticeable delay on the taxiway, the pilot announced, "Sorry folks, we need to return to the terminal because I'm not happy with the functioning of one of the fuel control systems. Although the system has triple redundancy, I'm not willing to take the chance."

Groans sounded throughout the plane over expectations of missed meetings or missed flight connections, but probably not a single person aboard wished the pilot would go ahead and "take the chance." Even with a triple-redundant system.

Most large enterprises have become dependent on their networks for the functioning of their core business. And if you run a carrier or ISP, the network is your business. As a result, designers of large networks must have a streak of pessimism in them, believing that if something can go wrong, it will go wrong. You should be as diligent in designing redundancy into the most vital portions of your network as an aircraft engineer is when designing a vehicle that will carry hundreds of people miles above an ocean. The consequences of failure can be severe.

There are three areas in which to consider redundancy in network design: system components, network links, and network nodes.

The most vulnerable of individual system components is usually the power supply, because of the high heat they generate. All mission-critical routers in your network should therefore have redundant power supplies. And do not make the surprisingly common mistake of connecting both power supplies on the same system to the same power source. They should be on separate electrical circuits with separate circuit breakers.

The second essential system to consider for redundancy on a router is the route processor modulethe route processor, routing engine, route controller, control processor, or whatever the individual vendor chooses to call this component. Both heat and complex software code can be culprits in putting these modules at risk. Physical separation of this component from the packet forwarding module, as discussed in Section 9.2.4, makes redundant route processor modules possible. Graceful restart is a particularly important feature to support when using redundant route processor modules, to ensure that an automatic or manual switchover to a backup module does not interfere with packet forwarding.

And because heat is a major contributor to component failure, redundant cooling systems are important. Other router components to consider for redundancy are switching fabrics and clock sources.

Even with a wealth of redundant components, it is still possible for an entire router to fail. Therefore, at the most critical parts of your network, the routers themselves should be redundant. Figure 9.15 shows an example of a common redundant router design typically used in a core access site. Here both the core routers and the aggregation routers behind them are redundant. Such a site architecture provides not only resiliency against a router failure, but also redundancy for one of the most vulnerable parts of the network: the links and interfaces. In this design, no single core or aggregation router failure can isolate the site, nor can the failure of any two links or interfaces connecting the four routers isolate any one of them from the other three.

Figure 9.15. Using redundant routers at a core access site.

Because the routers in Figure 9.15 are presumably in the same physical site (and probably in the same or adjoining equipment racks), the links connecting them are likely to be wire or fiber jumpers. As such, they are safer than the usual physical link, but not without risk. Jumpersparticularly the connectors at each endcan go bad. And the biggest risk of all, as usual, is human: The local technician might inadvertently disconnect or break a jumper while working nearby.

However, links connecting core sites to each other and links connecting access sites to the core sitein other words, any link connecting physically remote sitesare among the most failure-prone components of your network. The majority of the physical link is out of your control, and is exposed to human, animal, and natural damage. Redundancy here is crucial, particularly in the core. You have already read, in Chapters 5 and 7, suggestions concerning making your IGP backbone and area connectivity reliable. Figure 9.16 extends those suggestions and shows four general core architectures: fully meshed, partially meshed, ring, and a ring-mesh hybrid.

Figure 9.16. Four general core architectures are a full mesh (a), a partial mesh (b), a ring (c), and a ring-mesh hybrid (d).

The full-mesh architecture provides the highest degree of redundancy, but is also the most cost-prohibitive due to the number of links required. The partial mesh is a good compromise, and allows you to add links where you decide that both the risk and the bandwidth demand is greatest. Rings are the most economical of the redundant architectures, but also provide the least resiliency: Any two link failures will partition the network. Rings can also introduce more latency than other architectures because of the average distance between nodes. The ring-mesh hybrid is perhaps the best compromise between redundancy and cost, particularly in large region- or continent-spanning networks. Dual link failures might still isolate some parts of the network, but the mesh element reduces this risk while still requiring a low number of links.

Notice in Figure 9.15 that single links connect the access routers to the aggregation routers. If the access routers are located within the core site, doubling the number of interfaces used easily adds redundancy from each access router to each aggregation router. The consequences of isolating a single access site might well justify the expense of doubling the number of interfaces used. More likely, however, the access routers are located at remote sitescustomer sites or field offices, for example. If the remote site is to have redundant connections to the core network, another vulnerability must be considered: A core site is vulnerable to catastrophic loss through fire, weather, flood, massive power outage, riot, or terrorist act. So if a remote access site needs redundancy, consider the technical and economic feasibility of attaching the redundant links to separate core sites.

9.3.2. Protecting the Domain Edge

Always remember that OSPF and IS-IS are IGPs. That is, they are designed to be used interior to an autonomous system. Never run either protocol to a router outside of your administrative control; you should always have full control over what crosses the edge of your OSPF or IS-IS domain. Static routes are the preferred means of routing to an external router because you have complete control over the external routes. If dynamic exchange of routes is required, use BGP, which is designed for peering with untrusted routers by supporting complex routing policies.

You must also use packet filters to help regulate what comes into your network. Of particular importance are source filters, which examine the source address of packets and reject any packets with source addresses you do not expect to see from the external peer. This helps prevent source address spoofing, which is a common element of many denial-of-service attacks.

Source address filtering is useful for customer or client peering, where you should know what prefixes the peer network is using. Although this is the most exact method of guarding against address spoofing, in some cases the number of prefixes used by the peer can make a configured source address filter impractical. A somewhat less-exact but still effective alternative supported by a number of router vendors is Unicast Reverse Path Forwarding (uRPF). Originally developed to prevent loops in multicast networks, uRPF compares the source address of incoming packets with the unicast routing table. If the route entries indicate that the next hop toward the source address is out an interface different from the interface on which the packet was received, the packet is assumed to have been spoofed and is dropped.

9.3.3. Protecting the Router

When peering to the public Internet, source address filters are impractical, and uRPF is unlikely to be effective. Public peering opens your network to a world of bright, cunning attackers. Just as firewalls and other security devices are necessary to protect hosts and servers exposed to public access, extensive and well-considered measures must be taken to protect your routers from unauthorized access and abuse originating not only from outside of your network but also from within your network.

9.3.3.1. Router Access Policies

One of the holy grails of network attacks is gaining access to a router. An attacker who can control a router can inflict grave harm to your network, or can choose to use covert means to gain even deeper access into your network. Therefore, your first line of defense is to ensure that access to the router is tightly secured.

All commercial routers provide a console port for maintenance access to the router. This port is particularly vulnerable and must be protected by proper physical security of the router. Many network operators provide access to routers through a terminal server or dialup modem, or both, connected to console ports. Securing these devices is beyond the scope of this brief discussion, but suffice it to say that these devices extend physical access to remote users and therefore represent a significant risk if they are accessible by unauthorized users.

The other means of accessing a router are logical, through a management network or directly from the production network, via a protocol such as Telnet, rlogin, or Secure Shell (SSH). Of these, SSHparticularly SSH version 2is far more secure. If you have the option on your router, you should use SSH exclusively for logical access and disable Telnet and rlogin. Furthermore, if your router provides the option, you should limit the number of concurrent SSH sessions allowed and the rate of connection attempts. A typical example is a maximum of 10 concurrent sessions and 5 login attempts per minute.

Many routers also support file transport protocols, such as FTP or TFTP for upgrading system software. These protocols should be enabled only when they are needed for system maintenance, and disabled at all other times.

Other protocols that allow packets to reach the CPU of your router, such as Domain Name Service (DNS), Network Time Protocol (NTP), and Simple Network Management Protocol (SNMP), should be authenticated whenever possible. You can further secure protocols such as these, required for normal router operations, by using packet filters to restrict accepted packets to those sourced from one of the few servers that would normally provide these services. Packet filters for router protection are discussed in Section 9.3.3.3.

Of course, you cannot keep everyone out of your routers. Therefore, you need an authentication, authorization, and accounting (AAA) policy to closely control the operations and engineering access required for routine network operations:

• Authentication policies involve requiring anyone attempting to access the router to submit a password or (preferably) a stronger, regularly changing code such as provided by a SecurID system.

• Authorization policies define what a person who has been authenticated is allowed to do on the router. For example, daily operational personnel need to be able to observe the results of various show commands, but should have little reason to change the router configuration. Troubleshooting personnel might have all the privileges of operations personnel but can also change a limited number of configuration variables. Senior engineering personnel might have full privileges to execute any command a router supports.

• Accounting policies record what an authenticated and authorized user actually does on the router. An accounting policy should record everyone who accesses the router and when, and should record every command issued on the router, when it was executed, and by whom. This recorded information is useful not only for security but also for troubleshooting: If a mistake is made that is not immediately detected, a later troubleshooter can identify what was done on a router and therefore can more easily understand what corrective actions to take.

AAA policies might be statically defined on a router, but networks of moderate to large size normally use an AAA system such as TACACS or RADIUS. These systems allow policies to be defined on a server rather than on individual routers, making policies uniform across the network and making them easier to change. As with other essential systems, the servers providing these policies should be redundant.

9.3.3.2. Login Banners

Most routers allow you to define a banner that is displayed to anyone logging in to the router. However, the importance of these banners is often overlooked, and the banner (if used at all) might say something like "You have logged into the Acme Anvil Corporation network. If you are not authorized to be here, please log off at once." What the creator of such a banner does not understand is that the banner should be, above all else, a legal document defining an agreement between the user and the network owner.

The login banners should be identical on all routers, and should display a strongly worded message warning of the legal consequences of unauthorized access. Such banners are important when building a successful prosecution case against anyone illegally accessing any of your routers or servers.

A strongly worded login banner should include statements regarding the following:

• Clear prohibition of unauthorized access.

• Clear prohibition of unauthorized use. Some operations personnel might be authorized to access the system but limited in what they are authorized to do. This warns authorized users against stepping outside of the boundaries of their authorization.

• Warning that the system may be monitored. Note that the wording may be has important ramifications for successful prosecutions. Do not say the system will be monitored.

• Statement that there is no expectation of privacy. This statement ensures that no legal defense can be mounted claiming that you should not have monitored the unauthorized user.

• Statement that results of monitoring may be provided to the appropriate authorities.

• Statement that continued use of the system implies consent to the stated terms and conditions.

• Warning to log off immediately if consent is not given.

Login banners should not include any of the following information:

• Information about the device type or software

• Information about the device location

• Contact information

• Administrator information

All of your routers should be configured so that they display the banner at any login, whether remote or local (such as a console login).

An example of a strong login banner is:^[18]

^[18] This banner is based on one used by the United States Department of Energy and is publicly published.

*********************************************************************** WARNING! This is a private system, and is the property of Acme Anvil Corporation. Access is restricted to authorized users and to authorized purposes. Users (authorized and unauthorized) have no explicit or implicit expectation of privacy. Any or all uses of this system and all files on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed to authorized site, Acme Anvil Corporation, and law enforcement personnel. By using this system, the user consents to such interception, monitoring, recording, copying, auditing, inspection, and disclosure at the discretion of authorized site or Acme Anvil personnel. UNAUTHORIZED OR IMPROPER USE OF THIS SYSTEM MAY RESULT IN ADMINISTRATIVE DISCIPLINARY ACTION AND CIVIL AND CRIMINAL PENALTIES. By continuing to use this system you indicate your awareness of and consent to these terms and conditions of use. LOG OFF IMMEDIATELY if you do not agree to the conditions stated in this warning. *********************************************************************** 

Although this example banner follows best practice, you should consult legal counsel familiar with local and international telecommunications law for any adjustments to accommodate current local and federal laws.

9.3.3.3. Packet Filtering for Router Protection

Your router simply cannot function usefully without allowing certain packets into the router CPU or route processor module. However, by using packet filters, you can explicitly define what packets are allowed to access the router. The packet filter should define the packets by source and destination address, by protocol, and by port.

A framework for a typical packet filter for protecting a router is:

• Allow any TCP sessions established from this router. This allows BGP sessions the router originates and also allows Telnet or SSH sessions an operator might create from this router to another device.

• If you have an out-of-band management system, allow packets with source addresses coming from this system.

• Allow packets for all routing protocols (OSPF, IS-IS, BGP, and so on) running on this router. You can make this part of the filter much stronger by defining the IP addresses of the router's neighbors and only accepting packets with source addresses from this list. This part of the filter supplements the protocol authentication methods described earlier in this chapter.

• Allow packets from signaling protocols such as Resource Reservation Protocol (RSVP) and Label Distribution Protocol (LDP) that might be running on the router. As with routing protocols, limiting packet source addresses to known neighbors strengthens the filter.

• Allow ICMP messages. ICMP is necessary for routine maintenance, but not all messages are necessary. So, you can make this part of the filter stronger by accepting only the ICMP messages you will need.

• Allow traceroute packets, which are normally UDP packets with destination ports in the range of 33,434 to 33,523.

• Allow packets from operationally necessary protocols such as SNMP, NTP, TACACS or RADIUS, and DNS. List the addresses of the servers providing these services and only accept protocol packets from those sources.

Keep in mind that a filter such as this must be positioned to apply only to packets destined for processing by the router itself. It cannot affect packets transiting the router as part of normal packet forwarding.

9.3.3.4. Rate Limiting

The previous section discussed how you can tighten security on your router by permitting only those packets necessary for the routine operation of the router. But these packets themselves can present a risk. For example, a common denial-of-service attack is to flood the target with more ICMP messages than the target is capable of processing.

If your router supports it, rate limiting of certain packets, particularly ICMP packets, to the route processing module can reduce your exposure to DoS attacks that exploit packet flooding. You should assess for each protocol the maximum rate of packets that might be required for normal operations. You should be liberal with this estimate because a flooding attack can still be expected to far exceed this maximum. For example, in a moderately large network, 500kbps of ICMP and traceroute traffic to a router CPU might be more than sufficient for normal operations; 2Mbps of routing protocol traffic and 5Mbps of SNMP traffic might also be sufficient. Actual numbers, of course, depend on traffic analysis of a specific network. If your router supports it, you should also specify an allowance for small bursts beyond the normal maximum. Any packet rate that exceeds your configured rate limit and burst limit is then considered abnormal, and the out-of-spec packets are dropped.