iptables/firewall brainstorming

[Lennart Poettering]

On Sun, 14.06.09 15:09, Chuck Anderson (cra at WPI.EDU) wrote:

> > > I think this is actually a problem that needs solving. We have
> > > several network services that are either installed by default or
> > > might be expected to be part of a standard setup, but which don't
> > > work because of the default firewall rules. The Anaconda people have
> > > (sensibly, IMHO) refused to simply add further exceptions to the
> > > firewall policy.
> > > 
> > > So, what should happen here? Should we leave the firewall enabled in 
> > > these cases* by default and require admins to open them? If so, is
> > > there any way that we can make this easier in some
> > > Packagekit-oriented manner? If not, how should we define that
> > > packages indicate that they need ports opened? Should this be handled
> > > at install time or run time?
> > > 
> > > * The case that I keep hitting is mDNS resolution, which requires 
> > > opening a hole in the firewall
> 
> For the case of mDNS resolution, we should create a nf_conntrack 
> module to track outbound requests and allow the related replies back 
> in.  This case is identical to the Samba browsing case where we 
> created nf_conntrack_netbios_ns [1].  We need a nf_conntrack_mdns too.

No. Absolutely not.

Firstly, mDNS is not a client/server protocol where you just send out
a query and then wait for one response. Instead mDNS is about
minimizing traffic by having an elaborate caching logic. And that
logic is based on learning from other machine's queries, from
gratuitious announcement and goodbye packets. mDNS is genuinly
peer-to-peer and it needs the whole traffic that goes on the mdns
multicast group on the local LAN segment.

Secondly, connection tracking is not a magic wand. It creates almost
as many problems as it solves.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4