Border Router Security | Extreme Exploits: Advanced Defenses Against Hardcore Hacks (Hacking Exposed)

The border (or perimeter) of an organization is the most important means of initial defense. We consider the IP border to be the router interface(s) that represents the "IP first hop" into an organization. This is normally a serial interface on a router. If organizations have more than one IP gateway to the Internet, this section applies to all gateways. Figure 4-1 depicts an example IP border interface.

Figure 4-1: Example IP border interface

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.

Note

If your vendor supplies digital signatures for NOS images that you download, you should verify the digital signature before loading the NOS image on your network devices. While we have not yet heard of a network equipment vendor distributing compromised software images (embedded with a Trojan horse or other malware), it is only a matter of time before it happens. Save yourself the agony and always check digital signatures before loading software!

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.

Table 4-2: Potentially Dangerous "Default" Services on Routers/Switches
Service	Description	Security Risk
TCP/UDP host services	Unix-style echo, discard, chargen, etc.	Flooding/DoS attack or information disclosure
BOOTP	Other routers can boot from this device	May open security hole
Finger	Unix-style remote user query	Unnecessary information disclosure
HTTP	Remote device management	Intrusion; filter access if necessary
SNMP	Remote device management	Intrusion/information disclosure; filter access if necessary
IP source routing	Forces packets to use alternative path to destination	May aid in spoofing or hijacking connections
IP directed broadcast	Specifies a LAN to broadcast traffic on	Can be used in DoS/flooding attacks
IP redirects	Router sends ICMP redirect in response to certain IP packets	Aids attackers in mapping network topology
IP unreachables	Router responds to invalid destination IP addresses	Aids attackers in mapping network topology
ICMP codes	ICMP used for echo/reply, mask request, timestamp request, etc.	Various ICMP codes can be used to disclose information about the network and map topology
Proxy ARP	Router can proxy-resolve layer-2 addresses	Dissolves security between LAN segments
DNS	Router can resolve domain names	Recursive cache poisoning , information disclosure, or DoS

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:

Secure traffic to the router.
Secure traffic from outside the router (Internet) into the network.
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

Note

The definition of a packet that belongs to an "established" connection differs by vendor. However, most routers will consider a packet part of an established connection when the ACK bit is set. This gives attackers the chance to simply flood the router with SYN-ACK packets, possibly creating a denial-of-service attack.

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

Note

There is a slight danger in permitting packets with a source port of UDP/53 (DNS) through the border router from any source address. Miscreants are now able to probe the network behind the border router, looking for live hosts and available services by sourcing all packets with port 53. A reasonable solution to this is to configure internal systems to query an internal DNS server, and allow only that internal server to send and receive DNS queries, and perform zone transfers if necessary.

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

Note

One specific type of ICMP you really should permit is ICMP Type 3, Code 4 (ICMP fragmentation needed and "don't fragment" bit was set). Many applications today will perform Path MTU discovery (PMTUd) to determine the minimum MTU value along a given network path. The sender sets the "do not fragment" bit in the packet. An interface in a router with a smaller MTU receiving this packet will send an ICMP message of Type 3, Code 4, telling the sender to reduce the MTU. If you block these ICMP messages, you may inadvertently create a denial of service for the application.

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

Note	The previous ACL entries may not be necessary if you utilize unicast Reverse Path Forwarding (uRPF). See Chapter 2 for more information on uRPF.

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.

Note	If you would rather not deal with the complexity of filtering RFC 1918 prefixes and additional bogons, you may wish to utilize the "bogon feed" from Cymru, which is detailed in Chapter 2.

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.