Cisco Access List priority

Home » ASA » Cisco ASA – Global Access Lists

KB ID 0001019

Problem

I’ve been working for a client that has a large firewall deployment, and they have twelve switches in their six DMZ’s. I wanted to take a backup of these switches [and all the other network devices].

While I was bemoaning the amount of ACL’s that I would need to allow TFTP in from, [note: that’s UDP port 69 if you are interested]. My colleague said “Why not use a global ACL?”, On the rare occasions I’m in the ASDM I’ve seen the ‘global’ rule but never really paid it much attention. [Note: You need an OS of 8.3 or newer!]

Don’t panic! I’m not going to use the ASDM, [if you want to use it you can pretty much work out how to do it from the picture above].

What is a Global ACL?

This is an access list that will allow traffic inbound on all interfaces. There are a couple of caveats;

• Interface specific ACL’s will take precedence over the global ACL [with the exception of the implicit deny at the end of the ACL].
• With the above in mind, if there is a deny on an interface ACL, traffic will be blocked for that interface.
• If you have manually added a deny ip any any to the end of an interface ACL [e.g. for logging purposes] then traffic allowed in the global ACL will fail for that interface.

So the firewall processes each interfaces ACL and just before the implicit deny, if then checks the global ACL, if the global ACL allows the traffic it is passed.

Solution

OK, I want to allow all my DMZ devices to be able to communicate with a the TFTP server on my management server in the LAN.

1. Log into the firewall and create and ACL as you would normally.

PetesASA> enable Password: ********* PetesASA# configure terminal PetesASA[config]# access-list ACL-Global extended permit udp any any eq 69

2. Then instead of applying the ACL directionally to an interface, apply it globally.

PetesASA[config]# access-group ACL-Global global

Thats it! Let’s test it by trying to backup a DMZ switch.

DMZ1-SW-1#copy running-config tftp Address or name of remote host []? 192.168.10.10 Destination filename [DMZ-SW-1-confg]? DMZ-SW-1-Backup !! 1130 bytes copied in 12.244 secs [92 bytes/sec]

Related Articles, References, Credits, or External Links

NA

A relatively deep knowledge of IP ACL configuration and use is assumed to be pre-requisite knowledge for readers of this book. In fact, many of the examples in the earlier sections of the book did not take the space required to explain the detailed logic of ACLs used in the examples. However, some reference information, as well as statements regarding some of the rules and practices regarding IP ACLs, is useful for general CCIE Routing and Switching exam study. Those details are presented in this section.

First, Table 21-7 lists the majority of the Cisco IOS commands related to IP ACLs.

Table 21-7 IP ACL Command Reference

Command	Configuration Mode and Description
access-list access-list-number {deny | permit} source [source-wildcard] [log]	Global command for standard numbered access lists.
access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source source-wildcard destination destinationwildcard [precedence precedence] [tos tos] [log | log-input] [time-range time-range-name] [fragments]	Generic syntax used with a wide variety of protocols. The options beginning with precedence are also included for TCP, UDP, and ICMP.
access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} tcp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [established]	Version of access-list command with TCP-specific parameters; identical options exist for UDP, except for the established keyword.
access-list access-list-number {deny | permit} icmp source source-wildcard destination destinationwildcard [icmp-type [icmp-code] | icmp-message]	Version of access-list command to match ICMP packets.
access-list access-list-number remark text	Defines a remark.
ip access-list {standard | extended} access-list-name	Global command to create a named ACL.
[sequence-number] permit | deny protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range time-range-name] [fragments]	Named ACL subcommand used to define an individual entry in the list; similar options for TCP, UDP, ICMP, and others.
ip access-group {number | name [in | out]}	Interface subcommand to enable access lists.

Table 21-7 IP ACL Command Reference [Continued]

Command	Configuration Mode and Description
access-class number | name [in | out]	Line subcommand for standard or extended access lists.
access-list compiled	Global command to compile ACLs on Cisco 7200s/7500s.
ip access-list resequence access-list-name starting-sequence-number increment	Global command to redefine sequence numbers for a crowded ACL.
show ip interface [type number]	Includes a reference to the access lists enabled on the interface.
show access-lists [access-list-number | access-listname]	Shows details of configured access lists for all protocols.
show ip access-list [access-list-number | access-listname]	Shows IP access lists.

ACL Rule Summary

Cisco IOS processes the Access Control Entries [ACEs] of an ACL sequentially, either permitting or denying a packet based on the first ACE matched by that packet in the ACL. For an individual ACE, all the configured values must match before the ACE is considered a match. Table 21-8 lists several examples of named IP ACL permit and deny commands that create an individual ACE, along with their meanings.

Table 21-8 Examples of ACL ACE Logic and Syntax

KEY POINT

Table 21-8 Examples of ACL ACE Logic and Syntax

KEY POINT

