JANANIB1/CyberShield
GitHub: JANANIB1/CyberShield
CyberShield 是一个受 SIEM 启发的轻量级 Web 应用,通过基于规则的事件检测和 MITRE ATT&CK 映射来模拟 SOC 分析师的核心安全监控工作流。
Stars: 0 | Forks: 0
# CyberShield — 受 SIEM 启发的安全监控平台
一个轻量级、受 SIEM 启发的 Web 应用程序,用于记录身份验证和网络扫描活动,使用基于规则的阈值检测来标记可疑模式,将标记的模式映射到 MITRE ATT&CK 技术 ID,对整体安全状况进行评分,并将所有信息呈现在监控仪表板上。
## 项目概述
CyberShield 在小规模上模拟了安全运营中心 (SOC) 分析师的核心工作流程:收集事件、应用检测规则、附加公认的框架参考、按严重程度划分优先级,以及将结果可视化。这是一个用于学习/作品集的项目,而不是一个生产级的安全产品——有关其无法执行的操作的明确说明,请参阅下文的**局限性**。
## 问题陈述
小型团队和学生很少能使用商业 SIEM 工具(Splunk、QRadar、Sentinel)。本项目以单个开发人员可以构建和解释的规模,演示了事件收集、基于规则的检测和基于框架的分类是如何结合在一起的——并不声称可以取代这些工具。
## 截图
| 仪表板 | 告警触发 | 端口扫描器 |
|---|---|---|
| `screenshots/dashboard.png` | `screenshots/alert-firing.png` | `screenshots/scanner.png` |
## 演示 GIF
## 架构
```
User Activity (login attempts, port scans)
│
▼
Event Logger (SQLite)
│
▼
Rule-Based Detection Module
(threshold checks over a time window)
│
▼
MITRE ATT&CK Technique Mapping
(lookup table: alert type → technique ID)
│
▼
Risk Scoring + Severity Label
│
▼
Monitoring Dashboard
```
## 工作流(暴力破解示例)
1. 登录失败 → 记录为 `LOGIN_FAILED`,包含用户名和服务器观察到的源 IP (`request.remote_addr`)。
2. 检测模块统计该用户名在过去 N 分钟内的失败登录次数(默认值为 2 分钟内 5 次,可配置)。
3. 如果达到阈值,则会创建一个告警,将其映射到 MITRE **T1110 (Brute Force)**,进行评分,并按严重程度进行标记。
4. 仪表板会显示告警和趋势,如果源 IP 再次出现,则将其标记为重复违规者。
## 功能特性
- 身份验证:bcrypt 密码哈希、强制的密码策略(长度 + 字符要求)、带有 HttpOnly/SameSite cookie 标志的 Flask-Login 会话
- 登录端点上的登录速率限制(Flask-Limiter)
- 将安全事件(登录、端口扫描)记录到 SQLite 中
- 基于规则的威胁检测模块——包含两条规则:暴力破解、端口扫描侦察(基于阈值,非机器学习)
- MITRE ATT&CK 技术映射——通过显式、易读的查找表将告警类型映射到真实的技术 ID (T1110, T1595)
- 风险评分和 0–100 的安全评分,使用已记录并公开的公式(参见设计决策)
- 重复违规者 IP 追踪
- 仪表板支持严重性过滤、搜索、告警趋势和风险分布图表,以及可点击的告警详情视图
- 端口扫描器实用程序,仅限于 localhost 和私有 (RFC1918) 地址范围——在进行任何 socket 调用之前会拒绝公共 IP,以防止使用此项目扫描用户不拥有的基础设施
## 设计决策
- **基于规则的检测,而非 ML。** 阈值是透明的,无需训练数据即可轻松推理,并且符合许多真实 L1/L2 SOC 检测的实际工作方式。这是一个刻意的简单化选择,而不是未来 ML 模型的占位符。
- **安全评分是公开的启发式算法,而非经过验证的模型。** 它从 100 开始,并根据过去 24 小时内告警的严重程度(Critical 减 15,High 减 8,Medium 减 4,Low 减 1)扣除加权惩罚。选择这些权重是为了实现合理的排序,而不是从任何已发布的风险评分标准中推导出来的——明确说明这一点是为了防止该评分被误认为比实际情况更严谨。
- **使用 bcrypt 存储密码** —— 自适应成本因子即使在数据库被窃取时,也能抵御对密码存储的离线暴力破解。
- **使用 `request.remote_addr` 作为源 IP,而不是 `X-Forwarded-For`。** 该项目的早期版本信任客户端提供的 `X-Forwarded-For` 标头,这使得攻击者可以伪造归因于其自身活动的 IP。由于此应用并未部署在真实的反向代理之后,因此完全信任客户端标头本身就是一个错误,而不仅仅是一个边缘情况——现已修复为使用实际的 socket 级地址。
- **端口扫描器仅限于私有/回环范围。** 允许通过共享的演示应用程序扫描任意公共主机是一种真实的滥用和责任风险,而非假设——扫描器会验证并解析目标,并拒绝任何不属于 RFC1918 或回环地址的内容。
- **使用 SQLite 而非客户端-服务器数据库。** 在这种规模下预期不会出现并发写入负载;SQLite 将设置简化为单个 `pip install`,无需运行任何外部服务。
- **使用基于 Socket 的端口扫描器,而不是 `python-nmap`。** 避免了对主机上存在 `nmap` 二进制文件的依赖,因此该项目可以在任何 Python 运行的地方运行。
## MITRE ATT&CK 映射表
| 内部告警类型 | MITRE ID | MITRE 技术 | 触发条件 |
|---|---|---|---|
| `BRUTE_FORCE` | T1110 | Brute Force | 同一用户名在 2 分钟内发生 5 次以上失败的登录 |
| `RECON_PORT_SCAN` | T1595 | Active Scanning | 单次扫描中探测了 5 个以上的端口 |
## 安装说明
```
git clone
cd CyberShield
python -m venv venv
source venv/bin/activate # Windows: venv\Scripts\activate
pip install -r requirements.txt
cp .env.example .env # then set SECRET_KEY to a random string
python app.py
```
访问 `http://127.0.0.1:5000`。SQLite 数据库会在首次运行时自动初始化。
## 演示指南
1. 注册一个账户,然后登录。
2. 在隐私/无痕模式的标签页中,在 2 分钟内使用相同的用户名登录失败 5 次以上 → 仪表板上将出现暴力破解告警 (T1110)。
3. 打开端口扫描器并扫描 `127.0.0.1` → 这将记录一个 `PORT_SCAN` 事件,并由于探测了多个端口而引发侦察告警 (T1595)。根据设计,扫描公共 IP(例如 `8.8.8.8`)会被拒绝。
4. 仪表板更新:安全评分、告警趋势、风险分布和重复违规者列表都会反映新的活动。
## 文件夹结构
```
CyberShield/
├── app.py # Flask routes, auth, session config
├── config.py # Environment-driven configuration
├── requirements.txt
├── .env.example
├── database/
│ ├── schema.sql # Tables + indexes
│ └── db.py # All DB access (parameterized queries)
├── modules/
│ ├── detection.py # Rule-based detection logic
│ ├── mitre_mapping.py # Alert type → MITRE ID + risk score
│ ├── port_scanner.py # Socket-based scanner
│ └── validators.py # Password policy + scan-target validation
├── templates/ # Jinja2 templates
├── static/css/style.css
└── screenshots/
```
## 局限性
这是一份诚实的清单——这也是你在面试中应该预期的内容。
- 没有自动化测试套件;正确性是通过手动和在开发过程中通过临时脚本检查来验证的,而不是通过 CI pipeline。
- 没有授权层级——每个经过身份验证的用户都具有相同的访问权限;没有分析师/管理员的区分。
- 检测仅用于观察。系统会发出告警,但不会采取任何自动响应措施(账户锁定、IP 封锁)。
- Flask-Limiter 默认使用内存存储,该存储会在重启时重置,并且不会在多个 worker 进程之间共享状态——这会通过 runtime 警告予以说明;对于单进程演示来说没问题,但不适用于生产环境。
- 安全评分公式是一个公开的启发式算法(参见设计决策),而不是经过验证或行业标准的评分模型。
- 表单上没有 CSRF token ——对于本地单用户演示来说是可以接受的,但对于任何面向互联网的部署来说都是一个真正的缺口。
- MITRE ATT&CK 覆盖了两种技术,这是为了与实施的两条检测规则相匹配——并非广泛的框架集成。
## 未来改进
- 在所有 POST 表单上提供 CSRF 保护
- 账户锁定 / 临时 IP 封锁,作为对已确认的暴力破解告警的自动响应
- 针对多进程部署的持久化(基于 Redis)速率限制
- 基于角色的访问(分析师 vs. 管理员)
- 额外的检测规则:从一个来源对多个用户名进行密码喷洒
- 自动化测试套件(pytest)
## 许可证
MIT
标签:AMSI绕过, Cloudflare, MITRE ATT&CK, 事件管理, 威胁检测, 安全运营, 扫描框架, 插件系统, 监控看板, 逆向工具