当前位置：首页 > news >正文

20252817 2025-2026-2 《网络攻防实践》实践五报告

news 2026/4/18 22:46:44

学号 20252817 2025-2026-2 《网络攻防实践》实践五报告

1. 实践内容

本次实践主要包括三部分内容：防火墙配置、Snort 离线入侵检测以及蜜网网关规则分析。和前几次更偏向攻击现象观察的实验相比，这次实验更强调防御与检测，也就是不仅要看到攻击行为，还要理解系统是如何限制流量、记录攻击和控制风险的。

第一部分是在 Linux 平台上使用 iptables 完成两项基本访问控制任务：一是过滤 ICMP 数据包，使目标主机不再响应 Ping；二是只允许指定 IP 地址访问某一网络服务，而其他主机无法访问。第二部分是使用 Snort 对老师提供的 pcap 文件进行离线检测，输出告警日志并对扫描行为进行分析。第三部分是进入 Honeywall 主机，查看其防火墙、Snort 和 snort_inline 相关配置，理解蜜网网关如何同时实现攻击数据捕获与风险控制。

通过这次实践，我对防火墙、IDS 和蜜网网关三者之间的关系有了更清楚的认识。防火墙主要解决“哪些流量可以通过”的问题，Snort 主要解决“哪些流量值得关注”的问题，而蜜网网关则是在这两者基础上进一步实现“既保留攻击过程，又限制对外危害”的目标。

2. 实践过程

2.1 防火墙配置实验

本部分实验在 Metasploitable 主机上使用 iptables 完成。为了让实验现象更清楚，我将 Kali 作为允许访问的 Linux 主机，将 Win2K 作为不被允许访问的测试主机。实验中涉及的主机信息如下表所示，具体地址以虚拟机实际配置为准。

主机	作用	IP 地址
Kali	允许访问主机	`192.168.200.64`
SEED	另一台 Linux 主机	`192.168.200.65`
Metasploitable	目标主机	`192.168.200.130`
Win2K	不允许访问主机	`192.168.200.131`

2.1.1 过滤 ICMP 数据包，使主机不接收 Ping 包

在配置规则之前，我先分别在 Kali 和 Win2K 上测试 Metasploitable 是否可以被正常 Ping 通：

ping 192.168.200.130

Kali测试Ping

测试结果显示，两台主机都能正常收到回显，说明此时目标主机未对 ICMP 探测进行限制。

随后回到 Metasploitable，查看当前规则并加入丢弃 ICMP Echo Request 的规则：

sudo iptables -L -n
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
sudo iptables -L -n

添加ICMP过滤规则

这条规则的作用是直接丢弃进入主机的 Ping 请求报文。配置完成后，我再次在 Kali 和 Win2K 上执行 Ping 测试，发现两边都已经无法收到正常回显，说明目标主机已经不再响应外部的 Ping 请求。

Kali过滤后Ping结果

Win2K过滤后Ping结果

为避免该规则影响后续实验，我在下一项实验开始前清空了当前规则：

sudo iptables -F
sudo iptables -L -n

通过这一实验可以看出，主机仍然在线，但外部主机已经无法通过 Ping 直接探测其响应情况，这体现了防火墙对特定协议类型进行单独控制的能力。

2.1.2 只允许特定 IP 地址访问某一网络服务

这一部分我选择对 HTTP 服务进行控制，即只允许 Kali 访问 Metasploitable 的 80 端口，而 Win2K 不能访问。

在正式添加规则之前，我先测试目标主机的 80 端口是否本来可以访问。在 Kali 和 Win2K 上分别执行：

telnet 192.168.200.130 80

Kali连接80端口

测试结果显示，Kali 可以成功连接目标主机的 80 端口；Win2K 终端进入黑屏等待输入状态，也说明它已经成功建立 TCP 连接。因此，在添加防火墙规则之前，两台主机都能访问目标主机的 HTTP 服务端口。

Win2K连接80端口

随后，我在 Metasploitable 上重新配置 iptables 规则：

sudo iptables -F
sudo iptables -P INPUT DROP
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp -s 192.168.200.64 --dport 80 -j ACCEPT
sudo iptables -L -n

