Snaksz/SIEM-Threat-Detection-Dashboard

# SIEM 日志分析与威胁检测仪表板 一个微型 SIEM（安全信息与事件管理）工具，用于解析 Linux SSH/sudo 身份验证日志，将其存储在 SQL 中，运行基于规则的 威胁检测，并在交互式仪表板中可视化告警。 **仅供防御/教育使用。** 此处的所有操作均针对合成的、 本地生成的日志文件（或您提供的日志文件）运行——本仓库中的任何内容均不会 扫描、攻击或连接到任何外部系统。示例数据集中使用的所有“攻击者” IP 均来自 IANA 保留的文档地址范围（RFC 5737），而非真实主机。 ## 为什么开发这个项目 蓝队 / SOC 分析师的工作主要包括：将日志转换为结构化格式， 应用检测逻辑，按严重程度进行分类，并将发现转化为具体的 补救措施。本项目端到端地实现了这一完整闭环——日志解析、 关系型 schema、检测工程以及面向分析师的仪表板—— 基于一个足够小、便于手动阅读和验证的数据集。 ## 架构 ``` auth.log ──▶ src/parser.py ──▶ pandas DataFrame ──▶ src/db.py ──▶ SQLite (events) │ ▼ src/detectors.py (5 rules) │ ▼ src/db.py ──▶ SQLite (alerts) │ ▼ dashboard/app.py (Streamlit + Plotly) ``` `src/ingest.py` 将左半部分连接到 CLI pipeline；`dashboard/app.py` 将整个系统连接到一个交互式应用（它也可以直接摄取上传的 文件，而无需使用 CLI）。 ## 文件夹结构 ``` SIEM-Threat-Detection-Dashboard/ ├── README.md ├── requirements.txt ├── Dockerfile ├── docker-compose.yml ├── RESUME_BULLETS.md ├── db/ │ └── schema.sql # events + alerts tables ├── data/ │ ├── generate_sample_logs.py # synthetic auth.log generator │ └── sample_logs/ │ └── auth.log # generated sample dataset (attack scenario embedded) ├── src/ │ ├── parser.py # syslog regex parser -> DataFrame │ ├── db.py # SQLite init/insert/query helpers │ ├── detectors.py # 5 detection rules + severity scoring │ └── ingest.py # CLI: parse -> store -> detect -> alert ├── dashboard/ │ └── app.py # Streamlit dashboard ├── tests/ │ ├── test_parser.py │ └── test_detectors.py └── screenshots/ └── README.md # how to capture + where to place dashboard screenshots ``` ## 安装说明 ``` python -m venv .venv source .venv/bin/activate # Windows: .venv\Scripts\activate pip install -r requirements.txt ``` ## 快速开始 **选项 A —— 仅启动仪表板（推荐）：** ``` streamlit run dashboard/app.py ``` 在侧边栏中：点击 **生成 / 重新生成示例日志**，然后点击 **运行 分析**。或者切换到“上传日志文件”以分析您自己的 `auth.log` 风格的文件（指定日志的年份——经典的 syslog 时间戳 会省略它）。 **选项 B —— CLI pipeline：** ``` python data/generate_sample_logs.py --days 6 --output data/sample_logs/auth.log python -m src.ingest --log-file data/sample_logs/auth.log --db data/siem.db --reset streamlit run dashboard/app.py # reads the same data/siem.db ``` **选项 C —— Docker：** ``` docker compose up --build # 打开 http://localhost:8501，然后从侧边栏生成/运行分析 ``` ## 示例数据集 `data/generate_sample_logs.py` 会生成一个确定性（带种子）且逼真的 `auth.log`，跨越数天，并内置了一个场景： - 5 名员工从内部 IP 进行的正常日常 SSH 登录，包含常规的 `sudo` 使用和偶尔的密码输入错误。 - 背景“互联网噪音”——机器人从分散的 IP 探测常见用户名 （`oracle`、`test`、`postgres`、...），量很小， 不会触发告警（逼真的无误报噪音）。 - 来自单个外部 IP（`203.0.113.7`，一个 RFC 5737 文档地址）的暴力破解攻击，尝试了多个用户名，并最终猜中了 `admin` 账户的弱密码。 - 被攻破后的权限提升尝试：攻击者的会话 尝试了几条 `sudo` 命令（`visudo`、`su -`、读取 `/etc/shadow`、 ...），但均被拒绝。 - 一名真实员工在非工作时间（凌晨 02:17）的一次合法登录。 这无需真实数据集即可演练所有五条检测规则。 ## 检测规则 | 规则 | 函数 | 捕获内容 | 默认阈值 | |---|---|---|---| | 登录失败激增 | `detect_failed_login_spikes` | 一台主机上来自任意 IP 组合的登录失败激增（例如密码喷洒） | 10 分钟内失败 15 次 | | IP 暴力破解 | `detect_brute_force_ips` | 单个源 IP 疯狂尝试登录 | 5 分钟内失败 5 次 | | 失败后成功 | `detect_success_after_failures` | 在来自同一 IP 的多次失败后立即成功的登录——极有可能是账户被攻破 | 15 分钟内先前的失败次数达到 3 次及以上 | | 非工作时间登录 | `detect_off_hours_logins` | 在工作时间之外的成功登录 | 09:00–18:00 之外 | | Sudo / 权限提升 | `detect_sudo_abuse` | 同一用户反复被拒绝/失败的 `sudo` 尝试 | 10 分钟内被拒绝 3 次 | 所有阈值均可在仪表板侧边栏中调整（或通过向 `detectors.run_all_detectors` 传递 `config` 字典来实现）。严重程度（低/中/高/ 严重）根据激增超过阈值的程度进行缩放——参见 `src/detectors.py` 中的 `_scale_severity`。 **实施说明 / 已知的简化处理**（值得了解，特意指出 而非隐藏）： - 时间窗口规则使用真正的滑动窗口（基于 pandas 时间的 `.rolling()`），并且每次激增仅在其峰值处报告一次——而不是每行 报告一次告警。 - 经典的 syslog 时间戳没有年份；解析器会锚定到提供的 `--year`（默认值：当前年份）。真实的 SIEM 通过文件轮转 元数据或结构化的日志格式（例如 journald、CEF、JSON）来处理此问题。 - `detect_success_after_failures` 的复杂度是每个源 IP O(n²)——在日志文件 规模下没问题；生产环境的 pipeline 会使用流式/增量窗口。 ## 数据库 schema 两张表（`db/schema.sql`）：`events`（每个解析后的日志行）和 `alerts` （规则生成的发现，带有严重性标签，并包含 `related_event_ids` 以供 下钻查看）。请参阅该文件以获取完整的列定义和索引。 ## 仪表板 - **概览**：总事件数、失败与成功的登录、总/严重 告警数。 - **失败与成功的登录**，**最可疑的 IP**。 - **随时间变化的告警**，按严重性堆叠。 - **用户风险评分** —— 每个用户告警的加权总和 （严重=10，高=5，中=2，低=1）。 - **最近的严重/高优先级事件**和可筛选的**所有告警**表格。 - **建议** —— 自动生成，与实际触发的规则相关联 （见下文）。 图表颜色遵循经验证的色盲友好调色板：严重性使用 固定的状态调色板（绝不用于其他任何地方），单序列 量级图表使用单一连续色调，多序列图表保持 固定的分类色调顺序。 ## 截图 _在本地运行应用后添加截图——有关确切步骤，请参阅 `screenshots/README.md`。_ ```      ``` ## 安全与业务建议 以下是仪表板针对每个发现所展示的通用的、与规则关联的缓解措施： - **暴力破解 / 密码喷洒** → 对违规 IP 进行速率限制或封锁（fail2ban、 WAF/防火墙规则），并强制目标账户轮换密码。 - **失败后成功** → 视为可能的账户被攻破：立即重置 凭证，审查该账户的后续活动，并在 今后的远程访问中要求使用 MFA。 - **非工作时间登录** → 根据值班/出差计划进行核对；如果 出人意料，暂停该账户以待调查，并考虑 基于时间或条件的访问策略。 - **Sudo / 权限提升尝试** → 审计用户的 sudoers 权限是否符合最小权限原则，并确切审查试图执行了哪些命令，以寻找横向移动的迹象。 - **程序层面**：将身份验证日志集中存储在主机外（这样攻击者就 无法篡改证据），在所有可行的地方启用 MFA，并将 告警量作为重新评估阈值的信号——低价值告警过多 会导致分析师疲劳，从而遗漏真正的安全事件。 ## 测试 ``` pytest ``` ## 可能的扩展 - 在 Linux auth.log 之外，提供 Windows 事件日志（EVTX/XML）和云提供商（AWS CloudTrail、Azure AD 登录日志）的解析器。 - 为每个用户/IP 持久化存储滚动基线，而不是使用固定阈值 （统计/ML 异常评分）。 - 告警去重/抑制窗口以及“误报”反馈 循环，以减少同一来源未来的噪音。 - 将 SQLite 替换为 PostgreSQL（`db/schema.sql` 是可移植的 SQL），以实现 并发的多用户摄取。

标签：AMSI绕过, Kubernetes, SQLite, Streamlit, 威胁检测, 安全, 访问控制, 请求拦截, 超时处理, 逆向工具