软件代理的安装后任务及详细说明

（仅限手动安装）更新用户配置文件

只有涉及以下所有内容的安装才需要执行以下程序：

  • Cisco Secure Workload SaaS 或具有多个租户的本地集群（仅使用默认租户的本地集群不需要此程序）

  • 手动安装

  • Linux 或 Windows 平台

代理需要激活密钥才能注册到 Cisco Secure Workload 集群。它们需要使用集群激活密钥。此外，他们可能需要使用 HTTPS 代理来访问集群。


Note

在 Windows 环境中，如果手动安装时使用了激活密钥和代理选项，则无需手动配置 user.cfg。

在安装前，请在用户配置文件中配置所需的变量：

Procedure

Step 1

要检索激活密钥，请导航至管理 (Manage) > 代理 (Agents)，点击安装程序 (Installer) 选项卡，点击使用经典打包安装程序手动安装 (Manual Install using classic packaged installers)，然后点击代理激活密钥 (Agent Activation Key)。

Step 2

打开 Cisco Secure Workload 代理安装文件夹中的 user.cfg 文件。（例如：Linux 上的 /usr/local/tet 或 Windows 上的 C:\Program Files\Cisco Tetration ）。该文件包含“key=value”形式的变量列表，每行一个。

Step 3

将激活密钥添加到 ACTIVATION_KEY 变量。示例：ACTIVATION_KEY=7752163c635ef62e6568e9e852d07bd21bfd60d0

Step 4

如果代理需要 HTTPS 代理，请使用 HTTPS_PROXY 变量来添加 http 协议代理服务器和端口。示例：HTTPS_PROXY=http://proxy.my-company.com:80

其他类代理工具

AnyConnect 代理

具有网络可视性模块 (NVM) 的思科 AnyConnect 安全移动代理支持的平台不需要 Secure Wrokload 代理。AnyConnect 连接器会注册这些代理，并将流观察结果、资产和标签导出到 Cisco Secure Workload。有关详细信息，请参阅 AnyConnect 连接器。

对于 Windows、Mac 或 Linux 平台，请参阅《思科 AnyConnect 安全移动客户端产品手册》。

ISE 代理

向 Cisco Identity Services Engine (ISE) 注册的终端不需要在终端上安装 Cisco Secure Workload 代理。ISE 连接器通过 ISE 设备上的 pxGrid 服务从 ISE 收集有关终端的元数据。它将终端注册为 Cisco Secure Workload 上的 ISE 代理，并推送这些终端上资产的标签。有关详细信息，请参阅 ISE 连接器。

SPAN 代理

SPAN 代理与 ERSPAN 连接器配合使用。有关详细信息，请参阅 ERSPAN 连接器。

第三方和其他思科产品

  • 对于使用 Cisco Secure Workload中配置的外部协调器的集成，

    请参阅Cisco Secure Workload中的“外部协调器”。

  • 对于使用在 Cisco Secure Workload中配置的连接器的集成。

    请参阅什么是连接器。

连接信息

在工作负载上安装代理时，它通常会与 Cisco Secure Workload 集群上托管的后端服务建立多个网络连接。连接数会因代理类型及其功能而异。

下表记录了各种代理类型建立的各种永久连接。

Table 1. 代理连接

代理类型

配置服务器

收集器

执行后端

可视性（本地）

CFG-SERVER-IP:443

COLLECTOR-IP:5640

不适用

可视性 (SaaS)

CFG-SERVER-IP:443

COLLECTOR-IP:443

不适用

安全策略

（本地）

CFG-SERVER-IP:443

COLLECTOR-IP:5640

ENFORCER-IP:5660

执行 (SaaS)

CFG-SERVER-IP:443

COLLECTOR-IP:443

ENFORCER-IP:443

docker 映像

CFG-SERVER-IP:443

不适用

不适用

图例：

  • CPG-SERVER-IP 是配置服务器的 IP 地址。

  • COLLECTOR-IP 是收集器的 IP 地址。深度可视性和执行代理连接到所有可用的收集器。

  • ENFORCER-IP 是执行终端的 IP 地址。执行代理仅连接到其中一个可用终端。

  • 对于 Kubernetes/OpenShift 代理部署，安装脚本不包含代理软件 - 包含代理软件的 Docker 映像由每个 Kubernetes/OpenShift 节点从 Cisco Secure Workload 集群提取。这些连接由容器运行时映像获取组件建立，并指向 CFG-SERVER-IP:443。

导航至平台 (Platform) > 集群配置 (Cluster Configuration)，了解配置服务器 IP 和收集器 IP。

  • 传感器 VIP (Sensor VIP) 用于配置服务器 IP：已为此集群中的配置服务器设置的 IP 地址。

  • 外部 IP 用于收集器 IP 和执行器 IP：如果填充此字段，则在分配外部集群 IP 地址时，选择过程仅限于此列表中定义的属于外部网络的 IP 地址。


Note

  • Cisco Secure Workload 代理始终充当客户端以发起与集群内托管的服务的连接，并且从不会作为服务器打开连接。

  • 支持升级的代理会定期向集群传感器 VIP 执行 HTTPS 请求（端口 443），以查询可用的软件包。

  • 代理可以位于 NAT 服务器后面。

如果工作负载位于防火墙后面，或者主机防火墙服务已启用，则到集群的连接可能会被拒绝。在此情况下，管理员必须创建适当的防火墙策略来允许连接。

安全排除项

软件代理在正常运行过程中会不断与主机操作系统交互。此操作可能会导致主机上安装的其他安全应用（例如防病毒软件、安全代理等）发出警报，或者阻止 Cisco Secure Workload 代理的操作。因此，为确保代理安装成功并正常运行，必须在监控主机的安全应用上配置必要的安全排除。

Table 2. 代理目录的安全排除项

主机操作系统

目录

AIX

/opt/cisco/tetration

Linux

/usr/local/tet 或 /opt/cisco/tetration 或 <user chosen inst dir>

/var/opt/cisco/secure-workload

Windows

C:\Program Files\Cisco Tetration

C:\ProgramData\Cisco Tetration

Solaris

/opt/cisco/secure-workload
Table 3. 代理进程的安全排除项

