This is a Canonical Question about the privacy of Server Fault and the needed detail to get an answer from the community.

Is there any information other than a password that would be considered a security threat?

I am primarily interested in knowing what could compromise the security of a server, rather than the security of intellectual property.

For example, it seems to me that it would be a security threat to include both my username and domain name.

If I post a large amount of output, it is not possible for me to know what nefarious uses it could be put to, especially if data were combined from across multiple posts.

migrated from serverfault.com Nov 16 '10 at 22:57

This question came from our site for system and network administrators.

  • 6
    Keep in mind that these sites are very well spidered by search-engines, and whatever you post will be very discoverable. – sysadmin1138 Nov 16 '10 at 22:54
  • I agree, assume that any information you divulge to Q/A website is stored somewhere in perpetua. – Dave Drager Nov 17 '10 at 13:54
  • 4
    @Dave Drager, you are almost right, just strike out 'Q/A'. Anything you post anywhere is probably stored somewhere. – Zoredache Nov 17 '10 at 17:46
up vote 47 down vote accepted

Provide as much information as necessary to answer the question. You may obfuscate anything that may be sensitive, but be careful of obfuscating too much. These may occasionally come into conflict...

Server Fault does not require you to obfuscate anything. These guidelines are intended to keep you out of trouble and to help you get better answers to your questions.


Passwords

Never post passwords, API keys, or any other credential that can be used for authentication or authorization.

If you accidentally post such data, do the following:

  1. Consider the credentials compromised and have them revoked or changed immediately. Do not skip this step! API users may retrieve the original revision of your post before you are able to edit it, and your password may then be out on the Internet forever.
  2. Edit the post, removing the credentials and other sensitive information.
  3. Flag the post for moderator attention. Moderators can then redact the sensitive information from the post's revision history.

User names

If the content of the user name is itself sensitive, consider replacing it with something generic.


Host names and domain names

If your domain name is sensitive, replace it with an example domain name. The example domain names are specified in RFC 6761, section 6.5:

  • example.com
  • example.net
  • example.org
  • example TLD and any subdomain thereof

When referring to Microsoft products, it may also be acceptable to use Microsoft's example domain names, contoso.com and fabrikam.com.

Never replace your domain name with a domain name which does not belong to you or your organization and which is not reserved for use in examples.

NB: In many cases it may be necessary to know the actual domain name in order to answer your question. This is especially true if your question relates to setting up or reconfiguring the domain name itself. An experienced community member will typically comment on your question if this is the case.


IP addresses

Never obfuscate private IP addresses. This only leads to confusion and makes it more difficult to answer your question. Private IP addresses are those defined in various RFCs:

  • 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 defined in RFC 1918
  • 100.64.0.0/10 defined in RFC 6598
  • fc00::/7 defined in RFC 4193

You may obfuscate public (globally routable) IP addresses, if doing so you must use an IP address range reserved for that purpose (see below). Never obfuscate using IP addresses not controlled by you or your organization and which are not reserved for use in examples or documentation.

The following IP address ranges can be used for obfuscation, examples, and documentation. These should be used only to obfuscate public IP addresses:

  • 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 defined in RFC 5737
  • 2001:db8::/32 defined in RFC 3849

NB: In some cases it may be necessary to know the actual public IP address(es) in order to answer your question. An experienced community member will typically comment on your question if this is the case.


Service providers

If your question involves resources purchased or leased from a third party service provider, do mention the names of the providers involved. Many such providers have their own idiosyncrasies and this information makes it possible to answer your question in these cases.


Business information

When asking questions, do not mention the name of your company unless it is necessary to understanding the question.

When answering questions, do mention the name of your company if you are recommending or advising regarding your company's product or service. You are required to disclose your affiliation if one does or appears to exist.

  • I see that that there is no mention of link-local addresses. I can imagine that some people want to obfuscate those if they have an embedded MAC address. Would fe80::200:5eff:fe00:5300/120 be the correct range to use if somebody chose to obfuscate a link-local address? Based on my reading of RFC 7042 it would be. But I found no example of anybody doing so, so it might be that I am not reading it correctly. – kasperd Jan 11 '16 at 2:25
  • 1
    @kasperd While MAC addresses are supposed to be unique, they aren't actually so in practice. There are any number of instances of non-unique MAC addresses out there in the wild. And as they're only visible on a particular link, there's little reason to keep them private. Any scenario I can think of that would realistically require MAC addresses to be obfuscated involves state-level actors that most people on SF will not be worried about anyway. – Michael Hampton Jan 11 '16 at 2:41

Since this question's floated up to to the top of the front page, I'm going to give my contrarian answer, which is: obfuscate nearly no technical data in your question.

