Re: [squid-users] Securing squid3

Oh, this was a lot of information! :D

So here goes. Im only using squeeze on the production server. On the testing server Im running wheezy, but not squid. Only havp.
And yeah, I seems a bit poor but I was only testing this as proof of concept. Or to satisfy my inner nerd.
Im not going to use this solution in the long run, and like you say there is more options as well. So now Im going to check them out since Im done with this.
Could a managed switch help me out here? Instead of the crazy iptables/forwarding/redirecting on the server?
Right now Im researching a small HP procurve to manage these connections for me, is this the normal route (no pun intended) to do this?
Was thinking about setting up the switch directly in front of 192.168.0.1 and redirect the traffic to 192.168.0.24 before it hits the server.

Thanks for the other links. Im under the weather here, got the flu and a toot ache signed by satan him self. So Im going to check it out when Im fit for fight again.

And about the cve patches Im like hoping the debian team is on top of this. If you have other information - please keep it to your self :D

-Andreas

On Feb 15, 2013, at 06:11 , Amos Jeffries <squid3_at_treenet.co.nz> wrote:

> 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 - 11:18:02 MST