一、 應用特征識別技術

1.傳統行為檢測技術

1.1?五元組檢測原理

1.2 配置思路

1.3 效果展示

需求背景2

1.4 傳統行為檢測的缺陷

2.深度行為檢測技術

2.1 產生原因

• 核心問題：

  • 傳統技術無法識別精細的數據包應用和行為，無法識別經過偽裝的數據包，無法滿足現在的安全需求和可視需求。

• 解決方案：深度行為檢測分為兩類：

  • DPI（深度包檢測）：解析應用層內容。

  • DFI（深度流檢測）：分析流量行為模式。

2.2 深度行為檢測技術有點

2.3?DPI（深度包檢測）

1.?基于特征字的檢測技術

• 原理：通過匹配數據包應用層的特征字符串識別應用。

• 優勢：支持協議擴展（更新特征庫即可識別新應用）。

2.基于應用層網關的檢測技術

• 原理：

  1. 先解析控制流（如VoIP的H.245信令）。

  2. 從中提取數據流信息（如IP、端口）。

3.基于行為模式的檢測

• 原理：通過分析用戶行為頻率而非協議內容識別應用。

• 優勢：適用于加密流量或協議無特征的場景。

2.4?DFI技術（深度流檢測）

1.?原理

• 分析流量行為特征（非內容）：

  • 包長度、連接速率、會話持續時間等。

2.5?DPI vs DFI對比

二、 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重定向

• 流程：

  1. 用戶發送GET請求（含違規Host字段）。

  2. 設備偽裝成目標服務器，向客戶端發送?302重定向響應。

     • 源IP = 目標網站IP（欺騙客戶端）

     • 內容：跳轉到拒絕頁面（如?http://10.1.3.40/disable.htm）。

  3. 客戶端自動加載拒絕頁面，顯示管控提示。

• 技術關鍵：

  • 偽造數據包的IP標識（IP.ID =?0x5826）用于設備識別自身發出的包。

2.?與普通防火墻的區別

3.配置思路

數據包單向經過設備時，無法有效控制，核心邏輯是?“控制依賴雙向交互的完整信息”?。

不管是 HTTP 封堵、HTTPS 攔截，還是其他應用控制，本質是?“識別請求→回包干預→斷開連接”?的完整流程：

1. 設備先 “看到” 客戶端發的請求（比如 HTTP 的 GET 包、HTTPS 的 Client Hello 包 ）；
2. 基于請求識別應用 / 網站，再偽裝服務器發 “拒絕包”（HTTP 發 302 重定向，HTTPS 發 RST ）；
3. 最后發 RST 包斷開連接，讓客戶端無法繼續訪問。

但這一切的前提是：設備能同時 “看到請求” 和 “回包給客戶端”?，也就是需要?雙向的數據包交互?。

三、HTTPS識別控制技術

1.需求背景

2.HTTPS簡介

3.HTTPS握手過程

【前提】客戶端發起連接：TCP 三次握手（為 HTTPS 鋪路）

終端要訪問 HTTPS 網站（比如?https://www.baidu.com?），得先和服務器完成?TCP 三次握手?，建立基礎的網絡連接：

1. 客戶端發?SYN 包（請求連接），告訴服務器 “我要連你，這是我的初始序列號（ISN）”；
2. 服務器回?SYN+ACK 包（同意連接），說 “好的，你的請求我收到了，這是我的 ISN，確認你的序列號”；
3. 客戶端回?ACK 包（確認連接），說 “收到你的確認，咱們連接建立啦”。

這一步和 HTTP 一樣，是所有網絡通信的基礎。只有 TCP 連接建好，HTTPS 握手才能開始?，對應 PPT 里 “控制需要放通 TCP 三次握手” 的邏輯 —— 不放通的話，后面啥都干不了。

階段 1：客戶端發起握手（Client Hello）

誰發？?客戶端（瀏覽器 / APP）
發什么？?Client Hello?報文，包含 5 類核心信息：

1. TLS 版本：客戶端支持的最高 TLS 版本（如 TLS 1.3），限制協商范圍。
2. 加密套件列表：客戶端支持的加密算法組合（如?TLS_AES_256_GCM_SHA384），包含密鑰交換、對稱加密、哈希算法。
3. 客戶端隨機數（Client Random）：隨機生成的字符串，用于后續生成會話密鑰。
4. Session ID：若客戶端想復用之前的會話（Session Resumption），會帶上舊 ID，否則為?0（新會話）。
5. 壓縮算法列表：可選的流量壓縮算法（現代 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）

• 控制流程：

  1. 設備捕獲Client Hello包，提取SNI字段（如?www.taobao.com）。

  2. 若域名在封堵列表，設備偽裝成目標服務器，向客戶端發送?TCP RST包。

     • 偽造源IP = 目標服務器IP（如淘寶IP）

     • 特殊標記：IP.ID =?0x5826（標識設備偽造）

  3. 客戶端收到RST，立即斷開TCP連接，無法繼續SSL握手。

