• 请参阅支持的平台和要求。

• 用于安装和执行服务的根权限。

• 1 GB 存储空间，用于代理和日志文件。

• 在监控主机的安全应用上配置安全排除项，以防止这些应用阻止代理安装或代理活动。有关详细信息，请参阅安全排除项。

• 系统会在安装代理的主机中创建一个特殊用户 tet-sensor。如果主机上配置了 PAM 或 SELinux，则必须授予 tet-sensor 用户执行 tet-sensor 进程和连接收集器的适当权限。如果提供了替代安装目录并配置了 SELinux，请确保允许为该位置执行。

• 如果使用 AutoInstall（安装程序脚本）方法安装代理，则必须要能够使用 unzip 命令。

安装 Linux 代理以实现深度可视性和执行的方法：

• 使用代理脚本安装程序方法安装 Linux 代理

  • 代理支持 Nvidia SmartNIC (Bluefield DPU)

• 使用代理映像安装程序方法安装 Linux 代理

• 请参阅“支持的平台和要求”部分。

• 安装和执行服务需要具有管理员权限。

• Npcap 必须安装在运行 Windows 2008 R2 的工作负载上，而当安装的代理版本低于版本 3.8 时也必须安装。如果尚未安装 Npcap 驱动程序，代理会在服务启动后在后台安装推荐的 Npcap 版本。有关详细信息，请参阅 Npcap 版本信息。

• 1 GB 存储空间用于代理和日志文件。

• 启用代理安装所需的 Windows 服务。如果您的 Windows 主机已经过安全强化，或者偏离了默认配置，则某些 Windows 服务可能已被禁用。有关详细信息，请参阅“必需的 Windows 服务”部分。

• 在监控主机的安全应用上配置的安全排除，可能会阻止代理安装或代理活动。有关详细信息，请参阅安全排除项。

有两种方法可以安装 Windows 代理，以实现深度可视性和执行。

• 使用代理脚本安装程序方法安装 Windows 代理

• 使用代理映像安装程序方法安装 Windows 代理

您还可以使用黄金映像进行安装。有关详细信息，请参阅在 VDI 实例或 VM 模板上部署代理 (Windows)。

1. 确保服务 CswAgent 在配置的服务用户情景中运行。CswAgent 在同一服务用户情景中运行。

   使用管理员权限运行命令 cmd.exe

   运行命令 sc qc cswagent

   检查 SERVICE_START_NAME <configured service user>

   或

   运行命令 services.msc

   查找 Cisco Secure Workload 深度可视性 (Cisco Secure Workload Deep Visibility) 的名称

   检查 <configured service user> 的登录身份

   查找名称 Cisco Secure Workload 执行 (Cisco Secure Workload Enforcement)

   检查 <configured service user> 的登录身份

   或

   运行命令 tasklist /v | find /i “cswengine”

   检查正在运行的进程的用户情景（第 5 列）

在安装 Windows 代理后，使用以下方法之一修改现有的深度可视性和执行服务。

• 使用 services.msc。

  

• 使用任何第三方应用来配置服务。

• 使用以下命令：

  1. 以管理员身份运行 cmd。

  2. 通过运行以下命令，使用服务帐户名称来修改服务：

     • sc config cswagent obj= <service user name> password= <password>

  3. 通过运行以下命令来验证服务配置：

     • sc qc cswagent

  4. 通过运行以下命令来重启 CswAgent 服务：

     1. sc.exe cswagent

     2. sc.exe cswagent

默认情况下，代理服务会在代理安装后自动启动。在黄金镜像上安装时，必须使用安装程序标记来阻止这些服务启动。从黄金映像克隆实例时，代理服务会按预期自动启动。

代理不会在黄金 VM 上安装 Npcap，但如有需要，会在从黄金映像克隆的 VM 实例上自动安装。有关详细信息，请参阅 Windows 代理安装程序和 Npcap。

1. 有关受支持的 Npcap 版本，请参阅https://www.cisco.com/go/secure-workload/requirements/agents上的支持矩阵。

2. 安装：

   如果未安装 Npcap，代理会在服务启动十秒后安装受支持的版本。如果用户已安装 Npcap，但其版本早于支持的版本，则 Npcap 无法升级。手动升级或卸载 Npcap，使用选项 overwritenpcap=yes 来运行代理安装程序，或使用 -npcap 来运行安装程序脚本，以获取支持的 Npcap 版本。如果任何应用正在使用 Npcap 驱动程序，则代理稍后会升级 Npcap。

3. 升级：

   如果 Npcap 是由 Windows Agent 安装的，且版本早于支持的版本，则 Npcap 会在服务启动十秒后升级到支持的版本。如果任何应用正在使用 Npcap 驱动程序，则代理稍后会升级 Npcap。如果 Npcap 不是由 Windows 代理安装，则不会升级 Npcap。

4. 卸载：

   如果 Npcap 是由 Windows 代理安装的，则代理会卸载 Npcap。如果 Npcap 由用户安装，但由代理安装程序使用 overwritenpcap=yes 进行升级，则不会卸载 Npcap。如果任何应用正在使用 Npcap 驱动程序，则代理不会卸载 Npcap。

从最新版本的 Windows 开始，该代理使用 ndiscap.sys（Microsoft 内置）驱动程序和使用 Windows 的事件跟踪 (ETW) 框架来捕获网络流。

在升级到最新版本期间：

• 代理从 npcap.sys 切换到 ndiscap.sys。

• 在以下情况时，代理安装程序会卸载 Npcap：

  • Npcap 由代理安装。

  • 未使用 Npcap。

  • 操作系统版本并非 Windows Server 2008 R2。

代理服务启动后，代理会创建 ETW 会话 CSW_MonNet 和 CSW_MonDns（用于 DNS 数据），同时启动网络流捕获。

Note	在 Windows Server 2012 上，系统会解析网络数据包以获取 DNS 数据。 Windows Server 2012 及更高版本的主机上的 Windows 代理会捕获使用者和提供者用户名，并且用户名在流观察结果中可用。由于操作系统限制，Windows Server 2008 R2 不支持此功能。在代理配置文件中，配置以下内容以捕获用户名： 启用 PID/用户查找。 将“流分析精确度”(Flow Analysis Fidelity) 设置为“详细”(Detailed)。

