-- 简介 --

• Dos(Denial of Service): 通过某种手段是目标计算机或网络无法提供正常服务, 影响正常用户 DDos(Distribute Denial of Service): 即规模更大的Dos
• 造成DDos方式:
  1. 触发服务器Bug导致服务器进程崩溃
  2. 大量恶意请求导致服务器CPU、内存、磁盘等资源被过度消耗
  3. 网络流量劫持、DNS劫持导致服务器中断
• 类型: SYN flood、UDP flood、UDP反射放大攻击、cc攻击(应用层攻击)

-- 网络层DDos --

SYN flood

• 特点: 应用了TCP协议的缺陷
• 原理: 攻击者发送大量伪造IP地址的SYN包, 进行第一次握手, 服务端随后发送 SYN+ACK 包, 由于源IP是伪造的, 服务端无法接收到ACK回应包, 此时服务端会等待一段时间(大约75秒, 若超时则丢弃这个连接), 处于半开连接状态(此时服务端也需要为这些连接分配资源, 并使用一个队列储存这些半开连接, 消耗CPU和内存)
• 措施: SYN Cookie, SYN Proxy, Safe Reset SYN Cookie: 服务端不储存半开连接信息, 而是根据客户端SYN包, 通过算法计算出SYN+ACK报文的初始序列号y(一般是HMAC算法), 所以这个序列号y并不是随机生成的，而是服务端秘密生成的, 如果客户端发送ACK报文， 服务端收到后将以同样的算法再次计算序列号，确认ack是合法的，服务端从这个时候开始才真正为这个连接分配资源并建立连接 开启SYN Cookie后，半开连接不会占用队列，不消耗服务端的内存。但是为了生成这个特殊的序列号，服务端需要做额外的密码学计算SYN Reset: 一般在网络防火墙中使用, 接收到客户端的SYN报文后，防火墙返回一个确认号错误的SYN+ACK报文，真实的客户端在发现错误后会回应一个RST报文，这样防火墙就知道这个IP地址是真实客户端，并将其添加到白名单中，后面如果客户端重新请求连接时就将它放行。而虚假的源IP地址不会有回应，所以它们就不会被列入白名单。

UDP flood

• 特点：与SYN flood相似，只不过使用了UDP无连接协议

UDP放大攻击

• 特点：近几年非常流行的DDoS攻击方式，超大流量的DDoS攻击多数是由反射放大型攻击产生的
• 原理：使用UDP协议，因为UDP是无连接的协议，当客户端伪造源IP地址访问UDP服务时，服务端会把响应内容返回给伪造的源IP地址，所以当攻击者把源IP地址指定为攻击目标时，响应内容就被发送给了攻击目标。如果一个UDP 服务的响应内容远大于请求内容，攻击者就借助UDP服务实现了四两拨千斤的放大攻击效果

-- 应用层DDos --

特点

• TCP三次握手已经完成，连接已经建立，即发起攻击的IP地址都是真实的
• 攻击流量难以与正常访问流量相区分

CC攻击

• 原理：对资源消耗较大的应用页面不断发起正常请求 查询数据库、读/写硬盘文件等操作，都会消耗比较多的资源

  比如$sql="select*from post where tagid-'$tagid' order by postid desc limit Sstart, 30";当 post 表数据庞大，翻页频繁，$start数字急剧增加时，数据库要查询出$start+30条数据并过滤掉前$start条数据，该查询操作的效率就会呈现明显下降趋势。存在高并发请求时，因查询无法立即完成，资源无法立即释放，会导致数据库请求连接过多，数据库阻塞，无法正常打开网站 此外，别有用心的用户简单地使用应用程序的正常功能也能过度消耗服务器资源，在很多应用中，分页大小是可以由客户端指定的，如果用户提交一个超大的值，那么数据库将返回一个超大的结果集。不仅数据库查询会消耗很多资源，而且应用程序也有可能因内存不足而崩溃。

• 手段: 可利用HTTP管线化特性, 在同一个TCP连接中连续发送HTTP请求, 而不等待HTTP响应, 从而实现更高的请求频率, 但是，管线化存在队头阻塞问题，如果Web服务器支持HTTP/2或HTTP/3协议，理论上使用多路复用及请求头压缩机制可以实现更高的攻击效率。到目前为止，我们还没看到利用这些特性的cC攻击工具

SSL/TLS Exhaustion DDoS

