On 7/23/2011 3:32 AM, Török Edwin wrote:
>
> I think that a very simple way of limiting which machines have access to 
> clamd is via an SSH tunnel.
> You bind clamd to localhost on the server, and each client does SSH port 
> forwarding to get access:
> autossh -fN -M 40000 -L localhost:3310:localhost:3310 youruser@clamdserverip
> 
> And if you don't trust the users on either of the machines you can forward 
> the Unix sockets [*]
> CLAMD_FORWARDED_SOCKET=/var/run/clamd-forwarded.socket
> REMOTE_CLAMD_SOCKET=/var/run/clamd.socket
> umask 007
> socat UNIX-LISTEN:$CLAMD_FORWARDED_SOCKET,unlink-early,su=clamav,fork 
> EXEC:"ssh youruser@clamdserverip socat STDIO 
> UNIX-CONNECT\:$REMOTE_CLAMD_SOCKET"
> 
> And then use Unix permissions to control access to the CLAMD_FORWARDED_SOCKET 
> (i.e. clamav group).
> You should also probably use ssh-agent otherwise this'll prompt for the ssh 
> key password everytime someone connects
> 
> [*] Idea based on http://www.debian-administration.org/users/dkg/weblog/68
> 

LOL I thought you said simple.
:-)

I understand what you just said, but a 5 years back, my eyes would have
glazed over, and you would have lost me.
:-)

However, even then I understood that open access to a network service
was a potential problem.

Consider my typical clamd installation.
Clamd's bound to IPs.
Clamav-milter load balancing between all the clamds.
Clamdscan doing daily system scans on each host.
Why clamdscan instead of clamscan?
Because clamd already has the DBs loaded.
Current scan time is 1-8 hours depending on host resources, and amount
of data to be scanned.

Now scale this up to lets say a 16 node scanning cluster.
If/when clamdscan supports load balancing like the milter, I'm sure scan
times would go down.
Which would be really cool.

However, if taking down the scanning cluster is as trivial as properly
using it, that's not so cool.

The client to utilize a Clamav scanning cluster isn't here yet.
When that shows up, people will start hooking the clamd's to the network
to improve efficiency, add redundancy, etc. Doing so is trivial.

The ability to build a scanning cluster is here.
The ability to hose a scanning cluster is here.
That is definitely not so cool.


I tested it in our shop last night with clambake.
It took less than a minute to make the mess, and more than 5 minutes to
fix it.

Scale that up to network size proportions.
:-0


-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

Reply via email to