• 请参阅支持的平台和要求。

• 深度可视性的其他要求：

  • 用于安装和执行服务的根权限。

  • 代理和日志文件的存储要求：500 MB。

  • 在监控主机的任何安全应用上配置的安全排除。这些排除是为了防止其他安全应用阻止代理安装或代理活动。有关详细信息，请参阅安全排除项。

  • AIX 仅支持 20 台网络设备的流捕获（如果版本为 AIX 7.1 TL3 SP4 或更早，则为 6 台网络设备）。深度可视性代理最多从 16 台网络设备捕获，而其他 4 个捕获会话可用于专用的通用系统（例如，tcpdump）。

  • 深度可视性代理执行以下操作，以确保对 20 台网络设备进行流捕获：

    • 代理会在代理目录 (/opt/cisco/tetration/chroot/dev/bpf0 - /opt/cisco/tetration/chroot/dev/bpf15) 下创建 16 个 bpf 设备节点

    • tcpdump 和其他使用 bpf 的系统工具将扫描系统设备节点 (/dev/bpf0-/dev/bpf19)，直至找到未使用的节点 (!EBUSY)

    • 代理创建的 bpf 节点和系统 bpf 节点会共享相同的主/次要文件，而每个主要或次要文件仅由一个实例（tcpdump 或代理）打开。

    • 代理不会访问系统设备节点，也不会像 tcpdump 那样创建系统设备节点（如果不存在，tcpdump-D 会创建 /dev/bpf0. . . /dev/bpf19）。

  • 在某些情况下，在系统上运行 iptrace 可防止来自 tcpdump 和深度可视性代理的流捕获。这是一个已知的设计问题，需要与 IBM 核实。

    • 要检查是否存在此场景，请在安装代理之前运行 tcpdump。如果错误消息为 tcpdump: BIOCSETIF: en0: File exists，则 iptrace 已阻止流捕获。停止 iptrace 以解决问题。

• AIX 7 和 POWER8 或更高版本支持进程可视性和调查分析。

• 策略执行的其他要求：

  • 如果启用了 IP 安全过滤器（即 smitty IPsec4），则代理安装会在预先检查中失败。建议您在安装代理之前禁用 IP 安全过滤器。

  • 如果在运行 Cisco Secure Workload 执行器代理时启用了 IP 安全，则会报告错误并停止执行。请联系支持人员，以便在执行器代理运行时安全地禁用 IP 安全过滤器。

容器协调平台允许定义和执行安全策略，如网络策略、Pod 安全策略和基于角色的访问控制 (RBAC)，以进一步增强容器化应用的安全性。Cisco Secure Workload 使用 Kubernetes 自动执行容器化应用的部署、扩展和管理。它提供了对容器化工作负载状态和性能的详细可视性。另一方面，OpenShift 以 Kubernetes 为基础，增加了企业级功能，如增强的安全性、开发人员工具和管理功能。

• 请参阅支持的平台和要求。

• 用于安装和执行服务的根权限。

• 1 GB 存储空间用于代理和日志文件。

• 在监控主机的安全应用上配置安全排除，以防止其他安全应用阻止代理安装或代理活动。有关详细信息，请参阅安全排除项。

Linux 内核具有 iptables 和 ip6tables，用于设置、维护和检查 IPv4 和 IPv6 数据包过滤规则表。iptables 和 ip6tables 包含许多预定义的表。每个表都包含预定义的链，也可以包含用户定义的链。这些链包含规则集，而每个规则指定了数据包的匹配条件。预定义表包括 raw、mhole、filter 和 NAT。预定义链包括 INPUT、OUTPUT、FORWARD、PREROUTING 和 POSTROUTING。

Cisco Secure Workload 代理对包含允许或丢弃数据包的规则的过滤表进行编程。过滤器表由预定义链 INPUT、OUTPUT 和 FORWARD 组成。除此以外，代理还会添加自定义 TA 链，以便对来自控制器的策略进行分类和管理。这些 TA 链包含从策略派生的 Cisco Secure Workload 规则以及代理生成的规则。当代理收到与平台无关的规则时，它会将其解析并转换为 iptable、ip6table 或 ipset 规则，并将这些规则插入 TA 在过滤表中定义的链中。在对防火墙进行编程后，代理会监控防火墙是否有任何规则或策略偏差，如有，则会重新对防火墙进行编程。它会跟踪防火墙中编程的策略，并定期向控制器报告其统计信息。

以下是一个描述这种行为的示例：

独立于平台的网络策略消息中的典型策略包括：

source set id: “test-set-1”
destination set id: “test-set-2”
source ports: 20-30
destination ports: 40-50
ip protocol: TCP
action: ALLOW
. . .
set_id: “test-set-1”
     ip_addr: 1.2.0.0
     prefix_length: 16
     address_family: IPv4
set_id: “test-set-2”
     ip_addr: 3.4.0.0
     prefix_length: 16
     address_family: IPv4

代理会处理该策略和其他信息，并将其转换为特定平台的 ipset 和 iptables 规则：

ipset rule:
Name: ta_f7b05c30ffa338fc063081060bf3
Type: hash:net
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16784
References: 1
Members:
1.2.0.0/16
Name: ta_1b97bc50b3374829e11a3e020859
Type: hash:net
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16784
References: 1
Members:
3.4.0.0/16
iptables rule:
TA_INPUT -p tcp -m set --match-set ta_f7b05c30ffa338fc063081060bf3 src -m set --match-
˓→set ta_1b97bc50b3374829e11a3e020859 dst -m multiport --sports 20:30 -m multiport --
˓→dports 40:50 -j ACCEPT

Windows 上的本地组件（高级安全 Windows 防火墙）根据以下类型的设置来调节网络流量：

• 监管入站网络流量的规则。

• 监管出站网络流量的规则。

• 根据网络流量源和目标的身份验证状态来覆盖规则。

• 适用于 IPsec 流量和 Windows 服务的规则。

使用入站和出站防火墙规则对 Cisco Secure Workload 网络策略进行编程。

在 Windows 平台上，Cisco Secure Workload 网络策略按如下方式执行：

