Chapter 13: Policy Networking

In Depth

Behind all switching implementations and configurations lies an area that, if left unattended, can render you and your network defenseless: access security policies. In this chapter, we will discuss the need for and creation of access security policies; we will also focus on how to implement these policies.

Security is one of the most important functions in today’s networks. Without it, competitors would have access to various data warehouses, and hackers and common users would have an open invitation to your network. With e−commerce booming, the need to strengthen network security in order to reduce network intrusion and network vulnerabilities becomes increasingly important.

Note	You can never count on network and data security even if it is in place, because it’s only as
	secure as you make it. To implement strong security measures, you must begin at the physical
	device and extend them throughout your entire network.

Once access policies have been created, it’s a great advantage to you, as the network administrator, to know how to implement these policies and how to distribute them. The following sections will cover this material in depth and explain how it relates to Internet Protocol (IP) switching and routing.

Access Security Policies

An access security policy is designed to help define what your network needs in order to be secure from all possible intrusions. Creating this policy for your business or entity allows you, as the network administrator, to provide service−level agreements (SLAs) based on a set of defined traffic and security standards.

An access security policy should define the following:

∙The physical security of all the devices in the network

∙Control of user access to the network through the implementation of virtual LANs (VLANs) and port security

∙What traffic should be allowed in and out of the network

∙Route filters to determine the data that should be sent through the network and what route filters should be applied at the Distribution layer

∙User groups that have access to each area of the network

∙Types of access each user group should have to the network

Each layer of the network has a different function and applies policies differently. Figure 13.1 shows the policies and switches found at each layer of the network. Policies defined in the access security policy need to be applied to all the devices in your network. In the following sections, we will address how security should be applied at each individual layer of the network.

254

Figure 13.1: A short list of various switches overlapping into different areas of the policy layers.

Core Layer Policies

By implementing security policies at the Core layer, also known as the backbone, you increase the elapsed amount of time between when a device requests access to a network and when it is allowed to transmit because of the amount of processing that is done on the switch. The job of the Core layer is to pass traffic as quickly as possible. Policies should be applied at the Access and Distribution layers before the data reaches this level. The Core layer should rely on the other two layers to provide filtering and security policies.

Note According to Cisco, the only policies at the Core layer should relate to Quality of Service (QoS)—features that allow for lower processing on the switch processor. This allows for a guarantee of a particular level of service for a given connection. Limiting policies this way will aid in congestion management and congestion avoidance.

Distribution Layer Policies

The Distribution layer is the primary layer for implementing security access policies. Implementation at this layer can be as simple as applying policy blocking to workgroups, or as complex as defining which paths different types of data should take through the network. The Distribution layer is also responsible for advertising correct routes, blocking identified traffic, and limiting the amount of data sent to the Core layer.

Note When you configure route summarization and distribution lists at the Distribution layer, they may have an adverse affect on the Core layer—mainly in the form of increased latency. Be sure you have a firm understanding of what you want to accomplish when configuring these policies.

As the demarcation point between the Access and Core layers, the Distribution layer is the perfect location in the network to administer most of your policies. At this layer, you will define which resources and routes are to be sent to the Core layer, as well as what traffic should be allowed in or out of a switch block.

A good policy at this layer ensures that no unnecessary traffic or incorrect routes will be advertised to the Core layer. A good Distribution layer policy should define the following:

∙User traffic that can span different VLANs—This policy can be defined by applying access lists to identified interfaces to permit or deny certain data traffic.

∙Routes that should be seen by the core switch block—These can be defined by applying distribution lists, which are another form of access lists.

∙Services that will ultimately be advertised to the rest of the network—These services include the Domain Name Service (DNS) and Dynamic Host Configuration Protocol (DHCP).

In this section, we will cover the following issues relating to the Distribution layer of the network:

∙Access lists

∙Managing virtual terminal access

255

∙ Managing Hypertext Transfer Protocol (HTTP) access

Access Lists

