ACLs

Note: This guide is related to using Cisco equipment. For basic introductory details about using Cisco, see: Cisco Introduction, Cisco equipment, and Cisco basic usage guide.

This may also be referred to by Cisco Certified Network Associate (“CCNA”) Routing and Services certification information.

This guide is currently a bit messier than much of the content... clean-up should be done. Also, this may be rather IPv4-specific.

This guide covers both Cisco IOS and Cisco ASA, since there is really just one extremely significant difference to how they handle ACLs. The difference is described further in upcoming text, but just to get this out of the way: the super significant difference is that Cisco IOS uses wildcard masks, and Cisco ASA uses subnet masks. Since so many other details apply identically, this training covers both.

An “access control entry” (“ACE”) can be used to help to identify traffic, and can specify what to do with the traffic. For example, an ACE may specify that traffic related to the IPv4 address at 192.0.2.100 should be denied. Basically, an ACE refers to one rule. An easier way to think about it may be that an ACE is typically just referring to one line of configuration. That might not be a very technical description, but it does communicate the essential idea well enough to apply to basic introductory training of ACLs in an environment using Cisco IOS or Cisco ASA).

An access control list (“ACL”) is a collection of access control entries “ACE”). An ACL may have one access control entry, or zero, or more.

An ACL can be used for packet filtering, implementing QoS, specifying a class map which can be used for implementing other technologies like how much permission a user has to perform certain tasks. This can affect what user(s) may be authorized to use a certain virtual teletype terminal (“VTY”) line, or affect SNMP (to use a couple of examples from Cisco's official “CCNA Security” certification book). IPsec may also use 'em. So, there are quite a few possible ways that ACLls may be used.

Material related to the basic Cisco Certified Network Associate (“CCNA”) Routing and Switching certification will likely focus on packet filtering, because that is what is likely to show up on the examination for that certification. This guide may use packet filtering ACLs as a primary example of learning how to work with ACLs.

This guide may currently be a bit focused on IPv4.

Three types

First, there are three types of ACLs. This is probably a relic from the days when there were fewer types of ACLs. If equipment is new enough to support all three types, then there's no additional functionality that the first type offers as an advantage. Even so, it seems that examinations (such as Cisco's official examination to get a certification, as well as “practice” exams that some schools may require) seem to like to drill people on these types, so it makes sense to cover them.

Standard ACLs

These contain one IPv4 address. These ACLs are used to identify where traffic originated.

That doesn't mean that standard ACLs can only be used on incoming traffic. They can be used for outgoing traffic, but they focus on the source address of the IP packet.

These ACL's are given a number. The original set of available numbers was 1 through 99. An “expanded” range allows standard ACLs to also use numbers from 1399 to 1999.

Extended ACLs

These ACLs typically have support to contain references to a protocol, two combinations of a network and an optional port. A network refers to a network ID and a subnet size. Using the most flexible syntax, this means that they can contain a reference to a protocol, one network ID (which looks like an IPv4 address), a network size, a service, another network ID, another network size, and another service.

That probably looks like a huge mouthful, so let's start by just seeing what a rather complicated example looks like. Then, this will be broken down piece by piece.

# access-list 100 permit tcp 192.0.2.192 0.0.0.223 198.51.100.128 0.0.0.223 eq pop3 established

Note that there are optional pieces there. For example, specifying "tcp" is not needed if the TCP protocol isn't part of the ACE.

Specifying protocol
e.g.: tcp, udp, ip, icmp
Specifying network