1. Cisco Secure Workload 网络策略中独立于平台的防火墙规则将转换为 Windows 防火墙规则。

2. 规则将在 Windows 防火墙中编程。

3. Windows 防火墙执行规则。

4. 系统将监控 Windows 防火墙及其规则集。如果检测到更改，系统会报告偏差，并在 Windows 防火墙中重置 Cisco Secure Workload Network 策略。

Windows 防火墙会根据主机连接的网络对规则进行分组。这些规则组被称为配置文件，共有三个此类配置文件：

• 域配置文件

• 专用配置文件

• 公共配置文件

Cisco Secure Workload 规则会被编程到所有配置文件中，但只会持续监控活动配置文件中的规则。

Windows 防火墙中的规则集未根据优先级进行排序。当多个规则与数据包匹配时，最严格的规则将生效，这意味着 DENY 规则优先于 ALLOW 规则。有关详细信息，请参阅 Microsoft TechNet 上的文章。

1. ALLOW 1.2.3.30 tcp port 80
2. ALLOW 1.2.3.40 udp port 53
3. BLOCK 1.2.3.0/24 ip
4. ALLOW 1.2.0.0/16 ip
5. Catch-all: DROP ingress, ALLOW egress

当流向主机 1.2.3.30 TCP 端口 80 的数据包到达防火墙时，它会匹配所有规则，但其中最严格的规则 3 将被执行，数据包将被丢弃。这种行为违背了按顺序评估规则、执行规则 1 以及允许数据包的预期。

由于上述 Windows 防火墙的设计，这种行为差异在 Windows 平台上是意料之中的。在具有不同规则操作的重叠规则的混合列表策略中，可以观察到这种行为。

例如，

1. ALLOW 1.2.3.30 tcp
2. BLOCK 1.2.3.0/24 tcp

Windows 高级防火墙被视为有状态的防火墙，即对于某些协议（例如 TCP），防火墙维护内部状态跟踪，以检测到达防火墙的新数据包是否属于已知连接。属于已知连接的数据包无需检查防火墙规则即可被允许。状态防火墙支持双向通信，而无需在 INBOUND 和 OUTBOUND 表中建立规则。

例如，请考虑适用于 Web 服务器的以下规则：Accept all TCP connections to port 443

这样做的目的是接受端口 443 上到服务器的所有 TCP 连接，并允许服务器与客户端进行通信。在这种情况下，INBOUND 表中只会插入一条规则，从而允许端口 443 上的 TCP 连接。无需在 OUTBOUND 表中插入任何规则。在 OUTBOUND 表中插入规则由 Windows 高级防火墙隐式执行。

Note	状态跟踪只适用于建立和维护显式连接的协议。对于其他协议，必须对 INBOUND 和 OUTBOUND 规则进行编程，以启用双向通信。

启用执行后，当协议为 TCP 时，给定的具体规则将被编程为有状态（代理会根据情景决定将该规则插入 INBOUND 表还是 OUTBOUND 表）。对于其他协议（包括 ANY），会同时编程 INBOUND 和 OUTBOUND 规则。

Windows 过滤平台 (WFP) 是 Microsoft 提供的一组 API，用于配置过滤器以处理网络流量。网络流量处理过滤器使用内核级 API 和用户级 API 进行配置。WFP 过滤器可在各个层进行配置：网络层、传输层、应用层执行 (ALE)。Cisco Secure Workload WFP 过滤器在 ALE 层配置，类似于 Windows 防火墙规则。每个层都有多个子层，按权重从高到低排序。在每个子层中，过滤器按权重从高到低排序。网络数据包会遍历所有子层。在每个子层，网络数据包都会根据权重从高到低穿过匹配过滤器，并返回相应的操作：允许或阻止。通过所有子层后，数据包将根据“阻止”操作优先于“允许”操作的规则进行处理。

• 避免 Windows 防火墙配置依赖关系。

• 克服 GPO 限制。

• 确保轻松迁移和策略恢复。

• 允许您控制策略排序。

• 避免 Windows 防火墙的严格阻止优先策略顺序。

• 减少策略更新时的 CPU 开销。

• 创建高效的 1:1 策略规则过滤器。

• 确保更快的单步更新。

当执行配置为使用 WFP 时，Cisco Secure Workload 过滤器会覆盖 Windows 防火墙规则。

在 WFP 模式下，代理配置以下 WFP 对象：

• 提供者具有 GUID 和名称，用于过滤器管理，不会影响数据包过滤

• 子层具有 GUID、名称和权重。Cisco Secure Workload 子层配置的权重高于 Windows 高级防火墙子层。

• 过滤器具有名称、GUID、ID、权重、层 ID、子层密钥、操作 (PERMIT/BLOCK) 和条件。为 Golder 规则、自身规则和策略规则配置 WFP 过滤器。代理还会配置端口扫描防护过滤器。Cisco Secure Workload 过滤器配置了 FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT 标志。此标志可确保 Cisco Secure Workload 过滤器不会被 Microsoft 防火墙规则覆盖。对于每个 Cisco Secure Workload 网络策略规则，系统会根据方向（入站或出站）和协议来配置一个或多个 WFP 过滤器。

对于 TCP 入站策略，

id: 14 , TCP Allow 10.195.210.184 Dir=In localport=3389

配置的 WFP 过滤器如下：

Filter Name:                  Cisco Secure Workload Rule 14
------------------------------------------------------
EffectiveWeight:                       18446744073709551589
LayerKey:                              FWPM_LAYER_ALE_AUTH_LISTEN_V4
Action:                                Permit
Local Port:                            3389
Filter Name:                           Cisco Secure Workload Rule 14
------------------------------------------------------
EffectiveWeight:                       18446744073709551589
LayerKey:                              FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
Action:                                Permit
RemoteIP:                              10.195.210.184-10.195.210.184

Cisco Secure Workload 代理分别为入站和出站捕获全部策略配置 Cisco Secure Workload 默认入站和 Cisco Secure Workload 默认出站过滤器。

• 代理不监控 WAF 规则或 WAF 配置文件。

• 代理不监控防火墙状态。

• 代理不需要启用防火墙状态。

• 代理不与 GPO 策略冲突。

