2016年5月，不法黑客针对全球范围内的多家银行网站发动了一系列的DDoS攻击。导致约旦、韩国以及摩纳哥等央行网络系统陷入了半小时的瘫痪状态，无法进行正常工作。

2016年11月，俄罗斯五家主流银行遭遇长达两天的DDoS攻击。来自30个国家2.4万台计算机构成的僵尸网络持续不断发动强大的DDOS攻击。

2017年4月初，江苏省某网络公司服务器频繁遭到DDoS流量攻击，导致挂载在服务器上的多个网站无法正常运营，损失严重。

2018年3月，Github遭受了迄今为止记录的最大的DDoS攻击。攻击者通过公共互联网发送小字节的基于UDP的数据包请求到配置错误的memcached服务器，作为回应，memcached服务器通过向Github发送大量不成比例的响应，形成巨大规模的DDoS攻击。

2019年9月初，北京市公安局网络安全保卫总队（以下简称“网安总队”）发起了针对“分布式拒绝服务攻击”类违法犯罪的全国性专项打击行动。三个月内，网安总队在全国范围内共抓获违法犯罪嫌疑人379名，清理在京被控主机7268台。

……

什么是DDOS攻击？

举个例子，我开了一家饭店，这家饭店可以容纳100人同时就餐，我的一个竞争对手在对门也开了一家饭店，竞争对手雇佣了300人来这个饭店坐着不吃不喝，导致饭店满满当当无法正常营业，这在计算机中的表现就是分布式拒绝服务。在计算机系统中它利用网络协议和操作系统的一些缺陷，采用欺骗和伪装的策略来进行网络攻击，使网站服务器充斥大量要求回复的信息，消耗网络带宽或系统资源，导致网络或系统不胜负荷以至于瘫痪而停止提供正常的网络服务。

分布式拒绝服务攻击(英文意思是Distributed Denial of Service，简称DDoS)是指处于不同位置的多个攻击者同时向一个或数个目标发动攻击，或者一个攻击者控制了位于不同位置的多台机器并利用这些机器对受害者同时实施攻击。

在进行攻击的时候，可以对源IP地址进行伪造，通常攻击者会在发起DDOS 攻击之前就控制着成千上万个存在漏洞的计算机，这些计算机我们称之为“肉鸡”，入侵者通过这些“肉鸡”向目标机器在相同时间内发起并发请求，导致目标机器的系统资源瞬间被打满，无法正常对外提供服务。

与DoS攻击由单台主机发起攻击相比较，分布式拒绝服务攻击DDoS是借助数百、甚至数千台被入侵后安装了攻击进程的主机同时发起的集团行为。

攻击方式

SYN Flood攻击

SYN Flood 攻击是当前网络上最为常见的DDoS攻击，它利用了TCP协议实现上的一个缺陷。通过向网络服务所在端口发送大量的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。

众所周知,TCP要建立连接，需要进行三次握手，通信的双方最少得经过3次成功的信息交换才能进入连接全开状态(Full-Open)。一个正常的连接建立需要如下步骤：

首先，客户端向服务器发送SYN数据包，以便启动连接；
服务器响应该初始包与SYN / ACK包，以确认通信；
最后，客户端返回ACK数据包以确认从服务器接收到的数据包。完成这个数据包发送和接收序列后，TCP连接打开并能发送和接收数据。

攻击者利用TCP握手这一机制，在接收到初始SYN数据包之后，服务器将用一个或多个SYN / ACK数据包进行响应，并等待握手中的最后一步。这是它的工作原理：

攻击者向目标服务器发送大量SYN数据包，通常会使用欺骗性的IP地址。
服务器响应每个连接请求，并留下开放端口准备好接收响应。
服务器等待从未到达的最终ACK数据包时，攻击者继续发送更多的SYN数据包。每个新的SYN数据包的到达导致服务器暂时维持新的开放端口连接一段时间，一旦所有可用端口被使用，服务器就无法正常工作。

当服务器断开连接但连接另一端的机器没有连接时，连接被认为是半开的。在这种类型的DDoS攻击中，目标服务器不断离开打开的连接，等待每个连接超时，然后端口再次可用。结果是这种攻击可以被认为是“半开攻击”。

UDP Flood攻击

UDP Flood 是日渐猖厥的流量型DDoS攻击，原理也很简单。常见的情况是利用大量UDP小包冲击DNS服务器或Radius认证服务器、流媒体视频服务器。由于UDP协议是一种无连接的服务，在UDP Flood攻击中，攻击者可发送大量伪造源IP地址的小UDP包。

ICMP Flood攻击

ICMP Flood攻击属于流量型的攻击方式，是利用大的流量给服务器带来较大的负载，影响服务器的正常服务。由于目前很多防火墙直接过滤ICMP报文。因此ICMP Flood出现的频度较低。

Connection Flood攻击

Connection Flood是典型的利用小流量冲击大带宽网络服务的攻击方式，这种攻击的原理是利用真实的IP地址向服务器发起大量的连接。并且建立连接之后很长时间不释放，占用服务器的资源，造成服务器上残余连接(WAIT状态)过多，效率降低，甚至资源耗尽，无法响应其他客户所发起的链接。

HTTP Get攻击

这种攻击主要是针对存在ASP、JSP、PHP、CGI等脚本程序，特征是和服务器建立正常的TCP连接，并不断的向脚本程序提交查询、列表等大量耗费数据库资源的调用。这种攻击的特点是可以绕过普通的防火墙防护，可通过Proxy代理实施攻击，缺点是攻击静态页面的网站效果不佳，会暴露攻击者的lP地址。

