一、CDN（内容分发网络）

1、基本定义

CDN（Content Delivery Network，内容分发网络） 是一种通过在全球部署节点服务器，将用户请求导向最近节点的技术，其核心目标是通过缩短数据传输距离，减少网络延迟，提升用户体验。

工作流程：

a、用户发起DNS解析请求时，被引导至CDN的智能DNS服务器
b、智能DNS根据用户地理位置、网络状况、节点负载等因素，返回最优CDN节点的IP地址
c、浏览器向该CDN节点请求内容；如节点有缓存则直接返回，无缓存则回源站获取并缓存

关键组件：

a、源站：存储原始内容的真实服务器
b、边缘节点：全球分布的缓存服务器，存储热门内容副本
c、智能DNS：根据用户地理位置返回最近的边缘节点IP
d、负载均衡：动态分配请求到最优节点，避免单点过载

2、以蓝队的视角如何看待CDN

a、如何配置CDN

基础配置步骤：

a、域名接入：将加速域名解析到CDN服务商提供的CNAME地址
b、源站配置：设置源站IP或域名，指定回源端口和协议
c、缓存策略配置：根据业务需求设置不同路径的缓存规则（如静态资源缓存7天，动态页面不缓存）
d、HTTPS配置：上传SSL证书，开启HTTPS加速和安全传输

安全加固配置：

a、源站IP访问控制：配置防火墙规则，仅允许CDN节点的IP段访问源站，拒绝任何直接访问源站的请求
b、Referer防盗链：配置访问控制，识别和过滤非法访客，防止流量盗刷和恶意攻击
c、Rate Limiting：配置严格限流规则，防止CC攻击
d、WAF开启：启用Web应用防火墙，拦截SQL注入、XSS等应用层攻击

b、配置CDN后有何作用

a、隐藏源站真实IP：用户始终只与CDN节点交互，源站真实IP完全不可见，攻击者难以直接攻击源站
b、防御DDoS攻击：CDN的分布式架构拥有巨大带宽，可将海量攻击流量分散到全网节点吸收消化
c、减轻源站压力：边缘节点缓存大量静态内容，源站请求量可大幅下降
d、提升访问速度：用户就近访问，减少网络传输延迟
e、高可用性保障：节点冗余设计，源站故障时缓存内容仍可为用户提供服务
f、防御应用层攻击：配合WAF功能，在CDN节点层面拦截恶意请求

c、为什么要配置CDN

a、安全需求：防止源站IP泄露后被DDoS攻击、CC攻击或漏洞扫描直接命中
b、性能需求：提升用户体验，减少页面加载时间
c、稳定性需求：应对突发高流量，防止源站过载崩溃
d、成本优化：通过就近访问减少跨区域带宽传输成本
e、合规需求：部分行业监管要求具备一定的DDoS防护能力

3、以红队视角如何看待CDN

1、如何识别CDN

方法一：多地Ping检测

使用在线Ping工具（如ITDOG、站长工具、Ping.pe）对目标域名进行全球多节点Ping：

  • 未使用CDN：各地区返回的IP地址完全一致

  • 已使用CDN：不同地区、不同运营商返回多个截然不同的IP地址

常用在线工具：

方法二：Nslookup/Dig检查

通过命令行查询域名的DNS记录，观察CNAME记录：

bash

dig target.com

如输出包含 *.w.kunlunsl.com（阿里云CDN）、*.cloudfront.net（AWS CloudFront）等明显的CDN厂商CNAME别名，则说明开启了CDN

2、如何绕过CDN识别真实资产

方法一：子域名枚举

原理：很多网站主站配置了CDN，但子域名（如mail.xxx.com、dev.xxx.com、oa.xxx.com）因运维疏忽未配置CDN，直接暴露源站IP

  • 工具：Subfinder、OneForAll、Layer子域名挖掘机

  • 操作：枚举所有子域名后逐个解析IP，发现未上CDN的子域名

  • 局限性：如配置了泛解析加速（*.example.com），该方法失效

方法二：DNS历史解析记录查询

原理：CDN部署前，域名曾直接解析到源站IP，这些历史A记录可能仍被DNS缓存服务保留

  • 工具：ViewDNS、dnsdumpster、SecurityTrails

  • 操作：查询域名的历史DNS记录，找到CDN部署前的源站IP

方法三：SSL证书查询

原理：源站IP通常与SSL证书绑定，通过证书信息可发现源站IP。即便源站隐藏于CDN之后，SSL证书中仍可能包含真实IP信息

  • 工具：crt.sh、Censys

  • 操作：搜索目标域名的SSL证书历史记录，提取证书中的IP地址

方法四：国外节点访问（利用地域配置差）

原理：国内中小网站为节约成本，仅购买“中国大陆加速”套餐，海外请求绕过CDN直接回源

  • 操作：使用海外VPS或海外代理节点进行解析和访问，获取真实源站IP

方法五：C段扫描