WFP 模式下的代理执行支持混合列表或灰名单策略。

请考虑“执行代理”部分中的混合列表（允许和拒绝）策略示例：

1. ALLOW 1.2.3.30 tcp port 80-            wt1000
2. BLOCK 1.2.3.0/24 ip-                   wt998
3. ALLOW 1.2.0.0/16 ip-                   wt997
4. Catch-all: DROP ingress, ALLOW egress - wt996

当发向主机 1.2.3.30 tcp 端口 80 的数据包到达防火墙时，它会匹配过滤器 1 并被允许。但由于过滤器 2，流向主机 1.2.3.10 的数据包会被阻止。过滤器 3 允许发往主机 1.2.2.10 的数据包。

Cisco Secure Workload WFP 过滤器在 ALE 层进行配置。网络流量会针对套接字 connect()、listen() 和 accept() 操作进行过滤。建立连接后，与 L4 连接相关的网络数据包不会被过滤。

您可以使用 c:\program files\tetration\tetenf.exe 来查看已配置的 Cisco Secure Workload WFP 过滤器。支持的选项：

• 使用管理权限运行 cmd.exe。

• 运行 c:\program files\tetration\tetenf.exe -l -f <-verbose> <-output=outfile.txt>。

或

• 使用管理权限运行 cmd.exe。

• 运行 netsh wfp show filters。

• 查看 filters.xml 文件以获取已配置的 Cisco Secure Workload 过滤器。

您可以使用 c:\program files\tetration\tetenf.exe 来删除已配置的 Cisco Secure Workload WFP 过滤器。为避免意外删除过滤器，当您运行 delete 命令时，请以 <yyyymm> 格式指定令牌，其中 yyyy 是当前年份，mm 是当前月份的数字形式。例如，如果今天的日期是 2021/01/21，则令牌为 -token=202101

支持的选项包括：

• 使用管理权限运行 cmd.exe。

• 要删除所有已配置的 Cisco Secure Workload 过滤器，请运行 c:\program files\tetration\tetenf.exe -d -f -all - token=<yyyymm>

• 要删除所有已配置的 Cisco Secure Workload WFP 对象，请运行 c:\program files\tetration\tetenf.exe -d -all -token=<yyyymm>

• 要按名称删除 Cisco Secure Workload WFP 过滤器，请运行 c:\program files\tetration\tetenf.exe -d -name=<WFP filter name> -token=<yyyymm>

• 将“执行模式”(Enforcement Mode) 设置为 WFP 时，代理配置文件中的保留规则 (Preserve Rules) 设置将不起作用。

• Windows 2008 R2 不支持基于 Windows 操作系统的过滤策略。

• 可以使用单个用户名来配置网络策略，而 MS 防火墙 UI 支持多个用户。

• 在使用基于 Windows 操作系统的策略时，使用者/提供者范围或过滤器应仅包含 Windows 代理。否则，非 Windows 操作系统（Linux、AIX）会跳过策略并在“执行状态”(Enforcement Status) 中报告同步错误。

• 避免创建过滤条件宽松的 Windows 操作系统过滤器。此类条件可能会打开不需要的网络端口。

• 如果操作系统过滤器是为使用者配置的，那么策略只适用于使用者，同样，如果是为提供者配置的，那么策略只适用于提供者。

• 由于对网络流的进程上下文、用户上下文或服务上下文了解有限或一无所知，如果策略采用基于 Windows 操作系统的过滤器，策略分析就会出现偏差。

如果使用基于 Windows 操作系统的过滤属性，则以下主题将为您提供验证和故障排除信息。

思科 TAC 可以根据需要使用这些信息来对此类策略进行故障排除。

它作为内核扩展模块 /usr/lib/drivers/ipf 进行加载。它包括用于编程 ipfilter 规则的 ipf、ippool、ipfstat、ipmon、ipfs 和 ipnat 实用程序，每个规则指定数据包的匹配条件。有关详细信息，请参阅 AIX 手册中的 IPFilter 页面。

启用执行时，代理使用 IPFilter 对包含允许或丢弃 IPv4 数据包的规则的 IPv4 过滤表进行编程。代理会将这些规则分组，以使用控制器来对策略进行分类和管理。这些规则包括从策略派生的 Cisco Secure Workload 规则和代理生成的规则。

当代理收到独立于平台的规则时，它会解析这些规则并将其转换为 ipfilter 或 ippool 规则，并将这些规则插入过滤器表中。对防火墙进行编程后，执行代理会监控防火墙是否存在任何规则或策略偏差，如果是，则重新编程防火墙。代理会跟踪防火墙中编程的策略，并定期向控制器报告其状态。

独立于平台的网络策略消息中的典型策略包括：

      source set id: "test-set-1"
      destination set id: "test-set-2"
      source ports: 20-30
      destination ports: 40-50
      ip protocol: TCP
      action: ALLOW
      ...
      set_id: "test-set-1"
         ip_addr: 1.2.0.0
         prefix_length: 16
         address_family: IPv4
      set_id: "test-set-2"
         ip_addr: 5.6.0.0
         prefix_length: 16
         address_family: IPv4

代理会与其他信息一起处理策略，并将其转换为特定于平台的 ippool 和 ipfilter 规则：

    table role = ipf type = tree number = 51400
    { 1.2.0.0/16; };

    table role = ipf type = tree number = 75966
    { 5.6.0.0/16; };

pass in quick proto tcp from pool/51400 port 20:30 to pool/75966 port 40:50 flags S/SA group TA_INPUT
pass out quick proto tcp from pool/75966 port 40:50 to pool/51400 port 20:30 flags A/A group TA_OUTPUT

不支持 IPv6 执行。

1. 根范围所有者只有创建配置文件和配置意图规范的权限。

2. 作为根范围所有者，您可以创建只与所拥有的范围相关联的配置文件，并将这些配置文件强制用于代理。

   Note	在“代理配置文件”(Agent Configuration Profile) 下，您现在可以在编辑配置文件之前使用配置文件查看意图数。

   

3. 站点管理员可以访问“代理配置”(Agent Configuration) 页面中的所有组件，包括指定接口配置意图、远程虚拟路由和转发配置。