HTTP访问控制规则

这里的思路是先将 INPUT 链默认策略设置为 DROP，也就是默认拒绝所有进入主机的流量，然后只保留本地回环、已建立连接以及来自 192.168.200.64 的 80 端口访问请求。这样比较容易体现白名单控制的效果。

规则生效后，我再次分别在 Kali 和 Win2K 上测试访问目标主机的 80 端口。结果显示，Kali 仍然可以访问，而 Win2K 的访问失败。最后我又使用如下命令查看规则列表：

sudo iptables -L -n --line-numbers

Kali访问80端口成功

Win2K访问80端口失败

HTTP规则列表

从实验结果可以看出，iptables 不仅可以按协议过滤报文，也可以按照源地址和服务端口进行更细致的访问控制。

2.2 Snort 离线入侵检测实验

本部分实验使用 Snort 对老师提供的 pcap 文件进行离线检测。与在线监听不同，离线检测不需要实时抓取网卡流量，而是直接读取已经保存好的 pcap 文件，再根据规则对其中的异常行为进行识别和告警。

首先，我在 Kali 主机上确认 Snort 已经安装，同时确认待检测的 pcap 文件已经放置到合适位置。本次实验中，我将 listen.pcap 放在桌面目录下。

在 Kali 虚拟机上执行：

snort -V
ls /home/kali/Desktop

Snort环境确认

在实验过程中我发现，当前环境使用的是 Snort 3，因此不能继续沿用旧版本 snort.conf 的写法，而应使用 snort.lua 配置文件。开始时虽然能够正常读取 pcap 文件，但默认规则没有直接生成明显的告警日志。结合运行统计信息，可以判断 pcap 中确实存在扫描行为，因此后续增加了一条本地规则，用于识别短时间内大量 TCP SYN 报文的扫描特征。

首先创建本地规则文件：

nano /home/kali/Desktop/local.rules

在规则文件中加入如下内容：

alert tcp any any -> any any (msg:"Possible TCP SYN scan"; flags:S; detection_filter:track by_src,count 20,seconds 60; sid:1000001; rev:1;)

本地规则文件

这条规则的含义是：当某个源地址在 60 秒内向任意目标发送不少于 20 个带有 SYN 标志位的 TCP 报文时，Snort 产生一条告警。该规则适合用于识别典型的 TCP SYN 扫描行为。

为了便于查看检测结果，我先创建日志目录：

sudo mkdir -p /var/log/snort

随后执行离线检测命令，让 Snort 从 pcap 文件中读取网络流量，并加载本地规则文件，同时将快速告警结果写入日志文件：

sudo rm -f /var/log/snort/alert_fast.txt
sudo snort -r /home/kali/Desktop/listen.pcap -c /etc/snort/snort.lua -R /home/kali/Desktop/local.rules -A alert_fast -l /var/log/snort --lua "alert_fast = {file = true}"

Snort离线检测执行过程

Snort 运行结束后，我查看生成的告警日志文件：

ls /var/log/snort
sudo cat /var/log/snort/alert_fast.txt

Snort告警日志输出结果

从日志中可以看到，源主机 172.31.4.178 在较短时间内向目标主机 172.31.4.188 的多个端口发起 TCP SYN 探测，例如 143、993、21、1025、113、443 和 111 等端口。Snort 根据本地规则将其识别为 Possible TCP SYN scan，这说明 pcap 文件中包含较为典型的端口扫描行为。

这一部分实验让我更清楚地认识到，Snort 的作用不是像防火墙一样直接控制访问，而是对网络中的可疑行为进行检测和记录。当默认规则无法直接输出明显告警时，也可以通过补充本地规则的方式提高对特定攻击行为的识别能力。

2.3 蜜网网关防火墙和 IDS/IPS 规则分析

这一部分实验主要是在 Honeywall 主机上查看防火墙和 Snort 相关配置，分析它是怎样完成攻击数据捕获和风险控制的。

首先，我切换到 root 用户后，查看了 Honeywall 上的 iptables 规则，包括 filter、nat 和 mangle 三张表，以及防火墙启动脚本中的关键规则：

