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解析器