RE: 192.168.x.x oddities

["Burton M. Strauss III" <BStrauss () acm org>]

> -----Original Message-----
> From: Jimmy Brokaw [mailto:hedgie () hedgie com]
> Sent: Monday, June 14, 2004 4:49 PM
> To: security-basics () securityfocus com
> Subject: 192.168.x.x oddities
>
>
> This seems like a stupid question from a non-guru like me, but I've asked
> a couple of the "gurus" I know and gotten nothing but strange looks.
>
> I run a small network at home, using a wireless router to connect to a
> cable modem.  My internal IPs all fall in the 192.168.0.x range, which is
> the only address-space the router is configured to support.  I've got
> authentication and logging, so before anyone says "I bet it's a neighbor
> using your connection," I've verified nobody else is logging in.
>
> My understanding is that the entire 192.168.x.x range is for internal
> networks only (RFC 1918), and unrouteable on the Internet.

Not true.  The RFC 1918 space is not routable on the Global Internet, that
is between ISPs (technically ASNs - Autonomous System Numbers).  But it's
perfectly routable and often is used within an ISP or site.

>  When I run the
> following command, however, I can see several computers:
>
> [computer]$ nmap 192.168.*.* -sP
>
> I get what looks like four computers (in addition to mine), plus some x.0
> and x.255 addresses responding to the pings.  I picked one at random, and
> it appears to belong to my ISP.  Doing a traceroute, I found the packet
> reached its destination at a public (routeable) address, indicating to me
> the machine has two addresses on the same interface.  RFC 1918 states:
>
>    One might be tempted to have both public and private addresses on the
>    same physical medium. While this is possible, there are pitfalls to
>    such a design (note that the pitfalls have nothing to do with the use
>    of private addresses, but are due to the presence of multiple IP
>    subnets on a common Data Link subnetwork).  We advise caution when
>    proceeding in this area.

traceroute works by sending ping packets (ICMP echo-request) with
incremented TTLs and extracting the address from the expired replies.  A
router can properly report either or both of it's interface addresses.

> Am I therefore correct in my assumption that the ISP is routing my pings
> onto their internal network?

Sounds like it.

>  Is this a normal response?

Uncommon but not unheard of.  What may be happening is that your ISP is
running it's own NAT service, to preserve it's own small block of Globally
routable space.  This used to be common when Tier3 ISPs would get a /28 or
/29 from a Tier2 ISP and have to cram all of their customers traffic in
there.  Also it's often used for dialups.

If you can ping to another computer where you can run tcpdump or ethereal,
you should be able to see the address of the 'source' computer in the
packets.  It should be the WAN side of your router.

> It seems like
> there ought to be security concerns here, but I can't nail them down,
> except the assumption that traffic destined for 192.168.x.x addresses may
> not be filtered as well (or at all), since it may be assumed it originated
> from within the internal network.

Not really.  The responsibility lies on both heads at the peering points,
not to send out RFC1918 traffic and not to accept it.


-----Burton




---------------------------------------------------------------------------
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off 
any course! All of our class sizes are guaranteed to be 10 students or less 
to facilitate one-on-one interaction with one of our expert instructors. 
Attend a course taught by an expert instructor with years of in-the-field 
pen testing experience in our state of the art hacking lab. Master the skills 
of an Ethical Hacker to better assess the security of your organization. 
Visit us at: 
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
----------------------------------------------------------------------------