CCNA :: Part 9 - IP Access Lists - Standard

Standard IP Access Control Lists

IP access control lists (ACLs) cause a router to discard some packets based on criteria defined by the network engineer. The goal of these filters is to prevent unwanted traffic in the network—whether to prevent hackers from penetrating the network or just to prevent employees from using systems they should not be using. IP access lists can also be used to filter routing updates, to match packets for prioritization, to match packets for VPN tunneling, and to match packets for implementing quality of service features.

As soon as you know what needs to be filtered, the next step is to decide where to filter the traffic. Fig. 45 serves as an example. In this case, imagine that Bob is not allowed to access the WWW Server, but Larry is.

                                                                    Fig - 45

Filtering logic could be configured on any of the three routers and on any of their interfaces. The dotted arrowed lines in the figure show the most appropriate points at which to apply the filtering logic in an ACL. Because Bob’s traffic is the only traffic that needs to be filtered, and the goal is to stop access to WWW Server, the access list could be applied at either R1 or R3. And because Bob’s attempted traffic to WWW Server would not need to go through R2, R2 would not be a good place to put the access list logic. For the sake of discussion, assume that R1 should have the access list applied.

Cisco IOS software applies the filtering logic of an ACL either as a packet enters an interface or as it exits the interface. In other words, IOS associates an ACL with an interface, and specifically for traffic either entering or exiting the interface. After you have chosen the router on which you want to place the access list, you must choose the interface on which to apply the access logic, as well as whether to apply the logic for inbound or outbound packets. For instance, imagine that you want to filter Bob’s packets sent to WWW Server. Fig. 46 shows the options for filtering the packet.

                                                                       Fig - 46

Filtering logic can be applied to packets entering S1 or to packets exiting E0 on R1 to match the packet sent by Bob to WWW Server. In general, you can filter packets by creating and enabling access lists for both incoming and outgoing packets on each interface. Here are some key features of Cisco access lists:

_Packets can be filtered as they enter an interface, before the routing decision.

_Packets can be filtered before they exit an interface, after the routing decision.

_Deny is the term used in Cisco IOS software to imply that the packet will be filtered.

_Permit is the term used in Cisco IOS software to imply that the packet will not be filtered.

_The filtering logic is configured in the access list.

_At the end of every access list is an implied “deny all traffic” statement. Therefore, if a packet does not match any of your access list statements, it is blocked.

For example, you might create an access list in R1 and enable it on R1’s S1 interface. The access list would look for packets that came from Bob. Therefore, the access list would need to be enabled for inbound packets, because in this network, packets from Bob enter S1, and packets to Bob exit S1.

Access lists have two major steps in their logic: matching and action. Matching logic examines each packet and determines whether it matches the access-list statement. For instance, Bob’s IP address would be used to match packets sent from Bob. IP ACLs tell the router to take one of two actions when a statement is matched: deny or permit. Deny means to discard the packet, and permit implies that the packet should continue on its way.

So the access list for preventing Bob’s traffic to the server might go something like this:

Cisco calls its packet-filtering features “Access Control Lists” in part because the logic is created with multiple configuration commands that are considered to be in the same list. When an access list has multiple entries, IOS searches the list sequentially until the first statement is matched. The matched statement determines the action to be taken. The two diamond shapes in Fig. 46 represent the application of access list logic.

The logic that IOS uses with a multiple-entry ACL can be summarized as follows:

1. The matching parameters of the access-list statement are compared to the packet.
2. If a match is made, the action defined in this access-list statement (permit or deny) is performed.
3. If a match is not made in Step 2, repeat Steps 1 and 2 using each successive statement in the ACL until a match is made.
4. If no match is made with an entry in the access list, the deny action is performed.

IOS IP ACLs match packets by looking at the IP, TCP, and UDP headers in the packet. Extended access lists can check source and destination IP addresses, as well as source and destination port numbers, along with several other fields. However, standard IP access lists can examine only the source IP address.

Regardless of whether you use standard or extended IP ACLs, you can tell the router to match based on the entire IP address or just a part of the IP address. For instance, if you wanted to stop Bob from sending packets to WWW Server, you would look at the entire IP address of Bob and WWW Server in the access list. But what if the criteria were to stop all hosts in Bob’s subnet from getting to WWW Server? Because all hosts in Bob’s subnet have the same numbers in their first three octets, the access list could just check the first three octets of the address to match all packets with a single access-list command.

Cisco wildcard masks define the portion of the IP address that should be examined. When defining the ACL statements, as you’ll see in the next section of this chapter, you can define a wildcard mask along with the IP address. The wildcard mask tells the router which part of the IP address in the configuration statement must be compared with the packet header.

The wildcard masks were mentioned in the previous parts of the course, but here is the example table once again:

Wildcard Mask	Binary Version of the Mask	Description
0.0.0.0	00000000.00000000.00000000.00000000	he entire IP address must match.
0.0.0.255	00000000.00000000.00000000.11111111	Just the first 24 bits must match.
0.0.255.255	00000000.00000000.11111111.11111111	Just the first 16 bits must match.
0.255.255.255	00000000.11111111.11111111.11111111	Just the first 8 bits must match.
255.255.255.255	11111111.11111111.11111111.11111111	Don’t even bother to compare; it’s automatically considered to match (all 32 bits are "don’t care" bits).
0.0.15.255	00000000.00000000.00001111.11111111	Just the first 20 bits must match.

Before diving into the configuration, here’s a quick review of how standard IP ACLs work:

If statement 1 is matched, carry out the action defined in that statement. If it isn’t matched, examine the next statement. If it matches, carry out the action it defines. Continue looping through the list until a statement is matched or until the last statement in the list is not matched. If none of the statements is matched, the packet is discarded.

Configuration

The following table lists the configuration commands related to standard IP access lists.

Command	Description
access-list access-list-number {deny | permit} source [source-wildcard] [log]	Global command for standard numbered access lists. Use a number between 1 and 99 or 1300 and 1999, inclusive.
access-list access-list-number remark text	Defines a remark that helps you remember what the ACL is supposed to do.
ip access-group {number | name [in | out]}	Interface subcommand to enable access lists.
access-class number | name [in | out]	Line subcommand to enable either standard or extended access lists.
show ip interface [type number]	Includes a reference to the access lists enabled on the interface.
show access-lists [access-list-number | access-list-name]	Shows details of configured access lists for all protocols.
show ip access-list [access-list-number | access-list-name]	Shows IP access lists.

The following example attempts to stop Bob’s traffic to WWW Server. You can see two different ways to set the same rule:

!
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
ip access-group 10 out
duplex auto
speed auto
!
...
!
access-list 10 deny 172.16.3.10 0.0.0.0
access-list 10 permit any
access-list 10 remark Stop all traffic whose source IP is Bob

!
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
ip access-group 10 out
duplex auto
speed auto
!
...
!
access-list 10 remark Stop all traffic whose source IP is Bob
access-list 10 deny host 172.16.3.10
access-list 10 permit any
!