ACL文档格式.docx

上传人:b****5 文档编号:16874475 上传时间:2022-11-26 格式:DOCX 页数:13 大小:25.45KB
下载 相关 举报
ACL文档格式.docx_第1页
第1页 / 共13页
ACL文档格式.docx_第2页
第2页 / 共13页
ACL文档格式.docx_第3页
第3页 / 共13页
ACL文档格式.docx_第4页
第4页 / 共13页
ACL文档格式.docx_第5页
第5页 / 共13页
点击查看更多>>
下载资源
资源描述

ACL文档格式.docx

《ACL文档格式.docx》由会员分享,可在线阅读,更多相关《ACL文档格式.docx(13页珍藏版)》请在冰豆网上搜索。

ACL文档格式.docx

也就是说修改一条或删除一条都会影响到整个ACL列表。

这一个缺点影响了我们的工作,为我们带来了繁重的负担。

不过我们可以用基于名称的访问控制列表来解决这个问题。

基于名称的访问控制列表

反向访问控制列表:

我们使用访问控制列表除了合理管理网络访问以外还有一个更重要的方面,那就是防范病毒,我们可以将平时常见病毒传播使用的端口进行过滤,将使用这些端口的数据包丢弃。

这样就可以有效的防范病毒的攻击。

不过即使再科学的访问控制列表规则也可能会因为未知病毒的传播而无效,毕竟未知病毒使用的端口是我们无法估计的,而且随着防范病毒数量的增多会造成访问控制列表规则过多,在一定程度上影响了网络访问的速度。

这时我们可以使用反向控制列表来解决以上的问题。

反向访问控制列表的用途及格式 

反向访问控制列表配置实例

基于时间的访问控制列表:

上面我们介绍了标准ACL与扩展ACL,实际上我们数量掌握了这两种访问控制列表就可以应付大部分过滤网络数据包的要求了。

不过实际工作中总会有人提出这样或那样的苛刻要求,这时我们还需要掌握一些关于ACL的高级技巧。

基于时间的访问控制列表就属于高级技巧之一。

基于时间的访问控制列表

基于时间的访问控制列表配置实例

访问控制列表流量记录

网络管理员就是要能够合理的管理公司的网络,俗话说知己知彼方能百战百胜,所以有效的记录ACL流量信息可以第一时间的了解网络流量和病毒的传播方式。

下面这篇文章就为大家简单介绍下如何保存访问控制列表的流量信息,方法就是在扩展ACL规则最后加上LOG命令。

访问控制列表流量的记录

访问控制列表使用原则

1、最小特权原则

只给受控对象完成任务所必须的最小的权限。

也就是说被控制的总规则是各个规则的交集,只满足部分条件的是不容许通过规则的。

2、最靠近受控对象原则

所有的网络层访问权限控制。

也就是说在检查规则时是采用自上而下在ACL中一条条检测的,只要发现符合条件了就立刻转发,而不继续检测下面的ACL语句。

3、默认丢弃原则

在CISCO路由交换设备中默认最后一句为ACL中加入了DENYANYANY,也就是丢弃所有不符合条件的数据包。

这一点要特别注意,虽然我们可以修改这个默认,但未改前一定要引起重视。

由于ACL是使用包过滤技术来实现的,过滤的依据又仅仅只是第三层和第四层包头中的部分信息,这种技术具有一些固有的局限性,如无法识别到具体的人,无法识别到应用内部的权限级别等。

因此,要达到端到端的权限控制目的,需要和系统级及应用级的访问权限控制结合使用。

访问控制列表ACL分很多种,不同场合应用不同种类的ACL。

其中最简单的就是标准访问控制列表,他是通过使用IP包中的源IP地址进行过滤,使用的访问控制列表号1到99来创建相应的ACL。

标准访问控制列表是最简单的ACL。

它的具体格式如下:

access-listACL号permit|denyhostip地址

例如:

