As an example, we will assume that you would like to prevent users from accessing cooking recepies.
One way to implement this would be to deny access to any URLs
that contain the words ``cooking'' or ``recepie.''
You would use these configuration lines:
acl Cooking1 url_regex cooking
acl Recepie1 url_regex recepie
http_access deny Cooking1
http_access deny Recepie1
http_access allow all
The url_regex means to search the entire URL for the regular
expression you specify. Note that these regular expressions are case-sensitive,
so a url containing ``Cooking'' would not be denied.
Another way is to deny access to specific servers which are known
to hold recepies. For example:
acl Cooking2 dstdomain gourmet-chef.com
http_access deny Cooking2
http_access allow all
The dstdomain means to search the hostname in the URL for the
string ``gourmet-chef.com.''
Note that when IP addresses are used in URLs (instead of domain names),
Squid-1.1 implements relaxed access controls. If the a domain name
for the IP address has been saved in Squid's ``FQDN cache,'' then
Squid can compare the destination domain against the access controls.
However, if the domain is not immediately available, Squid allows
the request and makes a lookup for the IP address so that it may
be available for future reqeusts.
You can use
ident lookups
to allow specific users access to your cache. This requires that an
ident server
process runs on the user's machine(s).
In your squid.conf configuration
file you would write something like this:
ident_lookup on
acl friends user kim lisa frank joe
http_access allow friends
http_access deny all
Another option is to use proxy-authentication.
-DUSE_PROXY_AUTH=1. Uncomment USE_PROXY_AUTH
in src/Makefile.
make clean
vi src/Makefile
make
make install
proxy_auth /usr/local/squid/etc/passwd
passwd is an apache-style file of passwords for authenticated proxy access Looks like username:password, with the password being standard crypt() format.
Sort of.
If you use a user ACL in squid conf, then Squid will perform an ident lookup for every client request. In other words, Squid-1.1 will perform ident lookups for all requests or no requests. Defining a user ACL enables ident lookups, regardless of the ident_lookup setting.
However, even though ident lookups are performed for every request, Squid does
not wait for the lookup to complete unless the ACL rules require it. Consider this
configuration:
acl host1 src 10.0.0.1
acl host2 src 10.0.0.2
acl pals user kim lisa frank joe
http_access allow host1
http_access allow host2 pals
Requests coming from 10.0.0.1 will be allowed immediately because
there are no user requirements for that host. However, requests
from 10.0.0.2 will be allowed only after the ident lookup completes, and
if the username is in the set kim, lisa, frank, or joe.
You've probably noticed (and been frustrated by) the fact that you cannot combine access controls with terms like ``and'' or ``or.'' These operations are already built in to the access control scheme in a fundamental way which you must understand.
For example, the following access control configuration will never work:
acl ME src 10.0.0.1
acl YOU src 10.0.0.2
http_access allow ME YOU
In order for the request to be allowed, it must match the ``ME'' acl AND the ``YOU'' acl.
This is impossible because any IP address could only match one or the other. This
should instead be rewritten as:
acl ME src 10.0.0.1
acl YOU src 10.0.0.2
http_access allow ME
http_access allow YOU
Or, alternatively, this would also work:
acl US src 10.0.0.1 10.0.0.2
http_access allow US
I have read through my squid.conf numerous times, spoken to my neighbors, read the FAQ and Squid Docs and cannot for the life of me work out why the following will not work.
I can successfully access cachemgr.cgi from our web server machine here, but I would like to use MRTG to monitor various aspects of our proxy. When I try to use 'client' or GET cache_object from the machine the proxy is running on, I always get access denied.
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl server src 1.2.3.4/255.255.255.255
acl all src 0.0.0.0/0.0.0.0
acl ourhosts src 1.2.0.0/255.255.0.0
http_access deny manager !localhost !server
http_access allow ourhosts
http_access deny all
The intent here is to allow cache manager requests from the localhost
and server addresses, and deny all others. This policy has been
expressed here:
http_access deny manager !localhost !server
The problem here is that for allowable requests, this access rule is not matched. For example, if the source IP address is localhost, then ``!localhost'' is false and the access rule is not matched, so Squid continues checking the other rules. Cache manager requests from the server address work because server is a subset of ourhosts and the second access rule will match and allow the request. Also note that this means any cache manager request from ourhosts would be allowed.
To implement the desired policy correctly, the access rules should be
rewritten as
http_access allow manager localhost
http_access allow manager server
http_access deny manager
http_access allow ourhosts
http_access deny all
You may be concerned that the having five access rules instead of three may have an impact on the cache performance. In our experience this is not the case. Squid is able to handle a moderate amount of access control checking without degrading overall performance. You may like to verify that for yourself, however.
You can debug your access control configuration by setting the
debug_options parameter in squid.conf and
watching cache.log as requests are made. The access control
routes correspond to debug section 28, so you might enter:
debug_options ALL,1 28,9
The problem...
[ Parents ] / \ / \ [ Proxy A ] --- [ Proxy B ] | | USERProxy A sends and ICP query to Proxy B about an object, Proxy B replies with an ICP_HIT. Proxy A forwards the HTTP request to Proxy B, but does not pass on the authentication details, therefore the HTTP GET from Proxy A fails.
Only ONE proxy cache in a chain is allowed to ``use'' the Proxy-Authentication request header. Once the header is used, it must not be passed on to other proxies.
Therefore, you must allow the neighbor caches to request from each other
without proxy authentication. This is simply accomplished by listing
the neighbor ACL's first in the list of http_access lines. For example:
acl proxy-A src 10.0.0.1
acl proxy-B src 10.0.0.2
acl user_passwords proxy_auth /tmp/user_passwds
http_access allow proxy-A
http_access allow proxy-B
http_access allow user_passwords
http_access deny all