Michelle Dawson wrote:
Hi Guys, I searched the whole FAQ, mailing list archives and Googled my way through the evening and I couldn't find any references in solving my problem. So please, if you can, help me figure it out. My team and I are currently struggling with an issue in which we would like to detect/identify some extra parameters in the Squid config file so we can determine what website blocking filter we should use. For example, if a user would connect to us with a parameter or a part in the header that we can detect (blocked=none) we would display all the sites to this user without denying any of the blocking lists, but if he would connect as (blocked=phishing) we would show all the sites except the ones that are known for phishing such as: acl blockphishing url_regex "c:/squid/etc/blacklists/phishing/domains.squid" http_access deny blockphishing This works fine in a static environment without the use of identifying the user with ACLs. The problem is that our users are completely random throughout North America, we don't know their mac addresses or their ip addresses or their user names or machine names (so static
What service are you providing?
configuration based on that data is impossible) . I guess the only way of blocking them is with additional parameters or something like that being sent to the Squid server in connection requests. We are able to modify the headers from Firefox where we have a plugin that sets the settings for our proxy and modifies the headers a bit. My current bet is on that if Squid can read the headers, we could set the ACL's based on that and filter the content as required. But we don't know how to do it or if it is even posibile.
Squid can and does read the headers. Have a read through http://www.squid-cache.org/Versions/v2/2.7/cfgman/acl.html for a list of the ACL types available to you.
How would you approach our problem without using LDAP or any other type of authentication to resolve it?
Reliable authorization without identity checking is a race that can never be won. Everything except the request method in HTTP can be forged trivially. If the blocked users discover what your check parameters are they will bypass them in no time.
Security Authentication is the solution to that problem. It provides a reliable identity confirmation.
You said you have a plugin that can alter headers. I suggest making it add a Proxy-Authenticate: header on outgoing requests with your access-type token encrypted inside. Squid is easy to write custom authenticators for. One such can de-crypt the header into a "username" for each access type.
Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.5
