【51CTO.com 7月26日外電頭條】拒絕服務(wù)（簡稱DoS）——特別是分布式拒絕服務(wù)（簡稱DDoS）——攻擊近來困擾著許多知名企業(yè)，從索尼公司到美國銀行皆未能幸免。

經(jīng)年以來，大多數(shù)企業(yè)都將DoS攻擊列為一種可接受范圍內(nèi)的安全風(fēng)險，因?yàn)槠浒l(fā)生概率與業(yè)務(wù)破壞風(fēng)險類似，相對較低。然而如今，這一類攻擊的出鏡頻率大為提高，進(jìn)而使得不少機(jī)構(gòu)不得不重新估量其相對危險性。CIO們懊惱于其所帶來的收益損失及負(fù)面新聞；IT部門也被其導(dǎo)致的應(yīng)用程序崩潰及額外工作量弄得焦頭爛額。

雖然沒人能徹底杜絕所有DDoS攻擊，但我們?nèi)匀挥修k法減弱其不良影響并使自己的機(jī)構(gòu)盡快從問題中恢復(fù)正常。在當(dāng)下的襲擊中，大多數(shù)是針對Web應(yīng)用程序而來——它們只需輕松地發(fā)送大量請求，即可讓目標(biāo)Web應(yīng)用程序應(yīng)接不暇，進(jìn)而導(dǎo)致其他訪問者無法正常使用。

[[37586]]

在這類攻擊活動中，大多數(shù)攻擊者并不在意目標(biāo)系統(tǒng)及應(yīng)用程序是否確實(shí)崩潰掉了，當(dāng)然如果崩潰結(jié)果真的發(fā)生，他們絕對會樂觀其成。事實(shí)上他們的主要訴求是通過給受害企業(yè)挖坑，進(jìn)而妨害合法用戶的正常操作。

如果大家具備適當(dāng)?shù)谋O(jiān)控技術(shù)，那么這類攻擊活動很容易被揪出來。我們的網(wǎng)絡(luò)操作中心（簡稱NOC）將明確反饋運(yùn)行現(xiàn)狀——帶寬、每秒請求數(shù)量以及系統(tǒng)資源使用情況等各項(xiàng)參數(shù)都應(yīng)顯示正常。一旦所有參數(shù)在很短或是較短的一段時間中突然增大并既而達(dá)到閾值，監(jiān)控系統(tǒng)將立即發(fā)出警報。

一般說來，成熟的機(jī)構(gòu)會立即就此做出反應(yīng)，例如調(diào)動IT團(tuán)隊(duì)中合適的技術(shù)人員加以處理。管理層也將很快拿到此次站點(diǎn)及應(yīng)用程序異常事態(tài)的通知，同時這種短時間內(nèi)各項(xiàng)參數(shù)急速提升的情況會立刻引起大家的警覺。

此時，除非你的網(wǎng)站上了Slashdot網(wǎng)站的主頁，否則最可能的情況一定是DDoS攻擊光顧了。恭喜！你現(xiàn)在正式成為DDoS受害者俱樂部中的一員——這些攻擊活動的通常起因是那幫家伙不喜歡你的企業(yè)政策，當(dāng)然也可能是有人花錢雇人來陰你。

首先我們要做的是對記錄請求信息的日志文件展開分析。你肯定想知道激增的請求到底在請求些啥功能，另外這些請求到底來自何處。通過對新請求與正常請求的對比來判斷這到底是洶涌而來的高人氣還是切實(shí)存在的攻擊行為。

要作個聰明人，集中管理日志記錄是不可或取的好習(xí)慣，這樣一來我們就可以立即著手系統(tǒng)分析而不必?fù)?dān)心查詢請求被淹沒在攻擊者的請求大潮中。遺憾的是，如果登錄服務(wù)無法正常運(yùn)作，那么它可能也處于過載狀態(tài)下了——這時日志文件可能丟失、你的搜索也可能得不到正確響應(yīng)。如果攻擊已經(jīng)徹底拿下了你的應(yīng)用程序，日志文件可能無法從受影響的服務(wù)器上傳輸?shù)降卿浵到y(tǒng)中。這時你必須搶在攻擊活動整體展開前進(jìn)行分析，否則就只能望洋興嘆了。

如果大家需要更多的當(dāng)前日志信息——而且還同時具備用于托管目標(biāo)應(yīng)用程序的冗余系統(tǒng)——可以將其中之一暫時從池中取出、獲取日志文件、再將其放回集群當(dāng)中。這種方式可能會在一段時間內(nèi)令攻擊活動的效果更加明顯，但如果不及時拿到日志文件，這幫賊人會在瘋狂地扇了我們無數(shù)耳光之后瞬間消失，而你再也沒機(jī)會將其繩之以法了。

一旦我們得到了日志文件，立刻選用自己最順手的排序工具及分析工具進(jìn)行處理。我個人的推薦是grep和sed。通過分析，我們可以從日志中找出一些關(guān)鍵性信息，并順藤摸瓜了解整個攻擊的實(shí)施過程并加以應(yīng)對。

