[squid-users] peek and splice content inspection question

[Stanford Prescott]

Yes, really. ufdbGuard, like squidGuard before it, is a URL Filter that
filters known unwanted URLs. A content filter, like DansGuardian and
E2Guardian are content filters which examine the content of web pages
looking for unwanted things.

On Sun, Aug 16, 2015 at 6:10 PM, Yuri Voinov <yvoinov at gmail.com> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> O, really?
>
> 17.08.15 4:03, Stanford Prescott пишет:
> > ufdbGuard is not a content filter.
> >
> > On Sun, Aug 16, 2015 at 4:07 PM, Yuri Voinov <yvoinov at gmail.com>
> <yvoinov at gmail.com> wrote:
> >
> >>
> > ufdbguard does.
> >
> > 16.08.15 20:27, Stanford Prescott пишет:
> >
> > >>> I have SquidClamAV implemented with the Smoothwall Express 3.1
> firewall.
> > It
> > >>> works well and fast with ssl-bump, although the majority of our users
> > only
> > >>> have relatively small networks with smaller loads.
> > >>>
> > >>> FYI, E2Guardian has replaced the DansGuardian project and is
> currently
> > well
> > >>> maintained. E2Guardian can do content filtering for SSL but only in
> > >>> explicit mode, It currently does not support intercept (transparent)
> mode
> > >>> for SSLBump.
> > >>>
> > >>> On Fri, Aug 14, 2015 at 10:51 AM, Alex Rousskov <
> > >>> rousskov at measurement-factory.com> wrote:
> > >>>
> > >>>> On 08/13/2015 10:31 PM, Amos Jeffries wrote:
> > >>>>> AFAICS it
> > >>>>> is the backend AV library only scanning disk objects that causes
> the
> > >>>>> whole issue. Otherwise the eCAP could be much, much faster.
> > >>>>
> > >>>> The situation is more nuanced: eCAP supports asynchronous adapters.
> It
> > >>>> is possible to write a ClamAV adapter that writes messages to disk
> and
> > >>>> analyses them without blocking Squid. Doing so should eliminate most
> > >>>> overheads between Squid and ClamAV.
> > >>>>
> > >>>> Factory ClamAV adapter can run in asynchronous mode, but threads are
> > >>>> only used for _analysis_ of written files. We have not optimized the
> > >>>> file writing part (yet?). Hopefully, using a RAM-based file system
> can
> > >>>> mitigate a large part of that performance damage (as well as address
> > >>>> some of the security concerns related to disk storage?).
> > >>>>
> > >>>> A bigger performance problem, AFAICT, is that ClamAV does not
> support
> > >>>> incremental analysis. It waits for the entire file to be downloaded
> > >>>> first. This breaks the message delivery pipeline and increases
> > >>>> user-perceived response time. This problem cannot be solved outside
> the
> > >>>> ClamAV library.
> > >>>>
> > >>>>
> > >>>> Cheers,
> > >>>>
> > >>>> Alex.
> > >>>>
> > >>>> _______________________________________________
> > >>>> squid-users mailing list
> > >>>> squid-users at lists.squid-cache.org
> > >>>> http://lists.squid-cache.org/listinfo/squid-users
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> squid-users mailing list
> > >>> squid-users at lists.squid-cache.org
> > >>> http://lists.squid-cache.org/listinfo/squid-users
> >
> >>
> >>
> >> _______________________________________________
> >> squid-users mailing list
> >> squid-users at lists.squid-cache.org
> >> http://lists.squid-cache.org/listinfo/squid-users
> >>
> >>
> >
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJV0QpsAAoJENNXIZxhPexG24gIAMNuWsyfn/QkXWTXROZEJYL1
> 0frhC+w22fjV8svGjTrZEtSKY4LTHiHEjp99bPBEpPdoCURifUq20m018qRoIcEA
> XZfadD+s47bT7FvZbc2W58BQZUsWvotQRMNDPE+Mf0e38ev6PXsj16SaHmWytdx2
> Z9H0y5qlgJwwbUyfps4uQn1wF16Qlf2Fw5TGRUbBrij+rjPYzDSXTXxtfT+4j/3V
> 4lZ0bN0HSFfvJrbfcpPoMCnSlRyJOm/b6Rxqv7v733OtrY/41EW1+HE1HOmW0em3
> rwpAV1KgWrwMZYHcIBE147itXlz1RGQutX01auiiSvm/hO3h78rl6aSawmanOAM=
> =GgTR
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150816/b4cb7f9d/attachment.html>