网络流信息汇总了流经系统的所有数据包。有两种捕获流信息的模式：“详细”和“对话”。默认情况下，对话模式用于捕获流信息。捕获的流会被导出到收集器，导出的信息包括：

• 流标识符：唯一标识网络流。它包括一般信息，例如：IP 协议、源和目标 IP 以及第 4 层端口。

• IP 信息：包含在 IP 标头中看到的信息，例如：TTL、IP 标志、数据包 ID、IP 选项和分段标志。

• TCP 信息：包含在 TCP 标头中看到的信息，例如：序列号、确认号、TCP 选项、接收窗口大小。

• 流信息：流统计信息（例如总数据包数、总字节数、TCP 标志统计信息、数据包长度统计信息和套接字统计信息）、从中观察到流的接口索引、流的开始时间和结束时间。

• 在 K8s 环境中，代理可捕获来自 pod 和主机的网络流，然后将这些流关联起来，并报告为相关流。这符合以下 CNI 的条件：

  • Calico

  • Flannel

  • Weave

  • AKS/GKE/AWS VPC CNI

  • Openshift CNI

  • Cilium CNI

    Note	从 Pod 和主机捕获网络流，但使用 Cilium CNI 时，无法对网络流进行关联。

在“对话”模式下，代理仅导出本质上是双向的 TCP 流以及其他无连接流。Windows、AIX 和 Linux 平台支持对话模式。有关对话模式的详细信息，请参阅对话模式。

Note	在 K8s 环境中，Pod 或主机流量的相关性不在“对话”模式下进行。 在任一模式下，代理都不会导出以下流： ARP/RARP 对话 流向收集器的代理流

计算机信息描述了主机上运行的所有进程。此外，它还包含与进程相关联的网络信息以及用于启动进程的命令。计算机信息每分钟输出一次，其中包括以下信息：

• 进程 ID

• 用户 ID：流程所有者

• 父进程 ID

• 用于启动进程的命令字符串

• 套接字信息：协议（例如 UDP 或 TCP）、地址类型：IPv4 或 IPv6、源和目标 IP、源和目标端口、TCP 状态、进程的开始和结束时间、进程二进制文件的路径

• 取证信息：有关详细信息，请参阅兼容性部分。

代理会跟踪各种统计信息，包括系统和自身的统计信息，例如：

• 代理的开始时间和正常运行时间

• 代理在用户模式和内核模式下的运行时间

• 接收和丢弃的数据包数

• 成功和失败的 SSL 连接数

• 总流数据包数和字节数

• 导出到收集器的流和数据包总数

• 代理的内存和 CPU 使用率

  {
    "AgentType":"ENFORCER",
    "Bios":"72EF1142-03A2-03BC-C2F8-F600567BA320",
    "CurrentVersion":"3.5.1.1.mrpm.build.win64-enforcer",
    "DesiredVersion":"",
    "HostName":"win2k12-production-db",
    "IP":"172.26.231.193",
    "Platform":"MSServer2012R2Standard"
  }

  {
    "AgentType":"SENSOR",
    "Bios":"72EF1142-03A2-03BC-C2F8-F600567BA320",
    "CurrentVersion":"3.5.1.1.mrpm.build.win64-sensor",
    "DesiredVersion":"",
    "HostName":"win2k12-production-db",
    "IP":"172.26.231.193",
    "Platform":"MSServer2012R2Standard"
  }

rpm -Uvh tet-sensor-1.101.2-1.el6-dev.x86_64.rpm

   error: cannot create transaction lock on /var/lib/rpm/.rpm.lock (Permission denied).

答：如果您没有安装代理的适当权限，请切换到根权限或使用 sudo 来安装代理。

问：运行“sudo rpm -Uvh tet-sensor-1.0.0-121.1b1bb546.el6-dev.x86_64.rpm”并遇到以下错误时，会发生什么情况：

   Preparing...              ########################################### [100%]
   which: no lsb_release in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)
   error: %pre(tet-sensor-site-1.0.0-121.1b1bb546.x86_64) scriptlet failed, exit status 1
   error:   install: %pre scriptlet failed (2), skipping tet-sensor-site-1.0.0-121.1b1bb546

答：系统不符合安装代理的要求。在这种特定情况下，未安装 lsb_release 工具。

有关详细信息，请参阅软件代理部署标签部分，并安装所需的依赖关系。

问：运行“sudo rpm -Uvh tet-sensor-1.0.0-121.1b1bb546.el6-dev.x86_64.rpm”并遇到以下错误时，会发生什么情况：

  Unsupported OS openSUSE project
  error: %pre(tet-sensor-1.101.1-1.x86_64) scriptlet failed, exit status 1
  error: tet-sensor-1.101.1-1.x86_64: install failed
  warning: %post(tet-sensor-site-1.101.1-1.x86_64) scriptlet failed, exit status 1

答：您的操作系统不支持运行软件代理（在此特定情况下，“openSUSE 项目”是不支持的平台）。

有关详细信息，请参阅“软件代理部署标签”部分。

问：在我安装了所有依赖关系并以适当权限运行安装程序后，没有出现任何错误。如何知道代理已安装成功？

答：要在安装代理后验证是否安装成功，请运行以下命令：

$ ps -ef | grep -e csw-agent -e tet-
root     14158     1  0 Apr03 ?        00:00:00 csw-agent
root     14160 14158  0 Apr03 ?        00:00:00 csw-agent watch_files
root     14161 14158  0 Apr03 ?        00:00:03 csw-agent check_conf
root     14162 14158  0 Apr03 ?        00:01:03 tet-sensor -f conf/.sensor_config
root     14163 14158  0 Apr03 ?        00:02:38 tet-main --sensoridfile=./sensor_id
root     14164 14158  0 Apr03 ?        00:00:22 tet-enforcer --logtostderr
tet-sen+ 14173 14164  0 Apr03 ?        00:00:21 tet-enforcer --logtostderr
tet-sen+ 14192 14162  0 Apr03 ?        00:07:23 tet-sensor -f conf/.sensor_config

您必须看到 csw-agent 的三个条目，以及 tet-sensor 的至少两个条目。如果服务未运行，请确保以下目录可用，否则表明安装失败。

