[squid-users] Squid Deployment Questions

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31/12/2014 6:59 p.m., Evan Blackstone wrote:
> Hey all, Wondering if I could get some advice on potentially
> setting up a Squid forward proxy on my network. I'm not a Linux
> novice by any means, but I'm not experienced in server
> administration, log review, etc.
> 
> We're needing to deploy a simple non-caching, non-peering forward
> proxy to integrate with an ICAP server for web filtering. My plan
> is pretty basic...here's my network config:
> 
> Internet --> Cisco ASA --> DMZ --> Internal LAN
> 
> I've received conflicting advice on whether or not there's any
> advantage to putting a forward proxy on the DMZ vs. internal LAN.
> In any case, 'm wanting to deploy an explicit proxy with a single
> NIC. Workstations will use a PAC file, etc. to point to the proxy.
> 
> If the server is on the DMZ, I'd allow 80/443 from the internal LAN
> to the DMZ, then allow 80/443 from the proxy to outside. I'd also
> be allowing the proxy to internal LAN for ICAP, syslog, and
> possibly NTP. The proxy would have a single interface...although it
> would NAT to outside for internet access, there would be no ports
> open on the outside interface.

Like Eliezer mentioned if ICAP services are in the LAN place the proxy
there. Placing the proxy in the DMZ if ICAP services are in the LAN
means the traffic has to flow across the DMZ<->LAN pathways three
times - limiting your traffic to 1/3 of line speed on the slowest NIC
along the way.

Similarly using a single NIC machine means the HTTP traffic through
the proxy is already limited to 1.2 the speed of that NIC. If it's not
a Gbit NIC then using two NIC (for separate inbound and outbound
flows) will allow Squid to run at capacity - which is somewhat over
50Mbps these days and increasing a little each release.


> 
> Based on some testing I've done, my squid.conf would be pretty
> basic...
> 
> http_access allow internalnetwork cache deny internalnetwork 
> always_direct allow internalnetwork http_access deny all etc.
> 

No need for always_direct. Nor for "cache deny internalnetwork".

You could use "cache deny all" to prevent all HTTP caching but a small
amount of memory-only cache is good for improving responses to the
topmost popular URLs. Squid has a default 256MB of memory cache to
store approx 10K objects (cache_mem directive).


> My questions are:
> 
> Does it sound like I'm on the right track here? Would the above
> described configuration be safe? I've read that Squid should listen
> only on an internal interface? What about when the server only has
> one?

Use the default squid.conf as a basis and extend as necessary. It has
the basic security measures that are important. For a quick start you
only need to ensure *localnet* ACL is defined with your LAN IP ranges
and you are good to go as a forward proxy.


Internal/external interface makes no difference when there is only one
NIC.

The default config is safe enough to reject traffic from external
sources (non-localnet), but you can be extra sure with either a
firewall block in the routers preventing non-LAN connections inbound
to the proxy machine.


> 
> What level of risk would I be assuming (regular patching included)?
> Given that I'm relatively new to monitoring Linux servers for
> security, etc., is this a bad idea? I'm not really sure what to be
> looking for log-wise in terms of compromise. I have edge devices
> and monitoring on the perimeter, but I don't really know what to
> look for on the server itself...

Squid is one of (if not The) most hardened proxies available. It can
basically only be compromised in two ways:
1) corruption of cached objects - you dont have any on disk, and
avoiding the refresh_pattern override/ignores removes the risk of
memory objects corruption.

2) infection of the binaries that make up Squid - this is not
detectable from within Squid anyway. A system AV scanner (or regular
update schedule) is required for that.

Squid does crash in a numer of ways, but that is a fail-closed DoS
type event rather than compromise.

* You should monitor cache.log for anything that mentions "assertion"
or "FATAL". These are Squid bugs and self-DoS vulnerability. We are
always interested in finding out how these happen and fixing.

* access.log monitoring is a possibility. One can usually find web
exploits being attempted on *other* services in a Squid access.log, so
monitoring it like one woud la web server log for suspicious URL
requests can be useful to proactively identify compromised clients.


The Safe_ports and SSL_ports ACLs in the default config map out blocks
on the ports with known security issues.

You may have clients with web apps needing special ports accessible
via CONNECT. Take the usual due-diligence there as if you were opening
a firewall port for unrestricted use, then if you wish add the port
number to SSL_ports ACL (Safe_ports should already be open for 1024 or
larger port numbers).


You can enable the to_localhost rules which are commented out by
default to protect against clients accessing services on the Squid
machine itself (if any exist accessible over localhost interface).
Though on a dedicated proxy the SSL_Ports rule should already be
taking care of that.


> 
> Am I approaching this the wrong way? Should I be looking at putting
> it on the inside LAN? Would such an approach leave my network
> vulnerable should the Squid box get owned?
> 

Since the purpose of a proxy is to be reachable from LAN clients the
security impact on Squid itself is no different in either position.

The security balance is betweeen whether the rest of the machine
access methods (including the ICAP servers security "footprint") are
more/worse secure in either position vs the traffic costs mentioned above.

NP: ICAP servers and particularly the unencrypted TCP connections to
them are the weakest point, since they have the ability to alter the
HTTP traffic contents in arbitrary ways. Explicitly not touching the
traffic content is one of the security hardening aspects of Squid.

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUo8gFAAoJELJo5wb/XPRjtX8H+wRNpqWFQ5+Q/elGQcVJVMtO
z4U1SrMG3fk1Mbda/i2J/1gds/bdkOSqRtc6E8Qi35qTBDARxNCLixT60zcEla4m
r/kqBqPXwl0ZpheaS+st9n5Pmc2LoQxwZTJzUT4CjzVZ4+dWPVHhBZoIbizo1EGO
hpZLLGf7Xxoy975119av/NTY+as5moXvG94qoOVne+qOzMuJjUhw1Yk9N6drZ7K8
4TKLdi6ePFF6esHe2XERjPVEdx9L5YtAhV8TeJH2V4RENdZkbwzOe6Bcf/RIa3Do
/9FL03OfI36F7XepjsQzMgf57wpB6T5Kh27geqmWuhkP7AuU13U8vRrAZIYHzNw=
=xmjG
-----END PGP SIGNATURE-----