Snort IDS/IPS 部署实验

在 Kali Linux 上的三虚拟机网络中，对 Snort 3 进行了全流程部署，既作为入侵检测系统（被动监控），也作为入侵防御系统（通过 iptables 主动阻断），并针对四种攻击向量完成了验证。

本实验通过将同一套四向量攻击链运行两次，证明了检测与防护之间的运维性区别——第一次针对只能记录日志但无法阻断的 IDS，第二次针对 IDS + iptables IPS 层，后者有选择地丢弃攻击流量，同时保留合法流量。

目录

• 实验环境
• 网络拓扑
• 方法论
• Snort 配置
• 自定义检测规则
• 阶段 1 — IDS 模式
• 阶段 2 — IPS 模式
• IDS vs IPS — 并排结果对比
• 讨论
• 架构说明
• 仓库结构
• 复现实验
• 道德免责声明
• 许可证

实验环境

网络拓扑

攻击机与 Metasploitable 之间的所有流量都会被强制经过分析机，使其成为监控与执行管控两方面的天然咽喉点。

                           ┌─────────────────────────┐
                           │   Analyzer / Router     │
                           │   Kali + Snort 3        │
                           │                         │
   Attacker Kali ──VMnet9──┤ eth1: 10.10.10.1        │
   10.10.10.10             │                         │
                           │ eth0: 192.168.10.143 ───┼──> WAN (NAT)
                           │                         │
   Metasploitable 2 ─VMnet10┤ eth2: 192.168.50.1     │
   192.168.50.10           │                         │
                           └─────────────────────────┘

图片就位后，请用 screenshots/01-network-topology.png 替换此 ASCII 示意图：Topology

方法论

本实验分两个阶段执行，每个阶段使用相同的四向量攻击链：

1. ICMP 侦察 — 使用 ping 进行主机发现
2. Nmap SYN 扫描 — 使用 nmap -sS 进行端口枚举（1000 个端口）
3. Hydra FTP 暴力破解 — 针对 vsftpd 服务的口令攻击
4. vsftpd 2.3.4 后门 — 针对 CVE-2011-2523 的 Metasploit 漏洞利用

阶段 1（IDS） 在分析机上以被动模式运行 Snort，并加载五条自定义规则——实时观察告警，确认漏洞利用仍会照常进行。

阶段 2（IPS） 将 Snort 与 iptables 执行层配合，使用精准的丢弃规则——确认攻击被阻断，同时 ICMP ping 和合法 FTP 登录仍然可用。

部署前准备

1. 在 VMware 中为分析机配置三块网卡（两块仅主机模式，一块 NAT/桥接）。
2. 启用 IP 转发并添加 MASQUERADE 和 FORWARD 规则，使分析机能够在子网间路由并访问 WAN——参见 scripts/router_config.sh。
3. 在安装 Snort 之前，使用 scripts/ping_check.sh 验证各虚拟机之间的端到端连通性。

Snort 配置

Snort 通过 Kali 包管理器安装（sudo apt install snort -y），并在 /etc/snort/snort.conf 中配置：

HOME_NET = "10.10.10.0/24,192.168.50.0/24"
EXTERNAL_NET = "any"

ips = {
    enable_builtin_rules = true,
    include = "/etc/snort/rules/local.rules",
    variables = default_variables
}

alert_fast = { file = true, packet = false }

HOME_NET 覆盖两个内部子网，使 Snort 将分析机上所有子网间流量都视为值得检查的对象。alert_fast 生成紧凑的单行告警（逐包记录会产生过大的数据量）。

配置验证：

sudo snort -T -c /etc/snort/snort.conf
# Result: 652 rules loaded (5 custom text + 647 built-in), 0 warnings

自定义检测规则

/etc/snort/rules/local.rules 中的五条规则（完整文件见 scripts/local.rules）：

阶段 1 — IDS 模式

Snort 以被动模式运行在两个内部接口上：

sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 \
    -A alert_fast -l /var/log/snort/

# Watch alerts in a second terminal:
sudo tail -f /var/log/snort/alert_fast.txt

启动输出确认 pcap DAQ configured to passive——Snort 能看到每个数据包，但无法丢弃或修改其中任何一个。

