[FW1] [Fwd: read-rfc1918-for-details.iana.net]

[Chris Brenton <cbrenton@sover.net>]

I'm cross posting this based on Lance's request. I've also left in his
additional commentary as it is information I missed in the original
post.

Cheers,
Chris


-------- Original Message --------
Subject: Re: sec_speak: read-rfc1918-for-details.iana.net
Date: Mon, 26 Apr 1999 16:37:19 -0400 (EDT)
From: Lance Spitzner <spitzner@dimension.net>
To: Chris Brenton <cbrenton@sover.net>

On Mon, 26 Apr 1999, Chris Brenton wrote:

> Many windows based networks running private address space hit a slight
> bump last week. While this was mostly a connectivity issue, it does have
> some security implications.

Dude, excellent posting.  I highly recommend you post this to the FW1
group.  Also, you may want to mention that "whois -h whois.arin.net
192.168.x.x
is not broken, but has always stated "IANA (IANA-CBLK-RESERVED)".  I
noticed people posting that whois was broken too, when it is not.

> 
> The bump had to do with how IANA deals with private address space
> (10.x.x.x, 172.16.x.x - 172.31.x.x and 192.168.x.x). As you know, this
> is the pool of address that anyone can use on their internal network.
> This is because information related to private addresses is not suppose
> to be propagated across the Internet (per RFC 1918).
> 
> Of course compliance with that RFC varies from domain to domain. Most
> people take this to mean you can not route these addresses and they
> should not be directly addressable from outside of the private network.
> Some domains do not even comply to this degree. For example if you
> traceroute across AT&T's backbone after 5:00 PM you'll see a number of
> 172.30.x.x subnets appear. 
> 
> What is even more wide spread, is the propagation of private address
> info via DNS. Consider the following:
> 
> You have a WINS server which attempts to do a PTR lookup on a private
> address host
> The DNS query is forwarded to the domain's ISP
> The ISP does not have records for this address space so the request is
> forwarded to the root servers
> 
> Up till last week, the lookup would simply fail. As of last week
> however, the root servers started returning
> "read-rfc1918-for-details.iana.net" as the host name which uses this IP
> address.
> 
> The connectivity implications are obvious. If I'm doing the lookup in
> order to verify a host name, that verification has just failed (unless
> of course the host is really named read-rfc1918-for-details.iana.net ;).
> This brought down connectivity for a very large number of sites. So many
> in fact that IANA was forced to reverse this setup and go back to giving
> no response. What I find funny is that I have not seen a single news
> feed pick up on this.
> 
> The security implications is that the systems are leaking internal
> network info out onto the Internet. For example all an ISP has to do is
> review their logs and they could build a pretty accurate map of your
> internal network. Kinda defeats some of the purpose of NAT. ;)
> 
> This problem is going to return. From what I here the DNS entries will
> be repopulated in a couple of months. Last week's change was announced a
> year ago, but not many people clued in. If you got whacked, consider it
> a wake up call. ;)
> 
> The reason for the change is performance. The root servers are taking a
> beating from people who are incorrectly sending queries for private
> address space. 
> 
> So how do you prevent problems? By setting up authoritative records for
> any private address space you may be using. For example, if you are
> using 192.168.1.0 for your internal network, you need to setup an
> internal DNS server which thinks its authoritative for the 192.168.1.0
> subnet. You also need to point all of your internal clients at this DNS
> server. This will keep you from leaking out private address info as well
> as keep you from breaking when the IANA does their thing again. 
> 
> Cheers all,
> Chris
> -- 
> **************************************
> cbrenton@sover.net
> 
> * Multiprotocol Network Design & Troubleshooting
> http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet
> * Mastering Network Security
> http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet
> 
> To unsubscribe from this list, send mail to majordomo@geek-speak.net with "unsubscribe security_speak" in the body of the message.
> 

Lance Spitzner
http://www.enteract.com/~lspitz/papers.html
Internetworking & Security Engineer
Dimension Enterprises Inc


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================