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 <[EMAIL PROTECTED]> 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/
