20253918 2025-2026-2 《网络攻防实践》第5次作业

20253918 2025-2026-2 《网络攻防实践》第5次作业

1.实践内容概述

1.1 防火墙配置实践

本次实践首先围绕主机防火墙配置展开，主要使用 iptables 完成两类典型访问控制任务：
一是过滤 ICMP 数据包，使主机不响应 Ping 请求；二是通过设置默认丢弃策略和指定放行规则，实现“只允许特定 IP 地址访问指定网络服务”。
通过这一部分实践，加深了对防火墙基本链、默认策略、规则匹配顺序以及访问控制原理的理解。

1.2 Snort 入侵检测实践

在入侵检测部分，使用 Snort 对给定的离线 pcap 文件进行分析，并结合告警结果识别攻击行为。
实验中成功检测到 TCP 端口扫描、异常 TCP 标志位组合、Nmap XMAS 扫描、异常会话行为等内容，同时完成了告警日志输出配置。
通过这一过程，进一步理解了 IDS 在流量分析、攻击识别、规则启用和日志记录中的实际作用。

1.3 蜜网网关防火墙与 IDS/IPS 规则分析

在蜜网网关分析部分，通过查看 rc.firewall、iptables 规则表、snortd、hw-snort_inline、honeywall.conf 以及相关进程信息，分析了 Honeywall 的防火墙与 IDS/IPS 配置机制。
可以看出，蜜网网关通过防火墙实现流量引导、访问控制和对外限制，通过 Snort 与 Snort_inline 实现攻击检测、日志记录及联动处置，从而满足攻击数据捕获与行为控制的双重需求。

2.实践过程

本次实践需要用到以下设备，此处先列举出来以备后用：

机器名称	IP 地址	子网掩码
Kali	192.168.200.64	255.255.255.128
Metasploitable	192.168.200.134	255.255.255.128
Seed	192.168.200.65	255.255.255.128
Windows XP	192.168.200.66	255.255.255.128

2.1 防火墙配置

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

以配置seed linux主机的防火墙为例，使用iptables -L命令：

在受保护的主机 SEED 上，通过 su 命令切换到 root 权限后，执行了 iptables -L 命令查看当前的防火墙规则。结果显示 INPUT、FORWARD 和 OUTPUT 三条链下均为空白，没有任何过滤规则（target、prot、opt、source、destination 均无具体条目），且默认策略（policy）均为 ACCEPT。

接着在 SEED 主机上，执行了精确的防火墙配置命令 iptables -A INPUT -p icmp --icmp-type echo-request -j DROP。随后再次使用 iptables -L 查看规则。可以清晰地看到 INPUT 链中成功增加了一条规则：目标动作（target）为 DROP，协议（prot）为 icmp，并且在最右侧的详细信息中指定了 icmp echo-request。这表明防火墙规则已经成功生效，SEED 主机现在被配置为：当收到任何发往本机的 ICMP Ping 请求包时，直接静默丢弃（DROP）。

终端仅输出了第一行 PING 192.168.200.65... 的提示信息后，光标就一直停留在那里，没有任何后续的响应输出，由于 SEED 主机防火墙的拦截，Ping 请求发出去后如同泥牛入海，没有收到任何回音，实现了“防 Ping”的初步表象。

使用 Wireshark 网络分析工具对刚才的 Ping 测试过程进行了底层抓包。

• 列表： 可以看到全是源地址 192.168.200.64 (Kali) 发往目标地址 192.168.200.65 (SEED) 的单向 ICMP Echo (ping) request 数据包。
• 详情： 在展开的 ICMP 协议详细信息中，Wireshark 专家系统（Expert Info）明确给出了黄色的警告提示：[No response seen] 以及 No response seen to ICMP request。

它从网络底层协议的角度证明了，Kali 确实不断地把请求包发过去了，但是 SEED 主机在网卡收到包后，被 iptables 直接丢弃了，根本没有生成 Echo reply（应答包）发回来。

牢记上一次的失误，避免影响后续实验，在测试结束后清空当前规则。使用iptables -F清空之前的内容，恢复原状。

2.1.2 只允许特定IP地址访问主机的某一网络服务，而其他的IP地址无法访问

首先在kali和windowXP上面都telnet seed，发现两个都可以成功telnet：

然后再seed机上使用命令iptables -P INPUT DROP，这条命令将防火墙INPUT链的默认策略设置为DROP。这意味着，除非有明确允许的规则，否则所有进入服务器的数据包都将被丢弃。这是实现“其他IP无法访问”的基础。

依次查询两台机器kali和windowXP，发现确实已经无法telnet通seed这个机器了。

此时使用命令iptables -A INPUT -p tcp -s 192.168.200.64 -j ACCEPT ：这条命令在INPUT链的末尾追加(-A)了一条规则。规则的含义是：对于TCP协议(-p tcp)的数据包，如果其源IP地址(-s)是192.168.200.64，则接受(-j ACCEPT)它。

