squid 6

splendidsky

6．访问控制
6.1 访问控制元素
ACL 元素是Squid 的访问控制的基础。这里告诉你如何指定包括IP 地址，端口号，主机名，和URL 匹配等变量。每个ACL 元素有个名字，在编写访问控制规则时需要引用它们。基本的ACL 元素语法如下：
acl name type value1 value2 ...
例如：
acl Workstations src 10.0.0.0/16
在多数情况下，你能对一个ACL 元素列举多个值。你也可以有多个ACL 行使用同一个名字。例如，下列两行配置是等价的：
acl http_ports port 80 8000 8080
acl Http_ports port 80
acl Http_ports port 8000
acl Http_ports port 8080
6.1.1 一些基本的ACL 类型
Squid 大约有25 个不同的ACL 类型，其中的一些有通用基本类型。例如，src 和dst ACL使用IP 地址作为它们的基本类型。为避免冗长，我首先描述基本类型，然后在接下来章节里描述每种ACL 类型。
6.1.1.1 IP 地址
使用对象：src,dst,myip
squid 在ACL 里指定IP 地址时，拥有强有力的语法。你能以子网，地址范围，域名等形式编写地址。squid 支持标准IP 地址写法（由”.”连接的4 个小于256 的数字）和无类域间路由规范。另外，假如你忽略掩码，squid 会自动计算相应的掩码。例如，下例中的每组是相等的：
acl Foo src 172.16.44.21/255.255.255.255
acl Foo src 172.16.44.21/32
acl Foo src 172.16.44.21
acl Xyz src 172.16.55.32/255.255.255.248
acl Xyz src 172.16.55.32/28
acl Bar src 172.16.66.0/255.255.255.0
acl Bar src 172.16.66.0/24
acl Bar src 172.16.66.0
当你指定掩码时，squid 会检查你的工作。如果你的掩码在IP 地址的非零位之外，squid会告警。例如，下列行导致告警：
acl Foo src 127.0.0.1/8
aclParseIpData: WARNING: Netmask masks away part of the specified IP in 'Foo'
这里的问题是/8 掩码（255.0.0.0）在最后三个字节里都是零值，但是IP 地址127.0.0.1不是这样的。squid 警告你这个问题，以便你消除歧义。正确的写法是：
acl Foo src 127.0.0.1/32
or:
acl Foo src 127.0.0.0/8
有时候你可能想列举多个相邻子网，在这样的情况下，通过指定地址范围很容易做到。例如：
acl Bar src 172.16.10.0-172.16.19.0/24
这等价但高效于下面的行：
acl Foo src 172.16.10.0/24
acl Foo src 172.16.11.0/24
acl Foo src 172.16.12.0/24
acl Foo src 172.16.13.0/24
acl Foo src 172.16.14.0/24
acl Foo src 172.16.15.0/24
acl Foo src 172.16.16.0/24
acl Foo src 172.16.18.0/24
acl Foo src 172.16.19.0/24
注意使用IP 地址范围，掩码只能取一个。你不能为范围里的地址设置多个不同掩码。
你也能在IP ACL 里指定主机名，例如：
acl Squid dst www.squid-cache.org
squid 在启动时，将主机名转换成IP 地址。一旦启动，squid 不会对主机名的地址发起第二次DNS 查询。这样，假如在squid 运行中地址已改变，squid 不会注意到。
假如主机名被解析成多个IP 地址，squid 将每一个增加到ACL 里。注意你也可以对主机名使用网络掩码。
在基于地址的ACL 里使用主机名通常是坏做法。squid 在初始化其他组件之前，先解析配置文件，所以这些DNS 查询不使用squid 的非阻塞IP 缓存接口。代替的，它们使用阻塞机制的gethostbyname()函数。这样，将ACL 主机名转换到IP 地址的过程会延缓squid 的启动。除非绝对必要，请在src,dst,和myip ACL 里避免使用主机名。
squid 以一种叫做splay tree 的数据结构在内存里存储IP 地址ACL （ 请见http://www.link.cs.cmu.edu/splay/）。splay tree 有一些有趣的自我调整的特性，其中之一是在查询发生时，列表会自动纠正它自己的位置。当某个匹配元素在列表里发现时，该元素变成新的树根。在该方法中，最近参考的条目会移动到树的顶部，这减少了将来查询的时间。
属于同一ACL 元素的所有的子网和范围不能重迭。如果有错误，squid 会警告你。例如，如下不被允许：
acl Foo src 1.2.3.0/24
acl Foo src 1.2.3.4/32
它导致squid 在cache.log 里打印警告：
WARNING: '1.2.3.4' is a subnetwork of '1.2.3.0/255.255.255.0'
WARNING: because of this '1.2.3.4' is ignored to keep splay tree searching predictable
WARNING: You should probably remove '1.2.3.4' from the ACL named 'Foo'
在该情形下，你需要修正这个问题，可以删除其中一个ACL 值，或者将它们放置在不同的ACL 列表中。
6.1.1.2 域名
使用对象：srcdomain,dstdomain,和cache_host_domain 指令域名简单的就是DNS 名字或区域。例如，下面是有效的域名：
www.squid-cache.org
squid-cache.org
org
域名ACL 有点深奥，因为相对于匹配域名和子域有点微妙的差别。当ACL 域名以"."开头，squid 将它作为通配符，它匹配在该域的任何主机名，甚至域名自身。相反的，如果ACL 域名不以"."开头，squid 使用精确的字符串比较，主机名同样必须被严格检查。
表6-1 显示了squid 的匹配域和主机名的规则。第一列显示了取自URL 请求的主机名（或者srcdomain ACL 的客户主机名）。第二列指明是否主机名匹配lrrr.org。第三列显示是否主机名匹配.lrrr.org ACL。你能看到，唯一的不同在第二个实例里。
Table 6-1. Domain name matching
___________________________________________________________________
__URL hostname_____Matches ACL lrrr.org? ____Matches ACL .lrrr.org?
__lrrr.org_________Yes_______________________Yes
__i.am.lrrr.org____No________________________Yes
__iamlrrr.org______No________________________No
___________________________________________________________________
**说明：为了表现表格形状，“__”仅代表空格分隔符，没有任何实际意义（段誉 注释）。
域名匹配可能让人迷惑，所以请看第二个例子以便你能真正理解它。如下是两个稍微不同的ACL：
acl A dstdomain foo.com
acl B dstdomain .foo.com
用户对http://www.foo.com/的请求匹配ACL B，但不匹配A。ACL A 要求严格的字符串
匹配，然而ACL B 里领头的点就像通配符。
另外，用户对http://foo.com/的请求同时匹配A 和B。尽管在URL 主机名里的foo.com前面没有字符，但ACL B 里领头的点仍然导致一个匹配。
squid 使用splay tree 的数据结构来存储域名ACL，就像它处理IP 地址一样。然而，squid的域名匹配机制给splay tree 提供了一个有趣的问题。splay tree 技术要求唯一键去匹配任意特定搜索条目。例如，让我们假设搜索条目是i.am.lrrr.org。该主机名同时匹配.lrrr.org和.am.lrrr.org。事实上就是两个ACL 值匹配同一个主机名扰乱了splay 机制。换句话说，在配置文件里放置如下语句是错误的：
acl Foo dstdomain .lrrr.org   .am.lrrr.org
假如你这样做，squid 会产生如下警告信息：
WARNING: '.am.lrrr.org' is a subdomain of '.lrrr.org'
WARNING: because of this '.am.lrrr.org' is ignored to keep splay tree searching predictable
WARNING: You should probably remove '.am.lrrr.org' from the ACL named 'Foo'
在该情况下你应遵循squid 的建议。删除其中一条相关的域名，以便squid 明确知道你的意图。注意你能在不同的ACL 里任意使用这样的域名：
acl Foo dstdomain .lrrr.org
acl Bar dstdomain .am.lrrr.org
这是允许的，因为每个命名ACL 使用它自己的splay tree.
6.1.1.3 用户名
使用对象：ident，proxy_auth
该类型的ACL 被设计成匹配用户名。squid 可能通过RFC 1413 ident 协议或者通过HTTP验证头来获取用户名。用户名必须被严格匹配。例如，bob 不匹配bobby。squid 也有相关的ACL 对用户名使用正则表达式匹配（ident_regex 和proxy_auth_regex）。
你可以使用单词"REQUIRED"作为特殊值去匹配任意用户名。假如squid 不能查明用户名，ACL 不匹配。当使用基于用户名的访问控制时，squid 通常这样配置。
6.1.1.4 正则表达式
使用对象：srcdom_regex，dstdom_regex，url_regex，urlpath_regex，browser，referer_regex，ident_regex，proxy_auth_regex，req_mime_type，rep_mime_type
大量的ACL 使用正则表达式来匹配字符串（完整的正则表达式参考，请见O'Reilly 的Mastering Regular Expressions 一书）。对squid 来说，最常使用的正则表达式功能用以匹配字符串的开头或结尾。例如，^字符是特殊元字符，它匹配行或字符串的开头：
^http://
该正则表达式匹配任意以http://开头的URL。$也是特殊的元字符，因为它匹配行或字
符串的结尾：
.jpg$
实际上，该示例也有些错误，因为.字符也是特殊元字符。它是匹配任意单个字符的通配符。我们实际想要的应该是：
\.jpg$
反斜杠对这个"."进行转义。该正则表达式匹配以.jpg 结尾的任意字符串。假如你不使用^或$字符，正则表达式的行为就象标准子串搜索。它们匹配在字符串里任何位置出现的单词或词组。
对所有的squid 正则表达式类，你可以使用大小写敏感的选项。匹配是默认大小写敏感的。为了大小写不敏感，在ACL 类型后面使用-i 选项。例如：
acl Foo url_regex -i ^http://www
6.1.1.5 TCP 端口号
使用对象：port，myport
该类型是相对的。值是个别的端口号或端口范围。回想一下TCP 端口号是16 位值，这样它的值必须大于0 和小于65536。如下是一些示例:
acl Foo port 123
acl Bar port 1-1024
6.1.1.6 自主系统号
使用对象：src_as，dst_as
Internet 路由器使用自主系统(AS)号来创建路由表。基本上，某个AS 号指向被同一组织管理的IP 网络范围。例如，我的ISP 分配了如下网络块：134.116.0.0/16, 137.41.0.0/16, 206.168.0.0/16,和其他更多。在Internet 路由表里，这些网络被公布为属于AS 3404。当路由器转发包时，它们典型的选择经过最少AS 的路径。假如这些对你不重要，请不必关注它们。AS 基础的ACL 仅仅被网络gurus 使用。
如下是基于AS 的类型如何工作的：当squid 首先启动时，它发送一条特殊的查询到某个whois 服务器。查询语句基本是：“告诉我哪个IP 网络属于该AS 号”。这样的信息被RADB收集和管理。一旦Squid 接受到IP 网络列表，它相似的将它们作为IP 基础的ACL 对待。
基于AS 的类型仅仅在ISP 将他们的RADB 信息保持与日更新时才工作良好。某些ISP更新RADB 比其他人做得更好；而许多根本不更新它。请注意squid 仅仅在启动或者reconfigure 时才将AS 号转换为网络地址。假如ISP 更新了它的RADB 接口，除非你重启或者重配置squid，squid 不会知道这个改变。
另外的情况是，在你的squid 启动时，RADB可能不可到达。假如Squid 不能联系上RADB服务器，它从访问控制配置里删除AS 接口。默认的whois 服务器是whois.ra.net，对许多用户来说太遥远了而不可信赖。
6.1.2 ACL 类型
现在我们能把焦点放在ACL 类型自身上。我在这里按照重要性的降序来列举它们。
6.1.2.1 src
IP 地址在访问控制元素里是最普遍使用的。大部分站点使用IP 地址来控制客户允许或不允许访问Squid。src 类型指客户源IP 地址。也就是说，当src ACL 出现在访问控制列表里时，squid 将它与发布请求的客户IP 地址进行比较。
正常情况下你允许来自内网中主机的请求，并阻塞其他的。例如，假如你的单位使用192.168.0.0 子网，你可以这样指定ACL：
acl MyNetwork src 192.168.0.0
假如你有许多子网，你能在同一个acl 行里面列举它们：
acl MyNetwork src 192.168.0.0 10.0.1.0/24 10.0.5.0/24 172.16.0.0/12
squid 有许多其他ACL 类型用以检查客户地址。srcdomain 类型比较客户的完整可验证域名。它要求反向DNS 查询，这可能会延缓处理该请求。srcdom_regex ACL 是类似的，但它允许你使用正则表达式来匹配域名。最后，src_as 类型比较客户的AS 号。
6.1.2.2 dst
dst 类型指向原始服务器（目标）IP 地址。在某些情况下，你能使用该类型来阻止你的用户访问特定web 站点。然而，在使用dst ACL 时你须谨慎。大部分squid 接受到的请求有原始服务器主机名。例如：
GET http://www.web-cache.com/ HTTP/1.0
这里，www.web-cache.com 是主机名。当访问列表规则包含了dst 元素时，squid 必须找到该主机名的IP 地址。假如squid 的IP 缓存包含了该主机名的有效接口，这条ACL 被立即检测。否则，在DNS 查询忙碌时，squid 会延缓处理该请求。这对某些请求来说会造成延时。
为了避免延时，你该尽可能的使用dstdomain ACL 类型来代替dst。
如下是简单的dst ACL 示例：
acl AdServers dst 1.2.3.0/24
请注意，dst ACL 存在的问题是，你试图允许或拒绝访问的原始服务器可能会改变它的IP 地址。假如你不关心这样的改变，那就不必麻烦去升级squid.conf。你可以在acl 行里放上主机名，但那样会延缓启动速度。假如你的ACL 需要许多主机名，你也许该预处理配置文件，将主机名转换成IP 地址。
6.1.2.3 myip
myip 类型指Squid 的IP 地址，它被客户连接。当你在squid 机上运行netstat -n 时，你见到它们位于本地地址列。大部分squid 安装不使用该类型。通常所有的客户连接到同一个IP 地址，所以该ACL元素仅仅当系统有多个IP 地址时才有用。
为了理解myip为何有用，考虑某个有两个子网的公司网络。在子网1的用户是程序员和工程师。子网2包括会计，市场和其他管理部门。这样情况下的squid 有三个网络接口：一个连接子网1，一个连接子网2，第三个连接到外部因特网。
当正确的配置时，所有在子网1 的用户连接到squid 位于该子网的IP 地址，类似的，子网2 的用户连接到squid 的第二个IP 地址。这样你就可以给予子网1 的技术部员工完全的访问权，然而限制管理部门的员工仅仅能访问工作相关的站点。
ACL 可能如下：
acl Eng myip 172.16.1.5
acl Admin myip 172.16.2.5
然而请注意，使用该机制你必须特别小心，阻止来自某个子网的用户连接squid 位于另一子网的IP 地址。否则，在会计和市场子网的聪明的用户，能够通过技术部子网进行连接，从而绕过你的限制。
6.1.2.4 dstdomain
在某些情况下，你发现基于名字的访问控制非常有用。你可以使用它们去阻塞对某些站点的访问，去控制squid 如何转发请求，以及让某些响应不可缓存。dstdomain 之所以非常有用，是因为它检查请求url 里的主机名。
然而首先我想申明如下两行的不同：
acl A dst www.squid-cache.org
acl B dstdomain www.squid-cache.org
A 实际上是IP 地址ACL。当Squid 解析配置文件时，它查询www.squid-cache.org 的IP地址，并将它们存在内存里。它不保存名字。假如在squid 运行时IP 地址改变了，squid 会继续使用旧的地址。
然而dstdomain ACL 以域名形式存储，并非IP 地址。当squid 检查ACL B 时，它对URL的主机名部分使用字符串比较功能。在该情形下，它并不真正关心是否www.squid-cache.org
的IP 地址改变了。
使用dstdomain ACL 的主要问题是某些URL 使用IP 地址代替主机名。假如你的目标是使用dstdomain ACL 来阻塞对某些站点的访问，聪明的用户能手工查询站点的IP 地址，然后将它们放在URL 里。例如，下面的2 行URL 带来同样的页面：
http://www.squid-cache.org/docs/FAQ/
http://206.168.0.9/docs/FAQ/
第一行能被dstdomain ACL 轻易匹配，但第二行不能。这样，假如你依靠dstdomain ACL，你也该同样阻塞所有使用IP 地址代替主机名的请求。请见6.3.8 章节。
6.1.2.5 srcdomain
srcdomain ACL 也有点麻烦。它要求对每个客户IP 地址进行所谓的反向DNS 查询。技术上，squid 请求对该地址的DNS PTR 记录。DNS 的响应--完整可验证域名(FQDN)--是squid匹配ACL 值的东西。（请参考O'Reilly's DNS and BIND 找到更多关于DNS PTR 记录的信息）使用dst ACL,FQDN 查询会导致延时。请求会被延缓处理直到FQDN 响应返回。FQDN响应被缓存下来，所以srcdomain 查询通常仅在客户首次请求时延时。
不幸的是，srcdomain 查询有时不能工作。许多组织并没有保持他们的反向查询数据库与日更新。假如某地址没有PTR 记录，ACL 检查失败。在该情形下，请求可能会延时非常长时间（例如2 分钟）直到DNS 查询超时。假如你使用srcdomain ACL，请确认你自己的DNS in-addr.arpa 区域配置正确并且在工作中。假如这样，你可以使用如下的ACL：
acl LocalHosts srcdomain .users.example.com
6.1.2.6 port
你很可能想使用port ACL 来限制对某些原始服务器端口号的访问。就像我即将讲到的，squid 其实不连接到某些服务，例如email 和IRC 服务。port ACL 允许你定义单独的端口或端口范围。例如：
acl HTTPports port 80 8000-8010 8080
HTTP 在设计上与其他协议类似，例如SMTP。这意味着聪明的用户通过转发email 消息到SMTP 服务器能欺骗squid。Email 转发是垃圾邮件的主要原因之一，我们必须处理它们。历史上，垃圾邮件有真正的邮件服务器。然而近来，越来越多的垃圾邮件制造者使用开放HTTP 代理来隐藏他们的踪迹。你肯定不想Squid 被当成垃圾邮件转发器。假如是这样，你的IP 地址很可能被许多邮件转发黑名单冻结（MAPS,ORDB,spamhaus 等）。除email 之外，还有其他许多TCP/IP 服务是squid 不与其通信的。这些包括IRC,Telnet,POP,和NNTP。你的针对端口的策略必须被配置成拒绝已知危险端口，并允许剩下的；或者允许已知安全端口，并拒绝剩下的。
我的态度比较保守，仅仅允许安全的端口。默认的squid.conf 包含了下面的安全端口ACL：
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
http_access deny !Safe_ports
这是个较明智的配置。它允许用户连接到任何非特权端口（1025－65535），但仅仅指定的特权端口可以被连接。假如你的用户试图访问某个URL如下：http://www.lrrr.org:123/，squid会返回访问拒绝错误消息。在某些情形下，为了让你的用户满意，你可能需要增加另外的端口号。
宽松的做法是，拒绝对特别危险的端口的访问。Squid FAQ 包括了如下示例：
acl Dangerous_ports 7 9 19 22 23 25 53 109 110 119
http_access deny Dangerous_ports
使用Dangerous_ports 的弊端是squid 对几乎每个请求都要搜索整个列表。这对CPU 造成了额外的负担。大多数情况下，99%到达squid的请求是对80端口的，它不出现在危险端口列表里。所有请求对该表的搜索不会导致匹配。当然，整数比较是快速的操作，不会显然影响性能。
（译者注：这里的意思是，两者都要对列表进行搜索和匹配。在第一种情况下，它搜索安全端口列表并匹配80，显然第一个元素就匹配成功了。而第二种情况中，会搜索危险端口列表并试图匹配80，当然危险端口不会包括80，所以每次对80 的请求都要搜索完整个列表，这样就会影响性能。）
6.1.2.7 myport
squid 也有myport ACL。port ACL 指向原始服务器的端口号，myport 指向squid 自己的端口号，用以接受客户请求。假如你在http_port 指令里指定不止一个端口号，那么squid 就可以在不同的端口上侦听。
假如你将squid 作为站点HTTP 加速器和用户代理服务器，那么myport ACL 特别有用。你可以在80 上接受加速请求，在3128 上接受代理请求。你可能想让所有人访问加速器，但仅仅你自己的用户能以代理形式访问squid。你的ACL 可能如下：
acl AccelPort myport 80
acl ProxyPort myport 3128
acl MyNet src 172.16.0.0/22
http_access allow AccelPort # anyone
http_access allow ProxyPort MyNet # only my users
http_access deny ProxyPort # deny others
6.1.2.8 method
method ACL 指HTTP 请求方法。GET 是典型的最常用方法，接下来是POST,PUT，和其他。下例说明如何使用method ACL：
acl Uploads method PUT POST
Squid 知道下列标准HTTP 方法：GET, POST, PUT, HEAD, CONNECT, TRACE,OPTIONS 和DELETE。另外，squid 了解下列来自WEBDAV 规范，RFC 2518 的方法：PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK。某些Microsoft 产品使用非标准的WEBDAV 方法，所以squid 也了解它们：BMOVE, BDELETE, BPROPFIND。最后，你可以在extension_methods 指令里配置squid 去理解其他的请求方法。请见附录A。
注意CONNECT 方法非常特殊。它是用于通过HTTP 代理来封装某种请求的方法（请见RFC 2817:Upgrading to TLS Within HTTP/1.1）。在处理CONNECT 方法和远程服务器的端口号时应特别谨慎。就像前面章节讲过的一样，你不希望squid 连接到某些远程服务。你该限制CONNECT 方法仅仅能连接到HTTPS/SSL 或NNTPS 端口（443 和563）。默认的squid.conf 这样做：
acl CONNECT method CONNECT
acl SSL_ports 443 563
http_access allow CONNECT SSL_ports
http_access deny CONNECT
在该配置里，squid 仅仅允许加密请求到端口443（HTTPS/SSL）和563（NNTPS）。CONNECT 方法对其他端口的请求都被拒绝。
PURGE 是另一个特殊的请求方法。它是Squid 的专有方法，没有在任何RFC 里定义。它让管理员能强制删除缓存对象。既然该方法有些危险，squid 默认拒绝PURGE 请求，除非你定义了ACL 引用了该方法。否则，任何能访问cache 者也许能够删除任意缓存对象。我推荐仅仅允许来自localhost 的PURGE:
acl Purge method PURGE
acl Localhost src 127.0.0.1
http_access allow Purge Localhost
http_access deny Purge
关于从squid 的缓存里删除对象，请见7.6 章。
6.1.2.9 proto
该类型指URI 访问（或传输）协议。如下是有效值：http, https (same as HTTP/TLS), ftp,gopher, urn, whois, 和cache_object。也就是说，这些是被squid 支持的URL 机制名字。例如，假如你想拒绝所有的FTP 请求，你可以使用下列指令：
acl FTP proto FTP
http_access deny FTP
cache_object机制是squid的特性。它用于访问squid的缓存管理接口，我将在14.2 章讨论它。不幸的是，它并非好名字，可能会被改变。
默认的squid.conf 文件有许多行限制缓存管理访问：
acl Manager proto cache_object
acl Localhost src 127.0.0.1
http_access allow Manager Localhost
http_access deny Manager
这些配置行仅允许来自本机地址的缓存管理请求，所有其他的缓存管理请求被拒绝。这意味着在squid 机器上有帐号的人，能访问到潜在的敏感缓存管理信息。你也许想修改缓存管理访问控制，或对某些页面使用密码保护。我将在14.2.2 章里谈论到。
6.1.2.10 time
time ACL 允许你控制基于时间的访问，时间为每天中的具体时间，和每周中的每天。日期以单字母来表示，见如下表。时间以24 小时制来表示。开始时间必须小于结束时间，这样在编写跨越0 点的time ACL 时可能有点麻烦。
Code____Day
-----------------
S_______Sunday
M_______Monday
T_______Tuesday
W_______Wednesday
H_______Thursday
F_______Friday
A_______Saturday
D_______All weekdays (M-F)
-----------------
日期和时间由localtime()函数来产生。请确认你的计算机位于正确的时区，你也该让你的时钟与标准时间同步。
为了编写time ACL 来匹配你的工作时间，你可以这样写：
acl Working_hours MTWHF 08:00-17:00
or:
acl Working_hours D 08:00-17:00
让我们看一个麻烦的例子。也许你是某个ISP，在下午8 点到早上4 点这段不忙的时间内放松访问。既然该时间跨越子夜，你不能编写“20:00-04:00”。代替的，你需要把它们分成两个ACL 来写，或者使用否定机制来定义非忙时。例如：
acl Offpeak1 20:00-23:59
acl Offpeak2 00:00-04:00
http_access allow Offpeak1 ...
http_access allow Offpeak2 ...
另外，你可以这样写：
acl Peak 04:00-20:00
http_access allow !Peak ...
尽管squid 允许，你也不应该在同一个time ACL 里放置多个日期和时间范围列表。对这些ACL 的解析不一定是你想象的那样。例如，假如你输入：
acl Blah time M 08:00-10:00 W 09:00-11:00
实际能做到的是：
acl Blah time MW 09:00-11:00
解析仅仅使用最后一个时间范围。正确的写法是，将它们写进两行：
acl Blah time M 08:00-10:00
acl Blah time W 09:00-11:00
6.1.2.11 ident
ident ACL 匹配被ident 协议返回的用户名。这是个简单的协议，文档是RFC 1413。它工作过程如下：
1.用户代理（客户端）对squid 建立TCP 连接。
2.squid 连接到客户系统的ident 端口（113）。
3.squid 发送一个包括两个TCP 端口号的行。squid 端的端口号可能是3128（或者你在squid.conf 里配置的端口号），客户端的端口号是随机的。
4.客户端的ident 服务器返回打开第一个连接的进程的用户名。
5.squid 记录下用户名用于访问控制目的，并且记录到access.log。
当squid 遇到对特殊请求的ident ACL 时，该请求被延时，直到ident 查询完成。这样，ident ACL 可以对你的用户请求造成延时。
我们推荐仅仅在本地局域网中，并且大部分客户工作站运行ident 服务时，才使用ident ACL。假如squid 和客户工作站连在一个局域网里，ident ACL 工作良好。跨广域网使用ident难以成功。
ident 协议并非很安全。恶意的用户能替换他们的正常ident 服务为假冒服务，并返回任意的他们选择的用户名。例如，假如我知道从administrator 用户的连接总是被允许，那么我可以写个简单的程序，在回答每个ident 请求时都返回这个用户名。
你可以使用ident ACL 拦截cache（请见第9 章）。当squid 被配置成拦截cache 时，操作系统假设它自己是原始服务器。这意味着用于拦截TCP 连接的本地socket 地址有原始服务器的IP 地址。假如你在squid 上运行netstat -n 时，你可以看到大量的外部IP 地址出现在本地地址栏里。当squid 发起一个ident 查询时，它创建一个新的TCP 套接字，并绑定本地终点到同一个IP 地址上，作为客户TCP 连接的本地终点。既然本地地址并非真正是本地的（它可能与原始服务器IP 地址相距遥远），bind()系统调用失败。squid 将这个作为失败的ident查询来处理。
注意squid也有个特性，对客户端执行懒惰ident 查询。在该情形下，在等待ident 查询时，请求不会延时。在HTTP 请求完成时，squid 记录ident 信息，假如它可用。你能使用ident_lookup_access 指令来激活该特性，我将在本章后面讨论。
6.1.2.12 proxy_auth
squid 有一套有力的，在某种程度上有点混乱的特性，用以支持HTTP 代理验证功能。使用代理验证，客户的包括头部的http 请求包含了验证信用选项。通常，这简单的是用户名和密码。squid 解密信用选项，并调用外部验证程序以发现该信用选项是否有效。
squid 当前支持三种技术以接受用户验证：HTTP 基本协议，数字认证协议，和NTLM。基本认证已经发展了相当长时间。按今天的标准，它是非常不安全的技术。用户名和密码以明文同时发送。数字认证更安全，但也更复杂。基本和数字认证在RFC 2617 文档里被描述。NTLM 也比基本认证更安全。然而，它是Microsoft 发展的专有协议。少数squid 开发者已经基本完成了对它的反向工程。
为了使用代理验证，你必须配置squid 使用大量的外部辅助程序。squid 源代码里包含了一些程序，用于对许多标准数据库包括LDAP,NTLM,NCSA 类型的密码文件，和标准Unix密码数据库进行认证。auth_param 指令控制对所有辅助程序的配置。我将在12 章里讨论这些细节。
auth_param 指令和proxy_auth ACL 是少数在配置文件里顺序重要的实例。你必须在proxy_auth ACL 之前定义至少一个验证辅助程序（使用auth_param）。假如你没有这样做，squid 打印出错误消息，并且忽略proxy_auth ACL。这并非致命错误，所以squid 可以启动，但所有你的用户的请求可能被拒绝。
proxy_auth ACL 取用户名作为值。然而，大部分安装里简单的使用特殊值REQUIRED：auth_param ...
acl Auth1 proxy_auth REQUIRED
在该情况中，任何具有有效信用选项的请求会匹配该ACL。假如你需要细化控制，你可以指定独立的用户名：
auth_param ...
acl Auth1 proxy_auth allan bob charlie
acl Auth2 proxy_auth dave eric frank
代理验证不支持HTTP 拦截，因为用户代理不知道它在与代理服务器，而非原始服务器通信。用户代理不知道在请求里发送Proxy-Authorization 头部。见9.2 章更多细节。
6.1.2.13 src_as
该类型检查客户源IP 地址所属的具体AS 号（见6.1.1.6 关于squid 如何将AS 号映射到IP 地址的信息）。作为示例， 我们虚构某ISP 使用AS 64222 并且通告使用10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 网络。你可以编写这样的ACL，它允许来自该ISP 地址空间的任何主机请求：
acl TheISP src 10.0.0.0/8
acl TheISP src 172.16.0.0/12
acl TheISP src 192.168.0.0/16
http_access allow TheISP
当然，你还可以这样写：
acl TheISP src_as 64222
http_access allow TheISP
第二种写法不但更短，而且假如ISP 增加了新的网络，你不必更新ACL 配置。
6.1.2.14 dst_as
dst_as ACL 经常与cache_peer_access 指令一起使用。在该方法中，squid 使用与IP 路由一致的方式转发cache 丢失。考虑某ISP，它比其他ISP 更频繁的更换路由。每个ISP 处理他们自己的cache 代理，这些代理能转发请求到其他代理。理论上，ISP A 将ISP B 网络里主机的cache 丢失转发到ISP B 的cache 代理。使用AS ACL 和cache_peer_access 指令容易做到这点：
acl ISP-B-AS dst_as 64222
acl ISP-C-AS dst_as 64333
cache_peer proxy.isp-b.net parent 3128 3130
cache_peer proxy.isp-c.net parent 3128 3130
cache_peer_access proxy.isb-b.net allow ISP-B-AS
cache_peer_access proxy.isb-c.net allow ISP-C-AS
我将在第10 章里讨论更多关于cache 协作。
6.1.2.15 snmp_community
snmp_community ACL 对SNMP 查询才有意义，后者被snmp_access 指令控制。例如，你可以这样写：
acl OurCommunityName snmp_community hIgHsEcUrItY
acl All src 0/0
snmp_access allow OurCommunityName
snmp_access deny All
在该情况中，假如community 名字设置为hIgHsEcUrItY，SNMP 查询才被允许。
6.1.2.16 maxconn
maxconn ACL 指来自客户IP 地址的大量同时连接。某些squid 管理员发现这是个有用的方法，用以阻止用户滥用代理或者消耗过多资源。
maxconn ACL 在请求超过指定的数量时，会匹配这个请求。因为这个理由，你应该仅仅在deny 规则里使用maxconn。考虑如下例子：
acl OverConnLimit maxconn 4
http_access deny OverConnLimit
在该情况中，squid 允许来自每个IP 地址的同时连接数最大为4 个。当某个客户发起第五个连接时，OverConnLimit ACL 被匹配，http_access 规则拒绝该请求。
6.1.2.17 arp
arp ACL 用于检测cache 客户端的MAC 地址（以太网卡的物理地址）。地址解析协议（ARP）是主机查找对应于IP 地址的MAC 地址的方法。某些大学学生发现，在Microsoft Windows 下，他们可以改变系统的IP 地址到任意值，然后欺骗squid 的基于地址的控制。这时arp 功能就派上用场了，聪明的系统管理员会配置squid 检查客户的以太网地址。
不幸的是，该特性使用非移植性代码。假如你运行Solaris 或Linux，你能使用arp ACL。其他系统不行。当你运行./configure 时增加--enable-arp-acl 选项，就可以激活该功能。
arp ACL 有另一个重要限制。ARP 是数据链路层协议，假如客户主机和squid 在同一子网，它才能工作。你不容易发现不同子网主机的MAC 地址。假如在squid 和你的用户之间有路由器存在，你可能不能使用arp ACL。
现在你知道何时去使用它们，让我们看看arp ACL 实际上是怎样的。它的值是以太网地址，当使用ifconfig 和arp 时你能看到以太网地址。例如：
acl WinBoxes arp 00:00:21:55:ed:22
acl WinBoxes arp 00:00:21:ff:55:38
6.1.2.18 srcdom_regex
srcdom_regex ACL 允许你使用正则表达式匹配客户域名。这与srcdomain ACL 相似，它使用改进的的子串匹配。相同的限制是：某些客户地址不能反向解析到域名。作为示例，下面的ACL 匹配以dhcp 开头的主机名：
acl DHCPUser srcdom_regex -i ^dhcp
因为领头的^ 符号， 该ACL 匹配主机名dhcp12.example.com ， 但不匹配host12.dhcp.example.com。
6.1.2.19 dstdom_regex
dstdom_regex ACL 也与dstdomain 相似。下面的例子匹配以www 开头的主机名：
acl WebSite dstdom_regex -i ^www\.
如下是另一个有用的正则表达式，用以匹配在URL 主机名里出现的IP 地址：
acl IPaddr dstdom_regex [0-9]$
这样可以工作，因为squid 要求URL 主机名完全可验证。既然全局顶级域名中没有以数字结尾的，该ACL 仅仅匹配IP 地址，它以数字结尾。
6.1.2.20 url_regex
url_regex ACL 用于匹配请求URL 的任何部分，包括传输协议和原始服务器主机名。例如，如下ACL 匹配从FTP 服务器的MP3 文件请求：
acl FTPMP3 url_regex -i ^ftp://.*\.mp3$
6.1.2.21 urlpath_regex
urlpath_regex 与url_regex 非常相似，不过传输协议和主机名不包含在匹配条件里。这让某些类型的检测非常容易。例如，假设你必须拒绝URL 里的"sex"，但仍允许在主机名里含有"sex"的请求，那么这样做：
acl Sex urlpath_regex sex
另一个例子，假如你想特殊处理cgi-bin 请求，你能这样捕获它们：
acl CGI1 urlpath_regex ^/cgi-bin
当然，CGI 程序并非总在/cgi-bin/目录下，这样你应该编写其他的ACL 来捕获它们。
6.1.2.22 browser
大部分HTTP 请求包含了User-Agent 头部。该头部的值典型如下：
Mozilla/4.51 [en] (X11; I; Linux 2.2.5-15 i686)
browser ACL 对user-agent 头执行正则表达式匹配。例如，拒绝不是来自Mozilla 浏览器的请求，可以这样写：
acl Mozilla browser Mozilla
http_access deny !Mozilla
在使用browser ACL 之前，请确认你完全理解cache 接受到的User-Agent 字符串。某些user-agent 与它们的来源相关。甚至squid 可以重写它转发的请求的User-Agent 头部。某些浏览器例如Opera 和KDE 的Konqueror，用户可以对不同的原始服务器发送不同的user-agent字串，或者干脆忽略它们。
6.1.2.23 req_mime_type
req_mime_type ACL 指客户HTTP 请求里的Content-Type 头部。该类型头部通常仅仅出现在请求消息主体里。POST 和PUT 请求可能包含该头部，但GET 从不。你能使用该类型ACL 来检测某些文件上传，和某些类型的HTTP 隧道请求。
req_mime_type ACL 值是正则表达式。你可以这样编写ACL 去捕获音频文件类型：
acl AuidoFileUploads req_mime_type -i ^audio/
6.1.2.24 rep_mime_type
该类型ACL 指原始服务器的HTTP 响应里的Content-Type 头部。它仅在使用http_reply_access 规则时才有用。所有的其他访问控制形式是基于客户端请求的。该ACL 基于服务器响应。
假如你想使用squid 阻塞Java 代码，你可以这样写：
acl JavaDownload rep_mime_type application/x-java
http_reply_access deny JavaDownload
6.1.2.25 ident_regex
在本节早些时讲过ident ACL。ident_regex 允许你使用正则表达式，代替严格的字符串匹配，这些匹配是对ident 协议返回的用户名进行。例如，如下ACL 匹配包含数字的用户名：
acl NumberInName ident_regex [0-9]
6.1.2.26 proxy_auth_regex
该ACL 允许对代理认证用户名使用正则表达式。例如， 如下ACL 匹配
admin,administrator 和administrators:
acl Admins proxy_auth_regex -i ^admin
6.1.3 外部ACL
Squid 2.5 版本介绍了一个新特性：外部ACL。你可以指示squid 发送某些信息片断到外部进程，然后外部的辅助程序告诉squid，数据匹配或不匹配。
squid 附带着大量的外部ACL 辅助程序；大部分用于确定命名用户是不是某个特殊组的成员。请见12.5 章关于这些程序的描述，以及关于如何编写你自己的程序的信息。现在，我解释如何定义和使用外部ACL 类型。
external_acl_type 指令定

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/35234/showart_331928.html