- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- 關於我們
18-uRPF配置
本章節下載： 18-uRPF配置 (302.46 KB)
uRPF（unicast Reverse Path Forwarding，單播反向路徑轉發）是一種單播逆向路由查找技術，用來防範基於源地址欺騙的攻擊手段，例如基於源地址欺騙的DoS（Denial of Service，拒絕服務）攻擊和DDoS（Distributed Denial of Service，分布式拒絕服務）攻擊。
對於使用基於IPv4地址驗證的應用來說，基於源地址欺騙的攻擊手段可能導致未被授權用戶以他人，甚至是管理員的身份獲得訪問係統的權限。因此即使響應報文沒有發送給攻擊者或其它主機，此攻擊方法也可能會造成對被攻擊對象的破壞。
如圖1-1所示，攻擊者在Device A上偽造並向Device B發送大量源地址為2.2.2.1的報文，Device B響應這些報文並向真正的“2.2.2.1”（Device C）回複報文。因此這種非法報文對Device B和Device C都造成了攻擊。如果此時網絡管理員錯誤地切斷了Device C的連接，可能會導致網絡業務中斷甚至更嚴重的後果。
攻擊者也可以同時偽造不同源地址的攻擊報文或者同時攻擊多個服務器，從而造成網絡阻塞甚至網絡癱瘓。
uRPF可以有效防範上述攻擊。一般情況下，設備在收到報文後會根據報文的目的地址對報文進行轉發或丟棄。而uRPF可以在轉發表中查找報文源地址對應的接口是否與報文的入接口相匹配，如果不匹配則認為源地址是偽裝的並丟棄該報文，從而有效地防範網絡中基於源地址欺騙的惡意攻擊行為的發生。
uRPF檢查有嚴格（strict）型和鬆散（loose）型兩種。
不僅檢查報文的源地址是否在轉發表中存在，而且檢查報文的入接口與轉發表是否匹配。
在一些特殊情況下（如非對稱路由，即設備上行流量的入接口和下行流量的出接口不相同），嚴格型uRPF檢查會錯誤地丟棄非攻擊報文。
一般將嚴格型uRPF檢查布置在ISP的用戶端和ISP端之間。
僅檢查報文的源地址是否在轉發表中存在，而不再檢查報文的入接口與轉發表是否匹配。
鬆散型uRPF檢查可以避免錯誤的攔截合法用戶的報文，但是也容易忽略一些攻擊報文。
一般將鬆散型uRPF檢查布置在ISP-ISP端。另外，如果用戶無法保證路由對稱，可以使用鬆散型uRPF檢查。
嚴格型uRPF檢查中還可以進一步進行鏈路層檢查，即用源地址查轉發表得到的下一跳地址再查一次ARP表，確保報文的源MAC地址和查到的ARP表項中的MAC地址一樣才允許報文通過。
鏈路層檢查功能對於運營商用一個三層以太網接口接入大量PC機用戶時部署非常合適。
鬆散型uRPF檢查不支持鏈路層檢查功能。
當設備上配置了缺省路由後，會導致uRPF根據轉發表檢查源地址時，所有源地址都能查到下一跳。針對這種情況，支持用戶配置uRPF是否允許匹配缺省路由。如果允許匹配缺省路由（配置allow-default-route），則當uRPF查詢轉發表得到的結果是缺省路由時，認為查到了匹配的表項；如果不允許匹配缺省路由，則當uRPF查詢轉發表得到的結果是缺省路由時，認為沒有查到匹配的表項。
缺省情況下，如果uRPF查詢轉發表得到的結果是缺省路由，則按沒有查到表項處理，丟棄報文。
運營商網絡邊緣位置一般不會有缺省路由指向客戶側設備，所以一般不需要配置allow-default-route。如果在客戶側邊緣設備接口所在安全域上麵啟用uRPF，這時往往會有缺省路由指向運營商，此時需要配置allow-default-route。
如果用戶確認具有某些特征的報文是合法報文，則可以在ACL中指定這些報文，那麼這些報文在逆向路由不存在的情況下，不做丟棄處理，按正常報文進行轉發。
uRPF的處理流程如圖1-2所示。
圖1-2 uRPF處理流程圖
(1) 檢查地址合法性：
¡ 對於目的地址是組播地址的報文，直接放行。
¡ 對於源地址是全零地址的報文，如果目的地址是廣播，則放行（源地址為0.0.0.0，目的地址為255.255.255.255的報文，可能是DHCP或者BOOTP報文，不做丟棄處理）；如果目的地址不是廣播，則進入步驟（7）。
¡ 對於不是上述情況的報文，則進入步驟（2）。
(2) 檢查報文的源地址在轉發表中是否存在匹配的單播路由：如果在轉發表中查找失敗（源地址是非單播地址則會匹配到非單播路由），則進入步驟（7），否則進入步驟（3）；
(3) 如果轉發表中匹配的是上送本機路由，即查到InLoop接口，則檢查報文入接口是否是InLoop接口：如果是，則直接放行，否則進入步驟(7)；如果轉發表中匹配的不是上送本機路由則繼續步驟(4)；
(4) 如果轉發表中匹配的是缺省路由，則檢查用戶是否配置了允許匹配缺省路由（參數allow-default-route）：如果沒有配置，則進入步驟（7），否則進入步驟（5）；如果轉發表中匹配的不是缺省路由，則進入步驟（5）；
(5) 檢查報文源地址與入接口是否匹配。反向查找報文出接口（反向查找是指查找以該報文源IP地址為目的IP地址的報文的出接口）或者缺省路由的出接口：如果其中至少有一個出接口和報文的入接口相匹配，則進入步驟（6）；如果不匹配，則查看是否是鬆散型檢查，如果是，則報文檢查通過，進入步驟（7）；否則說明是嚴格型檢查，進入步驟（6）；
(6) 檢查用戶是否配置了對鏈路層信息進行檢查（參數link-check）：如果沒有配置，則認為報文通過檢查，進行正常的轉發。如果已經配置，則根據轉發表中的下一跳查詢ARP表，並比較IP報文源MAC地址與ARP表中的MAC地址是否一致。如果兩者一致，則報文通過檢查；如果查詢失敗或兩者不一致，則進入步驟（7）；
(7) ACL檢查流程。如果報文符合ACL，則報文繼續進行正常的轉發（此類報文稱為被抑製丟棄的報文）；否則報文被丟棄。
圖1-3 uRPF典型組網應用
通常在ISP上配置uRPF，在ISP與用戶端，配置嚴格型uRPF檢查，在ISP與ISP端，配置鬆散型uRPF檢查。
如果有特殊用戶，或者具有一定特征，需要特殊處理的報文，可以配置ACL規則。
配置鬆散型uRPF檢查時不建議配置allow-default-route參數，否則可能導致防攻擊能力失效。
嚴格型uRPF不能與等價路由功能同時使用，否則匹配等價路由的業務報文無法通過嚴格型uRPF的檢查，導致業務報文被丟棄。
安全域上配置的uRPF對域內所有接口生效。
(1) 進入係統視圖。
system-view
(2) 進入安全域視圖。
security-zone name zone-name
(3) 開啟uRPF功能。
ip urpf { loose [ allow-default-route ] [ acl acl-number ] | strict [ allow-default-route ] [ acl acl-number ] [ link-check ] }
缺省情況下，uRPF功能處於關閉狀態。
在完成上述配置後，在任意視圖下執行display命令可以顯示配置uRPF後的運行情況，通過查看顯示信息驗證配置的效果。
表1-1 uRPF顯示和維護
|
配置步驟 |
命令 |
|
顯示uRPF的配置應用情況 |
（獨立運行模式） display ip urpf [ security-zone zone-name ] [ slot slot-number [ cpu cpu-number ] ] （IRF模式） display ip urpf [ security-zone zone-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
|
顯示安全域的uRPF統計信息 |
（獨立運行模式） display ip urpf statistics security-zone zone-name [ slot slot-number [ cpu cpu-number ] ] （IRF模式） display ip urpf statistics security-zone zone-name [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
|
清除安全域的urpf統計信息 |
reset ip urpf statistics security-zone zone-name |
IPv6 uRPF（unicast Reverse Path Forwarding，單播反向路徑轉發）是一種單播逆向路由查找技術，用來防範基於源地址欺騙的攻擊手段，例如基於源地址欺騙的DoS（Denial of Service，拒絕服務）攻擊和DDoS（Distributed Denial of Service，分布式拒絕服務）攻擊。
對於使用基於IPv6地址驗證的應用來說，基於源地址欺騙的攻擊手段可能導致未被授權用戶以他人，甚至是管理員的身份獲得訪問係統的權限。因此即使響應報文沒有發送給攻擊者或其它主機，此攻擊方法也可能會造成對被攻擊對象的破壞。
如圖2-1所示，攻擊者在Device A上偽造並向Device B發送大量源地址為2000::1的報文，Device B響應這些報文並向真正的“2000::1”（Device C）回複報文。因此這種非法報文對Device B和Device C都造成了攻擊。如果此時網絡管理員錯誤地切斷了Device C的連接，可能會導致網絡業務中斷甚至更嚴重的後果。
攻擊者也可以同時偽造不同源地址的攻擊報文或者同時攻擊多個服務器，從而造成網絡阻塞甚至網絡癱瘓。
IPv6 uRPF可以有效防範上述攻擊。一般情況下，設備在收到報文後會根據報文的目的地址對報文進行轉發或丟棄。而IPv6 uRPF可以在轉發表中查找報文源地址對應的接口是否與報文的入接口相匹配，如果不匹配則認為源地址是偽裝的並丟棄該報文，從而有效地防範網絡中基於源地址欺騙的惡意攻擊行為的發生。
IPv6 uRPF檢查有嚴格（strict）型和鬆散（loose）型兩種。
不僅檢查報文的源地址是否在IPv6轉發表中存在，而且檢查報文的入接口與IPv6轉發表是否匹配。
在一些特殊情況下（如非對稱路由，即設備上行流量的入接口和下行流量的出接口不相同），嚴格型IPv6 uRPF檢查會錯誤地丟棄非攻擊報文。
一般將嚴格型IPv6 uRPF檢查布置在ISP的用戶端和ISP端之間。
僅檢查報文的源地址是否在IPv6轉發表中存在，而不再檢查報文的入接口與IPv6轉發表是否匹配。
鬆散型IPv6 uRPF檢查可以避免錯誤的攔截合法用戶的報文，但是也容易忽略一些攻擊報文。
一般將鬆散型IPv6 uRPF檢查布置在ISP-ISP端。另外，如果用戶無法保證路由對稱，可以使用鬆散型IPv6 uRPF檢查。
當設備上配置了缺省路由後，會導致IPv6 uRPF根據IPv6轉發表檢查源地址時，所有源地址都能查到下一跳。針對這種情況，支持用戶配置IPv6 uRPF是否允許匹配缺省路由。如果允許匹配缺省路由（配置allow-default-route），則當IPv6 uRPF查詢IPv6轉發表得到的結果是缺省路由時，認為查到了匹配的表項；如果不允許匹配缺省路由，則當IPv6 uRPF查詢IPv6轉發表得到的結果是缺省路由時，認為沒有查到匹配的表項。
缺省情況下，如果IPv6 uRPF查詢IPv6轉發表得到的結果是缺省路由，則按沒有查到表項處理，丟棄報文。
運營商網絡邊緣位置一般不會有缺省路由指向客戶側設備，所以一般不需要配置allow-default-route。如果在客戶側邊緣設備接口所在安全域上麵啟用IPv6 uRPF，這時往往會有缺省路由指向運營商，此時需要配置allow-default-route。
如果用戶確認具有某些特征的報文是合法報文，則可以在IPv6 ACL中指定這些報文，那麼這些報文在逆向路由不存在的情況下，不做丟棄處理，按正常報文進行轉發。
IPv6 uRPF的處理流程如圖2-2所示。
圖2-2 IPv6 uRPF處理流程圖
(1) 檢查地址合法性：對於目的地址是組播地址的報文直接放行。否則，進入步驟（2）；
(2) 檢查報文的源地址在IPv6轉發表中是否存在匹配的單播路由：如果在IPv6轉發表中查找失敗（源地址是非單播地址則會匹配到非單播路由），則進入步驟（6），否則進入步驟（3）；
(3) 如果IPv6轉發表中匹配的是上送本機路由，則檢查報文入接口是否是InLoop接口：如果是，則直接放行，否則進入步驟（6）；如果IPv6轉發表中匹配的不是上送本機路由則繼續步驟（4）；如果源地址是Link-Local地址，倘若這個地址是入接口的地址，並且入接口不是InLoop接口則進入步驟（6），否則直接放行；
(4) 檢查報文源地址與入接口是否匹配：反向查找報文出接口（反向查找是指查找以該報文源IPv6地址為目的IPv6地址的報文的出接口）或者缺省路由的出接口，如果其中至少有一個出接口和報文的入接口相匹配，則進入步驟（5）；如果不匹配，則查看是否是鬆散型檢查，如果是，則進入步驟（5），否則說明是嚴格型檢查，進入步驟（6）；
(5) 如果IPv6轉發表中匹配的是缺省路由，則檢查用戶是否配置了允許匹配缺省路由（參數allow-default-route），如果沒有配置，則進入步驟（6），否則處理結束報文正常轉發；如果IPv6轉發表中匹配的不是缺省路由，則處理結束報文正常轉發；
(6) IPv6 ACL檢查流程。如果報文符合IPv6 ACL，則報文繼續進行正常的轉發（此類報文稱為被抑製丟棄的報文）；否則報文被丟棄。
圖2-3 IPv6 uRPF典型組網應用
通常在ISP上配置uRPF，在ISP與用戶端，配置嚴格型IPv6 uRPF檢查，在ISP與ISP端，配置鬆散型IPv6 uRPF檢查。
如果有特殊用戶，或者具有一定特征，需要特殊處理的報文，可以配置IPv6 ACL規則。
配置鬆散型IPv6 uRPF檢查時不建議配置allow-default-route參數，否則可能導致防攻擊能力失效。
嚴格型uRPF不能與等價路由功能同時使用，否則匹配等價路由的業務報文無法通過嚴格型uRPF的檢查，導致業務報文被丟棄。
安全域上配置的IPv6 uRPF對域內所有接口生效。
(1) 進入係統視圖。
system-view
(2) 進入安全域視圖。
security-zone name zone-name
(3) 開啟IPv6 uRPF功能。
ipv6 urpf { loose | strict } [ allow-default-route ] [ acl acl-number ]
缺省情況下，IPv6 uRPF功能處於關閉狀態。
在完成上述配置後，在任意視圖下執行display命令可以顯示配置IPv6 uRPF後的運行情況，通過查看顯示信息驗證配置的效果。
表2-1 IPv6 uRPF顯示和維護
|
配置步驟 |
命令 |
|
顯示IPv6 uRPF的配置應用情況 |
（獨立運行模式） display ipv6 urpf [ security-zone zone-name ] [ slot slot-number [ cpu cpu-number ] ] （IRF模式） display ipv6 urpf [ security-zone zone-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
|
顯示安全域的IPv6 uRPF統計信息 |
（獨立運行模式） display ipv6 urpf statistics security-zone zone-name [ slot slot-number [ cpu cpu-number ] ] （IRF模式） display ipv6 urpf statistics security-zone zone-name [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
|
清除安全域的IPv6 uRPF統計信息 |
reset ipv6 urpf statistics security-zone zone-name |
不同款型規格的資料略有差異, 詳細信息請向具體銷售和400谘詢。H3C保留在沒有任何通知或提示的情況下對資料內容進行修改的權利!
支持