• 用戶感知：瀏覽器顯示?“連接重置”（如Chrome的ERR_CONNECTION_RESET）。

2.?與HTTP控制的本質區別?

???關鍵限制：HTTPS無法返回自定義拒絕頁面（加密信道未建立，無法注入內容）。

??說明：

在 HTTPS 的訪問控制里，識別是通過 Client Hello 的 SNI 字段。但由于在 SSL/TLS 握手的初始階段，雖然 Client Hello 報文里有可供識別的信息（如 SNI 字段 ），然而此時加密信道尚未完全建立好，后續的數據傳輸通道是加密的。設備無法像在 HTTP 中那樣，直接修改傳輸中的數據包內容來注入自定義的拒絕頁面信息。因為一旦設備嘗試修改數據包內容，由于加密機制的存在，數據的完整性會被破壞，客戶端和服務器之間無法正常完成握手流程，也無法將自定義的拒絕頁面信息正確呈現給用戶 。（自定義拒絕頁面信息需要在通信連接建立后，通過 HTTP 或 HTTPS 協議傳輸給客戶端進行顯示）所以，設備只能直接發送 RST 包斷開連接，用戶端看到的就是瀏覽器原生的報錯信息，而不是像 HTTP 控制那樣能展示定制化的拒絕頁面。

6.配置思路

?HTTPS網站不能正常封堵，應該如何排查？

?HTTPS網站和HTTP網站封堵的相同點和不同點？

四、 自定義應用識別技術

1.自定義應用方法

2.自定義應用思路

3.URL自定義思路

4.對象自定義總結

?上網權限策略排查思路

核心目標：解決“策略不生效”問題（如該封堵的未封堵）

分步深度排查：

1. 部署模式驗證（最高優先級）

   • 關鍵問題：是否旁路部署？

   • • 檢測方法：

       # 檢查設備部署模式
       show running-config | include deploy-mode

     • 影響：旁路模式僅能控制?TCP 應用（如 HTTP），無法管控 UDP 或加密流量

     • 解決方案：切換為網橋/網關模式

   • 用戶在線狀態核查

     • 關鍵命令：

       # 查看目標用戶是否在線
       display firewall session table | include 192.168.1.100

     • 隱藏問題：用戶可能通過 VPN/4G 繞行

   • 規則庫更新檢查

     • 三庫聯動驗證：

       規則庫	更新命令（示例）	影響范圍
       應用識別庫	update app-db	IM/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 軟件

?審計策略排查思路

核心目標：解決“審計記錄缺失”問題

分步深度排查：

1. 審計策略基礎配置

   • 必查項：

     • 是否勾選?“應用審計”？

     • 是否選擇具體審計內容（如文件傳輸/網頁訪問）？

   • 經典錯誤：啟用策略但未選擇審計類型

2. 用戶策略匹配驗證

   • 操作路徑：

     # 查看在線用戶策略匹配情況
     display online-user detail user@domain.com

   • 輸出關鍵項：Matched Audit Policy: Yes/No

3. 加密流量特殊處理

   • HTTPS/加密郵件審計要求：

     • 必須啟用?SSL 內容識別

       show ssl-decrypt policy  # 檢查解密策略

     • 目標域名必須加入解密列表

     • 客戶端必須信任設備 CA 證書

4. 全局排除地址干擾

   • 排查命令：

     show global-exclude-address | include 192.168.1.100

   • 影響：被排除地址不會產生任何日志

5. 時間范圍陷阱

   • 場景：查詢 “今天” 日志但數據中心時區錯誤

   • 解決方案：

     # 校準設備與數據中心時區
     display clock  # 查看設備時間
     display log-server timezone  # 查看日志服務器時區

?準入策略排查思路

核心目標：解決“終端無法上網”或“策略不執行”問題

分步深度排查：

1. 全局干擾項優先排查

   • 必查兩項：

     bash

     show system troubleshoot-mode  # 直通模式
     show global-exclude-address    # 全局排除

   • 影響：直通模式下所有準入策略失效

2. 終端兼容性驗證

   • 不支持場景：

     • 非 Windows 設備（Mac/Linux/手機）

     • Windows Server 操作系統

     • 精簡版 WinPE 系統

   • 檢測方法：

     # 查看終端類型（需終端安裝Agent）
     display endpoint type 192.168.1.100

3. 用戶在線與區域匹配

   • 關鍵命令：

     # 檢查用戶是否在線及策略匹配
     display準入-user-status 192.168.1.100

   • 輸出分析：

     • Policy Applied: Yes/No

     • Match Location: Office-WiFi（需與策略區域一致）

4. 自定義準入規則診斷

   • 經典錯誤：進程名匹配錯誤

     # 查看進程識別結果
     display endpoint-process 192.168.1.100

   • 進程名規范：

     • 帶后綴：chrome.exe（非?chrome）

     • 大小寫敏感：Teams.exe?≠?teams.exe

   • 動作配置：檢查 “允許/拒絕” 動作是否設反