Which command will create an extended named access-list building )?
Before continuing, refer Introduction to Access Control Lists lesson , if you are not familiar with Access Contol Lists.
Refer Extended Access Control Lists lesson if you are not familiar with Extended Access Control List configuration IOS commands.
Refer Named Access Control Lists if you are not familiar with Named Access Control Lists configuration IOS commands.
The basic IOS command to create a named Access Control List [ACL] is shown below, which is similar to creating a numbered Access Control List [ACL].
Router[config]# ip access-list standard|extended ACL_name
The standard and extended keywords specify whether it is a Standard Access Control List [ACL] or an Extended Access Control List [ACL].
Extended Named Access Control Lists [ACLs] - Lab Practice
The following diagram shows our Extended Access Control List [ACL] lab setup. We have three routers, three switches, six workstations and three servers connected as below. The host names, IP addresses and the interfaces of the routers are shown in diagram. The IP addresses of the workstations and the servers are also shown in the diagram.
Figure4.3. An Example Network
Router[conflg]# interface serial 0
Router[config-if]# ip access-group 141 out
An example of an extended access list is as follows:
access-list 141 permit icmp host 172.16.130.88 10.0.0.0 0.255.255.255
access-list 141 permit tcp host 172.16.130.89 eq 734 10.0.0.0 0.
255.255.255 range 10000 10010
access-list 141 permit udp host 172.16.130.90 10.0.0.0 0.255.255.255
eq tftp
access-list 141 deny ip 172.16.130.0 0.0.0.255 host 192.168.10.118
access-list 141 permit ip any any
Table4.5 describes the extended access list commands.
Table4.5. A Description of Access List Commands
| access-list 141 permit icmp host 172.16.130.88 10.0.0.0 0.255.255.255 | Allows host 172.16.130.88 to send ICMP messages to any host on network 10.0.0.0. |
| access-list 141 permit tcp host 172.16.130.89 eq 734 10.0.0.0 0.255.255.255 range 10000 10010 | Allows host 172.16.130.89 to initiate TCP sessions from port 734 to any port between 10000 and 10010 on any host on network 10.0.0.0. |
| access-list 141 permit udp host 172.16.130.90 10.0.0.0 0.255.255.255 eq tftp | Allows host 172.16.130.90 to send files via TFTP [UDP port 69] to any host on network 10.0.0.0. |
| access-list 141 deny ip 172.16.130.0 0.0.0.255 host 192.168.10.118 | Denies any host on network 172.16.130.0 to host 192.168.10.118. Since we configured some permit statements from hosts within these previous two subnets, this entry will deny everything between these two networks that isn't explicitly permitted in the earlier listing. |
| access-list 141 permit ip any any | Allows all hosts from any network to any network, if it has not matched one of the preceding lists. Take a good look at the order of these commands to get a feel for the importance of the list order. Remember this is processed in a top-down manner, as shown in Figure 4.2. |
Just as in our standard access list, the extended access list will require a hyphen between the words access and list. Next is the list number. Since we are referencing an extended IP access list, the numbers would range from 100 to 199. The access list number serves the same dual purpose here as we looked at earlier with the standard access list. The router must have a way to distinguish between access lists. The number performs this purpose along with tying the lines of an access list together and designates which access list the filter is part of The number also tells the router the type of access list.
Desinging & Planning…
Placement of Access Lists
Often you have a few options about how to apply your access lists and stili achieve the same affect on the traffic flowing through the router, in the case of the previous example, access list 141 was applied outbound on the serial 0 interface. Because access list 141 was designed to only filter traffic originating from the 172.16.130.0 network, and not traffic from 172.17.0.0, this list could have been applied in the inbound direction on Ethernet 0. Both approaches will have the same affect on the traffic flowing through the router.
There is a minor difference between these two approaches, though. When the ACL is applied outbound on the Serial0 interface, the traffic enters the Ethernet0 interface and is processed against the routing table. The packet is then passed to the outbound interface, where it is checked against any outbound ACLs. If the outbound interface is Serial 0, it checks packets against access list 141 and will permit or deny the traffic based on the rules defined in that list.
When the ACL is applied inbound on the Ethernet0 interface, the traffic is permitted or denied before it is processed against the routing table. On a router under heavy traffic loads, this could make a considerable difference in the delay that is introduced because the router does not have to process packets that will be dropped by the outbound interface.
Although inbound filtering has the advantage with respect to route processing, that does not necessarily make it the better way to apply access lists. Under different circumstances, you may want to prevent access to an external subnet from both Ethernet interfaces. In this case, it may be easier to apply the access lists in the outbound direction of Serial0 because packets from both Ethernet interfaces will have to pass through Serial0 to get to the external subnet. In other words, you are applying the access list to the bottleneck in traffic. Otherwise, you will have to keep two separate access lists, one specific for Ethernet0 and the other specific for Ethernet1. If the router is under light traffic loads, it may be easier to maintain a single access list.
There is disagreement among network and security professionals about which approach is better, but neither approach should be considered better than the other in all cases. It is up to you to decide which is best for your situation.
Keywords permit or deny
A keyword permit or deny specifies to the router the action to be performed. For example, the keyword permit would allow the packet to exit or enter the interface, depending on whether you specify the filtering to be performed in or out. Again, this option provides the same function as in our standard access list. The last line of our extended access list example could have read as follows:
access-list 141 permit ip any any
Protocol
You have the option of filtering several different protocols using the extended access list. The protocol field in the IP header is an 8-bit number that defines what protocol is used inside the IP packet. TCP and UDP are only two of the possible protocols that can be filtered on, although they are most common. Other protocols, such as ICMP and EIGRP, have their own protocol numbers because they are not encapsulated inside TCP or UDP. If we use a question mark when defining an access list, we can see the protocol numbers that have been defined by name inside the router.
Router [config]#access-list 191 permit?
An IP protocol number
ahp Authentication Header Protocol
eigrp Cisco's EIGRP routing protocol
esp Encapsulation Security Payload
gre Cisco's GRE tunneling
icmp Internet Control Message Protocol
igmp Internet Gateway Message Protocol
igrp Cisco's IGRP routing protocol
ip Any Internet Protocol
ipinip IP in IP tunneling
nos KA9Q NOS compatible IP over IP tunneling
ospf OSPF routing protocol
pcp Payload Compression Protocol
pim Protocol Independent Multicast
tcp Transmission Control Protocol
udp User Datagram Protocol
Protocols not on the preceding list may also be filtered with extended access lists, but they must be referenced by their protocol number. A full list of assigned IP protocol numbers can be found at www.iana.org/assignments/protocol-numbers.
It is important to remember that the IP keyword in the protocol field matches all protocol numbers.You must use a systematic approach here when designing your access list. For example, if your first line in the access list permits IP for a specific address, and the second line denies UDP for the same address, the second statement would have no effect. The first line would permit IP, including all the above layers. An option here may be to reverse the order of the statements. With the statements reversed, UDP would be denied from that address and all other protocols would be permitted.
Source Address and Wildcard-mask
The source address and source wildcard-mask perform the same function here as in a standard IP access list. So, in the preceding example we could have used the wildcard mask instead of the host and any keywords. The access list would then look as follows:
access-list 141 permit ip 172.16.130.88 0.0.0.0 i0.0.0.0 0.255.255.255
access-list 141 permit ip 172.16.130.89 0.0.0.0 i0.0.0.0 0.255.255.255
access-list 141 permit ip 172.16.130.90 0.0.0.0 i0.0.0.0 0.255.255.255
access-list 141 permit ip 172.16.130.0 0.0.0.255 192.168.10.118 0.0.0.0
access-list 141 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
In the first three lines, we are permitting or allowing packets from individual hosts on subnet 172.16.130.0 to any host on network 10.0.0.0. In line 4, we are permitting packets with the source address that belongs to subnet 172.16.130.0 to the destination of host 192.168.10.118. Line 5 tells us that we are permitting all packets regardless of the source or destination address. Remember that standard IP access lists have a default mask of 0.0.0.0. This does not apply to extended access lists so we must specify one.
Destination Address and Wildcard-mask
The destination address and wildcard-mask have the same effect and structure as the source address and wildcard-mask. So, here the keywords host and any are also available. You can utilize these keywords to specify any destination address as well as a specific destination without using the wildcard mask. Remember that extended access lists try a match on both source and destination. A common mistake here is trying to build an extended access list with the idea of only filtering the source address, and forgetting to specify the destination address.
Source and Destination Port Number
Many times, we don’t want to deny all access to a particular server. When you put a Web server out on the Internet, you want everyone to be able to access it on port 80 [WWW], but you don’t want to allow access to any other ports, because it gives hackers the opportunity to exploit other services you may not be aware of [although you should know of them in the first place]. Restricting access to this level of detail is another benefit of extended ACLs. We have the option of specifying a source and destination port number in the access list. Let’s look at a simple example:
Router[config]# interface Serial 0
Router[config-if]# ip access-group 111 in
Router[config]#access-list 111 permit tcp any host 172.17.11.19 eq 25
Router[config]#access-list 111 permit tcp any host 172.17.11.19 eq 23
These commands are explained in Table 4.6.
Table4.6. Router Commands
| access-list 111 permit tcp any host 172.17.11.19 eq 25 | Permits SMTP from anywhere to host 172.17.11.19. |
| access-list 111 permit tcp any host 172.17.11.19 eq 23 | Permits Telnet from anywhere to host 172.17.11.19. |
| interface Serial 0 | Enters interface submode. |
| ip access-group 111 in | Applies access list inbound on interface. |
In line 1, we are permitting TCP packets from any source to the destination of host 172.22.11.19 if the destination port is 25 [SMTP]. In line 2, we are permitting TCP packets from any source to the destination of host 172.22.11.19 if the destination port is 23 [Telnet]. The implicit deny statement at the end of this access list will prevent all other traffic from making it into our network.
Let’s take a look at filtering with TCP and UDP. When using TCP, for example, the access list will examine the source and destination port numbers inside the TCP segment header. So, when using an extended access list, you have the capability to filter to and from a network address and also to and from a particular port number. You have several options when deciding which operator to use, such as:
■eq equal to
■neq not equal to
■gt greater than
■lt less than
■range specifies an inclusive range or ports [Here, two port numbers are specified.]
View chapterPurchase book
Read full chapter
URL://www.sciencedirect.com/science/article/pii/B9781931836562500088
Access Control List Examples
Different ACLs are used for different purposes. Let’s take a look at a few of the access control list types that Cisco defines for IOS:
- Standard ACL creates a list of IP addresses or IP address ranges. Standard access control lists are the simplest type of ACL.
- Extended ACL has more capability than a standard ACL. An extended ACL lists source and destination IP address pairs, and can even include what sort of traffic is flowing between the pairs. For example, an extended ACL could have an access control entry [ACE] identifying source IP address 10.100.200.3 talking to destination IP address 8.8.8.8 on port UDP 53. Extended ACLs offer fine control for traffic matching. Even more detailed matches are possible, such as matching on TCP flags or type-of-service values.
- IPv6 access control lists are similar to extended ACLs, but are used specifically for IPv6 addresses.
- MAC access control lists allow the filtering of traffic using the Ethernet MAC address of the traffic instead of the IP address. MAC ACLs are rarely used in production networks, but illustrate the power and flexibility available to network administrators.
- Prefix lists are typically used instead of standard ACLs when the goal is to filter routing updates. The syntax for prefix lists is less complicated than that of access control lists, particularly where route filtering is concerned.
There are several other kinds of access lists in the IOS world, including reflexive, lock and key, and MPLS. We don’t need to go through them all here. It’s enough for now to recognize that there are many different kinds of ACLs for different purposes. That said, the majority of Cisco IOS processes will use standard or extended ACLs, as well as prefix-lists, to identify traffic.
Tips for implementing access control lists
- Name your access control list using all capital letters. Device configurations can be long and crowded with information. One way to make a custom ACL stand out is by naming it in all capital letters. This is a policy I follow for any custom item I create at the command line interface [CLI]. At a glance, I can tell that a capitalized configuration object is something a human created, and not something included by default. This can be helpful when troubleshooting.
- An access list accomplishes nothing on its own. In other words, creating an ACL does not impact traffic in any way. An access list must be applied to something before it’s effective. I’ve seen some administrators scared to create an access control list, thinking it might impact traffic. I’ve seen others create the access list and think the job was done, even though it was never applied to any part of the router configuration. We’ll illustrate this situation in an example at the end of this blog post.
- Unused access lists should be cleaned up. There’s nothing more confusing when reviewing a router configuration than looking through an ACL, only to discover that it’s not used in the configuration. ACLs that are unused and won’t be used in the future should be deleted from the device configuration.
- Cisco uses wildcard masks in ACLs. Those familiar with IP addresses and subnet masks need to know that Cisco ACLs use wildcard masks, which are the bitwise inversion of a traditional subnet mask. For example, if “192.168.100.0 255.255.255.0” means “anything in the 192.168.100.x network” using a normal subnet mask, this would be expressed as “192.168.100.0 0.0.0.255” in an ACL using a wildcard mask instead.
- ALCs are processed in order, so order appropriately. Depending on your network hardware, this point is perhaps not a huge concern. Even so, knowing that access lists are processed in order from the top down is an important design consideration. Well-designed access lists will have the most frequently matched ACEs at the top, and lesser used ACEs towards the bottom.
- Some ACLs must consider directionality. Depending on the application, access control lists are applied in a specific direction. For example, an access list filtering traffic flowing through an interface will be applied either into or out of that interface. It’s easy to write the ACEs backwards if you aren’t paying attention to directionality.
- The last entry in any ACL denies all traffic, and might be invisible. All ACLs have an ACE at the very bottom that denies all traffic. You don’t have to write the ACE that does this; the access control list implicitly does it for you. This is critical to understand when implementing an access list. If the ACL you wrote does not explicitly permit traffic in the higher ACEs, then the implicit “deny everything” ACE at the bottom of the ACL will surely drop the traffic. This can be easy to forget, as the “deny any” is implied, and therefore won’t show up in the configuration.
- Logging can be useful. Cisco offers the ability to log an entry when a packet matches a specific ACE. This can be helpful when troubleshooting. This can also be helpful if you would like to know when traffic fell all the way through to the bottom of the ACL, and was consequently denied. To help log entries stand out or be more readily identified, Cisco allows ACEs to be tagged or have a hash value attached.
- ACLs can only get so big. ACLs reside in a very fast and expensive part of memory known as TCAM. The amount of TCAM available on any network device is limited. Therefore, if you’ll be writing several ACLs of several thousand lines each, it’s important to know whether or not the network device can handle it. Network device manufacturers include in their data sheets the number of access control entries the device supports. For example, the Cisco Catalyst C6880-X-LE supports 64K ACEs, while the C6880-X supports 256K.
- Router order of operations. An interesting side note about lists is that a Cisco router has a list of things it does when a packet arrives at an interface known as the order of operations. Access control list processing is just one of many things the router does.