目录
[一、 SELKS 简介](#一、 SELKS 简介)
[二、 实验环境架构](#二、 实验环境架构)
[三、 SELKS 网卡与流量镜像配置](#三、 SELKS 网卡与流量镜像配置)
[1. SELKS 底层网卡配置 (/etc/network/interfaces)](#1. SELKS 底层网卡配置 (/etc/network/interfaces))
[2. 关联 Suricata 监听接口](#2. 关联 Suricata 监听接口)
[3. PVE 宿主机流量引流配置（tc 镜像）](#3. PVE 宿主机流量引流配置（tc 镜像）)
[四、 核心管理：Scirius 规则更新与构建（Update & Build Ruleset）](#四、 核心管理：Scirius 规则更新与构建（Update & Build Ruleset）)
[五、 常见问题与排查全记录 (踩坑实录)](#五、 常见问题与排查全记录 (踩坑实录))
[问题 1：SELKS 抓包时，为何能抓到除目标外的其他数据包？](#问题 1：SELKS 抓包时，为何能抓到除目标外的其他数据包？)
[问题 2：Kibana 打开提示 "Welcome to Kibana / don't have any data"](#问题 2：Kibana 打开提示 "Welcome to Kibana / don't have any data")
[问题 3：Events 中有流量日志，但 EveBox 的 Alerts/Inbox 始终为空](#问题 3：Events 中有流量日志，但 EveBox 的 Alerts/Inbox 始终为空)
[排查 1：时区与时间过滤排查](#排查 1：时区与时间过滤排查)
[排查 2：测试 payload 特征匹配验证](#排查 2：测试 payload 特征匹配验证)
[排查 3：底层日志输出与管道连接（终极排查）](#排查 3：底层日志输出与管道连接（终极排查）)
[六、 最终验证结果](#六、 最终验证结果)
[七、 总结](#七、 总结)
在网络安全运维与靶场建设中，流量镜像（Port Mirroring） 与 入侵检测系统（IDS） 的结合是捕获网络攻击、实时感知威胁的核心手段。
本文将分享如何利用开源企业级 IDS 方案 SELKS ，配合 Proxmox VE (PVE) 虚拟化平台的网桥流量镜像功能，从零搭建一套全天候网络安全监控平台，并详细记录网卡配置、规则库更新编译以及实践中踩坑的排查思路。
一、 SELKS 简介
SELKS 是由 Stamus Networks 维护的一款基于 Debian 的免费开源 IDS/IPS 平台。它的名字由其核心集成的开源组件首字母组合而成：
-
S (Suricata)：高性能网络威胁检测引擎（IDS/IPS/NSM）。
-
E (Elasticsearch)：分布式的日志存储与搜索引擎。
-
L (Logstash)：日志收集、过滤与格式化洗数据管道。
-
K (Kibana)：功能强大的数据可视化与分析仪表盘。
-
S (Scirius)：专为 Suricata 设计的 Web 规则集管理与配置中心。
-
EveBox（补充）：轻量化、专门用于处理与归档 Suricata 告警（Alerts）的 Event 告警中心。
二、 实验环境架构
-
虚拟化宿主机 (PVE) ：
172.16.13.90(负责虚拟交换机与流量镜像tc配置) -
靶机 (Metasploitable2) ：
172.16.13.173(受保护/受监控对象) -
IDS 分析引擎 (SELKS) ：
172.16.13.89(流量接收与分析中心，管理接口ens18，接收接口ens19) -
攻击测试机 (物理机) ：
172.16.13.95(发起流量与扫描的主机)
三、 SELKS 网卡与流量镜像配置
为了保证管理流量与镜像抓包流量互不干扰，SELKS 在 PVE 中建议分配两块虚拟网卡：
-
管理网卡 (
ens18) ：配置常规 IP（172.16.13.89），用于 SSH 登录及访问 Web 控制台。 -
监听网卡 (
ens19) ：无 IP 地址、开启混杂模式（Promiscuous Mode），专门被动接收来自 PVE 的镜像流量。
1. SELKS 底层网卡配置 (/etc/network/interfaces)
登录 SELKS 虚拟机（.89）终端，修改网络配置文件：
nano /etc/network/interfaces写入以下双网卡配置：
# 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 networking2. 关联 Suricata 监听接口
确认配置文件 /etc/suricata/suricata.yaml 中的 af-packet 抓包接口指定为监听网卡 ens19：
af-packet:
- interface: ens19
cluster-id: 99
cluster-type: cluster_flow
defrag: yes3. 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：-
进入 Management \\rightarrow Index Patterns \\rightarrow Create index pattern。
-
输入索引前缀：
logstash-*。 -
时间字段选择：
@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 可视化展示 的完整链条成功闭环！
七、 总结
搭建 IDS 平台不仅需要理解引擎本身的配置，还必须正确规划双网卡（管理卡与混杂监听卡）的分工，掌握 Scirius 规则库的更新与推送机制 ，以及 ELK 日志流水线 的传递链路。
遇到告警不显示时，可遵循以下四步排查法：
-
网络层 ：用
tcpdump -i ens19确认监听网卡是否有流量进来。 -
引擎层 ：看
eve.json是否有event_type: alert写入（验证规则是否触发）。 -
传输层 ：检查
Logstash服务与 Elasticsearch 索引（logstash-*）映射。 -
展现层：排查 EveBox/Kibana 的时区与时间过滤设置。