UDP DNS Query Flood攻击

UDP DNS Query Flood攻击采用的方法是向被攻击的服务器发送大量的域名解析请求，通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名。域名解析的过程给服务器带来了很大的负载，每秒钟域名解析请求超过一定的数星就会造成DNS服务器解析域名超时。

DDOS 的防范

通过 Linux 自带防火墙防范攻击

以 DDOS SYN Flood 攻击为例，我们可以通过系统自带的iptables 防火墙来进行防护。

第一种方式是禁止攻击来源IP，但是通常攻击源都不只一个IP，这种方式防护比较弱。

$ iptables -I INPUT -s 192.168.0.2 -p tcp -j REJECT

第二钟方式是限制syn并发的次数以及同一个IP 新建连接数的数量。

#限制 syn 并发数为每秒 1 次$iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT#限制单个 IP 在 60 秒新建立的连接数为 10$iptables -I INPUT -p tcp --dport 80 --syn -m recent --name SYN_FLOOD --update --seconds 60 --hitcount 10 -j REJECT

但是如果攻击源特别多，其实还是很难阻挡。SYN Flood 会导致 SYN_RECV 状态的连接急剧增大，可以通过调整半连接容量大小，例如调整为 1024

$ sysctl -w net.ipv4.tcp_max_syn_backlog=1024net.ipv4.tcp_max_syn_backlog = 1024

另外，每个SYN_RECV 如果失败，内核还会自动重试，默认是 5次，可以修改为1次。

$ sysctl -w net.ipv4.tcp_synack_retries=1net.ipv4.tcp_synack_retries = 1

此外，TCP SYN Cookies 是一种专门防御 SYN Flood 攻击的方法，其原理是基于连接信息(包括源地址、源端口、目的地址、目的端口等）以及一个加密种子（如系统启动时间），计算出一个哈希值（SHA1），这个哈希值称为 cookie。

这个 cookie 就被用作序列号，来应答 SYN+ACK 包，并释放连接状态。当客户端发送完三次握手的最后一次 ACK 后，服务器就会再次计算这个哈希值，确认是上次返回的 SYN+ACK 的返回包，才会进入 TCP 的连接状态。因而，开启 SYN Cookies 后，就不需要维护半开连接状态了，进而也就没有了半连接数的限制。

注意开启 TCP syncookies 后，内核选项 net.ipv4.tcp_max_syn_backlog 也就无效了。可以通过下面的方式开启：

$ sysctl -w net.ipv4.tcp_syncookies=1net.ipv4.tcp_syncookies = 1

优化网络相关的内核参数

当遭遇攻击时，请求数会较大，你可能会看到大量处于TIME. WAIT状态的连接。

linux查看tcp的状态命令：

netstat -nat查看TCP各个状态的数量；
lsof -i:port可以检测到打开套接字的状况；
sar -n SOCK查看tcp创建的连接数；
tcpdump -iany tcp port 6000对tcp端口为6000的进行抓包。

[root@centos ~]# netstat -antActive Internet connections (servers and established)Proto Recv-Q Send-Q Local Address Foreign Address Statetcp 0 0 0.0.0.0:22 0.0.0.0:* LISTENtcp 0 0 127.0.0.1:25 0.0.0.0:* LISTENtcp 0 0 192.168.10.58:22 13.136.182.140:23107 TIME_WAITtcp 0 48 192.168.10.58:22 13.136.182.140:61282 TIME_WAITtcp6 0 0 :::22 :::* LISTENtcp6 0 0 ::1:25 :::* LISTEN

TCP状态及其描述：

状态描述 LISTEN 等待来自远程TCP应用程序的请求 SYN_SENT 发送连接请求后等待来自远程端点的确认。TCP第一次握手后客户端所处的状态 SYN-RECEIVED 该端点已经接收到连接请求并发送确认。该端点正在等待最终确认。TCP第二次握手后服务端所处的状态 ESTABLISHED 代表连接已经建立起来了。这是连接数据传输阶段的正常状态 FIN_WAIT_1 等待来自远程TCP的终止连接请求或终止请求的确认 FIN_WAIT_2 在此端点发送终止连接请求后，等待来自远程TCP的连接终止请求 CLOSE_WAIT 该端点已经收到来自远程端点的关闭请求，此TCP正在等待本地应用程序的连接终止请求 CLOSING 等待来自远程TCP的连接终止请求确认 LAST_ACK 等待先前发送到远程TCP的连接终止请求的确认 TIME_WAIT 等待足够的时间来确保远程TCP接收到其连接终止请求的确认

它们会占用大量内存和端口资源。这时，我们可以优化与TIME_ WAIT状态相关的内核选项，比如采取下面几种措施：

增大处于 TIME_WAIT 状态的连接数量net.ipv4.tcp_max_tw_buckets，并增大连接跟踪表的大小net.netfilter.nf_conntrack_max。
减小net.ipv4.tcp_fin_timeout和net.netfilter.nf_conntrack_tcp_timeout_time_wait，让系统尽快释放它们所占用的资源。
开启端口复用net.ipv4.tcp_tw_reuse。这样，被TIME_WAIT状态占用的端口，还能用到新建的连接中。
增大本地端口的范围net.ipv4.ip_local_port_range。这样就可以支持更多连接，提高整体的并发能力。
增加最大文件描述符的数量。你可以使用fs.nr_open和fs.file-max，分别增大进程和系统的最大文件描述符数；或在应用程序的systemd配置文件中，配置LimitNOFILE，设置应用程序的最大文件描述符数。