Cool IPv6 Stuff

Mailman List Mirror (Read Only)
21

I'm sure everyone understands the underlying principle, but I'm constantly
making the point that even the best firewall is not a total security
solution. Forget antivirus, IDS, host authentication, etc., and just look on
the perimeter.

At least four device types lead inside from the DMZ:
   NAT
   Firewalls of various flavors
   VPN concentrators/security gateways
   Rate-limiting anti-DOS devices to protect host-to-host encryption

For small and medium enterprises, these functions might, as an
implementation choice, reside in the same box; NAT is most likely to coexist
with firewalling or VPN concentration. The latter gets a little Zen-ish if
the VPN concentrator acts as a separately addressed proxy anyway.

22

Also, it is good to control the Internet addressable devices on your network by putting them behind a NAT device. That way you have less devices to concern yourself about that are directly addressable when they most likely need not be. You can argue that you can do the same with a firewall and a default deny policy but it's a hell of a lot easier to sneak packets past a firewall when you have a directly addressable target behind it than when it's all anonymous because it's NATed and the real boxes are on RFC1918.

This is patently untrue. Using a firewall such as CheckPoint, which integrates NAT into the object definition, makes it just as likely to accidentally allow traffic to a NAT'd address as it does a real address. Either you are allowing access to the _object_ or you are not.

If you start messing with the NAT table directly then you open up another can of worms- namely additional complexity and a greater opportunity for mistakes.

So really, those who do not think there is a security gain from NATing don't see the big picture.

We see the big picture- we see applications with a ton of extra code to handle NAT- code that may contain mistakes and end up being compromised.

We see firewalls that need more code to handle NAT'd applications- code that contains mistakes and can be compromised.

We see firewall rule sets that are more complicated and make less than if NAT were not involved.

We see security/performance problems that are harder to troubleshoot because we have to dig through a NAT table to figure out which connection is which.

Keep it simple. NAT is a terrible terrible hack- and it's sad that it's become so accepted in the maintsream.

-Don

23

Let's not forget all the NAT boxes out there that are *perfectly* willing
to let a system make an *outbound* connection. So the user makes a first
outbound connection to visit a web page, gets exploited, and the exploit
then phones home to download more malware.

Yeah, that NAT *should* be providing security, but as you point out, there's
that big gap between should and is... :slight_smile:

24

Cool, then I need four of these firewalls, and two Class-C (512) worth of IP
space that works behind my current ISP at no more than $39.95 each (my basic
price for a Dlink, Netgear, etc cable/dsl router with NAT) with no additional
cost to my monthly internet - and I will start switching over networks...

Yes, I am joking, but the point being that _currently_ NAT serves a purpose;
is supported by lots and lots of little "boxes" that customers can plugin,
configure, and be on the "net" quickly and easily without having to know
about all the "firewall" related stuff; and _does_ do all those neat stateful
things for people that have absolutely no interest in knowing about much less
learning how to make work.

While I agree with the principle being discussed, would that many, many, many
more cable in particular and dsl customers of <Insert-Name-of-Large-ISP> had
such NAT boxes installed and maybe the rest of us would not be getting quite
so much spam from hacked cable/dsl/whatever machines...

25

Valdis.Kletnieks@vt.edu writes:

Let's not forget all the NAT boxes out there that are *perfectly*
willing to let a system make an *outbound* connection. So the user
makes a first outbound connection to visit a web page, gets exploited,
and the exploit then phones home to download more malware.

Yeah, that NAT *should* be providing security, but as you point out,
there's that big gap between should and is... :slight_smile:

I will happily (well ...) further concede that NAT does not provide
*absolute* security. Let me be the first to mention that NAT provides
precisely zero protection against: "Hey, kids, just download and
run this .EXE to see a cute cartoon of Santa dancing with a polar
bear" :-).

Jim

26

Sorry, Owen, but your argument is ridiculous. The original statement was
"[t]here's no security gain from not having real IPs on machines". If
someone said, "there's no security gain from locking your doors", would you
refute it by arguing that there's no security gain from locking your doors
that you don't get from posting armed guards round the clock?

DS

27

Well, give the junky little NAT boxes their due. Grubby little home networks running windoze on one or a few computers cause a lot less trouble in the world when there is a junky little NAT box between the house LAN and the big world outside. Better ways to do it? Absolutely! Easier, cheaper and more widely methods that at least squelch a good bit of the crap? Maybe not…

28

Jim Shankland wrote:
>Owen DeLong <owen@delong.com> writes:
>
>>There's no security gain from not having real IPs on machines.
>>Any belief that there is results from a lack of understanding.
>>
>
>This is one of those assertions that gets repeated so often people
>are liable to start believing it's true :-).
>
>*No* security gain? No protection against port scans from Bucharest?
>No protection for a machine that is used in practice only on the
>local, office LAN? Or to access a single, corporate Web site?

Not so. NATing source addresses from multiple source hosts towards the
Internet anonymises the source machines so they can not be 'looked at'
individually.

