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.
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 running IOS 15.0(2) or greater that supports cryptographic features (image with K9 in the image name) with ssh keys generated
Below we configure several 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.
! Configure Archiving ! ! Start in privileged exec 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 !
There are a couple things to note about the configuration above:
- 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.
- The scp write operation does not create folders, meaning, in the above, a folder named (whatever $h would be) would need to exist on the server.
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.
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:
! Configure kron ! ! Start in privileged exec mode ! config t ! ! create the policy with two commands kron policy-list Config_Backup cli write memory cli archive config ! kron occurrence Config_Backup at 22:00 recurring policy-list Config_Backup ! end ! !
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:
Switch#show run | i password-|path service password-encryption path scp://ciscoconfigs:P455w0rd@192.168.1.100://cisco/configs/$h/$h_$t.txt Switch#
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?
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:
Switch#ssh -l ciscoconfigs 192.168.1.100 Password: Last login: Fri Jun 30 14:06:03 2017 from localhost This account is restricted by rssh. Allowed commands: scp If you believe this is in error, please contact your system administrator. [Connection to 192.168.1.100 closed by foreign host]
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:
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.