整个过程你来我往的，看似热闹，其实就是菜鸡互啄，攻击者通过工具发送恶意请求，恶意请求进来并被记录到日志文件中，被脚本检测到之后加入到iptables策略中封锁IP，然后攻击者又会利用新的IP做攻击，检测到之后再次封锁，周而复始。说难度嘛，倒是没什么技术难度，至于麻烦嘛，是有一些小麻烦，再说损失，通过参数验证后，应该不会请求短信服务商再造成损失了，关键是被恶心到了，毕竟这个事情没法彻底的解决掉，除非停掉这一个服务，这是不可能的，也只能等下次更新了，中间这段时间只能被恶心了。

防火墙的方案

虽然当时是选择使用iptables来作为主要的防火墙工具，但是现在想想，也有其他方法的，事后诸葛亮一下，总结了以下四种方式，希望大家补充：

结语

也想过在APP重新发版时，重新设计一套url，将原来的url废弃掉，或者关闭一些服务器以杜绝这些攻击，但是，这些都是冲动和极端的想法和做法，即使APP重新发版，也不可能立即关闭后端服务器，关闭后端服务意味着完全抛弃对上一个版本的支持，但是正确做法不可能对没有更新版本的用户不管不问，即使他们不更新也要保证原来的整体功能可用。不能因为一个服务的错误，让用户去承受错误，不能让用户来为我们埋单，停掉服务器的做法不可行，没有到那个地步，因此只能是自己去解决和维护。

每次发生这种意料之外的事件，都会提醒自己做好安全保障工作，不可掉以轻心，不要给心怀恶意之人有可乘之机，这次损失一块钱RMB，下次可能是一千块，一万块，金钱的损失可以衡量，如果是给系统带来影响或者给团队招来不必要的麻烦就真的百口莫辩了。

目前来看，虽然是解决了一部分问题，用请求验证阻止发送短信，用iptables阻止恶意IP的访问，但是并没有根本解除掉攻击，不排除攻击者会进一步攻击的可能性，因此只能被动的防守，同时也做好web和服务器的安全防护。

posted @