主机操作系统

进程

AIX

csw-agent

tet-sensor

tet-enforcer

tet-main

Linux

csw-agent

tet-sensor

tet-enforcer

tet-main

执行器

Windows

CswEngine.exe

TetEnfC.exe

Solaris

csw-agent

tet-sensor

tet-enforcer

tet-main
Table 4. 代理操作的安全排除项

主机操作系统

操作

AIX

访问 /dev/bpf*、/dev/ipl、/dev/ kmem
调用 cfg_ipf、ipf、ippool、ipfstat lslpp、lsfilt、prtconf、uname、uncompress、oslevel

扫描 /proc

启用取证功能时，系统会修改 /etc/security/audit/config 和 /etc/security/audit/objects，并创建对应的备份文件 /etc/security/audit/config.backup 和 /etc/security/audit/objects.backup。

Linux

调用 ip[6]tables-save、ip[6]tables-restore、rpm/dpkg、uname、unzip

扫描 /proc，打开 netlink 套接字

Windows

访问注册表

注册到防火墙事件

调用 c:\windows\system32\netsh.exe

Solaris 11.4

调用 pkg、ps、smbios（仅限 x86）、uname、unzip

扫描 /proc

在启用调查分析时创建 /etc/audit/rules.d/taau.rules

Solaris 10

pkgrm、pkgchk、pkgadd、ps

Scan/proc、prtconf、virtinfo（仅限 sparc）、svcadm、pfctl、uname、unzip

在启用调查分析时创建 /etc/audit/rules.d/taau.rules
Table 5. 代理脚本或二进制文件执行的安全排除项

主机操作系统

调用的脚本/二进制文件

AIX

-

Linux

-

Windows

dmidecode.exe

npcap-installer.exe

sensortools.exe

signtool.exe

Solaris

-

代理的服务管理

软件代理作为一项服务部署在所有支持的平台上。本部分介绍管理各种功能和平台的服务的方法。


Note

除非另有说明，否则此部分中的所有命令都需要 Linux 或 Unix 上的根权限或 Windows 上的管理权限方可运行。

RHEL、CentOS、OracleLinux-6.x 和 Ubuntu-14 的服务管理

为以下各项运行命令：

  • 启动服务：start csw-agent

  • 停止服务：stop csw-agent

  • 重启服务：restart csw-agent

  • 检查服务状态：status csw-agent

适用于 RHEL、CentOS、OracleLinux-7.x 及更高版本的服务管理

命令也适用于：

  • AlmaLinux，Rocky Linux-8.x 及更高版本

  • Amazon Linux 2 及更高版本

  • Debian 8 及更高版本

  • SLE-12SPx 及更高版本

  • Ubuntu-16.04 及更高版本

为以下各项运行命令：

  • 启动服务：systemctl start csw-agent

  • 停止服务：systemctl stop csw-agent

  • 重启服务：systemctl restart csw-agent

  • 检查服务状态：systemctl status csw-agent

Windows Server 或 Windows VDI 服务管理

为以下各项运行命令：

  • 启动服务：net start <service-name>

    示例：用于深度可视性和执行服务的 net start cswagent

  • 停止服务：net stop <service-name>

    示例：用于深度可视性和执行服务的 net stop cswagent

  • 重启服务：

    1. net stop <service-name>

    2. net start <service-name>

  • 检查服务状态：sc query <service-name>

    示例：用于深度可视性和执行服务的 sc.exe query CswAgent

AIX 的服务管理

为以下各项运行命令：

  • 启动服务：startsrc -s csw-agent

  • 停止服务：stopsrc -s csw-agent

  • 重启服务：

    1. stopsrc -s csw-agent

    2. startsrc -s csw-agent

  • 正在检查服务状态：lssrc -s csw-agent

Kubernetes 代理安装的服务管理

  • 启动或停止服务：无法在特定节点上启动或停止代理，因为它们不是作为单个服务安装的，而是作为整个集群的后台守护程序集安装的。

  • 在节点上重启代理：找到节点上的 Cisco Secure Workload 代理 Pod，并运行相应的 Kubernetes 命令将其终止。Pod 将自动重启。

  • 检查 Pod 的状态：kubectl get pod -n tetration 或 oc get pod -n tetration（适用于 OpenShift）会列出 Kubernetes 集群中所有 Cisco Secure Workload 代理 Pod 的状态。

Solaris 服务管理

为以下各项运行命令：

  • 启动服务：svcadm enable csw-agent

  • 停止服务：svcadm disable csw-agent

  • 重启服务：svcadm restart csw-agent

  • 检查服务状态：svcs -l csw-agent

在工作负载配置文件中查看详细的代理状态

Procedure

Step 1

请按照上述步骤检查代理状态。

Step 2

在“执行代理”(Enforcement Agents) 页面上，点击代理操作系统分发 (Agent OS Distribution)。选择操作系统，然后点击框右上角的过滤器映像。

Step 3

“软件代理列表”(Software Agent List) 页面上将列出具有所选操作系统分布的代理。

Step 4

点击代理 (Agent) 以查看代理详细信息，然后点击 IP 地址。在“工作负载配置文件”(Workload Profile) 页面上，您可以查看主机配置文件、代理配置文件和代理特定详细信息的详细信息，例如带宽、长期存在的进程、软件包、进程快照、配置、接口、统计信息、策略、容器策略等。

Step 5

点击配置 (Config) 选项卡以查看终端主机上的配置。

Step 6

点击策略 (Policies) 选项卡以查看终端主机上已执行的策略。

Figure 1. 工作负载配置文件 - 配置
工作负载配置文件 - 配置
Figure 2. 工作负载配置文件 - 策略
工作负载配置文件 - 策略

Note

 

Windows 代理主机不支持获取所有统计信息 (Fetch All Stats)，后者用于为单个策略提供统计信息。

生成代理令牌

在代理配置文件中，您可以启用服务保护，以防止卸载、禁用和停止 Windows 代理服务。要对代理执行任何更改，可以在代理配置文件上禁用此保护。但是，如果由于连接问题而无法禁用保护，则可以生成代理令牌以禁用工作负载上的服务保护。令牌有效期为 15 分钟。