Additionally, NATing services on separate machines behind a single NATed
address anonymises the services behind a single address.

Obscurity is not security. If you really want to anonymise traffic, then
you've got a lot more work to do than just have all your machines use one IP
address. At any rate, proxies (transparent, if necessary) are a better
option than NAT for hiding source IPs, as they understand the protocol
they're proxying better than your NAT firewall can (unless you build the
proxy into your NAT firewall, in which case all you've done is proxy anyway,
and you can throw the NAT away).

I can think of one counter-example to this argument, and that's
SSL-protected services, where having a proxy, transparent or otherwise, in
your data stream just isn't going to work. In that instance, though, the
SSL is almost always in place to protect some sort of personal information
(CC numbers, passwords, etc) -- in which case you've just identified the
other end of the connection *anyway*, so anonymity is a large, smelly red
herring.

Also, it is good to control the Internet addressable devices on your
network by putting them behind a NAT device. That way you have less
devices to concern yourself about that are directly addressable when
they most likely need not be. You can argue that you can do the same
with a firewall and a default deny policy but it's a hell of a lot
easier to sneak packets past a firewall when you have a directly
addressable target behind it than when it's all anonymous because it's
NATed and the real boxes are on RFC1918.

While "protection from mistakes" is a valid reason, it's a pretty weak one.
There's no shortage of other things in your system (security things, even!)
that don't have NAT to protect them from typos and screwups.

So really, those who do not think there is a security gain from NATing
don't see the big picture.

I would say that those who rely on NAT for security are the ones with the
narrow world-view.

- Matt

29

Valdis.Kletnieks@vt.edu writes:

> > *No* security gain? No protection against port scans from Bucharest?
> > No protection for a machine that is used in practice only on the
> > local, office LAN? Or to access a single, corporate Web site?
>
> Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly
> configured stateful *non*-NAT firewall should be doing for you already.

Thanks for the clarification, Owen and Valdis. We are, of course,
100% in agreement that it is stateful inspection that provides
(a measure of) security, and that stateful inspection can be had
without NAT.

But NAT *requires* stateful inspection; and the many-to-one, port
translating NAT in common use all but requires affirmative steps
to be taken to relay inbound connections to a designated, internal
host -- the default ends up being to drop them. All this can be
done without NAT, but with NAT you get it "for free".

NAPT (terminology from RFC 2663, a product of the IETF NAT Working Group) is what you refer to here. This is the most commonly deployed type of NAT, but far from the only. Cisco calls this PAT, for those who like keeping track of the acronyms. (The NAT WG in the IETF put together that RFC specifically because there were so many things being called "NAT").

Many stateful inspection firewall implementations do their work and optionally do the address translation as part of the same processing. Certainly this is very efficient, since the lookups have already been done.

For end user sites with client machines, NAT boxes do indeed provide the stateful inspection users really should have, and do so at many price points, from the dirt cheap to the feature rich. Some provide for multiple upstreams, load balancing or failing over when upstreams get congested, providing many of the benefits of multihoming, without the overhead. Obviously this is all best used for end users with client machines.

I can't pass over Valdis's statement that a "good properly configured
stateful firewall should be doing [this] already" without noting
that on today's Internet, the gap between "should" and "is" is
often large.

Depends greatly on the vendor. Appliance firewalls will generally provide the same default configuration out of the box, whether NAT is used or not. That's not to say the default configuration is sufficient for operations, but they'll do the basics just as well whether NAT is on or off.

30

But NAT *requires* stateful inspection; and the many-to-one, port
translating NAT in common use all but requires affirmative steps
to be taken to relay inbound connections to a designated, internal
host -- the default ends up being to drop them. All this can be
done without NAT, but with NAT you get it "for free".

Except for the costs of NAT, which it could be argued are, long term, higher
than the costs of just setting up a firewall properly. There's also no
reason why the default policy on a firewall, out of the box, cannot be "no
inbound". It's not beyond the realm of possibility that the UI for the
firewall device could be such that it was hard-to-impossible to turn off the
"no inbound by default" rule.

I can't pass over Valdis's statement that a "good properly configured
stateful firewall should be doing [this] already" without noting
that on today's Internet, the gap between "should" and "is" is
often large.

"In theory, there is no difference between theory and practice. In
practice, there is."

"There should be no difference between 'should' and 'is'. However, there
is."

- Matt

31

Since when are CPE devices 'properly' configured?

32

Date: Mon, 04 Jun 2007 12:20:38 -0700
From: Jim Shankland

If what you meant to say is that NAT provides no security benefits
that can't also be provided by other means, then I completely

What Owen said is that "[t]here's no security gain from not having real
IPs on machines". That is a true statement.

Moreover...

Provider: "We're seeing WormOfTheDay.W32 from 90.80.70.60."

Downstream: "That's our firewall."

Provider: "Chances are you have one or more compromised hosts behind
your firewall."

