网络层访问权限控制技术－ACL详解 （２）

扩展的IP ACL的配置
　　先看看配置实例吧。在SWA上进行如下配置：
　　int vlan 1
　　no ip access-group 1 out
　　exit
　　no access-list 1
　　access-list 101 permit tcp host 10.1.6.66 any eq telnet
　　access-list 101 deny tcp any any eq telnet
　　int vlan 1
　　ip access-group 101 out
　　int vlan 3
　　ip access-group 101 out
　　你应该注意到到这里的ACL有一些变化了，现在对变化的部分做一些说明：
　　access-list 101：注意这里的101，和刚才的标准ACL中的1一样，101是ACL号，表示这是一个扩展的IP ACL。扩展的IP ACL号范围是100-199，扩展的IP ACL可以控制源IP、目的IP、源端口、目的端口等，能实现相当精细的控制，扩展ACL不仅读取IP包头的源地址/目的地址，还要读取第四层包头中的源端口和目的端口，的IP在没有硬件ACL加速情况下，会消耗大量的CPU资源。
　　int vlan 1///no ip access-group 1 out///exit///no access-list 1：取消access-list 1，对于非命名的ACL，可以只需要这一句就可以全部取消。注意，在取消或修改一个ACL前，必须先在它所应用的接口上先把应用给no掉，否则会导致相当严重的后果。
　　tcp host 10.1.6.66 any eq telnet：匹配条件。完整格式为：协议 源地址 源wildcards [关系] [源端口] 目的地址 目的wildcards [关系] [目的端口]。其中协议可以是IP、TCP、UDP、EIGRP等，[]内为可选字段。仅在协议为tcp/udp等具备端口号的协议才有用。关系可以是eq(等于)、neq（不等于）、lt(大于)、range（范围）等。端口一般为数字的1-65535，对于周知端口，如23(服务名为telnet)等可以用服务名代替。源端口和目的端口不定义时表示所有端口。
　　把这个ACL应用上去后，用户们开始打电话来骂娘了，因为他们都访问不了Internet了，是哪里出了问题了呢？
　　注意：所有的ACL，缺省情况下，从安全角度考虑，最后都会隐含一句deny any(标准ACL)或deny ip any any（扩展IP ACL）。所以在不了解业务会使用到哪些端口的情况下，最好在ACL的最后加上一句permit ip any any，在这里就是access-list 101 permit ip any any。
　　现在用户倒是能够访问Internet了，但我们的可怜的网管却发现普通用户还是能够telnet到他的SWA上面，因为SWA上面有很多个网络接口，而且使用扩展的ACL会消耗很多的资源。有什么简单的办法能够控制用户对网络设备的Telnet访问，而又不消耗太多的资源呢？这就需要使用到：
　　对网络设备自身的访问如何进行控制的技术
　　让我们先把刚才配置的ACL都取掉(具体配置略，不然后读者会以为我在骗稿费了。)，再在每台网络设备上均进行如下配置：
　　access-list 1 permit host 10.1.6.66
　　line vty 0 4(部分设备是15)
　　access-class 1 in
　　这样就行了，telnet都是访问的设备上的line vty，在line vty下面使用access-class与ACL组进行关联，in关键字表示控制进入的连接。
　　就这么简单？wk，你丫是不是在玩我们，为什么还要绕一大圈？臭鸡蛋和烂西红柿开始在70的脑袋上方狂飞。(5555555，偶也只是想向大家把ACL的基础知识讲的明白一些的嘛)。经过刚才的配置，我们可以理出一个简单的ACL配置步骤了：
　　 分析需求，找清楚需求中要保护什么或控制什么；为方便配置，最好能以表格形式列出。在本文的后面会举例的。
　　 分析符合条件的数据流的路径，寻找一个最适合进行控制的位置；
　　 书写ACL，并将ACL应用到接口上；
　　 测试并修改ACL。
　　当A公司的领导知道在网管能够控制普通用户对网络设备的访问后，我们的可怜的网管就收到了很多看起来很难的要求。领导要求网管：
　　ACL执行顺序
　　“使用ACL技术对网络访问进行精细化控制”――ACL进阶配置
　　命名的IP ACL
　　由于最近服务器网段的机器老是被人用telnet、rsh等手段进行***，我们只对员工开放web服务器(10.1.2.20)所提供的http、FTP服务器(10.1.2.22)提供的FTP服务和数据库服务器(10.1.2.21：1521)。好吧，我们着手进行配置，可是我们的ACL刚写到一半，发现前面写的几句好像有问题，一个no命令输进去，整个ACL都没了，唉，一切都得重来，难道就没有一个变通的办法么？有，这里我就需要用到：
　　命名的IP acl提供的两个主要优点是：
　　l 解决ACL号码不足的问题。
　　l 可以自由的删除ACL中的一条语句，而不必删除整个ACL。
　　命名的ACL的主要不足之处在于无法实现在任意位置加入新的ACL条目。比如上面那个例子中，我们进行了如下的配置：
　　ip access-list extend server-protect
　　permit tcp 10.1.0.0 0.0.255.255 host 10.1.2.20 eq www
　　permit tcp 10.0.0.0 0.0.255.255 host 10.1.2.21 eq 1521
　　permit tcp 10.1.0.0 0.0.255.255 host 10.1.2.22 eq ftp
　　配置到这里，我们发现permit tcp 10.0.0.0 0.0.255.255 host 10.1.2.21 eq 1521这句配错了，我们得把它给取掉并重新配置，OK，我样可以简单的进行如下配置：
　　ip access-list extend server- protect
　　no permit tcp 10.0.0.0 0.0.255.255 host 10.1.2.21 eq 1521
　　permit tcp 10.1.0.0 0.0.0.255 host 10.1.2.21 eq 1521
　　exit
　　int vlan 2
　　ip access-group server- protect
　　就可以了。现在对命名的IP access-list的配置方法解释如下：
　　ip access-list extend server-access-limit：ip access-list相当于使用编号的access-list中的access-list段。extend表明是扩展的ACL(对应地，standard表示标准的ACL)。server-access-limit是access-list的名字，相当于基于编号的ACL中的编号字段。
　　permit tcp 10.1.6.0 0.0.0.255 host 10.1.2.21 eq 1521：这一段和使用编号的access-list的后半段的意义相同，都由操作和条件两段组成。
　　其实基于名字的IP ACL还有一个很好的优点就是可以为每个ACL取一个有意义的名字，便于日后的管理与维护。所以Ultra工作室强烈建议各位看官在实际工作中均使用命名的ACL。
　　进一步完善对服务器数据的保护――ACL执行顺序再探讨
　　在服务器网段中的数据库服务器中存放有大量的市场信息，市场部门的人员不希望研发部门访问到数据库服务器，经过协商，同意研发部门的领导的机器（IP地址为10.1.6.33）可以访问到数据库服务器。这样，我们的服务器网段的的访问权限部分如下表所示：
协议 源地址 源端口 目的地址 目的端口 操作
TCP 10.1/16 所有 10.1.2.20/32 80 允许访问
TCP 10.1/16 所有 10.1.2.22/32 21 允许访问
TCP 10.1/16 所有 10.1.2.21/32 1521 允许访问
TCP 10.1.6/24 所有 10.1.2.21/32 1521 禁止访问
TCP 10.1.6.33/32 所有 10.1.2.21/32 1521 允许访问
IP 10.1/16 N/A 所有 N/A 禁止访问
于是，网管就在server-protect后面顺序加了两条语句进去，整个ACL变成了如下形式：
ip access-list extend server-protect

