Automated and Secure Configuration Backups of Cisco Routers and Switches with Auto Archive

Ivan Brens
5 min readJul 3, 2017

--

Before we get started, I want to define the terms in the title to accurately set expectations. By secure, I mean using SCP/SSH and by automated, I mean daily configuration backups that do not require admin intervention.

Disclaimer: This is not a comprehensive tutorial on how to secure your devices.

Why

FTP and TFTP are insecure transport protocols. Meaning, if the transfer is captured with a packet sniffer, one could view the data transferred in clear text!

What You Need

  • A pre-configured Linux machine running sshd
  • Cisco router or switch that supports cryptographic features (image with K9 in the image name) with ssh keys generated

Config

Archiving

Below we configure several neat things. Let me go into the detail of the configuration:

  • First, we configure the archiving path with all the necessary details so that the scp copy does not need to prompt us for anything; the username, password, host, path, and filename.
  • Notice that the path and filename are using variables! ‘$h’ is the configured hostname of the device and ‘$t’ is the time as configured on the device!
  • Next, we enable command logging and specify how many commands should be logged (the last 200), how we should be notified (syslog), and to hide passwords in commands logged.
image for better reference, see below for text version
! Configure Archiving
!
! Start in privileged mode
!
config t
archive

! The path is where the archiving will save the configs to.
! The string will also hold the credentials
!
! example string:
! path scp://<username>:<password>@<linux_machine>://<path_on_linux_machine>
!
path scp://ciscoconfigs:P455w0rd@192.168.1.200://cisco/configs/$h/$h_$t.cisco
! add command logging for the last 200 commands with passwords hidden
log config
logging enable
logging size 200
hidekeys
notify syslog

!
end
!
!
!

One important thing to note here is that the password in the path will remain in clear text in the configuration despite the use of ‘service password-encryption’. I’m not sure why this is… It is a drawback of this implementation, but this is still more secure than transferring the configurations with FTP and TFTP.

Even though my security spidey-senses are tingling with this configuration, there are, however, other ways to further secure this implementation on the Linux side by restricting what this user can do. For example, preventing the user from having an interactive login and only able to execute the command scp at the same time! Refer to “Taking Things a Step Further” below.

Kron

For a long time I didn’t know that kron was supported on Cisco devices, but yes… yes it is… and its awesome! Kron allows us to prepare a set of commands to run in exec mode and perform those on a set schedule. Meaning user exec and privileged exec only, no global configurations, etc.

Below we create a kron policy to save and archive our configuration. We then specify that it should run every night at 10pm. Check it out:

image for better reference, see below for text version
! Configure kron
!
! Start in privileged mode
!
config t
! create the policy with two commands
kron policy-list Config_Backup
cli write memory
cli archive config

!
exit
!
kron occurrence Config_Backup at 22:00 recurring
policy-list Config_Backup

!
end
!
!

Verification

Now that all the configuration is in place, lets verify that its working as intended!

Switch#archive config
Writing /cisco/configs/Switch/Switch_-Mar--1-01-42-43.252.cisco-0 ! Sink: C0644 1853 Switch_-Mar--1-01-42-43.252.cisco-0
Switch#Switch#show log | i %PARSER-5-CFGLOG_LOGGEDCMD: User:ivan
*Mar 1 01:21:35.297: %PARSER-5-CFGLOG_LOGGEDCMD: User:ivan logged command:interface GigabitEthernet0/1
*Mar 1 01:21:46.949: %PARSER-5-CFGLOG_LOGGEDCMD: User:ivan logged command:description Testing archive logging
*Mar 1 01:21:53.887: %PARSER-5-CFGLOG_LOGGEDCMD: User:ivan logged command:shutdown
*Mar 1 01:22:04.406: %PARSER-5-CFGLOG_LOGGEDCMD: User:ivan logged command:interface GigabitEthernet0/2
*Mar 1 01:22:09.733: %PARSER-5-CFGLOG_LOGGEDCMD: User:ivan logged command:description more testing
Switch#show archive log config all ... 24 3 ivan@console |interface GigabitEthernet0/1
25 3 ivan@console | description Testing archive logging
26 3 ivan@console | shutdown
27 3 ivan@console | interface GigabitEthernet0/2
28 3 ivan@console | description more testing
Switch#show kron schedule
Kron Occurrence Schedule
Config_Backup inactive, will run again in 0 days 20:15:28 at 22:00 on
Switch#

Taking Things a Step Further

This is all cool and all, but can we implement it in production?

Ideally, you’d want to secure this a little bit more before you consider deployment in production. Lets take a look at what we can do to further secure this.

Securing the user account

One concerning part of this configuration is the user account that the devices use to copy the configs over. Despite the fact that ‘service password-encryption’ is enabled and “system passwords” are not supposed to be in clear text, these credentials are:

Like I mentioned before, I’m not sure why this is, but its not as bad as one may think. In order to view these credentials, the attacker would need to have access to the router configuration which is encrypted on transport. They would either need access to the device or where the configuration files are stored. If that is the case, you have bigger issues to worry about!

So how do we lock this down?

Enter rssh:
http://rpm.pbone.net/index.php3/stat/4/idpl/26480931/dir/redhat_el_7/com/rssh-2.3.3-2.el7.rf.x86_64.rpm.html

rssh is a restricted shell that only allows specific commands to be run with a non-interactive session! We can configure this to only allow scp. What does this mean?

No bash, no shell, no interactive access, just scp!

Configuration of rssh is out of the scope of this article, but this is what you get when you try to login when it’s configured:

rssh

This account can still scp configuration files just fine!

The Linux Machine

Security is never comprehensive and is only as strong as its weakest link. Its pretty silly if we take all the precautions to secure the transfer but leave destination of the transfer insecure.

Securing the Linux machine is outside of the scope of this article as well, but I’ll point you in a good direction.

To learn more about good security practices with Linux, check out the Center for Internet Security (CIS), specifically their benchmarks for different systems:

Wrap up

Managing many devices securely is always a challenge. This is one of the optimizations that makes my life easier, I hope its useful to you.

--

--

Ivan Brens

A Network Engineer that loves to learn new and interesting things. Certifications include: Linux+, CCNP, OSCP, and others.