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

[Török Edwin]

On 2011-03-03 18:42, Brian Kroth wrote:
> 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.

For someone who knows what is doing there is no risk.
Someone might turn it on by accident (i.e. they mean to bind to all IPv4
addresses but they also bind to IPv6 and their ip6tables is empty...),
so it shouldn't listen on all IPv6 interfaces by default.

So if we add IPv6 to clamd it should not be enabled by default,
so it would probably need a new config option (TCPAddr6?).

Still I don't see much benefit in clamd supporting IPv6, vs binding to
127.0.0.1 and setting up a tunnel where you also get authentication and
encryption for free.

> 
> 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.

I agree that IPv4 and IPv6 shouldn't be treated differently in this sense.
clamd should probably warn if you assign a publicly routable IP address
for it, regardless if it is IPv4 and IPv6.
clamd only makes sense to run on the LAN, and even in that case
accessing it via a unix socket might be better because the protocol has
no authentication in it.

Best regards,
--Edwin