With traditional IOS, which is what Cisco is likely to focus on for the Cisco Certified Network Associate (“CCNA”) Routing and Switching certification, each network sizes are expressed as a “wildcard mask”. (Further clarification can be provided. Basically, a wildcard mask is typically just a subnet mask with the bits flipped. So if a subnet mask is 255.255.255.0, then a wildcard mask of 0.0.0.255 is equivilent. Converting from a subnet mask to a wildcard mask can be done by subtracting 255 from each octet. Wildcard masks do offer some additional flexibility. For example, Exploration 4 5.2.3.2 shows an example of 00000000.00000000.11111110.11111111 which specifies odd-numbered subnets. That has a zero to the right of a one, which would be like the concept of a subnet mask having a subnet bit set to one in a location that is to the right of a host bit that has a value of zero. However, subnet masks don't allow such flexibility. So things can be done with wildcard masks that cannot be done with subnet masks.

It seems like wildcard masks were more unpopular than useful, as Cisco basically dropped support for using them with the Cisco ASA. On a Cisco ASA, the extended ACL has network sizes specified by a traditional subnet mask.

So, a basic format of an Extended ACL with IOS might contain an ACE that look something like this:

permit 192.0.2.0 0.0.0.255 198.51.100.192 0.0.0.223

There are two other ways to specify a network. One is to use the "host" command, which implies a network size of a single address. e.g.: “host 192.0.2.100”. Another option is to use “any”. That implies a network size of the entire address space (which implies a IPv4 network ID of 0.0.0.0).

service

By “service port”, this refers to a TCP port number or a UDP port number. So, this only applies if using a protocl that supports additional information, like TCP's port numbers and UDP port numbers. As an example, IP doesn't need a port number. ICMP may support a message type(true in this case?)?

Some names may also be used, such as “smtp”. That's a nice example since the service port name used by IOS matches the most widely recognized name for the service. Service ports are officially reserved by IANA: see information about IANA's list of service ports (including TCP and UDP ports). In this case, the IOS name of “smtp” refers to TCP port 25, which IANA has reserved for Simple Mail Transport Protocol.

FTP connects use two ports, and they have names. The primary destination FTP port, of 21, is called "ftp". The other FTP-related port, 20, is named ftp-data.

In some cases, IOS may use some alternate names. For example, the name "domain" may be used for DNS (UDP port 53) or "www" for HTTP (TCP port 80). Whether that is true or not might vary a bit. For instance, usage guidelines for extended ACLs and Transit ACL both document a service name of “www”, although Cisco IOS Port to Application Mapping Commands Table 22: System-Defined Port Mapping and Cisco documentation: Configuring Port to Application Mapping, Table 23: System-Defined Port Mapping show “http”. (Some hyperlink(s) just mentioned may be to a point in a document just above the port mappings. Scroll down, as needed, to see the service port names.) Presumably, the differences may be related to different commands or different versions of IOS.

A list of available names can be seen by looking online at some of the official Cisco documentation that has just been mentioned. Also, IOS help may show this. To see a list of service names related to TCP can be seen by typing a question mark when IOS is expecting the user might specify a service port name. e.g.: type the following at the start of an IOS command line: "access-list 100 permit tcp any eq ?". (There is no need to press the Enter key: help will show as soon as the ? key is pressed.) Another option might be to run show ip port-map.

There is really no technical difference between specifying a number or specifying a support name. IOS is known to report names, so being familiar with some names of frequently used protocols may be worthwhile. For instance, the most widely recognized official port reservation for a TCP port is by IANA: see information about IANA's list of TCP and UDP ports. IANA indicates that TCP port 80 is definitiely officially reserved for HTTP, but Cisco IOS often uses the service port name of “www”.

Custom port names can be made. The ip port-map command is used to do this, and is described by Port to Application Mapping Commands.

The most common operator is likely equal. Others may include: neq (not equal), lt (less than), gt (greater than), or range. If range is specified, then two ports need to be provided. The other operators just mentioned only require psecifying one port.

established
This optional word relates to TCP connections. The word is not optional, and cannot be used, for protocols that doesn't support that concept, like UDP. This word is only used for TCP according to IOS extended ACL guide: established and Exploration 4 slide “5.3.2.1”.

There may be more options, but those are some of the basics to focus on learning first. Those options provide a lot of flexibility to control some basic options for packet filtering.

These extended ACL's are given a number. The original set of available numbers was 100 through 199. An “expanded” range allows standard ACLs to also use numbers from 2000 to 2699.

named ACL

Named ACLs basically provide the same capabilities of an extended ACL. The most obvious difference is that they use a case-sensitive alphanumeric name (which starts with a letter), instead of using a number for identification. (If they contained just a number, that would make them look too much like an Extended ACL. So they must start with a letter.) The other difference is that the IOS commands to create/alter a named ACL look a bit different. However, as far as capability, they are functionally just as good (at least, on a basic level).

So, really, using a standard ACL is like using an extended ACL with a destination of "any". Standard ACLs probably work on more devices, as older devices probably supported them first. Maybe there is still some advantage to them, like that they use less resources because the hardware can process them faster. However, as far as simple capability, they offer no advantage.

Creating ACLs
show access-list

An ACL may be described as being either “numeric” or “named”.

  • This is totally separate from whether they are “standard” or “extended”, which is a different way of categorizing ACLs. So they could be any of these combinations:
    • standard numeric
    • standard named
    • extended numeric
    • extended named
creating Numeric ACL's

The general syntax looks roughly like this:

(config)# access-list # command log
  • The # must be customized.
  • The # is also needing customization. It is one of the following:
    • permit target
    • deny target
    • remark comment

    The target refers to either one network or two networks, depending on the syntax used. For standard ACLs, that is one network. For extended ACLs, two.

  • The “ log” is optional.
    • if enabled, first matching packet will be mentioned in a message that is logged, which typically means that it gets sent to the console. Subsequent packets don't get reported for 5 minutes, but they do get counted. After 5 minutes, when another packet matches, the counted sub-total is shown.
Creating named ACLs
(config)# ip access-list extended NameOfACL
(config-ext-nacl)# remark blah

Viewing results:

(config)# show access-lists
(config)# show access-lists 1
(config)# show access-lists CUSTOMNAME
Applying
(config)# interface Fa0/1
(config-if)# ip access-group 1 out

It seems that access-class is meant for VTY lines; perhaps access-group only works on physical interfaces?

Forum post: Access-group vs. Access-class

example:

(config)# line vty 0 4
(config???)# login
(config???)# password sample
(config???)# access-class 1 in
Some Important Notes about ACLs

Specifying a non-existant ACL will have no effect; traffic will just be passed. Named ACLs are case-sensitive.

ACLs have an invisible deny statement at the end. This is often called the “implicit” deny. That denies all traffic. If an ACL exists, that implicit deny statement exists, even if the ACL has no explicit (visible) ACEs.

Outbound ACLs (may?) have no impact for traffic which originates from the router itself. Such traffic may be passed.

Recommended practice: have ACLs get applied early. So, having packets be denied on an incoming interface may use less resources than an ougoing. That's probably the bigger performance booster, because then the router doesn't have to check things like what interface traffic traffic would go out if it will just be denied anyway, so the traffic is fully handled sooner and isn't wasting processor resources that didn't need to be wasted. Here's another idea which might have a smaller impact: If earlier ACEs can affect more traffic, or denied traffic, that is probably preferable. Once a match is found, further processing isn't needed.

Complex ACLs

These are some more complex options. They are not needed to implement a basic packet filter. Other concepts, like the types of access control lists, are more fundamental and are worth learning first. There are more details, like commands to learn, that are related to those basic concepts. On the plus side, at least some of these complex types of ACLs are fairly simple pieces of additional knowledge, so these can be learned quickly.

Just, understand that these complex types are simply additional options. They are not required to be able to use some of the simplest examples of ACLs.

Reflexive

This may be more commonly used with IOS, rather than newer options like Cisco ASA.

A “reflexive access list ” uses the word reflect. e.g., an ACE may say:

permit tcp any any reflect CUSTOMNAME”.

If traffic matches that, then an access list named CUSTOMNAME will be modified. That list doesn't need to pre-exist: it will just be automatically created if needed. This access list will then show up in a “Reflexive IP access list CUSTOMNAME” section of “show access-list

This doesn't do much yet, but that list can be used. For instance, for an external interface, inbound traffic can apply that list.

(config)#ip access-list extended CHECKREFLECT
(config-ext-nacl)#evaluate CUSTOMNAME
(config-ext-nacl)#remark deny ip any any is default from implicit deny
(config-ext-nacl)#remark but the next line will cause log to be made
(config-ext-nacl)#deny ip any any log

This can be used for security. It could also be effectively used simply to see current activity, because the Reflexive access list will show what traffic has been sent. (based on a simple example that was seen, it appears that the reflexive ACLs might have a default lifespan of about 5 minutes = 300 seconds.)

Some official documentation: Cisco ACLs: Reflexive ACLs

time-based

An ACE can be made, e.g.: “permit tcp any any eq 80 time-range CUSTOMTIMERANGE”.

That range should exist. e.g.:

(config)#time-range CUSTOMTIMERANGE
(config-time-range)#periodic Saturday Sunday 10:00 to 11:00

This could be useful for creating certain logs at only certain times. That can:

  • minimize the resources used to create logs,
  • and create smaller logs (which, because they are smaller, may be easier to look through)

... compared to what logs would be created if all network traffic gets logged all weekend long.

Exploration 4 5.4.1.1 mentions “Dynamic ACLs (lock and key)”, Reflexive, and Time-based. These get covered up through the end of section “5.4.4” (slide “5.4.4.2”).