<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br>
Either SquidGuard, or ufdbGuard has this functional onto blocking
page. Just configure it.<br>
<br>
17.08.15 5:04, Stanford Prescott пишет:<br>
<span style="white-space: pre;">> Yes, really. ufdbGuard, like
squidGuard before it, is a URL Filter that<br>
> filters known unwanted URLs. A content filter, like
DansGuardian and<br>
> E2Guardian are content filters which examine the content of
web pages<br>
> looking for unwanted things.<br>
><br>
> On Sun, Aug 16, 2015 at 6:10 PM, Yuri Voinov
<a class="moz-txt-link-rfc2396E" href="mailto:yvoinov@gmail.com"><yvoinov@gmail.com></a> wrote:<br>
><br>
>><br>
> O, really?<br>
><br>
> 17.08.15 4:03, Stanford Prescott пишет:<br>
> >>> ufdbGuard is not a content filter.<br>
> >>><br>
> >>> On Sun, Aug 16, 2015 at 4:07 PM, Yuri Voinov
<a class="moz-txt-link-rfc2396E" href="mailto:yvoinov@gmail.com"><yvoinov@gmail.com></a><br>
> <a class="moz-txt-link-rfc2396E" href="mailto:yvoinov@gmail.com"><yvoinov@gmail.com></a> wrote:<br>
> >>><br>
> >>>><br>
> >>> ufdbguard does.<br>
> >>><br>
> >>> 16.08.15 20:27, Stanford Prescott пишет:<br>
> >>><br>
> >>>>>> I have SquidClamAV implemented with
the Smoothwall Express 3.1<br>
> firewall.<br>
> >>> It<br>
> >>>>>> works well and fast with ssl-bump,
although the majority of our users<br>
> >>> only<br>
> >>>>>> have relatively small networks with
smaller loads.<br>
> >>>>>><br>
> >>>>>> FYI, E2Guardian has replaced the
DansGuardian project and is<br>
> currently<br>
> >>> well<br>
> >>>>>> maintained. E2Guardian can do
content filtering for SSL but only in<br>
> >>>>>> explicit mode, It currently does not
support intercept (transparent)<br>
> mode<br>
> >>>>>> for SSLBump.<br>
> >>>>>><br>
> >>>>>> On Fri, Aug 14, 2015 at 10:51 AM,
Alex Rousskov <<br>
> >>>>>> <a class="moz-txt-link-abbreviated" href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>>
wrote:<br>
> >>>>>><br>
> >>>>>>> On 08/13/2015 10:31 PM, Amos
Jeffries wrote:<br>
> >>>>>>>> AFAICS it<br>
> >>>>>>>> is the backend AV library
only scanning disk objects that causes<br>
> the<br>
> >>>>>>>> whole issue. Otherwise the
eCAP could be much, much faster.<br>
> >>>>>>><br>
> >>>>>>> The situation is more nuanced:
eCAP supports asynchronous adapters.<br>
> It<br>
> >>>>>>> is possible to write a ClamAV
adapter that writes messages to disk<br>
> and<br>
> >>>>>>> analyses them without blocking
Squid. Doing so should eliminate most<br>
> >>>>>>> overheads between Squid and
ClamAV.<br>
> >>>>>>><br>
> >>>>>>> Factory ClamAV adapter can run
in asynchronous mode, but threads are<br>
> >>>>>>> only used for _analysis_ of
written files. We have not optimized the<br>
> >>>>>>> file writing part (yet?).
Hopefully, using a RAM-based file system<br>
> can<br>
> >>>>>>> mitigate a large part of that
performance damage (as well as address<br>
> >>>>>>> some of the security concerns
related to disk storage?).<br>
> >>>>>>><br>
> >>>>>>> A bigger performance problem,
AFAICT, is that ClamAV does not<br>
> support<br>
> >>>>>>> incremental analysis. It waits
for the entire file to be downloaded<br>
> >>>>>>> first. This breaks the message
delivery pipeline and increases<br>
> >>>>>>> user-perceived response time.
This problem cannot be solved outside<br>
> the<br>
> >>>>>>> ClamAV library.<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>> Cheers,<br>
> >>>>>>><br>
> >>>>>>> Alex.<br>
> >>>>>>><br>
> >>>>>>>
_______________________________________________<br>
> >>>>>>> squid-users mailing list<br>
> >>>>>>>
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> >>>>>>>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
> >>>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>>
_______________________________________________<br>
> >>>>>> squid-users mailing list<br>
> >>>>>> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> >>>>>>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
> >>><br>
> >>>><br>
> >>>><br>
> >>>>
_______________________________________________<br>
> >>>> squid-users mailing list<br>
> >>>> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> >>>>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
> >>>><br>
> >>>><br>
> >>><br>
><br>
><br>
>><br>
>><br>
></span><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBCAAGBQJV0aHAAAoJENNXIZxhPexGQiMIAJAAW6E7JKROzwy0B+KcCLK6
<br>
BxfcA1o+lvJYwl6drsTeBH4NzO+Ra4eYmJMC94LwYc17E8Zwj5A+1t25cfQ1orIi
<br>
5EFjiVQ+0nseAGidcBnUNM1Nw+b4Xa/WswGo9+ApmslSstO1643uwteVip8o+Blg
<br>
FuhYDuodynLNedsvxFq8/098zkZs1yc8d/pDyTAg4rQIGgU3gvxoMj3DLixFAkSy
<br>
E0Qx0jEsSBvt0ksJAgxi0dVQh3ybeQqxevLgwDPFI0DuIvDh2Ho+6jwovzv+NyWS
<br>
EK2i5CigTk2VguviWSFGmhpEkn3mvdLE5Kdj2XCB+1KFecmRv8ITwjvNNPKuh2w=
<br>
=Mh/Z
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>