• /usr/local/tet（适用于大多数 Linux 发行版）

• /opt/cisco/tetration（适用于 AIX、Ubuntu）

• /opt/cisco/secure-workload（适用于 Solaris、Debian）

问：运行 PowerShell 代理安装程序脚本时，我收到以下错误之一：

1. 基础连接已关闭：接收时发生意外错误。

2. 客户端和服务器无法通信，因为它们没有共同的算法

[Net.ServicePointManager]::SecurityProtocol

[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]’Ssl3,Tls,Tls11,Tls12’

This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.

msiexec /i “TetrationAgentInstaller.msi” /l*v “msi_install.log” /norestart

问：我发现如果底层 NIC 是 Nutanix VirtIO 网络驱动程序，则 Windows 传感器软件无法升级。

答：在启用了接收分段合并的情况下，Npcap 0.9990 与 Nutanix VirtIO 网络驱动程序 1.1.3 之前的版本之间存在不兼容问题。

此问题的解决方法是将 Nutanix VirtIO 网络驱动程序升级到版本 1.1.3 或更高版本。

问：我安装了 Windows 传感器。传感器似乎未注册，并且 sensor_id 文件包含以下内容：uuid-invalid-platform

set PATH=%PATH%;C:\Windows\System32\

问：在 Windows 节点上，我没有收到来自 Kubernetes Pod 的网络流。

答：要验证所需的会话是否正在运行，以便从 Windows 节点上的 Kubernetes Pod 捕获流，请执行以下操作：

1. 使用管理权限运行 cmd.exe。

2. 运行以下命令：logman query -ets

   确保以下会话正在运行：

   • CSW_MonNet：捕获网络流

   • CSW_MonHCS：监控 Pod 的创建

   • CSW_MonNat：监控 NAT 的流

如果在 Kubernetes 守护进程集安装期间安装程序脚本失败，可能有很多原因。

问：是否可以从节点访问 Docker 注册表服务映像？

答：调试从思科 Cisco Secure Workload 集群提取映像的集群的直接或 HTTPS 代理问题

问：容器运行时是否会报告 SSL/TLS 不安全错误？

答：验证所有 Kubernetes 节点上是否已在容器运行时的适当位置安装了 Cisco Secure Workload HTTPS CA 证书。

问：映像下载失败的 Docker 注册表身份验证和授权？

答：在每个节点上，尝试使用 Helm 图表创建的密钥中的 Docker 拉取密钥手动从守护进程集规范中的注册表 URL 提取映像。如果手动映像提取也失败，则需要从 Cisco Secure Workload 集群注册表身份验证服务提取日志，以进一步调试问题。

问：在 Cisco Secure Workload 设备内部托管的 Kubernetes 集群是否正常？

答：检查集群的服务状态页面，确保所有相关服务均正常运行。从探索页面运行 dstool 快照并检索生成的日志。

问：Docker 映像生成器后台守护程序是否正在运行？

答：从 dstool 日志验证构建后台守护程序是否正在运行。

问：构建 Docker 映像的作业是否会失败？

答：从 dstool 日志验证是否未构建映像。Docker 构建 Pod 日志可用于调试构建工具包构建过程中的错误。执行协调器日志还可用于进一步调试构建失败。

问：创建 Helm 图表的作业是否失败？

答：从 dstool 日志验证是否未构建 Helm 图表。执行协调器日志将包含 Helm 构建作业的输出，可用于调试 Helm 图表构建作业失败的确切原因。

问：安装 bash 脚本已损坏？

答：尝试再次下载安装 bash 脚本。bash 脚本包含其附加的二进制文件数据。如果使用文本编辑器以任何方式编辑 bash 脚本或将其保存为文本文件，二进制文件数据中的特殊字符可能会被文本编辑器混淆或修改。

问：Kubernetes 集群配置 - 变体和风格过多，我们支持经典 K8。

答：如果客户运行的是 Kubernetes 的变体，则在部署的不同阶段可能存在许多故障模式。对故障阶段进行分类 - kubectl 命令运行失败、Helm 命令运行失败、Pod 映像下载失败、Pod 特权模式选项被拒绝、Pod 映像信任内容签名失败、Pod 映像安全扫描失败、Pod 二进制文件无法运行（架构不匹配）、Pod运行，但 Cisco Secure Workload 服务无法启动，Cisco Secure Workload 服务由于异常的操作环境而启动，但出现运行时错误。

问：Kubernetes RBAC 凭证是否失效？

答：为了运行特权守护进程集，我们需要 K8s 集群的管理员权限。验证 kubectl 配置文件的默认情景是否指向目标集群和该集群的管理员等效用户。

问：Busybox 映像是否可从所有集群节点获取或下载？

答：修复连接问题，并手动测试是否可以下载 Busybox 映像。Pod 规范中使用的 busybox 版本必须在所有集群节点上可用（预先设定种子）或可下载。

问：安装过程中出现 API 服务器和 etcd 错误或一般超时？

答：由于 Kubernetes 集群中所有节点上的守护进程集 Pod 实例化，集群上的 CPU/磁盘/网络负载可能会突然激增。这在很大程度上取决于客户的特定安装详细信息。由于过载，安装过程（在所有节点上提取并写入磁盘的映像）可能需要太长时间，或者 Kubernetes API 服务器或 Cisco Secure Workload Docker 注册表终端或（如已配置）代理服务器临时过载。短暂等待所有节点上的镜像提取完成，Kubernetes 集群节点上的 CPU/磁盘/网络负载减少后，再次重试安装脚本。来自 Kubernetes 控制平面的 API Server 和 etcd 错误表明，Kubernetes 控制平面节点可能配置不足，或受到活动突然激增的影响。

问：Cisco Secure Workload 代理在运行时遇到运行时问题？

答：如果 Pod 已正确部署且代理已开始运行但遇到运行时问题，请参阅“Linux 代理故障排除”部分。Kubernetes 部署成功安装并启动 Pod 后，故障排除步骤相同。

代理已停止检查集群服务。出现这种情况有多种原因：

• 主机可能已关闭

• 网络连接已被防火墙规则中断或阻止

• 该代理服务已停止

代理升级失败。这可能由少数情况触发，例如：

