在掃描IPv6空間?我們又為何要在意這件事?
最重要的原因最先說:從安全的角度來看,我們已經不能繼續忽視IPv6了。
最近,Akamai的研究人員與馬克斯?普朗克信息研究所(Max Planck Institute for Informatics)合作,對IPv6地址空間的大規模漏洞掃描行為進行了首次實證研究。結果發現,網絡上的各種掃描器已經開始掃蕩IPv6空間。由于IPv6空間的掃描難度遠高于IPv4,因此目前與IPv6有關的掃描活動還并不算太多。
總的來看,相關掃描流量主要集中于少數幾個活躍來源。從地理位置方面來看,兩個最活躍的來源均來自中國;從掃描流量來源的頂級網絡來看,還有一些網絡安全公司正在從云提供商的地址空間中發起掃描。
這類掃描器通常并不會使用單個128位IPv6地址發出掃描流量,而是會使用最大達到整個/32空間的無數個地址前綴來發起探測,這可能是為了逃避檢測。因而直接后果就是:對這些掃描器的檢測和封堵將變得異常困難。
為什么現在要開始關注這些?Akamai認為,如果針對IPv6的漏洞掃描繼續變得更普遍,那么業界可能就迫切需要提供可靠的IPv6掃描活動檢測和阻斷技術。因為這很可能導致新的安全問題。
延伸閱讀,了解Akamai cloud-computing
背景簡介
無論攻擊者、研究人員或防御者,大家都會通過網絡掃描來找出/暴露出連接到互聯網的設備中存在的漏洞。雖然這樣做的目標大相徑庭,但由于IPv4有數以萬計的持續來源,任何人只需要進行掃描,就能發現或抵御網絡威脅。當軟件中發現新漏洞后,攻擊者會爭先恐后掃描不同的地址空間,尋找容易受到攻擊的主機,并進行利用或攻擊。與此同時,爬蟲網絡也會不斷掃描地址空間,借此尋找新的可利用目標從而橫向傳播。安全公司和研究人員也會掃描地址空間,以確定不同地址空間的屬性并發現薄弱點。總而言之:IPv4空間很忙。
那么IPv6呢?有人在掃描IPv6空間嗎?我們是否有必要多多關注一下這方面?
答案很簡單:從安全的角度來看,我們已經不能繼續忽視IPv6了。上文提到的研究所產生的最新論文即將在ACM Internet Measurement Conference 2022大會上發表,論文中提到,我們使用在Akamai邊緣服務器上獲得的防火墻日志來闡述IPv6互聯網上正在進行的掃描活動。在超過15個月的時間里,我們一直在研究:誰在掃描,他們在掃描什么,以及在識別和阻止此類掃描方面我們面臨的最大挑戰是什么。
為何對IPv6空間進行的掃描更困難?
IPv4地址空間包含大約40億個地址,現如今,只要有網絡帶寬足夠大的計算機,整個IPv4地址空間可以在大約一小時內掃描完畢。同樣,低帶寬的IoT爬蟲只能生成并掃描隨機的IPv4地址以便橫向移動。只要有足夠的時間,隨機生成目標地址通常就足以找到有反應、可利用的主機。
但另一方面,IPv6的地址長度高達128位,可以包含大約10的38次方個地址,這要比IPv4地址空間的規模大好幾個數量級。以現如今的技術能力來說,整個IPv6地址空間至少需要數萬億年的時間才能掃描完畢。這使得對整個空間進行完整掃描成了一種不切實際的做法,那么如果攻擊者想要進行掃描,就需要首先通過其他方式找到目標地址,例如使用IPv6的命中列表(Hitlist),或使用DNS將域名解析為IPv6地址。雖然浩如煙海的IPv6使得攻擊者很難通過隨機掃描的方式尋找目標,但并不意味著我們可以完全忽視這種做法。這有些類似于“隱性安全性(Security by obscurity)”的思想,而根據這種思想,最佳做法是直接“阻斷”掃描操作,從而“保護”IPv6。
為何很難檢測到針對IPv6進行的掃描操作?
在IPv4空間中,每個能被路由的地址每天都會收到數以千計的掃描數據包,這是有人掃描整個IPv4空間,或有人以隨機方式生成目標地址并借此查找有漏洞的主機所導致的結果。因此只需要監測未使用的前綴(“暗網”)中抵達的掃描流量,我們就可以通過一種直接的方法研究IPv4空間中的整體網絡掃描活動趨勢。
然而當涉及到IPv6時,第一個挑戰在于找到一個足以看到足夠程度掃描流量的“有利位置”。正如上文所述,隨機地以整個IPv6空間為目標是不現實的。因此監測暫未使用的IPv6前綴(和IPv4一樣,也屬于“暗網”)上所產生的流量,這種方式幾乎無法發現任何掃描流量。這時候就要由Akamai智能邊緣平臺發揮作用了!我們在超過1300個網絡中運行了數十萬臺服務器,每臺服務器都承載著客戶的內容,由于我們在響應DNS請求時需要返回這些服務器的地址,因此這些服務器的IPv6地址就已經暴露到互聯網上了。因此,它們可以被掃描器發現,并成為公開可用的IPv6命中列表的一部分。
第二個挑戰是如何準確定位并隔離IPv6掃描源。由于攻擊者與合法掃描源都在積極掃描,隔離對于了解目前的掃描情況就顯得至關重要。此外,如果一個網絡想要阻止來自惡意攻擊者的流量,那么在生產環境中,隔離就變得更重要了。在研究掃描流量時,我們注意到一些掃描器并不使用單一128位源IPv6地址來發出自己的掃描探針,而是會從/64、/48,甚至/32等不太具體的前綴所包含的無數源地址發出掃描流量。畢竟IPv6的龐大規模使得這種做法完全可行,任何一個掃描器都可以輕松獲得一個巨大的IPv6分配(例如直接從區域性互聯網注冊機構(RIR)那里獲得一個/32空間,或者直接購買某些互聯網服務提供商的服務,這些服務商可以為每個用戶分配一整塊/48前綴)。我們發現,將流量分散到多個前綴上有助于規避檢測,因為每個源地址可能只發出了一個數據包。另外一些掃描器甚至還在IPv6地址中的可用位里編碼了掃描信息。
我們如何監測出大規模IPv6掃描?
Akamai的防火墻會記錄發送到我們邊緣主機上的未經請求的流量,其中就包含掃描流量。在掃描檢測方面,我們的依據是:一個特定來源,至少要以我們自己服務器的100個IP地址為目標,這有些類似于早期IPv4大規模掃描的檢測機制。
如上文所述,由于一些掃描器使用更大的前綴來發出流量,我們首先將展示在不對流量進行聚合(/128源)情況下發現的掃描器,隨后會展示首次將來自一個/64源的所有數據包聚合在一起后發現的掃描器,最后還有對來自一個/48源的所有數據包聚合后的結果。
2021和2022年的IPv6掃描趨勢
圖1:不同的源聚合程度下,每周檢測到的IPv6掃描來源
圖1展示了從2021年1月到2022年3月,我們每周檢測到的掃描器數量。從圖中可以看到,源數據包的聚合程度會對檢測到的掃描器來源數量產生巨大影響。總的來說,我們發現在整個時期內,掃描器的數量相對穩定,每周活躍的掃描器來源大致都在10到100個之間,與針對IPv4空間進行掃描的數十萬個掃描器相比,這個數量不值一提。從2121年11月開始,/128掃描源有一個明顯的增量,但我們發現所有這些/128源都可以聚合成一個/64,并且都是被同一個掃描者所使用的,那是一家美國的網絡安全公司。
對IPv6掃描流量進行的聚合
圖2:每周的掃描數據包數量(/64源聚合)
圖2展示了每周捕獲的掃描數據包數量,并且我們將每周最活躍和第二活躍掃描器與其他所有掃描器來源分開顯示了。令人震驚的是,我們發現,基本上,無論在什么時間,都有一個最活躍的掃描器發出了絕大部分掃描流量(最高占到每周總流量的92%),而其他不那么活躍的掃描器只產生了很少量的流量。那么這就引出了另一個問題:這個最活躍的掃描器到底是誰?
掃描的來源網絡
下表列出了按照掃描流量的數據包數量降序排序的前20個掃描流量來源網絡(自治系統,AS)。此外我們還針對每個網絡,列出了檢測到存在掃描器的/48前綴、/64前綴以及/128前綴的數量。對于每個網絡,我們還列出了網絡類型和來源國家/地區。
表:按照數量排名前20的掃描來源網絡(AS)
我們注意到,如果來自/48的聚合流量滿足有關掃描的定義,但來自/64的聚合流量無法滿足定義,那么/48的掃描源數量可能會超過/64或/128(例如排名第18位的AS)。
我們發現,掃描活動是嚴重集中的:前五個源網絡幾乎占據所有掃描流量的93%。尤其值得注意的是,最活躍的兩個源網絡都是位于中國的數據中心,緊隨其后的是一些網絡安全公司以及大型云提供商。總的來說,我們發現大部分掃描流量都來自數據中心/云提供商,排名前20的來源沒有一個是面向最終用戶的ISP。
進一步分析每個AS內部的掃描源后,我們發現不同網絡之間存在著驚人的差異。雖然最活躍的掃描源的全部流量都來自一個128位源地址,但我們發現一些網絡(例如排名第18位的AS)中,同一個掃描器會從超過1000個不同的/48前綴發出掃描流量。同時,第18位的AS在所有記錄在案的掃描流量中占比還不到0.1%,但在按照活躍的來源前綴對網絡進行排序時,其中可能會出現分析偏差。
挑戰和結論
我們在研究IPv6掃描時遇到了一個很重要的問題:在識別單一掃描者的過程中,使用怎樣的前綴大小才是合適的?如上表所示,答案要看情況:雖然排名第1的AS中的掃描器可以,并且應當用它所采用的單一128位IPv6地址加以識別,但排名第18的AS中的掃描器則需要聚合到整個/32前綴中。一般來說,聚合到如此長的前綴,可能導致無法區分個別的掃描源,特別是在云提供商的環境中,個人用戶經常也可以被分配/64、/9,甚至更具體的前綴。在實踐中,如果要通過掃描檢測來封鎖某些地址,那么太“粗粒度”的聚合可能導致無意中封鎖了合法來源。
我們的初步分析發現,目前以IPv6空間為目標的掃描器數量依然還相對較少,相比IPv4世界中那些知名的掃描器,數量更加不值一提。IPv6掃描流量高度集中,少數源地址占據了支配地位。我們認為,如果IPv6空間的漏洞掃描行為變得更加普遍,這種情況可能也將迅速產生變化。識別和正確定位IPv6掃描源已成為一個迫在眉睫的挑戰。
如果對這個研究的結果感興趣,歡迎閱讀我們的論文。
這篇文章的內容感覺還行吧?有沒有想要立即在 Linode 平臺上親自嘗試一下?別忘了,現在注冊可以免費獲得價值 100 美元的使用額度,快點自己動手體驗本文介紹的功能和服務吧↓↓↓
出海云服務,選擇Akamai Linode!
歡迎關注Akamai ,第一時間了解高可用的MySQL/MariaDB參考架構,以及豐富的應用程序示例。