Border Router Security

The following sections discuss securing the border router(s) against denial-of-service threats from a vendor-independent perspective (with the exception of access control lists).

Choosing a Network Operating System (NOS)

In general, unless you are an ISP who needs the latest and greatest features on a border router, you should run your vendor's most recent "general deployment" version of the NOS. General deployment versions tend to be well tested and heavily used by other organizations, thus they are least likely to exhibit bugs , crashes, or security vulnerabilities.

If you must run a more recent network operating system, or more full-featured versions of an NOS, choose a version with the minimal set of features and services you need. Utilizing NOSs with all the latest features may expose you to a host of vulnerabilities or bugs that could be mitigated by taking the minimalist approach.

You should also configure a router with the maximum amount of memory the router can accept. The incremental cost of additional memory is negligible compared to the total cost of the router, and the flexibility and increased performance against denial-of-service attacks gained by utilizing more memory.

Disabling Dangerous or Unused Services

One of the most important steps in securing a border router is to disable "default" or unused services. Many routers ship with a default configuration that has unnecessary or dangerous services enabled. See Table 4-2, which shows basic services, functions, and the security risk of having the services enabled.

Some of these services can greatly simplify remote management using network management tools (HP Openview, Cisco Works, etc.), and you may choose to run them. If so, proper access control mechanisms should be used to limit access to authorized users and systems. Unless these services are explicitly necessary, you should completely disable them. Access control is discussed in the next section.

Border Router Access Control Policy

The strongest method available to protect your IP border is the use of access control lists (ACLs). ACLs may be applied for packets arriving on, or leaving, an interface. Most routers provide robust ACL mechanisms to filter at layer 3 (IP layer) and higher layers including layer 7 (application layer). Your security policy will dictate the IP addresses and protocols that are allowed to traverse your border router or that are directed to your border router. Whether the ISP or an organization manages the border router, you must ensure robust access control lists are implemented. You may think of this in three easy steps:

1. Secure traffic to the router.

2. Secure traffic from outside the router (Internet) into the network.

3. Secure traffic from inside the network to the outside (Internet).

ISP policies govern routing and trust between the Internet at large and its customers. Sometimes, this trust or routing policy can be exploited for an attacker's benefit. An attacker may exploit the IP border by means of port scanning, spoofing, or using other methods to learn more specific information about the hosts behind the border router, including the firewall.

IP- related technologies follow the Open Systems Interconnect (OSI) model inherently . Without explaining the OSI model, we can simply state that all Internet protocols rely on each other at different layers. Thus, if IP is the "foundation" protocol, TCP and UDP ride on top of it, and commonly known protocols like HTTP (web) and SMTP (mail transfer) ride on top of those. The news media, along with most administrators, refer to application layer vulnerabilities and commonly known protocol exploits when discussing hacking. IP, the simple underlying protocol, is rarely referenced. In the hacker community, this view is the polar opposite .

IP may be simple; however, when complimented by TCP, it provides handshaking, persistent connectivity, and authentication of the sender by means of the round-trip required to "establish a connection." Experts know that most application-layer technologies rely on TCP to provide transmission-layer authentication and these characteristics make TCP a serious target.

The border router stands as the first line of defense, prior to packets being filtered on a firewall. Providing access control on both the border router and the firewall is part of a best practice known as "layered security." Developing an encompassing security policy is beyond the scope of this book; however, we highly recommend taking the stance of "if traffic is not explicitly allowed, it is denied ." In other words, your default security posture should be to deny all traffic unless you explicitly configure an ACL to allow said traffic. This requires more work in the initial development of ACLs, but this is the most secure posture to take.

Given that an organization's security policy is dependent upon their specific environment, we will only attempt to provide some standard best-practice ACL entries. The syntax for ACLs is dependent upon your router vendor, but we include Cisco-styled extended access list entries for simplicity. For the purposes of this exercise, assume a typical border router with a single T1 (serial) interface to an ISP, and a single Ethernet interface connecting to a firewall. This ACL would be applied inbound on the T1 interface (traffic flowing from the ISP to the organization).

First, we deny inbound IP traffic with a source address of our IP prefix (192.0.2.0/24) to any internal destination ( prevents spoofing of our own addresses):

deny ip 192.0.2.0/24 any

