Re: [squid-users] Securing squid3

On 15/02/2013 10:18 a.m., Andreas Westvik wrote:
> So i actually got it working!
>
> Client -> gateway -> havp -> squid -> internets
>
> I actually had blocked my self totally from squid3, so that was quite the head scratch. It turned out that http access deny all has to be
> at the bottom of the config file. ;)

:-)

You started this thread with a question on how to make Squid secure. If
you are using the Squeeze or Wheezy package you are not secure, the
Squeeze package is missing patches for 3 CVE vulnerabilities, the Wheezy
package is currently missing 1.

Also, since you have a good handle on where the traffic is coming from
you can lock down the proxy listening port.

I wouls suggest s small vriant of teh mangle table rule which can be
found here:
http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat
By adding a "-s !192.168.*" stanza to exclude your internal clients from
the port block you can give them service while halting all external access.

> So then I pasted this into squid.conf
>
> cache_peer 192.168.0.24 parent 3127 0 no-query no-digest
> And then I reloaded and everything just worked.
>
> Now my second server running debian wheezy is a first gen macbook. So that is not a beast. But it workes just fine.
> The log folder is mounted in the ram to use most of the speed.
>
> I made a little screencast of the thing working
> Have a look
>
> https://vimeo.com/59687536
>
> Thanks for the help everyone! :)
> On Feb 14, 2013, at 17:24 , Andreas Westvik <andreas_at_spbk.no> wrote:
>
>> havp supports parent setup, and as far as I have seen, it should be setup before squid.
>> Now, I can always switch this around, and move the squid3 setup to 192.168.0.24 and setup
>> havp on 192.168.0.1 of course.
>> But 192.168.0.1 is running debian "production" and Debian does not
>> support havp on a squeeze. So Im using a debian wheezy for havp in the mean while. And its not installed via apt.

HAVP appears to be a neglected project. You may want to update the
scanner to another AV (clamav with c-icap perhapse).

NP: With ICAP you can plug in almost any AV scanner system into Squid
and only have the MISS traffic being scanned, pre-scanned HITS still
served out of cache at full speed. ICAP also supports streamed scanning
from the latest AV systems, where the client gets delivery far faster.
  * serving from cache without re-scanning is a controverisial topic
though. It is fast on the HITs, but permits any infections in cache to
be delivered even after scanner signatures are updated.

>>
>>
>> If squid caches infected files, the local clamav should take care of that anyways? Since havp on the other server are
>> using clamav as well.

Try plugging clamav directly into Squid. c-icap works for most people
(unless you are one of the lucky ones with trouble).

>>
>> I really don't think the iptables rules should be that difficult to setup up, since I intercept the web traffic with this:
>>
>> iptables -t nat -A PREROUTING -i eth3 -p tcp --dport 80 -j REDIRECT --to-port 3128
>>
>> So it's basically the same thing, but kinda like -j REDIRECT -to-destination 192.168.0.24:3127
>>
>> But it's not working! grr!

REDIRECT is a special case of DNAT target which redirects to the hosts
main IP address. You cannot specify a destination IP on REDIRECT target,
you can on DNAT. The LInuxDnat wiki page I linked to above has all the
details you need for this - the iptables rules are the same for any
proxy which accepts NAT'd traffic.

So...
  * When your box IP is dynamically assigned and not known in advance
use REDIRECT.
  * When your box is statically assigned use DNAT to the IP Squid is
listening on.

Squid-3.2+ provide protection against the CVE-2009-0801 security
vulnerability in NAT and TPROXY traffic, I doubt HAVP supplies that, but
it may.
If so, you cannot receive traffic at a proxy which was NAT'd on another
box - since NAT erasing the destination IP is a cause of that CVE.

Amos
Received on Fri Feb 15 2013 - 05:11:33 MST