IP Access Control List Security

                         

Network security is one of the hottest topics in networking today. Cisco routers and switches can be used as part of a good overall security strategy. The most important tool in Cisco IOS software used as part of that strategy is Access Control Lists (ACLs). ACLs define rules that can be used to prevent some packets from flowing through the network.

Standard 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—where to prevent hackers or just to prevent employees from using systems that should not be using and so on.  

           

This chapter covers two main categories of IOS IP ACLs, standard and extended. Standard ACLs use simpler logic, and extended ACLs use more-complex logic.    

     

ACLs may also be used for purposes other than filtering IP traffic. For example, defining traffic to Network Address Translate (NAT) or encrypt, or filtering non-IP protocols such as AppleTalk or IPX.

  

IP Standard ACL Concept 

As soon as you know what needs to be filtered, the next step is to decide where to filter the traffic. Cisco IOC software applies the filtering logic of an ACL either as a packet enters an interface or as it exist 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 (traveling towards a place rather than leaving it.) or outbound packets.

           

Look at the following image:

                                                           

                                                                        Router

Here are some key features of 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 IOS to imply that the packet will be filtered.

·         Permit is the term used in IOS to imply that the packet will not be filtered.

·         At the end of every access list is an implied “deny all traffic” statement. Therefore, if a packet not matches any of your access list statement, it is blocked. These two ACLs (101 and 102) have the same effect:

               access-list 101 permit ip 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255

               access-list 102 permit ip 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255 

               access-list 102 deny ip any any 

·         When you refer to a router, these terms have these meanings:

Out - Traffic that has already been through the router and is leaving the interface. The source is where it has been (on the other side of the router) and the destination is where it goes.

In - Traffic that arrives on the interface and then goes through the router. The source is where it has been and the destination is where it goes (on the other side of the router).

Access list have two major steps in their logic: matching and acting. Matching logic examines each packet and determines whether it matches the access-list statement. ACLs tell the router to take one of two actions when a statement is matched: deny or permit. When an access list has multiple entries, IOS searches the list sequentially (following in order) until the first statement is matched. The matched statement determines the action to be taken.

           

Note: Because the switch stops testing conditions after the first match, the order of the conditions is critical. 
           

Wildcard Masks

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.

Cisco wildcard masks define the portion of the IP address that should be examined. For example, suppose that one mask implies that the whole packet should be checked and another implies that the only three octets of the address need to be examined.

Wildcard masks look similar to subnet mask, but they are not the same. The Wildcard mask’s 0 bits tell the router that those corresponding bits in the address must be compared when performing matching logic. The binary 1s in the Wildcard mask tell the router that those bits do not need to be compared.

Note: Unlike subnet masks, which require contiguous bits indicating network and subnet to be ones, wildcard masks allow noncontiguous bits in the mask.

           

The following table lists some of the more popular Wildcard masks, along with their meanings:

 

Standard IP Access List Configuration

Standard IP access lists can examine only the source IP address. Look at the following examples:

        

The number you use to denote your ACL shows the type of access list that you are creating. Standard IP access lists use a number in the range of 1 to 99 or 1300 to 1999. There is no difference in using one number or another, as long as it is in the correct range. In other words, list 1 is no better or worse than list 99. The access-list commands, under which the matching and action logic are defined, are global configuration commands. To enable the ACL on an interface and define the direction of packets to which the ACL is applied, the ip access-group command is used.

The wildcard mask of  0.0.0.0. means “match all 32 bits”, so only packets whose IP address exactly matches 172.16.3.10 match this statement and are discarded. The access-list permit 0.0.0.0 255.255.255.255 command, matches all packets.

Example 2

Cisco IOS allows both an older style and newer style of configuration for some parameters. The Figure 1 shows the older style and the router changes to the equivalent newer-style configuration in Figure 2. First, the use of a wildcard mask of 0.0.0.0 does indeed mean that the router should match that specific, host IP address. The newer style configuration uses the host keyword in front of the specific IP address. The other change to the newer style configuration involves the use of wildcard mask 255.255.255.255. The newer style configuration uses the keyword any to replace wildcard mask 255.255.255.255.

The following example shows how to create a standard ACL to deny access to IP host 172.16.20.1.