　　 permit tcp 10.1.0.0 0.0.255.255 host 10.1.2.20 eq www

　　 permit tcp 10.1.0.0 0.0.255.255 host 10.1.2.21 eq 1521

　　 permit tcp 10.1.0.0 0.0.255.255 host 10.1.2.22 eq ftp

　　 deny tcp 10.1.6.0 0.0.0.255 host 10.1.2.21 eq 1521

　　 permit tcp host 10.1.6.33 host 10.1.2.21 eq 1521

　　做完之后发现根本没起到应有的作用，研发部门的所有机器还是可以访问到数据库服务器。这是为什么呢？

　　前面我们提到过， ACL的执行顺序是从上往下执行，一个包只要遇到一条匹配的ACL语句后就会停止后续语句的执行，在我们的这个ACL中，因为前面已经有了一条 permit tcp 10.1.0.0 0.0.255.255 host 10.1.2.21 eq 1521语句。内部网上所有访问10.1.2.21的1521端口的在这儿就全部通过了，跟本不会到后面两句去比较。所以导致达不到我们的目的。应该把server-protect这个ACL按如下形式进行修改才能满足我们的要求：

　　ip access-list extend server-protect

　　 permit tcp host 10.1.6.33 host 10.1.2.21 eq 1521

　　 deny tcp 10.1.6.0 0.0.0.255 host 10.1.2.21 eq 1521

　　 permit tcp 10.1.0.0 0.0.255.255 host 10.1.2.21 eq 1521

　　 permit tcp 10.1.0.0 0.0.255.255 host 10.1.2.20 eq www

　　 permit tcp 10.1.0.0 0.0.255.255 host 10.1.2.22 eq ftp

　　这个例子告诉我们在写ACL时，一定要遵循 最为精确匹配的ACL语句一定要写在最前面的原则，只有这样才能保证不会出现无用的ACL语句。