3. 实验环境搭建

Suricata 的检测能力高度依赖“它能看到什么流量”。因此实验环境搭建的核心不是把软件装上，而是让 Suricata 的抓包接口与真实流量路径对齐。本节围绕三种典型部署形态——物理机、虚拟机、容器——说明各自的网卡选择、镜像流量接入方式和基础运行参数，并给出可直接复现的配置示例。

一、三种部署形态的定位与差异

物理机部署最接近生产环境：Suricata 直接绑定物理网卡，可借助交换机端口镜像（SPAN）或网络分流器（TAP）获得完整流量，性能上限最高，适合做吞吐与规则性能测试。虚拟机部署灵活、可快照回滚，通常把宿主机网卡或虚拟交换机端口设为混杂/镜像模式，让虚拟机的虚拟网卡收到全部流量，适合规则调试与教学。容器部署最轻量，但容器默认处于独立网络命名空间，必须显式授予抓包能力并共享宿主机的网络命名空间，否则只能看到容器自身流量。

三者的关键差异可以归纳为“抓包接口来源”和“权限模型”两点，下图给出三种形态的流量接入关系与关键配置点。

二、物理机部署：从镜像口到服务托管

物理机部署的第一步是确定抓包网卡。假设管理口为 eth0（192.168.10.20/24），镜像口为 eth1，交换机已把被监测网段的双向流量复制到 eth1。镜像口不需要配置 IP，也不应参与路由，避免 Suricata 自身流量混入。启用混杂模式并确认收包：

sudo ip link set eth1 promisc on
sudo ip link set eth1 up
# 观察是否持续有包进入（Ctrl+C 结束）
sudo tcpdump -i eth1 -nn -c 20

若 tcpdump 能看到双向会话，说明镜像链路正常。随后安装 Suricata 并修改 /etc/suricata/suricata.yaml 的关键项：把 af-packet 段的 interface 改为 eth1，cluster-type 设为 cluster_flow 以保证同一会话落到同一线程；HOME_NET 设为被监测网段，例如 [192.168.10.0/24]；default-log-dir 保持 /var/log/suricata。规则更新后即可启动：

sudo suricata-update
sudo suricata -T -c /etc/suricata/suricata.yaml -v   # 配置自检
sudo systemctl enable --now suricata
sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'

判断部署是否成功的依据有三条：suricata -T 输出 “Configuration provided was successfully loaded”；eve.json 中持续出现 flow 事件说明流量已进入引擎；触发一条测试规则后能看到 alert 事件。若只有 stats 没有 flow，通常是网卡选错或镜像未生效。

三、虚拟机部署：镜像口与业务口分离

虚拟机部署与物理机思路一致，差别在于“镜像”由虚拟交换机完成。以 VMware 为例，可把 VM 的一块虚拟网卡连接到“仅主机”或专用端口组，并在宿主机侧对该端口组开启混杂模式；KVM/libvirt 则可用 virsh 把 vSwitch 的镜像目标指向 VM 的 vnetX。虚拟机内同样用 ip link set ens33 promisc on 打开混杂模式。

虚拟机部署要特别注意两点：一是抓包网卡与 SSH 管理网卡分开，否则镜像流量会挤占管理通道；二是给足 CPU 与内存，AF_PACKET 多线程在高流量下会吃满单核。建议实验环境至少 2 vCPU、4 GB 内存，并把 af-packet 的 threads 设为 vCPU 数量。虚拟机可随时打快照，适合反复验证规则改动，但要注意快照会保存 eve.json 状态，回滚后日志会“倒退”，分析时需留意时间线。

四、容器部署：能力、网络与持久化

容器部署最容易踩的坑是“装上了却抓不到包”。原因是容器默认只有 NET_RAW 之外的受限能力，且处于独立网络命名空间。正确做法是共享宿主机网络并显式授予抓包能力：

docker run -d --name suri \
  --network host \
  --cap-add=NET_RAW --cap-add=NET_ADMIN \
  -v /etc/suricata:/etc/suricata \
  -v /var/lib/suricata:/var/lib/suricata \
  -v /var/log/suricata:/var/log/suricata \
  jasonish/suricata:latest -i eth0

这里 --network host 让容器直接使用宿主机 eth0，NET_RAW 允许原始套接字抓包，NET_ADMIN 允许设置混杂模式。三个挂载点分别持久化配置、规则和日志，避免容器重建后数据丢失。启动后用 docker logs suri 观察是否出现 “all 1 packet processing threads, 4 management threads initialized”，再用 docker exec suri suricatasc -c "iface-list" 确认接口状态。

五、基础运行参数与验证清单

无论哪种形态，以下参数都建议在实验前确认：抓包接口名、HOME_NET 与 EXTERNAL_NET、运行模式（af-packet 或 pcap）、线程数与 cluster 类型、日志目录与轮转策略、规则集来源。下表给出三种形态的对照，便于按环境选择。