Cristian160497/hids-project

# HIDS - Host Intrusion Detection System 针对 Windows 系统的主机入侵检测系统（HIDS）的实现。该进程监控系统攻击期间针对的四个攻击面：监控关键系统文件、监控系统日志、监控网络连接以及监控系统进程。检测遵循基于 MITRE ATT&CK 框架内映射的主要攻击技术的精确规则进行。 ## 动机 出于几个具体原因，该项目是从零开始使用 Python 构建的，而不是使用现有的基础设施工具。 **无法进行网络级检测：** 最初的目标是在家庭 WiFi 网络上部署该系统。然而，可用的路由器属于 4/32 硬件类别——4MB Flash 和 32MB RAM——被最新版本的 OpenWrt 明确标记为不支持。如果没有自定义固件，就无法实现完整的流量可见性。 **云基础设施不是一种选择：** 评估了在云提供商（Google Cloud, Oracle Cloud）上部署 Wazuh 组件作为替代方案。这两个平台都需要信用卡或借记卡进行注册——包括它们的免费层级——这使得如果不进行任何财务投资就无法采用这种方法。 **本地硬件上的资源限制：** 完整的 Wazuh 技术栈至少需要 8GB RAM 专门用于其组件。可用的机器运行 Windows 11，配备入门级处理器，总共 8GB RAM 与操作系统共享，这使得本地虚拟化部署不可行。 **学习目标。** 从零开始用 Python 构建自定义 HIDS 可以真正理解入侵检测系统在内部是如何工作的。每一个架构决策都是经过深思熟虑并记录在案的——从 Windows 事件日志解析到 SHA-256 文件完整性验证和进程伪装检测——而不是委托给预构建的工具。 ## 架构 系统遵循**关注点分离**原则分为四个不同的层——每个模块都有单一、明确的职责。这种设计还确保了**故障隔离**：如果一个收集器失败，其他的会继续独立运行。 ``` main.py ├── collector/ │ ├── file_integrity.py → SHA-256 hash comparison against baseline │ ├── process_monitor.py → process whitelist and masquerading detection │ ├── network_monitor.py → behavioral rules for suspicious connections │ └── log_monitor.py → Windows Event Log parsing (5 critical Event IDs) ├── analyzer/ │ └── engine.py → aggregates alerts from all collectors ├── alerter/ │ └── alert.py → prints and persists alerts to disk └── data/ ├── baseline.json → system snapshot (hashes, processes, connections) ├── checkpoint.json → last processed Event Log record number └── alerts.json → persistent alert history ``` **数据流：** 每个收集器独立检测异常并返回警报列表。分析器聚合所有结果，应用故障隔离，以便失败的收集器不会阻塞其他收集器。然后，警报器按严重程度将警报打印到控制台，并将其附加到持久警报历史记录中。 **检测方法：** 出于两个原因，选择了基于规则的引擎而不是基于异常的检测。首先，基于规则的检测更易于实现、解释和审计。其次，基于异常的检测需要在历史数据上进行训练期以建立行为基线——在没有历史数据的新系统上，它会产生过多的误报并且不可靠。基于异常的检测计划在 V2 中实现。 **主循环：** `main.py` 作为入口点，如果基线不存在则自动生成，然后以可配置的间隔（默认：60 秒）在连续循环中运行所有收集器。可以使用 CTRL+C 干净地中断该循环。 ## 模块 ### 文件完整性监控器 (`collector/file_integrity.py`) 通过将四个关键 Windows 系统文件的当前 SHA-256 哈希值与基线快照中存储的值进行比较来监控它们。任何不匹配都会生成一个警报，指示文件路径、预期哈希、当前哈希、时间戳和严重性级别。 **监控的文件和严重性** | 文件 | 严重性 | 原因 | |---|---|---| | `ntoskrnl.exe` | CRITICAL | Windows 内核 - 被攻陷意味着完全接管系统 | | `lsass.exe` | CRITICAL | 管理身份验证和凭据 - 凭据转储攻击的主要目标 | | `cmd.exe` | HIGH | 替换为恶意版本可执行任意代码 | | `drivers\etc\hosts` | MEDIUM | 修改可实现 DNS 劫持和流量重定向 | 严重性级别是根据成功篡改的爆炸半径分配的——如果该文件被攻击者修改，系统将有多少部分被攻陷。 ### 进程监控器 (`collector/process_monitor.py`) 根据基线快照和精心策划的已知合法 Windows 进程白名单监控正在运行的进程。两种不同的条件会生成警报： 1. **未知进程：** 正在运行的进程不存在于基线中，也不包含在已知合法进程的白名单中。 2. **进程伪装 (MITRE T1036)：** 进程名称与已知合法名称匹配，但从未预期的路径运行。这种技术通常被恶意软件用来冒充系统进程——例如，恶意 `lsass.exe` 从 `AppData\Roaming` 而不是 `System32` 运行。 为了处理同一进程可以从多个有效路径运行的合法情况（例如 `dllhost.exe` 同时来自 `System32` 和 `SysWOW64`），`PROCESS_TRUSTED_PATHS` 字典定义了每个进程的可接受路径——防止误报而不削弱检测能力。 **警报严重性：** 进程伪装为 CRITICAL，未知进程为 MEDIUM。 ### 网络监控器 (`collector/network_monitor.py`) 与其他收集器不同，网络监控器不与静态基线进行比较。网络连接本质上是动态的——在几秒钟内创建和关闭——这使得基线比较不可靠且容易产生过多的误报。相反，检测是基于实时应用于所有活动连接的三个行为规则。 **规则 1 - 可疑端口：** 标记指向通常与反向 Shell 和命令与控制 (C2) 基础设施相关联的端口的连接。 | 端口 | 已知用途 | |---|---| | 4444 | Metasploit 默认 | | 4445 | Metasploit 备选 | | 1337 | 常见攻击工具 | | 31337 | 经典后门 | | 8888 | 常见 C2 | | 9001 | Tor 默认 | **规则 2 - 可疑进程连接：** 标记由在正常情况下绝不应通过网络通信的进程发起的连接（`lsass.exe`、`cmd.exe`、`regedit.exe`、`taskmgr.exe`）。来自这些进程中任何一个的出站连接是系统被攻陷的强烈指示。 **规则 3 - 可疑 IP：** 标记指向在公共威胁情报来源中被记录为恶意的 IP 地址的连接。当前实现使用手动更新的静态列表——自动威胁情报源集成计划在 V2 中实现。 **警报严重性：** 可疑进程连接为 CRITICAL，可疑端口和 IP 为 HIGH。 ### 日志监控器 (`collector/log_monitor.py`) 解析 Windows 安全事件日志，监控根据 **MITRE ATT&CK 框架** 选择的五个关键事件 ID——将已知攻击技术映射到其相应的 Windows 事件。 | 事件 ID | 描述 | 严重性 | MITRE 策略 | |---|---|---|---| | 4625 | 登录尝试失败 | MEDIUM | 初始访问 | | 4688 | 创建了新进程 | LOW | 执行 | | 4697 | 安装了新服务 | HIGH | 持久化 | | 4698 | 创建了新计划任务 | HIGH | 持久化 | | 4663 | 文件/对象访问尝试 | MEDIUM | 防御规避 | **检查点模式：** 为了避免重新处理已分析的事件，最后处理的记录号在周期结束时保存到 `data/checkpoint.json`。下一个周期从该记录号恢复——确保没有事件被遗漏或重复。 **事件 4688 过滤器：** 在任何活动的 Windows 系统上，新进程创建事件都极其频繁——每分钟生成数百个事件。为了避免警报疲劳，仅当父进程在与 Living off the Land (LotL) 攻击和反向 Shell 技术相关的已知可疑进程列表中时，事件 4688 才会生成警报：`cmd.exe`、`powershell.exe`、`wscript.exe`、`cscript.exe`、`mshta.exe`、`rundll32.exe`。 从事件记录的 `StringInserts[13]` 中提取父进程字段——这是 Windows 特定的字段，包含生成新进程的进程的完整路径。 ## 安装 ### 前置条件 - Windows 10 或 Windows 11 - Python 3.x - 使用 `python --version` 验证 - Git - 使用 `git --version` 验证 ### 步骤 1. 克隆仓库： ``` git clone https://github.com/yourusername/hids-project.git cd hids-project ``` 2. 创建并激活虚拟环境： ``` python -m venv venv .\venv\Scripts\Activate.ps1 ``` 3. 安装依赖项： ``` pip install -r requirements.txt ``` ### ⚠️ 重要 HIDS 必须以 **Administrator** 身份运行——它需要提升的权限来访问 Windows 安全事件日志并读取受保护的系统文件。 在执行任何脚本之前，请始终使用 **"以管理员身份运行"** 打开 PowerShell。 ## 用法 ### 首次运行 - 生成基线 在启动监控循环之前，生成系统基线： ``` python baseline_generator.py ``` 这将创建当前系统状态的快照——文件哈希、正在运行的进程和活动的网络连接——并保存到 `data/baseline.json`。 ### 启动监控循环 ``` python main.py ``` 系统将自动验证基线是否存在，然后以 60 秒的间隔在连续循环中开始监控所有四个攻击面。 按 `CTRL+C` 停止。 ### 解读警报 每个警报包括：时间戳、警报类型、严重性级别和详细信息。 | 严重性 | 所需操作 | |---|---| | CRITICAL | 立即调查 - 隔离受影响的文件或进程 | | HIGH | 在几分钟内调查 - 检查 Windows 事件查看器以获取详细信息 | | MEDIUM | 在一小时内调查 - 可能是误报 | | LOW | 在下次有机会时审查 - 可能是良性的 | ### 调查 CRITICAL 和 HIGH 警报 1. 记录 `alert_type`、`filepath` 或 `process_name` 以及 `timestamp` 2. 打开 **Windows 事件查看器** -> **Windows 日志 -> 安全** 3. 按相关事件 ID 筛选 4. 分析详细信息 - 帐户名、登录类型、工作站 5. 确定它是真正的威胁还是误报 此过程被称为 **警报分流**——这是标准 SOC 分析师的工作流程。 ## 技术决策 ### 用于文件完整性验证的 SHA-256 尽管 MD5 和 SHA-1 速度更快，但特意避免了它们。这两种算法都容易受到冲突攻击——攻击者可以制作一个与原始文件产生相同哈希值的恶意文件，从而完全破坏完整性检查。SHA-256 没有已知的冲突，是安全上下文中完整性验证的当前标准。 ### 基于规则的检测优于基于异常的检测 为 V1 选择了基于规则的引擎，原因有两个：它是可审计的——每个警报都可以追溯到特定规则——并且它不需要训练期。基于异常的检测需要历史数据来建立行为基线，这使得它在没有先前历史的新系统上不可靠。它计划在 V2 中实现。 ### 模块化架构 - 关注点分离 每一层（收集器、分析器、警报器）都有单一的责任。这实现了故障隔离——失败的收集器不会阻塞其他收集器——并使代码库更易于扩展。添加新的检测面只需要添加一个新的收集器，而无需触及现有模块。 ### 日志监控器中的检查点模式优于时间戳 保存最后处理的 Windows 事件日志记录号而不是时间戳。记录号是连续的唯一整数——可以直接访问且没有歧义。时间戳不是唯一的：多个事件可以共享相同的毫秒级时间戳，这使得基于时间戳的过滤不可靠，并可能导致事件被遗漏或重复。 ### 进程监控器中的优雅降级 进程属性（如 `exe` 和 `username`）是在独立的 try/except 块中收集的。如果由于 `AccessDenied` 导致读取某个属性失败，该进程仍会被添加到结果中，并将该字段设置为 `null`——而不是丢弃整个进程。这最大化了数据收集，而不会在受保护的系统进程上崩溃。 ## 已知限制 ### 仅限 Windows 该系统依赖 `pywin32` 进行 Windows 事件日志访问，并依赖 Windows 特定的 API 进行进程和文件监控。检测规则也映射到 Windows 特定的攻击向量。移植到 Linux 或 macOS 需要重写所有四个收集器。 ### Windows 更新后需要手动重新生成基线 Windows 更新会用较新版本替换系统文件，从而改变其 SHA-256 哈希值。在重大更新之后，必须使用 `python baseline_generator.py` 手动重新生成基线，以避免在合法系统文件上出现持续的 FILE_MODIFIED 误报。 ### 白名单绕过风险 进程白名单引入了一个已知的弱点：知道白名单进程名称的攻击者可以将其恶意软件命名为白名单进程以逃避检测。这通过 `PROCESS_TRUSTED_PATHS` 检查得到了部分缓解——从未预期路径运行的白名单进程仍会生成 PROCESS_MASQUERADING 警报——但并不能完全消除风险。 ### 静态威胁情报 网络监控器使用已知恶意 IP 的静态列表。在上次手动更新后记录的新恶意 IP 将不会被检测到。自动威胁情报源集成——定期从 AbuseIPDB 等来源拉取更新的 IP 列表——计划在 V2 中实现。 ## 路线图 ### V2 - 基于异常的检测 实现一个机器学习模型，该模型随时间学习正常的行为并自动标记偏差——从静态规则转向动态行为分析。需要在当前基于规则的引擎收集的历史数据上进行训练期。 ### v2 - 动态威胁情报 用从公共威胁情报来源（AbuseIPDB、新兴威胁列表）定期更新的自动源替换静态列表。这涵盖了可疑端口、恶意 IP 和已知的恶意进程签名——确保检测规则保持最新，而无需人工干预。 ### V2 - 事件驱动基线 自动检测 Windows 更新何时正在进行（通过监控 `TiWorker.exe` 和 `TrustedInstaller.exe`），并在完成后自动重新生成基线——消除每次更新后手动重新生成的需要。 ### V3 - 警报通知系统 集成通过电子邮件、Telegram 或 Slack 进行实时警报传递——无需保持终端打开即可进行监控。CRITICAL 警报将触发即时通知。 ### V3 - 网络级监控扩展 将系统从单个主机扩展到网络级监控——与正确配置的路由器或专用设备集成，以捕获和分析整个本地网络的流量。 ### V3 - 可视化仪表板 用轻量级 Web 仪表板替换基于 JSON 的警报存储，用于实时警报可视化、历史分析和趋势检测。

标签：Cloudflare, HIDS, Homebrew安装, MITRE ATT&CK, Python, SHA-256, TLS, Web报告查看器, Windows事件日志, x64dbg, 主机入侵检测, 云计算, 子域名枚举, 工具集, 攻击面, 无后门, 系统安全, 网络安全, 网络安全审计, 网络连接监控, 规则引擎, 进程伪装检测, 逆向工具, 防御工具, 隐私保护