Re: Security Concerns

This question got me thinking, and maybe we should restrict Squid to plain
refuse to start if access rules say "http_access allow all".

A simple 2.5 patch for doing this and also detecting if "acl all" is
redefined as something else than intended is attached to this message.

Opinions please.

Regards
Henrik

On Sun, 25 Jan 2004, Henrik Nordstrom 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
>