access-list10denyhost192.168.1.1这句命令是将所有来自192.168.1.1地址的数据包丢弃。

当然我们也可以用网段来表示,对某个网段进行过滤。

命令如下:

access-list10deny192.168.1.00.0.0.255

通过上面的配置将来自192.168.1.0/24的所有计算机数据包进行过滤丢弃。

为什么后头的子网掩码表示的是0.0.0.255呢?

这是因为CISCO规定在ACL中用反向掩玛表示子网掩码,反向掩码为0.0.0.255的代表他的子网掩码为255.255.255.0。

小提示:

对于标准访问控制列表来说,默认的命令是HOST,也就是说access-list10deny192.168.1.1表示的是拒绝192.168.1.1这台主机数据包通讯,可以省去我们输入host命令。

术从来都是一把双刃剑,网络应用与互联网的普及在大幅提高企业的生产经营效率的同时,也带来了诸如数据的安全性,员工利用互联网做与工作不相干事等负面影响。

如何将一个网络有效的管理起来,尽可能的降低网络所带来的负面影响就成了摆在网络管理员面前的一个重要课题。

  A公司的某位可怜的网管目前就面临了一堆这样的问题。

A公司建设了一个企业网,并通过一台路由器接入到互联网。

在网络核心使用一台基于IOS的多层交换机,所有的二层交换机也为可管理的基于IOS的交换机,在公司内部使用了VLAN技术,按照功能的不同分为了6个VLAN。

分别是网络设备与网管(VLAN1,10.1.1.0/24)、内部服务器(VLAN2)、Internet连接(VLAN3)、财务部(VLAN4)、市场部(VLAN5)、研发部门(VLAN6),出口路由器上Fa0/0接公司内部网,通过s0/0连接到Internet。

每个网段的三层设备(也就是客户机上的缺省网关)地址都从高位向下分配,所有的其它节点地址均从低位向上分配。

该网络的拓朴如下图所示:

  

  自从网络建成后麻烦就一直没断过,一会儿有人试图登录网络设备要捣乱;

一会儿领导又在抱怨说互联网开通后,员工成天就知道泡网;

一会儿财务的人又说研发部门的员工看了不该看的数据。

这些抱怨都找这位可怜的网管,搞得他头都大了。

那有什么办法能够解决这些问题呢?

答案就是使用网络层的访问限制控制技术――访问控制列表(下文简称ACL)。

  那么,什么是ACL呢?

ACL是种什么样的技术,它能做什么,又存在一些什么样的局限性呢?

(详见下文)

  

ACL的基本原理、功能与局限性

  网络中常说的ACL是CiscoIOS所提供的一种访问控制技术,初期仅在路由器上支持,近些年来已经扩展到三层交换机,部分最新的二层交换机如2950之类也开始提供ACL的支持。

只不过支持的特性不是那么完善而已。

在其它厂商的路由器或多层交换机上也提供类似的技术,不过名称和配置方式都可能有细微的差别。

本文所有的配置实例均基于CiscoIOS的ACL进行编写。

  基本原理:

ACL使用包过滤技术,在路由器上读取第三层及第四层包头中的信息如源地址、目的地址、源端口、目的端口等,根据预先定义好的规则对包进行过滤,从而达到访问控制的目的。

  功能:

网络中的节点资源节点和用户节点两大类,其中资源节点提供服务或数据,用户节点访问资源节点所提供的服务与数据。

ACL的主要功能就是一方面保护资源节点,阻止非法用户对资源节点的访问,另一方面限制特定的用户节点所能具备的访问权限。

  配置ACL的基本原则:

在实施ACL的过程中,应当遵循如下两个基本原则:

  最小特权原则:

只给受控对象完成任务所必须的最小的权限

  最靠近受控对象原则:

所有的网络层访问权限控制

  局限性:

