Answers: Protecting CLI Access 2
This lab was pretty direct: configure an ACL and use to to protect CLI access rather than filter packets being routed by the router. You know the drill – read lab, do lab, check here.
Answers
Figure 1: Topology and Addresses for this Lab
Example 1: R1 Config
|
1 2 3 4 5 |
access-list 1 deny 20.20.20.0 0.0.0.255 access-list 1 permit any ! line vty 0 4 access-class 1 in |
Example 2: R2 Config
|
1 2 3 4 5 |
access-list 1 deny 10.10.10.0 0.0.0.255 access-list 1 permit any ! line vty 0 4 access-class 1 in |
Commentary
For this lab we are focused on controlling access to the virtual lines of a device. Whether a specific device has telnet or SSH enabled by default using the virtual lines is dependent on the type of device and the version of code. In the past it was common for all input protocols to be permitted by default, but on newer versions of code it has become common for all methods to be disabled by default. For this lab telnet access has been enabled as part of the initial configuration and your task was to alter which device were able to connect to each respective device.
For this lab you were tasked with configuring R1 to not allow telnet access to itself from R2’s LAN and configuring R2 to not allow telnet access to itself from R1’s LAN. To achieve this there are two methods: using ACLs to filter traffic entering and exiting layer 3 interfaces, or applying an access list directly on the virtual lines. This lab specifically asked to limit terminal access, so the configuration enables the ACLs with the access-class 1 in command in VTY configuration mode on each router.
Per the requirements, R1 needs to prevent incoming Telnet/SSH attempts from hosts in R2’s LAN subnet, which is 20.20.20.0/24. R1 can use a standard ACL (as is shown in Example 1), with a deny command matching all hosts in that subnet (access-list 1 deny 20.20.20.0 0.0.0.255. Then to permit all other traffic, which completes the requirements, the ACL ends with access-list 1 permit any.
R2’s ACL follows a similar line of thought. It first denies all packets with a source address from within subnet 10.10.10.0/24 (access-list 1 deny 10.10.10.0 0.0.0.255). It then permits all other packets.
I love these blogs, Wendell!
🙂
Thank you Wendell I love jour blog
i just want to say thank you Mr Odom for the resources like this. I love this Blog and all of your books. Those resources really helped me a lot in my CCNA studies.
Hi dell,
Thanks for letting me know! Much appreciated.
(Wen)dell
Hi Mr Wendell,
These are really great labs. Just had one question. If we enabled on the L3 interface, would it not be better instead of going through the router processing as in your e.g. Also from exam perspective does my point gives more score. Just a thought. Appreciated your work. Cheers.
Hi Mansoor,
First question: I can see arguments for both options working well. I personally think that the advantages of filtering at the VTY outweigh the advantages of filtering on the L3 interfaces. It’s much easier to do correctly using the VTY. More likely to pass a security audit.
As for the exam and exam points, I don’t think you get an advantage. It’s not a design test where you’re weighing design alternatives and then configuring them. It’s a bit more straightforward than that.
Hope that helps! Snd glad you like the labs.
Wendell
Thanks for the lab!
After configuring and testing the setup I found a funny trick: I could still log into R2 from a pc that resides in the 10.10.10.0/24 network by first logging into the R1 router and from there into R2.
I know that this is just an exercise but I guess there is a network out there with this kind of configuration mistake!
This is a great point. There are definitely security concerns with the “any” parameter. Change your ACL to permit 10.10.10.0 0.0.0.255 and you have eliminated this vulnerability, at least from R1 to R2.
Hmm, I did it a little differently. I used the following:
R1
access-list 1 permit 10.10.10.0 0.0.0.255
access-list 1 permit 192.168.1.0 0.0.0.255
R2
access-list 1 permit 10.10.10.0 0.0.0.255
access-list 1 permit 192.168.1.0 0.0.0.255
GJM – I’m good with it. In real life, just be careful of that implied “deny any” at the end of the list, as that might filter more than you wanted to filter.