[Pkg-clamav-devel] Bug#616172: clamav-daemon doesn't listen on ipv6 [::]

[Brian Kroth]

Török Edwin <edwin at clamav.net> 2011-03-03 12:35:
> On 2011-03-03 00:15, Brian P Kroth wrote:
> > Package: clamav-daemon
> > Version: 0.96.5+dfsg-1.1
> > Severity: normal
> > Tags: ipv6
> > 
> > 
> > I'm trying to get clamd to listen over ipv6 (eg ::) but no options I've
> > fed TCPAddr seem to allow for this - they just error out and clamd won't
> > start.
> > 
> > If I just specify TCPSocket it will only listen on 0.0.0.0.
> > 
> > Let me know if you need anything else.
> 
> freshclam supports IPv6, but could you please explain why clamd would
> need IPv6 support?

Sure.  It basically has to do with IPv4 exhaustion.

> You can only safely use clamd inside a LAN, and the LAN has IPv4 anyway.

It was not my intention to make this accessible outside our LAN, though
I could conceive of someone providing a nice load balanced pool for
something like this to at least a larger group.

> Also with IPv6 clamd would be routable from the outside world (because
> your machine would be), and anyone could issue commands to your clamd,
> unless explicitly firewall its port, so listening on IPv6 would be a
> security risk.

I perhaps should have explained that the logs I posted are sanitized for
public consumption.  We don't actually have RFC 1918s and even if we did
that seems like a step backwards.

For our main server subnet, we currently have a /23 of which only about
50 are left.  Like our IPv6 space, they are globally routable, but also
like our IPv6 space they are not publicly accessible.  There are
firewalls in the way, so that's not actually a risk.

Besides, due to the way IPv6 operates, everything on that LAN has
already given itself an IPv6 address (so long as it listens to RAs).
That doesn't necessarily mean that we've associated a AAAA with it.

Given that we have so few addresses left (and with VMs and SSL they are
likely to disappear quickly) and with ARIN's recent announcement aren't
likely to get any more at our level or above us, I have been making an
effort to make all new services we roll out be IPv6 enabled.  That way,
in a pinch, or hopefully before that, we can just yank their IPv4
addresses.  Much of our internal management traffic already flows over
IPv6 (dns, ldap, ntp, imap, smtp, syslog, etc.).

Further, if you really wanted to make them only locally available, you
could setup unique local addressing in IPv6 space.

The point is that the network protocol being used should not imply any
sort of globally accessible service, nor I think should applications
make assumptions about what is a permissible means of establishing a
connection between two hosts.

Hope that makes the case clearly enough for you.

Thanks,
Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-clamav-devel/attachments/20110303/b86a620a/attachment-0001.pgp>