Downstream: "But we have 150 workstations. How do we find which
one(s)?"

Bonus points for finding downstreams who understand "NIDS", "monitor
port", "state mapping tables", et cetera. :slight_smile:

In the big picture, I submit that NAT *worsens* the security situation.
Of course, the cost falls to "other people" -- a topic that inevitably
launches a protracted thread.

Eddy

33

Date: Mon, 04 Jun 2007 15:22:11 -0400
From: Dave Israel

So you make end devices unaddressable by normal means, and while it
shouldn't give them more security, it turns out it does. No matter
how much it shouldn't, and how much we wish it didn't, it does.

"Hey, this so-called 'DMZ' feature looks handy. Now I can run a server
process... and I'm protected because I'm using a private address!"

The security comes from state, full stop.

Eddy

34

Sure, NAT can’t prevent users from running with scissors, but sometimes it does block the scissors thrown at the back of their neck whilst they are sleeping :slight_smile:

35

Sorry, Owen, but your argument is ridiculous. The original statement was
"[t]here's no security gain from not having real IPs on machines". If
someone said, "there's no security gain from locking your doors", would you
refute it by arguing that there's no security gain from locking your doors
that you don't get from posting armed guards round the clock?

You're argument is equally ridiculous because in order to work the NAT box has to do stateful inspection anyway!

A better statement would be:
"there's no security gain from locking your doors" (NAT), if you have already posted "armed guards round the clock" (Stateful Inspection)

NAT provides protection in the case where you have a stateful inspection firewall that fails open- something that no serious firewall I have ever seen does. If they aren't doing stateful inspection- then they aren't routing at all (or certainly shouldn't be).

-Don

36

Except that's not the argument. The argument would map better to:

There's no security gain from having a screen door in front of your
door with a lock and dead-bolt on it that you don't get from a door
with a lock and dead-bolt on it.

I posit that a screen door does not provide any security. A lock and
deadbolt provide some security. NAT/PAT is a screen door.
Not having public addresses is a screen door. A stateful inspection
firewall is a lock and deadbolt.

Owen

37

Jim Shankland wrote:

But NAT *requires* stateful inspection;

No, NAT does not require this.

Port NAT mapping one IP to many does, but there are other
kinds of NAT.

this lack of precision can lead to nasty results when
clueless middle managers demand things they don't understand
(which is, after all, the way of clueless middle managers.) the
technically minded of us can at least not aggravate the situation
by being sloppy with our use of language.

richard

38

Matthew Palmer wrote:

I can think of one counter-example to this argument, and that's
SSL-protected services, where having a proxy, transparent or otherwise, in
your data stream just isn't going to work.

Not so. Look at: http://muffin.doit.org/docs/rfc/tunneling_ssl.html

S

39

I posit that a screen door does not provide any security. A lock and
deadbolt provide some security. NAT/PAT is a screen door.
Not having public addresses is a screen door. A stateful inspection
firewall is a lock and deadbolt.

This is a fine piece of rhetoric, but it's manifestly false and seriously
misleading.

I have a cluster of Windows machines at my store with no networking security
at all. They're behind NAT/PAT and nothing else. None of them have ever been
broken into. For a screen door, that's a mighty impressive screen door.

I can give you the root password to a Linux machine running telnetd and
sshd. If it's behind NAT/PAT, you will not get into it. Period.

I can give you the administrator password to a Windows machine with file
sharing wide open. If it's behind NAT/PAT, you will not get into it. Period.

The only ways into these machines would be if the NAT/PAT device were
misconfigured, another machine on the secure network were compromised, or
another gateway into the secure network was set up. Guess what? All of these
things would defeat a stateful inspection firewall as well.

Are there things most stateful inspection firewalls can do that NAT/PAT does
not do? Definitely. Are those things valuable and in some cases vital?
Definitely. So why lie and distory what NAT/PAT actually does do? A large
class of security vulnerabilities require the attacker to reach out to the
machine first, and NAT/PAT stops those attacks completely.

Is that enough if there are other attacks that it does nothing to stop?
Clearly not. Does that change the fact that it actually does completely
prevent a large class of serious attacks? No, it does not.

Is a car alarm useless because some professtional theives can disable it? Is
a lock useless because some thieves can pick it? Many exploits only go after
low-hanging fruit, and NAT/PAT stops them.

DS

40

Leigh Porter wrote:

Additionally, NATing services on separate machines behind a single NATed address anonymises the services behind a single address.

Agreed. It can be very useful to not expose the internal topology through address assignment so as to not expose which subnets/desktops/users are accessing certain foreign addresses.

This is an even bigger issue in v6 if your stack exposes the MAC address in its choice of stateless autoconfiguration address, as this then gives away not just your internal topology but the vendor of the machines (or at least the ethernet card maker). One can easily imagine attacks based on knowing that a vulnerable and hard-to-upgrade embedded system (an Internet-fax machine, say) was on a particular subnet.

Matthew Kaufman
matthew@eeph.com