支持生成和检索代理令牌的角色：

  • 站点管理员：适用于集群或租户。

  • 客户支持：适用于租户。

  • 代理安装程序：用于代理特定的令牌。

  • 租户所有者 (Tenant owner)：适用于 SaaS 租户。


Note

您只能为基于 Windows 操作系统的软件代理生成基于时间的代理令牌。

要生成和下载代理令牌，请执行以下步骤：

Procedure

Step 1

在导航窗格中，点击管理 (Manage) > 工作负载 (Workloads) > 代理 (Agents) > 代理列表 (Agent List)。

根据要求，您可以选择代理令牌类型之一 - 集群、租户或特定代理。对于代理特定令牌，请转至步骤 5。

Step 2

点击菜单图标并选择代理令牌 (Agent Token)。

Note

 

代理令牌 (Agent Token) 选项仅对站点管理员或客户支持用户角色可见。

Step 3

选择令牌类型：

  • 集群令牌 (Token For Cluster) - 此选项仅对站点管理员可见，并且令牌适用于所有代理。
  • 租户令牌 (Token For Tenant) - 适用于所选租户下的代理。

Step 4

要下载令牌密钥，请点击下载令牌 (Download Token)。

Step 5

要查看和下载特定代理的令牌密钥详细信息，请执行以下操作：

  1. 转到代理列表 (Agent List) 选项卡，然后点击所需的代理。在代理详细信息 (Agent Details) > 代理令牌 (Agent Token) 下，您可以查看令牌的令牌密钥和到期详细信息。

  2. 要下载代理特定的令牌，请点击下载令牌 (Download Token)。

What to do next

下载代理令牌文件后，在代理上运行以下命令以禁用服务保护："C:\Program Files\Cisco Tetration\TetSen.exe” -unprotect <token>，其中 token 是下载的代理令牌。

使用令牌禁用服务保护后，服务保护可能会在服务重启并连接到 Cisco Secure Workload 集群时自动重新启用。

禁用工作负载执行

作为租户所有者，您可以在故障排除时选择性地禁用对工作负载的执行。禁用执行会覆盖工作负载的配置，并且您可以在故障排除完成后恢复到初始执行状态。

要禁用对工作负载的执行，请执行以下程序。

Procedure

Step 1

从导航窗格中，选择管理 (Manage) > 工作负载 (Workloads) > 代理 (Agents) > 代理列表 (Agent List)。

Step 2

点击要为其禁用执行的代理旁边的执行 (Enforcement)。

Figure 3. 禁用工作负载执行

Step 3

要在代理上禁用执行，请在代理控制 (Agent Controls) 下点击禁用执行 (Disable Enforcement)。

Step 4

在显示的对话框中确认操作。

Step 5

（可选）同样，如果要在任何代理上重新启用执行，请在代理控制 (Agent Controls)下点击启用执行 (Enable Enforcement)，并在显示的对话框中确认操作。

启用执行时主机 IP 地址更改

作为站点管理员，如果在代理上已启用执行的情况下更改主机的 IP 地址，则在主机防火墙规则中发现该主机 IP 地址且全部捕获设置为“拒绝”时，可能会产生影响。

在这种情况下，请执行以下步骤来更改主机 IP 地址：

Procedure

Step 1

在 Cisco Secure Workload UI 上，创建新代理配置文件并禁用执行。

Step 2

创建包含需要更改 IP 地址的主机及其旧地址和新地址的列表。

Step 3

将新创建的代理配置文件应用于意图并保存意图。

Step 4

选择要更改其 IP 地址的主机，并确保已禁用这些主机的执行。

Step 5

更改所选主机的 IP 地址。

Step 6

在 Cisco Secure Workload UI 上，通过包含这些主机的新 IP 地址来更新范围内的过滤器。

Step 7

在接口 (Interfaces) > 代理工作负载配置文件 (Agent Workload Profile) 选项卡下，验证 IP 地址是否已更改为新的 IP 地址。

Step 8

在策略 (Policies) 选项卡下，确保使用新 IP 地址生成策略。

Step 9

删除之前创建的意图或配置文件。

Step 10

点击启用执行 (Enable Enforcement)，在已禁用执行的较早代理配置配置文件的范围内启用执行。

常见问题解答

本部分列出了在部署和运行软件代理期间可能会遇到的一些问题。

概述

日志文件：日志文件存储在 <install-location>/logs 或 <install-location>/log 文件夹。日志文件通过 Cisco Secure Workload 服务进行监控和轮换。

代理部署

Linux

问：当命令无法安装代理并显示以下错误时， 
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）

Windows

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

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

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

答：这很可能是因为主机和服务器配置的 SSL/TLS 协议不匹配所致。可以使用以下命令检查 SSL/TLS 版本：

[Net.ServicePointManager]::SecurityProtocol
要设置与服务器匹配的 SSL/TLS，可以使用以下命令（请注意，这并非永久性更改，只是当前 PowerShell 会话的临时更改）：

[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]’Ssl3,Tls,Tls11,Tls12’
问：从下载的捆绑包运行 MSI 安装程序时，收到以下错误：

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.
答：确保 C:\Windows\Installer 路径存在。如果是从命令行运行 MSI 安装程序，请确保在指向 MSI 文件时不包含相对路径。正确语法示例： 

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

答：对于 Windows，PATH 变量中可能没有 system32。检查 PATH 中是否有 system32，如果没有，则运行以下命令： 

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

如果在 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 后，故障排除步骤相同。

异常类型

以下是使用和管理 Cisco Secure Workload 代理时工作流程中最常见的问题。

代理不活动

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

  • 主机可能已关闭

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

  • 该代理服务已停止

所有平台

  • 验证主机是否处于活动状态且运行正常

  • 验证代理服务已启动且正在运行

  • 验证与集群的网络连接是否正常

升级失败

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

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

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

Windows

  • 缺少 CA 根证书：证书问题

  • 如果代理最初是使用 MSI 安装软件包手动安装的，请检查 Windows 版本是否与用户指南中支持的平台列表匹配：检查当前是否支持平台

  • 检查以确保已为 Windows Installer 操作正确配置操作系统：Windows Installer Issues

  • 确保主机上有足够的可用磁盘空间

