AttadaManoj/dtac-ir

# DTAC-IR — 动态信任评估与控制，事件响应 这是一个实时网络入侵检测与响应平台，结合了基于规则的检测、训练有素的 ML 分类器以及自定义的信任评分引擎，并配备了一个实时的 SOC dashboard 以提供可视化和响应能力。 该项目的架构设计可媲美开源 SOC 工具（Wazuh, Suricata），作为作品集项目，它展示了端到端的安全工程：数据包捕获 → 特征提取 → 混合检测 → 自适应信任评分 → 数据持久化 → 实时可视化。  ## 项目初衷 大多数学生的 IDS 项目仅仅停留在“判断数据包是否为恶意”的层面。DTAC-IR 提出了一个不同的问题：**基于设备随时间推移的行为，我们当前应该对特定设备给予多大的信任度** —— 以及系统应该如何自动应对？ 这就是 **Trust Scoring Engine**（信任评分引擎）的工作，也是该项目的核心差异化所在。网络上的每个设备初始均处于完全信任状态（100）。检测到的威胁会根据严重程度进行加权惩罚，并通过指数时间衰减来降低该评分，使设备经历以下四种状态： ``` TRUSTED (70–100) → SUSPICIOUS (30–69) → QUARANTINED (10–29) → BLOCKED (0–9) ``` 这为 SOC 分析师（或自动化响应层）提供了持续信号，而非简单的二元告警 —— 一个设备在一周内出现五次微小异常，与在最后一分钟内出现五次异常的情况截然不同，而评分机制准确地反映了这一点。 ## 架构 ``` ┌─────────────┐ ┌──────────────────┐ ┌───────────────────┐ │ Scapy │────▶│ Detection Engine │────▶│ Trust Scorer │ │ (live pkts) │ │ Rules + ML │ │ (severity decay) │ └─────────────┘ └──────────────────┘ └───────────────────┘ │ │ ▼ ▼ ┌─────────────────┐ ┌──────────────────┐ │ PostgreSQL │◀────▶│ FastAPI REST │ │ (devices/alerts) │ │ + WebSocket │ └─────────────────┘ └──────────────────┘ │ ▼ ┌────────────────────────┐ │ React SOC Dashboard │ │ (hex trust grid, live │ │ alerts, timeline) │ └────────────────────────┘ ``` **检测是混合式的，而非纯粹依赖 ML：** 首先运行规则（速度快，对于端口扫描和 SYN 泛洪等已知特征，误报率几乎为零）；如果没有规则触发，则由 ML 分类器对流量进行评估。这使得对于已充分了解的攻击，系统可以保持低延迟，同时仍能捕获规则未覆盖的新型模式。 ## 技术栈 **后端** - FastAPI (异步), SQLAlchemy 2.0 (异步), PostgreSQL, Redis - 使用 Scapy 进行实时数据包捕获 - scikit-learn 随机森林分类器，基于 CICIDS2017 衍生的合成数据集（通过 SMOTE 对 6 个类别进行平衡）进行训练 - WebSocket 流式传输，用于实时 dashboard 更新 **前端** - React 18 + Vite 5, Tailwind CSS, Zustand 用于状态管理 - 使用 Recharts 展示实时威胁时间线 - 自定义基于 SVG 的六边形设备信任网格（未使用任何图表库 —— 专门构建以契合独特的 SOC 风格，而非通用的 dashboard 模板） - 内置离线演示/模拟模式，方便在无实时网络访问的情况下进行作品集展示 **基础设施** - 使用 Docker Compose 部署 Postgres/Redis（并支持可选的完全容器化部署） - 专为 WSL2/Linux 设计，因为原始数据包捕获需要 root 权限及 `NET_ADMIN`/`NET_RAW` 权限 ## 本地运行 ### 前置条件 - Python 3.10+, Node 18+, Docker - Linux/WSL2（Scapy 数据包捕获需要真实的网络接口和 root 权限 —— 在没有桥接接口的沙盒/虚拟机环境中无法完全正常运行） ### 1. 启动 Postgres + Redis ``` cd docker docker compose up -d postgres redis ``` ### 2. 后端 ``` cd backend python3 -m venv venv source venv/bin/activate pip install -r requirements.txt cp .env.example .env # then edit SECRET_KEY and CAPTURE_INTERFACE (check with `ip a`) sudo venv/bin/uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload ``` Scapy 需要通过原始套接字访问来捕获实时流量，因此需要 root 权限。 ### 3. 前端 ``` cd frontend npm install npm run dev ``` 打开 `http://localhost:5173`。页面在加载时会检查后端的 `/health` endpoint —— 如果无法访问，它会自动切换到**演示模式**，该模式会模拟真实的设备/告警活动，因此即使在离线状态下，dashboard 也能随时进行演示。 ### 4. API 文档 FastAPI 的交互式 Swagger UI 可在 `http://localhost:8000/api/docs` 访问。 ## 真实检测实战 顶部的截图是演示模式 —— 专为离线作品集演示模拟的流量。以下是在同一 dashboard 上针对**实时网络流量**运行的截图，在几个小时内，少数外部 IP 持续对主机进行端口扫描。信任引擎正确地将其评分降至接近零，并将它们的状态更改为 `QUARANTINED`/`BLOCKED`。然而，这并非永久性的黑名单 —— 一旦设备停止异常行为，其评分会以指数级速度恢复至基准线（100），因此安静下来的设备有机会重新获得受信任状态，而不是永远处于被标记状态。  ## 核心设计决策 - **规则优先，ML 兜底** 而非纯 ML：确保常见攻击的检测快速且可解释，将模型保留用于规则无法捕获的场景。 - **信任评分作为持续信号，而非二元告警**：反映了真实 SOC 分级响应的工作方式 —— 随时间推移的上下文和模式比任何单一事件都更为重要。 - **在检测前显式过滤多播/广播流量**：mDNS (`224.0.0.251:5353`)、SSDP 和受限广播 (`255.255.255.255`) 属于正常的本地网络通信，简单的分类器很容易将其误判为扫描行为。从源头上过滤掉这些流量，可以保证信噪比的真实性，而不是用无害流量虚增威胁数量。 - **针对告警采用 WebSocket 推送，而不仅仅是轮询**：新的检测会立即广播到已连接的 dashboard，无需等待下一次轮询间隔。 ## 已知局限性 坦诚地说，这些局限性恰恰是面试中最值得探讨的有趣部分： - **ML/规则分类体系不匹配**：第一阶段的规则引擎和第二阶段的 ML 分类器是基于略微不同的攻击分类体系开发的（规则包括：`PORT_SCAN`、`SYN_FLOOD`、`DNS_EXFILTRATION`、`BRUTE_FORCE`、`ARP_SPOOFING`；ML 包括：`BENIGN`、`BOTNET`、`BRUTE_FORCE`、`DOS`、`PORT_SCAN`、`WEB_ATTACK`）。数据库 schema 中的 `AttackType` 枚举随后已进行扩展以覆盖两者，但当检测子系统独立演进时，这是一个很好的例子，说明在 pipeline 中保持共享分类体系同步是多么重要的一课。 - **内存中的信任评分**：Trust Scoring Engine 为了追求速度，将实时评分保留在内存中，并定期同步到 Postgres。重启会重置进行中的衰减状态（数据库中持久化的历史记录将保持完好）。 - **单主机数据包捕获**：目前仅能观察其运行主机可见的流量。要扩展到全网可见性，意味着需要将其部署为 span-port/mirror listener，或者部署多个分布式传感器以向中央信任引擎报告。 - **API/dashboard 尚未支持身份验证**：对于本地演示来说还可以，但在任何多用户或面向互联网的部署之前，需要引入 JWT/session 认证机制。 ## 项目背景 本项目作为大学课程作业的刻意升级，旨在打造一个作品集级别的平台，并分阶段进行开发： - **第一阶段 (Phase 1)**：FastAPI 后端，SQLAlchemy 模型，基于规则的检测引擎，带指数衰减的信任评分，Docker Compose，WebSocket endpoints - **第二阶段 (Phase 2)**：完整的 ML 训练 pipeline —— CICIDS2017 数据加载器，SMOTE 平衡，随机森林分类器，混合检测架构 - **第三阶段 (Phase 3)**：React SOC dashboard —— 六边形信任网格，实时威胁时间线，终端风格告警推送，离线演示模式 ## 演示视频 https://github.com/user-attachments/assets/2c1e1c5c-802b-4360-8234-203a4059cc31 ## 作者 Attada Manoj — B.Tech Cybersecurity, CMR College of Engineering and Technology, Hyderabad CEH v13 | Cisco CCNA | Cisco Junior Cybersecurity Analyst Career Path

标签：Apex, 威胁可视化, 安全运营中心, 库, 应急响应, 搜索引擎查询, 机器学习, 测试用例, 版权保护, 网络安全, 网络映射, 逆向工具, 隐私保护