The usual standard and extended Access Control Lists are a Cisco IOS feature that gives a network administrator the means to control access to a network by preventing one kind of traffic while allowing another to enter or exit the said network.
There are, however, more advanced features that use Access Control Lists. These include Dynamic Access Control Lists, Time-Based Access Control Lists, Reflexive Access Control Lists, etc. In this article we are going to discover and configure Dynamic Access Control Lists.
The Dynamic Access Control Lists feature is also known as Lock-and-Key. While the Standard and Extended Access Control Lists are static and change only when manually edited or configured by the network administrator, lock-and-key is a very interesting feature that allows Access Control Lists to be temporarily applied on an interface in order to allow in or out certain traffic only to be removed upon user disconnection, idle or absolute timeout or administrator action.
The lock-and-key feature with Dynamic Access Control Lists is configured to require authentication for users before said ACLs can be applied to open up for specific traffic through the IOS Router configured for it.
However to have access from outside to the inside, there are newer technologies like EasyVPN and SSLVPN with tons of other features that make it easy for configuration. Furthermore, this lock-and-key feature can be supplemented by the Authentication Proxy feature where per-user ACLs are dynamically downloaded from TACACS+ AAA server or Radius server upon connection. In that case, a few commands will be configured on the lock-and-key router and the rest of the authentication proxy commands on the AAA server.
EasyVPN, SSLVPN and Authentication Proxy are beyond the scope of this tutorial and might be studied in future tutorials.
Since the Dynamic Access Control Lists feature requires the user to telnet into the edge lock-and-key router and undergo authentication, telnet or SSH enabled on the edge router will be the prerequisite for this feature to work.
Dynamic ACL: Configuration
To configure Dynamic Access Control Lists, the ACLs will be defined as dynamic with the keyword … dynamic. The Dynamic ACLs, once configured, are inactive until the user authenticates with the lock-and-key router and manually issues the access-enable command to activate the specific Dynamic Access Control List.
Upon the access-enable command, the corresponding permissive ACLs are applied to the configured interface and allow the defined traffic to go through the lock-and-key router. In this case they are being manually triggered. It is also possible to automate the access-enable command with the autocommand on a per-user or per line basis.
In this tutorial, the topology to use is below. From the routers outside (outside1, outside2, outside3) we will be trying to telnet into the router inside but we are required to authenticate first with the lock-and-key router in between.
Manually Activated Dynamic ACLs
When the Dynamic ACLs are configured to be activated by the user manually entering the “access-enable” command, we first permit telnet to the lock-and-key router for that purpose.
The Dynamic ACL INTENSE_SCHOOL is created to permit any TCP traffic originating from any host outside to any host inside the network.
This is actually a very generous and dangerous situation. The target destination address and the source address could and should be restricted to those involved parties when known. The destination TCP port should also be explicit so that hosts outside have access only to specific ports like HTTP (83), SSH (22), HTTPS (443, etc.). The administrator should be in possession of these pieces of information and configure the access list accordingly lest the service stay open to attacks when not needed.
If for example on our topology we want to allow an administrator on the outside2 router (loopback1:192.168.100.2) to telnet the inside router on loopback1:188.8.131.52 after authenticating against the local database on Lock_and_key router, the Dynamic ACL would read like this:
For our convenience, always explicitly configure deny any any log so that we can have visual log messages showing us what is being denied. This will prove very useful when debugging the ACLs.
Finally, we apply the ACL on the outside interface in the incoming direction:
Make sure every needed traffic (control plane and various other previously allowed traffic) is taken into account or you might lose existing connectivity.
After a lot of ACL editing you might find yourself needing to “resequence” your ACLs for better readability. Let’s say you have the following ACLs on your router:
The MY_EXTENDED_ACL could use a little resequencing for better readability.
We give it a new starting sequence number (starts at 20).
And a step to increment the sequence number. Here the sequence number will move in increments of 10:
And now the ACL sequencing has gotten a facelift with better readability. This is a cosmetic operation and has no impact on the operation of the MY_EXTENDED_ACL access control list.
Let’s go back to the Dynamic Access Control List configuration and testing.
Try pinging from outside2 to the loopback1 of the inside router:
It will return ICMP unreachable messages and the logs on the Lock-and-key router will show ICMP was denied:
To be able to telnet to the inside router from an outside router, the user needs to first telnet to the lock-and-key router:
And issue the command access-enable at the exec level:
On the lock-and-key router we see that the access list number 101 sequence 10 is active:
Now we should be able to telnet beyond the lock-castle and log into the inside router.
Manual Dynamic Access Control Lists with Proper Restrictions
The following access list has allowed us to specify earlier (see the sections above) what host and what traffic can go through the lock-and-key router to the inside router once the authentication has succeeded.
Had we not put restrictions on what host can send traffic through the lock-and-key router once the outside2 router was authenticated:
The “access-enable” command issued without the host option would have allowed any host outside the network (e.g. outside3) to telnet directly into the inside router without first authenticating with the lock-and-key router, which is an unpleasant behavior because we want every user to first get authenticated on their own.
If, however, the access-enable command was issued with the host option, no other router (e.g. outside3) would be able to telnet beyond the lock-and-key router without passing the authentication test.
The lock-and-key router would show lax restrictions and the outside3 router traffic to inside will be rejected:
The outside3 router will have to succeed its own authentication. For that, let’s allow the outside3 router to telnet into the lock-and-key router with /source-interface lo 1:
And then we issue the access-enable host command:
Once again the show ip access-list command shows that the dynamic access control list is activated; therefore the outside3 router can now connect to the inside router.
Does the access-enable command without the host option allow anyone else behind the source IP address to send traffic through the lock-and-key router?
This has just been proven in the above sections. Provided the Dynamic ACL didn’t provide restrictions to specific source IP addresses, enable-access without the host option will let enyone outside our network walk through our lock-and-key router into our network once someone on the same side of the lock-and-key router has authenticated and the Dynamic ACL is still active. Our best pactice advice would be to always be restrictive in the Dynamic ACL since you can’t have enough assurance that users will always add the host option to the access-enable command.
Dynamic Access Control Lists and Timeouts
The beauty of the Dynamic Access Control List feature is in the dynamic nature of the Access Control List. The permissive Access Control Lists are applied or activated temporarily and removed or deactivated as soon as a timeout period is over or no traffic has been detected for a while.
The two types of timeout, as far as the lock-and-key feature is concerned, are the idle timeout and the absolute timeout. The former is a timer for the length of time elapsed without traffic seen through that door opened by the Dynamic Access Control List and the latter is a timer configured by an administrator to deactivate the Dynamic ACL whether there is traffic or not going through, thus triggering the legitimate end user to reauthenticate and re-issue the access-enable command on the lock-and-key router in case there were still traffic going through.
Just as the absolute timeout is configured by the administrator, the idle timeout will be set by the user on the access-enable command issued on the lock-and-key router. The administrator may want to have his/her users reauthenticate every now and then for safety best practices. Moreover, the user may not always set the idle timeout thus leaving the hole in the wall made by the Dynamic ACL open permanently unless the system administror clears out the activated access control list or reloads the router.
Even with properly set restrictions as to who can funnel traffic through the Dynamic ACL hole, this is still a security risk mostly when you don’t know what kind of bug is in the software. Every door open on the perimeter fence is an attack surface open to unknown attack vectors. When both the idle timeout and the absolute timeout are configured, the idle timeout value has to be less than the absolute timeout value.
So let’s go and do some timeout configurations with Dynamic ACLs.
The idle timeout will be set by the authenticated user with the command access-anable host timeout and this command will not appear in the running or startup configuration.
We first telnet to 192.168.100.5 (loopback1 on the lock-and-key router) with source interface lo1 from the outside3 router.
Then we issue the access-enable command, making sure we specify an idle timeout of 2 minutes.
The 2 minutes are arbitrary, and we could use less depending on how paranoid we want to be.
The show access-list command now tells us the Dynamic ACL has been activated. Better, it even tells us how much time is left (118 seconds) before the idle timeout expires, which will trigger the access list clearing up and force the user to reauthenticate with the lock-and-key router next time he/she wants to reach the inside router:
The absolute timeout will be set by the network adminstrator on the lock-and-key router with the ip
access-list xxx dynamic command and will appear in the running and startup configuration.
In this example we will go into the INTENSE_SCHOOL dynamic access control list and modify it to set the absolute timeout to 5 minutes. Once again this is an arbitrary value so choose yours as per your situation. You don’t really want to require your users to reauthenticate every 5 minutes. To me, 30 minutes seems an adequate choice but your mileage may vary. We should remember also to ask users to set the idle timeout (as seen above) to a reasonable value.
So here we go:
Let’s modify the ACL to add a timeout threshold:
From the outside3 router, we authenticate with the lock-and-key router (source and destination addresses are on the loopback intefaces):
Then, we trigger dynamic ACL activation with access-enable and an idle timeout of 3 minutes.
Now I made the idle timeout 3 minutes and the absolute timeout 5 minutes.
The show access-list command shows us that the dynamic access control list INTENSE_SCHOOL was activated but the time left before timeout expiry is not shown.
Finally we will telnet to the inside router successfully:
In part one of this tutorial, we covered how to configure Dynamic Access Control Lists as an administrator, how to set up proper restrictions, how to set up the timeouts as an administrator and as a user, and, finally, how to use the Dynamic Access Control Lists as a user, along with how to monitor the Dynamic Access Control Lists as an administrator.
Part two of this tutorial will cover the two types of Automated Dynamic Access Control Lists (per-user ACLs, and per-line ACLs), and how to monitor these kinds of ACLs.