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