Linux

  • 如果自上次安装代理以来已升级主机操作系统，请验证当前版本是否与用户指南中支持的平台列表匹配：检查当前是否支持平台

  • 确保自上次安装以来所需的依赖关系未发生任何更改。您可以使用 –no-install 选项来运行代理安装程序脚本，以重新验证这些依赖关系。

  • 确保主机上有足够的可用磁盘空间

AIX

  • 确保自上次安装以来所需的依赖关系未发生任何更改。您可以使用 –no-install 选项来运行代理安装程序脚本，以重新验证这些依赖关系。

  • 确保主机上有足够的可用磁盘空间

转换失败

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

所有平台

转换功能

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

策略未同步

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

Windows

  • 如果执行模式为 WAF，请验证主机上不存在会阻止防火墙启用的 GPO，从而添加规则（关闭“保留规则”）或设置默认操作：GPO 配置

  • 验证主机和集群之间是否存在连接：SSL 故障排除

  • 验证生成的规则计数是否小于 2000

  • 验证 WindowsAgentEngine 服务是否正在运行：sc query windowsagentengine

  • 验证是否有可用的系统资源

Linux

  • 使用 iptables 和 ipset 命令来验证 iptables 和 ipset 是否存在

  • 验证主机和集群之间是否存在连接：SSL 故障排除

  • 验证 tet-enforcer 进程是否正在运行：ps -ef | grep tet-enforcer

AIX

  • 使用 ipf -V 命令验证 ipfilter 是否已安装并正在运行

  • 验证主机和集群之间是否存在连接：SSL 故障排除

  • 验证 tet-enforcer 进程是否正在运行：ps -ef | grep tet-enforcer

流导出：Pcap 打开

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

Windows 日志：C:\Program Files\Cisco Tetration\Logs\TetSen.exe.log
I0609 15:25:52.354 24248 Started capture thread for device <device_name>
I0609 15:25:52.354 71912 Opening device {<device_id>}
Linux 日志：/usr/local/tet/logs/tet-sensor.log
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

流导出：HTTPS 连接

代理与集群之间的连接在外部被阻止，因此无法传送流和其他系统信息。这是由于网络防火墙、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 分钟。

    在对数据库中的代理记录进行初步排序后，集群和代理就会变得稳定，最终，更新间隔会越来越小，一致性也会越来越好。

流导出：eBPF

在版本 3.10.1.1 中，Cisco Secure Workload 代理在以下发行版上使用扩展伯克利数据包过滤器 (eBPF)：

  • Ubuntu 22/24

  • Debian 11/12

  • EL9 系列

若 Cisco Secure Workload 代理无法使用 eBPF 捕获流量，您将在代理日志中看到错误信息。

每个网络设备的流量捕获成功状态会如下所示：

Linux 日志：/usr/local/tet/logs/tet-sensor.log
I0604 21:29:20.357 833292 Opening device <device_name>
I0604 21:29:20.394 833292 Using eBPF TC to capture packets for <device_name>

证书问题

Windows

MSI 安装程序的证书问题

MSI 安装程序使用代码签名证书进行签名：

对于 MSI 安装程序，版本 3.6.x 及更高版本和 3.5.1.31 及更高版本

  • 分支证书：Cisco Systems, Inc

  • 中间证书：DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1

  • 根证书：DigiCert Trusted Root G4

对于 MSI 安装程序，早期版本

  • 分支证书：Cisco Systems, Inc

  • 中间证书：Symantec Class 3 SHA256 Code Signing CA

  • 根证书：VeriSign Class 3 Public Primary Certification Authority - G5

它使用时间戳证书：

对于 MSI 安装程序，版本 3.6.x 及更高版本和 3.5.1.31 及更高版本

  • 分支证书：Symantec SHA256 TimeStamping Signer - G3

  • 中间证书：Symantec SHA256 TimeStamping CA

  • 根证书：VeriSign Universal Root Certification Authority

对于 MSI 安装程序，早期版本

  • 分支证书：Symantec SHA256 Timestamping Signer - G2

  • 中间证书：Symantec SHA256 Timestamping CA

  • 根证书：VeriSign Universal Root Certification Authority

如果 MSI 安装程序的数字签名无效，则 Windows 传感器安装或升级将失败。以下情况时数字签名无效：

  • MSI 安装程序签名根证书或 MSI 安装程序时间戳根证书不在“受信任的根证书颁发机构”存储区内

  • MSI 安装程序签名根证书或 MSI 安装程序时间戳根证书过期或被撤销。

问题 1

代理安装可能会失败，TetUpdate.exe.log 中会出现以下错误：“Msi signature is not trusted. 0x800b0109"

解决方法

  • 从命令提示符运行命令 certmgr

  • 检查 MSI 安装程序签名根证书或 MSI 安装程序时间戳根证书是否在不受信任的证书 (Untrusted Certificates) 存储区中。

  • 将其移至受信任的根证书颁发机构 (Trusted Root Certification Authority) 存储区。

问题 2

Windows 传感器升级失败，TetUpdate.exe.log 中出现以下错误：“Msi signature is not trusted. 0x800B010C"

证书已被其颁发者明确撤销。

解决方法

  • 从命令提示符运行命令 certmgr

  • 检查 MSI 安装程序签名根证书或 MSI 安装程序时间戳根证书是否在不受信任的证书 (Untrusted Certificates) 存储区中。

  • 将其复制到受信任的根证书颁发机构 (Trusted Root Certification Authority) 存储区。

问题 3

Windows 传感器升级失败，TetUpdate.exe.log 中出现以下内容：“Msi signature is not trusted. 0x80096005"

解决方法

  • 从命令提示符运行命令 certmgr

  • 检查 MSI 安装程序签名根证书或 MSI 安装程序时间戳根证书是否在“受信任的根证书颁发机构”存储区内

如果证书缺失，请从其他计算机导入证书。

要导入证书，请执行以下步骤：