由于ACL是使用包过滤技术来实现的,过滤的依据又仅仅只是第三层和第四层包头中的部分信息,这种技术具有一些固有的局限性,如无法识别到具体的人,无法识别到应用内部的权限级别等。

因此,要达到endtoend的权限控制目的,需要和系统级及应用级的访问权限控制结合使用。

  ACL基本配置

  ACL配置技术详解

  “说那么多废话做什么,赶快开始进行配置吧。

”,A公司的网管说。

呵呵,并不是我想说那么多废话,因为理解这些基础的概念与简单的原理对后续的配置和排错都是相当有用的。

说说看,你的第一个需求是什么。

  “做为一个网管,我不期望普通用户能telnet到网络设备”――ACL基础

  “补充一点,要求能够从我现在的机器(研发VLAN的10.1.6.66)上telnet到网络设备上去。

”。

hamm,是个不错的主意,谁都不希望有人在自己的花园中撤野。

让我们分析一下,在A公司的网络中,除出口路由器外,其它所有的网络设备段的是放在Vlan1中,那个我只需要在到VLAN1的路由器接口上配置只允许源地址为10.1.6.66的包通过,其它的包通通过滤掉。

这中只管源IP地址的ACL就叫做

  标准IPACL:

  我们在SWA上进行如下的配置:

  access-list1permithost10.1.6.66

  access-list1denyany

  intvlan1

  ipaccess-group1out

  这几条命令中的相应关键字的意义如下:

  access-list:

配置均ACL的关键字,所有的ACL均使用这个命令进行配置。

  access-list后面的1:

ACL号,ACL号相同的所有ACL形成一个组。

在判断一个包时,使用同一组中的条目从上到下逐一进行判断,一遇到满足的条目就终止对该包的判断。

1-99为标准的IPACL号,标准IPACL由于只读取IP包头的源地址部分,消耗资源少。

  permit/deny:

操作。

Permit是允许通过,deny是丢弃包。

  host10.1.6.66/any:

匹配条件,等同于10.1.6.660.0.0.0。

刚才说过,标准的ACL只限制源地址。

Host10.1.6.66(10.1.6.660.0.0.0)的意思是只匹配源地址为10.1.6.66的包。

0.0.0.0是wildcards,某位的wildcards为0表示IP地址的对应位必须符合,为1表示IP地址的对应位不管是什么都行。

简单点说,就是255.255.255.255减去子网掩码后的值,0.0.0.0的wildcards就是意味着IP地址必须符合10.1.6.66,可以简称为host10.1.6.66。

any表示匹配所有地址。

  注意:

IOS中的ACL均使用wildcards,并且会用wildcards对IP地址进行严格的对齐,如你输入一条access-list1permit10.1.1.1290.0.0.31,在你showaccess-list看时,会变成access-list1permit10.1.1.1280.0.0.31,PIXOS中的ACL均使用subnetmasks,并且不会进行对齐操作。

  intvlan1///ipaccess-group1out:

这两句将access-list1应用到vlan1接口的out方向。

其中1是ACL号,和相应的ACL进行关联。

Out是对路由器该接口上哪个方向的包进行过滤,可以有in和out两种选择。

这里的in/out都是站在路由器或三层模块(以后简称R)上看的,in表示从该接口进入R的包,out表示从该接口出去的包。

  好了,这就是一个最基本的ACL的配置方法。

什么,你说普通用户还能telnet到RTA?

那你在intvlan3上现加一个ipaccess-group1out吧。

Hammmm,等等,你这样加上去普通用户就访问不了internet了。

让我们把刚才的ACL去掉,重新写一个。

  回忆一下,我们的目的是除了10.1.6.66能够进行telnet操作外,其它用户都不允许进行telnet操作。

刚才我们说过,标准的IPACL只能控制源IP地址,不能控制到端口。

要控制到第四层的端口,就需要使用到:

  扩展的IPACL的配置

  先看看配置实例吧。

