Re: Disable ZeroConf: how to ?
On Friday, March 04, 2011 02:48:07 pm Adam Borowski wrote:
> On Fri, Mar 04, 2011 at 04:09:44PM +0100, Olaf van der Spek wrote:
> > On Fri, Mar 4, 2011 at 3:59 PM, Klaus Ethgen <Klaus@ethgen.de> wrote:
> > > In ancient times debian was packaged the way that the administrator
> > > only installed the daemons that he needed. Today many daemons gets
> > > installed by dependencies and gets started without any need.
> > >
> > > If you want to change debian to be ubuntu it would be the time to look
> > > for another distribution that can be used on servers. (unfortunately I
> > > do not know an alternative.)
> > Actually "Ubuntu ships with no open ports on public interfaces" (by
> > default).
> [~]# netstat -ap|grep avahi
> udp 0 0 *:mdns *:* 1622/avahi-daemon:
> udp 0 0 *:45282 *:* 1622/avahi-daemon:
> udp6 0 0 [::]:mdns [::]:* 1622/avahi-daemon:
> udp6 0 0 [::]:58036 [::]:* 1622/avahi-daemon:
> I admit I didn't notice this before, as I would never expect a _client_
> system to have some crap listening by default. And it is world-reachable
> -- am I supposed to ensure the top s1kr3t address
> 2001:6a0:118:0:22cf:30ff:fec3:d4b7 never leaks out? (oops...)
> And why does it open this security hole? To make it slightly easier to
> configure link-local instant messages. Who exactly is going to need that
> these days? The times of local networks disconnected from the world are
> mostly over. You have some non-networked machines here and there, but if
> there's a network of some kind, it almost always is globally connected.
> These few places that do have airwalled networks definitely don't want to
> run link-local chat...
> So, any gain is infinitessimally small, and the risk is real. Even daemons
> coded by most security-minded people that have seen a lot of review do have
> exploitable holes once in a while, so I expect Avahi to fare no better.
> Like, for example, #614785.
This is actually a documented  exception to the general policy of no open
ports (not one I agree with BTW). The rationale is provided at .
What I did was change /etc/avahi/avahi-daemon.conf so it says:
I'm pretty sure that makes it safe (and was easier than dealing with the
dependency issues associated with trying to remove it). netstat -ap|grep
avahi returns nothing on such a system.