起首，為了對(duì)CDN進(jìn)行報(bào)復(fù)打擊，我們必需清晰CDN的工作道理，這里我們?cè)賮砗唵谓榻B一下CDN的工作模型。
CDN的全稱是Content Delivery Network(內(nèi)容分發(fā)收集)，經(jīng)由過程在收集遍地的加快節(jié)點(diǎn)辦事器來為網(wǎng)站抵當(dāng)歹意流量，把正常流量進(jìn)行轉(zhuǎn)發(fā)。用簡單點(diǎn)的話來講，CDN一般有三個(gè)感化
1. 跨運(yùn)營商加快：我們本身的網(wǎng)站常常只屬于一個(gè)運(yùn)營商(好比：電信)，而加快節(jié)點(diǎn)遍及每家運(yùn)營商，因而和網(wǎng)站不合運(yùn)營商(好比：聯(lián)通)的用戶拜候起來就不會(huì)那么慢了。
2. 緩存加快：良多的靜態(tài)資本和一部門頁面更新都是比較慢的(好比首頁)，這個(gè)時(shí)辰CDN就會(huì)按照瀏覽器的max-age和last-modified值和治理員的預(yù)設(shè)值來進(jìn)行緩存，因而良多流量CDN節(jié)點(diǎn)就不會(huì)每次都來向網(wǎng)站要求，CDN節(jié)點(diǎn)可以直接自作主張地將射中的緩存內(nèi)容返回。
3. 歹意流量過濾：這是CDN很是首要的一個(gè)感化，也是良多網(wǎng)站會(huì)用CDN的啟事，因?yàn)镃DN能為我們抵當(dāng)報(bào)復(fù)打擊大年夜流量報(bào)復(fù)打擊、通俗的報(bào)復(fù)打擊(好比注進(jìn)等)，只有正常流量才會(huì)轉(zhuǎn)發(fā)給網(wǎng)站。
這里還要申明幾個(gè)名詞：
源站：我們本身的阿誰網(wǎng)站就被稱為是源站。
反向代辦署理：CDN節(jié)點(diǎn)向源站要求數(shù)據(jù)的編制就叫反向代辦署理，也就是上文所說的轉(zhuǎn)發(fā)。
回源：CDN節(jié)點(diǎn)向源站要求數(shù)據(jù)的行動(dòng)就叫做回源。
下面開端我們的切磋之旅。
我們?cè)谧鯫penCDN測(cè)試的時(shí)辰，碰著了一些小標(biāo)題問題。發(fā)現(xiàn)一個(gè)沒有人拜候的網(wǎng)站竟然會(huì)有流量，并且有著驚人的拜候次數(shù)。
我們的OpenCDN有2分鐘一次的反向代辦署理檢測(cè)，可是此次數(shù)加起來也就戔戔的720次，而這400萬的拜候次數(shù)是哪里冒出來的?然后我們查看了日記，發(fā)現(xiàn)單個(gè)域名的日記達(dá)到了58G之多，而將其打開以后發(fā)現(xiàn)X-Forwarded-For字段中(X-Forwarded-For機(jī)制是經(jīng)由過程一層代辦署理跋文錄一個(gè)IP，讓源站在利用CDN后可以或許獲得真實(shí)的訪客IP而不是CDN節(jié)點(diǎn)IP)充滿著大年夜量有的IP，并且都是本辦事器IP。我們剎時(shí)大白了甚么，然后往治理端上驗(yàn)證了一下，果不其然地，我們一不謹(jǐn)慎把源站IP設(shè)成了CDN節(jié)點(diǎn)的IP，不外那時(shí)我們并沒有發(fā)現(xiàn)。因而這么大年夜的流量也好詮釋了，因?yàn)?分鐘一次的檢測(cè)觸發(fā)CDN節(jié)點(diǎn)的回源，而這個(gè)站點(diǎn)的源站是CDN節(jié)點(diǎn)本身，因而CDN就開端不竭本身反向代辦署理死輪回，如許一個(gè)要求就被無限地放大年夜了。當(dāng)超時(shí)或HEADER太大年夜(就是X-Forwarded-For字段導(dǎo)致HEADER溢出)的時(shí)辰，要求會(huì)被丟棄。
把站點(diǎn)的源站IP設(shè)為CDN節(jié)點(diǎn)本身，可以或許讓CDN節(jié)點(diǎn)進(jìn)行自我的反向代辦署理死輪回，然后放大年夜流量。
貌似有點(diǎn)意思，小火伴們因而頓時(shí)就步履起來了，進(jì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)收到要求，要求最終城市會(huì)聚到阿誰無辜的被設(shè)源站的CDN節(jié)點(diǎn))，不外嘗試成果其實(shí)不睬想，節(jié)點(diǎn)沒有宕機(jī)，經(jīng)由過程IP反查找到一臺(tái)和我們公用一個(gè)CDN節(jié)點(diǎn)的網(wǎng)站，經(jīng)由過程這個(gè)CDN節(jié)點(diǎn)反向代辦署理拜候阿誰網(wǎng)站，呈現(xiàn)了卡頓和打不開環(huán)境，僅此罷了。因?yàn)闆]法匯集到安然寶的這個(gè)節(jié)點(diǎn)的機(jī)能數(shù)據(jù)，我們也沒法對(duì)我們的報(bào)復(fù)打擊做出評(píng)估。并且我們這個(gè)嘗試貧乏了一個(gè)對(duì)比組，事實(shí)是因?yàn)樗垒喕匕蚜髁糠糯竽暌箤?dǎo)致CDN節(jié)點(diǎn)卡頓，仍是這個(gè)2000線程本身就可以把CDN節(jié)點(diǎn)打卡。
因而我們總結(jié)了一下，猜想這類節(jié)點(diǎn)反向代辦署理本身的報(bào)復(fù)打擊手法可能可以合用于如許的場(chǎng)景
你想要報(bào)復(fù)打擊某個(gè)CDN節(jié)點(diǎn)，可是假定打404頁面耗損不了太多，而假定打CDN中的某個(gè)站點(diǎn)，因?yàn)榱髁繒?huì)穿透過往，可能還沒有把CDN節(jié)點(diǎn)打掉落，背后的站點(diǎn)早被穿透死了。這個(gè)時(shí)辰，假定讓節(jié)點(diǎn)進(jìn)行本身反向代辦署理死輪回，他就會(huì)把所有的流量給吃進(jìn)往，并且沒法吐出來，這個(gè)時(shí)辰可以產(chǎn)生必然量的流量杠桿效應(yīng)，可使得CDN節(jié)點(diǎn)呈現(xiàn)異常。
不外話說回來，這類報(bào)復(fù)打擊的防御編制也異常簡單，只要在設(shè)置源站IP的時(shí)辰，不讓設(shè)置CDN節(jié)點(diǎn)IP就好了，只要在網(wǎng)站前端交互輸進(jìn)的時(shí)辰加點(diǎn)驗(yàn)證就好了。
我們考慮到我們沒法對(duì)不是我們的CDN節(jié)點(diǎn)的帶寬上限，機(jī)能上限有個(gè)很好的評(píng)估，黑盒式的試探可能帶來不了甚么，因而我們拿我們本身的CDN節(jié)點(diǎn)開刀。
同時(shí)我們繼續(xù)對(duì)這個(gè)思路進(jìn)行摸索。我們發(fā)現(xiàn)，既然一個(gè)節(jié)點(diǎn)能死輪回，那兩個(gè)節(jié)點(diǎn)如何樣?成果是必定的，并且產(chǎn)生了質(zhì)的改變。我們假定了如許的一個(gè)場(chǎng)景
我們的opencdn.cc在甲CDN辦事商注冊(cè)辦事，并且在乙CDN辦事商注冊(cè)辦事，然后我們獲得甲CDN辦事商的一個(gè)CDN加快節(jié)點(diǎn)1.1.1.1，然后又獲得乙CDN辦事商的一個(gè)CDN加快節(jié)點(diǎn)2.2.2.2。 然后智慧的你必然已猜到了。我們把在甲CDN辦事商設(shè)置源站為乙的加快節(jié)點(diǎn)2.2.2.2，在乙CDN辦事商設(shè)置源站為甲的加快節(jié)點(diǎn)1.1.1.1，然后甲會(huì)問乙往索取源站，乙又來問甲索取源站，因而1.1.1.1和2.2.2.2就很高興地并且不斷地交換了起來~
因而我們也進(jìn)行了嘗試。此次我們采取POST包進(jìn)行測(cè)試。
用POST包的啟事有兩個(gè)
1.CDN節(jié)點(diǎn)是會(huì)有緩存機(jī)制的，方才你要求的地址射中緩存，那么就直接返回，不會(huì)成為死輪回了，而POST包則有一個(gè)很好的特點(diǎn)，盡對(duì)回源，一點(diǎn)也不含混。
2.POST包可以擴(kuò)大年夜體積，在劃連續(xù)接數(shù)的環(huán)境下讓效應(yīng)加倍較著。
我們本次測(cè)試發(fā)送500個(gè)POST包，每個(gè)別積大年夜概為10k擺布。然后總共發(fā)送的流量為5M。
然后讓我們來看下兩個(gè)節(jié)點(diǎn)的反應(yīng)
不外仿佛到了帶寬上限。因?yàn)槲覀兪种械臋C(jī)械事實(shí)也不是很給力。
然后讓我們來看下這500個(gè)POST包產(chǎn)生的結(jié)果
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)
流進(jìn) 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)
流進(jìn) 550452735(524MB) 流出 627053745(598MB)
我們拿最小的進(jìn)行測(cè)算吧，大年夜概把流量擴(kuò)大年夜了100倍擺布，然后假定把流進(jìn)流出加起來就是擴(kuò)大年夜了200倍擺布。
這一種報(bào)復(fù)打擊編制和前一種比擬有兩個(gè)長處
1.CDN辦事商不克不及把源站IP做限制來防御，因?yàn)樗麤]法知道別家的CDN節(jié)點(diǎn)IP。
2.能借刀殺人，可以用一家CDN辦事商的CDN節(jié)點(diǎn)來打別的一家CDN辦事商。
然后我們還進(jìn)行了一些聯(lián)想，一個(gè)站點(diǎn)可以把兩個(gè)節(jié)點(diǎn)陷進(jìn)死輪回，假定把更多的節(jié)點(diǎn)來進(jìn)來呢?
我們可以如許。讓多個(gè)CDN節(jié)點(diǎn)和一個(gè)CDN節(jié)點(diǎn)死輪回，把中間的CDN節(jié)點(diǎn)帶寬耗盡。
我們還可以如許。讓三個(gè)CDN節(jié)點(diǎn)死輪回，假定有做流量上的流進(jìn)流出探測(cè)限制，如許能包管流進(jìn)流出不為一個(gè)IP。
事其實(shí)CDN辦事商添加一個(gè)域名的代價(jià)是很小的(免費(fèi))，我們可以用一個(gè)一個(gè)域名將節(jié)點(diǎn)串起來，然后啪一下開端流量死輪回震動(dòng)。
好了，讓我們用四個(gè)字總結(jié)一下此次的縫隙的特點(diǎn)：借力打力。
那么若何來防御這類和可能演變出來的報(bào)復(fù)打擊呢?
1. 避免把源站IP設(shè)為CDN節(jié)點(diǎn)本身(這是必需的)。
2. 限制每個(gè)站點(diǎn)的帶寬。
3. 對(duì)要求超時(shí)的源站做必然限制。
4. 經(jīng)由過程X-Forwarded-For來進(jìn)行限制，超越多少層主動(dòng)丟棄。
和CDN節(jié)點(diǎn)已存在的一系列的軟硬防都可讓一部門的報(bào)復(fù)打擊流量沒法成型，天然也沒法構(gòu)成死輪回震動(dòng)。
本文僅為一種CDN流量放大年夜報(bào)復(fù)打擊的思路，只是做過一些小范圍的嘗試，也歡迎大年夜牛們進(jìn)行驗(yàn)證。如有不足的地方或邏輯上的弊端還請(qǐng)?zhí)岢觯兄x您的瀏覽。