Erlang版TCP服务器对抗攻击解决方案
原创文章，转载请注明： 转载自系统技术非业余研究
本文链接地址: Erlang版TCP服务器对抗攻击解决方案
互联网上的TCP服务器面对的环境情况比企业私有的服务器要复杂很多。常见的针对tcp服务器的攻击有以下几种：
1. 伪造协议，导致服务器crash. 比如说某条命令的字段长度，协议最大规定是1024，伪造个4096的。
2. 伪造大的报文，比如说一个包有1024M这么大。
3. 消耗服务器资源。开大量的连接， 以龟速发送报文，比如说每分钟一个字节。
4. DDOS攻击，从不同的IP发起大量的连接, 大流量淹没服务器。
5. 攻击Erlang集群的授权体系，all or nothing。
6. 报文发送顺序逻辑错误，导致服务器crash. 比如说逻辑上应该先发A，再发B, 攻击者调了顺序。
7. 不停的连接断开，消耗服务器对资源的申请和释放，这个通常很耗。
8. 篡改协议中关键时间事件，造成时间混乱。
9. 利用协议中需要大量计算和资源的事件攻击。
10. 利用协议的安全漏洞或者实现系统的漏洞，比如说erlang的atom个数的限制，对系统造成威胁。
11. Hash Collision DoS 等攻击。
12. term_to_binary数据深度太大，底层VM实现用的是c的递归，很容易导致stack overflow。
13. Mnesia数据库各role对等, 很容易在其中一个节点发起数据破坏操作。
14. 大量的请求涌入，导致大量消息产生，消息队列爆了。
15. 利用inets底层实现的漏洞，构造些畸形数据导致inet drv工作异常。
16. 攻击系统的RPC通道，节点间的RPC通道只有一条容易饱和。
17. 攻击系统的NIF实现漏洞，导致VM crash。
等等，有很多方法。
那我们的Erlang版的TCP服务器如何应对这些情况呢？
刚才不小心按了发布，待续。。。
Post Footer automatically generated by wp-posturl plugin for wordpress.
tcp 伪造大报文是怎么做到的？
Yu Feng Reply:
November 3rd, 2011 at 5:10 pm
每个报文不是都有个比如说2个字节的报文长度，后面跟着报文内容。 我就随便说报文长度多少多少。。。
luqi Reply:
November 3rd, 2011 at 7:25 pm
那路由器就先挡掉了吧
test Reply:
November 3rd, 2011 at 8:04 pm
这里说的应用层的 message length吧，这个还好处理，因为官方客户端的长度肯定是正确的，所以要做的工作就是把账号，ip,记录下来，交给别的模块处理或者人工处理，然后果断地断开连接。 message也可能被伪造，不过用 google protocol buffers的话，处理会比较方便，parse返回 false.
Yu Feng Reply:
November 3rd, 2011 at 8:12 pm
恩，细节多
Yu Feng Reply:
November 3rd, 2011 at 10:20 pm
怎么挡，路由器知道7层的东西？
luqi Reply:
November 3rd, 2011 at 10:31 pm
哦，我一开始理解错了，我以为你是说伪造tcp报文。
如果是应用层的话，确实没办法，这个只能通过应用自己去控制了。
哇塞，期待，这些经验应该是普遍适用的。
Yu Feng Reply:
November 3rd, 2011 at 5:48 pm
谢谢关注！
怎么没啦
还有期待中… …
1.可以只对自己感兴趣的协议进行处理吧，不感兴趣的协议的包直接丢掉。
2.”每个报文不是都有个比如说2个字节的报文长度，后面跟着报文内容。 我就随便说报文长度多少多少。。。“ 可以根据整个包实际长度减去报文头部的长度再和填充的长度对比吧。如果是实际上发1024M的报文，那么发送者也同样要消耗资源吧。
3.”龟速“可以通过定制状态机各个状态的超时时间来解决吧。
4.若是完整的三次握手，如僵尸网络，只能硬扛吧。众核cpu如tilera的包处理性能还是ok的。若是syn flood的，可以通过syn cookie缓和下。
5.暂不了解Erlang啊，呵呵。看博主的blog后，很有兴趣。
6.”报文发送顺序逻辑错误“ 若是按照状态机来实现的话，从特定的状态下在特定的事件的触发下才能进入下一状态的话，即使是发包的逻辑打乱了，也能正常处理。异常的包直接丢弃吧。
7.“不停地连接断开“，连接发起方也要耗资源吧，session复用或许能缓和一下。
8. 期待博主分享更多的关于可能的服务器的攻击
1.可以只对自己感兴趣的协议进行处理吧，不感兴趣的协议的包直接丢掉。
2.”每个报文不是都有个比如说2个字节的报文长度，后面跟着报文内容。 我就随便说报文长度多少多少。。。“ 可以根据整个包实际长度减去报文头部的长度再和填充的长度对比吧。如果是实际上发1024M的报文，那么发送者也同样要消耗资源吧。
3.”龟速“可以通过定制状态机各个状态的超时时间来解决吧。
4.若是完整的三次握手，如僵尸网络，只能硬扛吧。众核cpu如tilera的包处理性能还是ok的。若是syn flood的，可以通过syn cookie缓和下。
5.暂不了解Erlang啊，呵呵。看博主的blog后，很有兴趣。
6.”报文发送顺序逻辑错误“ 若是按照状态机来实现的话，从特定的状态下在特定的事件的触发下才能进入下一状态的话，即使是发包的逻辑打乱了，也能正常处理。异常的包直接丢弃吧。
7.“不停地连接断开“，连接发起方也要耗资源吧，session复用或许能缓和一下。
8. 期待博主分享更多的可能的服务器的攻击。
Yu Feng Reply:
December 9th, 2011 at 2:05 pm
您这总结太好了，我也差不多是这样的，只不过按照erlang的方式来处理
好像可以修改为草稿呀
5. 攻击Erlang集群的授权体系，all or nothing。
这种攻击方式不太了解哦，可以详细一点吗？
Yu Feng Reply:
April 7th, 2013 at 4:44 pm
erlang的授权体系是基于cookie的all or nothing, 而且是集群全联通的。比如可以和epmd直接通信，搞掉节点名称和节点的对应关系。
Bryan Reply:
April 7th, 2013 at 5:27 pm
这个得知道服务器是erlang写的，且对erlang的授权那套比较熟悉才有可能攻击。而且通过TCP和直接和服务器的epmd联系很有难度吧？有木有攻击例子，来一个瞧瞧~~
怎样防御这些攻击呢？
霸爷，可以把具体的解决办法发给我下嘛？非常感谢
这是只说其一不说其二啊，下回分解木有~\(≧▽≦)/~啦啦啦
好多是逻辑方面应对的攻击，路由上能做的就做，但好多恐怕是难防住的，想知道是怎么防的。。。