IDS 结果

从攻击机执行 scripts/attack_simulator.sh 后：

IDS 检测到了一切，却未能阻断任何东西。 这是阶段 1 的核心教训：一个没有执行能力的 IDS 只是警报系统，而不是锁。等到人工分析师读取告警时，攻击者早已是 root 权限。

另一个观察点：Snort 的内置规则（116:408、116:414）会在 DHCP 广播流量上触发——这并非恶意行为，但在生产部署中需要加入抑制规则，才能保持告警日志的可操作性。

阶段 2 — IPS 模式

IPS 层通过 scripts/ips_setup.sh 部署，该脚本会：

1. 清空现有 iptables 规则
2. 重新启用 IP 转发并重新应用基线路由
3. 应用四条针对特定攻击特征的精准丢弃规则
4. 以守护进程模式（-D）启动 Snort，确保持续记录日志

iptables 规则

IPS 结果

从攻击机重新运行同一攻击脚本：

正常流量不受影响

两项手动检查确认了选择性执行：

• ping -c 4 192.168.50.10 → 发送 4 个数据包，接收 4 个，0% 丢失
• 使用 msfadmin:msfadmin 执行 ftp 192.168.50.10 → 220 (vsFTPd 2.3.4) … 230 Login successful

运行期间 iptables 数据包计数器的定量证明：2051 个数据包被接受，12 个数据包被 FTP connlimit 规则丢弃，808 个 ICMP 数据包被接受——选择性执行的具体数字。

持续 Snort 日志记录

即使在 IPS 模式下，Snort 仍会在 iptables 丢弃后续数据包之前，对到达其被动检测点的数据包持续触发 SID 1000002 / 1000003 告警——这意味着 iptables 负责执行阻断，而 Snort 负责审计日志，两者协同工作。

IDS vs IPS — 并排结果对比

讨论

IDS 模式是否检测到了所有模拟攻击？

是的——SID 1000001 至 1000004 中的每一条都在攻击模拟期间正确触发：

• ICMP ping（1000001） — 每次 echo/reply 均产生双向告警。
• Nmap SYN 扫描（1000003） — 毫秒内产生大量告警，并带有典型的源端口随机化特征。
• FTP 暴力破解（1000002） — 完整记录了 Hydra 的并行连接尝试，并带有精确时间戳。
• vsftpd 后门（1000004） — :) 内容匹配精确捕获了漏洞利用字节序列。

但检测不等于防护。 在每条告警持续触发的同时，vsftpd 漏洞利用打开了 root Meterpreter shell。SOC 分析师若实时盯着 IDS，会看到入侵发生——但攻击者在几秒内就已获得 root 权限，仅靠告警远远不够。这正是 IPS 存在的运维层面的核心原因。

IPS 在阻断攻击的同时不破坏正常流量，效果如何？

该实现实现了完整的攻击缓解，同时可观察的正常流量影响为零。效果来自精准的规则设计——每条 iptables 规则针对一种行为特征，而非宽泛的协议：

• SYN 速率限制 破坏端口扫描的洪泛模式，但不影响正常握手。
• 按来源的 connlimit 阻断暴力破解工具的并行性，但不破坏单会话 FTP。
• STRING 匹配 丢弃确切的漏洞利用载荷，但不过滤合法的 FTP 登录流量。

一个已承认的局限：ICMP 被完全放行，这意味着攻击者仍然可以通过 ping 确认 Metasploitable 是否在线。在安全要求更高的环境中，这应该被限速或限制为仅允许可信来源。在本实验中，ICMP 是主要的连通性验证机制，因此保持开放。

专用 Snort 机器 vs. pfSense/OPNsense 插件

本实验使用专用 Snort 机器。与在 pfSense 或 OPNsense 等防火墙设备中以插件方式运行 Snort 相比：

专用方案的优点：

• 性能隔离 — 全部 CPU 和内存专用于数据包检测；不会与路由、DHCP、VPN、DNS 争抢资源。
• 位置灵活 — IDS/IPS 可以内联部署、部署在 SPAN/镜像端口上，或部署在内部网段边界，以监控永远不会到达边界防火墙的东西向流量。
• 完全配置控制 — 每个预处理器、DAQ 设置、输出插件和规则更新计划都可以通过 CLI 配置。pfSense 仅通过 GUI 暴露其中一部分。
• 高韧性 — IDS/IPS 机器可以独立于路由器选择 fail-open 或 fail-closed。在 pfSense 中，Snort 崩溃会同时导致路由和检测失效。

