Re: Future of pf / firewall in FreeBSD ? - does it have one ?

From: Cy Schubert <Cy.Schubert_at_komquats.com>
Date: Tue, 29 Jul 2014 06:20:04 -0700
In message <CAN6yY1uHJn4xA-5zFr4fZez3FyXi7tT0LmhyR8yWkqG7k1A+=A_at_mail.gmail.c
om>
, Kevin Oberman writes:
> On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed <darrenr_at_freebsd.org> wrote:
> 
> > On 27/07/2014 4:43 AM, Cy Schubert wrote:
> > > In message <53D395E4.1070006_at_fastmail.net>, Darren Reed writes:
> > >> On 24/07/2014 1:42 AM, Cy Schubert wrote:
> > >>>>> But, lack of ipv6 fragment processing still causes ongoing pain.
> >  That'=
> > >>>>> s our=20
> > >>>>> #1 wish list item for the cluster.
> > >>> Taking this discussion slightly sideways but touching on this thread a
> > >>> little, each of our packet filters will need nat66 support too. Pf
> > doesn't
> > >>> support it for sure. I've been told that ipfw may and I suspect
> > ipfilter
> > >>> doesn't as it was on Darren's todo list from 2009.
> > >> ipfiler 5 handles fragments for ipv6.
> > > Switching gears and leaving the discussion of ipv6 fragments to mention
> > > nat66. A lot of people have been talking about nat66. I could be wrong
> > but
> > > I don't think it can handle nat66. I need to do some testing to verify
> > > this. I remember reading on sourceforge that it was on your todo list. It
> > > doesn't look like it was checked off as being completed.
> >
> > IPFilter 5 does IPv6 NAT.
> >
> > With the import of 5.1.2, map, rdr and rewrite rules will all work with
> > IPv6 addresses.
> >
> > NAT66 is a specific implementation of IPv6 NAT behaviour.
> >
> > Cheers,
> > Darren
> >
> 
> And all IPv6 NAT is evil and should be cast into (demonic residence of your
> choosing) on sight!


That I don't disagree with, IPv6 NAT makes no logical sense. Having said 
that I've received emails asking about NAT66 specifically. It is on 
people's minds.

> 
> NAT on IPv6 serves no useful purpose at all. It only serves to complicate
> things and make clueless security officers happy. It adds zero security. It
> is a great example of people who assume that NAT is a security feature in
> IPv4 (it's not) so it should also be in IPv6.

Agreed. People think NAT is a security feature (and those same people tout 
the "security" of reverse proxies too). It's a checkbox item.

> 
> The problem is that this meme is so pervasive that even when people
> understand that it is bad, they still insist on it because there will be an
> unchecked box on the security checklist for "All systems not pubic servers
> are in RFC1918 space? -- YES   NO". The checklist item should be (usually)
> "All systems behind a stateful firewall with an appropriate rule set? --
> YES  NO" as it is a stateful firewall (which is mandatory for NAT that
> provides all of the security.

Exactly! That's pretty much what people who know better are saying.

> 
> I say "usually" because the major research lab where I worked ran without a
> firewall (and probably still does) and little, if any, NAT. It was tested
> regularly by red teams hired by the feds and they never were able to
> penetrate anything due to a very aggressive IDS/IPS system, but most people
> and companies should NOT go this route. I have IPv6 at home (Comcast) and
> my router runs a stateful firewall with a rule set functionally the same as
> that used for IPv4 and that provides the protection needed.

Not part of this discussion: I think you need both. Firewalls and IPS with 
IDS.

OTOH using NAT as a means of securing a network is illogical. I worked at 
one place where they would NAT already NATted packets, themselves having 
previously been processed by previous NAT, all for the sake of "security" 
only terribly broke the network to the point there were issues to numerous 
to discuss in a quick reply here.

> 
> So putting support for NAT66 or any IPv6 NAT into a firewall is just making
> things worse. Please don't do it!


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_komquats.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.
Received on Tue Jul 29 2014 - 11:20:07 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC