Docker + Suricata 实验环境搭建指南：快速部署网络入侵检测与规则验证靶场

用容器跑 Suricata 的价值不只是省去编译安装，而是把"一次性的入侵检测实验"变成可重复、可销毁的动作：拉镜像、挂规则、指网卡、看告警，验证完直接删容器，宿主机不留残余配置。这解决了几类常见问题——想测试一条自写规则是否真的会触发，却不愿在物理机或生产网关上装 IDS；想复现某个告警场景，却担心实验流量跑到办公网；想给团队做规则验证演示，但每次重装环境要花半天。本文按最小可用路径，走一遍基于 Docker 的 Suricata 实验靶场搭建，重点在镜像选型、监听模式差异、自定义规则挂载和告警验证，并给出隔离与清理清单。所有操作应只在你自己拥有或已获书面授权的环境中执行。

适用场景与方案边界

这套环境适合三类工作：验证自写规则能否命中预期流量、对比不同规则集在同一份 PCAP 上的告警差异、给团队做告警研判和告警调优的演练。它不适合直接当作生产 IDS 使用——容器内的 Suricata 没有高可用、没有规则自动更新策略、也没有集中化日志管道，只作为验证沙箱。

需要提前明确的是权限边界：Suricata 要抓包就必须拿到 NET_ADMIN 和 NET_RAW 能力，这在容器语境下基本等同于宿主机网络层的高权限。因此实验容器不要与业务容器混跑在同一台关键宿主机上，更不要把 Docker socket 挂进实验容器。

镜像选型与版本固定

Suricata 官方并不以发行"认证镜像"为主，社区里维护较活跃的是 OISF 开发者维护的 jasonish/suricata，其仓库同时提供 Dockerfile 供审计构建过程。选型时关注三点：

• 版本 tag 必须固定。用 latest 会导致今天验证通过的规则，下周换台机器复现时行为不一致。示例统一用 jasonish/suricata:7.0，实际请按可用的具体 tag 锁定，并在文档里记下版本号。
• 镜像内配置路径固定。主配置在 /etc/suricata/suricata.yaml，规则目录为 /var/lib/suricata/rules，日志默认写 /var/log/suricata。挂载点按这三个路径规划，后面迁移到其他镜像也基本通用。
• 入口即 Suricata 二进制。镜像的 entrypoint 已经是 suricata，所以 docker run 里镜像名之后的参数直接就是 Suricata 的命令行参数，不要再写一遍 suricata。

宿主环境建议用 linux 或 linux 虚拟机。Docker Desktop 在 macOS / Windows 上的 host 网络模式并不会真正共享宿主网络栈，抓不到你期望的流量，这类平台请改用虚拟机内的 Docker。

准备一个工作目录，把规则、日志、PCAP 分开存放：

mkdir -p suri-lab/{rules,logs,pcap}
cd suri-lab

监听模式：host 与 bridge 的真实差异

这一步最容易踩坑，因为两种模式的抓包范围完全不同。

host 网络模式

容器直接使用宿主机网络命名空间，-i 后面写的网卡名就是宿主机上的网卡名（如 ens33、eth0）。这是做规则验证最省事的方式，宿主机上产生的流量、进出宿主机的流量都能看到。

ip -br link            # 先确认宿主机网卡名
docker run --rm -it 
  --name suri-lab 
  --net=host 
  --cap-add=NET_ADMIN --cap-add=NET_RAW 
  -v "$PWD/rules:/rules:ro" 
  -v "$PWD/logs:/var/log/suricata" 
  jasonish/suricata:7.0 
  -i ens33 -S /rules/local.rules -v

-v 结尾用于输出更多启动信息，方便确认接口和规则是否加载成功。-S 会覆盖配置文件里的 rule-files 列表，只加载你指定的文件——这对实验正好，既避免加载整套社区规则带来噪声，也让"规则是否命中"的判断更干净。

bridge 网络模式

默认 bridge（含自定义 bridge）下，容器内的 eth0 只是一对 veth 的一端，只能看到这个容器自己收发的流量，看不到其他容器之间的通信，更看不到宿主机流量。所以"起个 bridge 容器抓靶场流量"通常抓了个空。

如果既要与宿主机隔离，又要看到靶标的完整流量，比较稳妥的做法是让 Suricata 共享靶标容器的网络命名空间：

docker network create --internal suri-lab-net

# 先起靶标（示例占位，替换为你实际使用的靶场镜像）
docker run -d --name target --network suri-lab-net <靶场镜像>

# Suricata 共享 target 的网络栈，eth0 即 target 的 eth0
docker run --rm -it 
  --name suri-lab 
  --network container:target 
  --cap-add=NET_ADMIN --cap-add=NET_RAW 
  -v "$PWD/rules:/rules:ro" 
  -v "$PWD/logs:/var/log/suricata" 
  jasonish/suricata:7.0 
  -i eth0 -S /rules/local.rules

--internal 网络没有默认网关，靶标出不去外网，实验流量闭环在本地网桥内，风险和噪声都更可控。注意共享 netns 后，靶标映射到宿主机的端口在 Suricata 容器视角同样可见，验证时直接用 127.0.0.1:<端口> 访问即可。

挂载自定义规则并验证告警

先做语法检查再启动

规则写错时 Suricata 可能整体加载失败或静默跳过，先用 -T 做配置与规则校验，比对着日志猜要快得多：

docker run --rm 
  -v "$PWD/rules:/rules:ro" 
  jasonish/suricata:7.0 
  -T -c /etc/suricata/suricata.yaml -S /rules/local.rules

输出中重点看 rules successfully loaded 的数量是否为 0，以及有没有 Error 行。加载数为 0 通常意味着规则文件路径没挂对或 -S 指向了空文件。

写两条能立刻触发的规则

选 ICMP 和 HTTP User-Agent 两类最容易构造的流量，验证成本最低：

alert icmp any any -> any any (msg:"LAB ICMP echo request"; itype:8; sid:1000001; rev:1;)
alert http any any -> any any (msg:"LAB suspicious user-agent sqlmap"; flow:established,to_server; content:"sqlmap"; http_user_agent; nocase; sid:1000002; rev:1;)

sid 从 1000001 起是本地规则的常用区间，避免与社区规则冲突。两条规则分别对应两种验证路径：

# 触发 ICMP 规则（host 模式下 ping 本机网关或任一地址）
ping -c 3 192.0.2.1

# 触发 HTTP 规则
curl -A "sqlmap/1.7" http://127.0.0.1:8080/

看结果

告警落在 /var/log/suricata/eve.json，是逐行 JSON。快速筛出实验规则的告警：

tail -f logs/eve.json | grep --line-buffered '"event_type":"alert"'

或者用 jq 提炼关键字段，便于比对：

jq -c 'select(.event_type=="alert") | {time: .timestamp, sig: .alert.signature, sid: .alert.signature_id, src: .src_ip, dst: .dest_ip}' logs/eve.json

判定标准要提前定好：命中时能看到对应 sid；未命中时先确认流量本身是否存在。最有效的对照手段是同时开一个 tcpdump 或抓一份 PCAP，用"流量有没有到网卡"和"规则有没有命中"两个维度分开排查，避免把抓包问题误判成规则问题。

用 PCAP 回放做可重复验证

容器实时抓包受时序和环境影响，同一场景难以复现。更可靠的方式是把流量固化成 PCAP，离线跑：

docker run --rm 
  -v "$PWD/pcap:/pcap:ro" 
  -v "$PWD/rules:/rules:ro" 
  -v "$PWD/logs:/var/log/suricata" 
  jasonish/suricata:7.0 
  -r /pcap/test.pcap -S /rules/local.rules

-r 是离线读取，不需要 NET_ADMIN，也完全不会向网络发包，是团队之间交换验证用例最干净的形式。若需要按原始速率在网卡上重放，可以用 tcpreplay 另起一个容器，但那会真实发包，只在隔离网络里做。

每次离线跑之前建议清空或改名旧的 eve.json，否则新旧告警混在一起，统计规则命中率时会重复计数。

隔离、清理与恢复清单

实验环境最大的隐性成本是残留。开始前先确认隔离，结束后按清单回收：

开始前

• 只在个人虚拟机或专用实验宿主上运行，不与生产服务共宿主机。
• 使用 --internal 自定义网络，或至少确保实验网段不能直达办公网。
• 规则来源可审计，第三方规则先过一遍再加载，避免引入高开销或误报严重的规则拖慢实验。
• 容器名统一前缀（如 suri-），便于批量识别和清理。

结束后

docker rm -f suri-lab target
docker network rm suri-lab-net
docker image prune -f          # 按需，会清理悬空镜像，执行前确认影响范围
rm -rf suri-lab/logs suri-lab/pcap

数据层面：PCAP 与 eve.json 里可能包含明文凭据、Cookie、内网地址等敏感信息，实验结束后不要留在共享目录或提交进代码仓库。宿主机侧本次只改了工作目录，删除目录即恢复原状；如果实验中临时调整过宿主机防火墙或路由（例如为旁路抓包改过转发），务必逐条回滚并记录。

常见故障对照

把这套流程固化成脚本或一份 docker run 模板后，规则验证就从"搭环境"变成"改一条规则、跑一次离线回放、比对一次告警"的短循环。真正需要长期保留的是规则文件、PCAP 用例和每次验证的结论记录，容器本身随时可以丢弃。