Академический Документы
Профессиональный Документы
Культура Документы
http://wiki.squid-cache.org/SquidFaq/SquidAcl
1 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
To process a transaction another type of line is used. As each processing action needs to take place a check in run to test what action or limitations are to occur for the transaction. The types of checks are outlined in the next section Access Lists followed by details of how the checks operate.
ACL elements
The information here is current for version 3.1 see SquidConf:acl for the latest configuration guide list of available types. Squid knows about the following types of ACL elements: ***** ACL TYPES AVAILABLE ***** src: source (client) IP addresses dst: destination (server) IP addresses myip: the local IP address of a client's connection arp: Ethernet (MAC) address matching srcdomain: source (client) domain name dstdomain: destination (server) domain name srcdom_regex: source (client) regular expression pattern matching dstdom_regex: destination (server) regular expression pattern matching src_as: source (client) Autonomous System number dst_as: destination (server) Autonomous System number peername: name tag assigned to the cache_peer where request is expected to be sent. time: time of day, and day of week url_regex: URL regular expression pattern matching urlpath_regex: URL-path regular expression pattern matching, leaves out the protocol and hostname port: destination (server) port number myport: local port number that client connected to myportname: name tag assigned to the squid listening port that client connected to proto: transfer protocol (http, ftp, etc) method: HTTP request method (get, post, etc) http_status: HTTP response status (200 302 404 etc.) browser: regular expression pattern matching on the request user-agent header referer_regex: regular expression pattern matching on the request http-referer header ident: string matching on the user's name ident_regex: regular expression pattern matching on the user's name proxy_auth: user authentication via external processes proxy_auth_regex: regular expression pattern matching on user authentication via external processes snmp_community: SNMP community string matching maxconn: a limit on the maximum number of connections from a single client IP address max_user_ip: a limit on the maximum number of IP addresses one user can login from req_mime_type: regular expression pattern matching on the request content-type header req_header: regular expression pattern matching on a request header content rep_mime_type: regular expression pattern matching on the reply (downloaded content) content-type header. This is only usable in the http_reply_access directive, not http_access. rep_header: regular expression pattern matching on a reply header content. This is only usable in the http_reply_access directive, not http_access.
2 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
external: lookup via external acl helper defined by external_acl_type user_cert: match against attributes in a user SSL certificate ca_cert: match against attributes a users issuing CA SSL certificate ext_user: match on user= field returned by external acl helper defined by external_acl_type ext_user_regex: regular expression pattern matching on user= field returned by external acl helper defined by external_acl_type Notes: Not all of the ACL elements can be used with all types of access lists (described below). For example, snmp_community is only meaningful when used with SquidConf:snmp_access. The src_as and dst_as types are only used in SquidConf:cache_peer_access access lists. The arp 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. The SNMP ACL element and access list require the --enable-snmp configure option. Some ACL elements can cause processing delays. For example, use of srcdomain and srcdom_regex require a reverse DNS lookup on the client's IP address. This lookup adds some delay to the request. Each ACL element is assigned a unique name. A named ACL element consists of a list of values. When checking for a match, the multiple values use OR logic. In other words, an ACL element is matched when any one of its values is a match. You can't give the same name to two different types of ACL elements. It will generate a syntax error. You can put different values for the same ACL name on different lines. Squid combines them into one list.
Access Lists
There are a number of different access lists: SquidConf:http_access: Allows HTTP clients (browsers) to access the HTTP port. This is the primary access control list. SquidConf:http_reply_access: Allows HTTP clients (browsers) to receive the reply to their request. This further restricts permissions given by SquidConf:http_access, and is primarily intended to be used together with rep_mime_type SquidConf:acl for blocking different content types. SquidConf:icp_access: Allows neighbor caches to query your cache with ICP. SquidConf:miss_access: Allows certain clients to forward cache misses through your cache. This further restricts permissions given by SquidConf:http_access, and is primarily intended to be used for enforcing sibling relations by denying siblings from forwarding cache misses through your cache. SquidConf:cache: Defines responses that should not be cached. SquidConf:url_rewrite_access: Controls which requests are sent through the redirector pool. SquidConf:ident_lookup_access: Controls which requests need an Ident lookup. SquidConf:always_direct: Controls which requests should always be forwarded directly to origin servers. SquidConf:never_direct: Controls which requests should never be forwarded directly to origin servers. SquidConf:snmp_access: Controls SNMP client access to the cache.
3 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
SquidConf:broken_posts: Defines requests for which squid appends an extra CRLF after POST message bodies as required by some broken origin servers. SquidConf:cache_peer_access: Controls which requests can be forwarded to a given neighbor (SquidConf:cache_peer). SquidConf:htcp_access: Controls which remote machines are able to make HTCP requests. SquidConf:htcp_clr_access: Controls which remote machines are able to make HTCP CLR requests. SquidConf:request_header_access: Controls which request headers are removed when violating HTTP protocol. SquidConf:reply_header_access: Controls which reply headers are removed from delivery to the client when violating HTTP protocol. SquidConf:delay_access: Controls which requests are handled by what delay pool SquidConf:icap_access: (replaced by SquidConf:adaptation_access in Squid-3.1) What requests may be sent to a particular ICAP server. SquidConf:adaptation_access: What requests may be sent to a particular ICAP or eCAP filter service. SquidConf:log_access: Controls which requests are logged. This is global and overrides specific file access lists appended to SquidConf:access_log directives. Notes: An access list rule consists of an allow or deny keyword, followed by a list of ACL element names. An access list consists of one or more access list rules. Access list rules are checked in the order they are written. List searching terminates as soon as one of the rules is a match. If a rule has multiple ACL elements, it uses AND logic. In other words, all 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. To summarize the ACL logics can be described as: (note: AND/OR below is just for illustartion, not part of the syntax) http_access allow|deny acl AND acl AND ... OR http_access allow|deny acl AND acl AND ... OR ... If none of the rules are matched, then the default action is the opposite of the last rule in the list. Its a good idea to be explicit with the default action. The best way is to use the all ACL. For example: http_access deny all
4 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
5 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
Note that SquidConf:ident_lookup_access only permits/denies whether a machine is tested for its Ident. This does not directly alter access to the users request.
Is there a way to do ident lookups only for a certain host and compare the result with a userlist in squid.conf?
You can use the SquidConf:ident_lookup_access directive to control for which hosts Squid will issue ident lookup requests. Additionally, if you use a ident ACL in squid.conf, then Squid will make sure an ident lookup is performed while evaluating the acl even if SquidConf:ident_lookup_access does not indicate ident lookups should be performed earlier. However, 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 ident 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.
Do you have a CGI program which lets users change their own proxy passwords?
Pedro L Orso has adapted the Apache's htpasswd into a CGI program called chpasswd.cgi.
Common Mistakes
And/Or logic
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. All elements of an SquidConf:acl entry are OR'ed together. All elements of an access entry are AND'ed together (e.g. SquidConf:http_access and SquidConf:icp_access) For example, the following access control configuration will never work: acl ME src 10.0.0.1
6 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
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" SquidConf:acl AND the "YOU" SquidConf: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
allow/deny mixups
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 squidclient 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 acl server src 1.2.3.4 acl ourhosts src 1.2.0.0/24 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. if the source IP address is server, then "!server 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
7 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
http_access allow ourhosts http_access deny all If you're using SquidConf:miss_access, then don't forget to also add a SquidConf:miss_access rule for the cache manager: miss_access allow manager 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.
8 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
| USER 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. 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 SquidConf: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 Squid-2.5 allows two exceptions to this rule, by defining the appropriate SquidConf:cache_peer options: cache_peer parent.foo.com parent login=PASS This will forward the user's credentials as-is to the parent proxy which will be thus able to authenticate again. This will only work with the Basic authentication scheme. If any other scheme is enabled, it will fail cache_peer parent.foo.com parent login=*:somepassword This will perform Basic authentication against the parent, sending the username of the current client connection and as password always somepassword. The parent will need to authorization against the child cache's IP address, as if there was no authentication forwarding, and it will need to perform client authentication for all usernames against somepassword via a specially-designed authentication helper. The purpose is to log the client cache's usernames into the parent's access.log. You can find an example semi-tested helper of that kind as parent_auth.pl .
9 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
(visit http://www.proxy.org if you do not know what a web proxy is). The ACL syntax for using such a list depends on its contents. If the list contains regular expressions, use this: acl PornSites url_regex "/usr/local/squid/etc/pornlist" http_access deny PornSites On the other hand, if the list contains origin server hostnames, simply change url_regex to dstdomain in this example.
10 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
The problem is that it is wrong to say that co.us is greater-than, equal-to, or less-than boulder.co.us. For example, if you said that co.us is LESS than fff.co.us, then the Splay tree searching algorithm might never discover co.us as a match for kkk.co.us. similarly, if you said that co.us is GREATER than fff.co.us, then the Splay tree searching algorithm might never discover co.us as a match for bbb.co.us. The bottom line is that you can't have one entry that is a subdomain of another. Squid will warn you if it detects this condition.
Does Squid support the use of a database such as mySQL for storing the ACL list?
Yes, Squid supports acl interaction with external data sources via the SquidConf:external_acl_type directive. Helpers for LDAP and NT Domain group membership is included in the distribution and it's very easy to write additional helpers to fit your environment.
11 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
How can I allow some clients to use the cache at specific times?
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: acl FOO src acl WORKING http_access http_access 10.1.2.3 10.1.2.4 time MTWHF 08:30-17:30 allow FOO WORKING deny FOO
How can I allow some users to use the cache at specific times?
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
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. The best way to fix this problem is to use separate ACL names for each ACL value. For example, change the above to: acl restricted1 src 10.0.0.128/255.0.0.128 acl restricted2 src 10.85.0.0/16 Then, of course, you'll have to rewrite your SquidConf:http_access lines as well.
12 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
If src/acl.c doesn't compile, then ARP ACLs are probably not supported on your system. If everything compiles, then you can add some ARP ACL lines to your squid.conf: 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
13 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
Next, set up your access controls as follows: acl porn url_regex "/usr/local/squid/etc/porno.txt" deny_info ERR_NO_PORNO porn http_access deny porn (additional http_access lines ...)
14 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
#define ACL_NAME_SZ 32
15 de 16
http://wiki.squid-cache.org/SquidFaq/SquidAcl
need to go to the external data-source. Knowing the behaviour of an ACL type is relevant because not all ACL matching directives support all kinds of ACLs. Some check-points will not suspend the request: they allow (or deny) immediately. If a SLOW acl has to be checked, and the results of the check are not cached, the corresponding ACL result will be as if it didn't match. In other words, such ACL types are in general not reliable in all access check clauses. The following are SLOW access clauses: SquidConf:http_access SquidConf:adapted_http_access (2.x call this SquidConf:http_access2) SquidConf:http_reply_access SquidConf:url_rewrite_access SquidConf:storeurl_access SquidConf:location_rewrite_access SquidConf:always_direct SquidConf:never_direct SquidConf:cache These are instead FAST access clauses: SquidConf:icp_access SquidConf:htcp_access SquidConf:htcp_clr_access SquidConf:miss_access SquidConf:ident_lookup_access SquidConf:reply_body_max_size {R} SquidConf:authenticate_ip_shortcircuit_access SquidConf:log_access SquidConf:header_access SquidConf:delay_access SquidConf:snmp_access SquidConf:cache_peer_access SquidConf:ssl_bump SquidConf:sslproxy_cert_error SquidConf:follow_x_forwarded_for Thus the safest course of action is to only use fast ACLs in fast access clauses, and any kind of ACL in slow access clauses. A possible workaround which can mitigate the effect of this characteristic consists in exploiting caching, by setting some "useless" ACL checks in slow clauses, so that subsequent fast clauses may have a cached result to evaluate against.
16 de 16