Date: Sun, 31 Dec 2000 14:15:59 -0800
From: Stephen Stuart <stuart@mfnx.net>
To: jlewis@jasonlewis.net
Cc: nanog@merit.edu
Subject: Re: RFC1918 addresses to permit in for VPN?
Only that private addressing helps ensure that your machines don't
have access to the Internet. If you've set up a network where there is
truly no packet path to the Internet such that it wouldn't matter if
your back-end network was numbered in RFC1918 space or not, then it
becomes unlikely that the network in question will be compromised *by
an attacker arriving via the Internet*, and your security does not
depend on RFC1918 addressing. You will have someone walking up to a
switch and plugging in to consider (but that's more a facility
security issue). RFC1918 gives you a place to number hosts without
conflicting with "public" address space, that's all.
Using RFC1918 space also gets you an IP range where the outside world has
no route to it -- Sorry, but no packets are not getting there, ergo no way
to hack.
Assuming various things that should be standard procedure -- dynamic NAT
as opposed to static, blocking source routing, etc.
At that point, just by use of simple routing, you've effectively
eliminated 100% of attacks from the outside, and you only have to worry
about inside. The front door is secure, now work on the back door.
Thus spake <mdevney@teamsphere.com>
Using RFC1918 space also gets you an IP range where the outside
world has no route to it -- Sorry, but no packets are not getting
there,
ergo no way to hack.
...
At that point, just by use of simple routing, you've effectively
eliminated 100% of attacks from the outside, and you only have to
worry about inside. The front door is secure, now work on the back
door.
Being convinced you're secure is the surest way to get yourself hacked.
Perfect security is impossible.
Remember, it's not paranoia when they *are* out to get you.
S
> > Stephen Sprunk, K5SSS, CCIE #3723
:|: :|: Network Design Consultant, GSOLE
:|||: :|||: New office: RCDN2 in Richardson, TX
.:|||||||:..:|||||||:. Email: ssprunk@cisco.com
Using RFC1918 space also gets you an IP range where the outside world has
no route to it -- Sorry, but no packets are not getting there, ergo no way
to hack.
.
.
At that point, just by use of simple routing, you've effectively
eliminated 100% of attacks from the outside, and you only have to worry
about inside. The front door is secure, now work on the back door.
I know that this thread as escalated unrestrained, however this is the
original point that I attempted to make.
...djr...
* mdevney@teamsphere.com <mdevney@teamsphere.com> [20010101 01:51]:
[..]
Using RFC1918 space also gets you an IP range where the outside world has
no route to it -- Sorry, but no packets are not getting there, ergo no way
to hack.
Wanna bet? Just because you are not announcing your 10/8 usage doesn't mean
I can't send packets your direction... *I* control where I send packets
regardless of whether you are announcing the space or not... Think static
routes on my side and several (not uncommon) network topologies where I
control enough of the layer-3 network infrastructure between me and you to
get the packets to your border (say, I'm your customer, transit provider, or
peer..)
Assuming various things that should be standard procedure -- dynamic NAT
as opposed to static, blocking source routing, etc.
Dynamic translations (and NAPT even more than Basic NAT) make things a bit
more inconvienent for me but overall don't make things that much more
difficult than a static translation would be. All I need to know is what
the translated address is that my target is using *now* (as in when I'm
making my move). I don't care what is was before; I don't care what it is
after. And finding out what it is now I'd venture is not going to be very
hard with some simple cross-referencing against HTTP, SMTP, POP3, and the
like logfiles.
At that point, just by use of simple routing, you've effectively
eliminated 100% of attacks from the outside, and you only have to worry
about inside. The front door is secure, now work on the back door.
Some "routing" (use of RFC1918 space) and some access-lists. I'd argue that
the RFC1918 space has nothing to do with it since you could just as well
assign public IPs to the to-be-protected-hosts and combine them with similar
access-lists for the same effect. Heck, you can still run NAT in that
scenario if you like. The RFC1918 (or just unannounced space of any origin)
does not keep me from sending things your way, even if you aren't telling
your BGP neighbors about it..
(damn I really need to catch up on my list reading, this is a week old
thread...*sigh*)
-jr