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

經年以來，大多數企業都將DoS攻擊列為一種可接受范圍內的安全風險，因為其發生概率與業務破壞風險類似，相對較低。然而如今，這一類攻擊的出鏡頻率大為提高，進而使得不少機構不得不重新估量其相對危險性。CIO們懊惱于其所帶來的收益損失及負面新聞；IT部門也被其導致的應用程序崩潰及額外工作量弄得焦頭爛額。

雖然沒人能徹底杜絕所有DDoS攻擊，但我們仍然有辦法減弱其不良影響并使自己的機構盡快從問題中恢復正常。在當下的襲擊中，大多數是針對Web應用程序而來——它們只需輕松地發送大量請求，即可讓目標Web應用程序應接不暇，進而導致其他訪問者無法正常使用。

[[37586]]

在這類攻擊活動中，大多數攻擊者并不在意目標系統及應用程序是否確實崩潰掉了，當然如果崩潰結果真的發生，他們絕對會樂觀其成。事實上他們的主要訴求是通過給受害企業挖坑，進而妨害合法用戶的正常操作。

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

一般說來，成熟的機構會立即就此做出反應，例如調動IT團隊中合適的技術人員加以處理。管理層也將很快拿到此次站點及應用程序異常事態的通知，同時這種短時間內各項參數急速提升的情況會立刻引起大家的警覺。

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

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

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

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

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

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

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

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

通過查看日志文件內容，我們能夠判斷出攻擊工具的實時動態。無論請求指向網頁應用程序還是由防火墻在處理，我們觀察到的數據都是相同的。

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

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

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

在攻擊活動最猖獗的時期，我常常收到諸如將受影響的資源進行重命名的建議——例如更改URL或是主機名稱。這么做可謂正中攻擊者的下懷；因為只要他們搞清楚了我們的應對方式，就可以馬上重新組織進攻、或是將目標指向新的資源。

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

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

為了盡量保護好自己的基礎設施，大家一定要將過濾系統部署在自己網絡中盡可能邊緣的位置上。如果我們可以說服自己的網絡供應商或者數據中心管理員參與協助，那就非常理想了；因為他們能在設備上提供的過濾系統將提供最佳的屏蔽效果。他們的設備永遠領先于我們的實際需求，因此將繁重的過濾工作交給他們可謂再合適不過。

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

第一道過濾體系應該斷開來自攻擊者的全部連接，因為它們正是這海量請求的根源。此規則應部署于我們訪問控制列表的最高優先級上。當然，我們的邊緣設備也不要再接受來自此類接口的數據流量，同時也不要回饋數據包。因為一旦發出回應，攻擊者們會迅速將其鎖定為額外的攻擊目標。

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

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

此外，大家還可以調整主機及邊緣設備，以使其較平時更快終止空閑會話進程進而保持足夠的剩余資源。但要小心調整的幅度不能過大——因為這樣一來我們可能反而要在建立及關閉連接方面消耗更多的資源。

源屏蔽及速率限制工作完成之后，我們算是已經在減輕攻擊活動帶來的負面影響方面取得了階段性進展。如果此時攻擊仍沒有停止的跡象（且似乎沒完沒了），技術團隊應該立刻將工作重點放在保護那些尚未被觸及的業務之上。

通常情況下，攻擊者們會將目標設定為特定的主機、應用程序或是網絡。將指向這類資源的流量通過路由引導至其它位置——或是干脆放棄此類流量——確實能夠為后端系統減輕負荷，但這同時意味著我們的服務項目也無法正常工作了，這正是攻擊者們希望看到的結果。

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

如果大家通過互聯網提供服務項目，那么各位實際上都是DDoS攻擊的潛在目標。而這種攻擊實際到來的可能性，取決于我們各自的經營方式、攻擊者的突發奇想以及那些對我們的企業感到不滿的人群。盡管無法完全避免，但我們仍有不少措施削弱攻擊影響：提高業務能力、部署冗余站點、隔離服務項目以及在攻擊來臨之前做好充分的應對計劃。

原文鏈接：

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獨家譯稿，非經授權謝絕轉載！合作媒體轉載請注明原文出處及出處！】