本期回顾，我们只聊一个事情——UDP反射攻击。这个事情在上周被Akamai/Prolexic炒了一把，说黑客盯上SNMP协议了，用来发起UDP反射攻击。借此扯点闲篇，还是蛮有意思的。
SNMP及其UDP反射放大的兄弟们
UDP Flood应该是一种比较讨厌的DDoS攻击，现在来说，比较可行的防护手段不是太多，恐怕限流是最常见的防护方式了。UDP Flood比较难以防护的主要原因是UDP自身的通信方式决定的，不维持状态使得类似cooikie、验证码等反向探测手段难以实施。
去年曾经发生过300G DDoS的攻击事件。当时被打的目标是Spamhaus，而提供防护的CloudFlare也一起“屁滚尿流”，最终在全球多个Tier-1一级运营商的一起努力下才最终化解。打出300G DDoS的就是依靠DNS反射放大攻击，基于UDP。经过DNS解析服务器放大后，反射出来的数据包被放大了很多倍。据称，当时的300G流量是由近31000台DNS服务器打出来的。下图是发起300G DDoS攻击的最大嫌疑犯CyberBunker公司的老板，他后来被捕入狱。
其实Just so so了，和最近一起据称近400G的DDoS攻击相比，差远了。400G的DDoS是通过NTP服务器进行的反射放大。没错，也是基于UDP的Flood，也是经过反射放大，最终达到近400G的天量。和31000台DNS服务器相比，推到400G的攻击流量只用到了约4500台NTP服务器。
4500台NTP服务器 =400G UDP Flood是什么概念? 我们计算一下，一个NTP request经过MONLIST放大后，差不多反射出来的流量是request数据包的206倍。也就是说，1G的NTP request就可以反射200G的攻击流量。显然比DNS效率高多了。
下图是参与400G攻击的NTP服务器所在运营商的列表：
注：上图笔者给一些运营商打了码，为什么打码，自己去猜。
在上周，Akamai/Prolexic又开始炒SNMP Flood。哦，yes，SNMP为什么不可能呢?都是UDP Flood的兄弟嘛。让人稍感欣慰的是，SNMP Flood不象DNS和NTP反射威胁那么严重，还好还好。
下图是国外某厂商捕获的SNMP实际攻击数据。
上图是某系统遭到真实SNMP Flood攻击的实际数据。为了安全，实际的IP地址以192.0.2.1来替代。
我们可以看出，117.27.239.158是倒霉蛋，也就是被反的对象。如果getBulkRequest的数据包以87字节来计算，设备反射的SNMP response约为60kB，放大了多少大家自己可以计算一下。
众所周知，getBulkRequest是SNMP v2版本新增的。因此，普遍认为SNMP 反射放大攻击是基于SNMP v2的。SNMP v2存在某些安全隐患，这也是推出SNMP v3的一个重要原因。
我们翻回头再来说上面那个“某系统”是什么系统。这个系统是IOT系统，也就是物联网系统。具体来说，是一个视频会议系统。该会议系统是开放的(widely open)。资料没有查到，个人猜测，可能是这个系统没有对SNMP访问的IP进行限制，才导致被利用发起发射的结果。
这是一个非常有趣的事情。一个物联网系统被别人利用发起DDoS攻击，更为有趣的是，这个被利用的物联网系统根本就没有必要开放SNMP服务。
俗话说，no zuo no die，放在这里再合适不过。当然，最终倒霉的是117.27.239.158。话说回来，IOT系统被利用打DDoS，肯定不是这个系统设计的初衷。资源浪费，弄不好还会被溯源投诉。
最后，送上一点福利：反射攻击的历史。下面的内容从网上采集，供大家参考，可能拿来给客户讲故事。但是是否准确，不能保证：
- SYN/ACK floods始于90年代中期。
- Smurf attack出现于90年底。之后随着路由器将“no ip unreachables”作为缺省配置而消失。
- DNS 反射/放大攻击始于2000或2001年，2004年底，2005年出开始流行。
- SNMP 反射/放大攻击在2006 - 2007出现。
- NTP反射/放大攻击在2008 - 2009出现。
- CHARGEN反射/放大攻击在2009 - 2010出现。同一时期，TFTP反射/放大攻击也浮出水面。
总是，都不是新鲜玩意儿。但是，防不住还是防不住。