Editing an ACL requires special attention. For example, if you intend to delete a specific line from an existing numbered ACL as shown here, the entire ACL is deleted.

router#configure terminal

        Enter configuration commands, one per line.  End with CNTL/Z.

        router(config)#access-list 101 deny icmp any any

        router(config)#access-list 101 permit ip any any

        router(config)#^Z

  router#show access-list

        Extended IP access list 101

        deny icmp any any

        permit ip any any

  router#

        *Mar  9 00:43:12.784: %SYS-5-CONFIG_I: Configured from console by console

        router#configure terminal

               Enter configuration commands, one per line.  End with CNTL/Z.

               router(config)#no access-list 101 deny icmp any any

               router(config)#^Z

        router#show access-list

        router#

        *Mar  9 00:43:29.832: %SYS-5-CONFIG_I: Configured from console by console

To edit numbered ACLs, copy the configuration of the router to a TFTP server or a text editor such as Notepad. Then make any changes and copy the configuration back to the router.

Standard IP ACL: Example

The second standard IP ACL exposes more ACL issues. Figure 1 and Example 3 and 4 show a basic use of standard IP access lists, with two oversights in the first attempt. The criteria for the access list are as follows:

·         Sam is not allowed access to Buge or Daffy.

·         Hosts on the Seville Ethernet are not allowed access to hosts on the Yosemite Ethernet.

·         All other combinations are allowed.

At first glance, these two access lists seem to perform the desired function. However, when one of the WAV links fails, some holes can appear in the ACLs. For example, if the link from Albuquerque to Yosemite fails, Yosemite learns a route to 10.1.1.0/24 through Seville. Packets from Sam, forward by Yosemite and leave Yosemite’s serial 1 interface without being filtered. So criterion 1 is no longer met. Similarly, if the link from Albuquerque to Yosemite fails, Seville routes packets through Albuquerque, so criterion 2 is no longer met.

Example 5 illustrates an alternative solution –one that works even when some of the links fail.

Extended IP Access Control Lists

Extended ACLs were introduced in Cisco IOS Software Release 8.3. Extended IP access lists have both similarities and differences compared to standard IP ACLs. Just like standard lists, you enable extended lists on interfaces for packets either entering or exiting the interface. IOS searches the list sequentially and so on.

The one key difference between the two is the variety of fields in the packets that can be compared for matching by extended access lists. A single ACL statement can examine multiple parts of the packet header, requiring that all the parameters be matched correctly in order to match that one ACL statement.

When creating ACEs in numbered extended access lists, remember that after you create the list, any additions are placed at the end of the list. You cannot reorder the list or selectively add or remove ACEs from a numbered list. Look at the following example:

router#configure terminal

          Enter configuration commands, one per line.  

          router(config)#ip access-list extended test

          router(config-ext-nacl)#permit ip host 2.2.2.2 host 3.3.3.3

          router(config-ext-nacl)#permit tcp host 1.1.1.1 host 5.5.5.5 eq www

          router(config-ext-nacl)#permit icmp any any

          router(config-ext-nacl)#permit udp host 6.6.6.6 10.10.10.0 0.0.0.255 

eq domain

               router(config-ext-nacl)#^Z

        1d00h: %SYS-5-CONFIG_I: Configured from console by consoles-l

        router#show access-list

               Extended IP access list test

                       permit ip host 2.2.2.2 host 3.3.3.3

                       permit tcp host 1.1.1.1 host 5.5.5.5 eq www

                       permit icmp any any

                       permit udp host 6.6.6.6 10.10.10.0 0.0.0.255 eq domain

        router#configure terminal

        Enter configuration commands, one per line.  End with CNTL/Z.

        router(config)#ip access-list extended test

        !--- ACL entry deleted.

        router(config-ext-nacl)#no permit icmp any any

        !--- ACL entry added.

        router(config-ext-nacl)#permit gre host 4.4.4.4 host 8.8.8.8

        router(config-ext-nacl)#^Z

        1d00h: %SYS-5-CONFIG_I: Configured from console by consoles-l

        router#show access-list

               Extended IP access list test

                       permit ip host 2.2.2.2 host 3.3.3.3

                       permit tcp host 1.1.1.1 host 5.5.5.5 eq www

                       permit udp host 6.6.6.6 10.10.10.0 0.0.0.255 eq domain

                       permit gre host 4.4.4.4 host 8.8.8.8

