Cisco IOS Access Lists

The policy toolkit

What do we do with our policy sets once we define them? How can we use those policy sets to prevent the described scenarios from happening? This section talks about the “policy toolkit,” a set of four “tools” that are general techniques for manipulating policy sets.

As we know, policy sets can be described as the “what” of a policy. The policy tools fit into our conceptual framework as the “how.” Once we define a policy set, we must do something with it to implement a policy. There are four kinds of tools we can use with policy sets to implement network policy. These tools control the following:

• Router resources

• Packets passing through the router

• Routes accepted and distributed

• Routes based on characteristics of those routes

It may not be obvious why a network administrator would use these tools. To understand this, think about the functions that a router performs in a network. First, in many ways, a router functions like a host in that there are certain services it provides—logins, network time, SNMP MIB data. These are router resources that a network administrator can control. Secondly, a router’s key function is to forward packets from one network interface to another. Hence the network administrator can do packet filtering, i.e., can control the packets passing through the router. The last key function of a router is to accept and distribute routing information. Thus, there must be a way to control routes that are accepted and distributed. The most common way to do this is with the routes themselves: by filtering routes based on their network numbers. A second, more complex way to filter routes is to use another characteristic of the routes, like last hop or some other arbitrary route attribute. It can be argued that all route filtering is done based on some route characteristic, be it the network number or some other attribute, but we keep them in separate categories because route filtering based on route characteristics tends to be much more complex than filtering using network numbers. Controlling routes based on route properties also tends to use radically different access list constructs.

For each of the four policy tools, I describe the typical policy set and provide an example of how the tool is used. I’ll come back to these examples in later chapters when I show how to build and use access lists.

Controlling router resources

In the original scenarios, we saw how letting unauthorized people log into a web server created problems. Similar problems can arise when unauthorized people are allowed to log into routers. Logins over the Internet can allow the theft of passwords and therefore the penetration of networks. Problems occur when unqualified people are allowed to make changes. For these reasons, as well as in a more general sense, network administrators need to have control over the resources on a router. The main concern here is, of course, security, but network robustness and business policy also play a large part.

Earlier in this chapter, I mentioned that policy sets are composed of one of three things: host IP addresses, packets, or network addresses. When we control router resources, the policy set we use consists of host IP addresses: the IP addresses of systems that can access the resource. Let’s look at a policy that defines which machines can access a certain router, restricting router logins to the hosts at IP addresses 192.168.30.1 and 192.168.33.5. Figure 1.1 shows how the network is configured with the router, the two hosts allowed to access it, and other hosts and networks.

Figure 1-1. A router and hosts that could potentially access it

The first step in defining the access policy is to define the policy set of hosts that can access the router. We do that as follows:

Policy Set #1: IP address 192.168.30.1

Policy Set #1: IP address 192.168.33.5

Policy Set #1: No other IP addresses

Each of the first two policy set entries adds a specific IP address to the policy set: Policy Set #1 contains the IP addresses 192.168.30.1 and 192.168.33.5. The third entry explicitly denies all other IP addresses.

Once the policy set is defined, we apply Policy Set #1 to router logins:

Router logins: Use Policy Set #1

The policy we have just defined says that only hosts with IP addresses 192.168.30.1 and 192.168.33.5 may log into the router.

Controlling packets passing through a router

On the Internet, high-profile web servers are constantly probed for potential security vulnerabilities and opportunities for crackers to penetrate a web server and alter its contents. These web servers can be substantially protected from this and other kinds of attacks by limiting the type of packet a router passes on to the servers. With this policy tool, also known as packet filtering, we define in our policy sets the kinds of IP packets that can pass through router interfaces. Packet filtering with access lists is a very common use of Cisco routers, particularly as part of firewalls. Although the primary concern here is security, robustness and business policy are also considerations, since an organization may find that certain kinds of packets cause problems. It may decide that it doesn’t want a certain type of network traffic passing through, thus conserving bandwidth or reducing costs.

Almost all organizations now have some kind of web presence, so let’s use the web server example to show how to specify a packet-filtering policy.

The policy will limit access to a web server on an interface of a router to the web protocols HTTP and SSL. Figure 1.2 shows a typical network configuration that a company might use for this purpose.

Figure 1-2. Restricting packets to a web server

This configuration shows a web server 192.168.35.1 on router interface Ethernet 0. The interface Ethernet 1 connects to other hosts and network segments with the company, while the serial line connects directly to the Internet.

First, let’s specify the policy set:

Policy Set #101: HTTP packets to the host at 192.168.35.1

Policy Set #101: SSL packets to the host at 192.168.35.1

Policy Set #101: No other packets

The first two policy set entries permit HTTP and SSL. The last entry excludes all other packets.

