< Day Day Up > |
As I mentioned earlier, ACL elements are the first step in building access controls. The second step is the access control rules, where you combine elements to allow or deny certain actions. You've already seen some http_access rules in the preceding examples. Squid has a number of other access control lists:
Squid has a number of additional configuration directives that use ACL elements. Some of these used to be global settings that were modified to use ACLs to provide more flexibility.
6.2.1 Access Rule SyntaxThe syntax for an access control rule is as follows : access_list allowdeny [!] ACLname ... For example: http_access allow MyClients http_access deny !Safe_Ports http_access allow GameSites AfterHours When reading the configuration file, Squid makes only one pass through the access control lines. Thus, you must define the ACL elements (with an acl line) before referencing them in an access list. Furthermore, the order of the access list rules is very important. Incoming requests are checked in the same order that you write them. Placing the most common ACLs early in the list may reduce Squid's CPU usage.
6.2.2 How Squid Matches Access RulesRecall that Squid uses OR logic when searching ACL elements. Any single value in an acl can cause a match. It's the opposite for access rules, however. For http_access and the other rule sets, Squid uses AND logic. Consider this generic example: access_list allow ACL1 ACL2 ACL3 For this rule to be a match, the request must match each of ACL1 , ACL2 , and ACL3 . If any of those ACLs don't match the request, Squid stops searching this rule and proceeds to the next . Within a single rule, you can optimize rule searching by putting least-likely-to-match ACLs first. Consider this simple example: acl A method http acl B port 8080 http_access deny A B This http_access rule is somewhat inefficient because the A ACL is more likely to be matched than B . It is better to reverse the order so that, in most cases, Squid only makes one ACL check, instead of two: http_access deny B A One mistake people commonly make is to write a rule that can never be true. For example: acl A src 1.2.3.4 acl B src 5.6.7.8 http_access allow A B This rule is never going to be true because a source IP address can't be equal to both 1.2.3.4 and 5.6.7.8 at the same time. Most likely, someone who writes a rule like that really means this: acl A src 1.2.3.4 5.6.7.8 http_access allow A As with the algorithm for matching the values of an ACL, when Squid finds a matching rule in an access list, the search terminates. If none of the access rules result in a match, the default action is the opposite of the last rule in the list. For example, consider this simple access configuration: acl Bob ident bob http_access allow Bob Now if the user Mary makes a request, she is denied. The last (and only) rule in the list is an allow rule, and it doesn't match the username Mary . Thus, the default action is the opposite of allow , so the request is denied. Similarly, if the last entry is a deny rule, the default action is to allow the request. It is good practice always to end your access lists with explicit rules that either allow or deny all requests. To be perfectly clear, the previous example should be written this way: acl All src 0/0 acl Bob ident bob http_access allow Bob http_access deny All The src 0/0 ACL is an easy way to match each and every type of request. 6.2.3 Access List StyleSquid's access control syntax is very powerful. In most cases, you can probably think of two or more ways to accomplish the same thing. In general, you should put the more specific and restrictive access controls first. For example, rather than: acl All src 0/0 acl Net1 src 1.2.3.0/24 acl Net2 src 1.2.4.0/24 acl Net3 src 1.2.5.0/24 acl Net4 src 1.2.6.0/24 acl WorkingHours time 08:00-17:00 http_access allow Net1 WorkingHours http_access allow Net2 WorkingHours http_access allow Net3 WorkingHours http_access allow Net4 http_access deny All you might find it easier to maintain and understand the access control configuration if you write it like this: http_access allow Net4 http_access deny !WorkingHours http_access allow Net1 http_access allow Net2 http_access allow Net3 http_access deny All Whenever you have a rule with two or more ACL elements, it's always a good idea to follow it up with an opposite, more general rule. For example, the default Squid configuration denies cache manager requests that don't come from the localhost IP address. You might be tempted to write it like this: acl CacheManager proto cache_object acl Localhost src 127.0.0.1 http_access deny CacheManager !Localhost However, the problem here is that you haven't yet allowed the cache manager requests that do come from localhost. Subsequent rules may cause the request to be denied anyway. These rules have this undesirable behavior: acl CacheManager proto cache_object acl Localhost src 127.0.0.1 acl MyNet 10.0.0.0/24 acl All src 0/0 http_access deny CacheManager !Localhost http_access allow MyNet http_access deny All Since a request from localhost doesn't match MyNet , it gets denied. A better way to write the rules is like this: http_access allow CacheManager localhost http_access deny CacheManager http_access allow MyNet http_access deny All 6.2.4 Delayed ChecksSome ACLs can't be checked in one pass because the necessary information is unavailable. The ident , dst , srcdomain , and proxy_auth types fall into this category. When Squid encounters an ACL that can't be checked, it postpones the decision and issues a query for the necessary information (IP address, domain name , username, etc.). When the information is available, Squid checks the rules all over again, starting at the beginning of the list. It doesn't continue where the previous check left off. If possible, you may want to move these likely-to-be-delayed ACLs near the top of your rules to avoid unnecessary, repeated checks. Because these delays are costly (in terms of time), Squid caches the information whenever possible. Ident lookups occur for each connection , rather than each request. This means that persistent HTTP connections can really benefit you in situations where you use ident queries. Hostnames and IP addresses are cached as specified by the DNS replies, unless you're using the older external dnsserver processes. Proxy Authentication information is cached as I described previously in Section 6.1.2.12. 6.2.5 Slow and Fast Rule ChecksInternally, Squid considers some access rule checks fast , and others slow . The difference is whether or not Squid postpones its decision to wait for additional information. In other words, a slow check may be deferred while Squid asks for additional data, such as:
Some access rules use fast checks out of necessity. For example, the icp_access rule is a fast check. It must be fast, to serve ICP queries quickly. Furthermore, certain ACL types, such as proxy_auth , are meaningless for ICP queries. The following access rules are fast checks:
The following ACL types may require information from external sources (DNS, authenticators, etc.) and are thus incompatible with fast access rules:
This means, for example, that you can't reliably use an ident ACL in a header_access rule. |
< Day Day Up > |