Nonroutable Networks

Besides private network addressing and antispoof filtering, there are a host of other networks that have no business being seen, including those that won't be seen for some time because they haven't yet beei allocated. For example, at the time this was written, the /8 networks from 82 to 126 had not yet been allocated from the Internet Assigned Numbers Authority (IANA) to any of the regional Internet registrie: (RIRs). This data can be tracked at a very high level at the following URL: http://www.iana.org/assignments/ipv4-address-space.

IANA is responsible for allocating Internet Protocol version 4 (IPv4) address space to the RIRs; the RIRs then allocate address space to customers and ISPs. All of this is of interest to ISPs, which might try not to forward traffic from address space that has yet to be allocated. In doing so, they will reduce the available networks that attackers can use in spoofing attacks. Rob Thomas (founder of Cymru.com) maintains an unofficial page of something called "bogon" ranges. Bogon ranges are address ranges that have no business being seen on the Internet. They are either reserved, specified for some special use, c unallocated to any RIR. Filtering this comprehensive list of subnets can narrow the potential source of spoofed IP packets. Be aware that this list can change every few months, meaning these filters must als be periodically changed. Thomas's bogon list is available here: http://www.cymru.com/Documents/bogon-list.html.

WARNING

Be aware that, with all this filtering, you are making things more difficult for the attacker but not impossible. An attack tool could easily decide to spoof only address ranges that have been allocated. In fact, attackers have started to reduce the amount of attacks that they actually spoof traffic from. By compromising several other hosts around the world, they feel safe launching attacks from those remote systems directly.

For organizations unable to track the changing bogon list, RFC 3330 states some special subnets that cc permanently be filtered from your network. They are the following:

• 0.0.0.0/8 This network refers to hosts on this network, meaning the network where the packet is seen. This range should be used only as a source address and should not be allowed in most situations except DHCP/Bootstrap Protocol (BOOTP) broadcast requests and other similar operations. It can certainly be filtered inbound and outbound from your Internet connection.

• 127.0.0.0/8 This subnet is home to the address 127.0.0.1, referring to localhost, or your machin Packets should never be seen on networks sourced from the 127/8 network. RFC 3330 says it best "No addresses within this block should ever appear on any network anywhere."

• 169.254.0.0/16 This subnet is reserved for hosts without access to DHCP to autoconfigure themselves to allow communications on a local link. You are safe in filtering this subnet on your network.

• 192.0.2.0/24 This subnet, commonly called the "TEST-NET," is a /24 subnet allocated for sample code and documentation. You might notice that some diagrams in this book use this address when a registered address is represented. You should never see this network in use anywhere.

• 198.18.0.0/15 This subnet has been set aside for performance benchmark testing as defined in RFC 2544. Legitimate network-attached devices should not use this address range, so it can be filtered.

• 224.0.0.0/4 This is the multicast range. On most networks, this can be filtered at your Internet edge, but obviously, if your network supports multicast, this would be a bad idea. In most cases, it is a bad idea to filter it internally because multicast addresses are used for many popular routing protocols.

• 240.0.0.0/4 This is the old Class E address space. Until IANA decides what to do with this space, can be safely filtered at your Internet edge.

One thing to consider is that although filtering bogons or the subset listed in RFC 3330 is possible on your internal network, it isn't necessary. If you are properly implementing RFC 2827 filtering, you implicitly deny any network that is not your own, which would include all bogon ranges. Filtering bogons is most appropriate at your Internet edge, where you would also implement RFC 2827 and RFC 1918 filtering. Within your campus network, filtering with RFC 2827 is sufficient.

uRPF

A far easier way to implement RFC 2827 filtering is to use something that on Cisco devices is called veri unicast reverse path forwarding (uRPF). This functionality is available on multiple vendors' platforms, though it might be known by a different name. Cisco documentation for basic uRPF configuration can be found here:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur c/fothersf/scfrpf.htr

This filtering works by blocking inbound source IP addresses that don't have a route in the routing table pointing back at the same interface on which the packet arrived. To be more specific, uRPF checks the forwarding information base (FIB) that is created from the routing table on all Cisco devices running Cisco express forwarding (CEF). As such, uRPF works only on Cisco devices that support CEF. For example, consider the following situation:

1. A packet arrives on a router with a source IP address of 192.0.2.5 at interface Ethernet0/0.

