In the previous part of this series, 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, as well as how to monitor the Dynamic Access Control Lists as an administrator.
In this section, we will cover the two types of Automated Dynamic Access Control Lists (per-user ACLs and per-line ACLs), as well how to monitor these kind of ACLs. Proper restrictions and timeouts will still be one the menu for better understanding.
Automated Dynamic ACLs
Manually activated Dynamic ACLs are not an elegant solution in real life situations. Requiring ordinary users to first telnet into an IP address (the lock-and-key router) before they can think of what resource or host they want to connect to can prove impractical. What is acceptable for administrators or advanced users is most of the time unworkable for mere users.
Besides, allowing users to telnet in a particular process on your router might be adding another attack surface on the router. Bugs in the IOS might allow the user unwarranted permissions. It is better to activate the dynamic ACLs automatically as the next few sections are going to show.
Trusting the user to issue the access-enable command with the right syntax and the right host and timeout options can be “not user friendly”. That step can be automated with the autocommand command so that the user has only to telnet into and authenticate with the lock-and-key without the requirement to issue the access-enable command.
The autocommand option on the username and password command requires the following command options to be literally entered “as-is” because it provides no usual auto completion feature. Therefore, you need to know whether you are going to say “access-enable” or “access-enable host” after the autocommand option. The latter allows you to be more specific about the origin of the request, adding more security through source IP address discrimination.
As seen in earlier sections, manually triggered dynamic access control lists also allow for host based restrictions but again, the user needs to enter, after a successful telnet into the lock-and-key router, the command access-enable host. Without the “host” option specified, in manually triggered, per user or per line dynamic access control lists, any source IP address coming to the inside area is allowed to proceed with normal traffic through the lock-and-key router without authenticating first.
Configuration of the Automated Dynamic Per User ACLs
Let’s go and configure the automated per user Dynamic ACLs. We configure the username with the auto command we want to have executed upon authentication by the user:
And the normal username and password the user will be authenticating with:
That’s all we need to configure on the lock-and-key router to enable dynamic per user access control lists because the dynamic access control list is set/kept the same as in the manual dynamic access control list.
The only change now is that, upon authentication, the user is automatically disconnected from the lock-and-key router before he/she can even try to issue the access-enable command. That command is no longer needed because at the same time the lock-and-key router disconnects the user it is also automatically setting up the access-enable feature with the host and timeout options as configured earlier.
Here we see the user authentication and immediate disconnection from the lock-and-key:
And the successful connection to the inside router:
Remember that beyond the autocommand option the IOS doesn’t provide an auto completion feature anymore. We need to type the command “as-is” since the IOS will not check the syntax of the commands and options after the autocommand command.
And the proof that we are on our own is here:
The wrong_command_syntax is accepted by the IOS and put in the running configuration.
The show running configuration will let us check that wrong_command_syntax is effectively in the running configuration file:
Our curiosity is for what will happen once the user tries to log in to the lock-and-key and the IOS on the router hits a snag on the wrong_command_syntax command.
Well, let’s go and test the problem and see the output message or lack thereof.
The error message is loud and clear. Before the lock-and-key disconnected, the IOS reports that “the line has an invalid autocommand” and even displays the culprit command, namely the wrong_command_syntax command. Rarely an error message has been that clear.
Configuration of the Automated Dynamic Per Line ACLs
The same autocommand, source host based restrictions and timeout remarks apply to per line automated Dynamic ACLs as well. In the automated dynamic per line access control lists the autocommand is applied on the VTY lines, the Virtual Terminal we telnet or SSH into remotely, offering the possibility to automatically run different commands on different VTY lines as needed.
Once again the only change here, compared to manual dynamic Access Control Lists, is the autocommand line introduced on the VTY lines to automate the desired command. In our situation, the access-enable command:
In trying to telnet the lock-and-key, the connection is successful but gets immediately disconnected by the lock-and-key router:
The friendly show access-lists command convinces us that the dynamic access control list has been activated successfully and even graces us with the time left.
To confirm this we try to telnet into the inside router:
The automated dynamic per line Access Control Lists are working as advertised.
Maintaining Dynamic Access Control Lists
Now before we close this tutorial, let’s talk about a couple of commands like show access-lists and clear access-template.
During the course of this tutorial we’ve seen what the show access-lists command can allow us to see. From the number and nature of access lists available on the IOS router to the status of dynamic access control lists (active or inactive), not forgetting the time left information that tells us how much time is left before the dynamic access control list times out, etc., that’s a really useful tool to verify the health and the nuts and bolts of your access control lists on the IOS router.
The other useful tool for maintaining your dynamic access control lists is the clear access-template command. This one can be useful when trying to test access lists and it takes time before they timeout. You can go ahead and clear the active access list and start on a clean slate without having to wait for the access list to expire.
The syntax of the clear access-template is like this:
Let’s say for example I am testing manual dynamic access control lists.
From the outside3 router, I telnet, authenticate, and issue the access-enable command:
On the lock-and-key router, I can see the dynamic access control list is active:
And also on the outside3 router I can successfully telnet beyond the lock-and-key straight into the inside router.
Now let’s say I want to redo the whole test immediately, re-authenticating on the lock-and-key and issuing the access-enable command again but before the dynamic access control list expires, I will be only able to re-authenticate on the lock-and-key router and the access-enable command is going to fail with an error message.
Successful authentication here below:
The access-enable is failing. We can try again and again, but we won’t be able to run this command successfully before the dynamic access list expires:
So now we are confronted with two possibilities: sit and wait for the absolute timeout to happen or manually clear the access control lists so we can re-run our access-enable command.
The clear access-template command will allow us to do the latter:
And we can now go on doing our tests to our heart’s desire without the constraints of a timer on a router:
We have come to the conclusion of our tutorial on Dynamic Access Control Lists, also known as Lock-and-key. This tutorial is just the tip of the iceberg of what administrators can do with Access Control Lists. I personally agree with anyone who says the Access Control Lists are the Swiss Army knife of the IOS configuration. I look forward to bringing you more labs on Access Control Lists and their numerous use scenarios.