dmelendez-sec/wazuh-detection-engineering-

# Wazuh 检测工程实验室 **作者：** Daniel Melendez, CISSP **环境：** Proxmox homelab — pfSense, Wazuh 4.14, OpenSearch, Cowrie SSH Honeypot **目的：** 针对生产 Honeypot 的实时攻击流量进行检测工程 ## 实验室架构 ``` Internet (live attackers) ↓ pfSense (DMZ firewall) ↓ Cowrie SSH Honeypot (10.10.40.10 / webserver01) Ubuntu 24.04 | Wazuh Agent | Port 22 (honeypot) | Port 2222 (real SSH) ↓ Wazuh Manager (192.168.1.181 / wazuh-server) Wazuh 4.14 | OpenSearch | Filebeat ↓ Wazuh Dashboard Custom rules, decoders, geo enrichment, threat intel pipeline ``` ## 目录 | 目录 / 文件 | 描述 | |---|---| | `decoders/cowrie_decoder.xml` | 用于 Cowrie JSON 日志的自定义 Wazuh decoder | | `rules/cowrie_rules.xml` | 用于 honeypot 事件的自定义检测规则 | | `pipelines/wazuh-alerts-pipeline.json` | 用于 GeoIP 富化的 OpenSearch ingest pipeline | | `pipelines/wazuh-alerts-enriched-mapping.json` | 启用地理信息的 alert 索引映射 | | `threat-intel/malicious-ioc/` | CDB 列表 — 恶意 IP、域名、哈希 | | `scripts/update-threatfeed.sh` | AbuseIPDB 自动化威胁源 pipeline | | `docs/geo-enrichment-fix.md` | 地图可视化的根本原因分析及修复 | ## Cowrie 集成 ### 问题 Wazuh agent 正在运行，但仪表板中没有出现 Cowrie 事件。`wazuh-logcollector` 进程打开了日志文件（通过 `/proc//fd` 确认），但未生成告警。 ### 根本原因 `wazuh` 用户对 Cowrie 日志目录链缺乏读取权限。路径中任何目录的单一权限拒绝都会阻断整个链。 ``` # 验证 issue sudo -u wazuh ls -la /home/webadmin/cowrie/var/log/cowrie/ # 返回：Permission denied ``` ### 应用的修复 ``` sudo chmod o+rx /home/webadmin/ sudo chmod o+rx /home/webadmin/cowrie/ sudo chmod o+rx /home/webadmin/cowrie/var/ sudo chmod o+rx /home/webadmin/cowrie/var/log/ sudo chmod o+rx /home/webadmin/cowrie/var/log/cowrie/ sudo chmod o+r /home/webadmin/cowrie/var/log/cowrie/cowrie.json sudo systemctl restart wazuh-agent ``` ### 验证 ``` # 确认文件描述符已打开 sudo ls -la /proc/$(pgrep -f wazuh-logcollector)/fd | grep cowrie # 期望：lr-x------ ... -> /home/webadmin/cowrie/var/log/cowrie/cowrie.json ``` ### Agent 配置 (`/var/ossec/etc/ossec.conf`) ``` json /home/webadmin/cowrie/var/log/cowrie/cowrie.json ``` ## 自定义 Decoder **文件：** `decoders/cowrie_decoder.xml` ``` "eventid":"cowrie. cowrie "src_ip":"(\d+\.\d+\.\d+\.\d+)" srcip cowrie "eventid":"(\.+)" extra_data ``` **使用 wazuh-logtest 测试：** ``` sudo /var/ossec/bin/wazuh-logtest ``` 粘贴一个示例 Cowrie JSON 事件，并验证阶段 2 显示提取了 `eventid`，阶段 3 显示触发了规则。 ## 自定义检测规则 **文件：** `rules/cowrie_rules.xml` ``` json cowrie.session.connect Cowrie Honeypot: New SSH connection from $(data.src_ip) cowrie,honeypot,connection, json cowrie.login.success Cowrie Honeypot: Successful login from $(data.src_ip) using $(data.username) cowrie,honeypot,authentication_success, json cowrie.command.input Cowrie Honeypot: Command executed by $(data.src_ip) cowrie,honeypot,command_execution, json cowrie.session.file_download Cowrie Honeypot: CRITICAL - File download attempt from $(data.src_ip) cowrie,honeypot,malware, ``` ## GeoIP 富化 — 地图可视化修复 ### 问题陈述 尽管事件通过了 pipeline，Wazuh 仪表板 GeoData 地图仍然为空。已识别并解决了三个独立的问题。 ### 根本原因分析 **问题 1 — 数据隐藏在 Archives 索引中** 大多数 honeypot 事件落入 `wazuh-archives-*` 而非 `wazuh-alerts-*`，因为自动化扫描流量量大但并不总是触发高优先级告警规则。仪表板默认的索引模式仅查询 alerts 索引。 **问题 2 — 字段类型不匹配** OpenSearch 动态将 `data.src_ip` 映射为 `text`（全文搜索）而非 `keyword`（精确匹配标签）。地图可视化需要 `keyword` 类型才能进行 IP 聚合。动态映射会猜测字段类型，而对于混合了其他数据的 IP，它会猜错。 **问题 3 — 缺少 GeoIP 坐标** 原始 Cowrie JSON 日志包含作为字符串的 `src_ip`，但没有地理坐标。Wazuh decoder 提取 `srcip` 以进行 geo 查询，但内置的 JSON decoder 先拦截了事件，导致 `src_ip` 仍作为数据字段存在，而不是保留的用于触发 Wazuh geo 富化 pipeline 的 `srcip` 字段。 ### 通过 OpenSearch Dev Tools Web GUI 的解决方案 — 三步修复 **步骤 1：创建 Ingest Pipeline** 必须首先创建 — reindex 操作通过名称引用此 pipeline。 ``` PUT _ingest/pipeline/wazuh-alerts { "description": "Add GeoIP info to Wazuh alerts", "processors": [ { "geoip": { "field": "data.src_ip", "target_field": "GeoLocation", "properties": ["city_name", "country_name", "region_name", "location"], "ignore_missing": true } }, { "set": { "field": "srcip", "copy_from": "data.src_ip", "ignore_failure": true } } ] } ``` **步骤 2：创建具有显式映射的索引** 必须第二步创建 — 数据写入后字段类型无法更改。在空索引上定义 schema。 ``` PUT wazuh-alerts-enriched { "mappings": { "properties": { "srcip": { "type": "keyword" }, "data": { "properties": { "src_ip": { "type": "keyword" } } }, "GeoLocation": { "properties": { "location": { "type": "geo_point" } } } } } } ``` **步骤 3：重建历史数据索引** 最后运行 — 将存档数据通过 pipeline 拉取到新的富化索引中。 ``` POST _reindex?wait_for_completion=false { "source": { "index": "wazuh-archives-*", "query": { "query_string": { "query": "data.src_ip:*" } } }, "dest": { "index": "wazuh-alerts-enriched", "pipeline": "wazuh-alerts" } } ``` **步骤 4：更新仪表板索引模式** 将 GeoData 地图可视化中的索引模式从 `wazuh-alerts-*` 更改为 `wazuh-alerts*`（带通配符），以包含新的富化索引和实时告警。 ### 关键经验 | 经验 | 详情 | |---|---| | Pipeline 先于映射先于数据 | 顺序不可协商。在映射之前写入的数据将永久锁定字段类型。 | | 地图和图表使用 `keyword` | `text` 字段无法聚合。在 SIEM 中，对于 IP、主机名、用户名始终使用 `keyword`。 | | Archives 包含信号 | 对于 honeypot，大容量的自动化攻击通常落入 archives 而非 alerts。两者都要查询。 | | 通配符索引模式 | `wazuh-alerts*` 捕获所有变体。`wazuh-alerts-*` 遗漏 `wazuh-alerts-enriched`。 | | 动态映射很危险 | OpenSearch 会猜测字段类型。对于生产索引，始终定义显式映射。 | ## 自动化威胁情报 Pipeline **脚本：** `scripts/update-threatfeed.sh` **计划：** 通过 cron 每天早上 6:00 运行 ### 它的功能 1. 从 AbuseIPDB 下载前 10,000 个恶意 IP（置信度 ≥ 90%） 2. 追加来自本地调查列表的已知 honeypot 攻击者 3. 重新生成 Wazuh CDB (Constant Database) 查找文件 4. 重启 wazuh-manager 以重新加载威胁情报列表 ### 生成的 CDB 文件 | 文件 | 大小 | 来源 | |---|---|---| | `malicious-ip.cdb` | ~375KB | AbuseIPDB + 手动 IOC | | `malicious-domains.cdb` | ~11KB | 域名黑名单 | | `malware-hashes.cdb` | ~20KB | 已知恶意软件哈希 | ### Cron 计划 ``` 0 6 * * * /usr/local/bin/update-threatfeed.sh >> /var/log/threatfeed-update.log 2>&1 ``` ## 记录的威胁行为者 所有调查并通过 VirusTotal 社区评论记录的威胁行为者均位于 [virustotal.com/gui/user/TechySec](https://www.virustotal.com/gui/user/TechySec) | IP | ASN | 会话 | TTP | 备注 | |---|---|---|---|---| | 159.203.173.197 | DigitalOcean US | 高 | 挖矿程序侦察 | OpenSSH Windows 客户端 | | 46.101.103.24 | DigitalOcean Frankfurt | 中 | SSH-2.0-Go 扫描器 | HASSH: 2ec37a7cc8daf20b10e1ad6221061ca5 | | 80.94.92.184 | DMZHOST Netherlands | 高 | 多向量 | Bulletproof hosting，17 个供应商检测 | | 165.245.135.50 | DigitalOcean US | 373 | 操作系统指纹识别 | uname 枚举活动 | | 170.64.192.224 | DigitalOcean US | 255 | 协调活动 | 轮换凭证喷洒 | | 139.59.23.117 | DigitalOcean | 195 次连接，62 次登录 | 硬件指纹识别 | 脚本化侦察：负载下发前进行 CPU/GPU/uptime 分析 | | 67.162.117.90 | 未知 | 低 | SMS 网关搜寻 | 针对 Telegram 会话文件，GSM 调制解调器设备 | ### 威胁情报样本分析：139.59.23.117 ``` 139.59.23.117 – Automated SSH login and host fingerprinting via Cowrie honeypot Observation window: Mar 3, 2026 19:58:51 – Mar 5, 2026 19:58:51 UTC Activity: 195 SSH connection attempts | 62 successful logins (ssh:ssh123) Post-authentication recon script collected: - OS/kernel (uname), uptime (/proc/uptime) - CPU architecture and model (/proc/cpuinfo, lscpu) - CPU/core count (nproc) - GPU presence (lspci grep VGA/nvidia) - Recent login history (last) - Shell utility behavior (cat --help, ls --help) Assessment: Automated scanning infrastructure performing post-authentication host fingerprinting to inventory system capabilities before payload deployment. Consistent with cryptomining or botnet recruitment operations. Tag: ssh-scanner ``` ## VirusTotal 集成 Wazuh VirusTotal 集成配置在 `/var/ossec/etc/ossec.conf` 中，范围为 Cowrie 规则 100200-100203。来自 honeypot 事件的文件哈希和 IP 会自动提交以进行信誉查询。 ## Canary 凭证 部署在 honeypot 文件系统中的虚假 AWS 凭证。配置了 CloudTrail 监控，并使用 CloudWatch metric filter 和 SNS 告警，监控任何使用 canary 密钥 `AKIAWQ7KMCRTJQWSOAT4` 的 API 调用。 任何此密钥的使用都会立即触发 SNS 电子邮件告警 — 表明攻击者成功窃取了凭证并试图使用它们。 ## 参考 - [Cowrie SSH Honeypot](https://github.com/cowrie/cowrie) - [Wazuh 文档](https://documentation.wazuh.com) - [AbuseIPDB API](https://docs.abuseipdb.com) - [OpenSearch Ingest Pipelines](https://opensearch.org/docs/latest/ingest-pipelines/) - [MITRE ATT&CK T1110 — 暴力破解](https://attack.mitre.org/techniques/T1110/) - [MITRE ATT&CK T1082 — 系统信息发现](https://attack.mitre.org/techniques/T1082/)

标签：Filebeat, GeoIP, IP 地址批量处理, Logstash, PB级数据处理, PE 加载器, pfSense, Proxmox, SSH蜜罐, Wazuh, 威胁情报, 安全实验室, 安全运维, 应用安全, 底层分析, 开发者工具, 恶意IP检测, 自制规则, 蜜罐, 证书利用, 进程注入