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 squ...@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 andr...@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
Re: [squid-users] Securing squid3
Sorry, I have been replying directly to users email. To clear things up, here is a image of the setup: http://bildr.no/image/1389674.jpeg havp is running on 192.168.0.24:3127 squid3 is running on 192.168.0.1:3128 -Andras On Feb 14, 2013, at 16:45 , babajaga augustus_me...@yahoo.de wrote: I think, 2 corrections: Instead squid.conf: cache_peer localhost parent 8899 0 no-query no-digest squid.conf: cache_peer avp-host parent 8899 0 no-query no-digest never_direct allow all Otherwise, uncachable requests will not go thru parent proxy, but direct. Which will result in some files, not scanned by havp. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Securing-squid3-tp4658495p4658498.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Securing squid3
heh, try this one http://bildr.no/view/1389674 On Feb 14, 2013, at 16:49 , Andreas Westvik andr...@spbk.no wrote: Sorry, I have been replying directly to users email. To clear things up, here is a image of the setup: http://bildr.no/image/1389674.jpeg havp is running on 192.168.0.24:3127 squid3 is running on 192.168.0.1:3128 -Andras On Feb 14, 2013, at 16:45 , babajaga augustus_me...@yahoo.de wrote: I think, 2 corrections: Instead squid.conf: cache_peer localhost parent 8899 0 no-query no-digest squid.conf: cache_peer avp-host parent 8899 0 no-query no-digest never_direct allow all Otherwise, uncachable requests will not go thru parent proxy, but direct. Which will result in some files, not scanned by havp. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Securing-squid3-tp4658495p4658498.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Securing squid3
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. ;) 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 andr...@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. 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. 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! -Andreas On Feb 14, 2013, at 17:12 , babajaga augustus_me...@yahoo.de wrote: Then its more a question how to setup iptables, the clients and HAVP. However, why HAV first ? This has the danger of squid caching infected files. And HAV will scan cached files over and over again. Then squid will be an upstream proxy of HAV. IF HAV supports parent proxies, then squid should have no problem. But this then either needs a proxy.pac for the clients browsers or explicit proxy config for the clients browsers. This would be the easier path. When this works, then to think about using ipt with explicit routing of all packets to HAV-box. And back, so you have to consider NAT. I am not fit enough in ipt, so I would keep it simple: client-PC-squid-HAV--web And the transparent setup for squid is well documented. PS: Grafik ist etwas klein :-) -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Securing-squid3-tp4658495p4658501.html Sent from the Squid - Users mailing list archive at Nabble.com.
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 andr...@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
