建站
咨詢
售后
建站咨詢
新聞中心
IP地址的規(guī)劃短則影響數(shù)年，長則影響數(shù)十年。20世紀(jì)90年代初的地址分配，在2021年給互聯(lián)網(wǎng)造成了巨大了影響。然而當(dāng)時(shí)沒有人能預(yù)計(jì)到互聯(lián)網(wǎng)如此迅猛發(fā)展，IPv4地址成為了稀缺資源。
創(chuàng)新互聯(lián)專注于豐縣網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供豐縣營銷型網(wǎng)站建設(shè)，豐縣網(wǎng)站制作、豐縣網(wǎng)頁設(shè)計(jì)、豐縣網(wǎng)站官網(wǎng)定制、成都小程序開發(fā)服務(wù)，打造豐縣網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供豐縣網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
4月24日，據(jù)華盛頓郵報(bào)和美聯(lián)社報(bào)道，隸屬于美國國防部的一個(gè)部門Defense Digital Service(簡(jiǎn)稱 DDS)，過去三個(gè)月，以注冊(cè)在佛羅里達(dá)的 Global Resource Systems LLC 公司(GRS有限公司)名義，使用 BGP(邊界網(wǎng)關(guān)協(xié)議) 向全球路由表宣告了屬于美國國防部的地址段。所謂宣告地址，便是讓這些地址可以在互聯(lián)網(wǎng)上直接訪問。
既然這些地址屬于美國國防部，那他們開個(gè)公司在互聯(lián)網(wǎng)上發(fā)布這些地址有什么問題呢?
對(duì)遵循網(wǎng)絡(luò)協(xié)議，正常分配內(nèi)網(wǎng)地址的網(wǎng)絡(luò)沒有影響。然而，使用公網(wǎng)地址的內(nèi)部網(wǎng)絡(luò)可能會(huì)遇到兩個(gè)問題：
- 這種做法，破壞了互聯(lián)網(wǎng)運(yùn)行的規(guī)則，可能造成內(nèi)網(wǎng)不能正常訪問互聯(lián)網(wǎng)服務(wù)。
- 配置不完善不安全的網(wǎng)絡(luò)，會(huì)將本來僅限內(nèi)部的數(shù)據(jù)包發(fā)送到互聯(lián)網(wǎng)上去。
我們先來探討一下為什么會(huì)出現(xiàn)在內(nèi)網(wǎng)使用公網(wǎng)地址的現(xiàn)象。
大部分讀者都知道國家最近兩年在大力推進(jìn)IPv6，目的是從根本上解決我國 IPv4 地址短缺的情況。IPv4 地址短缺是全世界面對(duì)的共同問題，而且不僅僅是互聯(lián)網(wǎng)上 “公網(wǎng)” IPv4 地址短缺，各個(gè)NAT 機(jī)制后面的 “私網(wǎng)” IPv4 地址也存在嚴(yán)重的地址短缺，這種現(xiàn)象在大中型網(wǎng)絡(luò)中更為明顯。
下列地址在一月之前只是分配給了美國國防部，并沒有使用BGP 向全球宣告。
這些地址范圍，包括：
- 6.0.0.0 - 6.255.255.255
- 7.0.0.0 - 7.255.255.255
- 11.0.0.0 - 11.255.255.255
- 21.0.0.0 - 21.255.255.255
- 22.0.0.0 - 22.255.255.255
- 26.0.0.0 - 26.255.255.255
- 28.0.0.0 - 28.255.255.255
- 29.0.0.0 - 29.255.255.255
- 30.0.0.0 - 30.255.255.255
- 33.0.0.0 - 33.255.255.255
- 55.0.0.0 - 55.255.255.255
- 214.0.0.0 - 214.255.255.255
- 215.0.0.0 - 215.255.255.255
如果你管理一個(gè)大中型網(wǎng)絡(luò)，且內(nèi)部使用了上述地址，請(qǐng)立即在網(wǎng)絡(luò)邊界阻斷對(duì)這些地址的訪問，詳細(xì)步驟見后文。
RFC 1918 規(guī)定了三個(gè)組織內(nèi)部可以使用的私網(wǎng)地址段分別是：
- 10.0.0.0 - 10.255.255.255
- 172.16.0.0 - 172.31.255.255
- 192.168.0.0 - 192.168.255.255
其中最大 “私網(wǎng)” 地址段10.0.0.0 - 10.255.255.255，是大中型網(wǎng)絡(luò)的選擇。
第一段是 10 不變，第四段一般用于標(biāo)識(shí)一個(gè)網(wǎng)絡(luò)內(nèi)的主機(jī)地址，第二第三段用于標(biāo)識(shí)不同的部門或地理位置，所以第二段第三段合起來確定一個(gè)/24 的方便識(shí)別的子網(wǎng)。
這樣的網(wǎng)絡(luò)理論上最多承載 2^16 =65536 個(gè)子網(wǎng)，現(xiàn)實(shí)中的分配則相當(dāng)粗曠，為了便于人類識(shí)別，往往為某個(gè)功能塊分配幾十個(gè) /24 的子網(wǎng)，形如 10.20.20.0/24，10.200.20.0/24。組織結(jié)構(gòu)稍微復(fù)雜一點(diǎn)或者經(jīng)常變動(dòng)，地址很快就不夠分配了。
這時(shí)就會(huì)有很多網(wǎng)絡(luò)工程師提出使用 1，2，3，4，5，6，7，8，9，11，20，30，40，50……等等開頭看起來特殊的 IP 地址在內(nèi)網(wǎng)使用。
這就是為什么有些網(wǎng)絡(luò)內(nèi)部會(huì)出現(xiàn)這些奇怪的地址。
現(xiàn)象1：內(nèi)網(wǎng)不能正常訪問互聯(lián)網(wǎng)服務(wù)
上述地址在互聯(lián)網(wǎng)上使用 BGP 宣告之前，看起來是沒有問題的。然而一旦這些地址開始在互聯(lián)網(wǎng)上使用或出售繼而開始通過BGP 宣告，很快這些地址就會(huì)開始承載各種互聯(lián)網(wǎng)服務(wù)。
然而此時(shí)，組織內(nèi)網(wǎng)絡(luò)配置了這些本應(yīng)屬于公網(wǎng)地址的子網(wǎng)，用戶漸漸會(huì)發(fā)現(xiàn)有一些網(wǎng)站打不開。這是因?yàn)閿?shù)據(jù)包在流經(jīng)內(nèi)部網(wǎng)絡(luò)路由器時(shí)，受路由條目的影響，在到達(dá)互聯(lián)網(wǎng)出口之前，就被轉(zhuǎn)發(fā)到內(nèi)網(wǎng)對(duì)應(yīng)網(wǎng)段，而這些網(wǎng)段往往是沒有用戶需要訪問的服務(wù)的。
最經(jīng)典的例子莫過于Cloudflare 在 2018 年開始使用 1.1.1.1 提供 DNS 服務(wù)，結(jié)果發(fā)現(xiàn)很多用戶無法訪問，除了一些運(yùn)營商的配置問題外，很多網(wǎng)絡(luò)設(shè)備操作系統(tǒng)或默認(rèn)配置中存在包含1.1.1.1的路由。
現(xiàn)象2：僅限內(nèi)部的數(shù)據(jù)包發(fā)送到互聯(lián)網(wǎng)
上述情況僅限于內(nèi)網(wǎng)對(duì)應(yīng)地址在互聯(lián)網(wǎng)上提供了業(yè)務(wù)的情況，而美國國防部在互聯(lián)網(wǎng)上發(fā)布自己的地址，那些地址并沒有提供互聯(lián)網(wǎng)服務(wù)，會(huì)有什么樣的影響呢?
許多配置失誤的網(wǎng)絡(luò)，在同時(shí)滿足以下幾個(gè)條件時(shí)，本應(yīng)屬于內(nèi)部的數(shù)據(jù)包會(huì)到達(dá)美國國防部控制的GRS 網(wǎng)絡(luò)：
- 使用了不屬于自己的地址段(此例中是美國軍方地址)
- 內(nèi)部網(wǎng)絡(luò)路由表中并沒有對(duì)應(yīng)的條目
- 邊界網(wǎng)絡(luò)設(shè)備上并未配置對(duì)應(yīng)的 ACL 或安全策略阻斷這些地址
- 默認(rèn)路由指向互聯(lián)網(wǎng)接口，且能訪問互聯(lián)網(wǎng)
- 上游運(yùn)營商沒有對(duì)這些地址做特殊處理
眼尖的讀者一定發(fā)現(xiàn)了，會(huì)有本來目的地在私有網(wǎng)絡(luò)內(nèi)的數(shù)據(jù)包到達(dá)美國國防部控制的網(wǎng)絡(luò)，這存在嚴(yán)重的信息安全風(fēng)險(xiǎn)。
GRS 可以分析進(jìn)入他們網(wǎng)絡(luò)的所有數(shù)據(jù)包：
- 針對(duì) TCP 會(huì)話，可以構(gòu)建服務(wù)器響應(yīng)客戶端握手，進(jìn)而獲得泄漏出來的敏感數(shù)據(jù);
- UDP 是無連接協(xié)議，客戶端發(fā)送敏感數(shù)據(jù)不需要事先與服務(wù)器端握手建立連接;
- 統(tǒng)計(jì)單個(gè)原地址發(fā)來數(shù)據(jù)包的目的地址和端口，可以構(gòu)建該地址對(duì)應(yīng)內(nèi)網(wǎng)的服務(wù)器和端口列表。
根據(jù)公開信息，中國一些公有云、私有云和運(yùn)營商內(nèi)網(wǎng)中，存在不同程度的使用一些已經(jīng)分配給國外政府、軍隊(duì)、公司的公網(wǎng)地址?？梢韵氲剑瑑?nèi)網(wǎng)使用公網(wǎng)地址的模式長期運(yùn)行，由于誤配置造成的敏感數(shù)據(jù)流向互聯(lián)網(wǎng)是必然發(fā)生的，目前也正在發(fā)生。
對(duì)于已經(jīng)在內(nèi)網(wǎng)開始使用公網(wǎng)地址的網(wǎng)絡(luò)，網(wǎng)絡(luò)管理員應(yīng)該如何補(bǔ)救呢?
(1) 檢查自己網(wǎng)絡(luò)的路由表，找出既不屬于 RFC1918、RFC3927、RFC6598 定義的地址范圍，也不屬于互聯(lián)網(wǎng)運(yùn)營商或 CNNIC、APNIC 等區(qū)域 NIC 分配給自己的公網(wǎng)地址。
(2) 如果存在上述地址，補(bǔ)救方案要分為兩種情況：
- 與上級(jí)ISP使用BGP互聯(lián)。在運(yùn)行BGP的互聯(lián)網(wǎng)邊界路由器上，使用 route-map 等路由策略工具，在與ISP路由器相關(guān)的BGP配置中，雙向過濾掉上述地址。同時(shí)使用黑洞路由在邊界設(shè)備上將目的地是上述地址的數(shù)據(jù)包丟棄。
- 與ISP之間并無BGP關(guān)系，只是ISP的終端客戶。在邊界路由器或防火墻上，配置ACL、安全策略或黑洞路由，在邊界設(shè)備上將目的地是上述地址的數(shù)據(jù)包丟棄。
(3) 在實(shí)施補(bǔ)救方案后，針對(duì)內(nèi)部使用公網(wǎng)地址的情況，選擇一個(gè)徹底修復(fù)的方案：
- 遷移內(nèi)部應(yīng)用到 IPv6，完全避免使用 IPv4 地址。注意IPv6的地址應(yīng)該是正常渠道申請(qǐng)獲得的。如果完全不需要訪問互聯(lián)網(wǎng)，可以使用IPv6 ULA地址段，即fc00::/7 的后半段地址 fd00::/8，使用方法參見 RFC4193。
- 無法遷移到IPv6或預(yù)計(jì)使用時(shí)間不會(huì)超過5~10年的應(yīng)用，制定IP重新分配規(guī)劃，過渡期使用NAT幫助平滑過渡。
(4) 未來網(wǎng)絡(luò)地址規(guī)劃要考慮以下幾點(diǎn)：
- 不要盜用已經(jīng)分配給他人的 IP 地址
- 新建網(wǎng)絡(luò)選擇 IPv6 單棧結(jié)構(gòu)
- 無論 IPv4 還是 IPv6 都應(yīng)該在二進(jìn)制邊界劃分地址段
- 明確內(nèi)部地址范圍，在網(wǎng)絡(luò)邊界配置安全策略，防止地址偽造和數(shù)據(jù)泄露
(IANA IPv4 Special-Purpose Address Registry)
(IANA IPv6 Special-Purpose Address Registry)
結(jié)語
IP地址的規(guī)劃短則影響數(shù)年，長則影響數(shù)十年。20世紀(jì)90年代初的地址分配，在2021年給互聯(lián)網(wǎng)造成了巨大了影響。然而當(dāng)時(shí)沒有人能預(yù)計(jì)到互聯(lián)網(wǎng)如此迅猛發(fā)展，IPv4地址成為了稀缺資源。
抱著僥幸心理使用他人擁有的地址，破壞了互聯(lián)網(wǎng)運(yùn)行的規(guī)則，一方面隨著當(dāng)年IPv4地址的轉(zhuǎn)讓出售，會(huì)形成未來互聯(lián)互通的障礙，另一方面對(duì)自身造成了極大的信息安全風(fēng)險(xiǎn)。
關(guān)于 2020 年 6 月份有關(guān)美國國防部要出售這些IPv4 地址塊的消息及后續(xù)：
- 處理掉IPv4 地址眾議院修正案包含一項(xiàng)規(guī)定(第1088條)。
- 這將要求美國國防部在十年時(shí)間陸續(xù)出售一些IPv4 地址塊。
- 參議院法案中沒有類似規(guī)定。
- 眾議院退卻。
出處：https://www.congress.gov/congressional-report/116th-congress/house-report/333/1
當(dāng)前題目：美國防部這個(gè)大動(dòng)作，或造成我國內(nèi)網(wǎng)數(shù)據(jù)泄露
分享鏈接：http://www.dlmjj.cn/article/coeoggi.html
