[LAB] AAA concepts

Taken from the exam blueprint, the goals for this lab are the following:

2.2.b Configure administrative access on a Cisco router using TACACS+
2.2.c Verify connectivity on a Cisco router to a TACACS+ server

For this lab session I’ll be using:

Ubuntu 19.04 host (10.0.0.15)
Ubuntu 18.04 LTS server running tac_plus (10.0.0.11)
7200 series Router (10.0.0.1)

Configuration

To setup the TACACS+ server I followed this guide by Keeran Marquis. His guide is for Ubuntu 14.04 LTS but I can confirm it worked fine for 18.04 LTS.

Below is the server configuration file. The first line is where the accounting logs are stored. Next is the encryption key that’s used between the Router and the TACACS+ server. They have to be identical on both. Following that I’ve created two users. Will and test. Will is a member of the admin group. As TACACS+ implicitly denies all commands I’ve had to add the command ‘default service = permit’. Along with setting a privilege level of 15 this will give whoever is a member of the admin group access to do anything. The test user is a member of the read-only group. Even though whoever is in this group has a privilege level of 15 what they can do with it is very restricted.

After verifying that the TACACS+ server is operational and it’s able to reach the Router it’s time to configure the Router.

Router configuration

In the event that the TACACS+ server is unreachable I still need to be able to get onto the device. Below are two users that are setup locally on the Router.

After thoroughly testing local access enable AAA globally with the following command:

R1(config)# aaa new-model

Configure the TACACS server settings:

R1(config)# tacacs server tacsrv
R1(config-server-tacacs)# address ipv4 10.0.0.11
R1(config-server-tacacs)# single-connection
R1(config-server-tacacs)# key testing123
R1(config-server-tacacs)# exit

* the single-connection command will maintain a single TCP connection for the duration of the session.

Configure the first part of AAA, Authentication.

R1(config)# aaa authentication login default group tacacs+ local-case
R1(config)# aaa authentication login NOAUTH none
R1(config)# aaa authentication login httpAUTH group tacacs+ local-case
R1(config)# line con 0
R1(config)# login authentication NOAUTH
R1(config)# exit
R1(config)# ip http authentication aaa login-authentication httpAUTH

The first three commands are defining 3 different method lists. The first one being default. The default list is automatically applied to all login attempts (console, vty, aux, and http sessions) unless explicitly stated. I’ve provided an example below. You can see the VTY lines have not been given a login authentication method list so the default is used.

If you’re connecting to the Router via its console port the authentication method list is NOAUTH which has a value of none, meaning no authentication required. The last method list is specifically for ip http. So say for example you were attempting to use CCP on port 80, the custom method list of httpAUTH would be requested in that instance.

In the event that the TACACS+ server isn’t reachable the fall-back option is local-case. That will use case-sensitive local access for authentication.

That’s authentication complete, next up authorisation. Before enabling authorisation ensure that you have a local user that has full access rights otherwise you’ll lock yourself out!

R1(config)# aaa authorization exec SRVEXEC group tacacs+ local
R1(config)# aaa authorization commands 15 SRVCMD group tacacs+ local
R1(config)# aaa authorization config-commands
R1(config)# line vty 0 1869
R1(config-line)# authorization exec SRVEXEC
R1(config-line)# authorization commands 15 SRVCMD

The above commands add authorisation for access to the EXEC shell (the CLI) and authorisation for access to privilege level 15 and global configuration commands. Both authorisation lists are then applied to the vty lines. Similarly to the authentication method lists if the TACACS+ server isn’t reachable it will fall back to the local database.

Finally onto accounting. AAA accounting offers the following services that can be kept track of:

system tracks system-level events such as reloads.
network tracks network-related service requests.
exec tracks EXEC shell sessions.
commands tracks all commands at the specified privilege level.

R1(config)# aaa accounting exec ACCEXEC start-stop group tacacs+
R1(config)# aaa accounting commands 15 ACCCMDS stop-only group tacacs+
R1(config)# line vty 0 1869
R1(config-line)# accounting exec ACCEXEC
R1(config-line)# accounting commands 15 ACCCMDS