原理：找到目标域名解析出的IP后，扫描其所在C段的IP，可能发现其他关联资产或源站

  • 工具：FOFA、ZoomEye、Nmap

  • 操作：通过空间引擎搜索，寻找可能未受WAF保护的Nginx反向代理或其他边缘设备

方法六：邮件头分析

原理：目标服务器发送的邮件（如密码重置邮件、注册确认邮件）的原始邮件头中，可能包含源站真实IP

  • 操作：注册目标网站账号，触发邮件发送，查看邮件完整Header中的Received字段

3、如何确定真实资产

确认步骤：

a、IP验证：找到可疑真实IP后，直接访问该IP，观察返回内容是否与目标网站一致
b、端口扫描：对确认的源站IP进行端口扫描，发现更多开放服务和潜在攻击面
c、关联分析：通过FOFA、ZoomEye等空间引擎，搜索该IP关联的其他域名和资产
d、C段扩展：扫描源站IP所在C段，发现同一网络内其他潜在目标

防御建议（蓝队篇，红队需知）：

蓝队可采取以下措施防止源站IP泄露：

a、只允许CDN节点IP访问源站，配置严格的ACL白名单
b、定期更换源站IP（建议每月轮换）
c、禁止源站直接对外发送邮件，或使用第三方邮件服务代理
d、子域名统一接入CDN，避免出现防护死角
e、开启WAF的IP信誉库防护和严格限流规则

二、蜜獾（主动欺骗防御系统）

1、基本定义

注意：在网络安全领域，“蜜獾”常与“蜜罐”（Honeypot）混用，形成“主动欺骗防御体系”，包含以下概念：

蜜罐（Honeypot） 的核心定义：蜜罐技术本质上是一种对攻击方进行欺骗的技术，通过布置一些作为诱饵的主机、网络服务或者信息，诱使攻击方对它们实施攻击，从而可以对攻击行为进行捕获和分析，了解攻击方所使用的工具与方法，推测攻击意图和动机。

在蜜罐防御体系中，有三个层次的概念：

  • 蜜饵（Honeytoken） ：最轻量级的诱饵，如假API密钥、假数据库账号、假员工邮箱等，一旦被访问或使用，立即触发安全告警

  • 蜜罐（Honeypot） ：模拟真实服务的主机或虚拟系统，伪装成Web服务器、数据库、SSH服务等，吸引攻击者攻击并记录行为

  • 蜜网（Honeynet） ：由多个蜜罐组成的仿真网络环境，模拟真实企业网络拓扑，诱使攻击者深入探索

蜜獾（HoneyBadger） 的两种指代含义：

a、开源主动防御框架HoneyBadger：这是一个针对目标地理定位的开源框架。不同于传统的蜜罐被动检测恶意行为，HoneyBadger是一个主动防御工具，用于确定恶意行为者的身份及其地理位置。它通过代理技术收集目标主机信息，实现主动地理定位和多平台支持。

b、“高交互蜜獾” ：在蜜罐基础上的升级概念，指在传统蜜罐中预先注入反击代码，当攻击者触发时，反方向获取攻击者终端设备上的信息，进行主动的网络追踪和溯源。

2、以蓝队的视角如何看待蜜獾/蜜罐

a、如何配置蜜罐

部署位置选择：

  • 公网蜜罐：尽早部署以便被FOFA、鹰图等空间引擎收录，让红队尽早发现并攻击

  • 内网蜜罐：在内网调试后再部署，模拟脆弱服务捕获攻击者的横向探测行为

部署层次策略（分层部署）：

  • 外层蜜罐：开放常见端口，诱捕自动化扫描和初级攻击者

  • 中层蜜罐：高仿真业务系统，诱捕高级攻击者

  • 深层蜜罐：结合真实系统伪装，用于反制溯源

常见蜜罐工具：

  • HFish：国内流行的免费蜜罐平台，支持多种服务模拟和告警

  • OpenCanary：最流行的灵活蜜罐守护进程，可触发系统日志、邮件告警

  • Honeyd：在网络中创建虚拟主机的小守护进程

  • Canary Tokens：轻量级蜜饵工具

配置示例（HFish部署）：

bash

git clone https://github.com/hacklcx/HFish.git
cd HFish && pip3 install -r requirements.txt
python3 hfish.py

b、如何使蜜罐合理化（伪装）

核心原则：蜜罐不能太假。部署的蜜罐系统应尽可能与业务相关，且需要模拟出相对应的网络、服务器和终端设备。

a、服务模拟：同一蜜罐的多个端口开启不同的Web服务，给攻击者一种“靠自己努力获取成果”的假象

b、诱饵文件投放：在蜜罐文件系统中放置伪装的“敏感文件”（如fake_passwords.xlsx），诱捕攻击者下载并触发告警

c、高仿真蜜罐：部署高仿真WebLogic、SSH服务等，模拟真实业务环境

d、异构伪装：使用与真实系统不同的技术栈部署蜜罐，防止攻击者通过指纹识别判断

e、蜜网构建：构建包含Web服务器、数据库、域控的仿真内网，诱捕高级攻击者

