- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- 關於我們
07-uRPF
本章節下載： 07-uRPF (414.85 KB)
本幫助主要介紹以下內容：
· 特性簡介
¡ uRPF檢查方式
¡ uRPF技術優點
¡ uRPF處理流程
· 配置指南
uRPF（unicast Reverse Path Forwarding，單播反向路徑轉發）是一種單播逆向路由查找技術，用來防範基於源地址欺騙的攻擊手段，例如基於源地址欺騙的DoS（Denial of Service，拒絕服務）攻擊和DDoS（Distributed Denial of Service，分布式拒絕服務）攻擊。
對於使用基於IP地址驗證的應用來說，基於源地址欺騙的攻擊手段可能導致未被授權用戶以他人身份獲得訪問係統的權限。因此即使響應報文沒有發送給攻擊者或其它主機，此攻擊方法也可能會造成對被攻擊對象的破壞。
如圖所示，攻擊者在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檢查方式有嚴格型和鬆散型兩種。
不僅檢查報文的源地址是否在轉發表中存在，而且檢查報文的入接口與轉發表是否匹配。
在一些特殊情況下（如非對稱路由，即設備上行流量的入接口和下行流量的出接口不相同），嚴格型uRPF檢查會錯誤地丟棄非攻擊報文。
一般將嚴格型uRPF檢查布置在ISP的用戶端和ISP端之間。
僅檢查報文的源地址是否在轉發表中存在，而不再檢查報文的入接口與轉發表是否匹配。
鬆散型uRPF檢查可以避免錯誤的攔截合法用戶的報文，但是也容易忽略一些攻擊報文。
一般將鬆散型uRPF檢查布置在ISP-ISP端。另外，如果用戶無法保證路由對稱，可以使用鬆散型uRPF檢查。
當設備上配置了缺省路由後，會導致uRPF根據轉發表檢查源地址時，所有源地址都能查到下一跳。針對這種情況，支持用戶配置uRPF是否允許匹配缺省路由。如果允許匹配缺省路由，則當uRPF查詢轉發表得到的結果是缺省路由時，認為查到了匹配的表項；如果不允許匹配缺省路由，則當uRPF查詢轉發表得到的結果是缺省路由時，認為沒有查到匹配的表項。
缺省情況下，如果uRPF查詢轉發表得到的結果是缺省路由，則按沒有查到表項處理，丟棄報文。
運營商網絡邊緣位置一般不會有缺省路由指向客戶側設備，所以一般不需要配置“允許匹配缺省路由”。如果在客戶側邊緣設備接口上麵啟用uRPF，這時往往會有缺省路由指向運營商，此時需要配置“允許匹配缺省路由”。
嚴格型uRPF檢查中還可以進一步進行鏈路層檢查，即用源地址查轉發表得到的下一跳地址再查一次ARP表，確保報文的源MAC地址和查到的ARP表項中的MAC地址一樣才允許報文通過。
鏈路層檢查功能對於運營商用一個三層以太網接口接入大量PC機用戶時部署非常合適。
鬆散型uRPF檢查不支持鏈路層檢查功能。
如果用戶確認具有某些特征的報文是合法報文，則可以在ACL中指定這些報文，那麼這些報文在逆向路由不存在的情況下，不做丟棄處理，按正常報文進行轉發。
圖-2 uRPF處理流程圖
1. 檢查地址合法性：
¡ 對於目的地址是組播地址的報文，直接放行。
¡ 對於源地址是全零地址的報文，如果目的地址是廣播，則放行（源地址為0.0.0.0，目的地址為255.255.255.255的報文，可能是DHCP或者BOOTP報文，不做丟棄處理）；如果目的地址不是廣播，則進入步驟7。
¡ 對於不是上述情況的報文，則進入步驟2。
2. 檢查報文的源地址在轉發表中是否存在匹配的單播路由：如果在轉發表中查找失敗（源地址是非單播地址則會匹配到非單播路由），則進入步驟7，否則進入步驟3；
3. 如果轉發表中匹配的是上送本機路由，即查到InLoop接口，則檢查報文入接口是否是InLoop接口：如果是，則直接放行，否則進入步驟7；如果轉發表中匹配的不是上送本機路由則繼續步驟4；
4. 如果轉發表中匹配的是缺省路由，則檢查用戶是否配置了允許匹配缺省路由：如果沒有配置，則進入步驟7，否則進入步驟5；如果轉發表中匹配的不是缺省路由，則進入步驟5；
5. 檢查報文源地址與入接口是否匹配。反向查找報文出接口（反向查找是指查找以該報文源IP地址為目的IP地址的報文的出接口）或者缺省路由的出接口：如果其中至少有一個出接口和報文的入接口相匹配，則進入步驟6；如果不匹配，則查看是否是鬆散型檢查，如果是，則報文檢查通過，進入步驟7；否則說明是嚴格型檢查，進入步驟6；
6. 檢查用戶是否配置了對鏈路層信息進行檢查：如果沒有配置，則認為報文通過檢查，進行正常的轉發。如果已經配置，則根據轉發表中的下一跳查詢ARP表，並比較IP報文源MAC地址與ARP表中的MAC地址是否一致。如果兩者一致，則報文通過檢查；如果查詢失敗或兩者不一致，則進入步驟7；
7. ACL檢查流程。如果報文符合ACL，則報文繼續進行正常的轉發（此類報文稱為被抑製丟棄的報文）；否則報文被丟棄。
圖-3 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轉發表中匹配的是缺省路由，則檢查用戶是否配置了允許匹配缺省路由，如果沒有配置，則進入步驟6，否則處理結束報文正常轉發；如果IPv6轉發表中匹配的不是缺省路由，則處理結束報文正常轉發；
6. IPv6 ACL檢查流程。如果報文符合IPv6 ACL，則報文繼續進行正常的轉發（此類報文稱為被抑製丟棄的報文）；否則報文被丟棄。
圖-4 uRPF典型組網應用
通常在ISP上配置uRPF，在ISP與用戶端，配置嚴格型uRPF檢查，在ISP與ISP端，配置鬆散型uRPF檢查。
如果有特殊用戶，或者具有一定特征，需要特殊處理的報文，可以配置ACL規則。
1. 單擊“策略 > 安全防護 > uRPF > IPv4 uRPF”。
2. 在“IPv4 uRPF”頁麵單擊<新建>。
3. 新建IPv4 uRPF。
表-1 IPv4 uRPF配置
|
參數 |
說明 |
|
安全域 |
在指定安全域上應用IPv4 uRPF 下拉列表中顯示的安全域包括設備缺省的安全域和用戶在“網絡 > 安全域”頁麵已經配置的安全域 |
|
檢查方式 |
· 嚴格方式：不僅檢查報文的源地址是否在轉發表中存在，而且檢查報文的入接口與轉發表是否匹配 · 鬆散方式：僅檢查報文的源地址是否在轉發表中存在，而不再檢查報文的入接口與轉發表是否匹配 |
|
例外規則 |
訪問控製列表，用來抑製報文丟棄 可選擇已創建的IPv4 ACL，也可以新創建IPv4 ACL。此處新建的IPv4 ACL，可在“對象 > ACL > IPv4”頁麵查看 |
|
允許匹配缺省路由 |
允許源地址查轉發表時匹配缺省路由表項 |
|
開啟鏈路層檢查功能 |
允許對鏈路信息進行檢查 |
4. 單擊<確定>，新建的IPv4 uRPF會在“IPv4 uRPF”頁麵顯示。
1. 單擊“策略 > 安全防護 > uRPF > IPv6 uRPF”。
2. 在“IPv6 uRPF”頁麵單擊<新建>。
3. 新建IPv6 uRPF。
表-2 IPv6 uRPF配置
|
參數 |
說明 |
|
安全域 |
在指定安全域上應用IPv6 uRPF 下拉列表中顯示的安全域包括設備缺省的安全域和用戶在“網絡 > 安全域”頁麵已經配置的安全域 |
|
檢查方式 |
· 嚴格方式：不僅檢查報文的源地址是否在IPv6轉發表中存在，而且檢查報文的入接口與轉發表是否匹配 · 鬆散方式：僅檢查報文的源地址是否在IPv6轉發表中存在，而不再檢查報文的入接口與轉發表是否匹配 |
|
例外規則 |
訪問控製列表，用來抑製報文丟棄 可選擇已創建的IPv6 ACL，也可以新創建IPv6 ACL。此處新建的IPv6 ACL，可在“對象 > ACL > IPv6”頁麵查看 |
|
允許匹配缺省路由 |
允許源地址查轉發表時匹配缺省路由表項 |
4. 單擊<確定>，新建的IPv6 uRPF會在“IPv6 uRPF”頁麵顯示。
配置鬆散型uRPF檢查時不建議勾選“允許匹配缺省路由”，否則可能導致防攻擊能力失效。
不同款型規格的資料略有差異, 詳細信息請向具體銷售和400谘詢。H3C保留在沒有任何通知或提示的情況下對資料內容進行修改的權利!
支持
