Re: Security Concerns

I understand the matter of deciding on whether or not the firwall should control access or whether squid should. It's just not really a desired practice, to rely on administrators to secure the product being developed. Allow-all configurations, simply shouldn't exist. Even to assist admins with firewall issues.

I am willing to bet, that the majority of the open proxies out there, are left by admins, who simply don't 1.) Read the documentation in the config, 2.) Know what an open proxy is and why it's open.

The very first time I downloaded squid, and read the documentation (by just skimming over it :), my first instinct was to remove the line that said "deny all". "Why would I want to deny all? What sense does that make". Of course, I went on to read the documentation and understood what that line really meant. But most administrators don't do that. They're lazy, they don't have the time, etc.

So my suggestion is to patch squid so that it can NOT be run in an "allow-all" configuration. There are way too many security risks to attempt to balance and justify such a practice. If, after configuring the squid file, squid notices that it's running in an allow-all configuration, squid either reports this (constantly, so it can't be ignored), or squid simply shuts down. I'm pushing for the latter. I don't even think squid should be able to run in this fashion.

Let's have some feedback.

Tim Rainier
pixel

--- Henrik Nordstrom <hno@squid-cache.org> wrote:
On Sun, 25 Jan 2004, Tim Rainier wrote:

> I am curious whether there is any legit reason in running squid as an
> open proxy?

Not having access controls on the proxy makes the administrators life
slightly easier when there already is access controls enforced by
firewalls or the like, but personally I prefer having access controls
anyway. A open proxy is often a far worse security problem than a glitch
in the firewall rules for many reasons.

> I'm probably not the first person to ask about this, but I am very
> curious. There are way too many people abusing administrators' lack of
> knowledge, by connecting to these open proxies via chaining. This does
> two things:
>
> 1.) It allows people to abuse internet services, using insecure squid
> proxies.
>
> 2.) Using a chaining mechanism, they can connect through a 'chain' of
> proxies, providing ISPs, Law Enforcement, etc a complicated means of
> tracking abuse.
>
> Is there no way to hard code a module or function that disallows squid
> to run as an open proxy? Or are you allowing it because of some needed
> service that can justify the amount of problems it causes?

If there was a way to determine what the local networks who should be
using the proxy is then we would use it in the default configuration. But
based on past experiences I would say this is not sufficient to solve the
problem.

As there is no such methods the default Squid configuration does not allow
anything until the administator has entered information about his local
networks.

The default Squid access rules read like:

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

# Example rule allowing access from your local networks. Adapt
# to list your (internal) IP networks from where browsing should
# be allowed
#acl our_networks src 192.168.1.0/24 192.168.2.0/24
#http_access allow our_networks

# And finally deny all other access to this proxy
http_access deny all

Before this there is also a bunch of anti-abuse rules which should not be
removed unless one knows exacly what one is doing. These rules include
(but is not limited to) restricting the use of the CONNECT method to known
SSL services only, blocking access to well known non-HTTP services such as
SMTP, etc etc..

But still there is administrators who deliberately deletes all the
anti-abuse rules and uses "allow all" as their single rule, thereby
configuring Squid as a fully open proxy. If they do this knowing the
effects or not can be speculated upon.

Then there is a few which simply misunderstands how Squid access rules
works and by mistake allows broaded access then they intended, but these
seem to be relatively few.

I suspect a lot of these mishaps is due to the widespread "legal" abuse of
the CONNECT method for tunneling different non-HTTP applications over a
HTTP proxy. What I suspect is that many actually start out having somewhat
sane access rules, but when as their users come breathing down their necks
complaining about not being able to run this hyper-important non-HTTP
application which claims to support HTTP proxies (usually via the CONNECT
method, but they often don't tell or the users don't know) when using the
Squid HTTP proxy they finally give up and just deletes all access rules
including the anti-abuse rules and just uses a "allow all" rule.

It is truly amasing what "valid" applications one can find abusing the
CONNECT method to escape the local network instead of supporting SOCKS or
other sane proxy methods for non-HTTP applications. Each of these puts a
large strain on the security configuration of HTTP proxies.

Regards
Henrik

_____________________________________________________________
Proud member of United Networks Email, visit or report abuse at http://networks.org/
Received on Mon Jan 26 2004 - 06:39:31 MST