Cisco Access List priority
Home » ASA » Cisco ASA – Global Access Lists Show KB ID 0001019 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;
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. SolutionOK, 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 LinksNA
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.
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
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
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 MasksACEs 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.
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? |