My path to the CCNA Security certification

Today I earned the infamous CCNA Security certification. It’s exactly a month later than planned but I’m happy I managed to pass it on the first try. From reading other peoples experiences I went into this exam expecting to see some curve balls and I did.

The biggest complaints I’ve heard from people who have sat this exam is that the official certification guide doesn’t adequately prepare you for it. Also, the blueprint isn’t really that helpful either, see this post in Cisco’s learning forum. Daniel, the author of that post gives his perspective on how he found it, it’s eye opening. With hindsight, I agree. Had I simply used the OCG on its own I would have failed this exam. Even with all the material I went through I wasn’t confident during the exam that I had passed.

Below is a list of all the materials that I used to prepare for this:

  • CCNA Security 210-260 Official Cert Guide Premium Edition and Practice Test, ISBN: 9780134077895
  • CCNA Security 210-260 Complete Video Course
    By Omar Santos, Aaron Woland, Mason Harris
  • 31 Days Before Your CCNA Security Exam (Digital Study Guide): A Day-By-Day Review Guide for the IINS 210-260 Certification Exam (eBook, videos, interactive exercises, quizzes)
  • CCNA Security (210-260) Portable Command Guide, 2nd Edition
    By Bob Vachon
  • Cisco CCNA Security 210-260 IINS (references 640-554 A LOT) with Keith Barker
  • Cisco CCNP Security Firewall (CBT Nuggets)
  • Cisco CCNP Security VPN 2.0 (CBT Nuggets)

I started off with the OCG guide and Keith Barker’s 210-260 + 640-554 video series. Then I binged watched the ‘CCNA Security 210-260 Complete Video Course’ By Omar Santos, Aaron Woland, Mason Harris. All video series were a nice complement to the book. The latter might not be on most peoples radar but I highly recommend it.

For my virtual labs I used Keith Barker’s CCNP Security Firewall videos to get up to speed on ASDM. Along with using the 31 Days Before Your CCNA Security Exam and the Portable Command Guide. The digital version of the 31 Days Before Your Exam was surprisingly good. It has quite a bit of video content and a lot of quizzes throughout. Breaking it down into daily chunks and using it in combination with the Portable Command Guide was a nice combination.

Preparing for this exam was tough as some of the technology that you’re required to know about is simply no longer used in the real world. CCP and ACS being two of them. After installing CCP and briefly experimenting with it, I decided not to invest any more time on it and gambled that it wouldn’t show up on the exam. To practice AAA with tacacs+ I used an open source tacacs+ server to do so. I followed this guide to accomplish that using Ubuntu 18.04 LTS. (Cisco’s ISE was not an option that was available to me).

The practice exams that come with the Premium OCG guide was definitely worth the investment and I would highly recommend it if you’re on the same path.

My thoughts on the exam can be summed up in a single word..meh. I didn’t enjoy it, it was a classic Cisco exam in my opinion. Lots of tricky questions that are worded with a lot of ambiguity. Exam aside I really did learn a lot that’s been directly applicable to my job, which is the most important thing.

[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 (
Ubuntu 18.04 LTS server running tac_plus (
7200 series Router (


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
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


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


2.1.e Use SCP for file transfer.

For this lab session I’ll be using:

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
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

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 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

Then execute the following command: ssh-keygen -lf

-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@ /home/admin/Desktop

This command is logging into the remote host at 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 from my local machine to disk0 on the router.

scp -c aes256-cbc ~/Desktop/ admin@

See the results in the screenshot below:

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

SCP lab complete.