互联网企业安全高级指南读书笔记之网络安全

网络入侵检测

传统 NIDS

绿盟 IDS 体系架构

绿盟 IPS 体系架构

IDS/IPS 部署示意图

大型全流量 NIDS

由于 NIDS 采用的是基于攻击特征的签名库，只要加载的攻击特征一多，系统负载会马上飙升，远到不了系统的标称负载就会出现丢包和误报的上升。不能跟基础架构一起扩展的安全解决方案最终都会掣肘

针对 IPS 一个打折扣的版本就是利用 DDoS 引流 - 清洗（过滤）- 回注的防护原理，将防护的流量迁移到清洗集群，清洗集群上的过滤规则只是有针对性的几条高危漏洞规则，做一层很轻的过滤

T 级 DDoS 防御

DDoS 分类

网络层攻击

syn-flood：通过原始套接字发送源地址虚假的 SYN 报文，使目标主机永远无法完成 3 次握手，占满系统协议栈队列，进而拒绝服务。防御其攻击的常见方法有 syn proxy、syn cookies、第一次请求的 SYN 包丢弃等。近年攻击者开始采用 1000 字节的 SYN 包进行攻击，在消耗 CPU 资源的同时，阻塞边缘带宽，攻击流量相比标准 SYN 包大大增加
ACK-flood：虚假的 ACK 包，目标设备会直接回复 RST 包丢弃连接
UDP-flood：使用原始套接字伪造大量虚假源地址的 UDP 包
ICMP-flood：ping 洪水

应用层攻击

CC：通过傀儡主机或寻找匿名代理服务器，向目标发起大量真实 HTTP 请求，最终消耗掉大量并发资源
DNS-flood：伪造源地址的海量 DNS 请求，用于淹没目标的 DNS 服务器。将源地址设置为各大 ISP DNS 服务器的 IP 地址，以突破白名单限制，将查询内容改为针对目标企业的域名做的随机化处理，查询无法命中缓存时间，消耗会进一步增加。DNS 不仅在 UDP-53 提供服务器，同样在 TCP 提供服务，防御可将 UDP 查询强制转为 TCP，如果是虚假地址则不予回应。源地址伪造为 ISP DNS 的请求，可以通过 TTL 值进一步判断
慢速连接攻击：针对 HTTP 协议，先建立 HTTP 连接，设置一个较大的 content-length，每次只发送很小的字节，让服务器以为 HTTP 头一直没有传输完成，这样连接一多就会出现连接耗尽
DOS 攻击：服务器程序存在 bug、安全漏洞或架构性缺陷，攻击者通过构造畸形请求发送给服务器，服务器因不能正确处理恶意请求而陷入僵死状态

攻击方式

混合型攻击：实际大流量的攻击中，往往混杂了 TCP 和 UDP 流量，网络层和应用层攻击同时进行
反射型攻击：2004年反射型攻击（DRDOS）第一次披露，将 SYN 包的源地址设置为目的地址，向大量真实的 TCP 服务器发送 TCP 的 SYN 包，收到这些 SYN 包的 TCP 服务器为了完成 3 次握手把 SYN|ACK 包应答给目标地址。这样制造的流量和攻击流量是 1:1，如果回包体积比较大或协议支持递归效果，攻击流量就会被放大。反射型攻击利用的协议目前包括 NTP、Chargen、SSDP、DNS、RPC Portmap 等
流量放大型：以 SSDP 协议为例，攻击者将 Search type 设置为 ALL，搜索所有可用的设备和服务
脉冲型攻击：攻击持续时间非常短，通常在 5 分钟以内

攻击类型	放大倍数
DNS	54
NTP	556.9
SNMPv2	6.3
NetBIOS	3.8
SSDP	30.8
CharGEN	358.8
QOTD	140.3
BitTorrent	3.8
Kad	16.3
Quake Network Protocol	63.9
Steam Protocol	5.5
Multicast DNS(mDNS)	10
RIPv1	131.24
Portmap(RPCbind)	28

网络层的攻击检测通常分为逐流和逐包：

逐流根据 netflow 以一定的抽样比例，检测网络是否存在 DDoS 攻击，精确度低
精确度高，响应时间短，但成本比较高

防御清洗策略的启动依赖于阈值，大部分场景下可以做秒级检测，但不能做秒级防御，在触发防御前完成攻击就表现为脉冲

链路洪泛型攻击：不直接攻击目标，而是以堵塞目标网络的上一级链路为目的。对于使用了 IP anycast 的企业网络来说，流量会分摊到不同地址的基础设施，攻击者攻击目标网络 traceroute 的倒数第二跳，致使链路拥塞。国内 ISP 目前尚未开放 anycast

多层防御结构

ISP/WAN 层

