In this article, we are going to show you some more advanced ways to use access lists. Most of the advanced access-list topics are beyond the objectives of this CCNA course, so we’ll just discuss them briefly and you can find more information on the Cisco website if you are interested.
However, with that said, there are some important access-list options that you need to know, and the first one is named access lists.
Named ACLs
As we said earlier, the named access-list is just another way to create standard and extended access lists. In the medium to large enterprises, management of access lists can become, well, a real hassle over time. For example, when you need to make a change to an access list, a frequent practice is to copy the access list to a text editor, change the number, edit the list, then paste the new list back into the router. With this done, you can simply change the access-list number on the interface from the old one to the new one and there will never be a time on the network where an access list isn’t in place.
This would work pretty well if it weren’t for what we call “packrat” mentality. The question becomes, what do we do with the old access-list? Delete it? Or should we save it in case we find a problem with the new list and need to back out of the change? What happens is that over time through this and countless other scenarios you can end up with a whole bunch of unapplied access lists building up on a router. What were they for? Are they important? Do we need them? All good questions and named access lists could be your answer.
This can also apply to access lists that are up and running. Let’s say you come into an existing network and are looking at access lists on a router. Suppose you find an access-list 177 (which is an extended access list) that is 33 lines long. This could cause you much needless existence questioning what is it for? Why is it here? Instead, wouldn’t an access list called, say, finance LAN be more descriptive than one that’s named 177?
Named access lists to allow you to use names to both create and apply either standard or extended access lists. There is nothing new or different about these access lists aside from being able to refer to them in a way that makes sense to humans. But there are some subtle changes to the syntax, so let’s recreate the standard access list we created earlier for our test network in the picture below using a named access list.
Lab_A#config t
Enter configuration commands, one per line. End with CNTL/Z
Lab_A(config)#ip access-list ?
Extended extended Acc
Logging control access list logging standard starndard access list
Notice that we started by typing ip access-list, not access-list. This allows me to enter a named access list. Next, we’ll need to specify that it’s to be a standard access list.
Lab_A(config)#ip access-list standard ?
<1-99> standard IP access-list number
WORD Access-list name
Lab_A(config)#ip access-list standard blocksales
Lab_A(config-std-nacl)#We’ve specified a standard access list, then added a name BLocksale. Notice that we could’ve used a number for a standard access list, but instead, we choose to use a descriptive name. also, notice that after entering the name, we hit enter and the router prompt changed. We are now in named access-list configuration mode and entering the named access list.
Lab_A(config-std-nacl)#?
Standard Access list configuration commands”
Default set a command to its defaults
Deny specify packets to reject
Exit exit from access list configuration mode
No negate a command or set its defaults
Permit specify packets to forward
Lab_A(config-std-nacl)#deny 172.16.40.0 0.0.0.255
Lab_A(config-std-nacl)#permit any
Lab_A(config-std-nacl)#exit
Lab_A(config)#^Z
Lab_A#We enter the access list, and then exit out of configuration mode. Next, we’ll take a look at the running configuration to verify that the access list is indeed in the router.
Lab_A#show running-config
!
Ip access-list standard blocksales
Deny 172.16.40.0 0.0.0.255 permit any
!The Blocksales access list has truly been created and is in the running-config of the router. Next, we’ll need to apply the access list to an interface
Lab_A#config t
Enter configuration commands, one per line. End with CNTL/Z
Lab_A(config)#int e1
Lab_A(config-if)#ip access-group BlockSales out
Lab_A(config-if)#^Z
Lab_A#All right! At this point, we’ve recreated the work done earlier using a named access list.
Switch port ACLs
Okay, now remember this: you can only apply port ACLs to Layer 2 interfaces on your switches. Why? Because there are only supported on Physical layer 2 interfaces. Another good thing to keep in mind is that you can apply them as only inbound lists on your interfaces, and you can use only named lists as well.
Here’s a shortlist of supported access lists:
- As we mentioned, standard IP access lists use only source addresses to filter traffic.
- On the other hand, extended IP access lists use both source and destination addresses as well as optional protocol information and port numbers.
- There are also MAC extended access lists that use source and destination MAC addresses and optional protocol type information.
Switches scrutinized all inbound ACLs applied to a certain interface and decide to allow traffic through depending on whether the traffic is a good match to the ACL or not. So we are sure you can see how important ACLs are to security they’re gatekeepers with the power to permit or deny access to a special segment of your network, or all of it period!
ACLs can also be used to control traffic on VLANs. To make this happen, you just need to apply a port ACL to a trunk port. But do aware if you do this on a port that has a voice VLAN, that ACL will actually filter your data VLANs too. So tread carefully here!
Port ACLs control IP traffic via IP access lists. Any non-IP traffic is filtered through the use of MAC addresses. And even though you can apply both types of filters to a single interface, you only get to apply one of each. If you try to put an additional ACL of either type of an interface that’s already got them in place, the new one will override the one you had there before.
So it’s a good idea to be careful here look before you leap.
Let’s check out the access list.
S1#config t
S1(config)#mac access-list ?
Extended extended access list
S1(config)#mac access-list extended ?
WORD access-list name
S1(config)#mac access-list extended Todd_MAC_list
S1(config-ext-mac1)#deny ?
H.H.H 48-bit source MAC address
Any any source MAC address
Host a single source host S1(config-ext-mac1)#deny any ?
H.H.H 48-bit destination MAC address
Any any destination host
Host a single destination host
S1(config-ext-mac1)#deny any host ?
H.H.H 48-bit destination MAC address
S1(config-ext-mac1)#deny any host 000d.29.bd.4b85
S1(config-ext-mac1)#permit ?
H.H.H 48-bit source MAC address
Any any source MAC address
Host a single source host S1(config-ext-mac1)#permit any any
S1(config-ext-mac1)#do show access-list
Extended MAC access list Todd_MAC_list
Deny any host 000d.29bd.4b85 permit any any
S1(config-ext-mac!)#All right you can see that you can only create an extended named access list. You have no other options. And don’t forget to add the permit any any at the end!
Here is how you would apply the list to a switch port:
S1(config-ext-mac1)#int f0/6
S1(config-if)#mac access-group Todd_MAC_list inThis is pretty much the same as it is with an IP list, except that you start with the command mac.
But do you really want to deny MAC addresses? Doesn’t this sound like a bad hangover before you even start? While it’s true there are special circumstances where you would, there is another option, and we think it’s usually the better one: just deny access based on either type field in the Ethernet frame header instead. Take a look:
S1(config-ext-mac1)#deny any any ?
<0-65535> an arbitrary Ethertype in decimal, hex or octal
Aarp Ethertype: AppleTalk ARP
Amber Ethertype: DEC-Amber
Appletalk Ethertype: AppleTalk/EtherTalk
Cos cos value
Dec-spanning Ethertype: DEC-spanning-tree
Decent-iv Ethertype: DECnet phase IV
Diagnostic Ethertype: DEC-diagnostic
Dsm Ethertype: DEC-DSM
Etype-6000 Ethertype:0x6000
Etype-8042 Ethertype: 0x8042
Lat Ethertype: DEC-LAT
Lavc-sca Ethertype: DEC-LAVC-SCA
Lsap LSAP value
Mop-console Ethertype: DEC-MOP remote console
Mop-dump Ethertype: DEC-MOP dump
Msdos Ethertype: DEC-MSDOS
Mumps Ethertype: DEC-MUMPS
Netbios Ethertype: DEC-NETBIOS
Vines-echo Ethertype: VINES Echo
Vines-ip Ethertype: VINES IP
Xns-idp Ethertype: XNS IDP
<cr>It’s cool we know. But don’t go nuts here and start denying all ethertype numbers available or you’ll end up with some issues that will make you regret it. But who actually uses Dec Net and Apple Talk? They definitely deserve to be denied access to your beautiful, well-oiled network, don’t they?
If read our first article on the CCNA course, i.e. Internetworking, you would know that if you blocked 0x800, you’d block all of IP, right? This could come in handy in the future if you decided to force everyone to run IPv6. But for now, just don’t go there!
Lock and Key (Dynamic ACLs)
This flavor of ACL depends on either remote or local Telnet authentication in combination with extended ACLs.
Before you can configure a dynamic ACL, you need to apply an extended ACL on your router to stop the flow of traffic through it. The only way anyone can get through the blockade is if they telnet to the router and gain authentication. It works like this: the telnet connection the user-initiated gets dropped and is replaced with a single entry dynamic ACL that’s appended to the extended ACL already in place. This causes traffic to be allowed through for a specific amount of time, and as you may have guessed, time-outs can and do happen.
Reflexive ACLs
These ACLs filter IP packets depending upon upper-layer session information, and they often permit outbound traffic to pass but place limitations on inbound traffic. You can’t define reflexive ACLs with numbered or standard IP ACLs, or any other protocol ACLs for that matter. They can be used along with other standard or static extended ACLs, but they’re only defined with extended named IP ACLs that’s it.
Time-based ACLs
Time-based ACLs work a lot as extended ACLs do, but their type of access control is totally time-oriented. Basically, you specify a certain time of day and week and then identify that particular period by giving it a name referenced by a task. So, by necessity, the reference function will fall under whatever time constraints you’ve dictated. The time period is based upon the router’s clock, but we highly recommend using it in conjunction with Network Time Protocol (NTP) synchronization.
Here’s an example
Corp#config t
Corp(config)#time-range no-http
Corp(config-time-range)#periodic we ?
Wednesday weekdays weekend
Corp(config-time-range)#periodic weekend ?
Hh:mm starting time
Corp(config-time-range)#periodic weekend 06:00 to 12:00
Corp(config-time-range)#exit
Corp(config)#time-range tcp-yes
Corp(config-time-range)#periodic weekend 06:00 to 12:00
Corp(config-time-range)#exit
Corp(config)#ip access-list extended Time
Corp(config-ext-nacl)#deny tcp any any eq www time-range no-http
Corp(config-ext-nacl)#permit tcp any any time-range tcp-yes
Corp(config-ext-nacl)#interface f0/0
Corp(config-if)#ip access-group Time in
Corp(config-if)#do show time-range
Time-range entry: no-http (inactive)
Periodic weekdays 8:00 to 15:00
Used in: IP ACL entry
Time-range entry: tcp-yes (inactive)
Periodic weekend 8:00 to 13:00
Used in: IP ACL entry
Corp(config-if)#The time-range command is pretty flexible and will drive users crazy if you deny them basic network access or access to the internet during off-hours. Be careful with the preceding commands make sure you test your list on a nonproduction network before you implement the lists on your production network.
Remarks
This is the tool you grab to use the remark keyword, and it’s really important because it arms you with the ability to include comments, or rather remarks, regarding the entries you’ve made in both your IP standard and extended ACLs. Remarks are very cool because they efficiently increase your ability to examine and understand your ACLs to the super-hero level. Without them, you’d be caught in a quagmire of meaningless numbers without anything to help you recall what those numbers mean.
Even though you have the option of placing your remarks either before or after a permit or deny statement, we totally recommend that you chose to position them consistently so you don’t get confused about which remark is relevant to which one of your permits or deny statements.
To get this going for both standards and extended ACLs, just use the access-list access-list number remark global configuration command. And if you want to get rid of a remark, just use the command’s no form.
Let’s take a look at an example of how to use the remark command!
R2#config t
R2(config)#access-list 110 remark permit Bob sales only to finance
R2(config)#access-list 110 permit ip host 172.16.10.1 172.16.20.0 0.0.0.255
R2(config)#access-list 110 deny ip 172.16.10.0 0.0.0.255 172.16.20.0 0.0.0.255
R2(config)#ip access-list extended No_Telnet
R2(config-ext-nacl)#remark deny all of sales from telnetting to marketing
R2(config-ext-nacl)#deny tcp 172.16.30.0 0.0.0.255 172.16.40.0 0.0.0.255 eq 23
R2(config-ext-nacl)#permit ip any any
R2(config-ext-nacl)#do show run
[output cut]
!
Ip access-list extended No_telnet
Remark stop all of sales from telnetting to marketing
Deny tcp 172.16.30.0 0.0.0.255 172.16.40.0 0.0.0.255 eq telnet
Permit ip any any
!
Access-list 110 remark permit bob from sales only to finance
Access-list 110 permit ip host 172.16.10.1 172.16.20.0 0.0.0.255
Access-list 110 deny ip 172.16.10.0 0.0.0.255 172.16.20.0 0.0.0.255
!We were able to add a remark to both an extended list and a named access list. However, you cannot see these remarks in the output of the show access-list command, only in the running-config. We’ll see this command again when we configure ACLs using the SDM.