duaa-adnan/Squid-ClamAV-Wazuh-Detection-Lab
GitHub: duaa-adnan/Squid-ClamAV-Wazuh-Detection-Lab
记录在虚拟实验环境中部署pfSense、Squid+ClamAV与Wazuh SIEM构建恶意软件检测pipeline的蓝队实习项目,包含自定义Wazuh decoder开发与完整事件响应流程。
Stars: 0 | Forks: 0
蓝队实习。ITSimplera Solutions
第 3 周任务:使用 pfSense、Squid、ClamAV 和 Wazuh 进行恶意软件检测与监控
实习方向工具状态
作者:Duaa Bint E Adnan
## 概述
本仓库记录了我作为 SOC 分析师实习生在 ITSimplera Solutions 的工作,这是实操安全运营中心 (SOC) 实习项目的一部分。该实习的目标是通过直接使用真实 SOC 环境中使用的工具和工作流程,培养防御性网络安全方面实用的、符合行业需求的技能。
本 README 涵盖了第 3 周的内容,在此期间,我部署了 pfSense 防火墙和带有 ClamAV 的 Squid 代理,重新连接并验证了现有的 Wazuh SIEM 部署,使用 EICAR 文件测试了恶意软件检测,使用 Syslog-NG 构建了日志转发 pipeline,并在发现 Wazuh 自带的内置 Squid decoder 在此版本中无法正常工作后,开发了自定义的 Wazuh decoder 和检测规则。
## 目录
- 第 3 周 —— 任务简介
- 目标
- 实验环境
- 实施内容
- 挑战与故障排除
- 工具与技术
- 展现的技能
- 经验教训
- 成果
- 文档
- 未来改进
## 第 3 周 —— 任务简介
| 细节 | 信息 |
|---|---|
| 任务类型 | 设置 + 探索 |
| 角色 | SOC 分析师实习生 |
## 目标
部署并配置 pfSense 防火墙、带有 ClamAV 的 Squid 代理,并将它们与 Wazuh SIEM 平台集成,以检测和监控恶意软件活动。分析安全日志,识别妥协指标,使用 EICAR 文件测试恶意软件检测,并根据结果制定事件响应计划。
## 实验环境
| 组件 | 详情 |
|---|---|
| 宿主机 | Windows 11 |
| Hypervisor | VMware Workstation |
| 防火墙 | pfSense CE 2.7.2 |
| 代理 / AV 主机 | Ubuntu Server 22.04 LTS (Squid + ClamAV) |
| SIEM 平台 | Wazuh 4.9.2 (Manager, Indexer, Dashboard) |
| 日志转发 | Syslog-NG |
| 测试文件 | EICAR 标准防病毒测试文件 |
## 实施内容
- 部署并配置了 pfSense 防火墙作为实验室的网络边界
- 安装并配置了 Squid 代理服务器,并使用访问规则限制 LAN
- 安装并配置了 ClamAV,并保持特征码最新
- 尝试在 Squid 和 ClamAV 之间进行完整的 ICAP 集成以进行内联文件扫描(请参阅下文的挑战)
- 重新连接并验证了现有的 Wazuh SIEM 部署,解决了服务级别和主机网络故障
- 下载了 EICAR 测试文件并使用 ClamAV 进行扫描,以验证基于特征码的恶意软件检测
- 配置了 Syslog-NG 以将 Squid 的访问日志转发到 Wazuh 的远程 syslog 监听器,并通过实时流量对 pipeline 进行了端到端验证
- 诊断了 Wazuh 内置 Squid decoder 中的真实缺陷,该 decoder 甚至无法匹配其自身文档中记录的示例日志行
- 针对 Squid 代理事件构建了完全自定义的 Wazuh decoder 和检测规则,并针对实时代理流量进行了验证,在 Wazuh Dashboard 中得到了确认
- 通过配套截图记录了该过程的每一个步骤
- 根据基于 EICAR 的测试和自定义规则验证编写了事件响应计划
## 挑战与故障排除
**挑战 1 —— Squid 和 ClamAV 之间的 ICAP 集成**
原因:在 Squid 的配置中启用 ICAP 以通过 c-icap 和 squidclamav 内联扫描文件后,通过代理的所有 HTTPS 流量在每个请求上开始出现 500 错误而失败。
解决方法:通过禁用 ICAP 并恢复正常代理功能,确认问题仅限于 ICAP 配置。在项目截止日期前,根本原因未得到完全排查。
结果:恢复了 ICAP 配置以还原可正常工作的代理。将其记录为未完成项,而不是将其展示为可正常工作。
**挑战 2 —— VM 重启后无法访问 Wazuh Dashboard**
原因:Windows 宿主机的 VMware 网络适配器接收到了无效的、自动分配的 IP 地址,而不是正确的租约,从而导致流量通过 Wi-Fi 静默路由,而不是在实验室网络上路由。
解决方法:使用 Test-NetConnection 和 Get-NetIPAddress 进行诊断,然后直接为该适配器分配静态 IP。
结果:恢复了 Dashboard 访问权限;需注意该修复在 Windows 重启后不会保留,必须重新应用。
**挑战 3 —— Wazuh 内置的 Squid decoder 无法匹配任何日志**
原因:在排除了日志格式、syslog 封装和我自己的配置后,直接测试 Wazuh 自己文档中记录的示例日志行,发现它同样无法匹配其内置的 decoder。
解决方法:找到并查看了该 decoder 的源文件 (0305-squid_decoders.xml) 以确认预期格式,然后构建了完全自定义的 decoder 和检测规则,而不是继续调试一个无法按文档说明工作的组件。
结果:通过 wazuh-logtest 进行了验证,随后在 Wazuh Dashboard 中根据真实的被阻止代理流量生成了真实的实时告警。
**挑战 4 —— 本地磁盘已满,VM 无法开机**
原因:宿主机的 C: 驱动器可用空间耗尽,导致 VMware 无法写入 VM 的虚拟磁盘文件。
解决方法:释放了磁盘空间(清理了临时文件,删除了旧的 VM 快照)并重试。
结果:一旦有足够的可用空间,VM 即可正常开机。
## 工具与技术
- pfSense(防火墙 / 网络边界)
- Squid(代理服务器)
- ClamAV(防病毒引擎)
- c-icap / squidclamav(尝试的 ICAP 集成)
- Wazuh(Manager, Indexer, Dashboard, Agent)
- Syslog-NG(日志转发)
- EICAR 测试文件(恶意软件检测验证)
- 在 Ubuntu Server 上对所有服务配置进行命令行管理
- 使用 wazuh-logtest 进行 decoder 和规则的开发/调试
## 展现的技能
- 将防火墙和代理服务器部署并配置为网络安全边界
- 将防病毒引擎与代理服务器集成,包括解决未解决的实际情况下的集成失败
- 重新连接并排查现有的 SIEM 部署,包括主机级别的网络故障
- 使用符合行业标准的安全测试方法验证恶意软件检测
- 设计日志转发 pipeline(从 Syslog-NG 到 SIEM),并使用实时流量对其进行验证,而不是想当然地认为它可以正常工作
- 批判性地阅读供应商提供的检测逻辑,诊断出真正的产品缺陷而不是想当然地认为是配置错误,并构建了有效的替代方案
- 调试基于 XML 的规则和 decoder 配置,包括 schema 验证错误和保留字段冲突
- 将漫长且反复的故障排除过程梳理为清晰、专业的文档
## 经验教训
- 供应商提供的默认规则和 decoder 并非自动可信;尽早针对它们自己文档中记录的示例进行测试是值得的。
- SIEM 的默认输出并不总是显示全貌 —— wazuh-logtest 的标准模式静默遗漏了仅在 verbose 模式下才会出现的规则评估结果。
- 将两个安全工具集成在一起比独立运行它们要脆弱得多,因此值得设定时间盒,而不是在截止日期前无休止地追求。
- 主机级别的网络问题(例如错误分配的 VM 适配器 IP)看起来可能与应用程序级别的故障完全相同,因此值得尽早排除。
- 诚实地记录未解决的问题比仅仅展示有效部分更有价值,在专业上也更可靠。
## 成果
到第 3 周结束时,我拥有了一个可用的恶意软件检测和监控 pipeline:ClamAV 直接检测到了 EICAR 测试特征码,Squid 代理日志通过 Syslog-NG 实时流入 Wazuh,并且自定义构建的 Wazuh decoder 和检测规则根据实时代理流量在 Dashboard中生成了真实且经过验证的告警 —— 这是在发现并解决了 Wazuh 自带内置 Squid decoder 的真实缺陷后构建的。
## 文档
- 完整技术报告
- 事件响应计划
- 自定义 Wazuh Decoder 与规则
- LinkedIn 帖子链接:
## 未来改进
- 解决 Squid 和 ClamAV 之间的 ICAP 集成问题,以实现内联文件扫描
- 扩展 Syslog-NG 转发,以包括 pfSense 防火墙日志,而不仅仅是 Squid
- 构建涵盖更广泛 Squid 响应代码和请求模式的额外自定义规则
- 为高严重性自定义规则匹配配置电子邮件或 webhook 告警
- 在未来的 Wazuh 版本中重新测试内置的 Squid decoder,以查看上游是否已修复该缺陷
这是我不断深入学习蓝队和 SOC 运营之旅的一部分,通过一项项任务逐步构建了这个仓库。
Duaa Bint E Adnan · SOC 分析师实习生 @ ITSimplera Solutions
标签:IP 地址批量处理, pfSense, Wazuh, 安全运营中心(SOC), 库, 应急响应, 网络信息收集, 自定义DNS解析器