首先从其中一个工作服务器导出 VeriSign 通用根证书颁发机构的证书。请按照以下步骤操作：

  • 从命令提示符运行命令 certmgr

  • 右键点击“受信任的根证书颁发机构”(Trusted Root Certification Authorities) 下的“VeriSign 通用根证书颁发机构”(VeriSign Universal Root Certification Authority) 证书，然后转到“所有任务导出”(All tasksExport)。

  • 将导出的证书复制到非工作服务器，然后导入证书。

要导入证书，请执行以下步骤：

首先从其中一个工作服务器导出 VeriSign 通用根证书颁发机构的证书。请按照以下步骤操作：

  • 从命令提示符运行命令 certmgr

  • 右键点击“受信任的根证书颁发机构”(Trusted Root Certification Authorities) 下的证书选项卡，然后转到“所有任务导入”(All tasksImport)。

  • 选择复制的根证书并将其添加到存储库中。

NPCAP 安装程序的证书问题

适用于 Windows 2012、Windows 2012 R2、Windows 8、Windows 8.1

NPCAP 版本：1.55

NPCAP 签名证书：

  • 分支证书：Insecure.Com LLC

  • 中间证书：DigiCert EV Code Signing CA (SHA2)

  • 根证书：DigiCert High Assurance EV Root CA

NPCAP 时间戳证书：

  • 分支证书：DigiCert Timestamp 2021

  • 中间证书：DigiCert SHA2 Assured ID Timestamping CA

  • 根证书：DigiCert Assured ID Root CA

问题 1

Windows 代理安装可能会失败，msi_installer.log 中会出现以下错误
CheckServiceStatus : Exception System.InvalidOperationException: Service npcap was not found on computer 
‘.’. —> System.ComponentModel.Win32Exception: The specified service does not exist as an installed service

解决方法

  • 从命令提示符运行命令 certmgr

  • 选中“受信任的根证书颁发机构”(Trusted Root Certification Authority) 存储区中的“DigiCert High Assurance EV Root CA”。

  • 如果证书缺失，请从其他计算机导入证书。

要导入证书，请执行以下步骤：

首先从其中一个工作服务器导出证书“DigiCert High Assurance EV Root CA”。请按照以下步骤操作：

  • 从命令提示符运行命令 certmgr

  • 右键点击“受信任的根证书颁发机构”下的证书“DigiCert High Assurance EV Root CA”，然后转到所有任务导出。

  • 将导出的证书复制到非工作服务器，然后导入证书。

要导入证书，请执行以下步骤：

  • 从命令提示符运行命令 certmgr

  • 右键点击“受信任的根证书颁发机构”(Trusted Root Certification Authorities) 下的证书选项卡，然后转到“所有任务导入”(All tasksImport)。

  • 选择复制的根证书并将其添加到存储库中。

适用于 Windows 2008 R2

NPCAP 版本：0.991

NPCAP 签名证书：

  • 分支证书：Insecure.Com LLC

  • 中间证书：DigiCert EV Code Signing CA

  • 根证书：DigiCert High Assurance EV Root CA

NPCAP 时间戳证书：

  • 分支证书：DigiCert Timestamp Responder

  • 中间证书：DigiCert Assured ID CA-1

  • 根证书：VeriSign DigiCert Assured ID Root CA

问题 1

Windows 代理安装可能会失败，msi_installer.log 中会出现以下错误
CheckServiceStatus : Exception System.InvalidOperationException: Service npcap was not found on
computer ‘.’. —> System.ComponentModel.Win32Exception: The specified service does not exist as an
installed service

解决方法

  • 从命令提示符运行命令 certmgr

  • 选中受信任的根证书颁发机构 (Trusted Root Certification Authority) 存储区中的 DigiCert High Assurance EV Root CA。

  • 如果证书缺失，请从其他计算机导入证书。

要导入证书，请执行以下步骤：

首先从其中一个工作服务器导出证书“DigiCert High Assurance EV Root CA”。请按照以下步骤操作：

  • 从命令提示符运行命令 certmgr

  • 右键点击“受信任的根证书颁发机构”下的证书“DigiCert High Assurance EV Root CA”，然后转到所有任务导出。

  • 将导出的证书复制到非工作服务器，然后导入证书。

要导入证书，请执行以下步骤：

  • 从命令提示符运行命令 certmgr

  • 右键点击“受信任的根证书颁发机构”(Trusted Root Certification Authorities) 下的证书选项卡，然后转到“所有任务导入”(All tasksImport)。

  • 选择复制的根证书并将其添加到存储库中。

Windows 主机重命名

场景 1：重命名 Windows 主机后无法查看 IP 地址和 VRF 信息，解决该问题的步骤如下：

  • 从 TaaS UI 中删除条目（使用缺少 IP 地址和 VRF 信息的新主机名）。

  • 从 Windows 主机卸载“Cisco Cisco Secure Workload Agent”，并删除“Cisco Tetration”目录（该目录的路径通常为：“C:Program FilesCisco Tetration”）。

  • 在 Windows 主机上安装“Cisco Cisco Secure Workload Agent”。

按照上述步骤，代理就能成功在 TaaS UI 上注册 IP 地址和 VRF 信息。

场景 2：计划中的 Windows 主机重命名（提前），要遵循的步骤：

  • 从 Windows 主机卸载“Cisco Cisco Secure Workload Agent”，并删除“Cisco Tetration”目录（该目录的路径通常为：“C:Program FilesCisco Tetration”）。

  • 重命名 Windows 主机并重启。

  • 在 Windows 主机上安装“Cisco Cisco Secure Workload Agent”（使用新主机名）。

按照上述步骤进行计划的主机重命名后，代理就会在 TaaS UI 上用新的主机名注册。

检查当前是否支持平台

AIX

  • 运行命令 uname -a

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

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

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

Windows 安装程序问题

  • 确保存在 C:\Windows\Installer 目录。这不会显示在文件资源管理器中，最简单的验证方法是在 CMD 会话中并运行：dir C:\Windows\Installer

  • 检查 Windows Installer 服务是否未被禁用。它必须设置为手动 (Manual)

  • 检查 Windows Installer 是否未报告其他错误。检查 Windows 日志 (Windows Logs) > 应用 (Application) > 源 (Source) > MsiInstaller 下的 Windows 系统事件日志

必需的 Windows 服务