The first command will send an accounting record at the start of an administrative access session to the device’s EXEC process, and another accounting record to be sent at the end of the session. A second command is added that causes an accounting record to be sent for every privilege level 15 command and every configuration mode command that is entered by the user. Both accounting lists are then applied to the vty lines.

Testing and verification.

On the TACACS+ server I setup two users. will and test. Both are using the same password lab123 (the first is hashed using des and the second is hashed and salted using MD5). Using the following commands we can test both:

R1#test aaa group tacacs+ will lab123 legacy
Attempting authentication test to server-group tacacs+ using tacacs+
User was successfully authenticated.

R1#test aaa group tacacs+ test lab123 legacy
Attempting authentication test to server-group tacacs+ using tacacs+
User was successfully authenticated.

Below is a screenshot highlighting the successful SSH connections using both will and test user accounts. It also shows the accounting log file that confirms the successful connection and disconnection from both users and how long they were connected for.

Here’s an example of the user test attempting to run some show commands that it’s not authorised to use:

Next I’m now logged in as an administrator that’s making changes. Here’s the output of the accounting log file showing changes that have been made:

For debugging purposes the following commands are very useful.

R1# debug aaa authentication
R1# debug aaa authorization
R1# debug aaa accounting
R1# debug tacacs

Conclusion

Having the ability to centrally manage users, limit access and also view any changes that have been made really highlights the benefits of having AAA. This was a fun lab to complete.

 

[LAB] Secure Copy

Objective:

2.1.e Use SCP for file transfer.

For this lab session I’ll be using:

GNS3
Ubuntu Desktop 19.04
Cisco 7200 series Router

 


Out of the box the 7200 series Router that I’m using doesn’t have any flash or disk space available, but you can add them. Under ‘Configuration’ >  ‘Memories and disks’ an option to add PCMCIA disks is available.

Here they are on boot-up:

Router config:

R1(config)# ip domain-name layerunknown.com
R1(config)# crypto key generate rsa general-keys modulus 2048
R1(config)# username admin privilege 15 secret cisco
R1(config)# aaa new-model
R1(config)# aaa authentication login default local
R1(config)# aaa authorization exec default local
R1(config)# ip scp server enable

Host machines are getting IP addresses via DHCP from the Router. The Router’s address is 10.0.0.1.

Testing and verifying SSH.

You might be wondering why I’m specifying the cipher. If I don’t I’ll receive the following error:

Unable to negotiate with 10.0.0.1 port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

Lets actually check the fingerprint. On the Router enter the following command:  show ip ssh

Copy from ssh-rsa to the end of the string and put it into a file. Remove any unnecessary white space and newlines and save the file, I saved it as test.pub.

Then execute the following command: ssh-keygen -lf test.pub

-f filename
Specifies the filename of the key file.

-l Show fingerprint of specified public key file. For RSA and DSA keys
ssh-keygen tries to find the matching public key file and prints its fin‐
gerprint. If combined with -v, a visual ASCII art representation of the
key is supplied with the fingerprint.

Comparing the output from that command to the RSA fingerprint we received when making the initial SSH connection we can see they match.

We’ve verified we’re connecting to the right device and that SSH is working. Lets test the PCMCIA disks work.

copy running-config disk0:

dir disk0:

Now for SCP.

I’ll first copy the running-config we just saved to disk0 from the router to my local machine. The following commands are being executed from the Ubuntu host.

scp -c aes256-cbc admin@10.0.0.1:disk0:/running-config /home/admin/Desktop

This command is logging into the remote host at 10.0.0.1 with the username admin then copying the file ‘running-config’ from disk0 and placing it onto my Desktop.

Then I’ll test the other direction by uploading test.pub from my local machine to disk0 on the router.

scp -c aes256-cbc ~/Desktop/test.pub admin@10.0.0.1:disk0:/test.pub

See the results in the screenshot below:

Using the dir and more commands on the router we can verify this.

SCP lab complete.

Now that we’ve done that, here’s the bad news. Recently, multiple SCP vulnerabilities have been discovered. See here.