权衡取舍：

• 学习曲线更陡 — 需要熟练使用 CLI 并直接管理规则集。
• 维护开销更大 — 规则更新、版本升级、日志轮转都需要手动完成。

对于需要性能、位置灵活性和定制能力的企业环境，专用 Snort 是正确的选择。pfSense/OPNsense 插件方案则更适合以易用性为优先的中小企业或家庭实验室环境。

架构说明

阶段 2 在技术上属于被动 Snort + iptables 执行，而非 Snort 真正运行在 inline 模式——Snort 本身只负责记录日志（pcap DAQ configured to passive），而由 iptables 根据速率限制、字符串匹配和连接计数执行丢包。

这是一种合法且常见的部署模式（许多现实世界中的 Linux 系 IDS/IPS 架构正是如此运作）。一个自然的后续改进是将阶段 2 迁移到真正的 inline 配置，使用 snort --daq nfq（或 inline 模式下的 afpacket），并配合 Snort 的 reject / drop 规则动作，让 Snort 本身基于完整的特征匹配执行丢包，而不是交给 iptables。

仓库结构

snort-ids-ips-lab/
├── README.md                       ← this file
├── report/
│   ├── Snort-IDS-IPS-Report.pdf    ← full lab report
│   └── Snort-IDS-IPS-Report.docx   ← editable source
├── scripts/
│   ├── router_config.sh            ← IP forwarding + iptables routing
│   ├── ping_check.sh               ← connectivity verification
│   ├── attack_simulator.sh         ← 4-vector attack chain
│   ├── ips_setup.sh                ← IPS iptables rules + Snort daemon
│   └── local.rules                 ← 5 custom Snort rules (SID 1000001-1000005)
├── screenshots/                    ← report figures
├── .gitignore
└── LICENSE

复现实验

⚠️ 仅供实验使用。 这些脚本会对一个故意存在漏洞的目标运行真实漏洞利用和暴力破解工具。请勿对任何你不拥有、且未获得明确书面授权进行测试的系统运行这些脚本。

1. 按照上述拓扑在 VMware 中创建三台虚拟机（VMnet9 和 VMnet10 设为仅主机模式）。
2. 在分析机上：运行 scripts/router_config.sh，然后运行 scripts/ping_check.sh 确认全面连通。
3. 在分析机上安装 Snort 3：
   root@kitploit:~

   sudo apt update && sudo apt install snort -y
   

4. 将 scripts/local.rules 放到 /etc/snort/rules/local.rules，并在 /etc/snort/snort.conf 中设置 HOME_NET = "10.10.10.0/24,192.168.50.0/24"。
5. 验证：sudo snort -T -c /etc/snort/snort.conf — 预期加载 652 条规则，0 警告。
6. 阶段 1 — IDS：
   root@kitploit:~

   sudo snort -c /etc/snort/snort.conf -i eth1 -i eth2 -A alert_fast -l /var/log/snort/
   # In another terminal:
   sudo tail -f /var/log/snort/alert_fast.txt
   

   在攻击机上：sudo ./scripts/attack_simulator.sh — 观察告警触发并获取 Meterpreter shell。
7. 阶段 2 — IPS： 在分析机上运行 ，然后在攻击机上重新运行攻击链。确认阻断后，手动测试：

道德免责声明

本仓库记录的所有活动均仅在自包含的 VMware 虚拟实验室环境中进行，用于有监督的学术学习目的。未以任何方式针对、扫描或影响任何外部、生产或真实世界的系统。Metasploitable 2 是一台故意存在漏洞的虚拟机，专门为安全培训而设计。

不得利用本材料对任何真实系统复现这些活动，除非获得系统所有者的明确书面授权。 未经授权的端口扫描、口令攻击或利用网络服务，在大多数司法管辖区均属违法行为。

许可证

MIT — 参见 LICENSE。实验报告本身仅用于教学参考。