首先，我們需要確定此次攻擊的實(shí)施方式。該攻擊是對某個遠(yuǎn)程系統(tǒng)上未開放的端口發(fā)送數(shù)據(jù)，進(jìn)而消耗大量防火墻資源嗎？還是在搞TCP三路握手，一遍又一遍地索取某個特定的URL？抑或是僅僅簡單地向網(wǎng)頁服務(wù)器發(fā)送基礎(chǔ)的"Get /HTTP/1.1"指令？

通過企業(yè)監(jiān)控系統(tǒng)，應(yīng)該有可能對當(dāng)前負(fù)載的所處位置加以鎖定。如果大家的防火墻已然失守但網(wǎng)頁服務(wù)器常未被攻陷，那么結(jié)論就是我們遇上了第一類攻擊。而如果網(wǎng)頁服務(wù)器在后方已經(jīng)被無數(shù)處理請求折磨得死去活來——同時防火墻尚能抵擋一陣，但資源占用率已經(jīng)高于平時——那么可以認(rèn)定網(wǎng)頁應(yīng)用程序是攻擊活動的直接目標(biāo)。

一旦攻擊方式得以確認(rèn)，我們接下來要做的就是通過日志文件對幾個關(guān)鍵因素進(jìn)行辨別。

通過查看日志文件內(nèi)容，我們能夠判斷出攻擊工具的實(shí)時動態(tài)。無論請求指向網(wǎng)頁應(yīng)用程序還是由防火墻在處理，我們觀察到的數(shù)據(jù)都是相同的。

首先，我們要識別出那些違規(guī)請求。日志文件中應(yīng)該可以清楚地留下攻擊痕跡，例如大量相似的請求或者以集合形式存在的一類請求。也就是說，其中可能存在上萬個嘗試訪問某個URL的請求或是指向某個無效的端口。

在某些情況下，分布式攻擊工具可能會產(chǎn)生不同類型的請求。但是總體來說，我們能夠找出來自同一資源且指向另一種相同資源的請求集合——例如日志中記錄下的不斷向某個不存在的URL發(fā)出的請求。由此我們可以判斷攻擊所使用的請求樣式。如果所有攻擊節(jié)點(diǎn)使用的都是同類請求，我們就具備了掌握攻擊者蛛絲馬跡并將其從正常流量中區(qū)分出來的鑰匙。

當(dāng)我們明確了請求的模式，下一步就是要揪出攻擊者。找到那些發(fā)送量最高且提交請求最快的攻擊節(jié)點(diǎn)，這些正是引起麻煩的罪魁禍?zhǔn)?，控制住它們能夠有效地緩解攻擊活動帶來的?fù)面作用。換言之，只要了解了攻擊請求的通常形式及其來源，我們就能夠有效地做出回應(yīng)。

在攻擊活動最猖獗的時期，我常常收到諸如將受影響的資源進(jìn)行重命名的建議——例如更改URL或是主機(jī)名稱。這么做可謂正中攻擊者的下懷；因?yàn)橹灰麄兏闱宄宋覀兊膽?yīng)對方式，就可以馬上重新組織進(jìn)攻、或是將目標(biāo)指向新的資源。

這種應(yīng)對策略只在攻擊活動調(diào)用了某個合法的網(wǎng)頁應(yīng)用程序URL時才會奏效，而該URL的作用是執(zhí)行諸如大型數(shù)據(jù)庫查詢等資源密集型工作。在這種情況下，修改應(yīng)用程序、部署確認(rèn)界面或是執(zhí)行一套會令攻擊者的工具無法解讀的重定向操作（例如CAPTCHA或者具備用戶確認(rèn)及重定向功能的Flash應(yīng)用程序）的確可以減輕攻擊造成的影響。然而遺憾的是，在大多數(shù)情況下，攻擊者會很快改變攻擊手段。

大家嘗試了上述初始應(yīng)對措施，下一級防御體系也隨之明確：源過濾、連接及速率限制。如果我們能夠?qū)⒅饕艚M件瓦解掉、并讓其余部分暫緩生效，攻擊活動的不良效果將大打折扣。要想繼續(xù)犯壞，攻擊者部署的各節(jié)點(diǎn)必須能夠在任何特定的時間段內(nèi)向我們的生產(chǎn)集群發(fā)出超過承載能力的大量請求。只要我們將其中一部分節(jié)點(diǎn)堵住，系統(tǒng)負(fù)載將立即得到有效降低，這就為大家封堵更多攻擊節(jié)點(diǎn)、向網(wǎng)絡(luò)供應(yīng)商通報問題、遷移服務(wù)項(xiàng)目或是靜待攻擊結(jié)束提供了機(jī)會。

