被DDOS了怎么办，浅谈Liunx防御DDOS攻击

0x001 起因
这几天遇到了疑似DDos恶意攻击，后来一查，原来是虚惊一场，可能是有人使用作弊手段刷广告，导致流量暴增，吓到机房的人尿了，马上黑洞了被攻击的服务器，导致业务中断，这么一搞，吓到我也差点尿了，机器进不去，我也没法判断到底是什么类型的攻击。后来换了服务器经过抓包，监控等一系列排查，发现不是恶意攻击。把过程记录下来，在nigesb.com共享给大家.

0x002 诊断
遇到怀疑攻击情况，首先要看看服务器上面的情况，首先top一下，看看服务器负载，如果负载不高，那么基本可以判断不是cc类型的攻击，再输入命令

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

查看下网络连接的情况，会得到下面这些结果：

TCP/IP协议使用三次握手来建立连接，过程如下：
1、第一次握手，客户端发送数据包syn到服务器，并进入SYN_SEND状态，等待回复
2、第二次握手，服务器发送数据报syn/ack，给客户机，并进入SYN_RECV状态，等待回复
3、第三次握手，客户端发送数据包ACK给客户机，发送完成后，客户端和服务器进入ESTABLISHED状态，链接建立完成

如果ESTABLISHED非常地高，那么可能是有人在恶意攻击，进一步判断，可以把下面命令保存为脚本执行一下：

for i in `netstat -an | grep -i ':80 '|grep 'EST' | awk '{print $5}' | cut -d : -f 1 | sort | uniq -c | awk '{if($1 > 50) {print $2}}'`
do
        echo $i
        echo $i >> /tmp/evilip
done

如果输出了多个结果，那么可能表示有人在企图进行DDOS攻击，想用TCP连接来拖死你的服务器，输出的ip就是发出请求的服务器地址，并且保存在了/tmp/evilip里面。如果没有结果，可以调整一下阈值，把50改成40试一试，对策我们后面再说，这里只讲判断。

如果SYN_RECV非常高，那么表示受到了SYN洪水攻击。

如果上面的值看不出什么异常的话，我们来抓包分析下，可能并非基于TCP的攻击。抓包命令：

tcpdump -w tmp.pcap port not 22

抓包感觉差不多了就ctrl+c结束，结果在保存在当前目录下的tmp.pcap文件中，我们可以使用命令

tcpdump -r tmp.pcap -nnA

来查看，也可以拖回本地用wireshark打开分析等，个人喜好了。如果出现大量的ICMP包或者大量的UDP包，那么可能就是针对性的ICMP洪水以及UDP洪水了。

0x003 TCP连接攻击
TCP连接攻击算是比较古老的了，防御起来也相对比较简单，主要是利用大量的TCP连接来消耗系统的网络资源，通常同一个IP会建立数量比较大的TCP连接，并且一直保持。应对方法也比较简单，可以将以下命令保存为脚本，定时ban掉那些傀儡机ip

for i in `netstat -an | grep -i ':80 '|grep 'EST' | awk '{print $5}' | cut -d : -f 1 | sort | uniq -c | awk '{if($1 > 50) {print $2}}'`
do
        echo $i
        echo $i >> /tmp/banip
        /sbin/iptables -A INPUT -p tcp -j DROP -s $i
done

banip文件里面记录了所有被ban的ip地址信息，方面进行反渗透以及证据保存等等。为了更好地加固系统，我们可以使用iptables来限制一下，单个ip的最大连接数。

iptables -t filter -A INPUT -p tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 10 --connlimit-mask 32 -j REJECT

限制每个ip的连接数为10。如果是大些业务系统的话，需要注意，上面的做法可能导致一些共用IP的用户访问中断。需要谨慎。

0x004 SYN洪水攻击
SYN洪水是利用TCP/IP协议的设计缺陷来进行攻击的，采用一些策略以及配置可以适当的降低攻击的影响，但并不能完全消除。

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_syn_retries = 0
sysctl -w net.ipv4.tcp_max_syn_backlog=2048

tcp_syncookies设置为1表示启用syncookie，可以大大降低SYN攻击的影响，但是会带来新的安全缺陷，顺便科普一下snycookie吧。

syncookie基本原理是：仔细处理连接的初始序列号而不是随机选择一个序列号。一旦server接收到SYN报文，将关键信息仔细编码并作为 state存储在SYN队列中。这种经过编码的信息是用一个秘钥进行加密hash，形成SYN-ACK报文中的序列号并发送给client。在合法握手的 第三个报文中，即从client返回给server的ACK报文中，在acknowledgment number字段中包含该序列号(加1). 这样，open双向连接所必须的所有信息又返回给server，而server在三次握手完成之前不必维护state。syn-cookies解决了 SYN的基本问题，但是随之带来一个新的问题，就是服务器需要对收到的ACK报文进行计算，提高了三次握手需要的系统资源。一种新的攻击方式随之而来，即 ACK攻击，发送大量的ACK数据报，导致服务器忙于计算最终导致服务器停止相应。Linux上的实际应用中，只有等待数被占满的时候才会启用 syncookies的方式

tcp_syn_retries 表示syn重试次数，重传次数设置为0，只要收不到客户端的响应，立即丢弃该连接，默认设置为5次。

tcp_max_syn_backlog表示syn等待队列，改小这个值，使得SYN等待队列变短，减少对系统以及网络资源的占用。

上面的那个iptable的连接数限制在这里仍然有用的，也可以加上

0x005 ICMP或UDP洪水
提到ICMP洪水，我就想到了之前好像在网络大战的时候，有很多人在QQ群里面传信息呀，大意就是大家一起来ping白宫，而且开多个窗口等等，很囧。这两种协议，如果在系统中没用到的话，最方便的是完全可以联系机房让他们直接在设备上进行封禁，或者尝试使用iptables进行完全封禁。具体的命令要根据不同的类型来进行，也比较简单，因此就不多讲了。

如果这些方法限制都不太有用的话，说明对方的资源可能非常地多，良心大大地坏，考虑采用多机负载或者硬防的方式应对了。