作者：13
GitHub：https://github.com/ZHENFENG13
版權聲明：本文為原創文章，未經允許不得轉載。
前言
[短信發送接口被惡意訪問的網絡攻擊事件(一)緊張的遭遇戰險勝](http://www.cnblogs.com/han-1034683568/p/6973269.html) [短信發送接口被惡意訪問的網絡攻擊事件(二)肉搏戰-阻止惡意請求](http://www.cnblogs.com/han-1034683568/p/7001785.html) [短信發送接口被惡意訪問的網絡攻擊事件(三)定位惡意IP的日志分析腳本](http://www.cnblogs.com/han-1034683568/p/7040417.html) 以上三篇文章詳細的介紹了事件的起因和經過，回顧了一下整個過程，其實就是技術人員不上心沒有做好安全驗證導致接口被無聊的黑客攻擊，然后一系列菜雞互啄的過程，要說戰，肯定是沒有的，只是這個過程比較好玩兒，因此花了一些時間記錄了一下這個事故的經過，至於說為什么這一篇叫清理戰場嘛，就是這四篇文章把該寫的都寫完了，這一篇作為最終的完結篇，也不知道該起什么名字了，因此最后一篇就做做清理、打掃的活兒了,寫寫自己的感受，總結一下經驗教訓，給這次事件畫上一個句號。
一點小感受
文章發布之后，由於是關於系統安全方面的問題，感覺在這件事情上大家很熱情，終於有種自己不是玩單機的感覺了，哈哈哈哈哈。文章里收到了大量的留言，也看到了很多的處理方案，有些建議確實很好，因此也就學習到了一些東西，當然也受到了一些批評，從這些批評中也知道了自己的不足，這種交流的氛圍挺讓我感慨的，自從寫博客以來，一直有一種孤獨感，而且有時候不知道寫博客是干嘛的，但是通過這幾篇博客與大家的交流，我覺得和大家有互動才是最棒的，長久的封閉會導致落后，也會產生些許的抵觸和迷茫的情緒。
整理了一些留言，由於量有些大，就不全部貼出來了，謝謝你們的建議。
星多天空亮,人多智慧廣
也可以到對應的博客留言中查看。
-
有人針對這次攻擊給了一些處理的建議，也提出了不少的方案。在做日志分析的時候，就根據一位朋友提出的建議，通過日志文件去分析了請求者的request，確實是有規律可循的，可以很簡單的就被識別，也聽取了一些處理經驗，在處理方式上沒有特別的死板。
-
當然也有人提出了質疑和批評，指出對於事件的處理方法不恰、一開始也沒做好安全驗證等等之類的話。批評的對，確實是我們自己的原因，沒有做好一個模塊驗證導致了這種問題。
-
也有很多留言的朋友說到他們也遭受過類似的攻擊，因此這次的遭遇處境和很多朋友都挺有共鳴的，和大家的交流中得到了很多的寶貴的經驗。
前面三篇文章中所說的黑名單和iptables防火牆方案，是第一天發現問題后所做的事情，但是最終並不是用的這個方法，這些只是當時的應急方案，因為我們自己也發現這個方案其實缺點很多而且不夠靈活，只能臨時起到一些作用，很多朋友也在留言中直接指出了方案的不足。
最終采用了另外一種方案--WAF。
WAF模式
最終的方案是添加了驗證碼機制，前端加圖片驗證碼，后端加驗證，同時在部署的centos服務器上架設了WAF(應用防火牆)用來做請求驗證及制定策略來防御攻擊，這個是運維小哥搭建的，攔截效果非常好，以后有機會再分享吧。
最終的攔截方式效果圖：
圖中可以直觀的看到最新的防御方式為：WAF+驗證碼，在搭建了WAF之后，不僅僅是此次的接口攻擊，對於其他類型的攻擊以及一些騷擾也都有很好的防御效果，不過搭建過程較復雜，配置也比較麻煩，但是有很好的攔截功能，因此很值得推薦也很解渴。
教訓一：接口安全
在這次攻擊事件之前，根本沒有想到過會發生類似的事情，也根本沒有一個清晰而嚴格的關於安全驗證的概念，因為以往覺得請求驗證就是類似登錄那種功能，或者https協議這些，網絡安全和接口安全方面的意識太薄弱了，以前雖然也遭遇過攻擊，但是針對於應用接口的攻擊是第一次碰到，也算是自己上了一節安全知識的課了。
在實際應用層方面，做好接口安全設計和落地，以往做的安全驗證過於簡單，有的甚至沒做，現在看來應用里還存在一些裸奔的接口，這些都需要盡快修改。這次事件雖然是發生在APP移動端，但是在WEB模塊中，如果不做好接口安全，肯定也會出現類似的情況，而且WEB端的代碼是可以被查看的，如果被盯上肯定更加危險。
安全問題，一定要注意，我以前還碰到過服務器被黑的情況，所以深知被攻擊的痛苦。
教訓二：及時應對
現在說這些都是后話了，總結了這么多，也是事后諸葛亮，事件發生當時能想到的以及所做的與現在的想法和方案確實差別較大，畢竟事件穩定后，有了更多的思路和方案，許多事情也都比原來更加深刻和清楚，而且攻擊事件既然已經發生，當時的情境下，首先想到的肯定不是總結事件，也不是找各種各樣的方案，而是找到一個能夠實現的方案盡快止損，應對方案應該是阻止攻擊以避免進一步的損失和危害。
過程中也出現過錯誤的判斷，以為是什么流量攻擊，其實只是小打小鬧，只是當時太緊張，發生了錯誤的判斷，自己嚇唬自己。
也根據一些朋友留言中的建議，做了一些修改，接口返回的字段並沒有直接返回錯誤碼和錯誤信息，而是返回的發送成功，因為擔心攻擊者修改腳本，因此這么做是為了迷惑攻擊者，避免他們發現工具無用后對請求做修改，使得分析變得困難。
總結
首發於我的個人博客，地址在這里
這次是一個偶然事件，我也沒有預料到會忽然發生，過程中也一直在做整理，然后把整理后的文章發布到網上大家一起討論，很多方案其實都是通過各位朋友的建議去修改的，比如最終的方案，采用的WAF+驗證碼也是留言中提到的較多的有效方法，問題解決了就好。
原本打算寫的博客，因為這次事件已經被丟到馬里亞納海溝里去完全記不起來原先的計划了，不過關於接口攻擊這個系列的博客到這一篇就算是完結了，感謝大家提出的意見以及提供的幫助。接下來要繼續更新原來計划的博客了，要么是更新SSM系列的進階篇，要么是關於ELK日志系統集群搭建教程的一個系列博文，還都沒開始動筆寫，不確定該寫哪一篇。