In the best of all possible worlds, network administrators would never need network policies. Crackers would never break into a router to invade a network, routers would never pass bad routing information, and packets would never take network paths that network administrators did not intend. Sadly, we live in a hostile, imperfect world. Consider the following scenarios:
Crackers penetrate Company A’s public web site. The intruders replace the company’s web content with pornography. Company A’s management and public relations are consumed with dealing with the resulting negative publicity, much to the detriment of the company’s core business.
A network administrator works at Site O, one of many sites within a large, geographically dispersed intranet. Instead of typing “19”, he types “10” (“9” and “0” are next to each other on the keyboard) when configuring a local router. As a result, Site O begins to advertise a route to network 10.0.0.0/8 instead of network 19.0.0.0/8. Since network 10.0.0.0/8 belongs to Site P, users on network 10 are unable to access the rest of the intranet. Network 19.0.0.0/8 users are also isolated because their route in Site P is also not getting advertised. Users at Sites O and P can’t do any work requiring access to network resources outside their respective sites.
A company has two connections to the Internet through different Internet service providers (ISPs), both at the same bandwidth. This has been implemented to provide backup routing in case one connection goes down. One of the ISPs has traffic-based prices while the other has a fixed price. To reduce costs, the company wants to use the fixed-price ISP unless the line to it goes down, in which case it will use the traffic-based Internet connection. Because a routing policy has not been implemented to enforce this preference, all Internet IP traffic passes through the usage-based connection, forcing the company to incur higher than necessary costs.
What can we conclude by looking at these scenarios? We see that crackers may try to penetrate networks, router configuration mistakes can happen, and network traffic may not flow through the path that network administrators intend. We see that these problems can occur accidentally or intentionally, often despite good intentions. In all these cases, if certain network policies had been formulated and enforced, costly problems could have been avoided.
Let’s look more closely at these scenarios. The first involves crackers breaking into a web site and modifying the contents. What kind of policy could prevent this situation? Allowing only HTTP (web) access to the web server from the Internet can greatly reduce the probability of a break-in, since such a policy makes it much more difficult for crackers to exploit operating system weaknesses or application software security holes. Even if someone gains access to the web server, preventing the use of services such as Telnet or FTP to or from the Internet would make it difficult to exploit the server as a platform for further attacks. It would also be difficult to upload pictures or other content to the server.
This first scenario deals with security. A network administrator must worry about the definitive network security concerns: unauthorized modification of information, denial-of-service attacks, unauthorized access, and eavesdropping. Throughout this book, you’ll learn how to use Cisco access lists to enforce security policies.
The intranet scenario describes how a configuration mistake at one site in an enterprise network can create problems for another site far away. In this case, an intranet Site O advertised a route for a Site P, causing users in Site O and Site P to be cut off from the rest of the intranet. Again, why are both cut off? Typos happen. Errors in judgment happen. Even with injections of bad routing information and the best of intentions, a network should keep running. Network policies that help retain tight control over routes can minimize the impact of human error.
This scenario illustrates the robustness problem. This problem is conceptually different from the first scenario and, in many ways, more difficult to deal with. In the security-oriented scenario, we are trying protect against hostile attacks. In the intranet scenario, we are trying to protect against operator mistakes. The difference in intent makes it much harder to anticipate where a problem can occur. Despite the difficulty, it is important that this type of scenario be anticipated. As intranets and the Internet become mission critical, configuration errors should not shut down networks. Configuration errors become more and more common as intranets and the Internet get bigger—the larger a network is, the more components it has that can fail in strange ways. Also, as more people are involved with maintaining a network, the greater the chance that one of them will make a configuration mistake. Access policies can minimize these risks. Maintaining a healthy and robust network is a major motivation for network access policies, as we will see repeatedly in future chapters.
In the final scenario, traffic should go to the cheaper path, which is identical to the other path in every respect except for the way it is billed. In this scenario, security and robustness are not prime motivations. Instead, nontechnical business factors drive traffic policy. Business drivers are a third major motivation for network access policies.
So these are the three key concerns that motivate the need for access policies: security, robustness, and business drivers. It should be mentioned that they are not always easily separated and distinct. Security is often (and should be) a major business reason for access policies. Good security also helps with network robustness: preventing denial-of-service attacks keeps the network up and healthy. Conversely, policies intending to maintain network robustness—minimizing the impact of accidental misconfiguration and equipment failures—can also minimize the impact of deliberate sabotage. Having a highly available, robust network is often a business goal that is key to an organization’s effectiveness. Despite some overlap, I mention our three motivations as separate goals because they are distinct and important enough to help us focus on why we implement access policies.
Now that you know why you should have policies, how do you implement them in Cisco router networks? How are Cisco access lists involved with policy at all? In this section, I describe a conceptual framework that can help with the design and implementation of policies. The key concept in this framework is the policy set.
If you think about policies in general (not just network access policy), every policy has two parts, what and how. “What” designates the objects included in a policy. “How” describes how those objects are affected by the policy. When a policy is enforced, some set of objects or is evaluated against whether it is affected by that policy. Let’s look at policies in a department store. The store has a policy on business hours. Employees may come in during a specific range of hours, and customers are allowed in during another range. How is this policy divided into the two parts? The affected objects (the “what”) are the store’s employees and customers. The “how” is that employees are allowed in during certain hours, and customers are permitted to shop during certain hours. Of course, people other than employees, such as delivery workers, also go into stores. As each person goes in, the policy is enforced, and we check to see whether they are employees, deliverers, or customers. If they are customers, they may enter only during certain hours.
Let’s look at other policies a store might have. Many stores do not permit customers to bring in knapsacks or large bags. The “what” in the policy are the knapsacks and large bags brought by people coming to a store. The “how” is a rule forbidding customers from bringing them into the store and forcing them to check those items into lockers or drop them off in some area. Also, stores typically have a policy that only employees may enter certain areas. The “what” in this policy is employees. The “how” is that only employees are permitted in some area.
When implementing traffic policies in Cisco router networks, we have to partition them in a similar way. The “what” of a policy, the set of objects affected, is what I will call the policy set. Let’s look at the policy sets in the department store example. For the business-hours policy, the policy set consists of the store’s customers. For the knapsack policy, the policy set consists of the knapsacks and large bags that customers bring into the store. For the restricted-area policy, the policy set is made up of the stores’ employees.
Policy sets are defined using a series of policy set entries. These entries include or exclude objects of interest from a policy set. Let’s go back to our department store policies to show how these policy set entries work. The store may have a policy that only employees who have undergone cashier training, supervisors, or managers may operate a cash register. In this case, the policy set is made of employees with the approved characteristics. We define the policy set with the following policy set entries:
Employees with cashier training Supervisors Managers
When an employee tries to operate a cash register, he enters an employee ID number, which is checked against a database to see whether the employee is in the policy set. Is he an employee with cashier training? Is he a supervisor? Is he a manager? If any of these conditions apply, that employee is permitted to operate the cash register. In our knapsack policy example, knapsacks and large bags are included in our policy set, which is defined with the following policy set entries:
Knapsacks Large bags
To enforce this policy, each person coming into the store with a bag is checked. Is the bag a knapsack? Then it is not permitted. Is the bag very large? Again, it is not permitted. If it is not one of the choices in the policy set (a purse, say), the policy does not apply, and the customer may bring the bag into the store.
If the store changes its policy to allow large bags containing merchandise to be returned or exchanged, the policy set is then defined with the following policy set entries:
Knapsacks Exclude large bags with merchandise for exchange or return Large bags
When this bag policy is enforced, people coming into the store have their bags checked. Do they have a knapsack? The bag may not be brought in. Does the bag have merchandise to exchange or return? Then it may be brought in. Is the bag large? If so, it may not be brought in. Policy set entries, as mentioned earlier, can either include or exclude objects from the policy set.
Notice that we add each entry to the policy set in the order specified. This is important because objects are compared sequentially against a policy set. As soon as an object matches a policy set entry, no more matching is done. If we had the policy set entries in the following order:
Knapsacks Large bags Exclude large bags with merchandise for exchange or return
then “Large bags” are matched before excluding large bags with merchandise to be exchanged, and no exception is made.
Enforcing policies takes up resources and has costs. The longer the policy set, the longer it takes to enforce the policy, and more resources are required. Using our department store example, if our policy set spelled out different colors of knapsacks and bags:
Green knapsacks Purple knapsacks Red knapsacks Beige knapsacks All other knapsacks Aquamarine bags Blue bags Yellow bags Exclude pink bags with merchandise for exchange or return Exclude all large bags with merchandise for exchange or return All other bags
it would obviously take longer for an employee to inspect incoming bags. The number of points where policies are enforced also has an effect on resources. A store with many entrances would need to have an employee at each entrance to enforce the bag policy. This is why many department stores have only one entrance: to minimize the number of employees needed to enforce such a policy.
In network policies, policy sets are sets of the network objects that pass through or into a router. The three types of network objects that routers process are host IP addresses, packets, and routes. Network administrators implement policies by defining policy sets of these objects and applying rules to them. The policies are enforced as routers check the host IP addresses, packets, and network numbers going through them to see if they are members of a defined policy set. If so, rules are applied to those network objects.
Let’s give a few examples to show how network policies and policy sets work. I’ll describe a network policy, then break down each policy into a policy set and its rules. Let’s start with the following policy:
Only hosts in network 192.168.30.0/24 can log into Router A
This is the network analog of the department store policy of allowing only employees into certain areas. In this case, the policy set is composed of the IP addresses in the network 192.168.30.0/24, which we can define as follows:
Policy Set #1: Hosts with IP addresses in network 192.168.30.0/24
We implement this policy by allowing only hosts in the policy set to log into Router A. The rule that we apply is the following:
Router logins are permitted only from Policy Set #1
When someone tries to log into the router, the IP address of the host is checked. If the IP address is in Policy Set #1, the person is permitted to log on. This is one way of limiting who can make changes to a router.
For convenience, policy sets are labeled with numbers and, in some instances, names. This permits us to reuse policy sets. Let’s add another policy as follows:
Only hosts in network 192.168.30.0/24 may use Router A as an NTP (time) server
We can then have the following policy setting without redefining a new policy set:
Only hosts in Policy Set #1 may use the NTP Service
The previous example showed how sets of host addresses form a policy set. Another type of network object that can be used to form policy sets is a packet. A security-oriented policy might state:
Only web traffic is allowed to Host A
Such a policy is designed to prevent scenarios like the one mentioned previously, where a web server was penetrated and altered. The policy set in this example consists of IP packets carrying the HTTP protocol (the web protocol) going to Host A:
Policy Set #101: HTTP Packets to Host A
The policy set is applied against the router interface leading to Host A:
Only packets in Policy Set #101 can pass through the router interface leading to Host A
Only packets in Policy Set #101 are allowed through the interface to the host. Since web packets are the only packets defined in Policy Set #101, traffic to Host A is effectively limited to web traffic.
In addition to host IP addresses and packets, policy sets can be comprised of routes. A policy might say the following:
Accept only routes to network 192.168.65.0/24 from other routers
A policy like this could be used to send only traffic to network 192.168.65.0/24 through a given router. It might also be used if we know that only routes to 192.168.65.0/24 arrive at the router. Any other routes received would be there only because of configuration mistakes (robustness being the key concern) or intentional attacks (security the key concern). Whatever our motivation, the policy set would be the following:
Policy Set #2: Network 192.168.65.0/24
How would the policy set be affected? It would be as follows:
Routing protocol: Accept only Policy Set #2
The result would be that network 192.168.65.0/24 is the only route allowed into the router’s routing table.
As policies get more complex, it can be difficult to separate out a policy set. Take the following policy:
Network traffic should pass through Organization X only as a last resort
In other words, traffic should not go through Organization X unless no other route is available. This type of policy deals with scenarios like those discussed previously, where for business reasons like cost, certain network paths are preferred. How do we specify a policy set for this? Because traffic will not flow through a router to a given destination unless routing information exists for that destination, we can implement this policy by defining a policy set of all the routes going through Organization X:
Policy Set #3: All routes going through Organization X
We can then weight the metrics of the routes from the policy set to make them less appealing to routing processes and usable only as a last resort:
Routing protocol: Add extra routing metric values to routes in Policy Set #3
So far, I have focused only on policy sets, so you might be wondering how Cisco access lists come into the picture. The function of Cisco access lists is to hold the specification of a policy set. The term “access list” is somewhat deceptive in that it implies only a security function. Though access lists are indeed used for security functions, they are properly understood as a general mechanism used by Cisco routers to specify a set of network objects subject to policy. Access lists are built of access list entries, which directly correspond with policy set entries.
The framework described here is useful because it helps us think about network policies in ways that are almost directly translatable into Cisco access lists. In future chapters, I will almost always define network policies in terms of a policy set and a policy imposed upon it.
Get Cisco IOS Access Lists now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