• 签入脚本尝试下载软件包时找不到软件包 - 无法解压升级软件包或无法验证软件包中的安装程序。

• 安装过程因操作系统问题或依赖关系而失败。

当前代理类型与所需的代理类型不匹配，并且转换尝试已超时。当代理执行 check_in 下载软件包或 wss 服务未能向代理推送 convert_commnad 时，可能就会出现通信问题。

并非所有代理都支持将代理从一种类型（例如深度可视性）转换为另一种类型（例如执行）。如果无法执行转换的代理需要转换，则会报告异常。

代理上次报告的当前策略 (NPC) 版本与集群上生成的当前版本不一致。造成这种情况的原因可能是代理和集群之间的通信错误、代理未能通过本地防火墙执行策略或代理执行服务未运行。

如果 Cisco Secure Workload 代理无法打开 pcap 设备来捕获流，则您会在代理日志中看到错误。成功打开 Pcap 设备将报告如下：

I0609 15:25:52.354 24248 Started capture thread for device <device_name>
I0609 15:25:52.354 71912 Opening device {<device_id>}

I0610 03:24:22.354 16614 Opening device <device_name>
[2020/06/10 03:24:23:3524] NOTICE: lws_client_connect_2: <device_id>: address 172.29.
˓→136.139

代理与集群之间的连接在外部被阻止，因此无法传送流和其他系统信息。这是由于网络防火墙、SSL 解密服务或主机上的第三方安全代理存在一个或多个配置问题造成的。

• 如果代理和集群之间存在已知的防火墙或 SSL 解密安全设备，请确保允许与所有 Cisco Secure Workload 收集器和 VIP IP 地址的通信。对于本地集群，收集器列表将在 Cisco Secure Workload Web 界面左侧导航栏中的故障排除 (Troubleshoot) > 虚拟机 (Virtual Machines) 下列出。查找 collectorDatamover-*。对于 Cisco Secure Workload 云，您的门户中将列出所有需要允许的 IP 地址。

• 为了帮助确定是否存在 SSL 解密，可使用 openssl s_client 来建立连接并显示返回的证书。添加到证书链中的任何其他证书都将被代理的本地 CA 拒绝。SSL 故障排除

  Note	通常，用于更新“流量导出异常状态”的服务每 5 分钟运行一次。由于代理的状态更新是以 5000 次为一小批量执行的，因此持续时间可能会有所不同。因此，当集群中的代理较少时，更新速度会更快。当代理数量较多时，更新时间最长可达 70 分钟。 在对数据库中的代理记录进行初步排序后，集群和代理就会变得稳定，最终，更新间隔会越来越小，一致性也会越来越好。

• 运行命令 winver.exe

• 将此版本与此处列出的版本进行比较：支持的平台和要求

• 运行 cat /etc/os-release

• 将此版本与此处列出的版本进行比较：支持的平台和要求

• 运行命令 uname -a

• 注意：主要版本与次要版本是相反的

  p7-ops2> # uname -a
  AIX p7-ops2 1 7 00F8AF944C00

• 在本例中，主机名后的第一个数字是次版本，第二个数字是主版本，即 AIX 7.1 版。将此版本与此处列出的版本进行比较：支持的平台和要求

• 如果进程当前正在使用 Npcap 库，则 Npcap 有时会无法正确卸载。要对此进行检查，请运行以下命令：

  PS C:\Program Files\Npcap> .\NPFInstall.exe -check_dll
  WindowsSensor.exe, Wireshark.exe, dumpcap.exe
  

如果您看到列出的进程，则必须先将其停止，然后才能继续 Npcap 升级。如果没有进程在使用 Npcap，上述命令将仅显示 <NULL>

• 检查系统上安装的 CA 证书：NPCAP 安装程序的证书问题

• 检查 Windows 安装程序问题：Windows 安装程序问题

• 确认系统上没有其他用户正在对网络接口进行更改。否则可能会导致 COM 锁定，从而阻止 NDIS 驱动程序绑定。

仅适用于 Windows 2016

如果您在设置中具有第三方 LWF（轻量级过滤器）驱动程序（例如 netmon）或配置了组合适配器，并且在代理部署期间安装了 NPCAP，您可能会遇到

RDP 已重新连接

NetBIOS 服务已重启

类似网络连接问题

这是由 Windows 2016 操作系统中的 BUG 导致的

组合 NIC 功能基于底层物理 NIC（Intel、Broadcom、Realtek、MS 虚拟适配器等）和组合驱动程序配置（基于交换机、负载均衡或确保您的策略能解决不常见或不经常发生的活动和情况，如故障转移、从备份恢故障转移、在多个 NIC 之间分发数据包的算法）。

某些 NPCAP 版本存在与组合 NIC 的兼容性问题，尤其是在绑定到下面的组合 NIC 期间。

NIC type : Intel(R) 82574L Gigabit Network Connection
Teaming Mode : Switch Independent
Load Balancing Mode: Address Hash
OS : Windows 2012 , Windows 2012 R2, Windows 2016, Windows 2019
NPCAP version: 1.55

Note	Windows 2008R2 不支持 Microsoft 支持的 NIC 组合。

当 NPCAP 服务运行时，TetSensor 服务有时不会捕获克隆虚拟机上的网络流。如果使用 MSI 安装程序安装代理时没有 nostart 标志，或使用 PowerShell 安装程序在虚拟机模板或黄金镜像上安装代理时没有 goldImage 标志，就会出现这种情况。

在这种情况下，Cisco Secure Workload 代理服务将开始在 VM 模板上运行。已安装 NPCAP 并将其绑定到虚拟机模板上的网络堆栈。从虚拟机模板克隆新虚拟机时，NPCAP 未正确绑定到新克隆虚拟机上的网络堆栈。因此，NPCAP 无法捕获网络流。

据观察，当 Windows TetSensor 服务运行时，网络性能会受到影响。Windows Tet- 传感器服务 (tetsen.exe) 使用 NPCAP 捕获网络流。实施 NPCAP 以捕获网络流以及流向 tetsen.exe 的网络流会影响网络性能。

在安装 tetsensor 后比较网络性能，客户端：Windows 2016

NPCAP 1.55

