网络层访问权限控制技术-ACL详解 (2)
生活随笔
收集整理的這篇文章主要介紹了
网络层访问权限控制技术-ACL详解 (2)
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
擴展的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語句。
先看看配置實例吧。在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語句。
轉載于:https://blog.51cto.com/wgcys/28860
總結
以上是生活随笔為你收集整理的网络层访问权限控制技术-ACL详解 (2)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Log4j比较全面的配置
- 下一篇: H3C S3600-EI 系列以太网交换