Finally, the policy set is applied to the router interface:

Ethernet interface 0: Apply Policy Set #101 to outgoing packets

The result is that the web server at 192.168.35.1 on interface Ethernet can be accessed only with web protocols.

Controlling routes accepted and distributed

In a previous scenario, a typographic error by a network administrator at one site causes both the site’s own users and those at a remote site to lose network connectivity. Networks would function perfectly if routers always distributed routes correctly and with the metrics and directionality that the network designers intended. But as I said, operator mistakes do happen. In another scenario, network traffic paths are not optimal to an organization in terms of cost. Often the desire for traffic between networks to flow in certain paths goes against what would naturally happen with no intervention. To prevent routing errors from causing problems and to implement traffic-flow preferences, network implementers use the policy tool called route filtering. Route-filtering policies specify what routes are accepted into a router and what routes and routing metric values are distributed from a router. The policy sets used are composed of network numbers and are applied to routing protocols to indicate what routes are accepted and distributed from a router or what route metric values those routes should contain.

The main motivations for using this policy tool are robustness and business policy. A network administrator wants to make sure that a network operates despite the presence of configuration mistakes, or a business may decide it wants traffic flowing over some paths instead of others to make a cost-effective use of bandwidth. Security can also be a motivation for implementing these policies since one way to attack a network is to inject bad routing information. Route filtering can effectively stop this attack.

Let’s look at a simple but very common application of route filtering. To implement such a policy, we first need to define what networks we want to accept. We then declare that these routes are the only routes accepted by a given routing protocol. In this example, we accept only two routes, 192.168.30.0/24 and 192.168.33.0/24, into an EIGRP routing process 1000. Figure 1.3 shows this network configuration.

Figure 1-3. A configuration where route acceptance and distribution must be controlled

The policy set used with route filtering is composed of network numbers. For this example, we have the following policy set:

Policy Set #2: Network 192.168.30.0/24

Policy Set #2: Network 192.168.33.0/24

Policy Set #2: No other networks

It contains the two networks we specified and excludes all other networks. We then use this policy set to express the routes accepted for a given routing process:

Routing process EIGRP 1000 accepts only routes in Policy Set #2

Only routes for networks 192.168.30.0/24 and 192.168.33.0/24 are accepted by EIGRP routing process 1000. All other routes are excluded, so only traffic for the two networks included will be permitted through the router.

Controlling routes accepted and distributedbased on route characteristics

Networks would be much easier to configure and manage if network numbers were the only criteria we had for route policies, but there are other criteria for making routing decisions, including route characteristics. For instance, in a previous scenario, a company connecting to the Internet wants to prefer all routes coming from a particular Internet service provider. An ISP may want to route traffic depending on preferences that its customers send along with their route advertisements. In these cases, policy decisions must be made on some route characteristic other than just the network number. Like the previous policy tool, the policy sets themselves are still made up of network numbers, but membership in this type of policy set is based on route characteristics. Although this kind of access policy is typically implemented when dealing with Internet connectivity using the BGP-4 routing protocol, it can be done with interior routing protocols as well. The main motivations for using this technique are business drivers and robustness, but security (e.g., preventing denial-of-service routing attacks) can also drive its use.

In the next example, we’ll see how to control routing based on the properties of routes. In this case, we route based on the path that routing information has taken. Organization A has a policy to never route traffic through Organization B. Figure 1.4 shows how network connectivity might look in this situation.

Figure 1-4. Organization A restricting traffic based on paths

Organization A connects to other organizations through a number of paths, some that go through Organization B and some that do not. The policy’s goal is to prevent traffic leaving Organization A from going through Organization B. To do this, Organization A needs to reject all routes with a path through Organization B. We build a policy set containing only routes that do not pass through Organization B:

Policy Set #100: Exclude all routes passing through Organization B

Policy Set #100: Include all other routes

Then we apply the policy set to a route process:

BGP Routing process #65001: Accept only routes in Policy Set #100

on the router connecting Organization A to Organization C.

Putting it all together

These four policy tools are the fundamental techniques that network designers use to create and maintain secure and stable networks. Think of them as four different ways to keep networks running. When faced with an Internet or intranet network policy issue, you can deal with it by controlling router resources, packet filtering, or managing route distribution based on network numbers or route characteristics. We have seen how hosts, packets, and routes are controlled through access lists. Another way to think about these tools is to picture the router as a giant filter, taking in service requests from hosts, packets, or routes, and then either forwarding them, modifying them, or dropping them. When we want to implement a network policy, we use our four policy tools as different types of filters on the routers. The actual filters are defined in access lists.

In this book, we’ll see how to use access lists to apply these four categories of policy controls, and will return to these examples in future chapters to demonstrate how access lists are used.