akashreddygaddam/suricata-ids-traffic-analysis

# Suricata 网络 IDS 与流量分析 一个基于 **Suricata** 构建的家用实验环境网络入侵检测系统（NIDS），部署用于在隔离的 VMware 实验网络中检测和分析侦察、扫描和暴力破解流量。包含一个自定义的 **Python 工具**，用于将原始的 Suricata 告警日志解析为可读的摘要报告、CSV 导出以及可视化图表。     ## 概述 该项目模拟了一个由 Suricata 传感器监控的小型企业网络网段。使用攻击机（Kali Linux）针对目标主机生成真实的侦察、扫描和暴力破解流量，同时加载了完整 Emerging Threats Open 规则集（约 52,000 个特征码）的 Suricata 对流量进行实时检测并生成告警。然后，使用 Python 脚本将这些告警解析为攻击者摘要、特征码分类和时间线图表。 **项目意义：** 搭建检测工具并理解告警*为什么*会或不会触发是 Tier 1 SOC 的核心工作——该项目侧重于检测与分流方面，是对我的 [Cowrie SSH 蜜罐项目](https://github.com/akashreddygaddam/cowrie-ssh-honeypot)（侧重于欺骗和攻击者行为捕获）的补充。 ## 架构 ┌─────────────────┐ ┌──────────────────────┐ │ Kali Linux │ ───► │ Ubuntu 传感器 VM │ │ (攻击者) │ │ Suricata IDS │ │ 192.168.50.20 │ │ 192.168.50.10 │ └─────────────────┘ │ Interface: ens33 │ │ Ruleset: ET Open │ │ (52,000+ 特征码) │ └──────────┬───────────┘ │ ▼ /var/log/suricata/eve.json │ ▼ suricata_report.py (Python) │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ alerts_report.csv top_signatures.png alert_timeline.png 所有虚拟机均运行在隔离的 VMware **Host-only 网络 (VMnet2, 192.168.50.0/24)** 上——没有任何流量离开实验室，并且传感器使用第二个连接 NAT 的网络适配器专门用于更新规则。 ## 测试的攻击场景 | 攻击类型 | 工具 | 触发的特征码 | |---|---|---| | TCP SYN 扫描 | `nmap -sS` | ET SCAN Potential SSH Scan | | NULL / Xmas 扫描 | `nmap -sN` / `-sX` | (规避技术——参见经验教训) | | 操作系统及服务检测 | `nmap -sV -O` | SURICATA ICMPv4 unknown code | | 漏洞扫描 | `nmap --script vuln` | ET SCAN Suspicious inbound to MySQL/PostgreSQL/MSSQL/Oracle SQL, ET SCAN Potential VNC Scan | | SSH 暴力破解 | `hydra` (8 个并行线程) | ET SCAN Potential SSH Scan | | 主机指纹识别 | Kali DHCP 请求 | ET INFO Possible Kali Linux hostname in DHCP Request Packet | ## 示例输出 ============================================================ SURICATA ALERT SUMMARY REPORT Total alerts analyzed: 44 Top Attacking IPs: 192.168.50.20 31 alerts 0.0.0.0 9 alerts 192.168.50.10 4 alerts Top Signatures Triggered: [12] GPL ICMP PING *NIX [9] ET INFO Possible Kali Linux hostname in DHCP Request Packet [8] SURICATA ICMPv4 unknown code [5] ET SCAN Potential SSH Scan [2] ET SCAN Suspicious inbound to mySQL port 3306 [2] ET SCAN Suspicious inbound to Oracle SQL port 1521 [2] ET SCAN Potential VNC Scan 5800-5820 [2] ET SCAN Suspicious inbound to MSSQL port 1433 [2] ET SCAN Suspicious inbound to PostgreSQL port 5432 Alerts by Severity: Severity 1: 9 alerts Severity 2: 15 alerts Severity 3: 20 alerts   ## 关键发现 / 学到的经验 - **`HOME_NET` 配置错误会悄无声息地破坏检测。** 我的前几次攻击运行没有产生*任何*告警，尽管流量明显已经到达传感器。根本原因：Suricata 默认的 `HOME_NET` 覆盖了整个 `/24` 子网——包括攻击者自己的 IP——因此要求流量来自 `$EXTERNAL_NET` 的规则永远无法匹配。将 `HOME_NET` 缩小到仅受保护的主机（`/32`）后，立刻修复了检测问题。这是一种在现实中非常常见的配置错误。 - **并非所有的攻击工具都会触发所有的特征码。** 一个专门针对基于 `libssh` 的暴力破解工具编写的特征码在针对 Hydra/OpenSSH 流量时从未被触发，因为客户端 banner 不匹配——这很好地提醒了我们，基于特征码的检测是特定于模式的，而不是通用的。 - **基于阈值的规则需要足够的流量才能触发。** “ET SCAN Potential SSH Scan”规则要求在 120 秒内从一个源发起 5 个新连接；少量分散的登录尝试没有达到这个门槛，直到流量被整合为快速的并行连接。 - **其他项目遗留的配置可能会悄无声息地破坏新项目。** 同一台虚拟机上仍然启用了一条旧的 NAT 重定向规则（来自另一个 SSH 蜜罐项目），并且正在将所有 SSH 流量从端口 22 悄悄重定向走——导致了类似“connection refused”的错误，这看起来像是 Suricata 的问题，但实际上是 nftables 的遗留配置造成的。 ## 如何运行 1. 在隔离的 Host-only 网络上设置两台虚拟机。 2. 在传感器上安装 Suricata：`sudo apt install suricata` 3. 将 `/etc/suricata/suricata.yaml` 中的 `HOME_NET` 设置为仅受保护的主机（参见 `suricata.yaml.example`）。 4. 更新规则：`sudo suricata-update` 5. 运行 Suricata：`sudo suricata -c /etc/suricata/suricata.yaml -i -D` 6. 从攻击虚拟机产生流量。 7. 解析结果： ``` pip install -r requirements.txt python3 suricata_report.py ``` ## 展示的技能 - Suricata 部署、配置和规则调整 - 网络分段和隔离实验环境设计（VMware Host-only 网络） - 基于特征码的检测概念（HOME_NET/EXTERNAL_NET、阈值、规则类别） - 使用行业标准工具进行攻击模拟（侦察、扫描、暴力破解） - Python 日志解析、数据聚合和可视化（pandas、matplotlib） - 对网络和检测配置错误的根本原因排查 ## 仓库结构 suricata-ids-traffic-analysis/ ├── README.md ├── suricata_report.py ├── requirements.txt ├── suricata.yaml.example ├── sample_logs/ │ └── eve.json.sample └── output/ ├── alerts_report.csv ├── top_signatures.png └── alert_timeline.png

标签：Metaprompt, Python, Suricata, 安全运营, 扫描框架, 插件系统, 无后门, 日志解析, 现代安全运营, 证书伪造, 逆向工具