su -
iptables -L -n
iptables -t nat -L -n
iptables -t mangle -L -n
grep iptables /etc/init.d/rc.firewall

Honeywall规则查看结果

Honeywall防火墙脚本规则片段

从查看结果可以看出，Honeywall 并不是简单地把流量全部拦截，而是允许一部分攻击流量进入蜜罐，便于系统记录攻击过程。同时，在 rc.firewall 脚本中还能看到 FORWARD、LOG、QUEUE 和 ACCEPT 等规则，说明其不仅记录流量，还会将部分流量送入后续处理链中。

接着，我查看了 Snort 和 snort_inline 的相关配置：

grep snort /etc/init.d/hw-snort_inline
chkconfig --list | grep snort

snort_inline相关配置

Snort相关服务启动状态

从结果可以看出，Honeywall 中既有普通 Snort 相关组件，也有 snort_inline。其中 hw-snort_inline 在多个运行级别下处于启用状态，而 snortd 在当前查看结果中未设置为开机启动。这说明该环境更强调对流量的内联处理能力，也就是在检测的基础上进一步实现对部分流量的控制。

最后，我查看了 Honeywall 的主配置文件：

cat /etc/honeywall.conf

Honeywall主配置文件

从主配置文件可以看出，Honeywall 还会统一管理网络接口、NAT 和系统运行参数。结合前面的规则和配置，我认为 Honeywall 的作用可以概括为两点：一是尽量保留攻击过程，方便后续分析；二是限制蜜罐对外的攻击能力，减少安全风险。也就是说，蜜网网关既要“看见攻击”，又不能“放任攻击”。

3. 学习中遇到的问题及解决

问题1：从网页复制 iptables 命令后，系统提示参数错误。
这个问题出现在 --state 等参数上。后来检查发现，网页中的横线有时会变成长横线，导致命令不能被系统正确识别。
问题1解决方案：
对关键命令尽量手动输入，特别是 --state、--dport 这些参数，避免直接复制网页内容。
问题2：Snort 读取 pcap 文件时一直报错，后来发现环境使用的是 Snort 3。
一开始我按旧教程使用 snort.conf，结果配置语法不兼容，而且默认规则也没有直接生成明显的告警日志。
问题2解决方案：
改用 snort.lua 作为配置文件，并补充一条本地规则 local.rules 来识别 TCP SYN 扫描，同时使用 alert_fast 将告警结果写入日志文件。
问题3：Honeywall 上使用普通用户执行 sudo 失败。
在查看 Honeywall 规则时，系统提示当前用户不在 sudoers 文件中，导致无法直接执行需要权限的命令。
问题3解决方案：
先使用 su - 切换到 root 用户，再执行 iptables、chkconfig 和配置文件查看命令。
问题4：Honeywall 控制台环境不方便复制、翻页和查看长文件。
在 VMware 的字符终端中，使用 vim 查看文件时不容易翻页，也不方便复制粘贴。
问题4解决方案：
后来我尽量使用 grep、cat 等更简单的命令来查看关键内容，只截和实验结论直接相关的部分，减少不必要的操作。

4. 实践总结

通过这次实验，我对防火墙、Snort 和蜜网网关之间的关系有了更具体的认识。防火墙主要负责访问控制，Snort 主要负责检测和记录，而蜜网网关则是在这两者基础上进一步完成攻击数据的捕获和风险控制。

在 iptables 实验中，我体会最深的是规则顺序和默认策略的重要性。很多时候现象不符合预期，并不是命令写错了，而是前面的规则或者默认策略已经影响了结果。Snort 实验让我认识到 IDS 的作用更多是在于发现和记录可疑行为，而不是直接拦截流量。至于 Honeywall 的分析部分，我觉得最有意思的是它并不追求把所有攻击都挡在外面，而是在观察攻击过程和限制风险之间寻找平衡。

总的来说，这次实践让我不只是会照着命令做实验，也开始理解这些规则和配置为什么要这样写。以后再做类似实验时，我会更注意先明确主机角色、流量方向和实验目标，再去写规则和分析日志。