f、分层混淆：

  • 第一层：伪装成真实系统的蜜罐，尽可能还原业务功能

  • 第二层：将真实系统伪装成蜜罐，让攻击者产生误判

c、在红蓝对抗中如何使用

蓝队战术价值：

a、早期预警：部署蜜罐捕获攻击者的横向扫描行为，第一时间发现入侵
b、攻击溯源：通过蜜罐获取攻击者的IP地址、攻击工具和手法，进行溯源反制
c、反制红队：高交互蜜罐注入反击代码，反向获取攻击者终端设备信息
d、消耗攻击时间：精心设计的高交互蜜罐可以拖延红队数天时间，消耗其攻击精力
e、情报收集：收集攻击者的IP、工具样本、攻击路径，丰富威胁情报库

3、以红队视角如何看待蜜獾/蜜罐

a、如何识别蜜罐

手动识别：

a、端口与服务异常：蜜罐通常同时开放多个看似相关的端口服务，需判断是否符合业务逻辑

b、响应延迟差异：某些蜜罐响应请求存在固定的延迟模式，与真实服务有差异

c、命令行交互异常：在SSH/Telnet蜜罐中执行复杂命令时，响应可能不符合真实系统行为

d、低交互蜜罐特征：低交互蜜罐仅开放一些简单的服务或端口，用来检测扫描和连接，这种容易被识别

通过查看Web指纹识别常见的蜜罐：

a、开源蜜罐指纹：开源蜜罐通常保留版权信息或特定返回格式，可通过手动验证收集指纹库

b、商业蜜罐JS特征：知名商业蜜罐会在首页加载特定JS文件，可通过分析JS代码中的混淆变量进行识别

c、前端请求特征：当访问某个应用系统时有大量对各大主流厂商的ajax/jsonp请求时，大概率就是遇到蜜罐了

d、管理端指纹识别：蜜罐管理端通常有特定的页面结构和JS代码特征，可通过URL路径和响应码判断

e、Banner信息：某些蜜罐返回的Server头、Banner信息具有明显特征

b、如何确认蜜罐，或确定蜜罐后不被记录

确认蜜罐：综合多种识别方法交叉验证，如发现多个可疑特征（异常端口+异常JS请求+低交互特征），即可确认。

不被记录的策略：

a、代理链跳转：多级代理跳转，隐藏真实攻击来源

b、使用专用渗透环境：攻击方必须使用纯净的专用渗透环境进行攻击，完全与日常工作环境区分开来，并做测试环境的定期还原

c、浏览器防护：

  • 使用隔离的浏览器进行渗透，与日常浏览器区分

  • 开启无痕模式，避免本地Cookie泄露

  • 安装反蜜罐插件（如Bypass Honeypot），拦截可疑的XSSI请求和JS指纹采集

d、虚拟机隔离：渗透操作在虚拟机中进行，每次项目完成后回滚镜像

e、禁用或绕过fingerprintjs：蜜罐中常使用fingerprintjs库根据不同IP和浏览器的特定标识判断访客身份

f、抓包分析：通过抓包方式获取外域的请求链接，发现蜜罐特征后及时中断访问

c、蜜罐的基本特征有哪些

a、无业务流量特征：蜜罐没有正常的业务用途，所有流入/流出蜜罐的流量都预示着扫描或攻击行为

b、低交互特征：低交互蜜罐仅模拟部分服务协议，不支持执行复杂命令

c、高仿真但有瑕疵：高仿真蜜罐虽有较高迷惑性，但在细节上总有瑕疵（如配置文件路径、版本号、命令返回格式等）

d、JS指纹采集特征：蜜罐常利用jsonp/xss漏洞收集攻击者身份信息，表现在前端会有大量指向主流厂商的ajax请求

e、端口开放特征：蜜罐开放特定端口的组合常具有规律性，不符合真实业务部署逻辑

f、配置失真特征：部分蜜罐系统在配置层面存在异常，如使用了真实业务中不存在的默认口令组合

d、在红蓝对抗中如何快速测试是否是蜜罐

快速测试清单：

a、试探端口开放：使用Nmap扫描目标端口，判断端口开放组合是否符合常规业务逻辑

b、发送异常请求：发送格式错误或超长的请求数据包，观察响应是否过于规范或出现蜜罐特有错误页

c、检查JS请求：打开浏览器开发者工具查看Network面板，观察是否存在大量指向非目标域名的jsonp/ajax请求

d、测试低交互行为：尝试执行需要高交互的命令（如NC反弹Shell、上传文件等），观察是否被限制

e、延迟差异测试：多次发送相同请求，测量响应时间是否存在固定规律（蜜罐可能存在模拟延迟）

f、Banner特征对照：收集常见蜜罐的Banner指纹，快速对照识别

g、子域名试探：访问看似高风险的高价值服务（如xxl-job、zabbix、WebLogic管理后台），若发现存在明显弱口令但系统表现异常，极可能是蜜罐