一条 SQL 注入引出的惊天大案（二）：无限战争

此刻，帝国高层正在召开紧急会议。

防火墙：“ 现在有无数的网络连接进来，为了帝国的安全，我只好先关闭了网络，把那些数据包挡在外面。”

小马哥：“ 需要赶紧采取措施，恢复正常，我们nginx公司每秒钟都在丢失大量的客户，这是一笔巨额损失！”

帝国安全部长：“小Q，你把当前的形势介绍一下，大家一起来出谋划策。”

小Q：“好的。TCP的三次握手想必诸位都有所了解， 收到SYN数据包后，我需要准备一个数据块来存储客户端的信息，敌军正是瞄准了这一点，给我发送 大 量 SYN数据包，我就需要分配大量的数据块，直到把帝国空间耗尽 。”

小马哥： “抱歉，我打断一下，你为何不及时把无效的数据块释放掉，腾出空间呢？ ”

小Q：“当然有，我有一套超时机制，超时以后第三次握手还没来，我就会给释放掉。但现在问题是敌军声势浩大，刚刚腾出的空间马上又会被挤占。”

小马哥：“那简单，你把超时时间调小一点，尽快释放无效的数据块不就行了！”

小Q：“要是太小了，正常的用户因为网络原因，时延比较大的，这不就误伤了吗？”

小马哥：“嗯，这个你们自己权衡一下，取一个合适的值，如今也没有其他办法，赶紧恢复生产才是！”

安全部长：“小Q，先这样试试看”

小Q：“行吧，我这就去”

半小时后 ······

小Q：“大人，我已经按照指示执行，不过网络连接越来越多，这一招恐怕支撑不了太久，还是早做打算才是。”

安全部长：“ WAF公司呢，你们有什么办法没有？”

WAF公司黑衣人：“大人，我们关注的业务在于web应用安全，此次的 SYN Flood ，实非我等擅长。”

现场陷入了久久的沉默 ……

良久，防火墙打破了沉默：“小Q， 为何非得在收到第一次握手SYN数据包后就建立数据块？如果把数据块的建立时间放在第三次握手之后呢？ ”

小Q：“如果一开始不用建立数据块占用空间，那确实解决了大麻烦！不过，不建立数据块，那如何把客户端的信息保存起来呢？”

防火墙：“保存什么信息？”

小Q：“客户端的IP、端口、序列号这些啊。”

防火墙：“这些信息在第三次握手来的数据包中也有啊，不用提前存起来嘛！”

小Q：“说的也是，唉，还是不对，第三次握手我得校验对方发来的ACK是不是我在第二次发给他的序列号＋1，如果我提前不分配数据块把我发给他的序列号存起来，到时候就没办法校验了呀！不行，还是得提前存下来！”

防火墙：“有没有什么办法，不用提前存，也能做校验呢？”

小Q：“这，这怎么做？”

防火墙：“有了！ 第二次发给客户端的序列号，如果不是一个随机值，而是根据客户端信息和其他信息综合计算出来的一个哈希值，收到第三次握手的时候，我们拿到客户端答复的ACK，再重新计算一次哈希值，如果哈希值＋1＝ACK，那就能对得上，反之就是错误的包，直接丢弃！ ”

还没等小Q回过神，安全部长起身鼓掌： “妙哉！ 这真是一个绝妙的点子！ 小Q，就按这个办法，赶紧去办！ ”