一、 应用特征识别技术
1.传统行为检测技术
1.1 五元组检测原理
1.2 配置思路
1.3 效果展示
需求背景2
1.4 传统行为检测的缺陷
无法识别应用层内容：若应用更换端口（如QQ改用随机端口）或伪装协议（如HTTPS加密），传统方法失效。
无法精细控制：例如需求二中需放行特定QQ账号，五元组无法识别账号信息（位于应用层Data字段）。
2.深度行为检测技术
2.1 产生原因
核心问题：
传统技术无法识别精细的数据包应用和行为，无法识别经过伪装的数据包，无法满足现在的安全需求和可视需求。
解决方案：深度行为检测分为两类：
DPI（深度包检测）：解析应用层内容。
DFI（深度流检测）：分析流量行为模式。
2.2 深度行为检测技术有点
2.3 DPI（深度包检测）
1. 基于特征字的检测技术
原理：通过匹配数据包应用层的特征字符串识别应用。
优势：支持协议扩展（更新特征库即可识别新应用）。
2.基于应用层网关的检测技术
原理：
先解析控制流（如VoIP的H.245信令）。
从中提取数据流信息（如IP、端口）。
3.基于行为模式的检测
原理：通过分析用户行为频率而非协议内容识别应用。
优势：适用于加密流量或协议无特征的场景。
2.4 DFI技术（深度流检测）
1. 原理
分析流量行为特征（非内容）：
包长度、连接速率、会话持续时间等。
2.5 DPI vs DFI对比
| 维度 | DPI | DFI |
|---|---|---|
| 识别依据 | 应用层内容特征 | 流量行为模式 |
| 加密流量支持 | 无法识别加密内容 | 可识别（行为不变） |
| 精细度 | 高（精确到具体应用） | 低（仅分类，如P2P） |
| 性能消耗 | 高（需解析每个包） | 低（仅统计流特征） |
二、 HTTP识别控制技术
1.需求背景
❓HTTP报文中，哪个字段是表示URL？-Host字段
❓封堵HTTP网站，是否需要先放通三次握手的报文？-是
2.HTTP协议特性
明文传输：所有内容（URL、表单数据、Cookie）均未加密。
关键字段：
Host字段：标识访问的域名（如Host: www.youku.com）。User-Agent字段：标识客户端类型（PC/手机/浏览器）。会话流程：
3.HTTP识别工作原理
1. 识别关键点：Host字段
抓包分析：
用户访问
www.youku.com时，GET请求包中必含Host: www.youku.com。设备通过深度包检测（DPI） 提取该字段，匹配URL规则库。
技术依赖：
实时更新URL规则库（包含视频网站域名列表）。
2. 封堵前的必要条件
问题：是否需要放通TCP三次握手？
答案：是！
原因：只有完成三次握手，客户端才能向服务器发送 HTTP 的 GET 请求（封堵必须在应用层完成）。若不放通三次握手，连接无法建立，设备就无法捕获到包含目标 URL 的应用层数据，也就无法准确识别需要封堵的网站，后续的封堵操作（如发送 302 重定向报文和 RST 包）便无从谈起。
4.HTTP控制技术原理
1. 主动拦截：302重定向
流程：
用户发送GET请求（含违规Host字段）。
设备伪装成目标服务器，向客户端发送 302重定向响应。
源IP = 目标网站IP（欺骗客户端）
内容：跳转到拒绝页面（如
http://10.1.3.40/disable.htm）。
客户端自动加载拒绝页面，显示管控提示。
技术关键：
伪造数据包的IP标识（IP.ID =
0x5826）用于设备识别自身发出的包。
2. 与普通防火墙的区别
| 控制方式 | 传统防火墙 | HTTP深度控制 |
|---|---|---|
| 层级 | 网络层（IP/端口） | 应用层（HTTP内容） |
| 动作 | 丢弃或允许数据包 | 伪造响应欺骗客户端 |
| 效果 | 连接超时 | 显示定制化拒绝页面 |
3.配置思路
数据包单向经过设备时，无法有效控制，核心逻辑是 “控制依赖双向交互的完整信息” 。
不管是 HTTP 封堵、HTTPS 拦截，还是其他应用控制，本质是 “识别请求→回包干预→断开连接” 的完整流程：
- 设备先 “看到” 客户端发的请求（比如 HTTP 的 GET 包、HTTPS 的 Client Hello 包 ）；
- 基于请求识别应用 / 网站，再伪装服务器发 “拒绝包”（HTTP 发 302 重定向，HTTPS 发 RST ）；
- 最后发 RST 包断开连接，让客户端无法继续访问。
但这一切的前提是：设备能同时 “看到请求” 和 “回包给客户端” ，也就是需要 双向的数据包交互 。
三、HTTPS识别控制技术
1.需求背景
2.HTTPS简介
3.HTTPS握手过程
【前提】客户端发起连接：TCP 三次握手（为 HTTPS 铺路）
终端要访问 HTTPS 网站（比如
https://www.baidu.com），得先和服务器完成 TCP 三次握手 ，建立基础的网络连接：
- 客户端发 SYN 包（请求连接），告诉服务器 “我要连你，这是我的初始序列号（ISN）”；
- 服务器回 SYN+ACK 包（同意连接），说 “好的，你的请求我收到了，这是我的 ISN，确认你的序列号”；
- 客户端回 ACK 包（确认连接），说 “收到你的确认，咱们连接建立啦”。
这一步和 HTTP 一样，是所有网络通信的基础。只有 TCP 连接建好，HTTPS 握手才能开始 ，对应 PPT 里 “控制需要放通 TCP 三次握手” 的逻辑 —— 不放通的话，后面啥都干不了。
阶段 1：客户端发起握手（Client Hello）
谁发？ 客户端（浏览器 / APP）
发什么？Client Hello报文，包含 5 类核心信息：
- TLS 版本：客户端支持的最高 TLS 版本（如 TLS 1.3），限制协商范围。
- 加密套件列表：客户端支持的加密算法组合（如
TLS_AES_256_GCM_SHA384），包含密钥交换、对称加密、哈希算法。- 客户端随机数（Client Random）：随机生成的字符串，用于后续生成会话密钥。
- Session ID：若客户端想复用之前的会话（Session Resumption），会带上旧 ID，否则为
0（新会话）。- 压缩算法列表：可选的流量压缩算法（现代 TLS 已弱化，因安全风险）。
目的：告诉服务器 “我支持这些加密方式，想和你安全通信，这是我的初始信息”。
阶段 2：服务器响应握手（Server Hello 系列）
谁发？ 服务器
发什么？ 5 个连续报文，逐步确认握手参数、验证身份：1.
Server Hello
- 选参数：服务器从客户端列表中，选双方兼容的 TLS 版本、加密套件、压缩算法。
- 给随机数：服务器生成
Server Random（另一随机数，用于会话密钥）。- 给 Session ID：若同意复用会话，返回旧 ID；否则给新 ID。
2.
Server Certificate（服务器证书）
- 发证书链：服务器向客户端提供数字证书，包含：
- 域名（如
www.baidu.com）、服务器公钥、有效期、CA 机构签名。- 若启用 双向认证（客户端也需证明身份），这一步只是 “服务器先亮证”。
3.
Client Certificate Request（可选，双向认证时触发）
- 要求客户端证书：若服务器开启双向认证（如银行、企业内网），会要求客户端提供证书，验证 “你是谁”。
- 指定证书类型：告诉客户端 “我接受这些类型的证书（如 RSA、ECDSA）、这些 CA 签发的证书”。
4.
Server Hello Done
- 结束服务器响应：告诉客户端 “我的握手消息发完了，该你回应了”。
阶段 3：客户端回应握手（Client 系列）
谁发？ 客户端
发什么？ 5 个报文（双向认证时更多），完成身份验证、密钥交换：1.
Client Certificate（可选，双向认证时触发）
- 提交客户端证书：若服务器要求双向认证，客户端发送自己的证书（含公钥、身份信息），证明 “我是合法用户”。
2.
Client Key Exchange
- 交换预主密钥：客户端生成
preMasterKey（预主密钥），用 服务器证书的公钥 加密，发给服务器。- 核心逻辑：只有服务器能用 私钥 解密，保证 “预主密钥只有双方知道”。
3.
Certificate Verify（可选，双向认证时触发）
- 证明私钥持有：客户端用自己证书的 私钥，加密 “之前握手消息的哈希值”，发给服务器。
- 服务器验证：用客户端证书的公钥解密，若哈希匹配，说明 “客户端确实持有证书私钥，身份合法”。
4.
Change Cipher Spec
- 启用加密：告诉服务器 “从现在起，我发的消息都用 会话密钥 加密啦”。
5.
Client Finished
- 验证握手完整性：客户端用 会话密钥 加密 “所有握手消息的哈希值”，发给服务器。
- 目的：证明 “握手过程未被篡改，参数协商正确”。
阶段 4：服务器确认握手（Server 收尾）
谁发？ 服务器
发什么？ 2 个报文，完成最终验证：1.
Change Cipher Spec
- 启用加密：告诉客户端 “我也用会话密钥加密消息啦”。
2.
Server Finished
- 验证握手完整性：服务器用 会话密钥 加密 “所有握手消息的哈希值”，发给客户端。
- 客户端验证：解密后对比哈希，若一致，说明 “握手完成，加密信道可用”。
阶段 5：加密通信（真正的 HTTPS 数据传输）
当双方交换
Finished报文并验证通过后，TLS 握手正式完成，进入 应用数据传输阶段：
- 加密规则：所有 HTTP 层数据（GET/POST 请求、响应体），都会用 会话密钥 加密。
- 完整性保护：每个数据包带 MAC（消息认证码），用会话密钥生成，检测 “数据是否被篡改”。
- 通信流程：
- 客户端发 加密的 HTTPS 请求（如获取网页、提交表单）。
- 服务器解密、处理请求，加密 HTTP 响应（如 HTML、JSON 数据）返回。
- 客户端解密响应，渲染页面或执行业务逻辑。
4.HTTPS 识别工作原理
1. Client Hello中的明文字段
核心字段：
Server Name Indication (SNI)作用：客户端在握手初期声明目标域名（如
www.baidu.com）。位置：TLS握手第一阶段（Client Hello扩展字段）。
5.HTTPS控制技术：精准阻断连接
1. 核心原理：伪装RST阻断（Page 46）
控制流程：
设备捕获Client Hello包，提取SNI字段（如
www.taobao.com）。若域名在封堵列表，设备伪装成目标服务器，向客户端发送 TCP RST包。
伪造源IP = 目标服务器IP（如淘宝IP）
特殊标记：IP.ID =
0x5826（标识设备伪造）
客户端收到RST，立即断开TCP连接，无法继续SSL握手。
用户感知：浏览器显示 “连接重置”（如Chrome的ERR_CONNECTION_RESET）。
2. 与HTTP控制的本质区别
| 控制方式 | HTTP | HTTPS |
|---|---|---|
| 识别点 | GET请求的Host字段 | Client Hello的SNI字段 |
| 拦截手段 | 302重定向 + RST | 直接RST断连 |
| 用户界面 | 定制化拒绝页面 | 浏览器默认报错 |
| 加密影响 | 无 | 依赖SNI明文 |
⚠️ 关键限制：HTTPS无法返回自定义拒绝页面（加密信道未建立，无法注入内容）。
⚠️说明：
在 HTTPS 的访问控制里，识别是通过 Client Hello 的 SNI 字段。但由于在 SSL/TLS 握手的初始阶段，虽然 Client Hello 报文里有可供识别的信息（如 SNI 字段 ），然而此时加密信道尚未完全建立好，后续的数据传输通道是加密的。设备无法像在 HTTP 中那样，直接修改传输中的数据包内容来注入自定义的拒绝页面信息。因为一旦设备尝试修改数据包内容，由于加密机制的存在，数据的完整性会被破坏，客户端和服务器之间无法正常完成握手流程，也无法将自定义的拒绝页面信息正确呈现给用户 。（自定义拒绝页面信息需要在通信连接建立后，通过 HTTP 或 HTTPS 协议传输给客户端进行显示）所以，设备只能直接发送 RST 包断开连接，用户端看到的就是浏览器原生的报错信息，而不是像 HTTP 控制那样能展示定制化的拒绝页面。
6.配置思路
❓HTTPS网站不能正常封堵，应该如何排查？
❓HTTPS网站和HTTP网站封堵的相同点和不同点？
四、 自定义应用识别技术
1.自定义应用方法
2.自定义应用思路
3.URL自定义思路
4.对象自定义总结
❓上网权限策略排查思路
核心目标：解决“策略不生效”问题（如该封堵的未封堵）
分步深度排查：
部署模式验证（最高优先级）
关键问题：是否旁路部署？
检测方法：
# 检查设备部署模式 show running-config | include deploy-mode
影响：旁路模式仅能控制 TCP 应用（如 HTTP），无法管控 UDP 或加密流量
解决方案：切换为网桥/网关模式
用户在线状态核查
关键命令：
# 查看目标用户是否在线 display firewall session table | include 192.168.1.100
隐藏问题：用户可能通过 VPN/4G 绕行
规则库更新检查
三库联动验证：
规则库 更新命令（示例） 影响范围 应用识别库 update app-dbIM/P2P/流媒体等识别 URL分类库 update url-db网站分类管控 审计规则库 update audit-db敏感行为识别 最佳实践：设置定时更新任务（每周一凌晨）
策略关联与优先级
经典错误：多条策略冲突
排查工具：
# 查看用户关联策略及优先级 display user-policy-binding 192.168.1.100
优先级规则：从上至下匹配，第一条命中即生效
全局干扰项排查
两大杀手：
直通模式：临时放行所有流量（测试后未关闭）
show system troubleshoot-mode # 检查直通状态
全局排除地址：配置错误导致目标 IP 被放行
show global-exclude-address # 检查排除列表
应用识别验证
黄金操作：关联全审计策略 → 分析内置数据中心日志
日志分析重点：
识别到的应用名是否准确（如将钉钉识别为“其他加密流量”）
流量是否被错误分类（如淘宝流量被标记为“未知应用”）
流量绕行检测
终极验证：在用户 PC 执行路由跟踪
tracert www.taobao.com # 确认是否经过AC设备IP
典型绕行场景：
双网卡（有线+WiFi）
代理/VPN 软件
❓审计策略排查思路
核心目标：解决“审计记录缺失”问题
分步深度排查：
审计策略基础配置
必查项：
是否勾选 “应用审计”？
是否选择具体审计内容（如文件传输/网页访问）？
经典错误：启用策略但未选择审计类型
用户策略匹配验证
操作路径：
# 查看在线用户策略匹配情况 display online-user detail user@domain.com
输出关键项：
Matched Audit Policy: Yes/No
加密流量特殊处理
HTTPS/加密邮件审计要求：
必须启用 SSL 内容识别
show ssl-decrypt policy # 检查解密策略
目标域名必须加入解密列表
客户端必须信任设备 CA 证书
全局排除地址干扰
排查命令：
show global-exclude-address | include 192.168.1.100
影响：被排除地址不会产生任何日志
时间范围陷阱
场景：查询 “今天” 日志但数据中心时区错误
解决方案：
# 校准设备与数据中心时区 display clock # 查看设备时间 display log-server timezone # 查看日志服务器时区
❓准入策略排查思路
核心目标：解决“终端无法上网”或“策略不执行”问题
分步深度排查：
全局干扰项优先排查
必查两项：
bash
show system troubleshoot-mode # 直通模式 show global-exclude-address # 全局排除
影响：直通模式下所有准入策略失效
终端兼容性验证
不支持场景：
非 Windows 设备（Mac/Linux/手机）
Windows Server 操作系统
精简版 WinPE 系统
检测方法：
# 查看终端类型（需终端安装Agent） display endpoint type 192.168.1.100
用户在线与区域匹配
关键命令：
# 检查用户是否在线及策略匹配 display准入-user-status 192.168.1.100
输出分析：
Policy Applied: Yes/NoMatch Location: Office-WiFi（需与策略区域一致）
自定义准入规则诊断
经典错误：进程名匹配错误
# 查看进程识别结果 display endpoint-process 192.168.1.100
进程名规范：
带后缀：
chrome.exe（非chrome）大小写敏感：
Teams.exe≠teams.exe
动作配置：检查 “允许/拒绝” 动作是否设反
)
)
