使用安全Web裝置最佳做法
簡介
本文檔介紹配置思科安全網路裝置(SWA)的最佳實踐。
背景資訊
本指南旨在作為最佳做法配置的參考，它涉及SWA部署的多個方面。它包括支援的網路環境、策略配置、監控和故障排除。雖然記錄的最佳實踐對於所有管理員、架構師和操作員來說都是重要的，但是它們只是指導方針，必須這樣對待。每個網路都有其自身的具體要求和挑戰。
作為安全裝置，SWA以幾種獨特的方式與網路互動。它既是網路流量的源也是目標。它與Web伺服器和Web客戶端同時運行。它至少使用伺服器端IP地址欺騙和中間人技術來檢查HTTPS事務。它可以偽裝客戶端IP地址，這會增加部署的另一層複雜性，並對支援網路配置提出額外要求。本指南解決與網路裝置配置相關的最常見問題。
SWA策略配置不僅影響安全效能和實施，而且影響裝置的效能。本指南詳細介紹配置的複雜性如何影響系統資源。它定義了此環境中的複雜性，並描述了如何在策略設計中將其最小化。此外，還提到了特定功能，以及必須如何配置這些功能以提高安全性、可擴充性和有效性。
本文檔的監控和警報部分介紹了監控裝置、效能和可用性以及系統資源使用情況的最有效方法。它還提供基本故障排除的資訊。
網路環境
ICMP
路徑MTU探索(如RFC 1191所定義)機制可確定沿任意路徑的資料包的最大大小。透過IPv4，裝置可以在封包的IP標頭中設定不分段(DF)位元，藉此判斷路徑上任何封包的最大傳輸單位(MTU)。如果路徑沿途的某個連結上的裝置無法轉送封包而不進行分段，則會將所需的網際網路控制訊息通訊協定(ICMP)分段（型別3，代碼4）訊息傳送回來源。然後使用者端重新傳送較小的封包。此過程會一直持續，直到找到完整路徑的MTU。IPv6不支援分段，並且使用「資料包過大（型別2）」ICMPv6消息表示無法通過給定鏈路容納資料包。
由於封包分段程式可能會對TCP資料流的效能產生嚴重影響，因此SWA會利用路徑MTU探索。必須在相關網路裝置中啟用提到的ICMP消息，以允許SWA確定其通過網路路徑的MTU。通過在CLI中運行pathmtudiscovery 命令，可以在SWA中禁用此行為。執行此操作會導致預設MTU下降至576位元組（根據RFC 879），嚴重影響了效能。管理員還必須執行其他步驟，以便通過etherconfig CLI命令在SWA中手動配置MTU。
在網路快取通訊協定(WCCP)的情況下，網路流量會從另一個網路裝置沿著使用者端路徑重新導向到SWA，目的地為網際網路。使用其他通訊協定（例如ICMP），這些指令不會重新導向到SWA。SWA可能會觸發來自網路路由器的ICMP需要分段消息。但是，該消息不會傳送到SWA。如果網路中有可能出現這種情況，必須禁用路徑MTU發現。如前所述，使用此配置，需要在CLI中運行etherconfig命令，在SWA上手動設定MTU的附加步驟。
防火牆
在預設配置中，代理連線時，SWA不會欺騙客戶端IP地址。這表示所有出站Web流量均源自SWA IP地址。您必須確保網路地址轉換(NAT)裝置具有足夠大的外部地址池和埠來容納此功能。為此，最好指定特定地址。
某些防火牆採用拒絕服務(DoS)保護或其他安全功能，當大量併發連線源自單個客戶端IP地址時觸發這些功能。如果未啟用客戶端IP欺騙，則必須將SWA IP地址排除在這些保護之外。
單點傳送反向路徑轉送
當SWA與客戶端通訊時，SWA欺騙伺服器IP地址，並且可選地可以配置為當它與上游伺服器通訊時欺騙客戶端IP地址。可在交換器上啟用單點傳送反向路徑轉送(uRPF)等保護，以確保傳入封包與預期輸入連線埠相符。這些保護根據路由表檢查資料包的源介面，以確保它到達預期的埠。SWA必須在適當情況下免於這些保護。
使用WCCP進行IP欺騙
當SWA中啟用IP欺騙功能時，出站請求離開裝置時會使用原始客戶端請求的源地址。這需要對相關網路基礎設施進行額外配置，以確保返回的資料包路由到SWA出站介面，而不是發出請求的客戶端。
在網路裝置（路由器、交換機或防火牆）上實施WCCP時，會定義一個服務ID，該服務ID根據訪問控制清單(ACL)匹配流量。 然後服務ID應用於介面，並用於匹配流量以進行重定向。如果啟用IP欺騙，則必須建立第二個服務ID，以確保返回的流量也重定向到SWA。
SWA網路配置
介面
SWA具有五個可用的網路介面：M1、P1、P2、T1和T2。在可能的情況下，必須將這些選項分別用於其特定用途。由於自身的原因使用每個埠是有益的。M1介面必須連線到專用管理網路，並且必須啟用分割路由以限制管理服務的洩露。P1可以限於客戶端請求流量，不允許P2接受顯式代理請求。這減少了每個介面上的流量數量，並可以在網路設計中更好地進行分段。
T1和T2連線埠可用於第4層流量監控器(L4TM)功能。這將監控映象的第2層埠，並根據已阻止的已知惡意IP地址和域名清單來阻止流量。它通過檢視流量的來源和目的地IP位址來完成此操作，並傳送TCP重設封包或連線埠無法連線訊息（如果封鎖的清單相符）。使用此功能可以阻止使用任何協定傳送的流量。
即使L4TM功能未啟用，當T1和T2連線埠連線到映象連線埠時，也可增強透明旁路。在WCCP的情況下，SWA只知道傳入資料包的源和目標IP地址，必須決定代理該資料包，或基於該資訊繞過該資料包。SWA每30分鐘解析一次旁路設定清單中的任何條目，而不管記錄的「生存時間(TTL)」。 但是，如果已啟用L4TM功能，則SWA可以使用已監聽的DNS查詢更頻繁地更新這些記錄。這降低了客戶端解析了與SWA不同的地址的情況下出現誤報的風險。
管理網路路由
如果專用管理網路不能訪問Internet，則可以將每項服務配置為使用資料路由表。可以定製此拓撲以適應網路拓撲，但一般情況下，建議對所有系統服務使用管理網路，對客戶端流量使用資料網路。自AsyncOS版本11.0起，可以設定路由的服務包括：
- DNS
- Active Directory
- 外部URL源
- 更新和升級
- 進階惡意軟體防護(AMP)檔案信譽和分析
對於管理流量的其他出口過濾，可以配置靜態地址以用於以下服務：
外部URL源：
1.自定義；取決於它們託管在哪裡。
2. AMP檔案信譽和分析。
3.cloud-sa.amp.cisco.com（北美）。
4.cloud-sa.eu.amp.cisco.com（歐洲）。
5.cloud-sa.apjc.amp.cisco.com（亞太）。
更新和升級：
1.downloads-static.ironport.com
2.updates-static.ironport.com
TALOS遙測
Cisco Talos Group以識別新的和新興的威脅而聞名。所有傳送到Talos的資料都是匿名的，並儲存在美國資料中心。參與SensorBase可增強對Web威脅的分類和識別，從而更好地保護SWA和其他思科安全解決方案。
DNS
域名伺服器(DNS)安全最佳實踐建議每個網路必須託管兩個DNS解析程式：一個用於本地域內的權威記錄，另一個用於遞迴解析Internet域。為了適應此情況，SWA允許為特定域配置DNS伺服器。如果只有一個DNS伺服器可用於本地查詢和遞迴查詢，請考慮在用於所有SWA查詢時它增加的額外負載。較好的選擇是使用本地域的內部解析程式和外部域的根Internet解析程式。這取決於管理員的風險設定和容差。
預設情況下，無論記錄的TTL如何，SWA都會快取DNS記錄至少30分鐘。大量使用內容交付網路(CDN)的現代網站的TTL記錄較低，因為其IP地址經常更改。這可能會導致客戶端快取給定伺服器的IP地址，並且SWA快取同一伺服器的不同地址。為了解決此問題，SWA預設TTL可以從以下CLI命令降低到五分鐘：
SWA_CLI> dnsconfig
...
Choose the operation you want to perform:
- NEW - Add a new server.
- EDIT - Edit a server.
- DELETE - Remove a server.
- SETUP - Configure general settings.
- SEARCH - Configure DNS domain search list.
[]> SETUP
...
Enter the minimum TTL in seconds for DNS cache.
...
如果主伺服器不可用，則必須配置輔助DNS伺服器。如果所有伺服器都配置了相同的優先順序，則會隨機選擇伺服器IP。根據配置的伺服器數，給定伺服器的超時值可能有所不同。下表為最多六台DNS伺服器的查詢超時：
| DNS伺服器數量 | 查詢超時（按順序） |
| 1 | 60 |
| 2 | 5、45 |
| 3 | 5、10、45 |
| 4 | 1、3、11、45 |
| 5 | 1、3、11、45、1 |
| 6 | 1、3、11、45、1、1 |
只有通過CLI才能使用高級DNS選項。這些選項在CLI中可通過運行advanced proxyconfig > DNS命令來獲得。
選擇以下選項之一：
- 0 — 始終按順序使用DNS應答
- 1 — 先使用客戶端提供的地址，再使用DNS
- 2 — 有限的DNS使用
- 3 -DNS使用非常有限
- 對於選項1和2，如果啟用Web信譽，則使用DNS。
- 對於選項2和3,DNS用於顯式代理請求。如果沒有上游代理，或者配置的上游代理發生故障。
- 對於所有選項，在策略成員身份中使用目標IP地址時使用DNS。
這些選項控制SWA在評估客戶端請求時如何決定要連線的IP地址。收到請求後，SWA將看到目標IP地址和主機名。SWA必須決定是否信任TCP連線的原始目標IP地址，還是完成自己的DNS解析並使用已解析的地址。預設值為「0 =始終按順序使用DNS答案」，這表示SWA不信任客戶端提供IP地址。
- 選項1 - SWA嘗試連線由客戶端提供的IP地址，但如果失敗，則回退到解析地址。解析的地址用於策略評估(Web類別、Web信譽等)。
- 選項2 - SWA僅使用客戶端提供的地址進行連線，不會回退。解析的地址用於策略評估（Web類別、Web信譽等）。
- 選項3 - SWA僅使用客戶端提供的地址進行連線，不會回退。客戶端提供的IP地址用於策略評估（Web類別、Web信譽等）。
所選擇的選項取決於管理員在確定給定主機名的解析地址時必須給予客戶端的信任程度。如果使用者端是下游代理，請選擇選項3以避免不必要的DNS查詢增加延遲。
負載平衡
當使用最多八台裝置時，WCCP允許透明流量負載均衡。它允許根據雜湊或掩碼平衡流量，如果網路中混合了裝置模型，則可以進行加權，並且可以在不停機的情況下新增/刪除服務池中的裝置。使用8個SWA或更多時，建議使用專用負載平衡器。
WCCP配置的最佳實踐因使用的平台而異。對於Cisco Catalyst®交換機，最佳實踐記錄在Cisco Catalyst Instant Access Solution白皮書中。
WCCP在與Cisco Adaptive Security Appliance(ASA)配合使用時存在限制。 也就是說，不支援客戶端IP欺騙。此外，客戶端和SWA必須位於同一介面之後。因此，使用第4層交換器或路由器來重新導向流量會更靈活。ASA平台上的WCCP配置在ASA上的WCCP中描述：概念、限制和配置。
對於顯式部署，代理自動配置(PAC)檔案是部署最廣泛的方法，但是它的缺點和安全影響超出了本文檔的範圍。如果部署了PAC檔案，建議使用組策略對象(GPO)配置位置，而不是依賴Web代理自動發現協定(WPAD),WPAD是攻擊者的常見目標，如果配置錯誤，很容易被利用。SWA可以託管多個PAC檔案並在瀏覽器的快取中控制其過期。
可以通過可配置的TCP埠號（預設情況下為9001）直接從SWA請求PAC檔案。 如果沒有指定埠，請求可以像出站Web請求一樣傳送到代理進程本身。在這種情況下，可以根據請求中存在的HTTP主機標頭為特定PAC檔案提供服務。
在高可用性(HA)環境中使用時，Kerberos的配置必須不同。SWA支援keytab檔案，從而允許多個主機名與服務原則名稱(SPN)關聯。 有關詳細資訊，請參閱在Windows Active Directory中建立服務帳戶，以在高可用性部署中進行Kerberos身份驗證。
主動驗證
與NT LAN Manager安全支援提供程式(NTLMSSP)相比，Kerberos更安全，並且廣泛支援身份驗證協定。 Apple OS X作業系統不支援NTLMSSP，但是，如果域已加入，則它可以使用Kerberos進行身份驗證。不能使用基本身份驗證，因為它在HTTP報頭中傳送未加密的憑據，並且很容易被網路上的攻擊者嗅探。如果必須使用基本身份驗證，則必須啟用憑據加密以確保通過加密隧道傳送憑據。
必須將多個域控制器新增到配置以確保可用性，但是此流量沒有固有的負載平衡。SWA將TCP SYN資料包傳送到所有已配置的域控制器，第一個響應資料包用於身份驗證。
在authentication settings頁面中配置的重定向主機名確定將透明客戶端傳送到何處以完成身份驗證。要使Windows客戶端完成整合身份驗證並實現單點登入(SSO)，重定向主機名必須位於Internet選項控制面板中的「受信任的站點」區域。Kerberos協定要求使用完全限定域名(FQDN)來指定資源，這意味著，如果Kerberos是預期的身份驗證機制，則不能使用「短名稱」（或「NETBIOS」名稱）。需要將FQDN手動新增到受信任的站點（例如，通過組策略）。 此外，還必須在Internet選項控制面板中設定使用使用者名稱和密碼的自動登入(Automatic login with username and password)。
瀏覽器需要在Firefox中進行其他設定，才能使用網路代理完成身份驗證。可以在about:config頁面中配置這些設定。要成功完成Kerberos，必須將重定向主機名新增到network.negotiate-auth.trusted-uri選項。對於NTLMSSP，必須將其新增到network.automatic-ntlm-auth.trusted-uris選項中。
身份驗證完成後，身份驗證代理用於記住經過身份驗證的使用者的設定持續時間。必須儘可能使用IP代理來限制發生的主動身份驗證事件的數量。主動驗證客戶端是一項資源密集型任務，在使用Kerberos時尤其如此。代理超時預設情況下為3600秒（1小時），可以減少，但建議的最低值為900秒（15分鐘）。
此圖顯示「redirect.WSA.lab」如何用作重定向主機名：
被動驗證
SWA可以利用其他思科安全平台被動地識別代理使用者。被動使用者識別消除了身份驗證提示和直接Active Directory通訊。這將減少延遲和裝置資源使用量。當前可用的被動身份驗證機制是通過上下文目錄代理(CDA)、身份服務引擎(ISE)和身份服務聯結器被動身份聯結器(ISE-PIC)。
ISE是一種功能豐富的產品，可幫助管理員集中其身份驗證服務，並利用廣泛的網路訪問控制。當ISE獲知使用者身份驗證事件（通過Dot1x身份驗證或Web身份驗證重定向）時，它會填充包含有關身份驗證中涉及的使用者和裝置的資訊的會話資料庫。SWA通過平台交換網格(pxGrid)連線到ISE，並獲取與代理連線關聯的使用者名稱、IP地址和安全組標籤(SGT)。自AsyncOS版本11.7以來，SWA還可以查詢ISE上的外部Restful服務(ERS)以獲取組資訊。
建議版本為ISE 3.1和SWA 14.0.2-X及更高版本。有關SWA的ISE相容性矩陣的詳細資訊，請參閱安全Web裝置的ISE相容性矩陣。有關完全整合步驟的詳細資訊，請參閱網路安全裝置最終使用手冊。
思科宣佈Cisco Context Directory Agent(CDA)軟體的生命週期終止，請參閱Cisco Context Directory Agent(CDA)。
從CDA補丁6開始，這與Microsoft Server 2016相容。但是，我們積極鼓勵管理員將其CDA部署遷移到ISE-PIC。兩種解決方案都使用WMI來訂閱Windows安全事件日誌以生成使用者到IP的對映（稱為「會話」）。 對於CDA，SWA查詢對映為RADIUS。
對於ISE-PIC，在完整ISE部署中使用相同的pxGrid和ERS連線。ISE-PIC功能在完整ISE安裝和獨立虛擬裝置中可用。
服務配置
Web代理
必須在Web代理配置中啟用快取，以節省頻寬並提高效能。隨著HTTPS流量百分比的增加，這一點變得不那麼重要，因為SWA在預設情況下不快取HTTPS事務。如果將代理部署為僅服務於顯式客戶端，則必須指定轉發模式以拒絕任何未明確定向到代理服務的流量。這樣，裝置攻擊面就會減少，而且最佳做法也會到位（如果不需要就會將其關閉）。
HTTP請求中使用範圍請求標頭來指定要下載的檔案的位元組範圍。它通常由作業系統和應用程式更新守護程式用於一次傳輸檔案的小部分。預設情況下，SWA會刪除這些報頭，以便獲取整個檔案，用於防病毒(AV)掃描、檔案信譽和分析以及應用可視性控制(AVC)。 通過在代理設定中全域性啟用範圍請求報頭的轉發，管理員可以建立轉發或剝離這些報頭的單獨訪問策略。有關此配置的更多資訊，請參見Access Policies一節。
HTTPS代理
安全最佳實踐建議，必須在使用私鑰的裝置上生成私鑰，並且不得將其傳送到其他位置。HTTPS代理嚮導允許建立用於解密傳輸層安全(TLS)連線的金鑰對和證書。憑證簽署請求(CSR)可以下載並由內部憑證授權單位(CA)簽署。 在Active Directory(AD)環境中，這是最佳方法，因為AD整合的CA自動受域所有成員的信任，並且不需要其他步驟來部署證書。
HTTPS代理的一個安全功能是驗證伺服器證書。最佳實踐建議無效證書要求斷開連線。啟用Decrypt for EUN允許SWA顯示塊頁，解釋塊的原因。如果未啟用此功能，則任何被阻止的HTTPS站點都會導致瀏覽器錯誤。這會增加幫助台票證，並且使用者部分會認為某些內容已損壞，而不是SWA已阻止連線。所有無效的證書選項都必須至少設定為Decrypt。如果將其中任何選項設定為Monitor ，則不允許系統在證書問題阻止載入站點時記錄有用的錯誤消息。
與線上證書服務協定(OCSP)類似，必須啟用檢查且不能將監控用於任何選項。必須丟棄吊銷的證書，並且所有其他證書必須至少設定為「解密」，以允許記錄相關錯誤消息。授權資訊訪問追蹤（AIA追蹤）是客戶端可以收集證書的簽名者以及可以獲取其他證書的URL的位置。
例如，如果從伺服器接收的證書鏈不完整（如果缺少中間或根證書），則SWA可以檢查AIA欄位並使用該欄位獲取缺少的證書並驗證真實性。此設定僅在CLI中從以下命令可用：
SWA_CLI> advancedproxyconfig
Choose a parameter group:
- AUTHENTICATION - Authentication related parameters
- CACHING - Proxy Caching related parameters
- DNS - DNS related parameters
- EUN - EUN related parameters
- NATIVEFTP - Native FTP related parameters
- FTPOVERHTTP - FTP Over HTTP related parameters
- HTTPS - HTTPS related parameters
- SCANNING - Scanning related parameters
- PROXYCONN - Proxy connection header related parameters
- CUSTOMHEADERS - Manage custom request headers for specific domains
- MISCELLANEOUS - Miscellaneous proxy related parameters
- SOCKS - SOCKS Proxy parameters
- CONTENT-ENCODING - Block content-encoding types
- SCANNERS - Scanner related parameters
[]> HTTPS
...
Do you want to enable automatic discovery and download of missing Intermediate Certificates?
[Y]>
...
附註：此設定預設處於啟用狀態，不得禁用。許多現代伺服器依賴此機製為客戶端提供完全信任鏈。
第4層流量監控器(L4TM)
L4TM是將SWA的覆蓋範圍擴展到包括不通過Proxy的惡意流量，以及包括所有TCP和UDP埠上的流量的高效方式。T1和T2埠應連線到網路分路器或交換機監控會話。這允許SWA被動地監控來自客戶端的所有流量。如果發現發往惡意IP地址的流量，SWA可以在欺騙伺服器IP地址的同時通過傳送RST來終止TCP會話。若是UDP流量，它可傳送連線埠無法連線訊息。配置監控會話時，最好排除任何目的地為SWA管理介面的流量，以避免該功能可能干擾對裝置的訪問。
除了監控惡意流量外，L4TM還會監聽DNS查詢以更新繞過設定清單。此清單用於WCCP部署，用於將某些請求返回到WCCP路由器，以便直接路由到Web伺服器。代理不會處理與旁路設定清單匹配的資料包。清單可以包含IP地址或伺服器名稱。SWA每30分鐘解析一次旁路設定清單中的任何條目，無論記錄的TTL如何。但是，如果已啟用L4TM功能，則SWA可以使用已監聽的DNS查詢更頻繁地更新這些記錄。這降低了客戶端解析了與SWA不同的地址的情況下出現誤報的風險。
策略配置
正確的策略配置對於SWA的效能和可擴充性至關重要。有效的策略可保護客戶端並強制實施公司要求。但是，策略配置也會影響資源使用、裝置運行狀況和效能。複雜或設計欠佳的策略會導致不穩定和響應速度緩慢
複雜性
在制訂全部門辦法政策時採用了各種政策要素。從配置生成的XML檔案用於建立大量後端配置檔案和訪問規則。配置越複雜，代理進程必須花費更多時間來評估每個事務的各種規則集。在設定基準和調整SWA規模時，會建立一組基本策略要素，這些要素代表配置複雜性的三個層次。 低複雜性的配置包括10個身份配置檔案、解密策略、訪問策略和自定義類別（包含10個regex條目、50個伺服器IP和420個主機名）。 將這些值加倍或三倍會導致中或高複雜性的配置。
當配置變得過於複雜時，最初的症狀通常包括Web介面和CLI響應緩慢。一開始不會對使用者造成重大影響。但是，配置越複雜，代理進程在使用者模式下必須花費的時間就越長。因此，檢查此模式花費的時間百分比有助於將過於複雜的配置診斷為SWA緩慢的原因。
CPU時間（以秒為單位）每5分鐘記錄在track_stats日誌中。這意味著使用者時間百分比可以計算為（使用者時間+系統時間）/300。隨著使用者時間接近270，該進程在使用者模式下花費了過多的CPU週期，這通常是因為配置太複雜而無法高效地分析。
附註：SWA的最大限制是60,000個併發客戶端連線和60,000個併發伺服器連線。
標識配置檔案
標識(ID)配置檔案是在接收新請求時評估的第一策略元素。在ID配置檔案第一部分配置的所有資訊都將使用邏輯AND進行評估。這意味著所有條件必須匹配，請求才能與配置檔案匹配。建立策略時，策略必須儘可能具體，絕對必要。包含單個主機地址的配置檔案很少需要，而且可能會導致配置蔓延。利用HTTP標頭、自定義類別清單或子網中的使用者代理字串通常是限制配置檔案範圍的更好策略。
通常，需要身份驗證的策略配置在底部，而例外新增在頂部。在對不需要身份驗證的策略進行排序時，最常用的策略必須儘可能最接近頂部。不要依賴失敗的身份驗證來限制訪問。如果網路上的已知客戶端無法向代理進行身份驗證，則必須在訪問策略中免除身份驗證並阻止該客戶端。無法重複進行身份驗證的客戶端向SWA傳送未經身份驗證的請求，SWA使用資源並可能導致CPU和記憶體使用過度。
管理員普遍存在的一個誤解是，必須有一個唯一的ID配置檔案以及相應的解密和訪問策略。對於策略配置而言，這種策略效率很低。如有可能，策略必須被「摺疊」，以便單個ID配置檔案可以與多個解密和訪問策略相關聯。這可以確保給定策略中的所有條件必須相互匹配（流量和策略都匹配）。 一般而言，身份驗證策略和生成的策略總體上允許使用的策略較少。
解密策略
與ID配置檔案一樣，解密策略中設定的條件被評估為邏輯AND，但使用ISE中的資訊時有一個重要例外。這是策略匹配的工作方式，具體取決於配置的元素（AD組、使用者或SGT）：
- AD組和使用者 — 不改變以前的行為；如果使用者是組的成員，或者使用者在策略中指定，則匹配該策略。
- SGT和AD組和使用者 — 如果使用者與SGT關聯並且是AD組的成員，或者使用者在策略中指定，則匹配策略。
- SGT和使用者 — 如果使用者與SGT關聯或在策略中指定使用者，則匹配策略。
在SWA執行的服務中，從效能角度而言，對HTTPS流量的評估最為重要。已解密流量的百分比對裝置的大小有直接影響。管理員可以指望至少75%的網路流量是HTTPS。
初始安裝後，必須確定解密流量的百分比，以確保準確設定對未來增長的預期。部署後，必須每季度檢查一次此編號。使用access_logs的副本，即使沒有額外的日誌管理軟體，也可通過SWA輕鬆查詢已解密HTTPS流量的百分比。可使用運行簡單的Bash或PowerShell命令來獲取此數字。以下是適用於每個環境的一些範例命令：
1. Linux命令：
cat aclog.current | grep -Ev "\/407|\/401" | awk 'BEGIN { total=0; decrypt=0; ssl=0;} {total++; if($0 ~ "TCP_CONNECT .*\:443| CONNECT tunnel") ssl++; if($0 ~ "DECRYPT") decrypt++; } END {if(total==0 && ssl==0) exit; print "Total: " total; print "SSL: " ssl; print "Decrypt: " decrypt; print "Percentage (DECRYPT/SSL)..: " (decrypt/ssl)*100.0 "%"; print "Percentage (DECRYPT/TOTAL)..: " (decrypt/total)*100.0 "%";}'2. PowerShell命令：
$lines = Get-Content -Path "aclog.current" | Where-Object { $_ -notmatch "/407|/401" }; $total = 0; $decrypt = 0; $ssl = 0; $lines | ForEach-Object { $total++; if ($_ -match "TCP_CONNECT .*:443| CONNECT tunnel") { $ssl++ }; if ($_ -match "DECRYPT") { $decrypt++ } }; if ($total -ne 0 -or $ssl -ne 0) { Write-Output "Total: $total"; Write-Output "SSL: $ssl"; Write-Output "Decrypt: $decrypt"; if ($ssl -ne 0) { $percentageDecryptSSL = ($decrypt / $ssl) * 100.0; Write-Output "Percentage (DECRYPT/SSL)..: $percentageDecryptSSL%" }; if ($total -ne 0) { $percentageDecryptTotal = ($decrypt / $total) * 100.0; Write-Output "Percentage (DECRYPT/TOTAL)..: $percentageDecryptTotal%" } }設計解密策略時，必須瞭解策略中列出的各種操作如何導致裝置評估HTTPS連線。當必須允許客戶端和伺服器終止其TLS會話的每一端而沒有SWA解密每個資料包時，會使用直通操作。即使站點設定為通過，也必須要求SWA與伺服器完成一次TLS握手。SWA必須選擇根據證書有效性阻止連線，並且必須啟動與伺服器的TLS連線以獲取證書。如果證書有效，SWA將關閉連線，並允許客戶端繼續直接與伺服器建立會話。
SWA不執行任何TLS握手的唯一情況是伺服器名稱或IP地址存在於自定義類別中。該選項設定為passthrough，並且伺服器名稱在HTTP CONNECT或TLS客戶端Hello中可用。在顯式方案中，客戶端在TLS會話發起之前將伺服器的主機名提供給Proxy（在主機標頭中），因此會根據自定義類別檢查此欄位。
在透明部署中，SWA檢查TLS客戶端Hello消息中的「伺服器名稱指示」(SNI)欄位，並根據自定義類別評估該欄位。如果主機標頭或SNI不存在，SWA必須繼續與伺服器握手，以檢查證書上的Subject Alternative Name(SAN)和Common Name(CN)欄位（按此順序）。
要減少TLS握手的數量，請將受信任的伺服器設定為從自定義類別清單傳遞。與Web類別或信譽評分（仍需要SWA才能完成TLS握手）不同，這會繞過完全握手，但會阻止證書有效性檢查。
鑑於新站點在網上出現的速度，可能會發現許多站點未被SWA使用的Web信譽和分類資料庫分類。這並不意味著站點更可能是惡意站點，所有這些站點仍會受到AV掃描、AMP檔案信譽和分析以及任何對象阻止的影響。出於這些原因，建議不要刪除未分類的站點（大多數情況下）。 最好將這些內容設定為由AV引擎解密和掃描，並由AVC、AMP、訪問策略等進行評估。有關未分類站點的詳細資訊，請參閱訪問策略部分。
訪問策略
與ID配置檔案一樣，解密策略中設定的條件也作為邏輯AND進行計算，當使用ISE中的資訊時，有一個重要例外。策略匹配行為根據配置的元素（AD組、使用者或SGT）進行說明：
- AD組和使用者 — 如果使用者是組的成員，或者使用者在策略中指定，則不會更改以前的行為，因為策略已匹配。
- SGT和AD組和使用者 — 如果使用者與SGT關聯並且是AD組的成員，或者使用者在策略中指定，則匹配策略。
- SGT和使用者 — 如果使用者與SGT關聯，則匹配該策略，或者在策略中指定使用者。
HTTP流量在經過身份驗證後立即根據訪問策略進行評估。HTTPS流量在經過身份驗證後進行評估，並且如果根據匹配的解密策略應用了解密操作。對於已解密的請求，存在兩個access_log條目。第一個日誌條目顯示應用於初始TLS連線（解密）的操作，第二個日誌條目顯示訪問策略應用於解密HTTP請求的操作。
如Web代理一節所述，範圍請求報頭用於請求檔案的特定位元組範圍，通常由作業系統和應用程式更新服務使用。預設情況下，SWA從出站請求中刪除這些報頭，因為如果沒有整個檔案，就不可能執行惡意軟體掃描或利用AVC功能。如果網路中的許多主機頻繁請求小位元組範圍來檢索更新，則可能會觸發SWA同時下載整個檔案數次。這會快速耗儘可用的Internet頻寬並導致服務中斷。導致此故障情況的最常見原因是Microsoft Windows更新和Adobe軟體更新守護程式。
要緩解這一情況，最佳解決方案是完全控制SWA周圍的流量。這對於透明部署的環境並非總是可行的，在這些情況下，下一個最佳選項是為流量建立專用訪問策略，並在這些策略上啟用範圍請求報頭轉發。您必須考慮這些請求不能進行AV掃描和AVC，並且策略必須設計為僅針對目標流量。實現此目標的最佳方法是匹配請求標頭中的使用者代理字串。可以線上找到常見更新守護程式的使用者代理字串，或者由管理員捕獲並檢查請求。大多數更新服務（包括Microsoft Windows和Adobe軟體更新）未使用HTTPS。
如「解密策略」部分所述，不建議刪除解密策略中未分類的站點。出於同樣的原因，建議不要在訪問策略中阻止它們。動態內容分析(Dynamic Content Analysis， DCA)引擎可以使用給定網站的內容，以及其他啟發式資料來分類站點，這些站點將通過URL資料庫查詢進行未分類標籤。啟用此功能可減少SWA中未分類裁決的數量。
訪問策略的對象掃描設定可以檢查多種型別的歸檔檔案。如果網路在應用程式更新過程中定期下載歸檔檔案，則啟用歸檔檔案檢查會顯著增加CPU使用率。如果要檢查所有已存檔檔案，必須提前豁免和識別此流量。首先調查識別流量的可能方法的是使用者代理字串，因為這樣有助於避免可能變得繁瑣維護的IP允許清單。
自定義和外部URL類別
自定義類別清單用於按IP地址或主機名標識伺服器。可以使用正規表示式(regex)指定伺服器名稱匹配的模式。使用regex模式匹配伺服器名稱比使用子字串匹配更耗費資源。這必須僅在必要時使用。一個「。」 可以新增到域名的開頭，以便與子域匹配，而無需使用regex。
例如，「.cisco.com」也匹配「www.cisco.com」。 如「複雜性」部分所述，低複雜性定義為10個自定義類別清單，中等複雜性定義為20，而高複雜性定義為30。建議將此數字保持在20以下，尤其是當清單使用正規表示式模式或包含大量條目時。請參閱「訪問策略」部分，以瞭解有關每種型別的條目數量的其他詳細資訊。
外部URL源比靜態自定義類別清單更靈活，利用這些源可能會對安全性產生直接影響，因為它們不再需要管理員手動維護這些源。此功能可用於檢索不由SWA管理員維護或控制的清單，AsyncOS版本11.8引入了將單個例外新增到下載地址的功能。
Office365 API有助於針對此常見部署的服務制定策略，並可用於各個應用程式（PowerPoint、Skype、Word等）。 Microsoft建議繞過所有Office365流量的代理以最佳化效能。Microsoft文檔說明：
注意：「雖然SSL Break和Inspect產生的延遲最大，但代理身份驗證和信譽查詢等其他服務可能導致效能降低和使用者體驗不良。此外，這些外圍網路裝置需要足夠的容量來處理所有網路連線請求。我們建議繞過代理或檢查裝置來獲得直接Office 365網路請求。」 欲知更多資訊，請訪問：管理Microsoft 365終端。
從AsyncOS版本11.8開始，您可以使用從Office365 API檢索的動態類別清單來填充旁路設定清單。此清單用於將重新導向流量傳送回WCCP裝置以進行直接路由，但是在透明的代理環境中很難使用此指南。
繞過所有Office365流量會為需要一些基本安全控制和流量報告的管理員建立盲點。如果SWA沒有繞過Office365流量，瞭解可能產生的具體技術挑戰就非常重要。其中之一是應用程式所需的連線數。必須適當調整大小，以適應Office365應用程式所需的額外TCP連線。這會將每個使用者的10%-15%持續TCP會話之間的總連線數增加。
HTTPS代理執行的解密和重新加密操作會為連線帶來少量延遲。Office365應用程式對延遲很敏感，如果廣域網連線速度慢和地理位置分散等其他因素影響很大，使用者體驗可能會受到影響。
某些Office365應用程式使用專有的TLS引數，這些引數會阻止HTTPS代理與應用程式伺服器完成握手。驗證證書或檢索主機名時需要執行此操作。如果與Skype for Business等應用程式結合使用，則不會在TLS客戶端Hello消息中傳送伺服器名稱指示(SNI)欄位，您必須完全繞過此流量。AsyncOS v11.8引入了隻根據目標IP地址繞過流量，而不進行證書檢查來解決此情況的功能。
監控器和警報
CLI監控器
SWA CLI提供即時監控重要進程的命令。一些有用的命令顯示與代理進程相關的統計資訊。運行status detail命令是資源使用情況和效能指標（包括正常運行時間、使用的頻寬、響應延遲、連線數等）摘要的良好來源。
以下是輸出範例：
SWA_CLI> status detail
Status as of: Fri Nov 11 14:06:52 2022 +03
Up since: Fri Apr 08 10:15:00 2022 +03 (217d 3h 51m 52s)
System Resource Utilization:
CPU 3.3%
RAM 6.2%
Reporting/Logging Disk 45.6%
Transactions per Second:
Average in last minute 55
Maximum in last hour 201
Average in last hour 65
Maximum since proxy restart 1031
Average since proxy restart 51
Bandwidth (Mbps):
Average in last minute 4.676
Maximum in last hour 327.258
Average in last hour 10.845
Maximum since proxy restart 1581.297
Average since proxy restart 11.167
Response Time (ms):
Average in last minute 635
Maximum in last hour 376209
Average in last hour 605
Maximum since proxy restart 2602943
Average since proxy restart 701
Cache Hit Rate:
Average in last minute 0
Maximum in last hour 2
Average in last hour 0
Maximum since proxy restart 15
Average since proxy restart 0
Connections:
Idle client connections 186
Idle server connections 184
Total client connections 3499
Total server connections 3632
SSLJobs:
In queue Avg in last minute 4
Average in last minute 45214
SSLInfo Average in last min 94
Network Events:
Average in last minute 0.0
Maximum in last minute 35
Network events in last min 124502運行rate命令會顯示有關prox進程使用的CPU百分比的即時資訊、每秒請求數(RPS)和快取統計資訊。此命令將繼續輪詢和顯示新輸出，直到中斷。以下是輸出範例：
SWA_CLI> rate
Press Ctrl-C to stop.
%proxy reqs client server %bw disk disk
CPU /sec hits blocks misses kb/sec kb/sec saved wrs rds
5.00 51 1 147 370 2283 2268 0.6 48 37
4.00 36 0 128 237 21695 21687 0.0 47 38
4.00 48 2 179 307 8168 8154 0.2 65 33
5.00 53 0 161 372 2894 2880 0.5 48 32
6.00 52 0 198 328 15110 15100 0.1 63 33
6.00 77 0 415 363 4695 4684 0.2 48 34
7.00 85 1 417 433 5270 5251 0.4 49 35
7.00 67 1 443 228 2242 2232 0.5 85 44運行tcpservices命令會顯示有關所選進程偵聽埠的資訊。系統還會顯示每個進程、地址和埠組合的說明：
SWA_CLI> tcpservices
System Processes (Note: All processes may not always be present)
ftpd.main - The FTP daemon
ginetd - The INET daemon
interface - The interface controller for inter-process communication
ipfw - The IP firewall
slapd - The Standalone LDAP daemon
sntpd - The SNTP daemon
sshd - The SSH daemon
syslogd - The system logging daemon
winbindd - The Samba Name Service Switch daemon
Feature Processes
coeuslogd - Main WSA controller
gui - GUI process
hermes - Mail server for sending alerts, etc.
java - Processes for storing and querying Web Tracking data
musd - AnyConnect Secure Mobility server
pacd - PAC file hosting daemon
prox - WSA proxy
trafmon - L4 Traffic Monitor
uds - User Discovery System (Transparent Auth)
wccpd - WCCP daemon
COMMAND USER TYPE NODE NAME
connector root IPv4 TCP 127.0.0.1:8823
java root IPv6 TCP [::127.0.0.1]:18081
hybridd root IPv4 TCP 127.0.0.1:8833
gui root IPv4 TCP 172.16.40.80:8443
ginetd root IPv4 TCP 172.16.40.80:ssh
nginx root IPv6 TCP *:4431
nginx root IPv4 TCP 127.0.0.1:8843
nginx nobody IPv6 TCP *:4431
nginx nobody IPv4 TCP 127.0.0.1:8843
nginx nobody IPv6 TCP *:4431
nginx nobody IPv4 TCP 127.0.0.1:8843
api_serve root IPv4 TCP 172.16.40.80:6080
api_serve root IPv4 TCP 127.0.0.1:60001
api_serve root IPv4 TCP 172.16.40.80:6443
chimera root IPv4 TCP 127.0.0.1:6380
nectar root IPv4 TCP 127.0.0.1:6382
redis-ser root IPv4 TCP 127.0.0.1:6383
redis-ser root IPv4 TCP 127.0.0.1:6379
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:25255
prox root IPv4 TCP 127.0.0.1:socks
prox root IPv6 TCP [::1]:socks
prox root IPv4 TCP 172.16.11.69:socks
prox root IPv4 TCP 172.16.11.68:socks
prox root IPv4 TCP 172.16.11.252:socks
prox root IPv4 TCP 127.0.0.1:ftp-proxy
prox root IPv6 TCP [::1]:ftp-proxy
prox root IPv4 TCP 172.16.11.69:ftp-proxy
prox root IPv4 TCP 172.16.11.68:ftp-proxy
prox root IPv4 TCP 172.16.11.252:ftp-proxy
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:25256
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.21.11.69:https
prox root IPv4 TCP 172.21.11.68:https
prox root IPv4 TCP 172.21.11.252:https
prox root IPv4 TCP 127.0.0.1:25257
smart_age root IPv6 TCP [::127.0.0.1]:65501
smart_age root IPv6 TCP [::127.0.0.1]:28073
interface root IPv4 TCP 127.0.0.1:domain
stunnel root IPv4 TCP 127.0.0.1:32137日誌記錄
Web流量具有高度動態性和多樣性。代理部署完成後，定期重新評估通過裝置的流量數量和構成非常重要。您必須定期檢查解密流量的百分比（每季度一次），以確保大小與初始安裝的預期和規格一致。這可以通過高級網路安全報告(AWSR)等日誌管理產品或者帶有訪問日誌的Bash或PowerShell命令來完成。必須定期重新評估RPS的數量，以確保裝置有足夠的開銷來應對高可用性、負載平衡配置中流量激增和可能的故障切換。
track_stats日誌每五分鐘附加一次，其中包含多個與記憶體中的prox進程及其對象直接相關的輸出部分。在效能監控中，平均延遲請求進程包括DNS查詢時間、AV引擎掃描時間等都是一些有用的欄位。無法從GUI或CLI配置此日誌，並且只能通過安全複製協定(SCP)或檔案傳輸協定(FTP)訪問。 這是進行效能故障排除時需要的重要日誌，因為它必須經常輪詢。
每個SHD日誌行每60秒寫入一次，其中包含對效能監控重要的欄位，包括延遲、RPS、客戶端和伺服器端連線總數。以下是SHD日誌行的示例：
Fri Nov 11 14:16:42 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 62 Band 11383 Latency 619 CacheHit 0 CliConn 3817 SrvConn 3804 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:17:42 2022 Info: Status: CPULd 2.6 DskUtil 45.7 RAMUtil 6.7 Reqs 55 Band 10532 Latency 774 CacheHit 0 CliConn 3546 SrvConn 3539 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:18:43 2022 Info: Status: CPULd 1.9 DskUtil 45.7 RAMUtil 6.6 Reqs 48 Band 7285 Latency 579 CacheHit 0 CliConn 3418 SrvConn 3410 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:19:43 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.6 Reqs 52 Band 34294 Latency 791 CacheHit 0 CliConn 3605 SrvConn 3586 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:20:43 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 55 Band 8696 Latency 691 CacheHit 0 CliConn 3455 SrvConn 3432 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:21:43 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.7 Reqs 49 Band 7064 Latency 1403 CacheHit 0 CliConn 3339 SrvConn 3330 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:22:43 2022 Info: Status: CPULd 1.9 DskUtil 45.7 RAMUtil 6.8 Reqs 41 Band 5444 Latency 788 CacheHit 0 CliConn 3227 SrvConn 3212 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:23:43 2022 Info: Status: CPULd 2.2 DskUtil 45.7 RAMUtil 6.8 Reqs 48 Band 6793 Latency 820 CacheHit 0 CliConn 3280 SrvConn 3265 MemBuf 1 SwpPgOut 250467 ProxLd 3 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:24:44 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.7 Reqs 44 Band 8735 Latency 673 CacheHit 0 CliConn 3405 SrvConn 3389 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:25:44 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 53 Band 8338 Latency 731 CacheHit 0 CliConn 3637 SrvConn 3622 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0可以向access_logs新增其他自定義欄位，這些欄位表示單個請求的延遲資訊。這些欄位包括伺服器響應、DNS解析和AV掃描器延遲。必須將這些欄位新增到日誌中，以收集重要的故障排除資訊。這是建議使用的自定義欄位字串：
[ Request Details: ID = %I, User Agent = %u, AD Group Memberships = ( %m ) %g ] [ Tx Wait Times (in ms): 1st byte to server = %:<1, Request Header = %:, Response Header = %:h>, Client Body = %:b> ] [ Rx Wait Times (in ms): 1st request byte = %:1<, Request Header = %:h<, Client Body = %:b<, 1st response byte = %:>1, Response header = %:>h, Server response = %:>b, Disk Cache = %:>c; Auth response = %:a; DNS response = %:d, WBRS response = %:r, AVC response = %:A>, AVC total = %:A<, DCA response = %:C>, DCA total = %:C<, McAfee response = %:m>, McAfee total = %:m<, Sophos response = %:p>, Sophos total = %:p<, Webroot response = %:w>, Webroot total = %:w<, Anti-Spyware response = %:s, AMP response = %:e>, AMP total = %:e<; Latency = %x; %L ][Client Port = %F, Server IP = %k, Server Port = %p] 下表列出了從這些值匯出的效能資訊：
| 自定義欄位 | 說明 |
| %:<a | Web代理傳送請求後，等待從Web代理身份驗證進程接收響應的時間。 |
| %:<b | 在標頭之後將請求正文寫入伺服器的等待時間。 |
| %:<d | Web代理傳送請求後，等待從Web代理DNS進程接收響應的時間。 |
| %:<h | 在第一個位元組之後將請求報頭寫入伺服器的等待時間。 |
| %:<r | Web代理傳送請求後，等待從Web信譽過濾器接收響應的時間。 |
| %:<s | 在Web代理傳送請求後，從Web代理反間諜軟體進程接收判定結果的等待時間。 |
| %:> | 等待伺服器第一個響應位元組的時間。 |
| %:>a | 等待時間以接收來自Web代理身份驗證進程的響應。包括Web代理傳送請求所需的時間。 |
| %:>b | 收到標頭後等待完整響應正文的時間。 |
| %:>c | Web代理從磁碟快取讀取響應所需的時間。 |
| %:>d | 從Web代理DNS進程接收響應的等待時間。包括Web代理傳送請求所需的時間。 |
| %:>h | 第一個響應位元組之後的伺服器報頭的等待時間。 |
| %:>r | 從Web信譽過濾器接收裁決結果的等待時間。包括Web代理傳送請求所需的時間。 |
| %:>s | 等待時間以接收來自Web代理反間諜軟體進程的裁決。包括Web代理傳送請求所需的時間。 |
| %:1< | 等待新客戶端連線的第一個請求位元組的時間。 |
| %:1> | 寫入客戶端的第一個位元組的等待時間。 |
| %:b< | 等待完整的客戶端正文。 |
| %:b> | 將完整正文寫入客戶端的等待時間。 |
| %:e> | Web代理傳送請求後，等待從AMP掃描引擎接收響應的時間。 |
| %:e< |
等待時間以接收來自AMP掃描引擎的判定結果。包括Web代理傳送請求所需的時間。 |
| %:h< | 第一個位元組之後的完整客戶端報頭等待時間。 |
| %:h> | 寫入客戶端的完整報頭等待時間。 |
| %:m< | 等待時間以接收McAfee掃描引擎的判定結果。包括Web代理傳送請求所需的時間。 |
| %:m> | 等待時間以接收來自McAfee掃描引擎的響應。在Web代理傳送要求後。 |
| %F | 客戶端源埠。 |
| %p | 網路伺服器埠。 |
| %k | 資料來源IP地址（Web伺服器IP地址）。 |
| %:w< | 從Webroot掃描引擎接收判定結果的等待時間。包括Web代理傳送請求所需的時間。 |
| %:w> | 等待時間以接收來自webroot掃描引擎的響應。在Web代理傳送要求後。 |
SWA許可模式允許對虛擬裝置重複使用物理裝置許可證。您可以利用此優勢並部署測試SWAv裝置，以便在實驗室環境中使用。可以試用新功能和配置，以確保穩定性和可靠性，而不違反許可條款。
進階網路安全報告(AWSR)
必須利用AWSR來確保SWA的報告資料，尤其是在部署了許多SWA的環境中。與利用安全管理裝置(SMA)上的集中報告相比，此解決方案更具可擴充性，並提供自定義報告屬性，為資料新增深度和自定義。可以對報告進行分組和自定義，以滿足任何組織的需求。在確定AWSR的規模時必須使用Cisco Advanced Services Group。
電子郵件警報
SWA內建的電子郵件警報系統最好用作基本警報系統。必須對其進行適當調整以滿足管理員的需要，因為如果所有資訊性事件都處於啟用狀態，可能會引起噪音。限制警報並主動監視這些警報非常重要，與將所有警報都警報並忽略為垃圾郵件的警報相比更為重要。
| 警報設定 | 組態 |
| 傳送警報時要使用的發件人地址 | 自動生成 |
| 傳送重複警報之前等待的初始秒數 | 300秒 |
| 傳送重複警報之前等待的最大秒數 | 3600秒 |
可用性監控
有兩種方法可用於監控Web代理的可用性。
- 第一個是第3層(L3)監控，用於測試網路上是否可以訪問裝置IP地址。測試此情況的最簡單方法是定期向位址傳送ICMP回應(ping)要求，並檢查回覆封包。可以分析應答的屬性（如TTL和延遲）以確定網路層的運行狀況。
- 裝置可能對ping有響應，但代理進程沒有響應或間歇性中斷。如果發生這種情況，建議新增第7層(L7)監控器，該監控器會向裝置傳送顯式代理請求，並需要200 OK HTTP響應代碼。這測試網路介面的可達性、代理服務的響應性，以及在請求外部資源時上游服務的可行性。此類監控通常採用請求代理連線到資源的顯式HTTP HEAD請求的形式。HEAD方法請求返回報頭，客戶端必須傳送GET請求。這僅包括沒有資料的響應報頭。
- 如果您使用L7監控工具或指令碼，請確保流量免於身份驗證。否則將導致身份驗證失敗和資源消耗。在監控工具中使用自定義使用者代理字串時，必須使用該字串來識別流量。雖然流量無需進行身份驗證，但通過訪問策略仍可限制其不必要地訪問Internet。
當您使用其中一種或多種方法時，管理員必須圍繞代理響應建立可接受度量的基準，並使用該基準構建警報閾值。
SNMP監控
簡單網路管理協定(SNMP)是監控裝置運行狀況的主要方法。它可用於接收來自裝置的警報（陷阱），或輪詢各種對象識別符號(OID)以收集資訊。SWA上有許多OID詳細說明了各個流程和統計資訊的硬體到資源使用情況。
出於硬體和效能相關原因，必須監控許多特定的電腦資訊庫(MIB)。請參閱MIB的完整清單。
以下是建議監控的MIB清單：
| 硬體OID | 名稱 |
| 1.3.6.1.4.1.15497.1.1.1.18.1.3 | raidID |
| 1.3.6.1.4.1.15497.1.1.1.18.1.2 | raid狀態 |
| 1.3.6.1.4.1.15497.1.1.1.18.1.4 | raidLastError |
| 1.3.6.1.4.1.15497.1.1.1.10 | 風扇表 |
| 1.3.6.1.4.1.15497.1.1.1.9.1.2 | 攝氏度 |
這些OID直接對映到status detail CLI命令的輸出：
| OID | 名稱 | 狀態詳細資訊欄位 |
| 系統資源 | ||
| 1.3.6.1.4.1.15497.1.1.1.2.0 | 百分之CPU利用率 | CPU |
| 1.3.6.1.4.1.15497.1.1.1.1.0 | 記憶體利用率百分比 | RAM |
| 每秒交易數 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.1.1.0 | cacheThruputNow | 最後一分鐘每秒平均事務數。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.2.0 | cacheThruput1hrPeak | 上一小時每秒的最大事務數。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.3.0 | cacheThruput1hrMean | 上一小時每秒平均事務數。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.8.0 | cacheThruputLifePeak | 代理重新啟動後每秒最大事務數。 |
| 1.3.6.1.4.1.15497.1.2.3.7.1.9.0 | cacheThruLifeMean | 代理重新啟動後每秒平均事務數。 |
| 頻寬 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.4.1.0 | cacheBwidthTotalNow | 最後一分鐘的平均頻寬。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.2.0 | cacheBwidthTotal1hrPeak | 過去一小時內的最大頻寬。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.3.0 | cacheBwidthTotal1hrMean | 過去一小時內的平均頻寬。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.8.0 | cacheBwidthTotalLifePeak | 自代理重新啟動以來的最大頻寬。 |
| 1.3.6.1.4.1.15497.1.2.3.7.4.9.0 | cacheBwidthTotalLifeMean | 代理重新啟動後的平均頻寬。 |
| 響應時間 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.9.1.0 | cacheHitsNow | 上一分鐘的平均快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.2.0 | cacheHits1hrPeak | 上一小時的最大快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.3.0 | cacheHits1hrMean | 過去一小時內的平均快取記憶體命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.8.0 | cacheHits生命峰值 | 自代理重新啟動以來的最大快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.9.0 | cacheHits生命平均值 | 自代理重新啟動以來的平均快取命中率。 |
| 快取命中率 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.5.1.0 | cacheHitsNow | 上一分鐘的平均快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.2.0 | cacheHits1hrPeak | 上一小時的最大快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.3.0 | cacheHits1hrMean | 過去一小時內的平均快取記憶體命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.8.0 | cacheHits生命峰值 | 自代理重新啟動以來的最大快取命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.9.0 | cacheHits生命平均值 | 自代理重新啟動以來的平均快取命中率。 |
| 連線 | ||
| 1.3.6.1.4.1.15497.1.2.3.2.7.0 | cacheClientIdleConns | 空閒客戶端連線。 |
| 1.3.6.1.4.1.15497.1.2.3.3.7.0 | cacheServerIdleConns | 空閒伺服器連線。 |
| 1.3.6.1.4.1.15497.1.2.3.2.8.0 | cacheClientTotalConns | 客戶端連線總數。 |
| 1.3.6.1.4.1.15497.1.2.3.3.8.0 | cacheServerTotalConns | 伺服器連線總數。 |
有用連結
- 為安全Web裝置配置防火牆
- 瞭解安全Web裝置訪問日誌
- 在Vmware Esxi上安裝安全Web裝置
- 在Microsoft Hyper-V上安裝安全網路裝置
- 在兩個SWA之間遷移配置
- 將Secure Web Appliance還原為先前版本
- 在Secure Web裝置中配置備份
- 在SWA中配置Active Directory身份驗證
- 在SWA中配置Kerberos單一登入身份驗證
- 繞過安全Web裝置中的身份驗證
- 在SWA中阻止執行檔下載
- 在SWA中配置Microsoft O365租戶限制
- 繞過安全Web裝置中的Microsoft更新流量
- 在SWA中啟用特定的YouTube頻道/影片並阻止YouTube的其餘部分
- 在Secure Web Appliance中配置自定義URL類別
- 在Secure Web裝置中配置上游代理
- 在SWA中配置SNMP並對其進行故障排除
- 對安全Web裝置DNS服務進行故障排除
- 在內容安全裝置上配置資料包捕獲
- 訪問安全Web裝置日誌
- 配置訪問日誌中的效能引數
- 使用SHD日誌排除安全Web裝置效能故障
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
5.0 |
16-Jul-2026
|
已更新拼寫、語法、句子結構、簡介、插入行以分隔各個部分/可讀性、固定CCW警報和固定URL。 |
4.0 |
25-Sep-2024
|
初始版本 |
1.0 |
10-Apr-2023
|
初始版本 |
意見