浅析SYN FloodCC GJ与解决办法 _解决

知识就是力量，时间就是生命。这篇文章主要讲述浅析SYN FloodCC GJ与解决办法相关的知识，希望能为你提供帮助。
对服务器的 GJ一般有带宽 GJ、计算资源 GJ和服务 GJ三大类。
带宽 GJ就是耗尽你的网络带宽，直至服务不可用，常见的带宽 GJ例如服务器植入发包程序，不断对外发包，导致服务器网络带宽耗尽，而这些服务器一般是作为肉鸡存在的，所谓肉鸡，就是为 GJ其他服务器的代理机器。
计算资源 GJ主要是针对各种挖矿BD，这些植入的挖矿程序，主要目的是使用你的计算资源给自己挖矿。这是新出现的一种 GJ行为，跟这几年Bitcoin炒得火热有关。
最后是服务 GJ，这其实才是所有 GJ的最终目的，HK通过控制各种肉鸡，然后对某些互联网上的服务（主要是web服务）发动 GJ，这就是常说的DDoS GJ。
下面分别介绍下各种 GJ的现象和手段以及防御策略。
1、如何处理被肉鸡的系统肉鸡就是被HK GJ和RQ的服务器，HK在服务器上放入了BD和MUMA之类的后门程序，并设置管理权限远程控制我们的服务器。控制我们服务器的目的是为了对第三方系统发起更大的 GJ，因为单台服务器无法造成大规模的网络 GJ，而HK手里握有大量肉鸡的时候，就可以对指定系统或服务发起 GJ，这种威力是很大的。
被植入的肉鸡系统，大部分是通过LD（程序、系统LD）植入的，因此，处理要从程序和系统两个方面进行，处理建议如下：
（1）、从系统级检查
?经常检查系统内用户情况，是否发现有可疑账号，检查管理员组里是否增加了未知账号。
?检查自己网站目录权限，尽量减少无关用户的权限。
?定期更新系统软件版本，比如openssh、glibc等。
?建议关闭不需要的服务。
?建议关闭一些高危端口，比如22、8080、8000等等。
（2）、从程序上检查问题
?定期检查网站下有无可疑的可执行文件。
?避免使用无组件上传和第三方控件，如果使用第三方控件最好注意更新。
?定期备份自己的数据库和网站程序。
（3）、如何彻底清除BD
系统感染MUMABD或者被HKRQ，系统文件损坏，通过常规方式无法修复，严重影响使用的。建议通过重新安装系统，然后部署程序方式来解决，这是最彻底的一种方式。但前提是有完整的数据备份，如果没有备份数据，这种方式就会丢失数据。需要综合考虑。
另外一种方式是尽量在原系统上清除MUMA程序和可疑进程，为防止BD文件没有彻底清除，可通过添加监控或者定期观察系统运行状态来判断系统是否存在异常，经过一段时间的监控，如无异常，基本可以判断，系统BD已经彻底清除了。
2、DDoSGJ与防护DDoS是“分布式拒绝服务”，那么什么又是拒绝服务（Denial of Service）呢？可以这么理解，凡是能导致合法用户不能够访问正常网络服务的行为都算是拒绝服务 GJ。也就是说拒绝服务 GJ的目的非常明确，就是要阻止合法用户对正常网络资源的访问，从而达成 GJ者不可告人的目的。
DDoS GJ是个统称，常见的SYN类 GJ、CC类 GJ、udp GJ、tcp洪水 GJ等都属于DDoS GJ。下面主要介绍下常见的SYN类 GJ、CC类 GJ的原理以及防御策略。
（1）、SYN GJ原理与防御措施
SYN Flood是互联网上最经典的DDoS GJ方式之一。它利用了TCP三次握手的缺陷，能够以较小代价使目标服务器无法响应，且难以追查。
先看看标准的TCP三次握手过程：
1）、客户端发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号。
2）、服务器在收到客户端的SYN报文后，将返回一个SYN+ACK报文，表示客户端的请求被接受，同时TCP初始序号自动加1。
3）、客户端也返回一个确认报文ACK给到服务器端，同样TCP序列号被加1。
经过这三步，TCP连接就建立完成。TCP协议为了实现可靠传输，在三次握手的过程中设置了一些异常处理机制。第三步中如果服务器没有收到客户端的最终ACK确认报文，会一直处于SYN_RECV状态，将客户端IP加入等待列表，并重发第二步的SYN+ACK报文。重发一般进行3-5次，大约间隔30秒左右轮询一次，等待列表会重试所有客户端。
另一方面，服务器在自己发出了SYN+ACK报文后，会预分配资源为即将建立的TCP连接储存信息做准备，这个资源在等待重试期间一直保留。更为重要的是，服务器资源有限，可以维护的SYN_RECV状态超过极限后就不能再接受新的SYN报文，也就是会拒绝新的TCP连接建立。
基于上面的原理，SYN Flood正是利用了上文中TCP协议的规则，达到 GJ的目的。 GJ者会伪装大量的IP地址给服务器发送SYN报文，由于伪造的IP地址几乎不可能存在，也就几乎没有设备会给服务器返回任何应答了。因此，服务器将会维持一个庞大的等待列表，不停地重试发送SYN+ACK报文，同时占用着大量的资源无法释放。更为关键的是，被 GJ服务器的SYN_RECV队列被恶意的数据包占满，不再接受新的SYN请求，合法用户无法完成三次握手建立起TCP连接。也就是说，这个服务器被SYN Flood拒绝服务了。
这就是SYN类 GJ，此类 GJ会大量耗费服务器的CPU和内存资源，使其网站运行缓慢，严重者引起网络堵塞甚至系统瘫痪。SYN GJ实现起来非常的简单，不管目标是什么系统，只要这些系统打开TCP服务就可以实施。SYN GJ除了能影响主机外，还可以危害路由器、防火墙等网络系统。
【浅析SYN FloodCC GJ与解决办法】那么如何对SYN Flood GJ做防护呢，方法也是有的，根据上面对SYN Flood GJ的特点，我们只需修改操作系统内核参数即可有效缓解。主要参数如下：

