Cisco IOS ACLs
Good day to all!
In this article, I would like to talk about the capabilities of Cisco IOS Access Control Lists (ACLs). The topic of many of you should be familiar, so I want to summarize information on different types of ACLs. I will briefly go over the basics and then talk about special types of ACLs: time-based (time-based), reflexive (reflective), dynamic (dynamic). So, let's begin…
Quickly run through the basic concepts, syntax, so that later you can easily move on to more interesting things. ACLs on Cisco routers allow you to solve two groups of tasks:
')
This article is mainly about filtering, i.e. using ACL as a firewall. The classification allows you to select packages for further processing. For example, encrypt only certain traffic when creating a VPN, apply quality of service policies, broadcast only certain addresses, etc.
ACLs can be attributed to packet filtering firewalls. Those. they allow you to filter packets by five parameters:
ACLs are divided into 2 types:
Standard ACLs allow filtering traffic by a single criterion - the source IP address. Extended ACLs filter by all five parameters listed.
ACL consists of a set of rules. In each rule, you define the filtering parameters (addresses, ports, etc.) and the action performed on the packet, if it meets all the criteria of the rule. There are two actions: permit and deny. When enabled, the packet is processed further; if disabled, it is discarded. The rules are checked sequentially until the one that matches the packet is found. An action is taken over the packet (permit / deny) and further verification of the rules is terminated. At the end of any ACL, there is an implicit rule that prohibits all traffic. Those. restrictive access control is used: everything that is not explicitly allowed is prohibited.
Two ways to create an ACL:
The second method is more convenient. First, to identify the ACL, you use the name, not the number, i.e. by name it will be possible to understand why you use the ACL. Secondly, named sheets use their own configuration mode, which allows you to more conveniently edit ACLs.
Here are some examples of standard ACLs:
The first ACL (1) allows traffic from the 192.168.1.0/24 network. The second (2) ACL allows all traffic. The third (3) allows traffic from the host 10.1.1.1. And the last fourth, in the first line allows traffic from hosts 10.1.1.0 to 10.1.1.15, in the second line allows traffic from networks 192.168.0.0 - 192.168.31.0. I note that here are examples of four different ACLs, and not 5 rules of a single ACL.
And a few extended ACLs:
ACL 100 allows TCP traffic from a 10.1.1.0/24 network to any network, destination port 80. That is, allow web surfing from the local network. ACL 101 allows UDP traffic from host 1.1.1.1, port 500 to host 2.2.2.2, port 555. ACL 102 allows pings from anywhere to anywhere. And finally, the last ACL 103 allows all traffic.
Similar standard and extended ACLs, but using the new syntax:
Editing ACLs has become much easier starting I iOS 12.3 ,. If you give the command:
You will see a list of ACLs and their contents:
Notice that the ACL lines are numbered. To add new lines to a specific position, enter the edit mode of the desired ACL and enter the line number before entering a new rule:
And it does not matter how you created the ACL - with the help of the old syntax or in a new way, just specify the number of the ACL instead of the name. Adding and deleting lines is done in exactly the same way.
To delete lines, use the no command with the line number:
You can renumber the lines:
In the example above, the ACL named LIST103 will be renumbered and the first line number will be 10, and the subsequent lines will be numbered in increments of 50. That is, 10, 60, 110, 160 ...
Finally, after creating the ACL, you will need to apply it in accordance with your goals and objectives. As for filtering, the ACL is applied on the interface. When applying, you will need to specify the direction of filtering: in (input) - traffic comes from the wire to the router interface, out (exit) - traffic from the interface goes to the wire. In the example, the ACL is used to filter inbound traffic:
All this, I hope, famous things. If you have any questions, ask, I will try to answer. If there are a lot of questions, you can make a separate post. Now let's look at the additional features that ACLs have on Cisco routers.
Let's start with ACLs in which you can use time as an additional criterion by which traffic will be filtered or classified. For example, during working hours, web surfing is prohibited, and at lunchtime and after work - please. What is required to create a time-based ACL? Everything is very simple:
To create a "calendar", use the time-range command, in which you specify an arbitrary name assigned to the calendar. You will later refer to this name in your ACL rules. In the example, I create a “calendar” named WORK_DAYS:
In the calendar configuration mode, you define time ranges. Two types of ranges:
In the example above, two time intervals are created: absolute (determines the time from 00:00 January 01, 2012 to 23:59 December 31, 2012) and relative (determines days from Monday to Friday, from 9:00 to 18:00). For periodic intervals, as you can see, you can use the names of the days of the week, daily - daily, weekdays - weekdays, weekend - weekends.
To view the created "calendars" give the show time-tange command :
The word active next to the name of the calendar means that it is active, i.e. The “calendar” time now corresponds to the current time on the router.
Now let's use our “calendar” in the ACL rules:
As you can see, you can use different “calendars” for different rules of one ACL. Calendars can only be used in extended ACLs.
Reflective or mirrored ACLs allow some filtering to be extended. In effect, they turn the ACL from packet filtering into a stateful inspection firewall. Those. Now the router will monitor the status of sessions initiated from the company's internal network and create appropriate return rules.
Let me explain with an example of a typical situation. There is an internal network 192.168.1.0/24. We allow access from this network to the Internet (http) - a “green” ACL. Those. With this ACL, we define exit policies from the internal network to the external network. With the help of a second, “red” ACL, we protect the internal network from outside intrusions. But it is necessary to allow responses to sessions initiated from the internal network, so we allow return traffic. It seems to be all logical: they allowed requests there, allowed answers from there. But with this configuration, we strongly reveal the internal network. Any TCP packet from port 80 easily gets into the internal network. Welcome to SYN Flood attacks and more. This problem is easily solved using a stateful inspection firewall (CBAC or IOS Firewall), but what if your IOS edition does not support this functionality? Mirror ACLs come to the rescue.
The idea is that now from one ACL (usually, “green” - internal), packets that pass the test will be mirrored or reflected in the rules of a special temporary ACL, which in turn will be checked by an external (“red”) ACL.
See an example. For certain rules in the green ACL, we use the reflect parameter and specify the name of the temporary ACL (in the example, MIRROR) where the rules will be reflected. In the "red" ACL, we check the temporary mirror ACL: the evaluate command. You can view this command as an opportunity to check one ACL inside another, i.e. the command will be replaced by the rule set from the temporary ACL.
While sessions from the internal network are not open, the mirror ACL is empty and does not contain any rules:
But as soon as sessions open, the mirror ACL will begin to fill:
In the example from the internal network, the ping to the address 2.2.2.2 was launched from the address 192.168.1.1, then the telnet connection from the internal address 192.168.1.1 to the external address 192.168.2.1 was opened. On the example of a telnet connection, the sequence of actions performed is clearly visible:
Return traffic is ultimately allowed. If there was an attempt to open any connection to the internal network from the outside, then it would be forbidden: deny ip any any log .
In general, with a flick of the wrist, the ACL has almost become a stateful inspection firewall.
The next category of ACL is dynamic. Basically, these ACLs are used for remote connections to the company's network, but you can also use them when connecting to various resources requires pre-authentication. Imagine that administrators need constant connections to the company's network, but they will connect from different places, from different IP addresses. The idea of ​​dynamic ACLs is that a person must first authenticate and only if successful will an ACL be applied allowing access to network resources. The algorithm is as follows:
What is required for configuring dynamic ACLs:
Let's take everything into the following example:
The user needs to connect to the server 192.168.1.1 on port 80 on the internal network. The addresses from which the connection will be made are not known to us. First of all, we create an extended ACL that allows telnet connections to the router (address 1.1.1.1) and contains dynamic ACL entries, then use it on the desired interface:
The next step is setting up authentication. I will use local authentication, so I create a root user and enable local authentication on vty ports:
The autocommand access-enable command enables authentication and enables dynamic ACL entries. The host parameter is optional. When using it, any as the source IP address in a dynamic ACL will be replaced with the address from which the user connects. The timeout parameter defines the period of inactivity in minutes for this session, the default is infinite.
How will the access process in the above example:
As you can see ACLs in Cisco IOS have very interesting features, given that this is the basic functionality of virtually any IOS. Of course, much is left behind the scenes: ACL and QoS, rate limits. And even more so, such topics as CBAC, Zone-based Firewall and others. Thanks for reading.
In this article, I would like to talk about the capabilities of Cisco IOS Access Control Lists (ACLs). The topic of many of you should be familiar, so I want to summarize information on different types of ACLs. I will briefly go over the basics and then talk about special types of ACLs: time-based (time-based), reflexive (reflective), dynamic (dynamic). So, let's begin…
The basics: Recall everything ...
Quickly run through the basic concepts, syntax, so that later you can easily move on to more interesting things. ACLs on Cisco routers allow you to solve two groups of tasks:
')
- traffic filtering;
- traffic classification.
This article is mainly about filtering, i.e. using ACL as a firewall. The classification allows you to select packages for further processing. For example, encrypt only certain traffic when creating a VPN, apply quality of service policies, broadcast only certain addresses, etc.
ACLs can be attributed to packet filtering firewalls. Those. they allow you to filter packets by five parameters:
- Source ip address
- Destination ip address
- IP encapsulated protocol
- Source port
- Port of destination
ACLs are divided into 2 types:
- Standard
- Extended (Extended)
Standard ACLs allow filtering traffic by a single criterion - the source IP address. Extended ACLs filter by all five parameters listed.
ACL consists of a set of rules. In each rule, you define the filtering parameters (addresses, ports, etc.) and the action performed on the packet, if it meets all the criteria of the rule. There are two actions: permit and deny. When enabled, the packet is processed further; if disabled, it is discarded. The rules are checked sequentially until the one that matches the packet is found. An action is taken over the packet (permit / deny) and further verification of the rules is terminated. At the end of any ACL, there is an implicit rule that prohibits all traffic. Those. restrictive access control is used: everything that is not explicitly allowed is prohibited.
Syntax
Two ways to create an ACL:
- “Old” syntax. To identify the ACL numbers are used. Standard ACLs are assigned numbers 1-99 and 1300-1999, and extended ACL numbers are 100-199 and 2000-2699.
- Named ACL syntax. For identification, use the name selected by the administrator.
The second method is more convenient. First, to identify the ACL, you use the name, not the number, i.e. by name it will be possible to understand why you use the ACL. Secondly, named sheets use their own configuration mode, which allows you to more conveniently edit ACLs.
Here are some examples of standard ACLs:
access-list 1 permit 192.168.1.0 0.0.0.255 ! access-list 2 permit any ! access-list 3 permit host 10.1.1.1 ! access-list 4 permit 10.1.1.0 0.0.0.15 access-list 4 permit 192.168.0.0 0.0.31.255 The first ACL (1) allows traffic from the 192.168.1.0/24 network. The second (2) ACL allows all traffic. The third (3) allows traffic from the host 10.1.1.1. And the last fourth, in the first line allows traffic from hosts 10.1.1.0 to 10.1.1.15, in the second line allows traffic from networks 192.168.0.0 - 192.168.31.0. I note that here are examples of four different ACLs, and not 5 rules of a single ACL.
And a few extended ACLs:
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq 80 access-list 101 permit udp host 1.1.1.1 eq 500 host 2.2.2.2 eq 555 access-list 102 permit icmp any any echo access-list 103 permit ip any any ACL 100 allows TCP traffic from a 10.1.1.0/24 network to any network, destination port 80. That is, allow web surfing from the local network. ACL 101 allows UDP traffic from host 1.1.1.1, port 500 to host 2.2.2.2, port 555. ACL 102 allows pings from anywhere to anywhere. And finally, the last ACL 103 allows all traffic.
Similar standard and extended ACLs, but using the new syntax:
ip access-list standard LIST1 permit 192.168.1.0 0.0.0.255 ! ip access-list standard LIST2 permit any ! ip access-list standard LIST3 permit host 10.1.1.1 ! ip access-list standard LIST1 permit 10.1.1.0 0.0.0.15 permit 192.168.0.0 0.0.31.255 ! ip access-list extended LIST100 permit tcp 10.1.1.0 0.0.0.255 any eq 80 ! ip access-list extended LIST101 permit udp host 1.1.1.1 eq 500 host 2.2.2.2 eq 555 ! ip access-list extended LIST102 permit icmp any any echo ! ip access-list extended LIST103 permit ip any any Editing ACLs has become much easier starting I iOS 12.3 ,. If you give the command:
show access-list You will see a list of ACLs and their contents:
R0(config-ext-nacl)#do sh access-li Standard IP access list LIST1 <b> 10</b> permit 192.168.1.0, wildcard bits 0.0.0.255 <b> 20</b> permit 10.1.1.0, wildcard bits 0.0.0.15 <b> 30</b> permit 192.168.0.0, wildcard bits 0.0.31.255 Standard IP access list LIST2 10 permit any Standard IP access list LIST3 10 permit 10.1.1.1 Extended IP access list LIST100 10 permit tcp 10.1.1.0 0.0.0.255 any eq www Extended IP access list LIST101 10 permit udp host 1.1.1.1 eq isakmp host 2.2.2.2 eq 555 Extended IP access list LIST102 10 permit icmp any any echo Extended IP access list LIST103 10 permit ip any any Notice that the ACL lines are numbered. To add new lines to a specific position, enter the edit mode of the desired ACL and enter the line number before entering a new rule:
ip access-list standard LIST1 25 permit … And it does not matter how you created the ACL - with the help of the old syntax or in a new way, just specify the number of the ACL instead of the name. Adding and deleting lines is done in exactly the same way.
To delete lines, use the no command with the line number:
ip access-list standard LIST103 no 25 You can renumber the lines:
ip access-list resequence LIST103 10 50 In the example above, the ACL named LIST103 will be renumbered and the first line number will be 10, and the subsequent lines will be numbered in increments of 50. That is, 10, 60, 110, 160 ...
Finally, after creating the ACL, you will need to apply it in accordance with your goals and objectives. As for filtering, the ACL is applied on the interface. When applying, you will need to specify the direction of filtering: in (input) - traffic comes from the wire to the router interface, out (exit) - traffic from the interface goes to the wire. In the example, the ACL is used to filter inbound traffic:
interface fa0/0 ip access-group LIST103 in All this, I hope, famous things. If you have any questions, ask, I will try to answer. If there are a lot of questions, you can make a separate post. Now let's look at the additional features that ACLs have on Cisco routers.
Time-based ACLs
Let's start with ACLs in which you can use time as an additional criterion by which traffic will be filtered or classified. For example, during working hours, web surfing is prohibited, and at lunchtime and after work - please. What is required to create a time-based ACL? Everything is very simple:
- Create one or more "calendars" - time ranges;
- Use these "calendars" in the extended ACL rules.
To create a "calendar", use the time-range command, in which you specify an arbitrary name assigned to the calendar. You will later refer to this name in your ACL rules. In the example, I create a “calendar” named WORK_DAYS:
time-range WORK_DAYS absolute start 00:00 01 January 2012 end 23:59 31 December 2012 periodic weekdays 9:00 to 18:00 periodic ? Friday Friday Monday Monday Saturday Saturday Sunday Sunday Thursday Thursday Tuesday Tuesday Wednesday Wednesday daily Every day of the week weekdays Monday thru Friday weekend Saturday and Sunday In the calendar configuration mode, you define time ranges. Two types of ranges:
- Absolute (specific dates and times are indicated).
- Periodic (indicate the days of the week, working days or weekends, but without reference to a specific date).
In the example above, two time intervals are created: absolute (determines the time from 00:00 January 01, 2012 to 23:59 December 31, 2012) and relative (determines days from Monday to Friday, from 9:00 to 18:00). For periodic intervals, as you can see, you can use the names of the days of the week, daily - daily, weekdays - weekdays, weekend - weekends.
To view the created "calendars" give the show time-tange command :
R0#sh time-range time-range entry: WORK_DAYS <b>(active)</b> absolute start 00:00 01 January 2012 end 23:59 31 December 2012 The word active next to the name of the calendar means that it is active, i.e. The “calendar” time now corresponds to the current time on the router.
Now let's use our “calendar” in the ACL rules:
ip access-list extended TIME_BASED_ACL permit tcp 10.0.0.0 0.255.255.255 any eq www <b>time-range WORK_DAYS</b> permit tcp 10.0.0.0 0.255.255.255 any eq ftp-data <b>time-range ANOTHER_RANGE</b> As you can see, you can use different “calendars” for different rules of one ACL. Calendars can only be used in extended ACLs.
Reflexive ACL
Reflective or mirrored ACLs allow some filtering to be extended. In effect, they turn the ACL from packet filtering into a stateful inspection firewall. Those. Now the router will monitor the status of sessions initiated from the company's internal network and create appropriate return rules.
Let me explain with an example of a typical situation. There is an internal network 192.168.1.0/24. We allow access from this network to the Internet (http) - a “green” ACL. Those. With this ACL, we define exit policies from the internal network to the external network. With the help of a second, “red” ACL, we protect the internal network from outside intrusions. But it is necessary to allow responses to sessions initiated from the internal network, so we allow return traffic. It seems to be all logical: they allowed requests there, allowed answers from there. But with this configuration, we strongly reveal the internal network. Any TCP packet from port 80 easily gets into the internal network. Welcome to SYN Flood attacks and more. This problem is easily solved using a stateful inspection firewall (CBAC or IOS Firewall), but what if your IOS edition does not support this functionality? Mirror ACLs come to the rescue.
The idea is that now from one ACL (usually, “green” - internal), packets that pass the test will be mirrored or reflected in the rules of a special temporary ACL, which in turn will be checked by an external (“red”) ACL.
See an example. For certain rules in the green ACL, we use the reflect parameter and specify the name of the temporary ACL (in the example, MIRROR) where the rules will be reflected. In the "red" ACL, we check the temporary mirror ACL: the evaluate command. You can view this command as an opportunity to check one ACL inside another, i.e. the command will be replaced by the rule set from the temporary ACL.
While sessions from the internal network are not open, the mirror ACL is empty and does not contain any rules:
Extended IP access list EXTERNAL 10 evaluate MIRROR 20 deny ip any any log Extended IP access list INTERNAL 10 permit ip any any reflect MIRROR (2 matches) Reflexive IP access list MIRROR But as soon as sessions open, the mirror ACL will begin to fill:
R1#sh access-li Extended IP access list EXTERNAL 10 evaluate MIRROR 20 deny ip any any log (5 matches) Extended IP access list INTERNAL 10 permit ip any any reflect MIRROR (36 matches) Reflexive IP access list MIRROR permit icmp host 2.2.2.2 host 192.168.1.1 (19 matches) (time left 289) permit tcp host 192.168.2.1 eq telnet host 192.168.1.1 eq 62609 (30 matches) (time left 286) permit ospf host 224.0.0.5 host 192.168.1.1 (6 matches) (time left 297) In the example from the internal network, the ping to the address 2.2.2.2 was launched from the address 192.168.1.1, then the telnet connection from the internal address 192.168.1.1 to the external address 192.168.2.1 was opened. On the example of a telnet connection, the sequence of actions performed is clearly visible:
- The internal host initiates a connection from the address 192.168.1.1 and randomly selected port 62609 to the address of the external host 192.168.2.1, port 23 (telnet).
- Packets are checked by the INTERNAL ACL, allowed by the line: 10 permit ip any any reflect MIRROR
- Reflected in the MIRROR ACL: permit tcp host 192.168.2.1 eq telnet host 192.168.1.1 eq 62609
- External responses are checked by an EXTERNAL ACL containing a link to the MIRROR ACL: evaluate MIRROR .
Return traffic is ultimately allowed. If there was an attempt to open any connection to the internal network from the outside, then it would be forbidden: deny ip any any log .
In general, with a flick of the wrist, the ACL has almost become a stateful inspection firewall.
Dynamic (Lock-and-Key) ACLs
The next category of ACL is dynamic. Basically, these ACLs are used for remote connections to the company's network, but you can also use them when connecting to various resources requires pre-authentication. Imagine that administrators need constant connections to the company's network, but they will connect from different places, from different IP addresses. The idea of ​​dynamic ACLs is that a person must first authenticate and only if successful will an ACL be applied allowing access to network resources. The algorithm is as follows:
() . . , ACL. . What is required for configuring dynamic ACLs:
- Create an extended ACL allowing telnet or SSH connections to the router. These protocols will be used to connect to the router.
- Define authentication parameters. Local authentication, AAA, password on vty ports are supported.
- Configure dynamic ACL settings.
Let's take everything into the following example:
The user needs to connect to the server 192.168.1.1 on port 80 on the internal network. The addresses from which the connection will be made are not known to us. First of all, we create an extended ACL that allows telnet connections to the router (address 1.1.1.1) and contains dynamic ACL entries, then use it on the desired interface:
ip access-list extended TELNET-IN permit tcp any host 1.1.1.1 eq telnet (1) dynamic DYNAMIC-ACL-NAME permit tcp any host 192.168.1.1 eq www (4) deny ip any any ! int s0/0 description CONNECTED TO EXTERNAL NETWORK ip address 1.1.1.1 255.255.255.0 ip access-group TELNET-IN in The next step is setting up authentication. I will use local authentication, so I create a root user and enable local authentication on vty ports:
username root secret USERS_PASSWORD (2) ! line vty 0 4 login local (2) autocommand access-enable host timeout 10 (3) The autocommand access-enable command enables authentication and enables dynamic ACL entries. The host parameter is optional. When using it, any as the source IP address in a dynamic ACL will be replaced with the address from which the user connects. The timeout parameter defines the period of inactivity in minutes for this session, the default is infinite.
How will the access process in the above example:
- The user opens a telnet connection to the router to the address 1.1.1.1. Allowed by extended ACL rule (1).
- Local Authentication Phase (2).
- In case of successful authentication, the access-enable (3) command is automatically executed, activating dynamic ACL rules (4). Telnet connection is closed.
- The user is accessed according to the rules of dynamic ACL.
Conclusion
As you can see ACLs in Cisco IOS have very interesting features, given that this is the basic functionality of virtually any IOS. Of course, much is left behind the scenes: ACL and QoS, rate limits. And even more so, such topics as CBAC, Zone-based Firewall and others. Thanks for reading.
Source: https://habr.com/ru/post/154879/
All Articles