只有来自192.168.200.64的TCP流量（包括Telnet连接）会被接受。由于默认策略是DROP，且没有其他允许规则，因此来自其他任何IP地址的连接尝试都会被拒绝。此时我们来测试一下kali机的telnet联通（即192.168.200.64本机）

成功使得kali机连接成功，完成任务只允许特定IP地址访问主机的某一网络服务，而其他的IP地址无法访问。

2.2 动手实践：Snort

使用Snort对给定pcap文件，进行入侵检测，并对检测出的攻击进行说明。在kali攻击机上使用Snort，对给定的pcap文件进行入侵检测，获得报警日志。

首先安装snort：

使用命令apt install -y snort

可以看到大量内建规则没有启用，所以我们输入命令snort -c /etc/snort/snort.lua -r listen.pcap -A alert_full --lua 'ips.enable_builtin_rules = true'，打开内建规则，查看内容：

这实验命令已经正确执行：使用 Snort 读取离线 listen.pcap 文件，并加载 /etc/snort/snort.lua 配置文件。同时通过 --lua 'ips.enable_builtin_rules = true' 启用了内建规则，为后续检测更多异常行为做准备。

共加载了 866 条规则，其中包括 647 条 builtin rules，说明检测能力已经增强，能够识别更多扫描和异常报文行为。

Snort 已经开始正式分析 pcap 文件。同时这里已经出现了部分告警，例如 TCP portscan 和 TCP has no SYN, ACK, or RST，说明流量中存在端口扫描和异常 TCP 标志位行为。

包括 Nmap XMAS attack detected、TCP PDU missing ack for established session 等，表明抓包中存在明显的扫描探测和异常会话行为。

可以看到 unicast ARP request 和大量 IPv4 datagram length > captured length，说明流量中还存在可疑 ARP 请求以及异常 IPv4 报文。

可以看出本次共分析了 135580 个数据包，其中大部分是 IPv4 和 TCP 流量，说明这次检测样本量充足，分析过程完整。

其中 alert: 58 说明本次共触发了 58 条告警，port_scan 和 stream_tcp 的统计也说明 Snort 对扫描行为和 TCP 会话做了有效分析。

可以看到 wizard tcp_scans: 19，并且程序正常退出，说明本次实验已经顺利完成，且确实检测到了 TCP 扫描相关行为。

指定报警日志log目录/var/log/snort。

综上所述完成动手实践snort。

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

分析虚拟网络攻防环境中蜜网网关的防火墙和IDS/IPS配置规则，说明蜜网网关是如何利用防火墙和入侵检测技术完成其攻击数据捕获和控制需求的。

使用命令vim /etc/init.d/rc.firewall，打开：

显示了 rc.firewall 是 HoneyNet Project 提供的防火墙启动脚本。说明蜜网网关的防火墙规则不是临时手动配置，而是通过系统脚本统一管理和加载，具有较强的整体性和可维护性。

展示了 load_modules() 函数，主要用于检查旧的 ipchains 是否运行，并加载 ipt_LOG 日志模块。这说明蜜网网关在启用防火墙规则前，会先准备好日志记录能力，为后续攻击流量捕获提供支持。

显示 create_chains() 中创建了 BlackList、WhiteList、FenceList 等自定义链。说明 Honeywall 通过黑名单、白名单和隔离列表对流量进行分类控制，从而实现“允许、限制、阻断”三类不同的管理策略。

显示系统又创建了 tcpHandler、udpHandler、icmpHandler 和 otherHandler 等协议处理链。这说明蜜网网关会根据不同协议分别处理流量，便于对 TCP、UDP、ICMP 等不同类型的攻击行为进行精细控制。

中可以看到 FORWARD、INPUT、OUTPUT 的默认策略都被设置为 DROP，同时放行了本地回环接口 lo。这表明 Honeywall 采用“默认拒绝、按需放行”的思路，先保证整体安全，再允许必要通信。

为了进一步分析 Honeywall 的具体规则，实验中使用iptables 规则表查看，使用命令iptables -L | more查看：

显示 INPUT 链默认策略为 DROP，只允许部分管理流量和已建立连接通过。FORWARD 链同样默认 DROP，但对入站 TCP、UDP、ICMP 流量先记录日志再处理，说明蜜网网关既要捕获攻击数据，也要控制转发行为。

显示 OUTPUT 链默认也是 DROP，但允许部分必要的外联流量，如 SSH、SMTP、HTTP、HTTPS、DNS、NTP 等。这说明 Honeywall 会对蜜罐对外通信进行严格限制，只放行必要连接，防止被攻陷后的主机对外继续实施攻击。

再使用命令vim /etc/init.d/snortd查看：

展示了 snortd 启动脚本的内容，可以看到它会以守护进程方式启动 Snort，并指定接口、配置文件和日志目录。说明蜜网网关部署了标准 Snort IDS，用于对经过网关的流量进行持续监测和日志记录。

使用命令vim /etc/init.d/hw-snort_inline查看：

展示了 hw-snort_inline 的启动脚本，其中使用了 snort_inline，并指定了配置文件与日志目录。这说明网关不仅有普通 IDS 检测功能，还启用了 Inline 模式，具备一定的 IPS 联动处置能力。