在SWA上进行如下配置:

  noipaccess-group1out

  exit

  noaccess-list1

  access-list101permittcphost10.1.6.66anyeqtelnet

  access-list101denytcpanyanyeqtelnet

  ipaccess-group101out

  intvlan3

  你应该注意到到这里的ACL有一些变化了,现在对变化的部分做一些说明:

  access-list101:

注意这里的101,和刚才的标准ACL中的1一样,101是ACL号,表示这是一个扩展的IPACL。

扩展的IPACL号范围是100-199,扩展的IPACL可以控制源IP、目的IP、源端口、目的端口等,能实现相当精细的控制,扩展ACL不仅读取IP包头的源地址/目的地址,还要读取第四层包头中的源端口和目的端口,的IP在没有硬件ACL加速情况下,会消耗大量的CPU资源。

  intvlan1///noipaccess-group1out///exit///noaccess-list1:

取消access-list1,对于非命名的ACL,可以只需要这一句就可以全部取消。

注意,在取消或修改一个ACL前,必须先在它所应用的接口上先把应用给no掉,否则会导致相当严重的后果。

  tcphost10.1.6.66anyeqtelnet:

匹配条件。

完整格式为:

协议源地址源wildcards[关系][源端口]目的地址目的wildcards[关系][目的端口]。

其中协议可以是IP、TCP、UDP、EIGRP等,[]内为可选字段。

仅在协议为tcp/udp等具备端口号的协议才有用。

关系可以是eq(等于)、neq(不等于)、lt(大于)、range(范围)等。

端口一般为数字的1-65535,对于周知端口,如23(服务名为telnet)等可以用服务名代替。

源端口和目的端口不定义时表示所有端口。

  把这个ACL应用上去后,用户们开始打电话来骂娘了,因为他们都访问不了Internet了,是哪里出了问题了呢?

所有的ACL,缺省情况下,从安全角度考虑,最后都会隐含一句denyany(标准ACL)或denyipanyany(扩展IPACL)。

所以在不了解业务会使用到哪些端口的情况下,最好在ACL的最后加上一句permitipanyany,在这里就是access-list101permitipanyany。

  现在用户倒是能够访问Internet了,但我们的可怜的网管却发现普通用户还是能够telnet到他的SWA上面,因为SWA上面有很多个网络接口,而且使用扩展的ACL会消耗很多的资源。

有什么简单的办法能够控制用户对网络设备的Telnet访问,而又不消耗太多的资源呢?

这就需要使用到:

  对网络设备自身的访问如何进行控制的技术

  让我们先把刚才配置的ACL都取掉(具体配置略,不然后读者会以为我在骗稿费了。

),再在每台网络设备上均进行如下配置:

  linevty04(部分设备是15)

  access-class1in

  这样就行了,telnet都是访问的设备上的linevty,在linevty下面使用access-class与ACL组进行关联,in关键字表示控制进入的连接。

  就这么简单?

wk,你丫是不是在玩我们,为什么还要绕一大圈?

臭鸡蛋和烂西红柿开始在70的脑袋上方狂飞。

(5555555,偶也只是想向大家把ACL的基础知识讲的明白一些的嘛)。

经过刚才的配置,我们可以理出一个简单的ACL配置步骤了:

  分析需求,找清楚需求中要保护什么或控制什么;

为方便配置,最好能以表格形式列出。

在本文的后面会举例的。

  分析符合条件的数据流的路径,寻找一个最适合进行控制的位置;

  书写ACL,并将ACL应用到接口上;

  测试并修改ACL。

  当A公司的领导知道在网管能够控制普通用户对网络设备的访问后,我们的可怜的网管就收到了很多看起来很难的要求。

领导要求网管:

  ACL执行顺序

  “使用ACL技术对网络访问进行精细化控制”――ACL进阶配置

  命名的IPACL

  由于最近服务器网段的机器老是被人用telnet、rsh等手段进行攻击,我们只对员工开放web服务器(10.1.2.20)所提供的http、FTP服务器(10.1.2.22)提供的FTP服务和数据库服务器(10.1.2.21:

1521)。

