SYNPROXY抵御DDoS攻击的原理和优化

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.youkuaiyun.com/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

                       

序

又到了周末，我又要必须写点什么了…

  周末依然加班，感谢周末上班平日休息的老婆分担了几乎所有家务，一切依然…然而这些对我来讲都不是个事儿，事实上我是希望取消一切节假日和周末的，所谓的周末和节假日是我一直以来觉得出自《圣经》里面最荒唐的东西…休息时间为什么要集中化，既然有个集中化的休息时间，那么必有人会充分利用这段时间，说实话，根本就没有人把周末和假期用来休息，相反，很多时候在这些所谓的休息时间是比上班还要累的！难道每天工作4小时，然后365天每天都在工作不好吗？

  当为安息日守为圣日，《十诫》之第四：
Remember the Sabbath day,to keep it holy.
Six days you shall labor,and do all your work; but the seventh day is a Sabbath to The Lord your God; in it you shall not do any work,you,or your son,or your daughter,your manservant,or your maidservant,or your cattle,or the sojourner who is within your gates; for in six days The Lord made heaven and earth,the sea,and all that is in them,and rested the seventh day; therefore The Lord blessed the Sabbath day and hallowed it

只可惜远东很少真正信基督的，更别说犹太教徒了，这让我在引述时显得有点轻松的尴尬，既然知道在中国没有圣日，便无所谓安息日了，所以我一直以来都希望，取消所有周末和节假日，这是我16年来的梦想！

  我会专门写一篇《IT行业的12小时工作制》结合世界历史来联系所谓安息日和圣日，但在本文，我想谈点技术，关于DDoS攻击和nf_conntrack的技术。我的每周一报都会带有强烈的感情色彩，所以在本文中，我依旧是在为Netfilter/nf_conntrack而平反，但我并不嘲笑无知，因为技术无褒贬。

---

关于DDoS攻击和本文

DDoS攻击很多人都不会陌生，很多人都会花费很大的精力去对付它，然而却找不到根治的办法，DDoS攻击比那些病毒，木马什么的更难以根治！DDoS攻击特别像我们日常的感冒，不致命，但却非常之讨厌。你会花多少钱去应对一次普通的感冒呢？事实上，你甚至根本不需要花一分钱，感冒症状也会随着时间自然消失，但是如果你想让它快速离你而远去，你就势必要花点钱了。现如今，天花，霍乱，鼠疫这类致命传染病都有了根治的特效药，根治癌症，艾滋病也只是个时间问题，然而感冒却没有根治的办法，也不会有！从某种意义上讲，感冒不能算是病，它只是一种正常的生理反应，同时它还能检测你的免疫系统的健康程度呢。同样的道理，DDoS攻击也可以检验你的服务器的抗打能力。

  市面上经常见到的针对DDoS的防护手段非常多，你可以花几万甚至几十万去买专用的DDoS清洗设备，也可以不花一分钱任攻击者在暗爽后达到目的或者感到无聊时停止攻击。本文介绍一种中间手段，即一种廉价的DDoS防护机制，你不用花钱，当然也不是要你被动等待，你需要花点精力来熟悉一些技术，然后利用这些技术来主动做一些事情，事实证明，本文介绍的DDoS防护技术的效果非常好。

  本文大致分三个部分，第一部分主要介绍nf_conntrack的相关细节，第二部分主要介绍已经存在的SYNPROXY技术，这部分我主要是阐述原理以及在适当的时候讲一些故事，第三部分是我自己的一个设计和实现，旨在针对我觉得SYNPROXY不爽的地方做一些优化，这部分我当然是以见招拆招的方式进行，毕竟，先要找到问题，然后再去优化，不能为了优化而优化。

---

关于DDoS与nf_conntrack

人人都知道，DDoS防护是性能攸关的，它的目标在于提高在受到海量数据包倾泻式侵袭时的协议栈处理能力，同时，也是几乎人人都知道的是，Netfilter/nf_conntrack会影响协议栈的处理性能，DDoS防护万万不可以使用Netfilter的nf_conntrack机制，因为二者是不相容且相对的。我不知道这样认为的人出于什么心态，但可以肯定的是，这些人大部分都是在道听途说！我们从nf_conntrack的操作入手，看看到底怎么回事。

  nf_conntrack的操作是非常典型的，大体上分为了创建，删除，查询，更新这么几类，它们在整个协议栈以及Netfilter框架中的位置如下图所示：

如图可见，我们可以得出以下的结论:

 

•  
• nf_conntrack使用了全局链表(其实是两张表，一张正向元组表，一张反向元组表)
•  
• nf_conntrack的表项查询是非常高效的，因为它仅采用了Netfilter的RCU锁以及自身引用计数的保护
•  
• nf_conntrack的表项插入，删除是串行化的，因为全局链表只能采用自旋锁保护
•  

这意味着，Netfilter的入口位置，即PREROUTING，OUTPUT两个位置的查询和离线创建操作是十分高效的，而nf_conntrack的性能损耗主要就是在表项的插入和删除，即Netfilter的出口INPUT，POSTROUTING两个位置，这个位置上的插入操作才是罪魁祸首，整个nf_conntrack甚至Netfilter是为这种局部操作背锅的。
  我们接下来再来看看nf_conntrack表项的插入和删除与DDoS攻击的关系，就明白为什么大多数人这么抵触使用nf_conntrack来进行DDoS防护了(其实他们不是抵触用nf_conntrack进行DDoS防护，而是根本就是抵触Netfilter本身)。

  nf_conntrack机制就是为每一个