• 原理: HTTPS协议中SSL/TLS握手过程以及重协商(Renegotiation)也是消耗服务器计算资源的，如果攻击者发起大量SSL/TLS握手请求或重协商请求，就会大量占用服务器CPU
• 注意1: 为了提升攻击效率，客户端并不需要真正与服务端建立SSL/TLS连接 例如，名为Pushdo 的僵尸网络程序与使用了SSL/TLS 协议的服务器建立TCP连接之后，只是简单地发送随机数据，所以客户端的开销非常小。但是服务端还是要执行sSL/TLS握手流程，并尝试把垃圾数据当作sSL/TLS握手数据包来解析。虽然sSL/TLS握手失败，服务端还是耗费了CPU计算资源。大部分防火墙并不会深入解析SSL/TLS握手包的内容，所以不会阻拦这种攻击。
• 注意2: 使用重协商请求前提是服务端支持, 现在绝大部分Web服务器或者负载均衡都默认不启用重协商

防御手段(应用层)

• 限制请求频率

  原理: 对每个客户端的请求频率进行限制 缺点: 若通过IP进行限制, 可能造成在多用户共用IP地址的场景中出现连坐现象 解决: 所以可根据 用户信息 或 会话标识 配合IP检测 进行限制 (但注意, 使用用户可控的信息可能会导致其它安全问题) 绕过IP检测:

  1. 利用匿名代理服务器(但一般代理服务器普遍信誉不高, 很多可能已经进入安全设备的黑名单),
  2. 利用 家庭宽带拨号上网(PPPoe)提供的IP地址(全部都是干净的IP), 使用自动化拨号工具获得海量IP
  3. 使用云厂商的云服务器, 许多支持按量付费, 使用云厂商的API就可批量创建服务器, 用完后批量释放
  4. 创建恶意网站或APP, 嵌入相关js代码(循环访问给定url的代码), 访问者就会不停向目标发起请求

• IP威胁情报库

  原理: 将发起过DDos攻击的IP加入黑名单, 将一段时间内访问行为正常的IP加入白名单 (一般黑白名单在安全产品之间共享), 阻断黑名单IP的请求, 在紧急情况下只放行白名单IP的请求 注意: 用户的IP地址会变化, 所以 黑白名单 要设置有效期 缺点: 还是可能造成连坐, 需配合其它防御和检测方法

• JavaScript检测

  原理: 大多数攻击程序不带有js执行引擎, 只能发送http请求, 所以可通过校验客户端是否能正常执行js代码来判断是否为攻击流量 检验方式: 使用js在cookie中植入一小段Token, 然后自动刷新页面, 防御引擎可只让带有合法Token的请求通过 注意:由于在前端生成合法Token,所以生成过程要保密,且可对js代码做混淆处理,增加攻击者分析难度缺点: 在非网页(如API)场景中, 客户端本身就不支持js, 也不使用cookie, 所以此时该方法不适用

• 客户端指纹

  原理: 每一个HTTP客户端(包含浏览器)都有自己的特征，最简单的是User-Agent,但是User-Agent可以被轻易篡改。我们深入分析网络协议，就可以找到更多辅助判断客户端类型的特征, 在安全产品中被广泛用于识别客户端类型的是TLS指纹, 在TLS握手包中，客户端需要提交自己支持的加密算法套件，而每种客户端发送的算法套件都会有差异, 如果自己写一个HTTP客户端程序， 或者使用curl命令，它又会有不一样的算法套件。所以，如果我们收集了足够多的客户端及对应的算法套件特征，通过识别客户端的加密算法套件，就可以判断客户端的类型 其次可以识别HTTP头特征, 比如HTTP头的个数 顺序, 这些特征会根据客户端的 浏览器种类 以及代码层面的关系而改变, 服务端可检测 http头特征是否与 user-agent所声明的浏览器一致, 来判断是否为攻击流量 除此之外IP与TCP报文也有特征

• 人机校验

  原理: 通过人机检测(验证码 滑块等)检测是否为攻击者 缺点: 只适用于网页与app中, 在API场景下无法直接校验访问者, 且频繁人机检验会破坏用户体验

• 访问行为识别

  原理: 攻击者访问行为与正常用户有区别, 比如攻击程序可能只会访问固定的几个URL，或者完全随机的URL，而不会加载静态资源

• 其它

  校验客户端能否执行跳转，包括Location头跳转、meta标签刷新，一般攻击程序不会有这些特性，不能正确应答这个挑战