Community Pick: Many members of our community have endorsed this article.
Editor's Choice: This article has been selected by our editors as an exceptional contribution.

How to sanitise a Cisco config for Experts Exchange

ArneLovius
CERTIFIED EXPERT
Published:
Updated:
When posting a question about a Cisco ASA, Cisco Router or Cisco Switch, it can aid diagnosis if a suitably sanitised copy of the config is provided. It is much better to leave as much of the configuration as original as possible, as it could be that there is an error that you have not seen that is "corrected" by a change that you make to it in order to sanitise it. To aid intelligibility any changes to the config to sanitise it should be consistent throughout the config.

This tutorial is attempting to be as generic as possible across the many flavours and release levels of CatOS, IOS and PIX/ASA. If you are unsure about whether something should be replaced/redacted in the configuration then apply the question of "does it contain any information that is specific to the device/site/installation" is usually a good arbiter.

There are parts of the config that should be replaced and there are areas that should be redacted, unless your question is about the format or syntax in which case this might be the only part of the config that is required.

It is much better to mark something as redacted rather than just remove it, this is so that an Expert reading through the config will not be distracted by what appears to be a missing or syntactically incorect part of the config. To mark someing as redacted, it is better to do something in the form of <redacted LDAP bind> than just <redacted>. The exact form is not important, but it should be consistent throughout the config.


The parts that should usually be replaced

Public IP addresses on the device
Domain Names
Host Names
Trustpoint Names

Public IP addresses

Public IP addresses are defined as an addresses that can be routed to through the Internet. If you are using a device internally, then you may have Private IP Addresses on both the inside and outside interfaces, likewise, you may have a device that has Public IP Addresses on both the inside and outside of the device. Public IP Addresses can usually be replaced with an alternative address as long as it is apparent that the address has been replaced. The replaced addresses should be consistent through the config. Replacing the first two octets of any IPv4 external addresses is sufficient to sanitise it, if if you have multiple non contiguous external subnets, then use different replacements for each. Depending on your internal network numbering, I would suggest replacing the first two octets of external addresses with RFC 1918 private addresses such as 10.<1-255>, 192.168 or 172.16. that do not overlap with your internal addresses.

If you are using private addresses internally, then please leave them unchanged as they do not contain any locally identifying information.

Once this is completed it allows somebody to read through the config and follow the traffic flows.

If you are using IPv6 addresses, then you should replace the prefix with 2001:DB8::/32 as per RFC 3849

Domain Names

Domain Names can usually be replaced with an alternative Domain Name as long as it is apparent that it has been replaced. The replaced Domain Names should be consistent through the config

Host Names

Like Domain Names, Host Names can usually be replaced with an alternative Host Name as long as it is apparent that it has been replaced. The replaced Host Names should be consistent through the config

Trustpoint Names

Trustpoint Names should be treated as Host Names.

The parts that should usually be redacted

Certificates
Usernames and Passwords
LDAP bind information
LDAP search information
SNMP community strings
Pre Shared Keys for IPSec, RADIUS and WiFi etc

Certificates

Certificates can contain indentifiable information, and in a worst case scenario would allow somebody to re-use the certificate and impersonate it on something else. The certificate itself should be be redacted, but the trustpoint that contains it should usually be left in place.

Usernames and Passwords

Usernames and Passwords can appear in many places within a config. As well as users defined for management access to the device, they could also be in SNMPv3 configuration, FTP strings and EEM applets etc. Unless your question is about the particular syntax of the command, in which case they should be replaced, they would usually be redacted.

LDAP bind information

LDAP bind information would contain information about the internal LDAP/AD infrastructure. Like Usernamaes and Passwords, unless your question is about the particular syntax of the command, in which case they should be replaced, they would usually be redacted.

LDAP search information

LDAP search information should be treated the same as LDAP bind information

SNMP community strings

SNMP community strings should usually be redacted

Pre Shared Keys for IPSec, RADIUS and WiFi

All Pre Shared Keys should be redacted

After you have gone through the config as above, save it and read through it again to ensure that it a/ remains consistent, b/ still contains the pertinent information that your question is about, and c/ that you have not missed anything.

There are also some very good points from this article, in particular the Never Assume section.
4
9,430 Views
ArneLovius
CERTIFIED EXPERT

Comments (4)

CERTIFIED EXPERT

Author

Commented:
Yes, I'm happy with it
CERTIFIED EXPERT
Most Valuable Expert 2012
Top Expert 2013

Commented:
Arne,

Here are a few suggestions:

- Make a bulleted list of items that should be removed from config files.  This would go well under the heading for that section to introduce/summarize it before explaining it indepth.  If you need help with the formatting of a list, let me know.

-  I'm not sure if this is doable but maybe provide a couple of (junk) examples of addresses that should not be posted and counter-examples of those addresses 'sanitized'.  Again only if this is doable with fake addresses that don't compromise the security of someone somewhere across the world.  Someone who is not a subject matter Expert, might not be familiar with the terms you are using, and would want to know what "external addresses" look like (what defines them/makes them different from addresses you can share?).

- Finally I didn't realize you were going to use so much of my own article.  I think that it actually takes away from your own writing a bit, because a lot of it is not relevant to your topic.

Maybe provide the link, suggest to look at the "Never assumeā€¦" section.  Post a very small amount of text (a couple of sentences max) if you feel it is directly on target and relevant to your article, and summarize some of the key points -  in your own words - stressing issues specific to config files and how authurs and Experts in your topic areas interract (a lot of my article is specific to databases and the database topic areas).  It doesn't even have to be much writing, since you are referring them to that section.
CERTIFIED EXPERT
Author of the Year 2011
Top Expert 2006

Commented:
"Yes" vote above.

Great advice. I sometimes shudder when reading the information publicly posted here and in other forums. Good move on creating this article.

Commented:
Good One ArneLovius..

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.