作者：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日志系统集群搭建教程的一个系列博文，还都没开始动笔写，不确定该写哪一篇。