Lab-02A-Securing The Router For Administrative Access

In this lab, we configured routing and connectivity on 3 routers and then secured the devices by manually configuring passwords, users, views, and syslog settings. We tested connectivity and security features throughout. After reverting to basic configs, we used AutoSecure and One-Touch Lockdown to quickly harden the routers, learning that these tools automate much of the security configuration process.

Uploaded by

StanSmith_American

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

0% found this document useful (1 vote)

882 views

Lab-02A-Securing The Router For Administrative Access

Uploaded by

StanSmith_American

Available Formats

Download as DOCX, PDF, TXT or read online on Scribd

You are on page 1/ 2

Lab 2 A: Securing the Router for Administrative Access

Description of what we did in the lab:

In this lab, we worked with 3 routers in a V formation. On each end (R1 & R3, we had a PC attached to test connectivity. After we had configured the interfaces and routing on each router, we tested for connectivity and then began to secure the devices. We first manually configured password encryption, as well as users and secure logins. We then created and compared different administrative views. We secured the IOS image and config to test how it worked, as well as configuring the routers for syslog. Finally, we brought the routers back to the initial basic config and used AutoSecure and One-Touch Lockdown to quickly harden the devices.

Problems and Difficulties:

The initial issue that we had with this lab was in not being able to have access to the equipment when we had planned out lab. Once we were able to gain hardware access, our issues were much more along the normal lines. We had an issue with some of our interfaces not working correcting when we completed our original basic configs, and we quickly discovered that we had applied the configs for R1 and R3 in reverse. To solve this, we moved the cabling from between the routers to save the time of redoing the configurations. We had a hiccup on getting CCP to work, but after changing the CCP shortcut to Run As Administrator, we were able to get it up and running properly.

How we tested our lab:

Once we had the interfaces configured, we use sh ip int bri to verify that the interfaces were up, and then pinged between devices to verify that all static routing was being done properly. We tested that we had correctly configured a 10 digit password requirement by attempting to assign an enable secret password that was 8 digits and received an error that the password was too short. We used sh run to view all of the passwords entered system, and after issuing service passwordencryption we re-issued sh run to verify that the passwords were encrypted. After we had created a local user, we used sh run to verify that the user was present in the configuration. We then tested that the user could login successfully by applying login local to the console line and exiting to the initial router screen. We then tested remote logins by applying login local to the vty and aux lines and telneting successfully into the router. We tested that our brute-force login prevention was working by attempting to login with invalid credentials twice after applying login block-for, and we were not allowed to connect. We verified that the system was in quiet mode by issuing the sh login command. After configuring R1 and R3 for SSH access, we used PuTTY on PC1 to test that we could connect to both routers successfully. Once we had both R1 and R3 configured for different views, we used enable view admin2 to login as Admin2 to verify that the view was configured properly. We repeated this with the view tech to verify that it had a limited access. We then verified the clock settings on R2 with sh clock. We verified that

R1 had associated its clock with the NTP server on R2 using sh ntp associations. We used debug ntp all to view the NTP activity between R1 and R2. After R1 was configured to use a syslog server, we tested that it worked by attempting to authenticate an SSH session with invalid credentials twice which sent logs to our syslog server successfully. After we had reverted to our presaved basic configuration, we used sh run to verify that only the basic information was configured, and used ping on PC-A to ping PC-C to verify connectivity. After completing AutoSecure on R3, we used PuTTY on PC-C to verify that we could remotely connect to R3 through SSH successfully. We then tested that R1 was successfully returned to its basic configuration with sh run and repeated the ping test from PCA to PC-C. After we had completed the Security Audit, we verified that the changes were made by viewing the config by opening View > Running Configuration in CCP. We then checked for differences between the CCP and AutoSecure methods by using SSH to view the config of R3 side-by-side with that of R1. We then issued pings to and PC-A and PC-C to verify that connectivity was not lost.

What we learned:
Through this lab, we were able to dramatically increase our knowledge of the use of AutoSecure and CCP. We learned that you can skip most of the basic configurations for security related items when using either to harden devices as they will do a bulk of the work for you. That said, it is still important to check the scripts that it would want to execute to secure the devices to make sure that there are no errors in the scripts. We also learned more about navigating CCP and the ease of using CCP to administer changes. This will be a great asset in the future when the need to execute the same changes on multiple devices will be needed.