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 should be familiar to many of you, so I want to summarize information on different types of ACLs. I will go over the basics briefly and then talk about special types of ACLs: time-based (time-based), reflexive (reflective), dynamic (dynamic). So, let's begin…

    The Basics: Remember All ...

    Quickly go over the basic concepts, syntax, so that later it would be easier to go to more interesting things. ACLs on Cisco routers allow you to solve two groups of problems:

    • traffic filtering;
    • traffic classification.

    This article is mainly devoted to filtering, i.e. Using ACLs as a firewall. 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
    • IP Encapsulated Protocol
    • Source port
    • Port of destination

    ACLs are divided into 2 types:

    • Standard
    • Extended

    Standard ACLs allow you to filter traffic by one single criterion - the source IP address. Advanced ACLs filter on all five of the listed parameters.

    An ACL consists of a set of rules. In each rule, you define filtering parameters (addresses, ports, etc.) and the action performed on the packet if it meets all the criteria of the rule. Two actions: allow (permit) and deny (deny). When enabled, the packet is processed further, if disabled, it is discarded. Rules are checked sequentially until the one to which the packet corresponds is found. An action (permit / deny) is performed on the package and further verification of the rules is terminated. At the end of any ACL is an implicit rule prohibiting all traffic. Those. restrictive access control is used: everything that is explicitly not allowed is forbidden.


    Two ways to create an ACL:

    • The "old" syntax. Numbers are used to identify ACLs. Standard ACLs are assigned numbers 1-99 and 1300-1999, and extended ACLs are assigned 100-199 and 2000-2699.
    • Syntax for named ACLs. The name selected by the administrator is used for identification.

    The second method is more convenient. First, you use a name rather than a number to identify the ACL, i.e. by name you can understand what you are using the ACL for. Secondly, the named sheets use their own configuration mode, which allows you to edit ACLs more conveniently.

    Here are some examples of standard ACLs:

    access-list 1 permit
    access-list 2 permit any
    access-list 3 permit host
    access-list 4 permit
    access-list 4 permit

    The first ACL (1) allows traffic from the network. The second (2) ACL allows all traffic. The third (3) allows traffic from the host And the last fourth, in the first line allows traffic from hosts -, in the second line allows traffic from networks - Please note that here are examples of four different ACLs, and not 5 rules of one ACL.

    And a few extended ACLs:

    access-list 100 permit tcp any eq 80
    access-list 101 permit udp host eq 500 host eq 555
    access-list 102 permit icmp any any echo
    access-list 103 permit ip any any

    ACL 100 allows TCP traffic from network to any network, destination port 80. That is, allow web surfing from the local network. ACL 101 allows UDP traffic from host, port 500 to host, port 555. ACL 102 allows pings from anywhere, 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
    ip access-list standard LIST2
     permit any
    ip access-list standard LIST3
     permit host
    ip access-list standard LIST1
    ip access-list extended LIST100
     permit tcp any eq 80
    ip access-list extended LIST101
     permit udp host eq 500 host eq 555
    ip access-list extended LIST102
     permit icmp any any echo
    ip access-list extended LIST103
     permit ip any any

    Editing an ACL has become much more convenient since 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
        10 permit, wildcard bits
        20 permit, wildcard bits
        30 permit, wildcard bits
    Standard IP access list LIST2
        10 permit any
    Standard IP access list LIST3
        10 permit
    Extended IP access list LIST100
        10 permit tcp any eq www
    Extended IP access list LIST101
        10 permit udp host eq isakmp host eq 555
    Extended IP access list LIST102
        10 permit icmp any any echo
    Extended IP access list LIST103
        10 permit ip any any

    Note that the ACL lines are numbered. To add new lines to a specific position, enter the editing ACL mode 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 — using the old syntax or in a new way, just specify the ACL number instead of the ACL name. Adding and removing rows is exactly the same.

    To delete lines, use the no command with the line number:

    ip access-list standard LIST103
     no 25 

    You can renumber lines:

    ip access-list resequence LIST103 10 50

    In the above example, for an ACL with the name LIST103, renumbering will be performed and the number of the first line will be 10, and subsequent lines will be numbered in increments of 50. That is, 10, 60, 110, 160 ...

    And 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, it will be necessary to indicate the direction of filtering: in (input) - traffic comes from the wire to the router interface, out (output) - traffic from the interface goes to the wire. In the example, the ACL is used to filter incoming traffic:

    interface fa0/0
     ip access-group LIST103 in

    All this, I hope, well-known 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:

    1. Create one or more "calendars" - time ranges;
    2. Use these calendars in extended ACL rules.

    To create a "calendar", use the time-range command , which indicates an arbitrary name assigned to the calendar. You will subsequently refer to this name in the rules of your ACLs. 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 (days of the week, workdays, or weekends are indicated, but without reference to a specific date).

    In the above example, two time intervals are created: absolute (determines the time from 00:00 January 01, 2012 to 23:59 December 31, 2012) and relative (determines the 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 - working days, weekend - days off.
    To view the created “calendars” give the command show time-tange :

    R0#sh time-range
    time-range entry: WORK_DAYS (active)
       absolute start 00:00 01 January 2012 end 23:59 31 December 2012

    The word active next to the name of the “calendar” indicates 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 any eq www time-range WORK_DAYS
    permit tcp any eq ftp-data time-range ANOTHER_RANGE

    As you can see, you can use different “calendars” for different rules of one ACL. Calendars you can use only in advanced ACLs.

    Reflexive acl

    Reflective or mirrored ACLs allow you to slightly expand your filtering capabilities. Essentially, they turn ACLs from packet filtering into a stateful inspection firewall. Those. Now the router will monitor the status of sessions initiated from the internal network of the company and create appropriate return rules.


    Let me explain with a typical situation. There is an internal network We allow access from this network to the Internet (http) - the "green" ACL. Those. Using this ACL, we define policies for leaving the internal network to the external network. Using the second “red” ACL, we protect the internal network from intruders from the outside. But it is necessary to allow responses to sessions initiated from the internal network, so we allow return traffic. Everything seems to be logical: allowed requests there, allowed answers from there. But with this configuration, we greatly open the internal network. Any TCP packet from port 80 freely enters the internal network. Welcome to SYN Flood attacks and more. This problem can be easily solved using the stateful inspection firewall (CBAC or IOS Firewall), but what to do, if your edition of iOS does not support this functionality? Mirrored 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 test the temporary mirrored ACL: the evaluate command. You can consider this command as an opportunity to check one ACL inside another, i.e. the command will be replaced by a set of rules from a temporary ACL.

    Until sessions from the internal network are open, the mirrored ACL is empty, it 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 the sessions open, the mirrored ACL will begin to fill up:

    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 host  (19 matches) (time left 289)
         permit tcp host eq telnet host eq 62609 (30 matches) (time left 286)
         permit ospf host  host  (6 matches) (time left 297)

    In the example, a ping was started from the internal network from the address to the address, then a telnet connection was opened from the internal address to the external address An example of a telnet connection clearly shows the completed sequence of actions:

    1. The internal host initiates a connection from the address and a randomly selected port 62609 to the address of the external host, port 23 (telnet).
    2. Packets are checked by the INTERNAL ACL, allowed by the line: 10 permit ip any any reflect MIRROR
    3. Reflected in the MIRROR ACL: permit tcp host eq telnet host eq 62609
    4. External responses are checked by an EXTERNAL ACL containing a reference to the MIRROR ACL: evaluate MIRROR .

    Return traffic is ultimately allowed. If an attempt were made to open any connection to the internal network from outside, then it would be prohibited: deny ip any any log .

    In general, with a flick of the wrist, the ACL almost turned into a stateful inspection firewall.

    Dynamic (Lock-and-Key) ACLs

    The next category of ACLs 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 preliminary 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 that allows access to network resources. The algorithm is as follows:

    Пользователь подключается к роутеру с любого (настраивается) адреса.
    Пользователь проходит аутентификацию.
    После успешной аутентификации, на интерфейсе активируются специальные правила динамического ACL.
    Правила остаются активными в течение настраиваемого периода времени.

    What is required to configure dynamic ACLs:

    • Create an extended ACL that allows 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 look at the following example: The


    user requires a connection to the server on port 80 on the internal network. The addresses from which the connection will occur are not known to us. First of all, create an extended ACL that allows telnet connections to the router (address and contains dynamic ACL entries, then apply it to the desired interface:

    ip access-list extended TELNET-IN						
     permit tcp any host eq telnet										(1)
     dynamic DYNAMIC-ACL-NAME permit tcp any host eq www		(4)
     deny ip any any
    int s0/0
     ip address
     ip access-group TELNET-IN in

    The next step is to configure 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 it is used, any as the source IP address in the dynamic ACL will be replaced with the address from which the user is connecting. The timeout parameter determines the period of inactivity in minutes for this session, by default it is infinite.

    How will the process of gaining access in the given example:

    • The user opens a telnet connection to the router to the address Permitted by the extended ACL rule (1).
    • Local authentication phase (2).
    • In case of successful authentication, the access-enable (3) command is automatically executed, which activates the dynamic ACL (4) rules. Telnet connection closes.
    • The user is granted access in accordance with the rules of the dynamic ACL.


    As you can see, Cisco IOS ACLs have very interesting capabilities, considering that this is the basic functionality of virtually any IOS. A lot of things, of course, remained behind the scenes: ACL and QoS, rate limits. And even more so, topics such as CBAC, Zone-based Firewall, etc. Thanks for reading.

    Also popular now: