ASA: access lists (continued cycle of articles about ASA)
Pretty simple chapter. Access lists (ACL, Access Control List) are the rules for checking the ip header of a packet up to level 4 of the OSI model. Access lists are simply constructs consisting of lines. In each line - the rule to allow (permit) or deny (deny). The lines are viewed from top to bottom for exact match of the package header with the line of the access list. Access lists on the ASA can perform several roles:
1. Filtering on the interface of incoming or outgoing traffic
2. Description of NAT Rules (Policy NAT)
3. Description of the rules of route redistribution (in the route-map)
4. The criterion for entering the traffic class for further processing (Modular Policy Framework, MPF)
5. Description of "interesting traffic" for encryption. Applies the crypto map access list
6. Description of the rights of the remote user when connecting via IPSec or SSL VPN
Important: at the end of any access list there is an invisible “deny all”, so no packet will pass by the access list.
Access lists are divided into standard and extended.
')
Standard access lists check only source addresses. On the ASA, such access lists have very narrow application (for example, to describe traffic for a remote VPN user, which needs to be wrapped in a tunnel. Split Tunneling technology)
Command format
The keyword remark is used to insert comments into access lists.
The line # parameter is used to insert a line at a specific location in the access list. For example, if an access list already exists and you need to insert a new line between lines 4 and 5, then it’s enough to write
all lines of a line starting from 5 will move down by 1.
You can remove a specific line from the access list by explicitly writing
write only the line number like this
no way - the ASA will say that “incomplete command”.
You can delete the entire access list line by line :) But not very convenient for large lists, so there is a command
Ignorance of this team spoils the blood of the 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, because it kills all lines from the current configuration starting with the keywords specified after the words clear configure. For example, you can kill the entire current configuration with the command
The network mask in the access lists on the ASA uses a direct one (and not a wildcard like on routers). For the convenience of specifying addresses there are a number of abbreviations that are convenient to use. So, if it is necessary to describe "all networks", then instead of cumbersome recording
You can use the keyword
instead of a host description with a mask of 32 bits
You can use the host keyword in front of the address itself.
The order of the rows in access lists is very important, since viewing goes from top to bottom and stops at the first coincidence. Therefore, the most accurate guidance 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 must write
In this case, the indication of the host is more accurate than the indication of 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, the destination addresses and can also take into account the source and destination TCP / UDP ports (in the format of the command - one
line):
protocol - TCP / IP stack protocol (ICMP, TCP, UDP, OSPF, IGMP, ESP, etc.) If you need to specify all IP packets, then you should write the word “ip” as a protocol
operator - a literal entry of mathematical operators (eq - equal, gt - more, lt - less, range - range)
port - the number or name of the TCP or UDP port.
Example:
As a convenient debugging method, you can use the log keyword at the end of the access list line. Then every time a match occurs on this line, a syslog message will be generated. You can adjust the frequency of generating such a message.
Important: do not get carried away with logging! This is a very laborious process for the ASA (and not only for it) process. Use it only for debugging. I personally consider it a bad tone to shove the obvious at the end everywhere (although in textbooks such a line is very much loved)
It is also 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 the indication of the time range of the access list line. To do this, use the construction of time-range
For example:
The next step is to apply time-range to the access list line.
For example:
You can view the received access lists with the command
In this case, you will see the lines of the config, which begin with the words access-list {NAME} .
If, however, you need to look at the access list with line numbers and line matches, 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 the session record is not in the session cache (for sessions, see the chapter “Processing packets and creating a session”). Therefore, the number of matches (hit) for session protocols (TCP and UDP) rather means the number of open sessions on this row.
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 for the backup interface would look like FROMBACKUP, and for forwarding by NAT on the dmz interface, NONATDMZ. It often happens that the configuration is created by several administrators or a part is made using the Web interface, which creates its own list names (how inconvenient they are!) And then there is a poorly readable mess in the settings. You can rename an access list with an ugly name using the rename command
______________
UPD 01.01.2010 00:18
Sorry, a piece fell out
On the interface, access lists can be applied both to the input and to the output of the interface. The entry access list is like a nightclub security guard, who may keep you out of sight because of an unpresentable appearance. And the list of access to the exit of the interface is similar to the turnstiles at the exit from the boutique, which begins to hysterically scrape if the glamorous strings hidden behind their bosoms smile
Example:
______________
Object groups
If there are many similar objects in your network (for example, networks of users, servers with the same set of services, etc.), then when setting up access lists you will definitely encounter the fact that they become hard to read and poorly expandable. 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 an element of the same type in the access list. For example, instead of the source or destination addresses, you can apply an object group of a network type (object-group network), and instead of explicitly specifying a TCP service (ssh, http), you can apply a group of service type TCP.
Example:
At the same time, the ASA will still expand your groups in the access lists line by line, but all the rows in the list with the object group will have the same row number.
Notice that the number of matches (hit) will be on each line, and not just the total number of matches.
You can view object groups with the command
Network Address Translation (coming soon :))
1. Filtering on the interface of incoming or outgoing traffic
2. Description of NAT Rules (Policy NAT)
3. Description of the rules of route redistribution (in the route-map)
4. The criterion for entering the traffic class for further processing (Modular Policy Framework, MPF)
5. Description of "interesting traffic" for encryption. Applies the crypto map access list
6. Description of the rights of the remote user when connecting via IPSec or SSL VPN
Important: at the end of any access list there is an invisible “deny all”, so no packet will pass by the access list.
Access lists are divided into standard and extended.
')
Standard access lists check only source addresses. On the ASA, such access lists have very narrow application (for example, to describe traffic for a remote VPN user, which needs to be wrapped in a tunnel. Split Tunneling technology)
Command format
access-list {NAME} [line #] standard {permit | deny | remark} {NETWORK} {MASK}
The keyword remark is used to insert comments into access lists.
The line # parameter is used to insert a line at a specific location in the access list. For example, if an access list already exists and you need to insert a new line between lines 4 and 5, then it’s enough to write
access-list {NAME} line 5 {new line}
all lines of a line starting from 5 will move down by 1.
You can remove a specific line from the access list by explicitly writing
no access-list {NAME} {specific entire access list line}
write only the line number like this
no access-list {NAME} line #
no way - the ASA will say that “incomplete command”.
You can delete the entire access list line by line :) But not very convenient for large lists, so there is a command
clear configure access-list {NAME}
Ignorance of this team spoils the blood of the 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, because it kills all lines from the current configuration starting with the keywords specified after the words clear configure. For example, you can kill the entire current configuration with the command
clear configure all
The network mask in the access lists on the ASA uses a direct one (and not a wildcard like on routers). For the convenience of specifying addresses there are a number of abbreviations that are convenient to use. So, if it is necessary 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 a host description with a mask of 32 bits
1.2.3.4 255.255.255.255
You can use the host keyword in front of the address itself.
host 1.2.3.4
The order of the rows in access lists is very important, since viewing goes from top to bottom and stops at the first coincidence. Therefore, the most accurate guidance 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 must write
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, the indication of the host is more accurate than the indication of 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, the destination addresses and can also take into account the source and destination TCP / UDP ports (in the format of the command - one
line):
access-list {NAME} [line #] {permit | deny] {protocol} {source net} {source mask} [{operator} {port #}] {destination net} {destination mask} [{operator} {port # }]
protocol - TCP / IP stack protocol (ICMP, TCP, UDP, OSPF, IGMP, ESP, etc.) If you need to specify all IP packets, then you should write the word “ip” as a protocol
operator - a literal entry of mathematical operators (eq - equal, gt - more, lt - less, range - range)
port - the number or name of the 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 debugging method, you can use the log keyword at the end of the access list line. Then every time a match occurs on this line, a syslog message will be generated. You can adjust the frequency of generating such a message.
Important: do not get carried away with logging! This is a very laborious process for the ASA (and not only for it) process. Use it only for debugging. I personally consider it a bad tone to shove the obvious at the end everywhere (although in textbooks such a line is very much loved)
deny ip any any log
It is also 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 the indication of the time range of the access list line. To do this, use the construction of time-range
time-range {NAME}
{absolute | periodic} {running time}
For example:
time-range WORKTIME periodic weekdays 10:00 to 19:00
The next step is to apply time-range to the access list line.
access-list {NAME} {string} time-range {NAME}
For example:
access-list ANTISPOOF permit ip any host 198.133.219.25 time-range WORKTIME
You can view the received access lists with the command
show run access-list {NAME}
In this case, you will see the lines of the config, which begin with the words access-list {NAME} .
If, however, you need to look at the access list with line numbers and line matches, 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 the session record is not in the session cache (for sessions, see the chapter “Processing packets and creating a session”). Therefore, the number of matches (hit) for session protocols (TCP and UDP) rather means the number of open sessions on this row.
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 for the backup interface would look like FROMBACKUP, and for forwarding by NAT on the dmz interface, NONATDMZ. It often happens that the configuration is created by several administrators or a part is made using the Web interface, which creates its own list names (how inconvenient they are!) And then there is a poorly readable mess in the settings. You can rename an access list with an ugly name using the rename command
access-list {UGLYNAME} rename {PRETTYNAME}
______________
UPD 01.01.2010 00:18
Sorry, a piece fell out
On the interface, access lists can be applied both to the input and to the output of the interface. The entry access list is like a nightclub security guard, who may keep you out of sight because of an unpresentable appearance. And the list of access to the exit of the interface is similar to the turnstiles at the exit from the boutique, which begins to hysterically scrape if the glamorous strings hidden behind their bosoms smile
access-group {NAME} {in | out} interface {INTERFACE NAME}
Example:
access-group FROMOUTSIDE in interface outside
______________
Object groups
If there are many similar objects in your network (for example, networks of users, servers with the same set of services, etc.), then when setting up access lists you will definitely encounter the fact that they become hard to read and poorly expandable. 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 an element of the same type in the access list. For example, instead of the source or destination addresses, you can apply an object group of a network type (object-group network), and instead of explicitly specifying a TCP service (ssh, http), you can apply a group of service type TCP.
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 all the rows in the list with the object group will have the same row 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) <output omitted>
Notice that the number of matches (hit) will be on each line, and not just the total number of matches.
You can view object groups with the command
show run object-group [{type}]
Network Address Translation (coming soon :))
Source: https://habr.com/ru/post/81396/
All Articles