Any deletions are removed from the ACL and any additions are made to the end of the ACL.

The following table summarizes the different fields that can be matched with an extended IP ACL, as compared with standard IP ACL.

IOS checks all the matching information configured in a single access-list command. Everything must match for that single command to consider a match and for the defined action to be taken.

Note: To match any Internet protocol (including TCP and UDP), use the keyword ip.

  

Extended IP ACL Configuration

Note: Use the no access-list access-list-number global configuration command to delete the entire ACL.

The following example focuses on understanding the basic syntax.

There are several new items to review. First, the access list number for extended access lists falls in the range of 100 to 199 or 2000 to 2699. Following the permit and deny action, the protocol parameter defines whether you want to check for all IP packets or just those with TCP or UDP headers. When you check for TCP or UDP port number, you must specify the TCP or UDP protocol.

The eq parameter means “equal”. It implies that you are checking the port numbers—in this case, the destination port number. You can use the numeric values or for the more popular options, a text is valid. If you were to enter eq 80, the config would show eq http.

With extended IP ACLs, Cisco suggests that you locate them as close to the source of the packet as possible.

In addition to defining ACL source and destination, it is possible to define ports, ICMP message types, and other parameters. A good source of information for well-known ports is RFC 1700.

The router can display descriptive text on some of the well-known ports. Use a ? for help.

                  access-list 102 permit tcp host 10.1.1.1 host 172.16.1.1 eq ?

                       bgp          Border Gateway Protocol (179)

                       chargen      Character generator (19)

                       cmd          Remote commands (rcmd, 514)

During configuration, the router also converts numeric values to more user-friendly values. This is an example where typing the ICMP message type number causes the router to convert the number to a name.

               access-list 102 permit icmp host 10.1.1.1 host 172.16.1.1 14

becomes

               access-list 102 permit icmp host 10.1.1.1 host 172.16.1.1 

               timestamp-reply

The following example shows how to create and display an extended access list to deny Telnet access from any host in network 171.69.198.0 to any host in network 172.20.52.0 and permit any others:

In this example, the last entry is sufficient. You do not need the first three entries because TCP includes Telnet, and IP includes TCP, User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP).

               access-list 101 permit tcp host 10.1.1.2 host 172.16.1.1 eq telnet 

               access-list 101 permit tcp host 10.1.1.2 host 172.16.1.1

               access-list 101 permit udp host 10.1.1.2 host 172.16.1.1

               access-list 101 permit ip 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255 

Named IP Access Lists 

You can identify IP ACLs with an alphanumeric string (a name) rather than a number. If you identify your access list with a name rather than a number, the mode and command syntax are slightly different. However, not all commands that use IP access lists accept a named ACL.

The name you give to a standard ACL or extended ACL can also be a number in the supported range of access list numbers. That is, the name of a standard IP ACL can be 1 to 99; the name of an extended IP

ACL can be 100 to 199.

Named ACLs have another key featured that numbered ACLs do not: you can delete individual lines in a named IP access list. With named ACLs, you can enter a command that removes individual lines in an ACL.

Consider these guidelines and limitations before configuring named ACLs:

• A standard ACL and an extended ACL cannot have the same name.

• Numbered ACLs are also available,

           

After you create an ACL, any additions are placed at the end of the list. You cannot selectively add ACEs to a specific ACL. However, you can use no permit and no deny commands to remove ACEs from a named ACL. This example shows how you can delete individual ACEs from a named ACL:

The following example shows the named IP ACL.

The above example begins with the creation of an ACL named Barney. The ip access-list extended barney command creates the ACL, naming it barney and place the user in ACL configuration mode. This command also tells the IOS that barney is an extended ACL. The permit and deny commands use the exact same syntax that the numbered access-list commands use.

ipThe show-config command output lists the named ACL configuration before the single entry is deleted. Next, the no deny ip… command deletes a single entry from the ACL.

The ACL does not actually filter any packets. It would need to be enabled on an interface first. For instance, the ip access-group out interface subcommand would enable the ACL.

Including Comments about Entries in ACLs

You can use the remark command to include comments (remarks) about entries in any IP standard or extended ACL. The remarks make the ACL easier for you to understand and scan. Each remark line is limited to 100 characters.

