20253909 2025-2026-2 《网络攻防实践》第5次作业
本文记录了网络攻防课程第五次作业的完整实验过程，涵盖 Linux iptables 防火墙配置与验证、Snort 入侵检测系统离线分析、蜜网网关（Honeywall）防火墙与 IDS/IPS 规则深度分析三项实验。
目录
- 一、实践内容
- 二、实践过程
- 第一部分：Linux iptables 防火墙配置
- 第二部分：Snort 入侵检测实践
- 第三部分：蜜网网关防火墙与 IDS/IPS 规则分析
- 三、学习中遇到的问题及解决
- 四、实践总结
- 参考资料
一、实践内容
这次实验在课程的蜜网靶场虚拟环境里做，主要围绕防火墙、入侵检测系统和蜜网网关这三个东西展开。
任务一（防火墙配置）：在 Kali Linux（192.168.200.3）上用 iptables 配防火墙，要求实现两个功能：① 过滤 ICMP 数据包，让主机不响应 Ping；② 只允许 SEEDUbuntu9（192.168.200.5）访问 HTTP 服务（80 端口），把 WinXP 攻击机（192.168.200.4）挡在外面。
任务二（Snort 入侵检测）：用 Snort 3 对给定的 pcap 文件做离线入侵检测，配好输出模块、写自定义规则，拿到报警日志，然后分析检测出来的攻击类型。
任务三（蜜网网关分析）：到 Honeywall 蜜网网关上去翻它的防火墙脚本和 Snort 配置，搞清楚它是怎么用防火墙和 IDS/IPS 来捕获攻击数据、同时又控制蜜罐不往外攻击的。
实验网络拓扑如下：
图1：实验网络拓扑
| 主机角色 | 主机名 | IP 地址 | MAC 地址 | 操作系统 |
|---|---|---|---|---|
| 防火墙/检测主机 | Kali Linux | 192.168.200.3 | 00:0c:29:83:85:26 | Kali Linux Rolling |
| 白名单主机 | SEEDUbuntu9 | 192.168.200.5 | 00:0c:29:17:a4:60 | Ubuntu 9.04 |
| 黑名单主机 | WinXP 攻击机 | 192.168.200.4 | — | Windows XP SP3 |
| 蜜罐靶机 | Metasploitable | 192.168.200.130 | 00:0c:29:0a:21:ca | Ubuntu 8.04 |
| 蜜罐靶机 | Win2kServer | 192.168.200.131 | — | Windows 2000 |
| 蜜网网关 | Honeywall | 192.168.200.8 | — | roo-1.4 |
| 虚拟网关 | VMware Gateway | 192.168.200.1 | 00:50:56:fe:52:aa | — |
二、实践过程
第一部分：Linux iptables 防火墙配置
技术原理
iptables 是 Linux 内核 Netfilter 框架的用户态配置工具。它在内核网络协议栈的关键位置设"钩子"，对流经的数据包做规则匹配和动作执行，能实现包过滤、NAT 和连接状态追踪。
iptables 的结构是 表（Table）→ 链（Chain）→ 规则（Rule） 三层。本实验用的是 filter 表（默认表），里面有三条内置链：
INPUT 链：处理发给本机的入站数据包——这次实验的重点
FORWARD 链：处理经本机转发的数据包
OUTPUT 链：处理本机往外发的数据包
iptables 的规则匹配有个很重要的特性：严格按顺序来。数据包从第一条规则开始逐条比对，一旦匹配上就立刻执行动作（ACCEPT / DROP / REJECT），不再往下看了。所以白名单必须写在黑名单前面，否则白名单永远不会生效。
这次实验的防火墙策略设计如下：
规则 1（ICMP 屏蔽）：
-p icmp --icmp-type echo-request -j DROP
→ 丢弃所有 Ping 请求，让主机对外"隐形"规则 2（HTTP 白名单）：
-s 192.168.200.5 -p tcp --dport 80 -j ACCEPT
→ 只放行 SEEDUbuntu9 的 HTTP 请求规则 3（HTTP 黑名单）：
-p tcp --dport 80 -j DROP
→ 其他所有机器的 HTTP 请求一律丢弃
实验操作
步骤 1：查看初始 iptables 状态
先切到 root，看一下当前防火墙规则。可以看到三条链全是空的，默认策略都是 ACCEPT，也就是说什么都不拦，完全放行状态。
图2：iptables -L 初始状态，三条链均为空
步骤 2：确认 Kali 网络配置
跑一下 ifconfig，确认 eth0 的 IP 是 192.168.200.3，MAC 是 00:0c:29:83:85:26，跟拓扑表对得上。
图3：Kali eth0 接口信息确认
步骤 3：在 Kali 上启动 HTTP 服务
用 Python 自带的模块快速起一个 HTTP 服务，当防火墙测试的靶子：
sudo python3 -m http.server 80
启动之后在 Kali 本机浏览器访问 http://127.0.0.1 验证一下，能看到 /home/ljt27 的文件列表就说明服务没问题。
图4：左侧终端启动 HTTP 服务，右侧浏览器验证正常
步骤 4：验证防火墙配置前的连通性
在加规则之前先确认一下各台机器到 Kali 的连通性，作为对照基准。
WinXP 攻击机 ping Kali，4 个包全通，零丢包：
图5：规则配置前 WinXP ping Kali 全部成功
SEEDUbuntu9 ping Kali，同样正常：
图6：规则配置前 SEEDUbuntu9 ping Kali 正常
SEEDUbuntu9 用 Firefox 访问 http://192.168.200.3/，页面正常加载，能看到目录列表：
图7：规则配置前 SEEDUbuntu9 HTTP 访问正常
步骤 5：配置 iptables 防火墙规则
接下来开始加规则。先清空旧规则确保干净，再按设计好的顺序依次添加：
# 清空
iptables -F
iptables -X
iptables -Z# 规则 1：禁 Ping
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP# 规则 2：白名单，只许 192.168.200.5 访问 80 端口
iptables -A INPUT -s 192.168.200.5 -p tcp --dport 80 -j ACCEPT# 规则 3：黑名单，其他所有人访问 80 端口一律 DROP
iptables -A INPUT -p tcp --dport 80 -j DROP
图8：依次执行清空和添加规则的命令
加完之后用 iptables -L -n -v --line-numbers 看看实际效果。这个命令比普通的 iptables -L 多了几个有用的信息：-n 不做 DNS 反解（更快）、-v 显示 pkts/bytes 命中计数、--line-numbers 显示规则编号。从输出里可以确认三条规则的顺序没错，而且 pkts 列已经有数字了，说明规则确实在工作。
图9：规则列表及命中计数
具体来说，规则 1 已经拦了 78 个 ICMP 包，规则 2 放行了 11 个包（1317 字节），这些数字就是各台机器测试时产生的流量。
| 规则编号 | 协议 | 源地址 | 目的端口 | 动作 | 命中包数 | 用途 |
|---|---|---|---|---|---|---|
| 1 | icmp | 0.0.0.0/0 | — | DROP | 78 pkts | 禁 Ping |
| 2 | tcp | 192.168.200.5 | 80 | ACCEPT | 11 pkts | HTTP 白名单 |
| 3 | tcp | 0.0.0.0/0 | 80 | DROP | — | HTTP 黑名单 |
步骤 6：验证 ICMP 过滤效果
规则加好之后回到 SEEDUbuntu9 再 ping 一次 Kali。可以看到只有发出请求的提示，完全没有回复，说明 ICMP 屏蔽生效了。
图10：规则生效后 SEEDUbuntu9 ping 无回复
WinXP 那边做了一个前后对比——上面是配置前 4 个包全通，下面是配置后 4 个包全超时（100% loss），效果很直观。
图11：WinXP ping 规则前后对比
步骤 7：验证 HTTP 访问控制效果
白名单验证：SEEDUbuntu9 刷新 http://192.168.200.3/ ，页面照常加载，说明白名单规则正确放行了它的请求。
图12：规则生效后 SEEDUbuntu9 HTTP 访问仍然正常
黑名单验证：WinXP 访问同一个地址，直接显示"连接超时"。因为用的是 DROP 不是 REJECT，WinXP 那边的 TCP 栈会一直傻等 SYN-ACK 直到超时，所以它只能看到"服务器响应时间过长"。
图13：规则生效后 WinXP HTTP 连接超时
汇总一下配置前后的变化：
| 测试主机 | IP 地址 | Ping（前→后） | HTTP（前→后） | 符合预期 |
|---|---|---|---|---|
| SEEDUbuntu9 | 192.168.200.5 | ✅→❌ | ✅→✅ | ✅ |
| WinXP | 192.168.200.4 | ✅→❌ | ✅→❌ | ✅ |
步骤 8：删除规则验证可逆性
最后试一下动态删除规则。把 ICMP 那条删掉：
iptables -D INPUT -p icmp --icmp-type echo-request -j DROP
图14：删除 ICMP DROP 规则
删完之后 WinXP 立刻就能 ping 通了，不需要重启任何服务，iptables 的规则变更是即时生效的。
图15：删除规则后 WinXP ping 立即恢复
配置要点
这里提一下 DROP 和 REJECT 的区别，因为这个选择其实挺有讲究的：
| 动作 | 行为 | 攻击者看到什么 | 适合场景 |
|---|---|---|---|
| DROP | 直接丢包，不回应 | 连接超时，不确定主机是否存在 | 对外服务，隐藏存在感 |
| REJECT | 丢包 + 回一个 RST 或 ICMP 错误 | 立刻收到"连接被拒绝" | 内网，给用户友好提示 |
这次实验用 DROP，WinXP 的扫描每个端口都得等超时（30~60秒），扫描效率极低；如果用 REJECT 的话对方瞬间就知道结果了，扫描速度快很多。所以对外一般都用 DROP。
第一部分小结
| 步骤 | 操作 | 结果 |
|---|---|---|
| 初始状态 | iptables -L |
三条链为空，全放行 |
| 启动 HTTP | python3 -m http.server 80 |
80 端口服务正常 |
| 配置前测试 | WinXP & SEED ping + HTTP | 均可访问 |
| 禁 Ping | iptables -A INPUT -p icmp --icmp-type echo-request -j DROP |
两台机器 ping 均超时 |
| HTTP 白名单 | iptables -A INPUT -s 192.168.200.5 -p tcp --dport 80 -j ACCEPT |
SEED HTTP 正常 |
| HTTP 黑名单 | iptables -A INPUT -p tcp --dport 80 -j DROP |
WinXP HTTP 超时 |
| 计数验证 | iptables -L -n -v --line-numbers |
pkts 列确认规则命中 |
| 删除验证 | iptables -D INPUT -p icmp ... |
删除后 ping 立即恢复 |
第二部分：Snort 入侵检测实践
技术原理
Snort 是最常用的开源入侵检测系统，能对网络流量做实时或离线的深度分析。它有三种工作模式：嗅探（只看不存）、包记录（存到磁盘）、入侵检测（对照规则库做匹配产生告警）。这次实验用的是第三种，通过 -r 参数读取之前捕获的 pcap 文件做离线回放。
这次用的是 Snort 3（版本 3.12.1.0），配置文件是 Lua 格式的 snort.lua。pcap 文件来自第四次作业，里面有 ARP 欺骗、SYN Flood、TCP RST 攻击等流量，一共 135,580 个包，TCP 占了 99.95%。
Snort 规则的基本格式是：
alert tcp any any -> any any (msg:"TCP SYN Packet Detected"; flags:S; sid:1000001; rev:1;)
意思是：检测到只有 SYN 标志位的 TCP 包时产生告警。sid:1000001 是自定义规则的编号。
实验操作
步骤 1：配置 snort.lua 的输出模块
打开 Snort 的配置文件：
图16：sudo vim /etc/snort/snort.lua
找到第 7 节 configure outputs 那一块，默认 alert_fast 和 alert_full 都是注释掉的：
图17：输出模块默认被注释禁用
把注释去掉，加上 file=true 让告警写到文件里：
图18：启用 alert_fast 和 alert_full 输出
步骤 2：写自定义检测规则
因为 pcap 里主要是 SYN Flood 产生的 TCP SYN 包，所以写一条针对 SYN 的规则。这里用 Python 写入文件是因为直接在终端里打 -> 会被 zsh 的字体连字功能渲染成箭头，虽然实际字节是对的但看着容易误判：
sudo python3 -c "
with open('/etc/snort/rules/local.rules', 'w') as f:f.write('alert tcp any any -> any any (msg:\"TCP SYN Packet Detected\"; flags:S; sid:1000001; rev:1;)\n')
"
写完之后用 xxd 检查一下文件的十六进制内容，确认 -> 这两个字符存的确实是 ASCII 的 2d 3e（减号+大于号），不是 Unicode 的箭头 →（那个是 e2 86 92）：
图19：xxd 确认规则文件字节正确（2d 3e）
步骤 3：配置 ips 模块加载规则
先看一下 RULE_PATH 变量指向哪里。结果发现是个相对路径 '../rules'，这就意味着从不同目录运行 Snort 可能找不到规则文件。
图20：RULE_PATH 是相对路径
为了保险，在 snort.lua 的 ips 模块里直接写绝对路径。顺便把 enable_builtin_rules 也打开，这样 Snort 内置的一些异常检测规则也会生效：
图21：ips 模块使用绝对路径引入规则
改完之后跑一下 --warn-all 验证配置有没有语法错误，输出"successfully validated"就说明没问题：
图22：Snort 配置验证通过
步骤 4：运行 Snort 做离线检测
sudo snort -r /etc/snort/listen.pcap -c /etc/snort/snort.lua -A full -l /var/log/snort
图23：执行 Snort 离线检测命令
参数说明：-r 指定 pcap 文件，-c 指定配置文件，-A full 用完整格式输出告警，-l 指定日志目录。
步骤 5：查看加载过程
Snort 启动后会打出一长串加载日志，能看到它加载了哪些模块：
图24：Snort 3.12.1.0 加载各检测模块
规则加载统计显示一共 219 条规则全部启用：
图25：219 条规则加载完成
搜索引擎加载了 438 个特征模式，然后进入 pcap 处理阶段：
图26：进入 pcap 处理阶段
步骤 6：分析统计结果
处理完之后 Snort 输出了详细的统计信息，这部分信息量很大，一块一块看。
首先是 Packet Statistics，总共分析了 135,580 个包，TCP 占了 99.95%。arp_spoof 模块检测到 20 个 ARP 欺骗包，back_orifice 模块发现了 3 个可疑包：
图27：数据包统计与模块检测概览
Module Statistics 更细，port_scan 跟踪了 135,515 个包；http_inspect 看到了 6 个 HTTP 流；dns 处理了 3 次 DNS 请求：
图28：各模块检测详情
最有价值的是 stream_tcp 的统计。67,657 个 SYN 请求只对应了 83 个 SYN-ACK，握手完成率不到 0.13%——这就是 SYN Flood 的典型特征。而且 67,549 个 RST 里只有 46 个是合法的，剩下 99.9% 都是异常的，对应 TCP RST 攻击注入的伪造 RST：
图29：stream_tcp 统计揭示 SYN Flood 和 RST 攻击特征
最后的 Summary 显示总共只花了 0.3 秒就处理完 13.5 万个包，速率 45 万 pkt/s：
图30：处理完成，0.3 秒/45 万 pkt/s
步骤 7：查看告警日志
用 root 权限查看 alert_full.txt 的前 50 行。可以看到开头有两条内置规则 [116:6:1] 检测到的 IPv4 长度异常，后面就是大量自定义规则 [1:1000001:1] 触发的 "TCP SYN Packet Detected" 告警。
每条告警都包含完整的五元组、TCP 头部信息——源 IP 172.31.4.178:57738、目标端口各不相同（3306、139、995、23、80 等）、TTL 在 45~57 之间随机变化、SYN 标志位单独置位（******S*）、序列号固定为 0xFAB52A31。这些特征跟上次作业里 hping3 --rand-source 产生的 SYN Flood 完全对得上。
图31：alert_full.txt 告警内容（一）
图32：alert_full.txt 告警内容（二）
步骤 8：统计告警数量和日志大小
用 wc 和 grep 数一下：alert_full.txt 共 473,755 行，其中 "TCP SYN Packet Detected" 出现了 67,655 次，跟 stream_tcp 统计的 67,657 个 SYN 会话基本一致（差 2 条是 IPv4 异常告警）。文件大小 18 MB。
图33：67,655 条 SYN 告警
图34：alert_full.txt 大小 18 MB
检测结果汇总
| 攻击类型 | 检测来源 | 数据 | 特征 |
|---|---|---|---|
| SYN Flood | 自定义规则 + stream_tcp | 67,655 条告警；syns 67,657 / syn_acks 83 | 随机源 IP、随机端口、固定 Seq |
| TCP RST 攻击 | stream_tcp | rsts 67,549（异常）/ 46（正常） | 99.9% 异常 RST |
| ARP 欺骗 | arp_spoof | 20 个包 | arpspoof 伪造 ARP Reply |
| 端口扫描 | port_scan | 135,515 包，6 追踪器 | SYN Flood 随机源 IP 触发 |
| 远控木马 | back_orifice | 3 个包 | Back Orifice 协议特征 |
| Telnet 会话 | telnet | 1 个会话 | 会话劫持实验流量 |
拿一条典型告警来逐字段看看：
[**] [1:1000001:1] "TCP SYN Packet Detected" [**]
[Priority: 0]
08/08-17:51:11.574964 172.31.4.178:57738 → 172.31.4.188:3306
TCP TTL:57 TOS:0×0 ID:16729 IpLen:20 DgmLen:44
******S* Seq: 0×FAB52A31 Ack: 0×0 Win: 0×800 TcpLen: 24
| 字段 | 值 | 说明 |
|---|---|---|
[1:1000001:1] |
GID:SID:REV | 自定义规则，SID 1000001 |
172.31.4.178:57738 |
源 | hping3 伪造的源地址 |
172.31.4.188:3306 |
目的 | 目标 MySQL 端口 |
TTL:57 |
生存时间 | 随机化，增加溯源难度 |
******S* |
TCP Flags | 只有 SYN，典型 Flood 特征 |
Seq: 0×FAB52A31 |
序列号 | 所有伪造 SYN 用同一个 Seq |
Win: 0×800 |
窗口 | 2048，hping3 默认值 |
第二部分小结
| 步骤 | 操作 | 结果 |
|---|---|---|
| 配置输出 | 启用 alert_fast + alert_full | file=true |
| 写规则 | TCP SYN 检测规则 | xxd 验证字节正确 |
| 配 ips | 绝对路径 + enable_builtin_rules | --warn-all 通过 |
| 运行检测 | snort -r pcap -A full | 0.3 秒处理 135,580 个包 |
| 统计分析 | 各模块 Statistics | arp_spoof:20, rsts:67,549 |
| 查看告警 | cat alert_full.txt | 473,755 行, 67,655 条 SYN 告警, 18 MB |
第三部分：蜜网网关防火墙与 IDS/IPS 规则分析
蜜网网关概述
Honeywall 是蜜网系统的核心，本实验环境用的是 roo-1.4 版本（内核 2.6.18）。它以二层透明网桥的方式部署在蜜罐和外网之间，攻击者完全看不到它的存在。
Honeywall 干两件事：一是用 iptables 做流量控制和数据捕获（防火墙子系统），二是用 Snort 做入侵检测和拦截（IDS/IPS 子系统）。它的设计哲学是"数据控制优先于数据捕获"——记录攻击者行为很重要，但首先得保证蜜罐不被攻击者拿来打别人。
防火墙配置分析
服务启动状态
先登录 Honeywall 看看各服务的开机启动情况。iptables 和 hw-snort_inline 都是 on，snortd 全部 off——也就是说 IPS 模式（Snort-Inline）是主力，传统的 IDS 模式没开。
图35：服务启动状态，hw-snort_inline 为 on，snortd 为 off
防火墙脚本有 859 行，算是个大脚本了：
图36：rc.firewall 共 859 行
脚本结构
图37：打开 rc.firewall 脚本
脚本头部是 Honeynet Project 2005 年的版权声明，GPL v2 协议：
图38：rc.firewall 脚本头部
默认策略
default_policy() 函数把三条链的默认策略全设成了 DROP。这跟我在第一部分给 Kali 配防火墙的思路正好相反——Kali 那个是默认 ACCEPT 然后手动加 DROP 规则，Honeywall 这个是默认 DROP 然后手动加 ACCEPT 规则（白名单模式）。显然后者更安全，因为你不可能遗漏要封堵的东西。
图39：默认策略全部 DROP
模块加载和自定义链
load_modules() 函数先处理旧版 ipchains 的兼容问题，然后加载两个关键内核模块：ipt_LOG（数据捕获用）和 ipt_QUEUE（IPS 内联检测用）。
图40：加载 LOG 和 QUEUE 内核模块
create_chains() 创建了三条自定义链：BlackList（封锁恶意 IP）、WhiteList（放行受信 IP）、FenceList（围栏，防止蜜罐往外连不该连的地址）。
图41：创建 BlackList / WhiteList / FenceList 三条自定义链
管理接口策略
回环接口全放行，管理接口只开 SSH 和 HTTPS，跟蜜罐流量物理隔离。
图42：回环和管理接口策略
实际运行的 iptables 规则
执行 iptables -L -n 看实际生效的规则。INPUT 链只放了回环、管理 SSH/HTTPS 和已建立连接的回包。FORWARD 链的入站部分很有意思——对从 eth0 进来的新 TCP/UDP/ICMP 连接，先 LOG（加上 "INBOUND TCP:" 之类的前缀）再 ACCEPT。先记录再放行，这就是蜜网抓数据的核心手法。
图43：INPUT 和 FORWARD 链规则
FORWARD 链的出站部分是这次分析里最精彩的地方——对蜜罐 192.168.200.130 和 131 的出站流量做了分协议限速。TCP 和 UDP 每小时最多 20 个新连接，ICMP 每小时 50 个，超了就 LOG + DROP。这就是蜜网的"数据控制"：就算蜜罐被黑了，攻击者也没法用它来大规模扫描或者打 DDoS。
图44：出站连接限速规则（TCP/UDP 20/h，ICMP 50/h）
OUTPUT 链同样是白名单模式，只允许网关自身往外发 SSH、SMTP、HTTP、HTTPS、DNS、NTP：
图45：OUTPUT 链白名单出站规则
最后是几条自定义的 Handler 链，结构都一样：LOG → QUEUE → ACCEPT。先记日志，再送进 Snort-Inline 检测，最后放行。QUEUE 是整个 IPS 的核心——iptables 把数据包交给用户态的 Snort，Snort 分析完了再告诉内核是放行还是丢弃。
图46：tcpHandler / icmpHandler / otherHandler 三阶段流水线
| 链 | 默认策略 | 核心规则 |
|---|---|---|
| INPUT | DROP | 只许回环、管理 SSH/HTTPS、已建立连接 |
| FORWARD 入站 | DROP | 先 LOG（前缀标记）再 ACCEPT |
| FORWARD 出站 | DROP | 分协议限速，超限 LOG+DROP |
| OUTPUT | DROP | 白名单：SSH/HTTP/HTTPS/DNS/NTP |
| Handler 链 | — | LOG → QUEUE → ACCEPT |
IDS/IPS 配置分析
snortd（传统 IDS，本环境未启用）
图47：打开 snortd 启动脚本
脚本说明里提到 Snort 能检测超过 1100 种漏洞、端口扫描和后门。它读取 /etc/sysconfig/snort 里的 ALERTMODE 配置来决定告警输出模式。不过在当前环境里这个服务没开，实际干活的是下面的 hw-snort_inline。
图48：snortd 脚本内容
hw-snort_inline（IPS 模式，主力引擎）
图49：打开 hw-snort_inline 启动脚本
核心启动命令是 snort -D -c -Q -l -t，其中 -Q 是关键——它让 Snort 工作在 QUEUE 模式下，iptables 把数据包送进来，Snort 检测完再决定放行或丢弃。-D 是后台运行，-t 是 chroot 隔离（安全加固）。
图50：启动命令和 PID 管理逻辑
蜜网配置和规则集
honeywall.conf 里定义了蜜罐 IP 是 192.168.200.130 和 131，跟拓扑表一致。HwSCALE=hour 说明限速单位是"每小时"，对应前面 iptables 里看到的 avg 20/hour。
图51：蜜罐 IP 定义和基本配置
图52：HwSCALE=hour 限速时间单位
Snort 规则目录里有很多规则文件，涵盖了 attack-responses、backdoor、ddos、exploit、ftp、icmp 等各种类型：
图53：蜜网 Snort 规则集文件列表
工作机制总结
把上面分析的内容串起来，Honeywall 的工作流程大概是这样的：
外部攻击者 → [eth0 入站] → FORWARD 链：① LOG "INBOUND TCP/UDP/ICMP:" （记录入站流量）② ACCEPT （透明转发给蜜罐）蜜罐 → [eth1 出站] → FORWARD 链：③ 限速检查：TCP 20/h, UDP 20/h, ICMP 50/h├─ 没超 → Handler 链：LOG → QUEUE(Snort检测) → ACCEPT/DROP└─ 超了 → LOG "Drop > 20 attempts" → DROP
| 目标 | 手段 | 要点 |
|---|---|---|
| 数据捕获 | FORWARD 链 LOG | 入站 INBOUND，出站 OUTBOUND，分协议打前缀 |
| 入侵检测 | Snort-Inline QUEUE 模式 | 数据包送进 Snort，检测后决定放行或丢弃 |
| 出站限速 | rate limit 规则 | TCP/UDP 20/h，ICMP 50/h |
| 黑白名单 | 自定义链 | BlackList 封 IP，WhiteList 放 IP |
| 管理隔离 | management_policy() | SSH/HTTPS 独立管理通道 |
| 透明部署 | 二层网桥 | 攻击者看不到网关存在 |
第三部分小结
| 分析对象 | 路径 | 发现 |
|---|---|---|
| 防火墙脚本 | /etc/init.d/rc.firewall | 859 行，含 default_policy / create_chains / load_modules 等 |
| 默认策略 | default_policy() | 三条链全部 DROP |
| 自定义链 | create_chains() | BlackList / WhiteList / FenceList |
| Handler 链 | tcpHandler 等 | LOG → QUEUE → ACCEPT 三阶段 |
| 出站限速 | FORWARD limit 规则 | TCP/UDP 20/h，ICMP 50/h |
| IDS | snortd | 未启用 |
| IPS | hw-snort_inline | -Q QUEUE 模式，已启用 |
| 蜜罐 IP | honeywall.conf | 192.168.200.130 和 131 |
| 规则集 | /etc/snort/rules/ | 20+ 规则文件 |
三、学习中遇到的问题及解决
- 问题 1：Snort 跑完之后
alert_full.txt是空的，一条告警都没有。
图54：alert_full.txt 为空
- 问题 1 解决方案：排查了半天，发现是三个问题叠在一起导致的。
第一，最开始写的是 ICMP 检测规则，但 pcap 里根本就没有 ICMP 包（TCP 占了 99.95%），规则自然不会触发。改成 TCP SYN 检测规则之后就对了。
第二，snort_defaults.lua 里的 RULE_PATH 是相对路径 '../rules'，换个目录运行 Snort 就找不到规则文件了。改成绝对路径 /etc/snort/rules/local.rules 解决。
图55：RULE_PATH 是相对路径，容易出问题
第三，排查过程中一直怀疑 -> 被输成了 Unicode 箭头 →，因为终端上看着确实像箭头。后来用 xxd 查了一下实际存的字节，2d 3e 没错，是正确的 ASCII。原来是 Kali 终端字体的连字渲染（Ligature）把 -> 画成了箭头的样子，实际内容完全正确。
图56：xxd 验证文件字节为 2d 3e（正确的 ASCII ->）
三个问题都修完之后重跑 Snort，alert_full.txt 一下子就出来了 47 万行、67,655 条告警：
图57：修复后告警正常产生
- 问题 2：
snort --warn-all验证配置时输出 "with 2 warnings"，不确定有没有影响。
图58：配置验证有 2 个 warning
- 问题 2 解决方案：这两个 warning 是非关键性的提示，一般是未使用的默认变量之类的问题，不影响规则加载和检测。关键看前面那句 "Snort successfully validated the configuration"，出现了就说明配置没问题。
-
问题 3：Honeywall 上
chkconfig --list | grep snort显示 snortd 全是 off，以为蜜网的 IDS 功能挂了。 -
问题 3 解决方案：后来发现 Honeywall 上有两种 Snort 模式。snortd 是传统 IDS（被动监听），hw-snort_inline 是 IPS（内联检测+主动拦截）。当前环境跑的是 hw-snort_inline（chkconfig on），比传统 IDS 还强——不光能检测还能直接拦截。snortd off 是正常的。
四、实践总结
做完这次实验，我觉得收获最大的不是某个具体工具的用法，而是对网络安全防护"层次感"的理解。
iptables 那部分让我印象最深的是规则顺序这件事。之前觉得配防火墙就是加规则嘛，实际操作才发现规则列表其实是个有序优先级队列——白名单写在黑名单后面就是废纸一张。还有 pkts/bytes 计数器那个功能挺好用的，78 个 ICMP 包被拦、11 个 HTTP 包被放行，数字摆在那里，一目了然。DROP 和 REJECT 的选择也让我想了挺久，DROP 让对方干等超时，扫描一个端口就得等半分钟，REJECT 的话瞬间就知道结果，扫描效率差很多。
Snort 那部分的排障过程是最折腾但也最有收获的。alert_full.txt 为空这个问题我来来回回查了好几遍——先怀疑配置文件，再怀疑规则语法，最后用 xxd 看字节才确认文件内容没问题，真正的原因是规则类型和 pcap 流量不匹配加上 RULE_PATH 路径错误。这个经历让我记住了一件事：终端上看到的不一定是真的，字体连字能把 -> 画成 →，遇到这种情况就得回到字节层面去验证。最后跑出来 67,655 条 SYN 告警的时候还挺有成就感的，18 MB 的日志文件，0.3 秒就处理完了。
蜜网网关分析是这次实验里最让我觉得设计精妙的部分。FORWARD 链那个 "先 LOG 再 ACCEPT" 的做法很聪明——攻击者的每个包都被记下来了，但攻击者完全不知道，对他来说蜜罐就是个正常的目标。同时出站限速（TCP 20/h，ICMP 50/h）又保证了蜜罐被打下来也没法拿来当跳板。Handler 链的 LOG → QUEUE → ACCEPT 三阶段流水线把数据捕获和入侵检测串到了一起，每个包都要过 Snort 的检查。整个设计就是在"让攻击者尽情表演"和"不让他伤害别人"之间找了个很精确的平衡。
三个实验串起来看，其实就是网络安全里"纵深防御"的思想：iptables 在网络层做粗粒度的包过滤，Snort 在应用层做细粒度的特征匹配，蜜网网关把两者集成在一起，还加上了限速和日志记录。不靠单一机制，而是多层叠加，每一层都有自己守的阵地。
参考资料
- iptables 官方文档（netfilter.org）
- Linux iptables HOWTO
- iptables 手册页
- Snort 官方文档
- Snort 3 用户手册
- Snort 3 规则编写指南
- 蜜网项目（The Honeynet Project）
- Honeywall roo 使用指南
- W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols[M]. Addison-Wesley, 1994.
- 诸葛建伟, 薛静锋. 网络攻防技术与实践[M]. 电子工业出版社.