TetSensor 配置：具有执行模式 WFP 的对话模式

服务器：Windows 2016

NPCAP 1.55

TetSensor 配置：具有执行模式 WFP 的对话模式

运行 cmd : iperf3.exe -c <server_ip> -t 40

使用 NPCAP 0.9990 时的网络性能

在安装 tetsensor 后比较网络性能，客户端：Windows 2016

NPCAP 0.9990

TetSensor 配置：具有执行模式 WFP 的对话模式

服务器：Windows 2016

NPCAP 0.9990

TetSensor 配置：具有执行模式 WFP 的对话模式

运行 cmd : iperf3.exe -c <server_ip> -t 40 .. table:: 使用 NPCAP 0.9990 时的网络性能

class 长表

Note	性能可能因安装的 Windows NPCAP 版本、Windows 操作系统和网络配置而异。

如果 Cisco Secure Workload 软件不支持安装的 NPCAP 版本或 NPCAP 配置，操作系统可能会遇到未知的性能或稳定性问题。

支持的 NPCAP 版本：0.991 和 1.55

• WSS：通过端口 443 与集群建立持久性套接字连接

• 签入：每 15-20 分钟对集群进行一次 HTTPS 调用，以检查当前配置、检查更新以及将代理的活动状态更新到集群。这也会报告升级失败。

• 流导出：通过端口 443 (TaaS) 或 5640（内部部署）建立持久性 SSL 连接，以将流元数据发送到集群

• 执行：通过端口 443 (Taas) 或 5660（内部部署）建立持久性 SSL 连接，以获取执行策略并报告执行状态

迭代 UI 将报告代理处于非活动状态（不再签入）、没有导出的流（在“代理工作负载配置文件”(Agent Workload Profile) 页面上的“统计信息”(Stats) 下））或执行失败。根据错误的情况，您可以检查工作负载上的不同日志，以帮助确定问题的根源。

Tue 06/09/2020 17:25:25.08 check_conf_update: "curl did not return 200 code, it's 304,
˓→ exiting"
Tue 06/09/2020 17:25:25.08 check_conf_update: "error code after running check_conf_
˓→update = 2"

cfgserver.go:261] config server: StateConnected, wss://<config_server_ip>:443/wss/
˓→<sensor_id>/forensic, proxy:

collector.go:258] next collector: StateConnected, ssl://<collector_ip>>:5640

ssl_client.cpp:341] Successfully connected to EFE server

Cisco Secure Workload 代理使用 TLS 来保护与 Cisco Secure Workload 云 SaaS 服务器的 TCP 连接。这些连接分为三个不同的通道。

• 代理 -> 端口 TCP/443 (TLS) (sensorVIP) 上的思科 Cisco Secure Workload SaaS 控制通道

  这是一个低容量控制通道，允许代理向 Cisco Secure Workload 注册，并且还处理配置推送和软件升级通知。

• 代理 -> 思科 Cisco Secure Workload TCP/443 (TLS) 上的 SaaS 流数据（收集器）

  流数据是提取的流元数据信息；数据将一次发送到一组 16 个 IP 地址。第二组 IP 地址用于备用设备。这大约是实际服务器流量的 1-5%。

• 代理 -> Cisco Cisco Secure Workload TCP/443 (TLS) (efe) 上的 SaaS 执行数据

  执行数据通道是一个低容量控制通道，用于将策略推送到传感器，并收集执行统计信息。

传感器根据随代理安装的本地 CA 验证来自 Cisco Secure Workload 云控制、数据和执行服务器的 TLS 证书。由于不使用其他 CA，因此发送到代理的任何其他证书都将导致验证失败，并且代理将无法连接。这将导致代理无法注册、签入、发送流或接收执行策略。

如上一部分所述，配置显式或透明 Web 代理，以绕过 SSL/TLS 解密进行代理通信非常重要。如果没有配置绕行，这些代理可能会尝试解密

SSL/TLS 流量，向代理发送自己的证书。由于代理只使用本地 CA 验证证书，因此这些代理证书会导致连接失败。

症状包括代理无法注册到集群、代理未签入、代理未发送流和/或代理未接收执行配置（如果已启用执行）。

Note	以下故障排除步骤假设使用了默认安装路径。Windows：C:Program FilesCisco Tetration Linux: /usr/local/tet。如果您将代理安装在其他位置，请在说明中替换该位置。

代理日志中会报告 SSL/TLS 连接问题。要验证日志中是否存在 SSL 错误，请针对观察到的相关问题运行以下命令。

grep "NSS error" /usr/local/tet/log/check_conf_update.log

get-content "C:\Program Files\Cisco Tetration\logs\TetUpdate.exe.log" | select-
˓→string -pattern "curl failed SSL peer certificate"

grep "SSL connect error" /usr/local/tet/log/tet-sensor.log

get-content "C:\Program Files\Cisco Tetration\logs\WindowsSensor*.log" | select-
˓→string -pattern "Certificate verification error"

grep "Unable to validate the signing cert" /usr/local/tet/log/tet-enforcer.log

get-content "C:\Program Files\Cisco Tetration\logs\WindowsSensor*.log" | select-
˓→string -pattern "Handshake failed"

curl -v -x http://<proxy_address>:<port> https://<sensorVIP>:443

cd "C:\Program Files\Cisco Tetration"
.\curl.exe -kv -x http://<proxy_address>:<port> https://<sensorVIP>:443

openssl s_client -connect <sensorVIP from TaaS Portal>:443 -CAfile /usr/local/tet/
˓→cert/ca.cert

cd C:\Program Files\Cisco Tetration
.\openssl.exe s_client -connect <sensorVIP from TaaS Portal>:443 -CAfile cert\ca.cert

Verify return code: 0 (ok)

0 s:/C=US/ST=CA/L=San Jose/O=Cisco Systems, Inc./OU=Tetration, Insieme BU/CN=129.146.
˓→155.109
i:/C=US/ST=CA/L=San Jose/O=Cisco Systems, Inc./OU=Tetration Analytics/CN=Customer CA

[Net.ServicePointManager]::SecurityProtocol

Ssl3, Tls

[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Ssl3,
˓→Tls,Tls11,Tls12'