以下是在禁用时与代理安装问题相关联的服务列表。建议在深度可视性和执行代理的初始安装以及任何升级期间运行这些服务。

Table 6. 必需的 Windows 服务

服务

安装目的

设备设置管理器

用于安装 Npcap 过滤器驱动程序的设备驱动程序管理。

设备安装服务

也用于安装 Npcap 过滤器驱动程序。

Windows 安装程序

安装代理 MSI 软件包时需要。

Windows Firewall

对于 WAF 执行模式，此字段为必填项。

应用体验

用于确定系统上的功能可执行文件。

Note

应用体验服务仅适用于 Windows Server 2008、2008R2、2012、2012R2 和 Windows 7 版本。如果禁用，Npcap 安装过程中可能会出现文件锁，从而导致安装失败。

Npcap 问题

Npcap 是仅用于 Windows 代理的 pcap 工具。在代理服务启动十秒后，它将尝试安装 Npcap 或将其升级为支持的版本。如果 Npcap 服务无法安装或升级，代理将在接下来的 30 分钟内重试安装。在尝试 3 次失败后，如果有可用的版本，代理会尝试将 Npcap 回滚到之前支持的版本。之后，代理将不再尝试安装 Npcap。您可以检查 C:\Program Files\Cisco Tetration\Logs\TetUpdate.exe.log 和 C:\Program Files\Cisco Tetration\Logs\npcap_install.log 以确定错误。

Npcap 不会升级（手动或通过代理）

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

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

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

Npcap 不会安装

验证 Npcap 是否已完全安装

Procedure

Step 1

检查控制面板 (Control Panel) > 程序 (Programs) 和 功能 (Features)，以查看 Npcap 是否列为已安装的应用

Step 2

确保 Npcap 数据包驱动程序已绑定到相关 NIC（存在复选标记）

Step 3

检查是否安装了网络驱动程序

C:\Windows\system32>pnputil -e | findstr Nmap
Driver package provider : Nmap Project

Step 4

检查驱动程序服务是否已安装并正在运行

C:\Windows\system32>sc query npcap
SERVICE_NAME: npcap
         TYPE : 1 KERNEL_DRIVER
         STATE : 4 RUNNING

Step 5

检查注册表项是否存在（由代理用于验证 Npcap 是否已存在）

C:\Windows\system32>reg query HKLM\software\wow6432node\npcap
HKEY_LOCAL_MACHINE\software\wow6432node\npcap
          AdminOnly REG_DWORD 0x1
          WinPcapCompatible REG_DWORD 0x0
         (Default) REG_SZ C:\Program Files\Npcap

Step 6

检查已安装的 Npcap 程序文件是否齐全

C:\Windows\system32>dir "c:\program files\npcap"
 Directory of c:\program files\npcap
04/29/2020 02:42 PM <DIR> .
04/29/2020 02:42 PM <DIR> ..
01/22/2019 08:16 AM 868 CheckStatus.bat
11/29/2016 03:43 PM 1,034 DiagReport.bat
12/04/2018 11:12 PM 8,908 DiagReport.ps1
01/09/2019 09:22 PM 2,959 FixInstall.bat
04/29/2020 02:42 PM 134,240 install.log
01/11/2019 08:52 AM 9,920 LICENSE
03/14/2019 08:59 PM 10,434 npcap.cat
03/14/2019 08:57 PM 8,657 npcap.inf
03/14/2019 09:00 PM 74,040 npcap.sys
03/14/2019 08:57 PM 2,404 npcap_wfp.inf
03/14/2019 09:00 PM 270,648 NPFInstall.exe
04/29/2020 02:42 PM 107,783 NPFInstall.log
03/14/2019 09:01 PM 175,024 Uninstall.exe
         13 File(s) 806,919 bytes
          2 Dir(s) 264,417,628,160 bytes free

Step 7

检查 .sys 驱动程序文件是否位于 Windows 驱动程序文件夹中

C:\Windows\system32>dir "C:\Windows\System32\Drivers\npcap.sys"
Directory of C:\Windows\System32\Drivers
03/14/2019 09:00 PM 74,040 npcap.sys
                  1 File(s) 74,040 bytes

NPCAP 安装或升级期间的网络连接问题

仅适用于 Windows 2016

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

RDP 已重新连接

NetBIOS 服务已重启

类似网络连接问题

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

NIC 组合与 NPCAP 的兼容性问题

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

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

当前使用的 Cisco Secure Workload 传感器软件已使用 Microsoft 支持的 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 组合。

VDI 实例虚拟机不报告网络流

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

在这种情况下，Cisco Secure Workload 代理服务将开始在 VM 模板上运行。已安装 NPCAP 并将其绑定到虚拟机模板上的网络堆栈。从虚拟机模板克隆新虚拟机时，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

Table 7. 121071：使用 NPCAP 155 时的网络性能

设置

网络性能

未安装 TetSensor

无 NPCAP

[ ID] 间隔传输带宽

[ 4] 0.00-40.00 秒 18.2 GB 3.90 Gbit/秒发送方

[ 4] 0.00-40.00 秒 18.2 GB 3.90 Gbits/秒接收方

已安装 TetSensor

已安装 NPCAP

[ ID] 间隔传输带宽

[ 4] 0.00-40.00 秒 17.3 GBytes 3.72 Gbits/秒发送方

[ 4] 0.00-40.00 秒 17.3 GB 3.72 Gbits/秒接收方

使用 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 长表

设置

网络性能

已安装 TetSensor

已安装 NPCAP

[ ID] 间隔传输带宽

[ 4] 0.00-40.00 秒 16.3 GB 3.50 Gbit/秒发送方

[ 4] 0.00-40.00 秒 16.3 GBytes 3.50 Gbits/秒接收方

Note

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

操作系统性能和/或稳定性问题

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

支持的 NPCAP 版本：0.991 和 1.55

GPO 配置