The remark can go before or after a permit or deny statement. You should be consistent about where you put the remark so that it is clear which remark describes which permit or deny statement. For example, it would be confusing to have some remarks before the associated permit or deny statements and some remarks after the associated statements.

For IP numbered standard or extended ACLs, use the access-list access-list number remark remark global configuration command to include a comment about an access list. To remove the remark, use the no form of this command.

In this example, the workstation belonging to Jones is allowed access, and the workstation belonging to

Smith is not allowed access:

For an entry in a named IP ACL, use the remark access-list global configuration command. To remove the remark, use the no form of this command.

In this example, the Jones subnet is not allowed to use outbound Telnet:

Applying ACLs to a Physical Interface

            The following example shows how to apply access list 2 on Gigabit Ethernet interface 0/2 to filter packets interning the interface:

Controlling Telnet Access with ACLs

         

Accessing into and out of the virtual terminal line (vty) ports can be controlled by IP access lists. You can use ACLs to limit the IP hosts that can Telnet into the router or the switch, and you can also limit the hosts to which a user of the router or the switch cans Telnet.

For example, imagine that only just in subnet 10.1.1.0/24 are supposed to be able to Telnet into any of the Cisco routers or switches in a network. In such a case, the following configuration could be used on each router or switch to deny access from IP addresses not in that subnet.

Note: When controlling access to a line, you must use a number and also you must use the access-class access-list-number {in | out} command.

The access-class command refers to the matching logic in access-list 3. The keyword in refers to Telnet connection into this router. As configured, ACL 3 checks the source IP address of packet for incoming Telnet connection.  

ACL Implementation Considerations

            Cisco makes following general recommendations about ACLs:

·         Create your ACLs using a text editor outside the router, and copy and paste the configuration into the router. That way, if you mistakes when typing, you can fix them in the editor. With numbered ACLs, to delete a single line, you have to delete the whole ACL and reenter all the commands in order. Or you might later want to add a line to it … Another reason to configure an access list before applying it is because if you applied a nonexistent access list to an interface and then proceed to configure the access list, the first statement is put into effect, and the implicit deny statement that follows could cause you immediate access problems.

·         Place extended ACLs as close to the source of the packet as possible to discard the packets quickly. If you are going to filter a packet filtering closer to the packet’s source means that the packet takes up less bandwidth in the network, which seems to be more efficient.

·         Place standard ACLs as close to the packet’s destination as possible, because standard ACLs often discard packets that you do not want discard when they are placed close to the source. For instance, imagine that Fred and Barney are separated by four routers. If you filter Barney’s traffic sent to Fred router, Barney can’t reach any hosts near the other routers.

·         Place more-specific statements early in the ACL. By placing more-specific matching parameters early in the list, you are less likely to make mistakes in the ACL. For example, imagine that you have a statement that permits all traffic from 10.1.1.1 to 10.2.2.2, destined, for port 80, and another statement that denied all other packets sourced in subnet 10.1.10/24. Both statements would match packets sent by host 10.1.1.1 to a web server at 10.2.2.2, but you probably meant to match the more-specific statement first.  

·         Disable an ACL from its interface (using the no ip access-group command) before making changes to it. If you have an IP ACL enabled on an interface and you delete the entire ACL, IOS does not filter any packets. Even so, as soon as you add a command to the ACL, the IOS starts filtering packets. If you want to enter a long ACL, you might temporarily filter packets you don’t want to filter! Therefore, the better way is to disable the list from the interface, make the changes to the list, and then reenable it on the interface.

·         Because the software stops testing conditions after it encounters the first match (to either a permit or deny statement), you will reduce processing time and resources if you put the statements that packets are most likely to match at the beginning of the access list. Place more frequently occurring conditions before less frequent conditions.

·         In order to make the purpose of individual statements more easily understood at a glance, you can write a helpful remark before or after any statement.   

Troubleshoot

How do I remove an ACL from an interface?

To remove an ACL from an interface, go into configuration mode and enter no in front of the access-group command, as shown in this example.

               interface <interface> 

               no ip access-group # in|out

What do I do when too much traffic is being denied?

If too much traffic is denied, study the logic of your list or try to define and apply an additional broader list. The show ip access-lists command provides a packet count that shows which ACL entry is being hit. 

Share