目前，CDN技術到處可見。像網(wǎng)宿、藍訊、加速樂等都依靠CDN過活，連安全寶也都使用了CDN技術，當然很多域名空間商現(xiàn)在也提供CDN服務。從以往互聯(lián)網(wǎng)的發(fā)展上看，CDN是個趨勢，很多廠商也都多多少少購買了商業(yè)化的CDN資源，比如360、騰訊、百度、新浪等等等，當然大部分流量還是走自建的CDN網(wǎng)絡。

本文筆者站從安全的角度出發(fā)，對CDN技術進剖析，揭開廠商使用CDN技術的風險、分析了黑客及黑產(chǎn)新的攻擊方向。實際上只要對CDN的工作流程有一定了解，并能夠對數(shù)據(jù)報文的流向比較清楚，就能夠獲取其風險點了，在文中筆者只對動態(tài)頁面的請求流程做討論(靜態(tài)頁面一般不回源)，至于靜態(tài)頁大部分由節(jié)點的webcache直接返回，一般不含敏感信息(cookie實際上是敏感信息)，所以不做討論。

一.CDN工作流程如下圖：

1.管理員或者站長將域名的DNS指向CDN廠商的DNS上(當然，根據(jù)選擇不同也有可能使用CName方式，但都不影響數(shù)據(jù)流的流向)。

2.用戶需要登錄站點，請求DNS以便獲得服務器IP(此處最終請求的DNS服務器為CDN廠商的DNS)

3.CDN廠商收到DNS查詢請求及各種信息，通過各種算法選擇一個離用戶最近的節(jié)點，將該節(jié)點的IP 1.1.1.1作為服務器IP返回給用戶(此處CDN廠商告訴用戶一個假的服務器IP)

4.用戶收到DNS響應，將HTTP請求(該處為登錄請求，請求報文包含用戶密碼)發(fā)給1.1.1.1

5.CDN節(jié)點接收到請求包判斷請求報文是否是動態(tài)頁面，如果是靜態(tài)則查看webcache，存在緩存直接返回緩存頁面。如果是動態(tài)頁面請求或者沒有緩存的靜態(tài)頁面，節(jié)點則直接請求真實源，以便獲取最新的內(nèi)容。(注:此處對于動態(tài)頁面的請求一般每次都會做回源操作)

6.接著就是服務器響應請求，此處不做討論

二.CDN的軟肋

由上圖可知，對于網(wǎng)站的請求報文都會經(jīng)過CDN廠商的節(jié)點(不做特殊操作的情況下)。因此安全隱患全都集中在了CDN廠商的節(jié)點上。一般一個節(jié)點會提供N多個網(wǎng)站的加速。不管是360、騰訊、百度還是新浪，只要使用了商業(yè)化的CDN，就相當于孤注一擲，將自己的部分安全交給CDN廠商。一旦攻擊者控制了CDN廠商節(jié)點就可以輕易的進行抓包并分析。對于CDN廠商來說，畢竟不是專業(yè)的安全公司，所以在防護方面肯定會有所不足CDN廠商節(jié)點遍布全國，數(shù)量眾多，很難保證每個節(jié)點的安全性(再不行可試下ARP欺騙，從同段IP搞起)

三.從CDN看黑產(chǎn)動向

1.以往攻擊者對目標發(fā)起攻擊都會先對目標IP進行掃描和檢測，但由于CDN的存在，很多攻擊者無法直接獲取到源IP，因此轉而對CDN節(jié)點發(fā)起攻擊，一旦攻陷節(jié)點，那拿到站點權限就是遲早的事情，另外在這個信息發(fā)達的時代一般都是買一送多，大數(shù)據(jù)時代，一個結點的網(wǎng)站夠撐死你了。目測接下來對CDN節(jié)點的攻擊會成為黑色產(chǎn)業(yè)鏈的熱門話題(估計已經(jīng)很熱了，只是我不知道)

2.CDN廠商實際上可以成為黑產(chǎn)的大數(shù)據(jù)提供商，對于應用軟件你可以本地分析看是否在后臺偷偷上傳數(shù)據(jù)，對于CDN你能么，筆者建議少用免費的CDN服務，除非你已經(jīng)麻木了，或者你做了特殊的手段。

3.大型企業(yè)會增加對自建CDN的安全維護成本，同時攻擊者會將大部分時間放在對企業(yè)CDN網(wǎng)絡的攻擊上

四.由CDN到DNS劫持

百度經(jīng)常被黑、某黑闊站點又被hellen干掉了、XXX也被整了。到頭來都是DNS劫持。難道DNS劫持就只能換個頁面?或只能讓用戶訪問惡意站點?看了CDN的工作原理，結合APT攻擊。長時間盯著就OK了。某天的某一時刻，某人說能控制某域名的DNS解析，問怎么利用。估計看了前面原理的人都想到了如何進一步利用DNS劫持了，筆者在這里發(fā)表幾個個人的方法，僅供參考。

1.搭建小型CDN網(wǎng)絡，一個節(jié)點、一個自己的域名、一個自己搭建的DNS服務器。修改域名DNS指向自己搭建的DNS，從而將站點的訪問流量全部牽引到自己的節(jié)點上，在自己節(jié)點裝抓包軟件(如何搭建CDN網(wǎng)絡可以找找相關資料)

2.搭建中轉服務器(代理服務器)，將域名解析到自己的服務器上，由攻擊者的服務器進行中轉(實際上利用本地的HOST及某些數(shù)據(jù)轉發(fā)軟件就可以實現(xiàn))。這個比上面一點好多了，少了個DNS服務器。

3.完全利用HTTP協(xié)議，寫個PHP腳本，對接收到的報文進行轉發(fā)，當然筆者在這邊通過測試，該方法效率不高，剛開始忘記cookie的處理，導致用戶無法登錄，后面對cookie進行了處理后成功轉發(fā)，但缺點是“速度像蝸牛”!