An access list is a list of conditions that control access to the switch, router, or route processor. IP, AppleTalk, and Internetwork Packet Exchange (IPX) access lists are like gatekeepers that control access from or to different segments of the network. After you build an access list, it can be applied to an inbound interface or an outbound interface. Once it has been applied to the interface, an implied “deny all” appears at the end of each access list.

The packets are filtered by comparing an identified value and acting upon a permit or deny statement. The list compares the packets receiving information (such as the source and destination addresses) to the values in your access list. If a match is made, the list follows the order to permit or deny the data. If a packet is denied, an Internet Control Message Protocol (ICMP) message is sent to the sending interface listed in the packet header, notifying the requester that the packet has been denied.

In Figure 13.2, the source address of 10.1.128.6 is trying to send a data packet to 10.1.128.10. Because the configured access list doesn’t contain a permit statement for the source address, the access list automatically denies the packet.

Figure 13.2: The request from x.x.128.6 to x.x.128.10 encounters an access list with no permit statement applied to the interface. As a result, the request is denied.

Before you apply the access list to the currently used management station using a console port or virtual terminal port, always remember to check that you have a permit statement near the top of your access list for the management station you are using. You won’t believe how many times we have had to deal with an administrator who is unfamiliar with access lists and who has locked himself out of his own internal or external route processor.

Tip It is important to remember that an access list is read in the order that it is configured. Here’s an analogy: Suppose you’re walking down a lane in a parking lot, looking for your car. Once you find your car, you don’t continue looking. Access lists work the same way—if the access list makes a match, it does not continue looking for further instructions.

Access List Types

There are two types of access lists: standard and extended. Both types permit or deny based on certain criteria. The standard access list allows a permit or deny statement based only on the source address. The extended access list is a bit more complex—it allows you to permit or deny based on the source address, destination address, protocol type, application type, or port number of the packet.

Standard IP and IPX addresses are the easiest to configure. The configuration statement requires an access list number, a permit or deny statement, and then the source address. This statement allows packets originating from the identified source address to be permitted or denied through the interface to which the access list is applied. Let’s take a look at an example of permitting the source address from Figure 13.2 on access list 2:

CAT5KRSM (config)# access−list 2 permit 10.1.128.6

To identify a subnet in one statement, use a wildcard value after the IP address. If a wildcard value is not present, the source address must match completely. The wildcard value looks a lot like a subnet mask. A 0 in the wildcard string indicates that the value must match exactly in the same octet as the IP address; the value 255 allows any number in the corresponding octet of the IP address to be used. Let’s look at the following

256

access list string as an example:

access−list 2 permit 193.5.5.10 0.0.0.255 log

Tip An octet is the 8−bit value between each dotted decimal in an IP address. For the IP address of 193.5.5.10 the first octet is 193 and the fourth octet is 10. It is always important to remember which octet you want to mask.

The 0.0.0 of the wildcard address means that the first three octets of the source interface’s IP address must exactly match the first three octets of the network portion of the Class C IP address: 193.5.5. Because the last octet is 255, the last octet of the source interface of received data can be any value. This statement means that any host address with the network ID 193.5.5 will be permitted. Based on this IP scheme, you may be using variable−length subnet masks (VLSM).

To identify IP addresses that can be used within your chosen subnet mask, you must use the correct inverse address to identify those addresses. Table 13.1 shows the possible wildcard inverse addresses matched to the subnet mask.

Table 13.1: Possible wildcard inverse addresses.

Mask	Wildcard Inverse Address
255	0
254	1
252	3
248	7
240	15
224	31
192	63
128	127
0	255

There is an easy way to figure out the wildcard inverse mask for your access list or the first network available with any subnet mask. Always remember the magic number of 256, then subtract the network mask minus 1. For example, with 255.255.255.192, use the 192, subtract it from the magic number of 256, and you will get 64, which is your first network. Subtract one more and you will get the inverse wildcard mask for your access list identifying the network.