Access List Statement	What It Matches
deny ip any host 10.1.1.1	IP packets with any source IP and destination IP = 10.1.1.1 only.
deny tcp any gt 1023 host 10.1.1.1 eq 23	IP packets with a TCP header, with any source IP, a source TCP port greater than [gt] 1023, plus a destination IP of 10.1.1.1, and a destination TCP port of 23.
deny tcp any host 10.1.1.1 eq 23	Same as previous example except that any source port matches, as that parameter was omitted.
deny tcp any host 10.1.1.1 eq telnet	Same results as the previous example; the syntax uses the telnet keyword instead of port 23.
deny udp 1.0.0.0 0.255.255.255 lt 1023 any	A packet with a source address in network 1.0.0.0/8, using UDP with a source port less than 1023, with any destination IP address.

The Port Number field is only matchable when the protocol type in an extended IP ACL ACE is UDP or TCP. In these cases, the port number is positional in that the source port matching parameter occurs right after the source IP address, and the destination port parameter occurs right after the destination IP address. Several examples were included in Table 21-8. Table 21-9 summarizes the matching logic used to match UDP and TCP ports.

Table 21-9 IP ACE Port Matching

POINT

Table 21-9 IP ACE Port Matching

Keyword	Meaning
gt	Greater than
lt	Less than
eq	Equals
ne	Not equal
range x-y	Range of port numbers, inclusive

ICMP does not use port numbers, but it does include different message types, and some of those even include a further message code. The IP ACL commands allow these to be matched using a rather long list of keywords, or with the numeric message type and message code. Note that these parameters are also positional, following the destination IP address. For example, the named ACL command permit icmp any any echo-reply is correct, but the command permit icmp any echo-reply any is syntactically incorrect and would be rejected.

Several other parameters can also be checked. For example, the IP precedence bits can be checked, as well as the entire ToS byte. The established parameter matches if the TCP header has the ACK flag set—indicative of any TCP segment except the first segment of a new connection setup. [The established keyword will be used in an example later in the chapter.] Also, the log and log-input keywords can be used to tell Cisco IOS to generate periodic log messages when the ACE is matched—one message on initial match, and one every 5 minutes afterwards. The log-input option includes more information than the log option, specifically information about the incoming interface of the packet that matched the ACE.

For ACL configuration, several facts need to be kept in mind. First, standard ACLs can only match the source IP address field. Numbered standard ACLs are identified with ACL numbers of either 1-99 or 1300-1999, inclusive. Extended numbered IP ACLs range from 100-199 and 2000-2699, again inclusive. Additionally, newly configured ACEs in numbered IP ACLs are always added at the end of the existing ACL, and ACEs in numbered IP ACLs cannot be deleted one at a time. As a result, to insert a line into the middle of a numbered ACL, the entire numbered ACL may need to be deleted [using the no access-list number global command] and then reconfigured. Named ACLs overcome that problem by using an implied or explicit sequence number, with Cisco IOS listing and processing the ACEs in an ACL in sequence number order.

Wildcard Masks

ACEs use wildcard masks [WC masks] to define the portion of the IP address that should be examined. WC masks represent a 32-bit number, with the mask's 0 bits telling Cisco IOS that those corresponding bits in the IP address must be compared when performing the matching logic. The binary 1s in the WC mask tell Cisco IOS that those bits do not need to be compared; as a result, these bits are often called "don't care" bits. Table 21-10 lists several example WC masks, and the implied meanings.

Table 21-10 Sample Access List Wildcard Masks

Wildcard Mask	Description
0.0.0.0	The entire IP address must match.
0.0.0.255	Just the first 24 bits must match.
0.0.255.255	Just the first 16 bits must match.
0.255.255.255	Just the first 8 bits must match.
255.255.255.255	Automatically considered to match because all 32 bits are "don't care" bits.
0.0.15.255	Just the first 20 bits must match.
0.0.3.255	Just the first 22 bits must match.
17.44.97.33	A valid WC mask, it means match all bits except bits 4, 8, 11, 13, 14, 18, 19, 24, 27, and 32.

That last entry is unlikely to be useful in an actual production network, but unlike IP subnet masks, the WC mask does not have to list a single unbroken set of 0s and another unbroken string of 1s. A much more likely WC mask is one that matches a particular mask or prefix length. To find a WC mask to match hosts in a known prefix, use the following simple math: in decimal, subtract the subnet mask from 255.255.255.255. The result is the "right" WC mask to match that prefix length. For instance, a subnet mask of 255.255.255.0, subtracted from 255.255.255.255, gives you 0.0.0.255 as a WC mask. This mask only checks the first 24 bits—which in this case is the network and subnet part of the address. Similarly, if the subnet mask is 255.255.240.0, subtracting from 255.255.255.255 gives you 0.0.15.255.

Continue reading here: General Layer 3 Security Considerations

Was this article helpful?