Next, we allow inbound TCP traffic that is part of a previously established outbound connection. Ideally, with proper ingress and egress filtering you may eliminate the established entry, but this may be difficult to do in practice:

permit tcp tcp any any established

Since routers generally cannot keep "state" on UDP streams (UDP is connectionless), we explicitly allow UDP DNS responses assuming a previous outbound query:

permit udp any eq domain any gt 1024

Next, we deny the most dangerous forms of ICMP while allowing the innocuous forms (you may wish to filter ICMP more heavily than this, depending on your level of paranoia ):

deny icmp any any timestamp-request
deny icmp any any mask-request
deny icmp any any information-request
permit icmp any any

Now we deny any packets with spoofed source addresses, including auto-configuration addresses and the RFC 1918 range. You may wish to add more specific prefixes here, unless you subscribe to some form of "bogon feed" (for detailed information on "reserved" and "bogon" addresses, as well as a "bogon feed," see Chapter 2):

deny ip 10.0.0.0/8 any
deny ip 172.16.0.0/12 any
deny ip 192.168.0.0/16 any
deny ip 169.254.0.0/16 any

Next, we deny all gratuitous TCP and UDP traffic that is not already explicitly permitted or part of an established connection:

deny udp any range 1 65535 any
deny tcp any range 1 65535 any

Finally, our default security posture is "if it is not explicitly allowed, it is denied":

deny ip any any

The final form of our basic access list looks like this:

deny ip 192.0.2.0/24 any
permit tcp any any established
deny ip 172.16.0.0/12 any
deny ip 192.168.0.0/16 any
deny ip 169.254.0.0/16 any
permit udp any eq domain any gt 1024
deny icmp any any timestamp-request
deny icmp any any mask-request
deny icmp any any information-request
deny icmp any any echo
permit icmp any any
deny udp any range 1 65535 any
deny tcp any range 1 65535 any
deny ip any any

Remember that ACLs are processed in a serial fashion, from top to bottom. As soon as a match is found, the remainder of the ACL is not processed . Therefore, the order of the permit and deny statements is critical.

This ACL is a reasonable start assuming you are going to add additional systems behind the router that Internet hosts will access. The best place to add additional permit statements is after the entry to permit inbound DNS query replies:

permit udp any eq domain any gt 1024

If you had no services hosted behind your border router or firewall (extremely rare), and if inbound TCP traffic was part of a previously established outbound connection, and if you had no need of UDP-based applications save for DNS, the following ACL should suffice:

deny ip 192.0.2.0/24 any
permit ip any any established
permit udp any eq domain any gt 1024
deny ip any any

Egress filtering (outbound traffic) on your border router is just as important as ingress filtering. This has become a major concern this year as viruses, worms, and Trojan programs are spreading at an alarming rate. We have found that while an internal system may become infected, with proper egress filtering on the border router, these types of programs will many times fail to spread further. Egress filtering is discussed in more detail in Chapter 9.

Configuring Administrative Services

Earlier in this chapter, we discussed disabling dangerous and/or unnecessary services. Among these services were management protocols such as HTTP and SNMP. In addition, we include telnet and Secure Shell (SSH), which are used to login remotely to the router.

Telnet is a dangerous protocol in that it is unencrypted. It provides no mechanism to secure the password used to login to the system. We recommend disabling telnet access to the border router, or at least not allowing access from the Internet. If a miscreant were monitoring communication between the remote user and the router, the router will assuredly be compromised. Even if the router is only accessed from inside the organization's network, we recommend the use of SSH, which provides strong encryption to protect passwords and the entire data stream. Some people assume, since SSH uses encryption, that allowing access across the Internet is acceptable. We recommend disallowing all remote access to the border router from the Internet, and instead requiring access from inside the trusted network through a VPN connection.

The same access rules apply to using HTTP or SNMP. Access using these protocols should only be allowed from the internal trusted network. In a perfect world, we would recommend disabling these services completely and using command line only. However, for very large networks, most network management tools use SNMP for managing large numbers of devices simultaneously . In that case, we recommend restricting access to the internal trusted network using strong access control lists and SNMP community strings.

The National Security Agency has developed an extensive collection of documents related to securing specific network devices and host operating systems. A Cisco-specific security configuration guide may be found at http://www.nsa.gov/snac/downloads_cisco.cfm?menuid=scg10.3.1.