Here’s another example. Say you have a class C subnet mask of 255.255.255.224. Subtract 224 from the magic number of 256 and you will get the first valid network of 32. Subtract 1 and you will get the network inverse mask of 31.

You can use the same magic number to subnet. Let’s say you want to know the first and second networks of a 30−bit mask that is commonly used on point−to−point WAN links in order to conserve IP addresses. This would be a mask of 255.255.255.252. Taking the magic number of 256 and subtracting 252 we would get the number 4, which is our first valid network number. This time, instead of subtracting one, multiply by 2 and you get your second valid network, which is 8. This means that your valid hosts are 5 and 6 and your broadcast address is 7. This means we have just created a network with two hosts and wasted no IP addresses.

Let’s look at another example using 255.255.255.240, which is a 28−bit mask. Table 13.2 shows the first three valid networks, the network numbers, the valid hosts for each network, and the broadcast address for each subnetted network.

Table 13.2: Example of subnetting 255.255.255.240.

257

Item	Network 1	Network 2	Network 3
Network	16	32	48
First Host	17	33	49
Last Host	30	46	62
Broadcast Address	31	47	63

Subnetting using variable length subnet masks (VLSM) seems pretty easy, doesn’t it?

The type of access list defined is identified by the number you assign to the access list. Table 13.3 identifies the types of access lists that can be configured, along with the associated string of numbers that can be used with each type.

Table 13.3: The available access list numbers and the associated access list types.

Available Numbers	Access List Type
1 through 99	IP standard
100 through 199	IP extended
200 through 299	Protocol−Type−Code
300 through 399	DECnet
600 through 699	AppleTalk
700 through 799	48−bit Media Access Control (MAC) address
800 through 899	IPX standard
900 through 999	IPX extended
1000 through 1099	IPX Service Advertising Protocol (SAP)
1100 through 1199	Extended 48−bit MAC address
1200 through 1299	IPX summary address

Extended access lists use many of the same configuration rules as standard access lists. An extended access list allows filtering based on source address, destination address, protocol type, application, or TCP port number.

Note	Just as in standard access lists, an implied “deny all” exists at the end of each extended access
	list.

The IP extended access list command is more complex than the standard access list command and offers many more options. The IP extended access list syntax is shown here:

access−list access−list−number {deny|permit} {protocol type} source−address source−wildcard destination−address destination−wildcard [protocol specific options|operator] [log]

Tip You can use the syntax any as a parameter to replace the source or destination address; any implies all addresses. In IPX access lists, A(n−1) indicates an any syntax.

Let’s take a look at the syntax elements for the IP extended access list that are not included in the standard access list:

∙access−list−number—For an IP extended access list, the range of possible numbers is 100 to 199.

∙deny|permit—A permit indicates whether the source will be allowed in or out of an interface. A deny indicates that the data will be dropped and an ICMP message will be sent to the source address.

∙protocol type—This syntax element indicates the protocol to match. Possible options include eigrp, icmp, igrp, ip, nos, ospf, tcp, udp, or any number from 0 to 255.

Tip The protocol syntax of ip indicates all protocol types.

258

∙operator—This syntax element compares source or destination ports. Possible syntaxes include lt (less than), gt (greater than), eq (equal), neq (not equal), and range (inclusive range).

∙log—This syntax enables logging of information about packets that match access list entries.

Warning The log command is optional and logs information about all packets that match the access list entry. Enabling this feature uses considerable processing power. You should use it for troubleshooting purposes only.

Let’s take a look at the any parameter:

CAT5KRSM(config)# access−list 199 permit tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 gt 255

CAT5KRSM(config)# access−list 199 permit tcp any any gt 255

The first line permits any incoming IP address to any destination using any TCP port greater than port 255. The second line does the same thing, but replaces the source, destination, and wildcard addresses with the any command.

Now, let’s examine how well−known TCP ports can work:

CAT5KRSM(config)# access−list 199 permit tcp any any eq 25

