建站
咨詢
售后
建站咨詢
新聞中心
IPv6數(shù)據(jù)包的結(jié)構(gòu)可以讓這個下一代網(wǎng)絡(luò)協(xié)議在可預(yù)見的未來實現(xiàn)幾乎無限的可擴(kuò)展性。然而，經(jīng)驗表明，這種靈活性是要付出代價的，這個代價就包括安全隱患。在本文中IPv6安全專家Fernando Gont探討了IPv6擴(kuò)展報頭帶來的安全風(fēng)險以及降低這種風(fēng)險的方法。
當(dāng)涉及到可擴(kuò)展性時，IPv4數(shù)據(jù)包結(jié)構(gòu)有兩個主要的限制。
首先，IPv4有著有限的選項空間(至多40字節(jié))，這種數(shù)據(jù)包結(jié)構(gòu)限制了IPv4可部署的擴(kuò)展的數(shù)量和類型。其次，所有IPv4選項(無論是針對路由器還是主機(jī))共享相同的“容器”，這意味著轉(zhuǎn)發(fā)IPv4數(shù)據(jù)包的每個路由器都必須處理所有IPv4選項，以防其中一個選項必須要由IPv4路由器處理。
相比之下，IPv6數(shù)據(jù)包結(jié)構(gòu)則明顯不同。對于可擴(kuò)展性，IPv6選項通過IPv6“擴(kuò)展報頭”來傳遞，而不是在強(qiáng)制IPv6報頭(具有固定大小)。IPv6擴(kuò)展報頭被插入在強(qiáng)制IPv6報頭和上層協(xié)議報頭之間，下圖顯示了IPv6數(shù)據(jù)包的結(jié)構(gòu)，包括兩個擴(kuò)展報頭。
從這個圖來看，IPv6數(shù)據(jù)包遵循“菊花鏈”的結(jié)構(gòu)，其中每個IPv6擴(kuò)展報頭指定了緊跟的報頭類型(通過“Next Header”字段)，并且每個擴(kuò)展報頭指定了自己的長度(或者具有相關(guān)的固定長度)。因此，通過從強(qiáng)制IPv6報頭開始，并且每次跟隨一個擴(kuò)展報頭，整個IPv6報頭鏈可以傳輸?shù)缴蠈訁f(xié)議報頭。下表列出了一些最常見類型的IPv6擴(kuò)展報頭(來自IANA協(xié)議編號注冊機(jī)構(gòu))相應(yīng)的Next Header值：
基于將對選項進(jìn)行處理的節(jié)點類型，它們被傳遞在不同類型的IPv6擴(kuò)展報頭。例如，預(yù)計將由到目標(biāo)沿路徑的所有節(jié)點處理的選項會放在逐跳選項擴(kuò)展報頭中。而僅由目標(biāo)節(jié)點處理的選項則包含在目的選項擴(kuò)展報頭中。其他擴(kuò)展報頭可能有不同的用途。例如，路由報頭用來影響數(shù)據(jù)包如何轉(zhuǎn)發(fā)到目標(biāo)節(jié)點，而分段報頭則被用于分段/重組機(jī)制。
有些擴(kuò)展報頭必須遵循特定順序。例如，如果有逐跳選項報頭，它必須是強(qiáng)制IPv6報頭之后的第一個擴(kuò)展報頭。這個概念很簡單;在IPv6報頭鏈中，將由到目標(biāo)沿路徑的所有節(jié)點處理的擴(kuò)展報頭必須先于僅由目標(biāo)節(jié)點處理的擴(kuò)展報頭。因此，IPv6路由器并不需要處理IPv6報頭鏈中所有報頭，而是停止在最后一個擴(kuò)展報頭--其中包含需由IPv6路由器處理的選項。
此外，由于逐跳選項報頭僅包含必須由數(shù)據(jù)包傳送路徑所有節(jié)點處理的選項，路由器將不會浪費資源來處理不必要的選項。
在IPv6中，所有分段相關(guān)的報頭字段已經(jīng)從強(qiáng)制IPv6報頭中刪除，并移動到(可選)“分段報頭”。從概念上講，原始(或“未分段”)數(shù)據(jù)包總是在發(fā)送節(jié)點構(gòu)建，并只有在那時(如果需要)會進(jìn)行分段。下圖展示了原始IPv6數(shù)據(jù)包的概念結(jié)構(gòu)：
原始數(shù)據(jù)包由“不可分段部分”和“可分段部分”組成。不可分段部分包括IPv6報頭以及必須由到目標(biāo)節(jié)點沿路徑所有節(jié)點處理的擴(kuò)展報頭，即到路由報頭的所有報頭(如果存在，也包括路由報頭)，或者逐跳選項報頭(如果存在)，或者沒有擴(kuò)展報頭。而不可分段部分則由其余數(shù)據(jù)包部分組成;即只能由最終目標(biāo)節(jié)點處理的所有IPv6擴(kuò)展報頭，還有上層報頭和數(shù)據(jù)。不可分段部分將存在于所有產(chǎn)生的片段中，而可分段部分將被分割為多個片段。因此，每個片段是通過“串聯(lián)”原始數(shù)據(jù)包的不可分段部分(具有一個分段報頭)和一塊可分段部分來構(gòu)建。下圖展示了基于上面描述的邏輯數(shù)據(jù)包如何分割成多個IPv6片段：
尋找上層協(xié)議信息
在IP數(shù)據(jù)包執(zhí)行簡單訪問控制列表(ACL)所需的每個路由器或中間體都必須能夠找到上層協(xié)議報頭，該報頭通常包括源和目的地端口號。IPv4的數(shù)據(jù)包結(jié)構(gòu)讓節(jié)點可以很容易找到上層協(xié)議報頭：通過從IPv4報頭跳過在IPv4“互聯(lián)網(wǎng)報頭長度”字段所指示的字節(jié)數(shù)，處理節(jié)點可以簡單地“跳過”選項空間。
然而，在IPv6的情況下，并沒有尋找上層協(xié)議報頭的“線索”。因此，尋找上層協(xié)議報頭的唯一方法是在強(qiáng)制IPv6報頭開始，處理/緊跟IPv6報頭鏈中的每個擴(kuò)展報頭，直到發(fā)現(xiàn)最后一個報頭。
應(yīng)當(dāng)指出的是，這個過程曾經(jīng)更為復(fù)雜：IPv6報頭鏈本身可以是分段的，擴(kuò)展報頭和上層協(xié)議報頭被分成多個片段。因此，無狀態(tài)設(shè)備(即在檢查前未執(zhí)行分段重組的設(shè)備)不太可能獲取上層協(xié)議信息。例如，下面的數(shù)據(jù)包以前被認(rèn)為是有效的：
幸運的是，2014年年初發(fā)布的RFC 7112已經(jīng)宣布這些數(shù)據(jù)包為非法，因此最新的部署并不需要擔(dān)心它們(可以丟棄它們)。#p#
IPv6擴(kuò)展報頭的安全隱患
IPv6擴(kuò)展報頭的安全隱患通常分為下面幾種：
· 安全控制規(guī)避
· 由于處理要求而創(chuàng)造拒絕服務(wù)條件
· 因為部署錯誤而創(chuàng)造拒絕服務(wù)條件
· 每個擴(kuò)展報頭特定的問題
正如上文所述，在IPv6數(shù)據(jù)包中尋找上層協(xié)議報頭被證明是一項艱巨的任務(wù)。更糟糕的是，有些中間體和安全設(shè)備希望上層協(xié)議報頭緊跟強(qiáng)制IPv6報頭，因此，當(dāng)使用IPv6擴(kuò)展報頭時，無法找到或者識別上層協(xié)議。例如，這些安全設(shè)備或中間體無法認(rèn)識到下面的數(shù)據(jù)包是TCP端，這僅僅是因為使用了目的選項擴(kuò)展報頭：
這樣的原因在于，上述設(shè)備不會處理整個IPv6報頭鏈來尋找上層報頭，而是假設(shè)強(qiáng)制IPv6報頭的“下一報頭”字段描述/指示了上層協(xié)議類型。因此，上述圖表中的數(shù)據(jù)包被認(rèn)為是“目的選項”數(shù)據(jù)包，而不是TCP段。
如果安全設(shè)備采用這種(存在問題的)邏輯，并且已經(jīng)被配置為執(zhí)行“默認(rèn)允許”政策(即允許所有數(shù)據(jù)包，除非它們符合指定的規(guī)則之一)，它們可能將受到規(guī)避攻擊。這種攻擊的簡單變體是，數(shù)據(jù)包采用多個IPv6擴(kuò)展報頭，或者一個大的擴(kuò)展報頭來在多個部署中觸發(fā)不同的問題。有些部署會限制它們處理的擴(kuò)展報頭的數(shù)量，或者對于它們可以檢查的關(guān)于“多少字節(jié)進(jìn)入IPv6數(shù)據(jù)包”有著特定的限制。這樣的情況可以從下面的圖中反映出來：
執(zhí)行一種或兩種限制并采用“默認(rèn)允許”政策的部署也容易受到規(guī)避攻擊。而某些極端情況數(shù)據(jù)包處理的模糊性則代表著規(guī)避安全控制的另一種可能。
通過隱藏上層協(xié)議類型(正如上文所述)或者隱藏應(yīng)用數(shù)據(jù)流，IPv6分段還可以被利用來執(zhí)行規(guī)避攻擊。在過去的幾年中，我們發(fā)現(xiàn)很多部署容易受到這些規(guī)避技術(shù)的攻擊。例如，RFC 7113在RA-Guard事件中描述了這個問題，相同的技術(shù)還可以用于繞過某些IPv6防火墻。此外，有些數(shù)據(jù)包處理方式的不一致可能導(dǎo)致安全控制規(guī)避，正如思科公司的Panos Kampanakis和研究人員Antonios Atlasis所指出的。
IPv6擴(kuò)展報頭可能對設(shè)備處理產(chǎn)生負(fù)面的性能影響。雖然這可能似乎不像一個安全問題，但這也需要慎重考慮。例如，IPv6路由器部署通常處理在軟件(而不是硬件)中包含逐跳選項擴(kuò)展報頭的數(shù)據(jù)包，其他IPv6路由器部署則處理在軟件中部署IPv6擴(kuò)展報頭(當(dāng)它們被配置為執(zhí)行ACL時)的數(shù)據(jù)包。這意味著，除非有適當(dāng)?shù)木徑獯胧?例如數(shù)據(jù)包過濾/或?qū)Σ捎脭U(kuò)展報頭的數(shù)據(jù)包的限速)，攻擊者可能會通過簡單地發(fā)送大量采用IPv6擴(kuò)展報頭的IPv6流量來執(zhí)行拒絕服務(wù)(DoS)攻擊。
雖然IPv6協(xié)議本身(以及很多部署)已經(jīng)存在很多年，最近在很多部署中發(fā)現(xiàn)了IPv6擴(kuò)展報頭處理過程中的漏洞問題。發(fā)現(xiàn)這些漏洞的可能原因在于，大多數(shù)擴(kuò)展報頭并沒有真正部署在現(xiàn)實世界的流量中，從而很少使用相應(yīng)的代碼。出于這個原因，在有些部署中發(fā)現(xiàn)IPv6擴(kuò)展報頭的處理中仍然存在漏洞并不令人驚訝。
最后，除了IPv6擴(kuò)展報頭的一般安全隱患外，每個擴(kuò)展報頭類型往往都有著自己特定的安全問題。例如，安全研究人員在2007年報道如何使用路由報頭Type 0(現(xiàn)在已經(jīng)過時)來執(zhí)行DoS攻擊。另一個具有安全隱患的擴(kuò)展報頭是Fragment Header，它用于IPv6的分段/重組功能。雖然分段/重組機(jī)制的很多安全隱患在IPv4領(lǐng)域已經(jīng)很有名，但現(xiàn)在很多相關(guān)問題已經(jīng)悄悄潛入IPv6部署，從DoS攻擊到信息泄露或規(guī)避攻擊(詳情請參與筆者最近對可預(yù)測片段標(biāo)識值的IETF草案和Antonios Atlasis在2012年歐洲黑帽大會的展示)。
結(jié)論
很多(如果不是大多數(shù))源自IPv6擴(kuò)展報頭的安全問題往往與如何部署相應(yīng)的支持有關(guān)：從有漏洞的代碼，到在軟件(而不是硬件)中處理擴(kuò)展報頭的設(shè)備。有些部署可能提供緩解技術(shù)，例如對采用IPv6擴(kuò)展報頭的數(shù)據(jù)包進(jìn)行限速(在創(chuàng)造DoS條件之前丟棄多余的流量)。在其他情況下，管理員可能沒有其他選擇，只能過濾相應(yīng)的流量。顯然這是值得關(guān)注的領(lǐng)域，隨著IPv6網(wǎng)絡(luò)部署工作繼續(xù)推進(jìn)，企業(yè)網(wǎng)絡(luò)安全專業(yè)人士必須密切關(guān)注。
新聞標(biāo)題：風(fēng)險剖析：IPv6擴(kuò)展報頭帶來的安全隱患
當(dāng)前地址：http://m.5511xx.com/article/djhcpdh.html