2. uRPF checks the FIB by doing a reverse lookup to determine whether the return path to the source IP address would use the same interface that the packet arrived on. If the best return path would use a different interface, the packet is dropped.

3. If the best return path is the interface that the packet arrived on, the packet is forwarded toward it destination.

If there are multiple best paths (as in the case of load balancing), uRPF will forward the packet as long i the interface the packet arrived on is in the list of best paths.

The syntax for uRPF is very simple:

IOS(config-if)#ip verify unicast reverse-path

Some additional options are available to provide more granularity in configuration. For example, ACLs that are evaluated when a uRPF check fails can be applied.

WARNING

Like RFC 2827, uRPF is most effective close to the edge of your network. This is because the edge of your network is the most likely location in your network to have routing symmetry (meaning packets arrive on the same interface that the return traffic will use). You should not deploy uRPF on interfaces that contain asymmetrically routed traffic, or legitimate traffic will be dropped.

For a service provider or a very large enterprise customer, there is an additional option called uRPF loos mode. (The previous mode is sometimes called strict mode.) Loose mode allows a packet to forward as long as there is a return route to the source somewhere in the FIB. This has the result of blocking the entire bogon list. I say "larger enterprise" here because you generally need the entire Border Gateway Protocol (BGP) routing table on your router before this is useful; otherwise, any spoofed packet will hav an entry for the FIB because of the default route. When you have the entire BGP routing table on a device, you usually don't need a default route. The command for loose-mode uRPF looks like this:

IOS(config-if)# ip verify unicast source reachable-via any

There is also an allow-default flag that can be set, depending on whether you want the default route to be considered a valid route when making the uRPF decision.

Few technologies have generated as much discussion among security communities as NAT. The idea of translating private addresses to public addresses is seen by many as a good way for organizations without their own IP ranges to get on the Internet. Rather than address their internal network with the addresses provided by their ISP (thus making changing ISPs very difficult), they simply choose to translate RFC 1918 addresses as they leave the network. If you want a simple rule to follow, never use NAT in a security role. NAT is fine for its intended purpose: address translation. But if you have places in your network where your security relies on NAT, you probably need to reevaluate your design. If you agree with me and understand why, feel free to skip the rest of this section; if not, read on.

NAT can be done in three main ways: static translation is when an internal IP address corresponds to a specific external IP address. This is generally done for publicly accessible servers that must be reachablf from the outside on a predictable IP address. One-to-one NAT, or basic NAT, is when an IP address insic corresponds to a single address on the outside selected from a pool. One day a system might get 192.0.2.10; another day it might get .11. Finally, many-to-one NAT (sometimes called port address translation [PAT] or NAT overload) is when a large number of private addresses can be translated to a single public IP address. This is a very popular use of NAT for organizations with limited public address space. All of their internal users can use a small number of public IP addresses.

There is little debate about the security benefits of the first two NAT options (static and one-to-one): simply put, there is none. Because each internal address corresponds to a single public address, an attacker would merely need to attack the public address to have that attack translated to the private address. Where the discussion comes in is about the benefits of many-to-one NAT. Although their numbers seem to be declining, there are some who believe that many-to-one NAT is a valuable security tool. The basic premise is this: when you are using many-to-one NAT, the NAT system keeps track of user connections from the inside to the outside by changing the source port number at Layer 4 (L4). When the return traffic comes back destined for that port number/IP address (with the right source IP address and port number), the NAT system translates the destination port number/IP address to the internal private host and sends the traffic.

This type of protection falls into the security-through-obscurity category outlined in Chapter 1, "Networt Security Axioms." An attacker could do a number of things that would not be stopped by NAT:

• Send a Trojan application by e-mail (or a compromised web page) that opens a connection from th private host to the attacking host.

• Send data with the correct port number and IP address (with the right spoofed source port and IP address). This would require some trial and error on the part of the attacker, but it cannot be discounted in the event that the attacker is going after your network specifically.

• Allow outside connections. Although this isn't so much an attacker action, there are many applications on a host that open periodic connections with hosts on the Internet. NAT has no way < blocking connections from the inside out.

The specifics of when, where, and why to use NAT are general networking design issues, not security related. From a security perspective, I would have no reservations using public addresses for all of a network and not using NAT at all.

Continue reading here: ICMP Echo Request and ICMP Echo Reply

Was this article helpful?

0 0