[146591] in North American Network Operators' Group
Re: Arguing against using public IP space
daemon@ATHENA.MIT.EDU (Ray Soucy)
Wed Nov 16 15:39:24 2011
In-Reply-To: <26943894.3017.1321469896235.JavaMail.root@benjamin.baylink.com>
Date: Wed, 16 Nov 2011 15:38:16 -0500
From: Ray Soucy <rps@maine.edu>
To: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Can't believe this is still going on. ;-)
NAT does not provide security; it provides utility. It is useful in
many situations, though.
If you are limited in the amount of public IP space you have, then NAT
is one solution to that.
If you want to have a backup connection to the Internet, but don't
want to involve your ISP, or your ISP won't let you talk BGP with them
(often for good reason), then NAT can be a solution to that as well.
IPv6 doesn't have NAT yet, because NAT has a lot of issues. We think
we can do better. The current momentum is behind Network Prefix
Translation (NPT); which rather than re-writing addresses and ports,
rewrites only the network segment of an address, leaving the host
segment unchanged. This is stateless translation and can be
implemented very efficiently to provide utility without limiting
performance in a meaningful way. It will likely be the way that most
small networks get service from more than one provider as IPv6
adoption grows (predictable internal addresses, independent from
provide addressing changes, etc.)
Like NAT, though, it doesn't provide security.
Stateful Packet Inspection (SPI) provides some level of security; and
most NAT devices include an SPI firewall, as state tracking is already
a requirement for NAT to function.
There is no requirement that SPI to use NAT, though.
For the majority of scenarios the failure mode for a firewall running
NAT with private IP address space, and the failure mode for a firewall
not performing NAT, are identical; except that the extra overhead and
complexity required by NAT can actually mean a higher failure rate in
some cases.
It's an absurd generalization (which is not based in fact) that a NAT
firewall will fail closed, and a firewall not using NAT will fail
open.
The problem with the article in the OP -- the thing that rubs most of
this list in the wrong way -- is that it's yet another self-proclaimed
expert telling people that private IP addresses provide security.
They do not.
Most on this list have seen time and time again compromised networks
that sit behind NAT. Almost every time it turns out to be that the
user though they were protected by NAT, and proceeded to not address
security concerns internally. Examples included disabling host
firewalls, not updating systems, and not monitoring activity.
Worse they then proceed to ask you how to find out which host is
compromise because the report only mentioned the IP of their firewall.
I would go as far as to argue that the false sense of security
provided by NAT is more dangerous than any current threat that NAT
alone would prevent.
Firewalls are still a necessary tool; but they don't really provide
the security that people associate with them. It isn't a magic box;
and short of blocking all traffic, they really don't provide
comprehensive security. The article in the OP not only makes it sound
like a magic box; but goes on to say that the magic box isn't what
keeps you safe -- it's the fact that your IP is "private".
So the idea that the answer for a nuclear power plant is to use
private IP addresses and that will address all their security concerns
is just frustrating and ridiculous. The author tried to simplify
things so much that the information become incorrect somewhere along
the way. I for one hope that our nuclear power plants are protected
by more than NAT.
I don't care if they don't use NAT.
Just as long as they address security.
On Wed, Nov 16, 2011 at 1:58 PM, Jay Ashworth <jra@baylink.com> wrote:
> ----- Original Message -----
>> From: "Owen DeLong" <owen@delong.com>
>
>> In this case, a router with NAT is slightly more likely to fail closed t=
han
>> a router without NAT.
>
> "Slightly"? =A0Continuing to assume here, as we have been, that the netwo=
rk
> behind a NAT is *unroutable*, then a NAT router has, IME, *many* more obv=
ious
> possible failure modes which will make the internal network inaccessible =
from
> outside than modes which cause the opposite.
>
> If you're an attacker, targeting a behind-NAT box from the outside, then
> if the NAT's working, you can hit directly any ports that are forwarded t=
o it.
>
> If not, then you have to a) know the private IP of the box and b) be able=
to
> get packets to the last upstream hop with source routing on them and c) t=
he
> box has to have failed (or been configured or built) in such a way as to
> *listen* to source-routing. =A0Those layers may have varying thicknesses,=
but
> there *are* at least 3 more of them, *on top of* "did it fail in a way wh=
ere
> it's listening at all?".
>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0However, a firewall witho=
ut NAT is more likely
>> to fail closed than a router with or without NAT and equally likely to
>> a firewall with NAT.
>
> If it's a firewall that meets your definition of the word, as opposed to,
> say, a shorewall box, a smoothwall box, a pf box, or any of the other 3 o=
r
> 4 dozen packaged linux based firewall routers of which there are *lots* o=
ut
> there. =A0Probably the most common failure more on those is "iptables acc=
identally
> cleared; box routes all packets".
>
> That's one failure to get to that point, insted of 2, 3 or 4. =A0And sinc=
e it's
> human-based a lot of the time, it's probably even more likely.
>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In other words, NAT doesn't r=
eally improve anything,
>> but, the difference between the common failure modes of a firewall
>> vs. a router are worthy of consideration. The infinitesimal advantage
>> of NAT if you use a router instead of a firewall to perform the duties
>> of a firewall is dramatically overshadowed by the costs and damage
>> done by NAT.
>
> Costs already sunk, IME. =A0Damage is a question-begging term here.
>
>> OTOH, routers, being designed primarily to forward packets and having
>> security appliance features added as a secondary capability will, in
>> many cases, address most of these failures by passing packets which
>> would not be permitted if properly configured and/or functioning.
>
> Yup. =A0What I've been saying (or implying) right along. =A0So, in networ=
ks,
> or in seats, take your pick, does anyone have any deployment numbers on
> router-based firewalls vs the other sort, whatever we're calling them?
>
>> Yes, they are identical and NAT makes no meaningful difference
>> to the chances that undesired packets will be forwarded in the event
>> of a catastrophic failure outside of these more common failure modes.
>
> I guess we're going to have to agree to disagree here; our respective
> clients will decide what their opinions on that are.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Baylink =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 jra@baylink.com
> Designer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The Things I Think =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RFC 2100
> Ashworth & Associates =A0 =A0 http://baylink.pitas.com =A0 =A0 =A0 =A0 20=
00 Land Rover DII
> St Petersburg FL USA =A0 =A0 =A0http://photo.imageinc.us =A0 =A0 =A0 =A0 =
=A0 =A0 +1 727 647 1274
>
>
--=20
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