CAT5KRSM(config)# access−list 199 permit tcp any any eq smtp

The first line indicates that access list 199 permits any address to enter the interface for TCP port 25, which is the well−known TCP port for Simple Mail Transfer Protocol (SMTP). The second line does the same thing, but instead of using the TCP port number, it uses the acronym.

The host syntax indicates a single host, as shown in the source address in this example:

CAT5KRSM(config)# access−list 199 permit tcp host 38.187.128.6 any eq smtp

The following example permits User Datagram Protocol (UDP) packets with a DNS name as the destination:

CAT5KRSM(config)# access−list 199 permit udp any eq domain any

You can add a message in your access list by using the remark command. This command can help you identify lines in your access list. The following is an example of using the remark command:

CAT5KRSM(config)# access−list 1 remark Sabrina’s IP Address

CAT5KRSM(config)# access−list 1 permit 18.1.12.25

CAT5KRSM(config)# access−list 1 remark Hanson’s IP Address

CAT5KRSM(config)# access−list 1 deny 18.1.12.26

To remove a remark, use a command like the following:

CAT5KRSM(config)# no access−list 5 remark Sean’s IP address

Applying Access Lists

Access lists are created in various ways. Once they’re created, you can use different commands to apply an access list to various types of interfaces.

Tip To disallow the flow of data through any port or interface, use the in syntax. To allow data to flow through the switch but not exit out a certain interface or port, use the out syntax on the outbound interface.

The following list shows the different commands and the types of interfaces associated with each command:

259

∙access−class—Applies the access list to an interface for security purposes. This command identifies users of specified VTY lines. By default, five VTY lines come in to your Cisco Internetwork Operating System (IOS) or router. Because you do not know which one you will be using when you Telnet into your switch or router, you must apply the same access list to all the interfaces.

∙access−group—Allows you to apply an access list configured in Global Configuration mode to an interface that can be used to filter data traffic based on source address, destination address, or many other protocol identifiers. For example, if a standard access list has been created and numbered access list 2 in Global Configuration mode and you want to deny traffic for the source address identified in the access list, use the command ip access−group 2 followed by either in or out. The in or out syntax indicates whether data will be filtered based on traffic entering or exiting out of the interface.

∙distribute−list—Identifies the routing update information that applies rules to allow the switch to learn new routes or advertise known routes to other routers or route processors. This is used on the (config−router) command mode when enabling a routing protocol.

∙ipx output−sap−filter—Allows the applied access list to determine what IPX protocol services will be advertised in or out of an interface.

Applying Access Lists to Route Filtering

By controlling the routing tables at the Core layer, you can limit the size of the tables on your network devices. Doing so allows the switches to process data more quickly, prevents users from getting to networks that do not have a default or static route, and maintains routing information integrity.

To do this, apply an access list using the distribute−list command. After creating a standard access list, you can apply it to an inbound or outbound interface. The following is the distribute−list command and the syntax for an inbound interface:

distribute−list {access−list number|name} in [type number]

Here is the syntax when using the distribute−list command to apply an access list to an outbound interface:

distribute−list {access−list number|name} out

[interface name|routing process|autonomous system number]

Figure 13.3 shows a standard Class C network in which two subnets intersect at the Distribution layer switch. Subnet 128 belongs to a production network, and subnet 129 is used only for testing and development of new LAN topologies. We want subnet 128 to be permitted through to the Core layer on Gigabit Ethernet port g0/0, which connects to the Core layer switch. The second network is used for testing purposes only, so the access list should block any traffic from that subnet from reaching the Core layer switches. For this scenario, we will assume there are no other subnets in our switch block to contend with.

Figure 13.3: Two Class C IP subnets connected from the Access layer to the Distribution layer switch. Let’s create an access list that allows traffic from network 192.128.0.0 but denies traffic from interface192.129.0.0. Use the following command, keeping in mind that an implied “deny all” exists at the end of our access list:

access−list 2 permit 192.128.0.0 0.0.255.255

260