為了盡量保護(hù)好自己的基礎(chǔ)設(shè)施，大家一定要將過濾系統(tǒng)部署在自己網(wǎng)絡(luò)中盡可能邊緣的位置上。如果我們可以說服自己的網(wǎng)絡(luò)供應(yīng)商或者數(shù)據(jù)中心管理員參與協(xié)助，那就非常理想了；因?yàn)樗麄兡茉谠O(shè)備上提供的過濾系統(tǒng)將提供最佳的屏蔽效果。他們的設(shè)備永遠(yuǎn)領(lǐng)先于我們的實(shí)際需求，因此將繁重的過濾工作交給他們可謂再合適不過。

如果大家由于種種原因而不得不在自己的設(shè)備上部署過濾系統(tǒng)——或者我們打算在上游供應(yīng)商回饋結(jié)果之前先做點(diǎn)積極的補(bǔ)救工作——邊緣設(shè)備和逆向工程是我們的切入點(diǎn)。充分調(diào)動一切手段屏蔽不良請求并盡可能減少系統(tǒng)遭受的負(fù)載沖擊。路由器、負(fù)載均衡、入侵防御系統(tǒng)、網(wǎng)頁應(yīng)用防火墻甚至系統(tǒng)本身，都能在拒絕請求方面發(fā)揮一定作用。

第一道過濾體系應(yīng)該斷開來自攻擊者的全部連接，因?yàn)樗鼈冋沁@海量請求的根源。此規(guī)則應(yīng)部署于我們訪問控制列表的最高優(yōu)先級上。當(dāng)然，我們的邊緣設(shè)備也不要再接受來自此類接口的數(shù)據(jù)流量，同時也不要回饋數(shù)據(jù)包。因?yàn)橐坏┌l(fā)出回應(yīng)，攻擊者們會迅速將其鎖定為額外的攻擊目標(biāo)。

接下來，我們要根據(jù)各類源的實(shí)際情況設(shè)置連接速率限制。這樣做的目的在于，一旦某些連入主機(jī)的新連接在特定時段內(nèi)達(dá)到限制條件，即會被立刻斷開。仔細(xì)檢查日志文件，并將限制條件設(shè)定地略寬于正常訪問請求。

如果大家不確定日志中哪些具體條目與攻擊者有關(guān)、而哪些又是正常的，那么將最大的攻擊來源作為出發(fā)點(diǎn)將是明智的選擇。由于主要攻擊來源發(fā)出請求的速度遠(yuǎn)高于平均水平，因此我們可能仍然漏掉了不少多余的請求。別忘了根據(jù)實(shí)際需要不斷進(jìn)行審查和調(diào)整。

此外，大家還可以調(diào)整主機(jī)及邊緣設(shè)備，以使其較平時更快終止空閑會話進(jìn)程進(jìn)而保持足夠的剩余資源。但要小心調(diào)整的幅度不能過大——因?yàn)檫@樣一來我們可能反而要在建立及關(guān)閉連接方面消耗更多的資源。

源屏蔽及速率限制工作完成之后，我們算是已經(jīng)在減輕攻擊活動帶來的負(fù)面影響方面取得了階段性進(jìn)展。如果此時攻擊仍沒有停止的跡象（且似乎沒完沒了），技術(shù)團(tuán)隊(duì)?wèi)?yīng)該立刻將工作重點(diǎn)放在保護(hù)那些尚未被觸及的業(yè)務(wù)之上。

通常情況下，攻擊者們會將目標(biāo)設(shè)定為特定的主機(jī)、應(yīng)用程序或是網(wǎng)絡(luò)。將指向這類資源的流量通過路由引導(dǎo)至其它位置——或是干脆放棄此類流量——確實(shí)能夠?yàn)楹蠖讼到y(tǒng)減輕負(fù)荷，但這同時意味著我們的服務(wù)項(xiàng)目也無法正常工作了，這正是攻擊者們希望看到的結(jié)果。

將受到攻擊的服務(wù)項(xiàng)目與尚未被觸及的其它服務(wù)項(xiàng)目隔離開來也是不錯的主意。只要大家有能力將受影響的服務(wù)從不相關(guān)的項(xiàng)目中獨(dú)立出來，我們就沒有理由坐以待斃、看著全套業(yè)務(wù)系統(tǒng)逐漸陷入癱瘓。

如果大家通過互聯(lián)網(wǎng)提供服務(wù)項(xiàng)目，那么各位實(shí)際上都是DDoS攻擊的潛在目標(biāo)。而這種攻擊實(shí)際到來的可能性，取決于我們各自的經(jīng)營方式、攻擊者的突發(fā)奇想以及那些對我們的企業(yè)感到不滿的人群。盡管無法完全避免，但我們?nèi)杂胁簧俅胧┫魅豕粲绊懀禾岣邩I(yè)務(wù)能力、部署冗余站點(diǎn)、隔離服務(wù)項(xiàng)目以及在攻擊來臨之前做好充分的應(yīng)對計(jì)劃。

原文鏈接：

http://www.darkreading.com/database-security/167901020/security/attacks-breaches/231002379/tech-insight-how-to-respond-to-a-denial-of-service-attack.html

 【51CTO.com獨(dú)家譯稿，非經(jīng)授權(quán)謝絕轉(zhuǎn)載！合作媒體轉(zhuǎn)載請注明原文出處及出處！】