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@xxxxxxx> 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
