Re: [squid-users] squidclamav: Reduce overhead by omitting request-scanning?

From: H <hm_at_hm.net.br>
Date: Sat, 30 Jun 2012 08:23:50 -0300

Em Sat, 30 Jun 2012 12:51:58 +0200
Felix Leimbach <felix.leimbach_at_gmail.com> escreveu:

> Hi Amos
>
> On 06/30/2012 10:25 AM, Amos Jeffries wrote:
> > On 30/06/2012 7:20 p.m., Felix Leimbach wrote:
> [...]
> >
> > 1) squidclamav is not part of the Squid project. So it is highly
> > unlikely that people here are in a position to edit that programs
> > documentation.
>
> That's why Gilles (author of squidclamav) was CCed ;-)

independent of existence of additional programs _and_ particular
needs, the general purpose of squid is enabling easy http proxying for
rfc1918 networks and browsing performance enhancing by its caching
capability

the funny part is, people add external programs which obviously add
processing overhead and then they ask for reducing this overhead ...

so at the end it is a simple question of profiling: what do you want?
adding a lot of add-ons or running fast?

so be reasonable

>
> > 2) the HTTP world is not limited to downloads. Uploaded files,
> > CONNECT tunnels, media streams and other types of client sent
> > things also need AV scanning to protect servers against infected
> > clients.
>
> You are right of course, there are defense-in-depth scenarios where
> you want to scan outgoing traffic.
> In my case - which I believe is the most common squidclamav use case
> - the purpose is to protect the internal network's users from
> external threats.

that may be a certain option for a corporate network but not for an ISP

Any additional squid options you may have are always overruled by
user's demand for speed, in an ISP environment

but then, if you are administrating a corporate network, why you permit
your people accessing wild sites? I mean, you're shooting yourself in
the leg, permit the access only to sites of corporate interest and
this way you naturally cut any kind of infection and get yourself a
quieter life

Hans

-- 
H
+55 11 4249.2222

Received on Sat Jun 30 2012 - 11:26:44 MDT

This archive was generated by hypermail 2.2.0 : Sat Jun 30 2012 - 12:00:04 MDT