使用命令vim /etc/honeywall.conf查看：

显示了 Honeywall 配置文件中与 Snort 规则更新相关的变量，如是否启用规则更新、是否自动重启、更新时间和 Oinkcode 等。说明蜜网网关支持对 IDS/IPS 规则进行集中维护和自动更新，从而保证检测规则能够持续生效。

使用命令ps aux | grep snort查看：

显示当前系统中存在 snort_inline 和 snort 两类相关进程。这说明 Honeywall 上的 IDS 与 IPS 组件都已实际运行，表明蜜网网关不仅配置了规则，而且已经处于工作状态。

综上所述：

通过查看 Honeywall 的防火墙脚本 rc.firewall 及当前 iptables 规则表，可以看出蜜网网关并不是简单放行或阻断流量，而是通过脚本统一加载防火墙策略，并建立 BlackList、WhiteList、FenceList 以及按 TCP、UDP、ICMP、其他协议划分的处理链，对不同类型的数据包分别处理。同时，其默认策略采用“默认丢弃、按需放行”的思路，只保留本地回环和管理接口等必要访问，从而保证所有经过蜜网网关的流量都处于可控状态。

从这些规则的作用来看，蜜网网关一方面允许外部攻击流量进入蜜罐，从而诱导攻击者与蜜罐主机交互并留下完整攻击痕迹；另一方面又通过黑名单、白名单、协议处理链和默认丢弃策略，对蜜罐的对外连接进行限制，防止被攻陷后的蜜罐继续向外部网络发起大规模攻击或横向扩散。也就是说，防火墙在 Honeywall 中承担的是“引流进入、限制外出、统一控制”的作用。

此外，实验中还进一步查看了 snortd、hw-snort_inline、honeywall.conf 以及 Snort 相关进程，说明该蜜网网关不仅依赖 iptables 做包过滤，还结合了 Snort/Snort_inline 机制完成流量检测与联动处置。其工作方式可以概括为：防火墙负责控制数据流向和访问边界，IDS 负责对经过网关的攻击流量进行实时监测、记录和告警，IPS 则可依据规则对部分恶意流量进行阻断或修改。这样，Honeywall 就同时实现了两类核心目标：一是尽可能完整地捕获攻击数据，二是严格控制攻击行为外溢风险，从而满足蜜网“可观测、可记录、可约束”的安全需求。

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

3.1 问题一：Telnet 连接被拒绝排错分析

在验证防火墙策略与网络连通性时，Kali 攻击机尝试通过 Telnet 协议连接受保护的 SEED 靶机，终端返回 Connection refused（连接被拒绝）报错，连接失败。请求包已成功到达靶机，但靶机操作系统主动返回了 TCP RST（复位）包强行断开。所以判断是没有打开telnet服务。
解决思路和方法：现代 Linux（如 SEED）出于安全考虑，默认不安装且不开启明文传输的 Telnet 服务。使用 netstat -tuln 检查靶机 23 端口，因为无监听，所以手动安装开启 telnetd 服务。

3.2 问题二：Snort 离线检测中日志输出与 Lua 参数配置问题排查

本次实验中，最初遇到的问题主要有两个：一是将 listen.pcap 路径写错，导致 Snort 无法读取离线抓包文件；二是在指定日志目录 /var/log/snort 并启用告警文件输出时，--lua 参数写法错误，导致两段配置被拼接成非法 Lua 语句，从而触发 FATAL 报错。

解决思路和方法：先确认 pcap 文件真实路径和 Snort 版本；再确认配置文件 snort.lua 是否存在；随后检查是否启用了 ips.enable_builtin_rules = true，以保证能检测到更多异常行为；最后定位报错根因，发现并非权限问题，而是 --lua 参数缺少分隔，改为用一个 --lua 并以分号分隔多条配置后成功解决。

4.学习感想和体会

通过本次实验，我对 iptables、Snort 和 Honeywall 的认识从理论概念走向了落地实践。我深切体会到，网络安全防护绝非单一技术的简单堆叠，而是边界控制、流量监测、行为约束与日志留存等多机制协同配合的系统工程。

实验让我深刻认识到“规则”在安全防护中的核心地位。无论是防火墙的精细化访问控制，还是 Snort 对异常流量的敏锐嗅探，本质上都是将抽象的安全需求转化为可执行的技术策略。在剖析 Honeywall 时，我进一步领悟了蜜网“既允许攻击发生，又严控其外溢”的设计哲学，对“可观测、可记录、可约束”的攻防理念有了更直观的认知。

此外，本次实践让我意识到，网络安全的学习绝不能止步于“会敲命令、会跑工具”，更要探究每条规则背后的目的、告警隐含的攻击特征以及各组件间的联动关系。这次经历不仅锻炼了我的动手排错能力，更培养了我透过配置文件洞察系统设计架构的思维。未来，我将在此基础上，继续向更复杂的攻防场景与整体安全体系设计深入探索。