|
Server : Apache/2.2.2 (Fedora) System : Linux App1.pathumtani.go.th 2.6.20-1.2320.fc5smp #1 SMP Tue Jun 12 19:40:16 EDT 2007 i686 User : apache ( 48) PHP Version : 5.2.9 Disable Function : NONE Directory : /proc/self/root/usr/share/doc/squid-2.5.STABLE14/ |
Upload File : |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
<TITLE>SQUID Frequently Asked Questions: Access Controls</TITLE>
<LINK HREF="FAQ-11.html" REL=next>
<LINK HREF="FAQ-9.html" REL=previous>
<LINK HREF="FAQ.html#toc10" REL=contents>
</HEAD>
<BODY>
<A HREF="FAQ-11.html">Next</A>
<A HREF="FAQ-9.html">Previous</A>
<A HREF="FAQ.html#toc10">Contents</A>
<HR>
<H2><A NAME="access-controls"></A> <A NAME="s10">10.</A> <A HREF="FAQ.html#toc10">Access Controls</A></H2>
<H2><A NAME="ss10.1">10.1</A> <A HREF="FAQ.html#toc10.1">Introduction</A>
</H2>
<P>Squid's access control scheme is relatively comprehensive and difficult
for some people to understand. There are two different components: <EM>ACL elements</EM>,
and <EM>access lists</EM>. An access list consists of an <EM>allow</EM> or <EM>deny</EM> action
followed by a number of ACL elements.</P>
<H3>ACL elements</H3>
<P><EM>Note: The information here is current for version 2.4.</EM></P>
<P>Squid knows about the following types of ACL elements:
<UL>
<LI><B>src</B>: source (client) IP addresses</LI>
<LI><B>dst</B>: destination (server) IP addresses</LI>
<LI><B>myip</B>: the local IP address of a client's connection</LI>
<LI><B>srcdomain</B>: source (client) domain name</LI>
<LI><B>dstdomain</B>: destination (server) domain name</LI>
<LI><B>srcdom_regex</B>: source (client) regular expression pattern matching</LI>
<LI><B>dstdom_regex</B>: destination (server) regular expression pattern matching</LI>
<LI><B>time</B>: time of day, and day of week</LI>
<LI><B>url_regex</B>: URL regular expression pattern matching</LI>
<LI><B>urlpath_regex</B>: URL-path regular expression pattern matching, leaves out the protocol and hostname</LI>
<LI><B>port</B>: destination (server) port number</LI>
<LI><B>myport</B>: local port number that client connected to</LI>
<LI><B>proto</B>: transfer protocol (http, ftp, etc)</LI>
<LI><B>method</B>: HTTP request method (get, post, etc)</LI>
<LI><B>browser</B>: regular expression pattern matching on the request's user-agent header</LI>
<LI><B>ident</B>: string matching on the user's name</LI>
<LI><B>ident_regex</B>: regular expression pattern matching on the user's name</LI>
<LI><B>src_as</B>: source (client) Autonomous System number</LI>
<LI><B>dst_as</B>: destination (server) Autonomous System number</LI>
<LI><B>proxy_auth</B>: user authentication via external processes</LI>
<LI><B>proxy_auth_regex</B>: user authentication via external processes</LI>
<LI><B>snmp_community</B>: SNMP community string matching</LI>
<LI><B>maxconn</B>: a limit on the maximum number of connections from a single client IP address</LI>
<LI><B>req_mime_type</B>: regular expression pattern matching on the request content-type header</LI>
<LI><B>arp</B>: Ethernet (MAC) address matching</LI>
</UL>
</P>
<P>Notes:</P>
<P>Not all of the ACL elements can be used with all types of access lists (described below).
For example, <EM>snmp_community</EM> is only meaningful when used with <EM>snmp_access</EM>. The
<EM>src_as</EM> and <EM>dst_as</EM> types are only used in <EM>cache_peer_access</EM> access lists.</P>
<P>The <EM>arp</EM> ACL requires the special configure option --enable-arp-acl. Furthermore, the
ARP ACL code is not portable to all operating systems. It works on Linux, Solaris, and
some *BSD variants.</P>
<P>The SNMP ACL element and access list require the --enable-snmp configure option.</P>
<P>Some ACL elements can cause processing delays. For example, use of <EM>src_domain</EM> and <EM>srcdom_regex</EM>
require a reverse DNS lookup on the client's IP address. This lookup adds some delay to the request.</P>
<P>Each ACL element is assigned a unique <EM>name</EM>. A named ACL element consists of a <EM>list of values</EM>.
When checking for a match, the multiple values use OR logic. In other words, an ACL element is <EM>matched</EM>
when any one of its values is a match.</P>
<P>You can't give the same name to two different types of ACL elements. It will generate a syntax error.</P>
<P>You can put different values for the same ACL name on different lines. Squid combines them into
one list.</P>
<H3>Access Lists</H3>
<P>There are a number of different access lists:
<UL>
<LI><B>http_access</B>: Allows HTTP clients (browsers) to access the HTTP port. This is the primary access control list.</LI>
<LI><B>icp_access</B>: Allows neighbor caches to query your cache with ICP.</LI>
<LI><B>miss_access</B>: Allows certain clients to forward cache misses through your cache.</LI>
<LI><B>no_cache</B>: Defines responses that should not be cached.</LI>
<LI><B>redirector_access</B>: Controls which requests are sent through the redirector pool.</LI>
<LI><B>ident_lookup_access</B>: Controls which requests need an Ident lookup.</LI>
<LI><B>always_direct</B>: Controls which requests should always be forwarded directly to origin servers.</LI>
<LI><B>never_direct</B>: Controls which requests should never be forwarded directly to origin servers.</LI>
<LI><B>snmp_access</B>: Controls SNMP client access to the cache.</LI>
<LI><B>broken_posts</B>: Defines requests for which squid appends an extra CRLF after POST message bodies as required by some broken origin servers.</LI>
<LI><B>cache_peer_access</B>: Controls which requests can be forwarded to a given neighbor (peer).</LI>
</UL>
</P>
<P>Notes:</P>
<P>An access list <EM>rule</EM> consists of an <EM>allow</EM> or <EM>deny</EM> keyword, followed by a list of ACL element names.</P>
<P>An access list consists of one or more access list rules.</P>
<P>Access list rules are checked in the order they are written. List searching terminates as soon as one
of the rules is a match.</P>
<P>If a rule has multiple ACL elements, it uses AND logic. In other
words, <EM>all</EM> ACL elements of the rule must be a match in order
for the rule to be a match. This means that it is possible to
write a rule that can never be matched. For example, a port number
can never be equal to both 80 AND 8000 at the same time.</P>
<P>To summarise the acl logics can be described as:
<PRE>
http_access allow|deny acl AND acl AND ...
OR
http_access allow|deny acl AND acl AND ...
OR
...
</PRE>
</P>
<P>If none of the rules are matched, then the default action is the
<EM>opposite</EM> of the last rule in the list. Its a good idea to
be explicit with the default action. The best way is to thse
the <EM>all</EM> ACL. For example:
<PRE>
acl all src 0/0
http_access deny all
</PRE>
</P>
<H2><A NAME="ss10.2">10.2</A> <A HREF="FAQ.html#toc10.2">How do I allow my clients to use the cache?</A>
</H2>
<P>Define an ACL that corresponds to your client's IP addresses.
For example:
<PRE>
acl myclients src 172.16.5.0/24
</PRE>
Next, allow those clients in the <EM>http_access</EM> list:
<PRE>
http_access allow myclients
</PRE>
</P>
<H2><A NAME="ss10.3">10.3</A> <A HREF="FAQ.html#toc10.3">how do I configure Squid not to cache a specific server? </A>
</H2>
<P>
<PRE>
acl someserver dstdomain .someserver.com
no_cache deny someserver
</PRE>
</P>
<H2><A NAME="ss10.4">10.4</A> <A HREF="FAQ.html#toc10.4">How do I implement an ACL ban list?</A>
</H2>
<P>As an example, we will assume that you would like to prevent users from
accessing cooking recipes.</P>
<P>One way to implement this would be to deny access to any URLs
that contain the words ``cooking'' or ``recipe.''
You would use these configuration lines:
<PRE>
acl Cooking1 url_regex cooking
acl Recipe1 url_regex recipe
http_access deny Cooking1
http_access deny Recipe1
http_access allow all
</PRE>
The <EM>url_regex</EM> 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.</P>
<P>Another way is to deny access to specific servers which are known
to hold recipes. For example:
<PRE>
acl Cooking2 dstdomain www.gourmet-chef.com
http_access deny Cooking2
http_access allow all
</PRE>
The <EM>dstdomain</EM> means to search the hostname in the URL for the
string ``www.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.</P>
<H2><A NAME="ss10.5">10.5</A> <A HREF="FAQ.html#toc10.5">How do I block specific users or groups from accessing my cache?</A>
</H2>
<H3>Ident</H3>
<P>You can use
<A HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc931.txt">ident lookups</A>
to allow specific users access to your cache. This requires that an
<A HREF="ftp://ftp.lysator.liu.se/pub/ident/servers">ident server</A>
process runs on the user's machine(s).
In your <EM>squid.conf</EM> configuration
file you would write something like this:
<PRE>
ident_lookup on
acl friends user kim lisa frank joe
http_access allow friends
http_access deny all
</PRE>
</P>
<H3><A NAME="proxy-auth-acl"></A> Proxy Authentication</H3>
<P>Another option is to use proxy-authentication. In this scheme, you assign
usernames and passwords to individuals. When they first use the proxy
they are asked to authenticate themselves by entering their username and
password.</P>
<P>In Squid v2 this authentication is hanled via external processes. For
information on how to configure this, please see
<A HREF="FAQ-19.html#configuring-proxy-auth">Configuring Proxy Authentication</A>.</P>
<H2><A NAME="ss10.6">10.6</A> <A HREF="FAQ.html#toc10.6">Do you have a CGI program which lets users change their own proxy passwords?</A>
</H2>
<P>
<A HREF="mailto:orso@ineparnet.com.br">Pedro L Orso</A>
has adapted the Apache's <EM>htpasswd</EM> into a CGI program
called
<A HREF="/htpasswd/chpasswd-cgi.tar.gz">chpasswd.cgi</A>.</P>
<H2><A NAME="ss10.7">10.7</A> <A HREF="FAQ.html#toc10.7">Is there a way to do ident lookups only for a certain host and compare the result with a userlist in squid.conf?</A>
</H2>
<P>Sort of.</P>
<P>If you use a <EM>user</EM> ACL in squid conf, then Squid will perform
an
<A HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc931.txt">ident lookup</A>
for every client request. In other words, Squid-1.1 will perform
ident lookups for all requests or no requests. Defining a <EM>user</EM> ACL
enables ident lookups, regardless of the <EM>ident_lookup</EM> setting.</P>
<P>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:
<PRE>
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
</PRE>
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.</P>
<H2><A NAME="ss10.8">10.8</A> <A HREF="FAQ.html#toc10.8">Common Mistakes</A>
</H2>
<H3>And/Or logic</H3>
<P>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.
<UL>
<LI><B>All elements of an <EM>acl</EM> entry are OR'ed together</B>.</LI>
<LI><B>All elements of an <EM>access</EM> entry are AND'ed together</B>.
e.g. <EM>http_access</EM> and <EM>icp_access</EM>.</LI>
</UL>
</P>
<P>For example, the following access control configuration will never work:
<PRE>
acl ME src 10.0.0.1
acl YOU src 10.0.0.2
http_access allow ME YOU
</PRE>
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:
<PRE>
acl ME src 10.0.0.1
acl YOU src 10.0.0.2
http_access allow ME
http_access allow YOU
</PRE>
Or, alternatively, this would also work:
<PRE>
acl US src 10.0.0.1 10.0.0.2
http_access allow US
</PRE>
</P>
<H3>allow/deny mixups</H3>
<P><I>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></P>
<P><I>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.</I></P>
<P>
<PRE>
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
</PRE>
</P>
<P>The intent here is to allow cache manager requests from the <EM>localhost</EM>
and <EM>server</EM> addresses, and deny all others. This policy has been
expressed here:
<PRE>
http_access deny manager !localhost !server
</PRE>
</P>
<P>The problem here is that for allowable requests, this access rule is
not matched. For example, if the source IP address is <EM>localhost</EM>,
then ``!localhost'' is <EM>false</EM> and the access rule is not matched, so
Squid continues checking the other rules. Cache manager requests from
the <EM>server</EM> address work because <EM>server</EM> is a subset of <EM>ourhosts</EM>
and the second access rule will match and allow the request. Also note that
this means any cache manager request from <EM>ourhosts</EM> would be allowed.</P>
<P>To implement the desired policy correctly, the access rules should be
rewritten as
<PRE>
http_access allow manager localhost
http_access allow manager server
http_access deny manager
http_access allow ourhosts
http_access deny all
</PRE>
If you're using <EM>miss_access</EM>, then don't forget to also add
a <EM>miss_access</EM> rule for the cache manager:
<PRE>
miss_access allow manager
</PRE>
</P>
<P>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.</P>
<H3>Differences between <EM>src</EM> and <EM>srcdomain</EM> ACL types.</H3>
<P>For the <EM>srcdomain</EM> ACL type, Squid does a reverse lookup
of the client's IP address and checks the result with the domains
given on the <EM>acl</EM> line. With the <EM>src</EM> ACL type, Squid
converts hostnames to IP addresses at startup and then only compares
the client's IP address. The <EM>src</EM> ACL is preferred over <EM>srcdomain</EM>
because it does not require address-to-name lookups for each request.</P>
<H2><A NAME="acl-debug"></A> <A NAME="ss10.9">10.9</A> <A HREF="FAQ.html#toc10.9">I set up my access controls, but they don't work! why?</A>
</H2>
<P>If ACLs are giving you problems and you don't know why they
aren't working, you can use this tip to debug them.</P>
<P>In <EM>squid.conf</EM> enable debugging for section 33 at level 2.
For example:
<PRE>
debug_options ALL,1 33,2
</PRE>
Then restart or reconfigure squid.</P>
<P>From now on, your <EM>cache.log</EM> should contain a line for every
request that explains if it was allowed, or denied, and which
ACL was the last one that it matched.</P>
<P>If this does not give you sufficient information to nail down the
problem you can also enable detailed debug information on ACL processing
<PRE>
debug_options ALL,1 33,2 28,9
</PRE>
Then restart or reconfigure squid as above.</P>
<P>From now on, your <EM>cache.log</EM> should contain detailed traces
of all access list processing. Be warned that this can be quite
some lines per request.</P>
<P>See also
<A HREF="FAQ-11.html#debug">11.20 Debug Squid</A></P>
<H2><A NAME="ss10.10">10.10</A> <A HREF="FAQ.html#toc10.10">Proxy-authentication and neighbor caches</A>
</H2>
<P>The problem...
<BLOCKQUOTE>
<PRE>
[ Parents ]
/ \
/ \
[ Proxy A ] --- [ Proxy B ]
|
|
USER
</PRE>
<P><I>Proxy 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.</I></P>
</BLOCKQUOTE>
</P>
<P>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.</P>
<P>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 <EM>http_access</EM> lines. For example:
<PRE>
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
</PRE>
</P>
<H2><A NAME="ss10.11">10.11</A> <A HREF="FAQ.html#toc10.11">Is there an easy way of banning all Destination addresses except one?</A>
</H2>
<P>
<PRE>
acl GOOD dst 10.0.0.1
acl BAD dst 0.0.0.0/0.0.0.0
http_access allow GOOD
http_access deny BAD
</PRE>
</P>
<H2><A NAME="ss10.12">10.12</A> <A HREF="FAQ.html#toc10.12">Does anyone have a ban list of porn sites and such?</A>
</H2>
<P>
<UL>
<LI>
<A HREF="http://members.lycos.co.uk/njadmin">Jasons Staudenmayer</A></LI>
<LI>
<A HREF="http://web.onda.com.br/orso/">Pedro Lineu Orso's List</A></LI>
<LI>
<A HREF="http://www.hklc.com/squidblock/">Linux Center Hong Kong's List</A></LI>
<LI>Snerpa, an ISP in Iceland operates a DNS-database of
IP-addresses of blacklisted sites containing porn, violence,
etc. which is utilized using a small perl-script redirector.
Information on this on the
<A HREF="http://www.snerpa.is/notendur/infilter/infilter-en.phtml">INfilter</A> webpage.</LI>
<LI>The
<A HREF="http://www.squidguard.org/blacklist/">SquidGuard</A>
redirector folks provide a blacklist.</LI>
</UL>
</P>
<H2><A NAME="ss10.13">10.13</A> <A HREF="FAQ.html#toc10.13">Squid doesn't match my subdomains</A>
</H2>
<P>NOTE: Current Squid versions (as of Squid-2.4) will warn you
when this kind of configuration is used. Also the configuration here uses
the dstdomain syntax of Squid-2.1 or earlier.. (2.2 and later needs to
have domains prefixed by a dot)</P>
<P>There is a subtle problem with domain-name based access controls
when a single ACL element has an entry that is a subdomain of
another entry. For example, consider this list:
<PRE>
acl FOO dstdomain boulder.co.us vail.co.us co.us
</PRE>
</P>
<P>In the first place, the above list is simply wrong because
the first two (<EM>boulder.co.us</EM> and <EM>vail.co.us</EM>) are
unnecessary. Any domain name that matches one of the first two
will also match the last one (<EM>co.us</EM>). Ok, but why does this
happen?</P>
<P>The problem stems from the data structure used to index domain
names in an access control list. Squid uses <EM>Splay trees</EM>
for lists of domain names. As other tree-based data structures,
the searching algorithm requires a comparison function that returns
-1, 0, or +1 for any pair of keys (domain names). This is similar
to the way that <EM>strcmp()</EM> works.</P>
<P>The problem is that it is wrong to say that <EM>co.us</EM> is greater-than,
equal-to, or less-than <EM>boulder.co.us</EM>.</P>
<P>For example, if you
said that <EM>co.us</EM> is LESS than <EM>fff.co.us</EM>, then
the Splay tree searching algorithm might never discover
<EM>co.us</EM> as a match for <EM>kkk.co.us</EM>.</P>
<P>similarly, if you said that <EM>co.us</EM> is GREATER than <EM>fff.co.us</EM>,
then the Splay tree searching algorithm might never
discover <EM>co.us</EM> as a match for <EM>bbb.co.us</EM>.</P>
<P>The bottom line is that you can't have one entry that is a subdomain
of another. Squid-2.2 will warn you if it detects this condition.</P>
<H2><A NAME="ss10.14">10.14</A> <A HREF="FAQ.html#toc10.14">Why does Squid deny some port numbers?</A>
</H2>
<P>It is dangerous to allow Squid to connect to certain port numbers.
For example, it has been demonstrated that someone can use Squid
as an SMTP (email) relay. As I'm sure you know, SMTP relays are
one of the ways that spammers are able to flood our mailboxes.
To prevent mail relaying, Squid denies requests when the URL port
number is 25. Other ports should be blocked as well, as a precaution.</P>
<P>There are two ways to filter by port number: either allow specific
ports, or deny specific ports. By default, Squid does the first. This
is the ACL entry that comes in the default <EM>squid.conf</EM>:
<PRE>
acl Safe_ports port 80 21 443 563 70 210 1025-65535
http_access deny !Safe_ports
</PRE>
The above configuration denies requests when the URL port number is
not in the list. The list allows connections to the standard
ports for HTTP, FTP, Gopher, SSL, WAIS, and all non-priveleged
ports.</P>
<P>Another approach is to deny dangerous ports. The dangerous
port list should look something like:
<PRE>
acl Dangerous_ports 7 9 19 22 23 25 53 109 110 119
http_access deny Dangerous_ports
</PRE>
...and probably many others.</P>
<P>Please consult the <EM>/etc/services</EM> file on your system
for a list of known ports and protocols.</P>
<H2><A NAME="ss10.15">10.15</A> <A HREF="FAQ.html#toc10.15">Does Squid support the use of a database such as mySQL for storing the ACL list?</A>
</H2>
<P><EM>Note: The information here is current for version 2.2.</EM></P>
<P>No, it does not.</P>
<H2><A NAME="ss10.16">10.16</A> <A HREF="FAQ.html#toc10.16">How can I allow a single address to access a specific URL?</A>
</H2>
<P>This example allows only the <EM>special_client</EM> to access
the <EM>special_url</EM>. Any other client that tries to access
the <EM>special_url</EM> is denied.
<PRE>
acl special_client src 10.1.2.3
acl special_url url_regex ^http://www.squid-cache.org/Doc/FAQ/$
http_access allow special_client special_url
http_access deny special_url
</PRE>
</P>
<H2><A NAME="ss10.17">10.17</A> <A HREF="FAQ.html#toc10.17">How can I allow some clients to use the cache at specific times?</A>
</H2>
<P>Let's say you have two workstations that should only be allowed access
to the Internet during working hours (8:30 - 17:30). You can use
something like this:
<PRE>
acl FOO src 10.1.2.3 10.1.2.4
acl WORKING time MTWHF 08:30-17:30
http_access allow FOO WORKING
http_access deny FOO
</PRE>
</P>
<H2><A NAME="ss10.18">10.18</A> <A HREF="FAQ.html#toc10.18">How can I allow some users to use the cache at specific times?</A>
</H2>
<P>
<PRE>
acl USER1 proxy_auth Dick
acl USER2 proxy_auth Jane
acl DAY time 06:00-18:00
http_access allow USER1 DAY
http_access deny USER1
http_access allow USER2 !DAY
http_access deny USER2
</PRE>
</P>
<H2><A NAME="ss10.19">10.19</A> <A HREF="FAQ.html#toc10.19">Problems with IP ACL's that have complicated netmasks</A>
</H2>
<P><EM>Note: The information here is current for version 2.3.</EM></P>
<P>The following ACL entry gives inconsistent or unexpected results:
<PRE>
acl restricted src 10.0.0.128/255.0.0.128 10.85.0.0/16
</PRE>
The reason is that IP access lists are stored in ``splay'' tree
data structures. These trees require the keys to be sortable.
When you use a complicated, or non-standard, netmask (255.0.0.128), it confuses
the function that compares two address/mask pairs.</P>
<P>The best way to fix this problem is to use separate ACL names
for each ACL value. For example, change the above to:
<PRE>
acl restricted1 src 10.0.0.128/255.0.0.128
acl restricted2 src 10.85.0.0/16
</PRE>
</P>
<P>Then, of course, you'll have to rewrite your <EM>http_access</EM>
lines as well.</P>
<H2><A NAME="ss10.20">10.20</A> <A HREF="FAQ.html#toc10.20">Can I set up ACL's based on MAC address rather than IP?</A>
</H2>
<P>Yes, for some operating systes. Squid calls these ``ARP ACLs'' and
they are supported on Linux, Solaris, and probably BSD variants.</P>
<P>NOTE: Squid can only determine the MAC address for clients that
are on the same subnet. If the client is on a different subnet,
then Squid can not find out its MAC address.</P>
<P>To use ARP (MAC) access controls, you
first need to compile in the optional code. Do this with
the <EM>--enable-arp-acl</EM> configure option:
<PRE>
% ./configure --enable-arp-acl ...
% make clean
% make
</PRE>
If <EM>src/acl.c</EM> doesn't compile, then ARP ACLs are probably not
supported on your system.</P>
<P>If everything compiles, then you can add some ARP ACL lines to
your <EM>squid.conf</EM>:
<PRE>
acl M1 arp 01:02:03:04:05:06
acl M2 arp 11:12:13:14:15:16
http_access allow M1
http_access allow M2
http_access deny all
</PRE>
</P>
<H2><A NAME="ss10.21">10.21</A> <A HREF="FAQ.html#toc10.21">Debugging ACLs</A>
</H2>
<P>See
<A HREF="#acl-debug">1.9 I set up my access controls, but they don't work! why?</A> and
<A HREF="FAQ-11.html#debug">11.20 Debugging Squid</A>.</P>
<H2><A NAME="ss10.22">10.22</A> <A HREF="FAQ.html#toc10.22">Can I limit the number of connections from a client?</A>
</H2>
<P>Yes, use the <EM>maxconn</EM> ACL type in conjunction with <EM>http_access deny</EM>.
For example:
<PRE>
acl losers src 1.2.3.0/24
acl 5CONN maxconn 5
http_access deny 5CONN losers
</PRE>
</P>
<P>Given the above configuration, when a client whose source IP address
is in the 1.2.3.0/24 subnet tries to establish 6 or more connections
at once, Squid returns an error page. Unless you use the
<EM>deny_info</EM> feature, the error message will just say ``access
denied.''</P>
<P>The <EM>maxconn</EM> ACL requires the client_db feature. If you've
disabled client_db (for example with <EM>client_db off</EM>) then
<EM>maxconn</EM> ALCs will not work.</P>
<P>Note, the <EM>maxconn</EM> ACL type is kind of tricky because it
uses less-than comparison. The ACL is a match when the number
of established connections is <EM>greater</EM> than the value you
specify. Because of that, you don't want to use the <EM>maxconn</EM>
ACL with <EM>http_access allow</EM>.</P>
<P>Also note that you could use <EM>maxconn</EM> in conjunction with
a user type (ident, proxy_auth), rather than an IP address type. </P>
<H2><A NAME="ss10.23">10.23</A> <A HREF="FAQ.html#toc10.23">I'm trying to deny <EM>foo.com</EM>, but it's not working.</A>
</H2>
<P>In Squid-2.3 we changed the way that Squid matches subdomains.
There is a difference between <EM>.foo.com</EM> and <EM>foo.com</EM>. The
first matches any domain in <EM>foo.com</EM>, while the latter matches
only ``foo.com'' exactly. So if you want to deny <EM>bar.foo.com</EM>,
you should write
<PRE>
acl yuck dstdomain .foo.com
http_access deny yuck
</PRE>
</P>
<H2><A NAME="ss10.24">10.24</A> <A HREF="FAQ.html#toc10.24">I want to customize, or make my own error messages.</A>
</H2>
<P>You can customize the existing error messages as described in
<A HREF="FAQ-19.html#custom-err-msgs">Customizable Error Messages</A>.
You can also create new error messages and use these in conjunction
with the <EM>deny_info</EM> option.</P>
<P>For example, lets say you want your users to see a special message
when they request something that matches your pornography list.
First, create a file named ERR_NO_PORNO in the
<EM>/usr/local/squid/etc/errors</EM> directory. That file might
contain something like this:
<PRE>
<p>
Our company policy is to deny requests to known porno sites. If you
feel you've received this message in error, please contact
the support staff (support@this.company.com, 555-1234).
</PRE>
</P>
<P>Next, set up your access controls as follows:
<PRE>
acl porn url_regex "/usr/local/squid/etc/porno.txt"
deny_info ERR_NO_PORNO porn
http_access deny porn
(additional http_access lines ...)
</PRE>
</P>
<H2><A NAME="ss10.25">10.25</A> <A HREF="FAQ.html#toc10.25">I want to use local time zone in error messages</A>
</H2>
<P>Squid by defaults uses GMT as timestamp in all geenrated error messages.
This to allow the cache to participate in a hierarchy of caches in different
timezones without risking confusion about what the time is.</P>
<P>To change the timestamp in Squid generated error messages you must change
the Squid signature. See
<A HREF="FAQ-19.html#custom-err-msgs">Customizable Error Messages</A>. The signature by defaults uses %T as timestamp, but if you like
then you can use %t instead for a timestamp using local time zone.</P>
<HR>
<A HREF="FAQ-11.html">Next</A>
<A HREF="FAQ-9.html">Previous</A>
<A HREF="FAQ.html#toc10">Contents</A>
</BODY>
</HTML>