带宽是所有 IDC 成本中最贵的资源，没有之一。云堤提供了“流量压制”和“近源清洗”的服务。流量压制是一种分方向的黑洞路由，近源清洗和黑洞路由相比，防御方的成本比较高，且触发到响应的延时较大

CDN/Internet 层

对 HTTP CC 类型的 DDoS，不会直接到源站，CDN 会先通过自身的带宽硬抗。抗不住的或者穿透 CDN 的动态请求会到源站

云清洗厂商提出的策略是，预先设置好网站的 CNAME，将域名指向云清洗厂商的 DNS 服务器，在一般情况下云清洗厂商的 DNS 仍将穿透 CDN 的回源的请求指向源站，在检测到攻击发生时间，域名指向自己的清洗集群，然后再将清洗后的流量回源，检测方式主要是在客户网站前部署反向代理（Nginx），托管所有的并发连接。在对攻击流量进行分流的时候，准备好一个域名到 IP 的地址池，当 IP 被攻击时封禁并启用地址池中的下一个IP，如此往复

不过这类方案都有一个通病，由于国内环境不支持 anycast，通过 DNS 引流的方式需要比较长的生效时间，这个时间依赖于 DNS 递归生效的时长，对自身完全不可控，很多用户使用的 DNS 递归服务器最小 TTL 值长达24小时。同时 CDN 仅对 Web 类服务有效，对游戏类 TCP 直连的服务无效

网上很多使用此类抗D服务的过程可以概括为一句话：更改 CNAME 指向，等待 DNS 递归生效

DC 层

在 DC 出口部署 ADS 设备，近目的清洗。在 DC 出口以镜像或分光部署 DDoS 探针，当检测到攻击发生时，将流量牵引到旁路部署的 DDoS 清洗设备，再将清洗的正常流量回注到业务主机

应用层的防护需要结合业务来做，ADS 在能利用的场景下承担辅助角色，比如对于游戏封包的私有协议，通过给 packet 添加指纹的方式，ADS 在客户端和服务端中间鉴别流入的数据包是否包含指纹

OS/App 层

这是 DDoS 的最后一道防线。这一层的意义主要在于漏过 ADS 设备的流量做最最后一次过滤和缓解，对 ADS 防护不了的应用层协议做补充防护。比如 NTP 反射，可通过服务器配置禁用 monlist，如果不提供基于 UDP 的服务，可以在边界上直接阻断 UDP 协议

实现方式可以是 Web 服务器模块，也可以是独立部署的旁路系统，反向代理将完整的 HTTP 请求转发给检测服务器，检测服务器根据几方面的信息：

来自相同 IP 的并发请求
相同 IP+Cookie 的并发请求
相同 HTTP 头部可设置字段
相同的 Request URL

然后保存客户端的连接信息技术表，直到触发阈值，然后服务器会进行阻断，为避免误杀，也可以选择性地弹出验证码

链路带宽

增加链路带宽是以上所有防御的基础，必须消除解决方案中的单点瓶颈

不同类型的企业、服务和策略

企业

大型共有云厂商，IaaS、PaaS 平台
市值百亿美元以上的互联网公司
例如比较高的业务
中小企业

服务

Web 类服务终端用户可以有一定的延迟容忍
游戏类分为两种：
- Web API 形式的游戏和 Web 服务类似
- TCP Socket 只有通过 DNS 引流和 ADS 来清洗。ADS 不能防御的部分可以通过修改客户端、服务端的通信协议，比如封包加 tag 标签，检测到没有 tag 的包一律丢弃，防御机制基本都依赖于信息不对称的小技巧

策略

分级策略：对于强帐号体系应用，例如电商、游戏等，如果 SSO 登录不可用则全线服务不可用，攻击者只要击垮这些服务就可以了。安全上需要考虑针对不同的资产使用不同等级的保护策略，根据 BCM 的要求，先将资产分类分级，划分出不同的可用性 SLA 要求，然后根据不同的 SLA 实施不同级别的防护
Failover 机制 —— DDoS 防御不只是依赖于 DDoS 防御的那 4 层手段，同时依赖于基础设施的强大，例如做分流，就需要多点异地灾备，mirror site & hot site & standby system，云上的系统需要跨 AZ 部署，这些是可以随时切换的基础
有损服务——在应用服务设计的时候，应该尽量避免”单点瓶颈”，避免一个点被 DDoS 了整个产品就不好用了，而是希望做到某些服务即使关闭或下线了，仍然不影响其他在线的服务（或功能），能在遇到需要弃卒保帅的场景时有可以”割肉”的选择，不要除了 0 就是 1，还是要存在灰度

链路劫持

HTTP DNS

运营商为了减少跨 ISP 流量结算，会在本网内缓存 ICP 的内容，广告联盟等甚至也会劫持域名替换广告

