建站
咨詢
售后
建站咨詢
新聞中心
首先，為了對(duì)CDN進(jìn)行攻擊，我們必須清楚CDN的工作原理，這里我們?cè)賮砗?jiǎn)單介紹一下CDN的工作模型。
創(chuàng)新互聯(lián)建站是專業(yè)的青川網(wǎng)站建設(shè)公司，青川接單;提供網(wǎng)站設(shè)計(jì)、做網(wǎng)站,網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行青川網(wǎng)站開發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!
CDN的全稱是Content Delivery Network(內(nèi)容分發(fā)網(wǎng)絡(luò))，通過在網(wǎng)絡(luò)各處的加速節(jié)點(diǎn)服務(wù)器來為網(wǎng)站抵擋惡意流量，把正常流量進(jìn)行轉(zhuǎn)發(fā)。用簡(jiǎn)單點(diǎn)的話來說，CDN一般有三個(gè)作用
1. 跨運(yùn)營(yíng)商加速：我們自己的網(wǎng)站常常只屬于一個(gè)運(yùn)營(yíng)商(比如：電信)，而加速節(jié)點(diǎn)遍布每家運(yùn)營(yíng)商，于是和網(wǎng)站不同運(yùn)營(yíng)商(比如：聯(lián)通)的用戶訪問起來就不會(huì)那么慢了。
2. 緩存加速：很多的靜態(tài)資源以及一部分頁(yè)面更新都是比較慢的(比如首頁(yè))，這個(gè)時(shí)候CDN就會(huì)根據(jù)瀏覽器的max-age和last-modified值以及管理員的預(yù)設(shè)值來進(jìn)行緩存，于是很多流量CDN節(jié)點(diǎn)就不會(huì)每次都來向網(wǎng)站請(qǐng)求，CDN節(jié)點(diǎn)可以直接自作主張地將命中的緩存內(nèi)容返回。
3. 惡意流量過濾：這是CDN非常重要的一個(gè)作用，也是很多網(wǎng)站會(huì)用CDN的原因，因?yàn)镃DN能為我們抵擋攻擊大流量攻擊、普通的攻擊(比如注入等)，只有正常流量才會(huì)轉(zhuǎn)發(fā)給網(wǎng)站。
這里還要說明幾個(gè)名詞：
源站：我們自己的那個(gè)網(wǎng)站就被稱為是源站。
反向代理：CDN節(jié)點(diǎn)向源站請(qǐng)求數(shù)據(jù)的方式就叫反向代理，也就是上文所說的轉(zhuǎn)發(fā)。
回源：CDN節(jié)點(diǎn)向源站請(qǐng)求數(shù)據(jù)的行為就叫做回源。
下面開始我們的探究之旅。
我們?cè)谧鯫penCDN測(cè)試的時(shí)候，遇到了一些小問題。發(fā)現(xiàn)一個(gè)沒有人訪問的網(wǎng)站居然會(huì)有流量，并且有著驚人的訪問次數(shù)。
我們的OpenCDN有2分鐘一次的反向代理檢測(cè)，但是這次數(shù)加起來也就區(qū)區(qū)的720次，而這400萬的訪問次數(shù)是哪里冒出來的?然后我們查看了日志，發(fā)現(xiàn)單個(gè)域名的日志到達(dá)了58G之多，而將其打開之后發(fā)現(xiàn)X-Forwarded-For字段中(X-Forwarded-For機(jī)制是通過一層代理后記錄一個(gè)IP，讓源站在使用CDN后能夠獲得真實(shí)的訪客IP而不是CDN節(jié)點(diǎn)IP)充斥著大量有的IP，而且都是本服務(wù)器IP。我們瞬間明白了什么，然后去管理端上驗(yàn)證了一下，果不其然地，我們一不小心把源站IP設(shè)成了CDN節(jié)點(diǎn)的IP，不過當(dāng)時(shí)我們并沒有發(fā)現(xiàn)。于是這么大的流量也好解釋了，由于2分鐘一次的檢測(cè)觸發(fā)CDN節(jié)點(diǎn)的回源，而這個(gè)站點(diǎn)的源站是CDN節(jié)點(diǎn)本身，于是CDN就開始不斷自身反向代理死循環(huán)，這樣一個(gè)請(qǐng)求就被無限地放大了。當(dāng)超時(shí)或者HEADER太大(就是X-Forwarded-For字段導(dǎo)致HEADER溢出)的時(shí)候，請(qǐng)求會(huì)被丟棄。
把站點(diǎn)的源站IP設(shè)為CDN節(jié)點(diǎn)本身，能夠讓CDN節(jié)點(diǎn)進(jìn)行自我的反向代理死循環(huán)，然后放大流量。
貌似有點(diǎn)意思，小伙伴們于是馬上就行動(dòng)起來了，進(jìn)行了實(shí)驗(yàn)。
我們?cè)诎踩珜毶铣晒Φ貙⒃凑綢P設(shè)置成了某個(gè)為我們加速的CDN節(jié)點(diǎn)IP，然后在美帝的一臺(tái)小vps上開webbench用2000個(gè)線程去打這個(gè)這個(gè)站點(diǎn)(無論是哪個(gè)CDN節(jié)點(diǎn)收到請(qǐng)求，請(qǐng)求最終都會(huì)匯聚到那個(gè)無辜的被設(shè)源站的CDN節(jié)點(diǎn))，不過實(shí)驗(yàn)結(jié)果并不理想，節(jié)點(diǎn)沒有宕機(jī)，通過IP反查找到一臺(tái)和我們公用一個(gè)CDN節(jié)點(diǎn)的網(wǎng)站，通過這個(gè)CDN節(jié)點(diǎn)反向代理訪問那個(gè)網(wǎng)站，出現(xiàn)了卡頓和打不開情況，僅此而已。由于沒法采集到安全寶的這個(gè)節(jié)點(diǎn)的性能數(shù)據(jù)，我們也沒法對(duì)我們的攻擊做出評(píng)估。而且我們這個(gè)實(shí)驗(yàn)缺少了一個(gè)對(duì)照組，到底是因?yàn)樗姥h(huán)把流量放大導(dǎo)致CDN節(jié)點(diǎn)卡頓，還是這個(gè)2000線程本身就能把CDN節(jié)點(diǎn)打卡。
于是我們總結(jié)了一下，猜想這種節(jié)點(diǎn)反向代理自身的攻擊手法可能可以適用于這樣的場(chǎng)景
你想要攻擊某個(gè)CDN節(jié)點(diǎn)，但是如果打404頁(yè)面消耗不了太多，而如果打CDN中的某個(gè)站點(diǎn)，因?yàn)榱髁繒?huì)穿透過去，可能還沒有把CDN節(jié)點(diǎn)打掉，背后的站點(diǎn)早被穿透死了。這個(gè)時(shí)候，如果讓節(jié)點(diǎn)進(jìn)行自身反向代理死循環(huán)，他就會(huì)把所有的流量給吃進(jìn)去，并且沒法吐出來，這個(gè)時(shí)候可以產(chǎn)生一定量的流量杠桿效應(yīng)，可以使得CDN節(jié)點(diǎn)出現(xiàn)異常。
不過話說回來，這種攻擊的防御方式也異常簡(jiǎn)單，只要在設(shè)置源站IP的時(shí)候，不讓設(shè)置CDN節(jié)點(diǎn)IP就行了，只要在網(wǎng)站前端交互輸入的時(shí)候加點(diǎn)驗(yàn)證就行了。
我們考慮到我們沒法對(duì)不是我們的CDN節(jié)點(diǎn)的帶寬上限，性能上限有個(gè)很好的評(píng)估，黑盒式的摸索可能帶來不了什么，于是我們拿我們自己的CDN節(jié)點(diǎn)開刀。
同時(shí)我們繼續(xù)對(duì)這個(gè)思路進(jìn)行探索。我們發(fā)現(xiàn)，既然一個(gè)節(jié)點(diǎn)能死循環(huán)，那兩個(gè)節(jié)點(diǎn)怎么樣?結(jié)果是肯定的，并且產(chǎn)生了質(zhì)的變化。我們假設(shè)了這樣的一個(gè)場(chǎng)景
我們的opencdn.cc在甲CDN服務(wù)商注冊(cè)服務(wù)，并且在乙CDN服務(wù)商注冊(cè)服務(wù)，然后我們得到甲CDN服務(wù)商的一個(gè)CDN加速節(jié)點(diǎn)1.1.1.1，然后又得到乙CDN服務(wù)商的一個(gè)CDN加速節(jié)點(diǎn)2.2.2.2。 然后聰明的你一定已經(jīng)猜到了。我們把在甲CDN服務(wù)商設(shè)置源站為乙的加速節(jié)點(diǎn)2.2.2.2，在乙CDN服務(wù)商設(shè)置源站為甲的加速節(jié)點(diǎn)1.1.1.1，然后甲會(huì)問乙去索取源站，乙又來問甲索取源站，于是1.1.1.1和2.2.2.2就很開心地并且不停地交流了起來~
于是我們也進(jìn)行了實(shí)驗(yàn)。這次我們采用POST包進(jìn)行測(cè)試。
用POST包的原因有兩個(gè)
1.CDN節(jié)點(diǎn)是會(huì)有緩存機(jī)制的，剛剛你請(qǐng)求的地址命中緩存，那么就直接返回，不會(huì)成為死循環(huán)了，而POST包則有一個(gè)很好的特性，絕對(duì)回源，一點(diǎn)也不含糊。
2.POST包可以擴(kuò)大體積，在同等連接數(shù)的情況下讓效應(yīng)更加明顯。
我們本次測(cè)試發(fā)送500個(gè)POST包，每個(gè)體積大概為10k左右。然后總共發(fā)送的流量為5M。
然后讓我們來看下兩個(gè)節(jié)點(diǎn)的反應(yīng)
不過似乎到了帶寬上限。因?yàn)槲覀兪种械臋C(jī)器畢竟也不是很給力。
然后讓我們來看下這500個(gè)POST包產(chǎn)生的效果
58.215.139.124 RX bytes:5473847154 (5.0 GiB) TX bytes:17106340685 (15.9 GiB) RX bytes:6014294496 (5.6 GiB) TX bytes:17717990777 (16.5 GiB) 流入 540447342(515MB) 流出 611650092(583MB) 112.65.231.233 RX bytes:5583125549 (5.1 GiB) TX bytes:5022744608 (4.6 GiB) RX bytes:6133578284 (5.7 GiB) TX bytes:5649798353 (5.2 GiB) 流入 550452735(524MB) 流出 627053745(598MB)
我們拿最小的進(jìn)行測(cè)算吧，大概把流量擴(kuò)大了100倍左右，然后如果把流入流出加起來就是擴(kuò)大了200倍左右。
這一種攻擊方式和前一種相比有兩個(gè)優(yōu)點(diǎn)
1.CDN服務(wù)商不能把源站IP做限制來防御，因?yàn)樗麩o法知道別家的CDN節(jié)點(diǎn)IP。
2.能借刀殺人，可以用一家CDN服務(wù)商的CDN節(jié)點(diǎn)來打另外一家CDN服務(wù)商。
然后我們還進(jìn)行了一些聯(lián)想，一個(gè)站點(diǎn)可以把兩個(gè)節(jié)點(diǎn)陷入死循環(huán)，如果把更多的節(jié)點(diǎn)來進(jìn)來呢?
我們可以這樣。讓多個(gè)CDN節(jié)點(diǎn)和一個(gè)CDN節(jié)點(diǎn)死循環(huán)，把中間的CDN節(jié)點(diǎn)帶寬耗盡。
我們還可以這樣。讓三個(gè)CDN節(jié)點(diǎn)死循環(huán)，如果有做流量上的流入流出探測(cè)限制，這樣能保證流入流出不為一個(gè)IP。
畢竟在CDN服務(wù)商添加一個(gè)域名的代價(jià)是很小的(免費(fèi))，我們可以用一個(gè)一個(gè)域名將節(jié)點(diǎn)串起來，然后啪一下開始流量死循環(huán)震蕩。
好了，讓我們用四個(gè)字總結(jié)一下這次的漏洞的特點(diǎn)：借力打力。
那么如何來防御這種以及可能演化出來的攻擊呢?
1. 禁止把源站IP設(shè)為CDN節(jié)點(diǎn)本身(這是必須的)。
2. 限制每個(gè)站點(diǎn)的帶寬。
3. 對(duì)請(qǐng)求超時(shí)的源站做一定限制。
4. 通過X-Forwarded-For來進(jìn)行限制，超過多少層自動(dòng)丟棄。
以及CDN節(jié)點(diǎn)已經(jīng)存在的一系列的軟硬防都可以讓一部分的攻擊流量無法成型，自然也無法形成死循環(huán)震蕩。
本文僅為一種CDN流量放大攻擊的思路，只是做過一些小規(guī)模的實(shí)驗(yàn)，也歡迎大牛們進(jìn)行驗(yàn)證。如有不足之處或者邏輯上的錯(cuò)誤還請(qǐng)?zhí)岢觯x謝您的閱讀。
名稱欄目：CDN流量放大攻擊思路
分享網(wǎng)址：http://m.5511xx.com/article/coccese.html