执行策略的代理仅需要使用本地设置或 GPO 启用防火墙。不应设置所有其他 GPO 设置，并将其保留为“未配置”(Not Configured)。

  • 要检查 GPO 设置是否阻止执行，您可以检查 C:\Program Files\Cisco Tetration\Logs\TetEnf.exe.log 日志并搜索以下错误示例：

  • 与“Preserve Rules = No”设置冲突的规则： “组策略中设置了防火墙规则。Cisco Secure Workload 代理无权删除这些”(There are firewall rules set in the Group Policy. Secure Workload agent does not have permission to remove these)

  • 防火墙设置为关闭：“GPO 已为 DomainProfile 禁用防火墙”(GPO has disabled firewall for DomainProfile)

  • 已设置默认操作：“组策略与 DomainProfile 的默认入站操作冲突”(Group Policy has conflicting default inbound action for DomainProfile)

  • 要检查向主机应用了哪些 GPO 策略，请运行 gpresult.exe /H gpreport.html 并打开生成的 HTML 报告。在下面的示例中，如果“保留规则”(Preserve Rules) 设置为“否”(No)，则 Cisco Secure Workload 代理防火墙会应用将与执行冲突的入站规则。

代理到集群的通信

Cisco Secure Workload 代理通过多个信道来维护与集群的连接。根据代理的类型，连接数会有所不同。

连接类型

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

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

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

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

检查连接状态

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

非活动代理

Windows 日志：C:\Program Files\Cisco Tetration\Logs\TetUpdate.exe.log

Linux 日志：/usr/local/tet/logs/check_conf_update.log

预期 HTTP 响应代码为 304，表示没有配置更改。错误代码 = 2 也是预期值。任何其他 HTTP 响应代码都表示与 Cisco Secure Workload 集群上的 WSS 服务存在通信问题。 

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"

  • 304 预期值，无配置更改。签入成功

  • 401 注册不成功，缺少激活密钥 (TaaS)

  • 403 代理已注册到具有相同 UUID 的集群

  • 000 表示 SSL 连接存在问题。curl 无法访问 WSS 服务器，或者证书存在问题。请参阅 SSL 故障排除：SSL 故障排除

没有导出的流

Windows 日志：C:\Program Files\Cisco Tetration\Logs\TetSen.exe.log

Linux 日志：/usr/local/tet/logs/tet-sensor.log

以下信息表示已成功连接到 WSS

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

如果连接到 WSS 或收集器时出错，请检查防火墙配置或验证代理与 Cisco Secure Workload之间是否正在发生任何 SSL 解密。请参阅：SSL 故障排除

未能执行策略

Windows 日志：C:\Program Files\Cisco Tetration\Logs\TetEnf.exe.log

Linux 日志：/usr/local/tet/logs/tet-enforcer.log

ssl_client.cpp:341] Successfully connected to EFE server

如果连接到 EFE 服务器时出错，请检查防火墙配置或验证代理与 Cisco Secure Workload之间是否正在发生任何 SSL 解密。请参阅：SSL 故障排除

SSL 故障排除

代理通信概述

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，因此发送到代理的任何其他证书都将导致验证失败，并且代理将无法连接。这将导致代理无法注册、签入、发送流或接收执行策略。

配置代理通信的 IP 流量

大多数情况下，典型的配置是在代理（工作流程）和 Cisco Secure Workload SaaS 之间设置边界防火墙和可能的代理。

每个客户（租户）都会被分配到一个特定的 SaaS 集群。您可以在管理 (Manage) > 服务设置 (Service Settings) > IP 地址 (IP Addresses) > 服务 IP (Service IPs) 下找到该集群的 IP 地址。。

在配置防火墙或代理时，应允许以下 IP。

  • 允许通过 TLS/HTTPS 的出站端口 443。

  • 如果使用的是解密代理，请为这些 IP 配置代理绕行和 SSL/TLS 绕行。

  • 如果使用的是透明代理，则必须路由特定 SaaS IP 地址并配置绕行规则。代理无法执行自动 HTTPS 重定向。


Note

确保出站防火墙规则允许流量流向目标元数据收集器 IP。

Note

现在，您可以在用户界面上编辑出站网关 IP 地址。此功能可将允许的元数据流量从工作负载发送到目标。

SSL/TLS 连接故障排除

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

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

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


Note

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

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

注册、签入

Linux

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

Windows (PowerShell)

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

大多数 SSL/TLS 连接问题都发生在初始连接和代理注册期间。发送流需要在尝试连接前完成注册。这里出现的 SSL/TLS 错误是由于允许使用 sensorVIP IP 但不允许使用收集器 IP 所致。

Linux

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

Windows (PowerShell)

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

Linux

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

Windows (PowerShell)

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

如果在上述日志检查中发现 SSL 错误，可以使用以下命令验证发送给代理的证书。

显式代理 - 其中代理在 user.cfg 中配置

Linux

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

Windows (PowerShell) 

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

透明代理 - 无需 user.cfg 代理配置。它是一个代理，在从代理到互联网的所有 HTTP(S) 流量之间配置。

Linux

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

Windows (PowerShell)

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

您正在 openssl s_client 响应中查找以下内容

Verify return code: 0 (ok)

如果出现错误，请检查证书。证书（链）示例应仅包括以下证书（CN IP 为示例）：

证书链

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

如果您看到其他证书，则代理和 Cisco Secure Workload 之间可能存在 Web 解密代理。请联系您的安全或网络小组，确认是否已使用“为代理通信配置 IP 流量”部分中列出的 IP 配置了代理绕行。

Windows 2016 服务器上的 Windows 传感器安装脚本失败：可能出现的错误消息“The underlying connection was closed: An unexpected error occurred on a receive.”。可能的原因可能是 PowerShell 中设置的 SSL/TLS 版本。

要检查正在运行的 SSL/TLS 版本，请运行以下命令： 

[Net.ServicePointManager]::SecurityProtocol

如果上述命令的输出为：

Ssl3, Tls

然后使用下面的命令更改允许的协议并重试安装：

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

代理操作

问：我已成功安装代理，但在“UI 传感器监控”(UI Sensor Monitoring) 页面上没有看到它。

答：代理需要先注册到在集群中运行的后端服务器，然后才能开始运行。如果 UI 页面上未显示代理，很可能是因为注册失败。我们可以从几个方面来了解注册失败的原因：

  • 检查代理与后台服务器之间的连接是否正常

  • 检查 curl 请求是否能正确发送到后端服务器

  • 检查 HAProxy 访问和后端服务器日志，以查看服务器是否收到注册请求

  • 检查日志文件中 curl 请求返回的错误消息

