收集 Kiteworks(以前称为 Accellion)日志
解析器版本:16.0
本文档介绍了如何使用 Bindplane 将 Kiteworks(以前称为 Accellion)日志注入到 Google Security Operations。
Kiteworks 是一个安全的文件共享和治理平台,可提供涵盖电子邮件、文件共享、代管式文件传输和 Web 表单的企业内容通信。它可让您了解、控制进出组织的敏感内容,并确保其合规性。
准备工作
请确保满足以下前提条件:
- Google SecOps 实例
- Windows Server 2016 或更高版本,或者安装了
systemd的 Linux 主机 - Bindplane 代理与 Kiteworks 设备之间的网络连接
- 如果在代理后面运行,请确保按照 Bindplane 代理要求打开防火墙端口
- 对 Kiteworks 管理控制台的特权访问权限(系统管理员角色)
获取 Bindplane 代理的 Google SecOps 凭证
如需向 Google SecOps 验证 Bindplane 代理,请选择以下方法之一:
- 新部署:使用 Chronicle API(选项 1)。
- 旧版部署:继续使用数据注入身份验证文件(方法 2),直到 Ingestion API 于 2027 年 7 月 20 日停用。
方法 1:为 Chronicle API 创建服务账号(推荐)
- 登录 Google Cloud 控制台,然后选择与您的 Google SecOps 实例关联的 Google Cloud 项目。
- 依次前往 IAM 和管理 > 服务账号。
- 点击创建服务账号。
- 提供以下配置详细信息:
- 服务账号名称:输入账号的名称(例如
bindplane-ingest)。 - 服务账号说明:输入说明(例如
Bindplane agent log ingestion)。
- 服务账号名称:输入账号的名称(例如
- 点击创建并继续。
- 在向此服务账号授予对项目的访问权限部分,点击选择角色,然后选择 Chronicle Editor。
- 点击继续,然后点击完成。
- 点击您创建的服务账号,然后前往密钥标签页。
- 依次点击添加密钥 > 创建新密钥。
- 选择 JSON,然后点击创建。密钥文件会下载到您的计算机上。
- 将密钥文件另存为 Bindplane 收集器目录(Linux 上的
/opt/observiq-otel-collector/ingestion-auth.json或 Windows 上的C:\Program Files\observIQ OpenTelemetry Collector\ingestion-auth.json)中的ingestion-auth.json,或更新config.yaml中的creds_file_path以匹配您保存它的路径。 - 前往 IAM 和管理 > 设置,然后复制项目编号。您在配置导出器时需要用到该名称。
方法 2:下载数据注入身份验证文件(旧版)
- 登录 Google SecOps 控制台。
- 依次前往设置 > 数据管理 > 收集代理。如果您使用的是仅限 SIEM 的平台,请依次前往设置 > 收集代理。
- 下载数据注入身份验证文件。
- 将该文件安全地保存在将要安装 Bindplane 代理的系统上。
获取 Google SecOps 客户 ID
- 登录 Google SecOps 控制台。
- 依次前往设置 > 管理 > 个人资料。如果您使用的是仅限 SIEM 的平台,请依次前往设置 > 个人资料。
复制并保存组织详细信息部分中的客户 ID。
安装 Bindplane 代理
根据以下说明,在 Windows 或 Linux 操作系统上安装 Bindplane 代理。
Windows 安装
- 以管理员身份打开命令提示符或 PowerShell。
运行以下命令:
msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet等待安装完成。
运行以下命令,验证安装是否成功:
sc query observiq-otel-collector
该服务应显示为正在运行。
Linux 安装
- 打开具有 root 或 sudo 权限的终端。
运行以下命令:
sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh等待安装完成。
运行以下命令,验证安装是否成功:
sudo systemctl status observiq-otel-collector
该服务应显示为 active (running)。
其他安装资源
如需了解其他安装选项和问题排查,请参阅 Bindplane 代理安装指南。
配置 Bindplane 代理以注入 syslog 并发送到 Google SecOps
找到配置文件
Linux:
sudo nano /opt/observiq-otel-collector/config.yamlWindows:
notepad "C:\Program Files\observIQ OpenTelemetry Collector\config.yaml"
修改配置文件
将
config.yaml的全部内容替换为以下配置:receivers: udplog: listen_address: "0.0.0.0:514" exporters: chronicle/accellion: protocol: https # Region of your instance, for example us, europe, asia-southeast1 location: <LOCATION> # Project number of the Google Cloud project linked to the instance project: '<PROJECT_NUMBER>' compression: gzip creds_file_path: '/opt/observiq-otel-collector/ingestion-auth.json' customer_id: '<customer_id>' endpoint: chronicle.googleapis.com log_type: ACCELLION raw_log_field: body service: pipelines: logs/accellion_to_chronicle: receivers: - udplog exporters: - chronicle/accellion
配置参数
替换以下占位符:
接收器配置:
listen_address:要监听的 IP 地址和端口:0.0.0.0,以监听所有接口(推荐)- 端口
514是标准 syslog 端口(在 Linux 上需要 root 权限;对于非 root 用户,请使用1514)
导出器配置:
creds_file_path:服务账号 JSON 密钥文件的完整路径(选项 1):- Linux:
/opt/observiq-otel-collector/ingestion-auth.json - Windows:
C:\Program Files\observIQ OpenTelemetry Collector\ingestion-auth.json
- Linux:
customer_id:从 Google SecOps 控制台复制的客户 IDlocation:将<LOCATION>替换为 Google SecOps 实例所在的区域(例如us、europe或asia-southeast1)。导出工具会在此值前面加上chronicle.googleapis.com。如需查看完整列表,请参阅区域级端点。project:将<PROJECT_NUMBER>替换为 IAM 和管理 > 设置中的项目编号。endpoint:保持设置为chronicle.googleapis.com。
旧版提取 API 导出工具
如果您使用选项 2 中的数据注入身份验证文件,请将
exporters代码块替换为以下内容。将creds_file_path设置为数据注入身份验证文件的路径,如果您的实例位于美国境外,请将malachiteingestion-pa.googleapis.com替换为您的区域端点(例如europe-malachiteingestion-pa.googleapis.com)。exporters: chronicle/accellion: compression: gzip creds_file_path: '/opt/observiq-otel-collector/ingestion-auth.json' customer_id: '<customer_id>' endpoint: malachiteingestion-pa.googleapis.com log_type: ACCELLION raw_log_field: body
保存配置文件
- 修改后,保存文件:
- Linux:依次按
Ctrl+O、Enter和Ctrl+X - Windows:依次点击文件 > 保存
- Linux:依次按
重启 Bindplane 代理以应用更改
如需在 Linux 中重启 Bindplane 代理,请执行以下操作:
运行以下命令:
sudo systemctl restart observiq-otel-collector验证服务是否正在运行:
sudo systemctl status observiq-otel-collector检查日志中的错误:
sudo journalctl -u observiq-otel-collector -f
如需在 Windows 中重启 Bindplane 代理,请执行以下操作:
请从下列选项中选择一项:
- 以管理员身份运行命令提示符或 PowerShell:
net stop observiq-otel-collector && net start observiq-otel-collector- 服务控制台:
- 按
Win+R,输入services.msc,然后按 Enter 键。 - 找到 observIQ OpenTelemetry 收集器。
- 右键点击并选择重启。
- 按
验证服务是否正在运行:
sc query observiq-otel-collector检查日志中的错误:
type "C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log"
在 Kiteworks(以前称为 Accellion)上配置 syslog 转发
- 以系统管理员身份登录 Kiteworks 管理控制台。
- 前往营业地点页面:
- 旧版管理界面:依次前往系统 > 位置。
- 新版管理界面:前往系统设置 > 位置。
- 从列表中选择目标位置。
- 前往外部服务部分。
- 展开系统日志设置面板。
- 点击添加以创建新的 syslog 服务器配置。
- 提供以下配置详细信息:
- Syslog 服务器:输入 Bindplane 代理主机的 IP 地址(例如
192.168.1.100)。 - 协议:选择 UDP 或 TCP,具体取决于您的 Bindplane 代理接收器配置。
- 端口:输入 Bindplane 代理端口号(例如
514)。 - 使用 TLS:如果您想通过 TLS 传输 syslog 消息,请选中此复选框(仅当选择 TCP 作为协议时可用)。
- 格式:选择 JSON 格式(推荐用于结构化解析)。
- Syslog 服务器:输入 Bindplane 代理主机的 IP 地址(例如
点击保存以应用配置。
UDM 映射表
| 日志字段 | UDM 映射 | 逻辑 |
|---|---|---|
acct |
principal.user.user_display_name |
原始日志的 msg 字段中的 acct 值。 |
acct |
target.user.user_display_name |
原始日志的 msg 字段中的 acct 值。 |
addr |
principal.ip |
原始日志的 msg 字段中的 addr 值。 |
a0 |
security_result.about.labels.value |
原始日志的 msg 字段中 a0 的值,其中对应的 key 为“a0”。 |
a1 |
security_result.about.labels.value |
原始日志的 msg 字段中 a1 的值,其中对应的 key 为“a1”。 |
a2 |
security_result.about.labels.value |
原始日志的 msg 字段中 a2 的值,其中对应的 key 为“a2”。 |
a3 |
security_result.about.labels.value |
原始日志的 msg 字段中 a3 的值,其中对应的 key 为“a3”。 |
arch |
security_result.about.platform_version |
原始日志的 msg 字段中的 arch 值。仅适用于 type_name SYSCALL。 |
auid |
about.user.userid |
原始日志的 msg 字段中的 auid 值。 |
auid |
security_result.detection_fields.value |
原始日志的 msg 字段中 auid 的值,其中对应的 key 为“auid”。 |
comm |
principal.application |
原始日志的 msg 字段中的 comm 值。 |
cmd |
principal.process.command_line |
原始日志的 msg 字段中的 cmd 值。 |
cwd |
security_result.detection_fields.value |
原始日志的 msg 字段中 cwd 的值,其中对应的 key 为“cwd”。 |
cwd |
target.process.file.full_path |
原始日志的 msg 字段中的 cwd 值。 |
exe |
principal.process.file.full_path |
原始日志的 msg 字段中的 exe 值。 |
exe |
target.process.file.full_path |
原始日志的 msg 字段中的 exe 值。 |
exit |
security_result.about.labels.value |
原始日志的 msg 字段中 exit 的值,其中对应的 key 为“Exit Code”。 |
hostname |
principal.hostname |
原始日志的 msg 字段中的 hostname 值。 |
key |
security_result.about.registry.registry_key |
原始日志的 msg 字段中的 key 值。仅适用于 type_name SYSCALL。 |
log_type |
metadata.log_type |
原始日志中 log_type 的值。 |
msg |
security_result.action_details |
原始日志的 msg 字段中 res= 后面的值。 |
msg |
security_result.summary |
原始日志的 msg 字段中的字段组合。从原始日志中 msg 字段的 audit 部分解析。根据原始日志中的 type 字段进行映射。例如,“USER_START”映射到“USER_LOGIN”,“CRED_DISP”映射到“USER_LOGOUT”,“CRED_ACQ”映射到“USER_LOGIN”,“USER_END”映射到“USER_LOGOUT”,“CRED_REFR”映射到“USER_LOGIN”,“USER_CMD”映射到“USER_LOGIN”,“CWD”映射到“STATUS_UPDATE”,“PROCTITLE”映射到“STATUS_UPDATE”,“USER_ACCT”映射到“USER_UNCATEGORIZED”,“SYSCALL”映射到“USER_UNCATEGORIZED”。 |
node |
principal.hostname |
原始日志的 msg 字段中的 node 值。 |
pid |
principal.process.pid |
原始日志的 msg 字段中的 pid 值。 |
ppid |
principal.process.parent_process.pid |
原始日志的 msg 字段中的 ppid 值。 |
proctitle |
target.process.file.full_path |
从原始日志的 msg 字段中解码的 proctitle 十六进制值。硬编码为“LINUX”。如果原始日志的 msg 字段中存在 res=success,则设置为“ALLOW”。 |
ses |
network.session_id |
原始日志的 msg 字段中的 ses 值。 |
syscall |
security_result.about.labels.value |
原始日志的 msg 字段中 syscall 的值,其中对应的 key 为“Syscall”。 |
success |
security_result.summary |
与其他字段结合使用,形成摘要。对于 SYSCALL 事件,逻辑如下:如果 success=yes,则为“是,系统调用成功”,否则为“否,系统调用失败”。 |
terminal |
principal.terminal |
原始日志的 msg 字段中的 terminal 值。 |
timestamp |
timestamp |
原始日志条目中的 timestamp 值。 |
tty |
principal.terminal |
原始日志的 msg 字段中的 tty 值。 |
type |
metadata.product_event_type |
原始日志的 msg 字段中的 type 值。 |
uid |
about.user.userid |
原始日志的 msg 字段中的 uid 值。仅适用于 type_name SYSCALL。 |
uid |
target.user.userid |
原始日志的 msg 字段中的 uid 值。如果 type 为“USER_ACCT”,则设置为“SETTING”。 |