Michael has a point inasmuch as some data are supposed to be secret, and you shouldn't post them. Passwords, SSL secret keys (don't laugh, it's happened, though I can no longer find the post), pre-shared keys of all types,: all these are supposed to be secret, and you shouldn't post them. But usernames? Post them; if your security is dependent on keeping the usernames secret, it's bad security. Domain names? Post them. IP addresses? Post them. Mail headers? Post them.

Why do I say this? This question would have taken significantly longer to solve without knowing the address; this question, and this one would have taken significantly longer to solve without the domain name in question. I could quote tens more examples, just from my own canon.

Could they have been solved if those data had been redacted. Yes, of course; but it would have taken longer. Instead of being able to test hypotheses ourselves, we'd've had to guess, and wait for the OP to clarify. In some cases, the lack of redaction helps with the formation of hypotheses in the first place.

When you come to post on SF, you're a supplicant in need of assistance, so anything you can do to make it easier for other people to help you is a good thing.

I'm sorry if you don't want to embarrass your company, or if there's some idiot local security-through-obscurity policy that forbids you to disclose anything, down to the price of the coffee in the company machine. You've got a problem, or you wouldn't be posting here; don't be so discourteous to the pool of potential helpers as to make their lives deliberately difficult.

Obfuscation in an answer is different. There, you're trying to help. It may be that your answer is less helpful with redaction, but that's your call as a helper. The community will judge by voting, as it should.

  • 1
    I'm pretty sure I covered this, but it always helps to reinforce the point. – Michael Hampton Sep 28 '14 at 12:31
  • 2
    I wouldn't disagree - I thought your answer excellent as regards things that ought to be secret. I might just go further than you in suggesting that everything that doesn't need to be secret, be public. – MadHatter Sep 28 '14 at 20:05

Hide your kids, hide your wife...

But seriously...

  • Hide/mask your IP address. You don't want to be giving attackers your exact address. At least the first 2 octets... x.x.0.1
  • Hide/mask your domain name (use example.com or whatever you want to indicate the domain)
  • If you work for a small organization, and depending on your industry, giving your exact network setup, vendor info, version information and security failings probably isn't a good idea.
  • Obfuscate usernames - replace with alternatives.

Ideally, give only the information needed to answer the question. Exact information is not needed in just about all cases.

  • 1
    +1 That last sentence pretty well sums it up. – John Gardeniers Nov 18 '10 at 0:00
  • 9
    Whilst that's true - indeed, a truism - it's also useless because anyone posting a question here doesn't fully understand what's going on. If they didn't, they wouldn't be posting. And because their understanding is imperfect, their judgement on what is and isn't needed to answer the question isn't reliable, so the advice can never - by definition - be properly acted upon. With the exception of very few genuinely sensitive data, all of which Michael covers in his answer above, being fully open and honest is the fastest way to get an accurate answer. – MadHatter Jan 14 '14 at 14:08

Work on the "need to know" principle. If there's anything that could at all be considered sensitive that others don't need to know in order to answer the question then there's no reason to include it. If you don't know whether or not a particular piece of information is sensitive please give that some very serious thought before posting anything. A critical part of our jobs as professional IT people is understanding security.

Before posting a large amount of output consider whether or not that will be beneficial to the question. Perhaps you should post just a small extract from that output instead. From what I've observed, questions with large postings like that seldom get very good responses anyway. Too much noise, not enough real content.

It kinda depends on the question, and you as a person who posts on the Internet.

I don't usually mention who I work for, specific server names, or IP addresses in answers or questions, but my userid is not common, and I believe only used by me. It can be pretty easily linked to where I work, my real name, and tons of detail. If someone evil person was bored enough they get a lot of information about me and make a lot of semi-informed guesses about the networks I support by reading through the thousands of posts by me here and on the rest of the Internet. Since I answer/ask a lot of questions, trying to hide some details probably is a waste of effort since someone can find out the information anyway.

I think it is reasonable to mask or hide some information. Perhaps using example.(org|com|net), or hiding an IP by changing the first 1-2 octets to a RFC1918 address 8.8.8.8 -> 10.8.8.8 or 192.168.8.8. Just replacing it with a like 8.8.8.8 -> *.*.8.8 may hide some useful information. If you want good answers, and also want to mask away critical details it is very important that you provide enough details so we can help. I have seen routing questions where the poster masked away the last two octets 10.10.*.* making the network nearly impossible to understand and so making the question unanswerable.

If I was talking about something that was internal to my network that could not be tested externally I doubt I would provide much detail that would expose the network I was working on. But I would try to provide masked information to make sure that people potentially answering my question where able to get an accurate understanding of the situation so they could provide the best answers.

When I am asking questions I usually only try to provide details that are directly relevant to the question. If I had a question about DNS, I might be tempted to mention the domain that I was talking about since other users could actually submit queries and provide more helpful answers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .