ASA: Access Lists (continued article series on ASA)
Pretty simple chapter. Access Control Lists (ACLs) are rules for checking the ip header of a packet up to level 4 of the OSI model. Access lists are simply constructions consisting of lines. In each line - the rule to allow (permit) or deny (deny). Lines are scanned from top to bottom for the exact match of the packet header with the access list string. Access lists on the ASA can perform several roles:
1. Filtering on the interface of incoming or outgoing traffic
2. Description of the NAT rules (Policy NAT)
3. Description of the rules for redistributing routes (in the route-map)
4. Criteria for getting into the traffic class for further processing ( Modular Policy Framework, MPF)
5. Description of the "interesting traffic" for encryption. Access list applied in crypto map
6. Description of the rights of the remote user when connecting via IPSec or SSL VPN
Important: at the end of any access list is the invisible “deny all” (implicit deny any), so no packets will pass by the access list.
Access lists are divided into standard and advanced.
Standard access lists only check source addresses. On ASA, such access lists are very narrowly used (for example, to describe traffic for a remote VPN user that needs to be tunneled. Split Tunneling technology)
Command format
The remark keyword is used to insert comments into access lists.
the line # parameter is used to insert a line at a specific place in the access list. For example, if an access list already exists and you need to insert a new line between 4 and 5, then just write
all lines of a line starting at 5 will shift 1 down.
You can delete a specific line from the access list by explicitly writing
write only line number like this
impossible - the ASA will say "incomplete command".
You can delete an access list completely line by line :) But it’s not very convenient for large lists, so there is a command
Ignorance of this command greatly spoils the blood of ASA tuners and is a powerful argument for their caustic remarks :)
Important: the clear configure command is quite powerful and can lead to unpleasant consequences, since it kills all lines starting from the keywords specified after the clear configure words from the current configuration . For example, you can kill the entire current configuration with the command
The netmask in the access lists on the ASA is direct (not a wildcard like on routers). For the convenience of indicating addresses, there are a number of abbreviations that are convenient to use. So, if you need to describe “all networks”, then instead of cumbersome recording
You can use the keyword
instead of describing a host with a mask of 32 bits
You can use the host keyword before the address itself
The order of the rows in the access lists is very important, because viewing goes from top to bottom and stops at the first match. Therefore, the most accurate instructions should be put higher.
Example: if we want to allow traffic to a specific host 10.1.1.100, prohibit the subnet 10.1.1.0/24 and allow everything except this network, then we need to write like this
In this case, specifying the host is more accurate than specifying the network. A network is a more accurate indication than "all addresses."
The format of extended access lists is somewhat more complicated, because it also takes into account the protocol, destination addresses, and can also take into account the TCP / UDP ports of the source and destination (in the command format - one
line):
protocol - the protocol of the TCP / IP stack (ICMP, TCP, UDP, OSPF, IGMP, ESP, etc.) If you need to specify all IP packets, then you need to write the word "ip"
operator as the protocol — the letter of mathematical operators ( eq - equal, gt - more, lt - less, range - range)
port - number or name of TCP or UDP port.
Example:
As a convenient way to debug, you can use the log keyword at the end of the access list line. Then every time a match passes on this line, a syslog message will be generated. You can adjust the frequency of generating such a message.
Important: do not get involved in logging! This is a very time-consuming process for the ASA (and not only for it). Use it only for debugging. In a bad form, I personally think everywhere shoved explicit at the end (although in textbooks they like this line very much)
Also, it is convenient to use the inactive keyword (starting with version 8.0) to temporarily disable the access list line without deleting it at all.
To bring this line back to life, you need to type it again without the word inactive.
Another useful addition is to indicate the time range of the access list line. The time-range construct is used for this.
For instance:
All that remains is to apply the time-range to the access list line.
For instance:
You can view the received access lists by the command
In this case, you will see the config lines that begin with the words access-list {NAME} .
If you need to look at the access list with the line numbers affixed and with line matches, then it is better to use the command
Important: unlike routers that check each packet on the access list, the ASA checks the packet on the access list only if there is no session entry in the session cache (for sessions, see the chapter “Processing packets and creating a session”). Therefore, the number of hits (hit) for session protocols (TCP and UDP) rather means the number of open sessions on this line.
Tip:I recommend everyone to use not too long, but "speaking" names of access lists and write them in capital letters. You can even work out your own names for different cases and always stick to them, for example, the access list on the backup interface input would look like FROMBACKUP for me, and for forwarding past NAT on the dmz interface it would be NONATDMZ. It often happens that several administrators create a configuration or a part is done using the Web-interface, which creates its own list names (what uncomfortable they are!) And then the settings have poor readability. You can rename an access list with an ugly name using the rename command
______________
UPD 01/21/2010 00:18
Sorry, a piece fell out
On the interface, access lists can be used both for input and output of the interface. The entry access list is similar to a nightclub guard who might not let you in because of an unpresentable appearance. And the access list for the interface output is similar to the turnstiles at the exit from the boutique, which begins to hysterically scoop if it feels glamorous thongs hidden in the bosom :)
Example:
______________
Object groups
If your network has many similar objects (for example, user networks, servers with the same set of services, etc.), then when setting up access lists, you will surely encounter them becoming difficult to read and poorly extensible. To simplify the writing of large access lists on the ASA, the so-called object groups are used. Using them, you can group similar network elements (protocols, networks, services, icmp messages).
Example:
The object groups themselves are used instead of explicitly specifying the same type of element in the access list. For example, instead of source or destination addresses, you can use an object group of network type (object-group network), and instead of explicitly specifying a TCP service (ssh, http), you can use a group of type TCP service.
Example:
At the same time, the ASA will still expand your groups in the access lists line by line, but at the same time all the lines of the list with the object group will have the same line number.
Note that each row will have a hit count (hit), not just the total number of hits.
You can view object groups using the command
Network Address Translation (coming soon :))
1. Filtering on the interface of incoming or outgoing traffic
2. Description of the NAT rules (Policy NAT)
3. Description of the rules for redistributing routes (in the route-map)
4. Criteria for getting into the traffic class for further processing ( Modular Policy Framework, MPF)
5. Description of the "interesting traffic" for encryption. Access list applied in crypto map
6. Description of the rights of the remote user when connecting via IPSec or SSL VPN
Important: at the end of any access list is the invisible “deny all” (implicit deny any), so no packets will pass by the access list.
Access lists are divided into standard and advanced.
Standard access lists only check source addresses. On ASA, such access lists are very narrowly used (for example, to describe traffic for a remote VPN user that needs to be tunneled. Split Tunneling technology)
Command format
access-list {NAME} [line #] standard {permit | deny | remark} {NETWORK} {MASK}
The remark keyword is used to insert comments into access lists.
the line # parameter is used to insert a line at a specific place in the access list. For example, if an access list already exists and you need to insert a new line between 4 and 5, then just write
access-list {NAME} line 5 {new line}
all lines of a line starting at 5 will shift 1 down.
You can delete a specific line from the access list by explicitly writing
no access-list {NAME} {specific line of the entire access list}
write only line number like this
no access-list {NAME} line #
impossible - the ASA will say "incomplete command".
You can delete an access list completely line by line :) But it’s not very convenient for large lists, so there is a command
clear configure access-list {NAME}
Ignorance of this command greatly spoils the blood of ASA tuners and is a powerful argument for their caustic remarks :)
Important: the clear configure command is quite powerful and can lead to unpleasant consequences, since it kills all lines starting from the keywords specified after the clear configure words from the current configuration . For example, you can kill the entire current configuration with the command
clear configure all
The netmask in the access lists on the ASA is direct (not a wildcard like on routers). For the convenience of indicating addresses, there are a number of abbreviations that are convenient to use. So, if you need to describe “all networks”, then instead of cumbersome recording
0.0.0.0 0.0.0.0
You can use the keyword
any
instead of describing a host with a mask of 32 bits
1.2.3.4 255.255.255.255
You can use the host keyword before the address itself
host 1.2.3.4
The order of the rows in the access lists is very important, because viewing goes from top to bottom and stops at the first match. Therefore, the most accurate instructions should be put higher.
Example: if we want to allow traffic to a specific host 10.1.1.100, prohibit the subnet 10.1.1.0/24 and allow everything except this network, then we need to write like this
access-list SPLIT remark - = ACL for VPN users = - access-list SPLIT permit host 10.1.1.100 access-list SPLIT deny 10.1.1.0 255.255.255.0 access-list SPLIT permit any
In this case, specifying the host is more accurate than specifying the network. A network is a more accurate indication than "all addresses."
The format of extended access lists is somewhat more complicated, because it also takes into account the protocol, destination addresses, and can also take into account the TCP / UDP ports of the source and destination (in the command format - one
line):
access-list {NAME} [line #] {permit | deny] {protocol} {source net} {source mask} [{operator} {port #}] {destination net} {destination mask} [{operator} {port # }]
protocol - the protocol of the TCP / IP stack (ICMP, TCP, UDP, OSPF, IGMP, ESP, etc.) If you need to specify all IP packets, then you need to write the word "ip"
operator as the protocol — the letter of mathematical operators ( eq - equal, gt - more, lt - less, range - range)
port - number or name of TCP or UDP port.
Example:
access-list ANTISPOOF deny ip host 0.0.0.0 any access-list ANTISPOOF deny ip host 255.255.255.255 any access-list ANTISPOOF permit tcp any host 1.2.3.4 eq 80 access-list ANTISPOOF permit tcp any host 1.2.3.4 eq https access-list ANTISPOOF permit udp any any range 16384 32768 access-list ANTISPOOF permit icmp any any unreachable
As a convenient way to debug, you can use the log keyword at the end of the access list line. Then every time a match passes on this line, a syslog message will be generated. You can adjust the frequency of generating such a message.
Important: do not get involved in logging! This is a very time-consuming process for the ASA (and not only for it). Use it only for debugging. In a bad form, I personally think everywhere shoved explicit at the end (although in textbooks they like this line very much)
deny ip any any log
Also, it is convenient to use the inactive keyword (starting with version 8.0) to temporarily disable the access list line without deleting it at all.
access-list ANTISPOOF permit icmp any any unreachable inactive
To bring this line back to life, you need to type it again without the word inactive.
Another useful addition is to indicate the time range of the access list line. The time-range construct is used for this.
time-range {NAME} {absolute | periodic} {uptime}
For instance:
time-range WORKTIME periodic weekdays 10:00 to 19:00
All that remains is to apply the time-range to the access list line.
access-list {NAME} {string} time-range {NAME}
For instance:
access-list ANTISPOOF permit ip any host 198.133.219.25 time-range WORKTIME
You can view the received access lists by the command
show run access-list {NAME}
In this case, you will see the config lines that begin with the words access-list {NAME} .
If you need to look at the access list with the line numbers affixed and with line matches, then it is better to use the command
show access-list {NAME}
Important: unlike routers that check each packet on the access list, the ASA checks the packet on the access list only if there is no session entry in the session cache (for sessions, see the chapter “Processing packets and creating a session”). Therefore, the number of hits (hit) for session protocols (TCP and UDP) rather means the number of open sessions on this line.
Tip:I recommend everyone to use not too long, but "speaking" names of access lists and write them in capital letters. You can even work out your own names for different cases and always stick to them, for example, the access list on the backup interface input would look like FROMBACKUP for me, and for forwarding past NAT on the dmz interface it would be NONATDMZ. It often happens that several administrators create a configuration or a part is done using the Web-interface, which creates its own list names (what uncomfortable they are!) And then the settings have poor readability. You can rename an access list with an ugly name using the rename command
access-list {UGLYNAME} rename {PRETTYNAME}
______________
UPD 01/21/2010 00:18
Sorry, a piece fell out
On the interface, access lists can be used both for input and output of the interface. The entry access list is similar to a nightclub guard who might not let you in because of an unpresentable appearance. And the access list for the interface output is similar to the turnstiles at the exit from the boutique, which begins to hysterically scoop if it feels glamorous thongs hidden in the bosom :)
access-group {NAME} {in | out} interface {INTERFACE NAME}
Example:
access-group FROMOUTSIDE in interface outside
______________
Object groups
If your network has many similar objects (for example, user networks, servers with the same set of services, etc.), then when setting up access lists, you will surely encounter them becoming difficult to read and poorly extensible. To simplify the writing of large access lists on the ASA, the so-called object groups are used. Using them, you can group similar network elements (protocols, networks, services, icmp messages).
object-group network {NAME} network-object host {ip} network-object {NET} {MASK} ! object-group service {NAME} {tcp | udp} port-object {operator} {port} ! object-group protocol {NAME} protocol-object {PROTOCOL} ! object-group icmp {NAME} icmp-object {icmp type}
Example:
object-group network SERVERS network-object host 192.168.100.100 network-object host 192.168.100.101 network-object host 192.168.100.102 ! object-group service WEBTCP tcp Port-object eq 80 Port-object eq 443 Port-object eq 1494
The object groups themselves are used instead of explicitly specifying the same type of element in the access list. For example, instead of source or destination addresses, you can use an object group of network type (object-group network), and instead of explicitly specifying a TCP service (ssh, http), you can use a group of type TCP service.
Example:
access-list FROMOUTSIDE permit tcp any object-group SERVERS object-group WEBTCP
At the same time, the ASA will still expand your groups in the access lists line by line, but at the same time all the lines of the list with the object group will have the same line number.
asa # show access-list FROMOUTSIDE access-list FROMOUTSIDE line 1 permit tcp any object-group SERVERS object-group WEBTCP access-list FROMOUTSIDE line 1 permit tcp any host 192.168.100.100 eq 80 (hit 5) access-list FROMOUTSIDE line 1 permit tcp any host 192.168.100.100 eq 443 access-list FROMOUTSIDE line 1 permit tcp any host 192.168.100.100 eq 1494 access-list FROMOUTSIDE line 1 permit tcp any host 192.168.100.101 eq 80 (hit 2)
Note that each row will have a hit count (hit), not just the total number of hits.
You can view object groups using the command
show run object-group [{type}]
Network Address Translation (coming soon :))