问：代理已安装，我可以在 UI 页面上找到。但是，“软件版本”(SW Ver) 列显示“正在初始化”(initializing)，而不是版本字符串。

答：在后端服务器安装并注册初始代理后，该代理还需要 30 分钟来报告其版本。

问：代理已正确升级，但经过很长时间（比如几个小时）后，“软件版本”(SW Ver) 字段仍显示旧版本。

答：代理成功升级后，会尝试发送 curl 请求以报告其当前运行的版本，并在同一请求中检查新版本。由于以下几个原因，请求可能无法到达后端：

  • 请求超时，无法及时获得响应

  • 网络存在问题，代理无法连接到后端服务器

问：我有一个在 RHEL/CentOS-6.x 上运行的代理，它运行正常。我正打算将操作系统升级到 RHEL/CentOS-7.x。升级后，代理还能工作吗？

答：目前，我们不支持升级操作系统的场景，尤其是升级主要版本。要使代理在操作系统升级后正常工作，请执行以下步骤：

  • 卸载现有代理软件

  • 清理所有文件，包括证书

  • 转到 UI，删除代理条目

  • 将操作系统升级到所需版本

  • 在新操作系统上安装代理软件

问：我有一个在 RHEL/CentOS-6.x 上运行的代理，它运行正常。我打算为主机重命名。重命名/重启后，代理是否仍可工作？

答：代理身份是根据主机的唯一性（包括主机名和 BIOS-UUID）计算得出的。更改主机名会更改主机的标识。建议执行以下操作：

  • 卸载现有代理软件

  • 清理所有文件，包括证书

  • 转到 UI，删除旧代理条目

  • 重命名主机并重启

  • 再次安装代理软件

问：在 Windows 主机上，添加/删除/修改规则导致防火墙偏离。如何查找规则？

答： 在检测偏差时，代理会将最近 15 秒的防火墙事件记录到“C:\Windows\System32\config\systemprofile\AppData\Roaming\tet\firewall_events”。导致偏差的规则将在创建为 policy_dev_<policy id>_<timestamp>.txt 的最新文件中找到。

问：我已在 Windows 主机上成功安装代理。为什么我看不到传感器的任何报告流？

答：在 Windows 主机上收集流需要使用 Npcap。成功安装代理后 10 秒，它将安装 Npcap。如果传感器在几分钟后未报告流量，请检查代理和后端服务器是否已连接，以及 Npcap 是否已在 NPCAP 问题上正确安装。

问：我已在 Windows 主机 2008 R2 上成功安装代理。为什么 tetsensor 服务运行时系统时钟会漂移？

答：这是 Go 和 Windows 2008 R2 的已知问题。有关详细信息，请参阅 Golang 和 Win2008 R2。

作为 tetsensor 服务一部分运行的进程 tet-main.exe，是使用 Go 1.15 版本构建的。这就是 tetsensor 服务运行时系统时钟漂移的原因。

当 Windows 2008 R2 工作负载配置为使用外部 NTP 服务器或域控制器作为 NTP 服务器时，就会出现此问题。

可能的解决方法：

  1. 定期强制 NTP 同步时钟：w32tm /resync /force

  2. 手动禁用 tet-main.exe。

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

    • 运行 regedit.exe

    • 转到“HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\TetSensor”

    • 双击“ImagePath”

    • 编辑值，删除 tet-main.exe

      在“C:\Program Files\Cisco Tetration\TetSenEngine.exe” TetSensor TetSen.exe “-f sensor_config” tet-main.exe ” ” TetUpdate.exe 之前

      在“C:\Program Files\Cisco Tetration\TetSenEngine.exe”TetSensor TetSen.exe “-f sensor_config”TetUpdate.exe 之后

    • 重启 tetsensor 服务


      Note

      每次升级代理后，请禁用 tet-main.exe。

  3. 删除外部 NTP 服务器配置：

    • 运行命令：w32tm /config /update /manualpeerlist: /syncfromflags:manual /reliable:yes

    • 重启 Windows 时间服务 W32Time

问：连接至 SaaS 集群、运行在 Windows 和 Linux 工作负载上的代理，为何会与 169.254.169.254 的实例元数据服务 (IMDS) 通信？

答：Cisco Secure Workload SaaS 集群需要获取信息，判断工作负载是否属于 Azure、AWS、GCP 等云厂商环境。代理会查询 169.254.169.254 的 IMDS，以获取该信息。该通信仅针对连接至 SaaS 集群、运行在 Windows 和 Linux 工作负载上的代理。代理安装后，仅会执行一次该查询。但在 3.10 (1.1) 及更早版本中，代理每次启动都会执行该查询。

排查 Windows 上的代理故障

该工具的 Windows 版本为 PowerShell 脚本。它支持通过不同参数，针对特定功能区域进行排查。
参数

参数

说明

-agentHealth

此选项可检查代理的运行状况并报告需要解决的任何问题。

-agentRegistration

此选项允许您检查代理注册是否存在任何已知问题。

-agentUpgrade

此选项允许您检查代理升级是否存在任何已知问题。

-enforcementHealth

此选项可检查整体执行运行状况，并确保编程了最新的策略。

-collectLogs

此选项可收集调试日志，从而对其进行分析以作进一步的故障排除。

-all

该选项会执行上述所有参数对应的检查项。

-collectDebugLogs

该选项会让代理以调试模式运行 2 分钟，并捕获 netsh 跟踪日志。（注：该参数不会与“-all”参数同时执行。）

运行 Windows 系统的代理故障排查工具脚本，请执行以下步骤：

过程

步骤 1

以管理员身份打开 Windows (PowerShell)。

步骤 2

导航至 CSW 安装目录（此目录的默认位置为：“C:\Program Files\Cisco Tetration”）。

步骤 3

使用以下命令运行脚本：

.\AgentTroubleshootingTool.ps1

例如，要检查代理的运行状况，请使用 -agentHealth 参数运行脚本： 

.\AgentTroubleshootingTool.ps1 -agentHealth