Routers Redux
| The additional configuration required of routers in the edge especially applies to the perimeter routers, which directly connect to another organization (typically an ISP). They should have two types of filtering installed, to minimize the amount of illegitimate traffic that gets through them into your network. The two types are RFC 2827 filtering and Unicast RPF. RFC 2827 FilteringA favorite method of attackers who seek to penetrate a network is to pretend that they belong to it: They send packets with a forged source IP address from inside the network. However, if you think for even a moment about traffic flows, there is no reason for traffic with an internal source address to enter your network from an outside interface (unless you somehow looped the traffic, but with an internal source and destination address, why would you loop it outside?). However, it could be legitimate traffic if you have multiple locations with a large address block. Therefore, be sure to implement this as filtering the address blocks that are behind the router and allowing corporate addresses that are not internal to this network to pass (at least, to pass on to other validation, such as your firewall). RFC 2827 was originally written to be implemented by ISPs, which, in fact, have seldom implemented it. Written as "do not accept traffic from your customers with anything other than your network as a source address," it has been adapted informally to mean (for receivers of Internet traffic) "do not accept anything from your upstream that should not come from that direction." Thus, in addition to filtering out any incoming traffic with a source IP address from your internal block, you should filter addresses that should never be attempting ingress from the outside world, the RFC 1918 private address space blocks (10/8, 172.16/12, and 192.168/16). Hopefully, your ISP is also performing such filtering, but you should implement this with an ACL just the sameyou cannot guarantee that the ISP's filters will always be present or that they will be set for the addresses that you believe should be filtered. In the interest of conserving bandwidth as well as security concerns and good citizenship, you should implement similar filters on egress from your network as well. There is no reason for you to send forth traffic with private IP addresses as their source: Even if you use such addresses internally, they should be NATed to a public address before they get to your perimeter router. Likewise, traffic should never pass out of your network with any source IP address except one from your address block; any traffic with a different address in the source field should be dropped, and these drops should be logged (so that you know you have a problem inside your network). A simple example is shown in Figure 9.1 (the figure uses a private address space, but the NAT is not shown, to minimize the clutter). Figure 9.1. Perimeter router filtering per RFC 2827. Most lines of the filters are straightforward to read; the only odd one is deny 172.16.0.0 0.15.255.255 the second octet of the wildcard mask might seem strange . Remember that the private address space in question is 172.16.0.0 to 172.31.255.255. This can be expressed as 172.16.0.0/12 (or 172.16/12 in shorthand). Twelve bits of network address matching leaves 20 bits of wildcard, or 16 bits for the last two octets and the rightmost 4 bits of the second octet: 00000000 00001111 11111111 11111111. Focusing on the second octet, you can see that its decimal value is 15. Using decimal subtractions properly also works (in this case, 31 16), but it must be done carefully ; many professionals set up the problem in binary to be sure that they get it rightespecially on production networks. Unicast RPFAs with access lists, Unicast RPF consumes a few CPU cycles, but the payoff is that less bogus traffic enters your network. A hacker might be smart enough not to forge one of your internal addresses or to use a private address; instead, he might forge an address from a legitimate host somewhere else in the world. Unicast RPF checks all packets arriving on an interface first for whether such an address exists in the routing table (do I know how to reach this address?) and, second, if so, whether traffic from it should arrive on the ingress interface (does the return route exit via that interface?). If the answer to the first question is no, the packet is dropped. If the answer to the first question is yes but the answer to the second question is no, the packet is dropped. Figure 9.2 illustrates a simple example. Figure 9.2. Unicast RPF example. In Figure 9.2, suppose that a packet arrived on interface s0 with a source address of 192.168.33.125. It would pass muster on the first question but not the second: It should have arrived on port s1, with that as the source address. In fact, this is a simplification of Unicast RPF. It relies on Cisco Express Forwarding (CEF) because it uses the Forwarding Information Base (FIB) created by CEF. It also examines the packet to see if it arrived via the best interface for that address (if there are multiple possibilities). If you want to log the drops caused by Unicast RPF, you must use an ACL in conjunction with it; using an ACL also enables you to allow such traffic to pass despite the ingress interface mismatch (a permit statement allows the traffic in, while a deny statement drops it). Nonperimeter Routers in the EdgeYou might also have nonperimeter routers in the edge, perhaps serving as multipurpose devices: routing, firewalling, and/or terminating VPNs. We need to address how to configure a router for those tasks (except routing, which is not in the purview of the CSI exam). A router running an IOS image that contains the Firewall Feature Set (FFS) can serve as a fully adequate firewall, depending on the volume of traffic to be controlled, of course. After all, a firewall inspects traffic, compares it to a set of rules, and either allows the traffic to pass or discards it: It operates like an access list. One difference, however, is that although a firewall typically allows free passage to outgoing trafficand responses to known outgoing trafficits fundamental stance on incoming traffic is to deny, while a router's fundamental stance is to permit; this is modified only by the ACL. Thus, you could call the firewall a strict access list, although it has the capability to use a few other things, such as NAT and secure tunnels (IPSec). The FFS provides a set of features to do all of what firewalls do:
With these capabilities, why would anyone need a PIX or any other dedicated appliance? Because the router does all this in software, while the dedicated appliance offloads the heavy processing to specialized ASICs, which can do the same job much faster in hardware. The dedicated appliance, such as a PIX firewall, can handle many more simultaneous processes and connections. As long as the volume of traffic to be firewalled is not too great, a router with the FFS can do the job adequately. Many of these FFS features were covered in the SECUR exam; for this exam, you must focus on the capability to perform NAT and terminate IPSec tunnels. Remember the placement of the router with firewall in the SMR Blueprint: It is often the choice for terminating tunnels and might easily hold the only public address for a small network. That's why NAT and IPSec tunnel termination are both important. Let's look at an example in which a router needs to perform NAT and terminate an IPSec tunnel; later, we'll use the other end of this example for the same tasks on a PIX firewall. This situation is shown in Figure 9.3. Figure 9.3. Router-to-PIX tunnel with NAT on each end. We will use the 192. 168. x . x addresses as public addresses, to which all others inside the LAN segments behind the router or PIX must be translated. As a worst case, we will also assume that only one public address can be used for each LAN segment. NAT on the RouterIn this example, multiple addresses in the 172.18.24.0/24 network must all be NATed to one public address, 192.168.12.1. When NATing on a Cisco device, you have local addresses (not routable outside the local network) and global addresses (routable outside the local network). From another point of view, you have inside addresses (addresses as they appear from inside the network) and outside addresses (addresses as they appear from outside the local network). Thus, an inside local address is the address that this host is known by only inside the network. The outside global address is a publicly known, publicly reachable address. A device can be known by one address from inside the network but another from the outside (its global address). This offers a bit of protection from an attack because the attacker sends traffic to, for instance, a Web server's outside global address, and the traffic must pass through a NAT device that translates the destination address to an inside local address. The NAT devicewhich is firewallingcan inspect the traffic at this time. You are simply making direct attacks more difficult. In this example, a host can have the inside local address of 172.18.24.42, but its inside global address is 192.168.12. x , where x comes from a pool assigned to the perimeter router. The translation between the two addresses is NAT. It can be a static NAT (a fixed mapping) or dynamic NAT (in which the inside global address comes from a pool and is recycled). Because one of the reasons for using NAT and private IP addresses is address conservation, assume that this perimeter router has available only one inside global address (192.168.12.3) for use by NAT. The 192.168.12.1 address is for the router interface, not other traffic; other traffic uses the 192.168.12.3 address, which is assigned only to the NAT functionality. To configure a router to provide NAT of multiple internal addresses to fewer external addresses, you must use port address translation (PAT), which the overload command invokes. You can use PAT with as few as one external address. Four steps are involved in creating a PAT configuration; although they need not be done in a given order, the following is a logical order:
In the previous example, interface e0 on the perimeter router was 172.18.24.1, and it should be the internal (LAN) interface (so that is its inside local address). Interface s0 (WAN) is 192.168.12.1, which is an outside global address, and the pool of addresses (inside global addresses) is 192.168.12.3, a "pool" of one address. Here are the commands:
It really is that simple to set up NAT on the router: Create a source list, and then create a NAT pool, a NAT inside interface, and a NAT outside interface. You might have already assigned IP addresses to the interfaces, so that little bit as shown might be redundant. The key is linking the pieces with the ip nat commandthere is only one NAT process on the router, so all entries of that command link to the same thing. IPSec on the RouterIn a large organization, it might prove worthwhile to set up a Certificate Authority and generate and distribute certificates. However, for small and midsize businesses, it is not practical. That means that IPSec will be set up with preshared keys. Obviously, the key to be used on any given IPSec tunnel must be the same at both ends, and it must not be compromised (protect it at least as well as you want the information it encrypts to be protected). Another point to be aware of is that when you set up your access lists to establish the traffic of interest for the IPSec tunnel (the crypto access lists), those must be the same on each end of the tunnel (they must refer to the same address sets, protocols, and so on). If they do not match, the tunnel will sometimes work and sometimes fail, which is difficult to troubleshoot. Establishing an IPSec tunnel requires two basic processes, establishing peering (using the Internet Key Exchange, IKE) and then establishing a Security Association (SA). Although the terms IKE and ISAKMP (the Internet Security Association and Key Management Protocol) are often used interchangeably, they are not the same. The short version of their relationship is that the IKE process uses the ISAKMP-mediated information exchange. Because you will use ISAKMP instead of a manually specified SA, you must either use certificates or preshared keys at the beginning, during the IKE phase (peer establishment) of creating a tunnel. Going through both the IKE and SA creation processes, six steps are required to set up the IPSec tunnel termination on a router; again, although there is no required order, this is a logical one:
Items 1 and 2 in this list establish your IKE policy; the rest are all IPSec configuration.
In the case of our example, suppose that you wanted to specify the hash and a smaller DH initialization. You would input something like this:
If you had to do NAT and create an IPSec tunnel for the same traffic, you could easily combine the interface-assignment commands, and you might want to use only one access list for both purposes. In that case, you would have a total of eight steps. Warning : If you have a tunnel exchange with a PIX firewall (as shown in Figure 9.3), the PIX and the router do not share the same default SA lifetime. You can change the router's default lifetime with crypto ipsec security-association lifetime { number_of_seconds } in global configuration mode. You can also change the default on the PIX.
 |
EAN: 2147483647
Pages: 177