Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu <eugen () imacandi net>]

On Fri, Apr 18, 2014 at 6:02 PM, William Herrin <bill () herrin us> wrote:

> On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu <eugen () imacandi net>
> wrote:
> > On Thu, Apr 17, 2014 at 11:45 PM, George Herbert <
> george.herbert () gmail com>
> > wrote:
> > > You are missing the point.
> > >
> > > Granted, anyone who is IPv6 aware doing a green-field enterprise
> firewall
> > > design today should probably choose another way than NAT.
> >
> > That's why you have gazzilions of IP addresses in IPv6, so you don't
> need to
> > NAT anything (among other things). I don't understand why people cling to
> > NAT stuff when you can just route.
>
> 4. Defense in depth is a core principle of all security, network and
> physical. If you don't practice it, your security is weak. Equipment
> which is not externally addressable (due to address-overloaded NAT)
> has an additional obstruction an adversary must bypass versus an
> identical system where the equipment is externally addressable (1:1
> NAT, static port translation and simple routing). This constrains the
> kinds of attacks an adversary may employ.
Let's make it simple:

Scenario (A) w/ IPv4
[Internet] -> Firewall Public IP :80/TCP -> DNAT to Internal IP Address
:80/TCP

Scenario (B) w/ IPv6
[Internet] -> FIrewall -> Host w/ Routable IP Address :80/TCP


In scenario (A) I hide a server behind a firewall and to a simple
destination NAT (most common setup found in all companies).
In scenario (B) I have a firewall rule that only allows port 80 to a
machine in my network.


Explain to me how from a security standpoint Scenario (A) is better than
scenario (B).


Defense in depth, to my knowledge - and feel free to correct me, is to have
defenses at every point in the network and at the host level to protect
against different attack vectors that are possible at those points. For
example a firewall that understands traffic at the protocol level, a
hardened application server, a hardened application, secure coding
practices and so on depending of the complexity of the network and the
security requirements.


> Feel free to refute all four points. No doubt you have arguments you
> personally find compelling. Your arguments will fall on deaf ears. At
> best the arguments propose theory that runs contrary to decades of
> many folks' experience. More likely the arguments are simply wrong.
Just because some people have decades of experience, it doesn't mean they
are right or know what they are doing.


Eugeniu