HTTPDNS 的本质就是利用 HTTP 协议来完成域名解析，防止被运营商劫持，不过其请求是明文的，仍然可以被劫持，只不过劫持的代价比原来更大一些

全站 HTTPS

加密算法：密钥交换算法建议使用 RSA 或 ECDHE_RSA，内容传输加密建议使用 AES-GCM 或 ChaCha20
防降级攻击：配置 SCSV(Signaling Cipher Suite Value)选项，另外禁止客户端主动重协商
如果为提升性能支持 TFO（TCP Fast Open），实际上允许 TCP|SYN 包带 payload，对现有的扛 DDoS 策略会产生比较大的影响

大型站点除了 Web 服务器需要支持 HTTPS 以外，CDN 也需要支持 HTTPS，一般情况下需要把网站的私钥提供给 CDN 服务商，但这样就引入了第三方的风险，不得不提的是 cloudflare，它提供了 keyless 的 HTTPS 服务，分成几种实现，从轻度到重度

Flexible SSL 只做客户端浏览器到 CDN 之间的 HTTPS 加密，回源使用 HTTP。Full SSL 这个层次不止实现前者，还包括 CDN 到源站之间也是用 HTTPS，但不校验服务端证书，而第三个层次不仅全 HTTPS，且会校验服务端证书的有效性

登录过程加密

即便在 HTTPS 的状态下传输口令，假如网关流量被劫持，证书被替换。无知的小白用户还是选择了不安全的连接怎么办，另一方面现在还出现了在 IDC 劫持流量的攻击行为，这种盗号的效果直逼拖库。于是有的厂商在 HTTPS 的基础上，在应用层再实现一次加密，即便你劫持了流量，也看不到明文。以某厂账号的网页登录为例，登录过程中，客户利用 Javascript 先将用户输入的口令加密，然后再提交给服务端

当然 Javascript 加密用于传输密文只是一方面，另一方面也是为了防止协议逆向后引发的业务安全问题，如自动化注册机

跨 IDC 传输加密

真正发生于 IDC 链路层的劫持，目前没有很好的解决方案，只能尽可能地做到在跨 IDC 传输，跨安全域传输时使用加密通道。应用层支持全流量 TLS 或加密的 VPN 点对点连接

WAF

WAF 架构分类

国外几款商业产品的 WAF 支持导入证书的方式来解决 HTTPS 环境的安全防护，通常国内各甲方安全团队自研 WAF 产品基本不支持 HTTPS

CNAME 部署

将域名的 CNAME 方式解析指向防御方分配的 CNAME 别名就完成了部署。优势在于部署方便快捷，同时还有加速网站性能与阻断 DDoS 等效果。缺点是无法防护 HTTPS 流量

module 部署

典型产品是 ModSecurity，需要在 WebServer 部署\编译时支持 modules，还需要对模块的规则进行优化精简与按需增加，开发和运营成本极高，不过这类方式在应对 HTTPS 类业务非常适用

也存在例如基于 Nginx 的 Lua 脚本开发的 WAF、基于 IIS 筛选器开发的 WAF

网络层部署

直接部署在机房或被防护网络入口位置，其对于 HTTPS 协议无能为力，但无入侵性、易部署、不影响业务性能、可通过 RESET 包阻断 HTTP 会话、可旁路接入

混合型 WAF 架构

通过前几类 WAF 的组合，实现相互补防覆盖不到的地方

安全策略建设

主流 Web 漏洞检测规则

OWASP 测试指南
各主流 Web 漏洞扫描器
漏洞测试演示平台 bWAPP

评判其是否覆盖主流高危 Web 漏洞的检测标准

业务风险检测规则

已发现的业务漏洞，需临时封堵攻击行为
某些高危或异常行为的监控，主要目的生产数据，为业务异常行为分析提供数据基础

性能优化

架构优化

资源：如果拥有整个机房的网络建设管理权限，则可以考虑在机务核心交换机处流量镜像到我们的 WAF 设备，此时无论 WAF 的性能如何，均不会影响业务的正常运营，是较为理想的以检测为目的的 WAF 架构
业务性能：安全产品对性能的影响通常是业务方最为敏感的问题，往往业务方耗费大量资源投人优化为提升业务性能毫秒级的响应，可能因安全产品的接入立马消耗殆尽，如果不能解决业务方挑战的问题，那么你的产品基本没有被接纳的机会，所以核心业务基本不会接受类似 Modsecurity 那种侵入性的安全产品，所以更应该优先选择 cname 或接入层 module WAF 方式

规则优化

算法优化：WAF 的流量匹配不能直接丢给正则引擎
正则优化：Google 出品的正则引擎 RE2 是目前公认的较好引擎，相比传统古老的 PCRE 引擎更高效快速，但存在对二进制数据流匹配的问题