net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 81920 net.ipv4.tcp_synack_retries = 2

三个参数的含义分别为启用SYN Cookie、设置SYN最大队列长度以及设置SYN+ACK最大重试次数。

SYN Cookie的作用是缓解服务器资源压力。启用之前，服务器在接到SYN数据包后，会立即分配存储空间，并随机化一个数字作为SYN号发送SYN+ACK数据包。然后保存连接的状态信息等待客户端确认。而在启用SYN Cookie之后，服务器不再马上分配存储空间，而且通过基于时间种子的随机数算法设置一个SYN号，替代完全随机的SYN号。发送完SYN+ACK确认报文之后，清空资源不保存任何状态信息。直到服务器接到客户端的最终ACK包。同时，通过Cookie检验算法鉴定是否与发出去的SYN+ACK报文序列号匹配，匹配则通过完成握手，失败则丢弃。
tcp_max_syn_backlog则是使用服务器的内存资源，换取更大的等待队列长度，让 GJ数据包不至于占满所有连接而导致正常用户无法完成握手。
net.ipv4.tcp_synack_retries是降低服务器SYN+ACK报文重试次数（默认是5次），尽快释放等待资源。
这三种措施与 GJ的三种危害一一对应，完完全全是对症下药。但这些措施也是双刃剑，设置过大可能消耗服务器更多的内存资源，甚至影响正常用户建立TCP连接，因此，需要评估服务器硬件资源和 GJ大小谨慎设置。

（2）、CC类 GJ
CC GJ的本名叫做HTTP FLOOD，是一种专门针对于Web的应用层FLOOD GJ， GJ者操纵网络上的肉鸡，对目标Web服务器进行海量http request请求，直到服务器带宽被打满，造成了拒绝服务。
CC GJ在HTTP层发起，它极力模仿正常用户的网页请求行为，与网站业务紧密相关，安全厂商很难提供一套通用的且不影响用户体验的方案。同时， GJ还会引起严重的连锁反应，不仅仅是直接影响被 GJ的Web前端响应缓慢，还间接影响到后端的java等业务层逻辑以及更后端的数据库服务，增大它们的压力，甚至对数据存储服务器都带来影响。
CC是目前应用层 GJ的主要手段之一，它的巨大危害性主要表现在三个方面：发起方便、过滤困难、影响深远。目前在防御上有一些方法，但都不能完美解决这个问题。
对于CC类 GJ的防御，目前主要通过缓存的方式进行，也就是尽量让缓存数据直接返回结果来保护后端业务。大型的互联网企业，会有庞大的CDN节点缓存内容。而当高级 GJ者穿透缓存时，会通过清洗设备截获HTTP请求做特殊处理。最简单的方法就是对源IP的HTTP请求频率做统计，高于一定频率的IP地址直接加入黑名单。很明显，这种方法过于简单，容易带来误杀，并且无法屏蔽来自代理服务器的 GJ，因此逐渐废止，取而代之的是javascript跳转人机识别方案。
HTTP Flood是由程序模拟的HTTP请求，一般来说不会解析服务端返回数据，更不会解析JS之类代码。因此当清洗设备截获到HTTP请求时，会返回一段特殊JavaScript代码，正常用户的浏览器会自动识别并正常跳转不影响使用，而 GJ程序则不能识别进而 GJ到空处。大家如果经常使用谷歌的话，会看到这样的防范策略。
那么我们要如何知道自己是否被cc GJ了呢？给出一些常用的命令，供大家参考使用：
1）查看所有80端口的连接数

netstat -nat|grep -i "80"|wc -l

2）对连接的IP按连接数量进行排序

netstat -ntu | awk print $5 | cut -d： -f1 | sort | uniq -c | sort -n

3）查看TCP连接状态

netstat -n | awk /^tcp/ ++S [$NF] ; END for (a in S) print a,S [a] netstat -ant | awk print $NF | grep -v [a-z] | sort | uniq -c

4）查看80端口连接数最多的20个IP

netstat -anlp|grep 80|grep tcp|awk print $5|awk -F: print $1|sort|uniq -c|sort -nr|head -n20 netstat -ant |awk /: 80/split ($5, ip, ":"); ++A [ip [1] ]ENDfor (i in A) print A,i | sort -rn|head -n 20

5）、用tcpdump嗅探80端口的访问看看谁最高