使用安全Web设备最佳实践
简介
本文档介绍如何配置思科安全网络设备(SWA)的最佳实践。
背景信息
本指南旨在作为最佳实践配置的参考，它涉及SWA部署的很多方面，包括支持的网络环境、策略配置、监控和故障排除。虽然此处记录的最佳实践对于所有管理员、架构师和操作员来说都是非常重要的，但是它们只是指导原则，因此必须进行处理。每个网络都有自己的具体要求和挑战。
作为安全设备，SWA以几种独特的方式与网络进行交互。它既是网络流量的源也是目标；同时充当Web服务器和Web客户端。它至少使用服务器端IP地址欺骗和中间人技术来检查HTTPS事务。它还可以伪装客户端IP地址，这会增加部署的另一层复杂性，并对支持网络配置提出额外要求。本指南解决有关网络设备配置的最常见问题。
SWA策略配置不仅会影响安全效力和实施，还会影响设备的性能。本指南介绍配置的复杂性如何影响系统资源。它定义了此环境中的复杂性，并描述了如何在策略设计中将其最小化。此外，还关注特定功能以及如何配置它们来提高安全性、可扩展性和有效性。
本文档的监控和警报部分介绍了监控设备的最有效方法；还包括监控性能和可用性以及系统资源使用情况。它还提供了对基本故障排除非常有用的信息。
网络环境
ICMP
路径MTU发现(如RFC 1191中所定义)，该机制确定沿任意路径的数据包的最大大小。对于IPv4，设备可以通过在数据包的IP报头中设置不分段(DF)位来确定路径中任何数据包的最大传输单位(MTU)。如果在路径沿途的某个链路上，设备无法转发数据包而不对其进行分段，则会向源设备发送一条Internet Control Message Protocol(ICMP)Fragmentation Needed(Type 3, Code 4)消息。然后，客户端重新发送较小的数据包。此过程会一直持续到发现完整路径的MTU为止。IPv6不支持分段，并且使用Packet Too Big(Type 2)ICMPv6消息表示无法通过给定链路容纳数据包。
由于数据包分段过程会严重影响TCP流的性能，因此SWA使用路径MTU发现。必须在相关网络设备中启用上述ICMP消息，以允许SWA确定其网络路径的MTU。在SWA中使用pathmtudiscovery命令行界面(CLI)命令可禁用此行为。这样做会导致默认MTU下降至576字节（根据RFC 879），严重影响性能。管理员必须执行其他步骤，从SWA手动配置MTU etherconfig CLI命令
在采用Web Cache Communication Protocol(WCCP)时，Web流量会从客户端路径沿互联网从另一网络设备重定向到SWA。在这种情况下，其他协议（例如ICMP）不会重定向到SWA。SWA可能会触发来自网络上路由器的ICMP需要分段消息，但不会将该消息传送到SWA。如果网络中可能存在这种情况，则必须禁用路径MTU发现。如前所述，在此配置中，手动设置SWA上MTU的额外步骤 etherconfig 需要CLI命令。
防火墙
在默认配置中，代理连接时，SWA不会欺骗客户端IP地址。这意味着所有出站Web流量均来自SWA IP地址。必须确保网络地址转换(NAT)设备具有足够大的外部地址池和端口池来满足此要求。为此，最好指定特定地址。
有些防火墙采用拒绝服务(DoS)保护或其他安全功能，当大量并发连接源自单个客户端IP地址时触发这些功能。如果未启用客户端IP欺骗，则必须将SWA IP地址排除在这些保护之外。
单播逆向路径转发
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地址和目标IP地址来达到此目的，并发送TCP重置数据包，或者如果阻止列表匹配，则发送Port Unreachable消息。使用此功能可以阻止通过任何协议发送的流量。
即使L4TM功能未启用，当T1和T2端口连接到镜像端口时，透明旁路也可以增强。对于WCCP，SWA只知道传入数据包的源和目标IP地址，必须决定代理该数据包，或根据该信息绕过它。SWA每30分钟解析一次旁路设置列表中的任何条目，而不管记录的生存时间(TTL)。但是，如果启用L4TM功能，SWA可以使用已监听的DNS查询更频繁地更新这些记录。这降低了客户端解析了与SWA不同的地址时产生误报的风险。
管理网络路由
如果专用管理网络无法访问Internet，可以将每项服务配置为使用数据路由表。这可以定制为适合网络拓扑，但一般而言，建议对所有系统服务使用管理网络，对客户端流量使用数据网络。从AsyncOS版本11.0开始，可以设置路由的服务包括：
- 外部URL源
- 高级恶意软件防护(AMP)文件信誉和分析
- 更新和升级
- DNS
- Active Directory
对于管理流量的其他出口过滤，可以配置静态地址用于以下服务：
- 外部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组以识别新威胁和新兴威胁着称。发送到Talos的所有数据都是匿名的，并存储在美国的数据中心。参与SensorBase可增强对Web威胁的分类和识别，从而更好地保护SWA和其他思科安全解决方案。
DNS
域名服务器(DNS)安全最佳实践建议，每个网络必须托管两个DNS解析器：一个用于本地域内的权威记录，另一个用于互联网域的递归解析。为此，SWA允许为特定域配置DNS服务器。如果只有一个DNS服务器可用于本地查询和递归查询，请考虑在用于所有SWA查询时它添加的额外负载。更好的选择是使用本地域的内部解析程序和外部域的根互联网解析程序。这取决于管理员风险简档和容差。
默认情况下，无论记录的TTL如何，SWA都会缓存DNS记录至少30分钟。大量使用内容交付网络(CDN)的现代网站的TTL记录较低，因为其IP地址经常更改。这可能导致客户端缓存给定服务器的IP地址，而SWA缓存同一服务器的不同地址。为此，可以从以下CLI命令将SWA默认TTL降低到五分钟：
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 |
也有一些高级DNS选项只能通过CLI使用。以下选项在CLI中可用：
advancedproxyconfig > DNS 命令。Select one of these options:
- 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允许透明流量负载均衡。它允许根据散列或掩码平衡流量，如果网络中混合了多种设备型号，可以对其进行加权，并且可以在不停机的情况下向服务池添加和删除设备。一旦需求超出八个SWA所能处理的范围，建议使用专用负载均衡器。
WCCP配置的具体最佳实践因使用的平台而异。对于Cisco Catalyst®交换机，最佳实践记录在Cisco Catalyst即时接入解决方案白皮书中。
WCCP与思科自适应安全设备(ASA)配合使用时存在限制。即不支持客户端IP欺骗，客户端和SWA必须位于同一接口之后。因此，使用第4层交换机或路由器来重定向流量更为灵活。ASA平台上的WCCP配置在ASA上的WCCP：概念、限制和配置中进行了说明。
对于显式部署，代理自动配置(PAC)文件是部署最广泛的方法，但它有许多缺点和安全影响不在本文档的讨论范围之内。如果部署了PAC文件，建议使用组策略对象(GPO)配置位置，而不是依赖Web代理自动发现协议(WPAD),WPAD是攻击者的常见目标，如果配置错误，很容易被利用。SWA可以托管多个PAC文件并在浏览器的缓存中控制其过期。
PAC文件可以直接从SWA从可配置的TCP端口号（默认为9001）请求。如果未指定端口，请求可以像出站Web请求一样发送到代理进程本身。在这种情况下，可以根据请求中存在的HTTP主机报头为特定PAC文件提供服务。
在高可用性环境中使用时，Kerberos的配置必须不同。SWA提供对keytab文件的支持，从而允许多个主机名与服务原则名称(SPN)关联。有关详细信息，请参阅在Windows Active Directory中创建服务帐户以在高可用性部署中进行Kerberos身份验证。
主动身份验证
与NT LAN Manager安全支持提供程序(NTLMSSP)相比，Kerberos更为安全且受到广泛支持的身份验证协议。Apple OS X操作系统不支持NTLMSSP，但是如果域已加入，则可以使用Kerberos进行身份验证。不能使用基本身份验证，因为它在HTTP报头中发送未加密的凭证，并且很容易被网络上的攻击者嗅探。如果必须使用基本身份验证，则必须启用凭证加密，以确保通过加密隧道发送凭证。
必须将多个域控制器添加到配置以确保可用性，但是此流量没有固有的负载均衡。SWA将TCP SYN数据包发送到所有已配置的域控制器，第一个响应数据包用于身份验证。
在身份验证设置页面中配置的“重定向主机名”确定透明客户端的发送位置以完成身份验证。要使Windows客户端完成集成身份验证并实现单点登录(SSO)，重定向主机名必须位于“Internet选项”控制面板中的“受信任站点”区域。Kerberos协议要求使用完全限定域名(FQDN)指定资源，这意味着，如果Kerberos是预期的身份验证机制，则不能使用“短名称”（或“NETBIOS”名称）。需要将FQDN手动添加到“受信任的站点”（例如，通过组策略）。此外，必须在“Internet选项”控制面板中设置“使用用户名和密码自动登录”。
Firefox中还需要其他设置，浏览器才能使用网络代理完成身份验证。这些设置可在about:config页面中配置。要成功完成Kerberos，必须将重定向主机名添加到network.negotiate-auth.trusted-uris选项。对于NTLMSSP，必须将其添加到network.automatic-ntlm-auth.trusted-uris选项。
身份验证代理用于在完成身份验证后的一段设置时间内记住经过身份验证的用户。必须尽可能使用IP代理来限制发生的主动身份验证事件的数量。主动对客户端进行身份验证是一项资源密集型任务，尤其是使用Kerberos时。代理超时默认情况下为3600秒（1小时），可以减少，但建议的最低值为900秒（15分钟）。
此图显示如何使用“redirect.WSA.lab”作为重定向主机名。
被动身份验证
SWA可以利用其他思科安全平台被动识别代理用户。被动用户识别无需直接身份验证质询和来自SWA的任何Active Directory通信，从而减少了设备上的延迟和资源使用量。当前可用的被动身份验证机制是通过情景目录代理(CDA)、身份服务引擎(ISE)和身份服务连接器被动身份连接器(ISE-PIC)。
ISE是一个功能丰富的产品，可帮助管理员集中其身份验证服务，并利用广泛的网络访问控制。当ISE获知用户身份验证事件（通过Dot1x身份验证或Web身份验证重定向）时，它会填充包含有关身份验证所涉及的用户和设备的信息的会话数据库。SWA通过Platform Exchange Grid(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事务。如果部署代理仅为显式客户端提供服务，则必须指定转发模式以拒绝任何并非指定流向代理服务的流量。这样可以减少设备攻击面，并遵循良好的安全原则：如果不需要则将其关闭。
Range请求报头用于HTTP请求，以指定要下载的文件的字节范围。操作系统和应用程序更新守护程序通常使用此命令来一次传输文件的小部分。默认情况下，SWA会删除这些信头，以便获取整个文件，以进行防病毒(AV)扫描、文件信誉和分析以及应用可视性控制(AVC)。通过在代理设置中全局启用范围请求报头的转发，管理员可以创建转发或剥离这些报头的单独访问策略。有关此配置的详细信息，请参阅访问策略一节。
HTTPS代理
安全最佳实践建议，私钥必须在使用它们的设备上生成，并且不得传输到其他地方。HTTPS代理向导允许创建用于解密传输层安全(TLS)连接的密钥对和证书。然后，证书签名请求(CSR)可下载并由内部证书颁发机构(CA)签名。在Active Directory(AD)环境中，这是最佳方法，因为AD集成的CA自动受域所有成员的信任，并且不需要其他步骤来部署证书。
HTTPS代理的一个安全功能是验证服务器证书。最佳实践建议无效证书要求断开连接。启用Decrypt for EUN允许SWA显示块页面，解释块的原因。如果未启用此功能，任何被阻止的HTTPS站点都会导致浏览器错误。这会导致服务台票证增加，并且用户认为某些内容已损坏，而不是SWA已阻止连接。所有无效的证书选项都必须设置为至少Decrypt。如果证书问题阻止站点加载，将其中任何选项保留为监控无法记录有用的错误消息。
同样，在线证书服务协议(OCSP)检查必须保持启用状态，并且监控不能用于任何选项。必须删除已撤销的证书，并且必须将所有其他证书至少设置为Decrypt以允许记录相关错误消息。授权信息访问追踪（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覆盖范围，包括不通过代理的恶意流量（包括所有TCP和UDP端口上的流量）的高效方法。T1和T2端口用于连接到网络分路器或交换机监控会话，从而允许SWA被动监控来自客户端的所有流量。如果发现发往恶意IP地址的流量，SWA可以通过在欺骗服务器IP地址的同时发送RST来终止TCP会话。对于UDP流量，它可以发送Port Unreachable消息。配置监控会话时，最好排除发往SWA管理接口的任何流量，以避免该功能可能干扰对设备的访问。
除了监控恶意流量外，L4TM还监听DNS查询以更新旁路设置列表。此列表用于WCCP部署，用于将某些请求返回到WCCP路由器，以直接路由到Web服务器。与旁路设置列表匹配的数据包不会由代理处理。列表可以包含IP地址或服务器名称。SWA每30分钟解析一次旁路设置列表中的任何条目，而不考虑记录的TTL。但是，如果启用L4TM功能，SWA可以使用已监听的DNS查询更频繁地更新这些记录。这降低了客户端解析了与SWA不同的地址时产生误报的风险。
策略配置
正确的策略配置是SWA的性能和可扩展性的关键。这不仅仅是因为策略本身在保护客户和执行公司要求方面的有效性。配置策略的方式直接影响SWA的资源使用情况以及整体运行状况和性能。一组过于复杂或设计欠佳的策略可能导致设备的不稳定性和响应速度缓慢。
复杂性
在制定SWA策略时，会使用各种策略要素。从配置生成的XML文件用于创建大量后端配置文件和访问规则。配置越复杂，代理进程需要花费更多时间来评估每个事务的各种规则集。在设定基准和调整SWA规模时，会创建一组基本策略元素，这些元素代表了配置复杂性的三个层次。10个身份配置文件、解密策略和访问策略，以及10个包含10个regex条目、50个服务器IP地址和420个服务器主机名的自定义类别，被视为低复杂性配置。将每个数字乘以两个和三个分别可得到中等复杂性和高复杂性的配置。
当配置变得过于复杂时，最初的症状通常包括Web界面和CLI响应缓慢。最初不会对用户造成重大影响。但是，配置越复杂，代理进程在用户模式下必须花费的时间就越多。因此，检查在此模式中花费的时间百分比是一种有用的方法，可将过于复杂的配置诊断为SWA缓慢的原因。
CPU时间（以秒为单位）每五分钟记录在track_stats日志中。这意味着用户时间百分比可以计算为（用户时间+系统时间）/300。随着用户时间接近270，该进程在用户模式中花费了过多的CPU周期，这几乎总是因为配置过于复杂，无法有效地分析。
注意：到目前为止，SWA的最大限制是60,000个并发客户端连接和60,000个并发服务器连接。
标识配置文件
标识(ID)配置文件是接收新请求时评估的第一批策略元素。ID配置文件第一部分配置的所有信息都使用逻辑AND进行评估。这意味着所有条件必须匹配，请求才能与配置文件匹配。创建策略时，策略必须严格到绝对必要的程度。包含单个主机地址的配置文件几乎从不需要使用，而且可能导致配置蔓延。利用HTTP报头、自定义类别列表或子网中的用户代理字符串通常是限制配置文件范围的更好策略。
通常，需要身份验证的策略在底部配置，例外项在顶部添加。在对不需要身份验证的策略进行排序时，最常用的策略必须尽可能最接近顶部。不要依赖失败的身份验证来限制访问。如果已知网络上的客户端无法向代理进行身份验证，则必须在访问策略中免除身份验证并阻止该客户端。无法进行身份验证的客户端会重复向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.查找HTTPS连接总数（显式和透明）：
Bash:
grep -cE 'tunnel://|TCP_CONNECT' aclog.current
PowerShell:
(Get-Content aclog.current | Select-String -Pattern 'tunnel://|TCP_CONNECT').length2.查找已解密HTTPS连接的数量：
Bash:
grep -E 'tunnel://|TCP_CONNECT' aclog.current | grep -c DECRYPT
PowerShell:
(Get-Content aclog.current | Select-String -Pattern 'tunnel://|TCP_CONNECT’| Select-String -Pattern ‘DECRYPT’).length3.将第二个值除以第一个值，然后乘以100。
设计解密策略时，必须了解策略中列出的各种操作如何导致设备评估HTTPS连接。当客户端和服务器必须被允许终止其TLS会话的每一端而没有SWA解密每个数据包时，将使用直通操作。即使站点设置为直通，也必须要求SWA与服务器完成一次TLS握手。这是因为SWA必须选择根据证书有效性阻止连接，并且必须启动与服务器的TLS连接以获取证书。如果证书有效，SWA将关闭连接并允许客户端继续直接与服务器建立会话。
SWA不执行任何TLS握手的唯一情况是服务器名称或IP地址存在于自定义类别（设置为passthrough）中，并且服务器名称在HTTP CONNECT或TLS客户端Hello中可用。在显式场景中，客户端在TLS会话启动之前（在主机报头中）向代理提供服务器的主机名，因此会根据自定义类别检查此字段。在透明部署中，SWA检查TLS客户端Hello消息中的Server Name Indication(SNI)字段，并根据自定义类别评估该字段。如果不存在主机报头或SNI，则SWA必须继续与服务器握手，以便按此顺序检查证书上的Subject Alternative Name(SAN)和Common Name(CN)字段。
此行为对策略设计的含义是，可以通过确定已知和内部信任的服务器并将其设置为从自定义类别列表传递，而不是依赖网络类别和信誉得分（这仍需要SWA完成与服务器的TLS握手）来减少TLS握手的数量。但是，需要注意的是，这也会阻止证书有效性检查。
新站点在Web上出现的速度，很可能是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 Proxy部分所述，请求报头用于请求文件的特定字节范围，通常由操作系统和应用程序更新服务使用。默认情况下，SWA从出站请求中删除这些报头，因为如果没有整个文件，将无法执行恶意软件扫描或使用AVC功能。如果网络中的许多主机经常请求小字节范围来检索更新，则可能会触发SWA同时下载整个文件几次。这会快速耗尽可用互联网带宽并导致服务中断。此故障场景的最常见原因是Microsoft Windows更新和Adobe软件更新守护程序。
要缓解此问题，最佳解决方案是完全控制SWA周围的流量。这对于透明部署的环境并非总是可行的，在这些情况下，下一个最佳选项是为流量创建专用访问策略，并在这些策略上启用范围请求报头转发。必须考虑到AV扫描和AVC无法处理这些请求，因此必须仔细设计策略，以便仅针对预期流量。通常，完成此任务的最佳方法是匹配请求报头中的用户代理字符串。可以在线找到通用更新守护程序的用户代理字符串，或者由管理员捕获并检查请求。大多数更新服务（包括Microsoft Windows更新和Adobe软件更新）不使用HTTPS。
如解密策略部分所述，不建议删除解密策略中的未分类站点。出于同样的原因，建议不要在访问策略中阻止它们。动态内容分析(DCA)引擎可以使用给定站点的内容以及其他启发式数据来分类站点，否则这些站点将被URL数据库查找标记为未分类。启用此功能可减少SWA中未分类裁决的数量。
在访问策略的“对象扫描”(Object Scanning)设置中，可以检查多种类型的存档文件。如果网络在应用程序更新过程中定期下载存档文件，启用此功能会显着增加CPU使用率。如果要检查所有存档文件，必须提前识别并免除此流量。首先调查识别此流量的可能方法的是用户代理字符串，因为这样有助于避免可能变得难以维护的IP允许列表。
自定义和外部URL类别
自定义类别列表用于按IP地址或主机名标识服务器。可以使用正则表达式(regex)指定服务器名称匹配的模式。与使用子字符串匹配相比，使用regex模式匹配服务器名称要耗费大量资源，因此只有在绝对必要时才必须使用这些模式。可以在域名的开头添加“。”以匹配子域，而无需正则表达式。例如，“.cisco.com”也匹配“www.cisco.com”。
如复杂性部分中所述，低复杂性定义为10个自定义类别列表，中等复杂性定义为20个，高复杂性定义为30个。建议将此数字保留为二十以下，尤其是当列表使用regex模式或包含大量条目时。有关每种类型的条目数量的其他详细信息，请参阅访问策略部分。
外部URL源比静态自定义类别列表灵活得多，利用这些源可能会对安全性产生直接影响，因为它们不再需要管理员手动维护这些源。由于此功能可用于检索不由SWA管理员维护或控制的列表，因此在AsyncOS版本11.8中增加了将单个例外添加到已下载地址的功能。
Office365 API对于针对此常见部署的服务做出策略决策特别有用，可用于各个应用（PowerPoint、Skype、Word等）。Microsoft建议绕过所有Office365流量的代理以优化性能。Microsoft文档规定：
“虽然SSL中断和检查会产生最大延迟，但代理身份验证和信誉查找等其他服务可能导致性能下降和用户体验不佳。此外，这些外围网络设备需要足够的容量来处理所有网络连接请求。我们建议绕过代理或检测设备来获得直接Office 365网络请求。"https://learn.microsoft.com/en-us/microsoft-365/enterprise/managing-office-365-endpoints?view=o365-worldwide。
在透明代理环境中使用此指南可能很困难。从AsyncOS版本11.8开始，可以使用从Office365 API检索的动态类别列表来填充旁路设置列表。此列表用于将透明重定向的流量发送回WCCP设备以进行直接路由。
绕过所有Office365流量会为需要一些基本安全控制和此流量报告的管理员创建盲点。如果SWA没有绕过Office365流量，了解可能出现的具体技术挑战就非常重要。其中之一是应用程序所需的连接数。大小调整必须适当以适应Office365应用程序所需的其他持续TCP连接。这会将每个用户的总连接数增加10到15个持续TCP会话。
HTTPS代理执行的解密和重新加密操作会为连接带来少量延迟。Office365应用程序对延迟非常敏感，如果广域网连接缓慢和地理位置分散等其他因素影响了这一情况，用户体验可能会受到影响。
某些Office365应用程序使用专有的TLS参数，这些参数会阻止HTTPS代理与应用程序服务器完成握手。验证证书或检索主机名需要此步骤。当此应用与其TLS客户端Hello消息中不发送服务器名称指示(Server Name Indication， SNI)字段的应用（例如Skype for Business）结合使用时，需要完全绕过此流量。AsyncOS 11.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 124502rate命令显示有关代理进程使用的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 44tcpservices命令显示有关所选进程侦听端口的信息。系统还会显示每个进程以及地址和端口组合的说明：
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日志每五分钟添加一次，包含几个输出部分，这些输出部分与代理进程及其在内存中的对象直接相关。性能监控中最有用的部分显示了各种请求进程的平均延迟，包括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> | Web代理发送请求后，从McAfee扫描引擎接收响应的等待时间。 |
| %F | 客户端源端口。 |
| %p | Web服务器端口。 |
| %k | 数据源IP地址（Web服务器IP地址）。 |
| %:w< | 从Webroot扫描引擎接收裁决的等待时间，包括Web代理发送请求所需的时间。 |
| %:w> | Web代理发送请求后，从Webroot扫描引擎接收响应的等待时间。 |
SWA许可模式允许对虚拟设备重复使用物理设备许可证。您可以利用此优势，部署测试SWAv设备，以便在实验室环境中使用。新功能和配置可以通过这种方式进行试点，以确保稳定性和可靠性，同时不会违反许可条款。
高级网络安全报告(AWSR)
必须利用AWSR从SWA充分利用报告数据。特别是在部署了许多SWA的环境中，此解决方案的可扩展性比在安全管理设备(SMA)上使用集中报告要高许多倍，并且提供了自定义报告属性，可增加数据深度和自定义程度。报告可以分组和自定义，以满足任何组织的需求。确定AWSR规模时必须使用思科高级服务组。
邮件警报
SWA上的内置邮件警报系统最好用作基本警报系统。它必须经过适当调整以满足管理员的需要，因为如果启用了所有的信息事件，它可能会非常嘈杂。限制警报并主动监控警报比对所有警报都发出警报并将其视为垃圾邮件更重要。
| 警报设置 | 配置 |
| 发送警报时要使用的发件人地址 | 自动生成 |
| 发送重复警报之前等待的初始秒数 | 300 秒 |
| 发送重复警报之前等待的最大秒数 | 3600 秒 |
可用性监控
有两种方法可用于监控Web代理的可用性。第一种是第3层(L3)监控，用于测试设备IP地址在网络上是否可达。测试此情况的最简单方法是定期向地址发送ICMP Echo(ping)请求并检查应答数据包。可以解析应答的属性（例如TTL和延迟）以确定网络层的运行状况。
设备可能会响应ping，但代理进程没有响应或间歇性中断。因此，建议使用第7层(L7)监控器，该监控器向设备发送显式代理请求，并需要200 OK HTTP响应代码。这不仅测试了网络接口的可达性，还测试了代理服务的响应性，以及在请求外部资源时上游服务的可行性。此类监控通常采用请求代理连接到资源的显式HTTP HEAD请求的形式。HEAD方法请求客户端发送GET请求时返回的报头，但仅包括响应报头而不包括数据。
如果使用L7监控工具或脚本，必须确保流量免于身份验证。否则会导致定期身份验证失败和资源消耗。当您在监控工具中使用自定义用户代理字符串时，必须采用它来标识流量。即使流量免于身份验证，仍可以通过访问策略限制其访问不必要的Internet。
当您使用其中一种或多种方法时，管理员必须围绕代理响应建立可接受度量的基准，并使用该基准构建警报阈值。您必须将时间用于收集此类检查的响应，然后才能决定如何配置阈值和警报。
SNMP 监控
简单网络管理协议(SNMP)是监控设备运行状况的主要方法。它可用于接收来自设备的警报（陷阱）或轮询各种对象标识符(OID)以收集信息。SWA上有许多OID，涵盖从硬件到资源使用再到单个流程信息和请求统计的所有内容。
由于硬件和性能相关的原因，必须监控许多特定的计算机信息库(MIB)。MIB的完整列表可在此处找到：https://www.cisco.com/web/ironport/tools/web/asyncosweb-mib.txt。
以下是建议监控的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 | fanTable |
| 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 | percentMemoryUtilization | RAM |
| 每秒事务数 | ||
| 1.3.6.1.4.1.15497.1.2.3.7.1.1.0 | cacheThruNow | 最后一分钟内每秒平均事务数。 |
| 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 | cacheThruputLifeMean | 代理重新启动后每秒的平均事务数。 |
| 带宽 | ||
| 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 | cacheHitsLifePeak | 自代理重新启动以来的最大缓存命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.9.9.0 | cacheHitsLifeMean | 自代理重新启动以来的平均缓存命中率。 |
| 缓存命中率 | ||
| 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 | cacheHitsLifePeak | 自代理重新启动以来的最大缓存命中率。 |
| 1.3.6.1.4.1.15497.1.2.3.7.5.9.0 | cacheHitsLifeMean | 自代理重新启动以来的平均缓存命中率。 |
| 连接 | ||
| 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 | 服务器连接总数。 |
结论
本指南旨在介绍SWA配置、部署和监控的最重要方面。作为参考指南，它的目标是为那些希望确保最有效地使用全部门办法的人提供有价值的信息。此处介绍的最佳实践对于设备作为安全工具的稳定性、可扩展性和有效性非常重要。它还寻求在相关资源不断向前发展时继续保留，因此必须频繁更新，以反映网络环境和产品功能集的变化。
修订历史记录
| 版本 | 发布日期 | 备注 |
|---|---|---|
3.0 |
25-Jul-2023 |
首次公开发布 |
1.0 |
10-Apr-2023 |
初始版本 |
反馈