What data should one erase from log files, error messages etc., if posting them as a screenshot so as not to expose sensitive information?
To narrow down my question: What should a Linux User be extra aware of hiding if posting screenshots of logfiles, error messages, settings, etc.?
This is a broad ranging question and can probably only be answered with the same sorts of brushstrokes. Ultimately, it comes down to what you, the user, wish to protect.
Fundamentally, you should not post anything that would allow someone else to find it easier to compromise your system, or any of the other connected tools or accounts you use. For this reason you should consider:
The real risk is not necessarily around the individual pieces of information (except, perhaps, in the case of your password—especially if it is one that you reuse, but you wouldn't do that, of course), but in the aggregate that some malefactor could piece together with some time and effort1.
Of course, it is not just about technology or your system; more broadly interpreted, there are other prophylactic measures you may wish to consider.
If you value your privacy, and that of your family, then you would want to take additional steps to ensure that only that personal information that you are comfortable with enters the public domain; for example your geographic location, full legal name, photograph or further identifying information could all constitute material that could be used for identity theft or other nefarious activity.
These other facets of information are unlikely to be included in screenshots or logfiles, but if they are already online through other means, such as social networking sites and the like, then it does increase the surface of vulnerability and, in any event, you should be conscious of that profile, at the very minimum.
1. Standard levels of paranoia being applied...
The basic rule should be to expose only necessary information.
So here the basic security rules apply:
As you can see from many questions asked here - comments will ask for further information, if needed. But it is up to you to obfiscate personal information about individuals or about technical details not needed for this problem.
Adding to the other two (great) answers, it's also good to realize that the process of factor separation, so important for good testing/troubleshooting, is somehow related to the act of removing the sensitive info.
In other words, whenever possible, always try to replicate your problem in a separate environment. Apart from the advantage of ruling out (which often eventually comes out as) irrelevant information and helping you find the root cause, it can also hide your production environment from the lab.
More specific examples:
create and use another testing account (don't forget to delete it afterwards)
if you have enough computing power, keep a testing virtual machine, or even a virtual network at hand and replicate the problem there. This can even give you huge advantage of snapshots.
under these environments, tend to name things like "foo", "bar", "me", "here". In many circumstances this will make it stand out that the information is of little or no value
By experimenting this way (while still respecting what is said in the other two posts), you'll find out that there is much less information that is relevant enough to actually need to be posted in the first place, and in turn that there is much less information that is left to hide.
Just complement the other answers that show you what types of things to anonymize in logs I thought I'd provide a list of tools that can be used to help facilitate anonymizing the logs.
The list is primarily tools for dealing with tcpdump/pcap logs. NOTE: The full list of tools and libraries is here.
Splunk
Splunk is a log file aggregator. Splunk aggregates system logs such as syslog into a centralized location where it can be analyzed. It provides a tool for anonymizing the data it's collected.
Running this tool works as follows:
./splunk anonymize file -source </path/to/filename>
The anonymize functionality is quite configurable, you can read more about it here.
syslog-ng You can actually use the logging framework, syslog-ng, itself to do the annonymization if it's data that should never be in the logs to begin with.
There's an interesting example of this here in this blog post titled: Linux: Anonymize IP logs with syslog-ng.
The idea is pretty simple:
Syslog-NG allows you to rewrite content using regular expressions. Add the following two rewrite rules to /etc/syslog-ng/syslog-ng.conf to replace IPv4 and IPv6 addresses by [REDACTED] and [REDACTED6]. (the regexp for IPv6 hasn't been tested extensively yet).
By using the rewrite and subst functionality built within syslog-ng you can do something like this:
rewrite r_ip {
subst('\b(1?[0-9]{1,2}|2[0-4][0-9]|25[0-5])\.(1?[0-9]{1,2}|2[0-4][0-9]|25[0-5])\.(1?[0-9]{1,2}|2[0-4][0-9]|25[0-5])\.(1?[0-9]{1,2}|2[0-4][0-9]|25[0-5])\b',
"\[REDACTED\]", value("MESSAGE"), type("pcre"), flags("global"));
}