好吧,我们着手进行配置,可是我们的ACL刚写到一半,发现前面写的几句好像有问题,一个no命令输进去,整个ACL都没了,唉,一切都得重来,难道就没有一个变通的办法么?

有,这里我就需要用到:

  命名的IPacl提供的两个主要优点是:

  l解决ACL号码不足的问题。

  l可以自由的删除ACL中的一条语句,而不必删除整个ACL。

  命名的ACL的主要不足之处在于无法实现在任意位置加入新的ACL条目。

比如上面那个例子中,我们进行了如下的配置:

  ipaccess-listextendserver-protect

  permittcp10.1.0.00.0.255.255host10.1.2.20eqwww

  permittcp10.0.0.00.0.255.255host10.1.2.21eq1521

  permittcp10.1.0.00.0.255.255host10.1.2.22eqftp

  配置到这里,我们发现permittcp10.0.0.00.0.255.255host10.1.2.21eq1521这句配错了,我们得把它给取掉并重新配置,OK,我样可以简单的进行如下配置:

  ipaccess-listextendserver-protect

  nopermittcp10.0.0.00.0.255.255host10.1.2.21eq1521

  permittcp10.1.0.00.0.0.255host10.1.2.21eq1521

  intvlan2

  ipaccess-groupserver-protect

  就可以了。

现在对命名的IPaccess-list的配置方法解释如下:

  ipaccess-listextendserver-access-limit:

ipaccess-list相当于使用编号的access-list中的access-list段。

extend表明是扩展的ACL(对应地,standard表示标准的ACL)。

server-access-limit是access-list的名字,相当于基于编号的ACL中的编号字段。

  permittcp10.1.6.00.0.0.255host10.1.2.21eq1521:

这一段和使用编号的access-list的后半段的意义相同,都由操作和条件两段组成。

  其实基于名字的IPACL还有一个很好的优点就是可以为每个ACL取一个有意义的名字,便于日后的管理与维护。

所以Ultra工作室强烈建议各位看官在实际工作中均使用命名的ACL。

  进一步完善对服务器数据的保护――ACL执行顺序再探讨

  在服务器网段中的数据库服务器中存放有大量的市场信息,市场部门的人员不希望研发部门访问到数据库服务器,经过协商,同意研发部门的领导的机器(IP地址为10.1.6.33)可以访问到数据库服务器。

这样,我们的服务器网段的的访问权限部分如下表所示:

协议源地址源端口目的地址目的端口操作

TCP10.1/16所有10.1.2.20/3280允许访问

TCP10.1/16所有10.1.2.22/3221允许访问

TCP10.1/16所有10.1.2.21/321521允许访问

TCP10.1.6/24所有10.1.2.21/321521禁止访问

TCP10.1.6.33/32所有10.1.2.21/321521允许访问

IP10.1/16N/A所有N/A禁止访问

  于是,网管就在server-protect后面顺序加了两条语句进去,整个ACL变成了如下形式:

ipaccess-listextendserver-protect

  permittcp10.1.0.00.0.255.255host10.1.2.21eq1521

  denytcp10.1.6.00.0.0.255host10.1.2.21eq1521

  permittcphost10.1.6.33host10.1.2.21eq1521

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

这是为什么呢?

前面我们提到过,ACL的执行顺序是从上往下执行,一个包只要遇到一条匹配的ACL语句后就会停止后续语句的执行,在我们的这个ACL中,因为前面已经有了一条permittcp10.1.0.00.0.255.255host10.1.2.21eq1521语句。

内部网上所有访问10.1.2.21的1521端口的在这儿就全部通过了,跟本不会到后面两句去比较。

所以导

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > IT计算机 > 电脑基础知识

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1