# 1. 管理网卡 (ens18) - 负责正常网络通信与 Web 管理
auto ens18
iface ens18 inet static
    address 172.16.13.89
    netmask 255.255.255.0
    gateway 172.16.13.1
    dns-nameservers 114.114.114.114 8.8.8.8

# 2. 监听网卡 (ens19) - 负责接收镜像流量（无 IP、混杂模式）
auto ens19
iface ens19 inet manual
    up ip link set dev ens19 up
    up ip link set ens19 promisc on
    down ip link set ens19 promisc off
    down ip link set dev ens19 down

保存退出后，重启网络或虚拟机：

systemctl restart networking

2. 关联 Suricata 监听接口

确认配置文件 /etc/suricata/suricata.yaml 中的 af-packet 抓包接口指定为监听网卡 ens19：

af-packet:
  - interface: ens19
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes

3. PVE 宿主机流量引流配置（`tc` 镜像）

在 PVE 宿主机（.90）上利用 tc (Traffic Control) 命令行工具，将发往靶机（.173）的流量复制一份转发给 SELKS 的监听网卡（ens19 对应的虚拟网卡，假设为 vnet89）：

# 在 PVE 宿主机（.90）上配置流量镜像
tc qdisc add dev vnet173 ingress
tc filter add dev vnet173 parent ffff: protocol all u32 match u32 0 0 action mirred egress mirror dev vnet89

四、核心管理：Scirius 规则更新与构建（Update & Build Ruleset）

系统安装完成后，初始规则库往往不是最新的。所有的 Suricata 规则生命周期管理都在 Scirius Web 控制台（[https://172.16.13.89/suricata/](https://172.16.13.89/suricata/)）中完成。

1.1. 更新规则源 (Update Sources)：从上游同步最新特征库。

登录 Scirius 管理界面，在左侧导航栏点击 Sources。
找到默认预设的规则源（如 Emerging Threats Open）。
点击右上角的 Update Sources 按钮。
系统会在后台自动从互联网下载最新的规则文本（通常包含 ET-scan、ET-web_server、ET-exploit 等分类），提示 Update completed 即表示下载成功。

2.2. 检查与启用规则分类 (Categories)：

点击左侧导航栏的 Rules $\rightarrow$ Categories。
浏览刚更新下来的分类列表，确保你需要防护的分类（如 ET-scan、ET-attack_response）右侧显示为 Enabled（绿色）。
如果有分类处于灰色的 Disabled 状态，点击选中并将其切换为 Enable，否则对应的特征将不会被放入监控逻辑中。

3.3. 构建与应用规则集 (Build & Push Ruleset)：将规则编译并加载至 Suricata 引擎。

下载和勾选规则后，它们尚未装载到 Suricata 内存中，必须执行 Build & Push：

点击左侧导航栏的 Suricata（或规则集名称）。
点击右上角的 Build Ruleset：Scirius 会检验规则语法，并将所有启用的分类打包组合成一个全新的规则配置文件。
构建成功后，页面会提示规则集版本更新，点击 Push Ruleset（或 Apply Ruleset）。
此时 Scirius 会向本地的 Suricata 引擎发送热重载（Reload）信号，使新规则即刻生效。

五、常见问题与排查全记录 (踩坑实录)

在搭建与规则更新完成后，看似系统一切正常，但在实操测试中遇到了几个非常典型的断点。以下是排查过程：

问题 1：SELKS 抓包时，为何能抓到除目标外的其他数据包？

现象：在 .89 上用 tcpdump 抓包，除了看到 .95 到 .173 的流量，还看到了大量广播与其它 IP 流量。
原因：虚拟交换机（Linux Bridge）默认会转发局域网的 ARP 广播 和 mDNS/LLMNR 组播 包，SELKS 本身也有背景流量。
解决：属于正常现象，在排查特定流量时指定监听网卡并使用过滤语句即可：
```
tcpdump -i ens19 host 172.16.13.173 -nn
```

问题 2：Kibana 打开提示 "Welcome to Kibana / don't have any data"

现象：首次登录 Kibana 提示集群无数据。
解决：不要选择 Try sample data，直接点击 Explore on my own，随后配置 Index Pattern：
1. 进入 Management $\rightarrow$ Index Patterns $\rightarrow$ Create index pattern。
2. 输入索引前缀：logstash-*。
3. 时间字段选择：@timestamp 并保存即可恢复大屏。

问题 3：Events 中有流量日志，但 EveBox 的 Alerts/Inbox 始终为空

这是本次实验中最复杂的排查过程，涉及多个层面的验证：

排查 1：时区与时间过滤排查

分析：SELKS 默认为 UTC 时间，而浏览器本地为北京时间（UTC+8）。EveBox 的 Alerts 视图对时间敏感度极高，时间戳错位容易导致告警被判定为“超时”而被自动过滤。
处理：将右上角时间范围拉大至 Today 或 All。

排查 2：测试 payload 特征匹配验证

分析：普通的 curl 或部分 User-Agent 扫描可能在较新的 Emerging Threats 规则库中被标记为低级别流量而未触发 alert 动作。

处理：使用标准的威胁特征 payload（测试 root 身份响应）进行验证：

# 发送含有 root 响应特征的攻击测试 Payload
curl http://172.16.13.173/ -A "uid=0(root) gid=0(root)"

排查 3：底层日志输出与管道连接（终极排查）

进入 SELKS（.89）终端实时观察 Suricata 底层日志文件 /var/log/suricata/eve.json：

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

发起攻击后，终端成功打印出以下命中的 JSON 告警日志：

{"event_type":"alert","src_ip":"172.16.13.90","dest_ip":"172.16.13.173","alert":{"signature":"GPL ATTACK_RESPONSE id check returned root"}}

结论：Suricata 引擎与规则匹配 100% 正常，但 Kibana/EveBox 读不到，说明 Logstash 管道传输卡住。

终极解决：在 SELKS（.89）上重启日志洗数据管道服务：
```
systemctl restart logstash evebox
```

六、最终验证结果

重启 Logstash 约 15 秒后，刷新 Web 界面：

EveBox 界面：成功刷出红色高亮告警 GPL ATTACK_RESPONSE id check returned root。
Scirius 界面：Rules Activity 仪表盘同步显示规则 SID: 2100498 的实时命中统计。

标志着从物理网络 $\rightarrow$ PVE 镜像 $\rightarrow$ 监听网卡(ens19) $\rightarrow$ Suricata 检测 $\rightarrow$ Logstash 传输 $\rightarrow$ Elasticsearch 存储 $\rightarrow$ EveBox/Kibana 可视化展示的完整链条成功闭环！