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

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

1.实践内容

本周的学习重点在于构建纵深防御体系，通过“访问控制”与“入侵检测”双重手段保护网络资产。实践内容涵盖：

  1. 防火墙规则定制：基于 iptables 实现基础的 ICMP 过滤（防御 Ping 扫描）及针对特定服务（Telnet 23端口）的源 IP 访问控制。
  2. Snort 流量指纹分析：利用 Snort 引擎对离线流量文件 listen.pcap 进行深度包检测（DPI），识别网络中的攻击探测行为。
  3. 蜜网网关（Honeywall）防御机制剖析：深入系统底层配置（如 snortd 守护进程）与 iptables 内存生效规则，解构经典 Roo Honeywall 系统如何通过静默网卡绑定实现高隐蔽的“数据捕获”，并利用细粒度的协议限速与网关隔离策略实现沙盒式的“数据控制”。

2.实践过程

2.1 防火墙配置实践

本次实验模拟对核心服务器的加固。

  • 环境参数：Linux靶机（192.168.200.5）、Kali攻击机（192.168.200.6）。

(1) 过滤 ICMP 数据包（防御 Ping 扫描）
为了直观验证防火墙规则的作用，本次测试采用“连通-阻断-恢复”的完整闭环流程：

  1. 初始连通性测试：首先在 Kali 攻击机上执行 ping 靶机IP，能够正常收到靶机（Ubuntu）的 ICMP 响应包，确认双方网络基础互通。

kali ping 靶机
image

靶机 ping kali
image

  1. 配置过滤规则：在攻击机上执行指令 sudo iptables -A INPUT -p icmp -j DROP。该规则会直接丢弃所有入站的 ICMP 请求，使靶机在网络扫描中处于“隐身”状态。

kali安装iptables sudo apt-get install iptables，并执行sudo iptables -L查看防火墙配置
image

执行指令 sudo iptables -A INPUT -p icmp -j DROP
image

  1. 阻断效果验证：从 靶机发起 ping 请求。此时终端卡死无响应或提示“Request timed out”（100% packet loss），充分验证了 ICMP 阻断规则已生效。
    image

  2. 清空规则：在攻击机终端执行 sudo iptables -F，清空当前设定的所有防火墙过滤规则。
    image

  3. 恢复连通性验证：最后一次从 Kali 攻击机执行 ping 测试，发现重新获得了 Ubuntu 的响应包。整个过程直观体现了 iptables 规则的动态生效与撤销。
    image

(2) 特定服务（Telnet 23端口）的访问控制
为了保证管理通道的安全，本次测试采用“先全局阻断，后针对性放行”的策略，最终实现仅允许特定的管理节点（Kali）访问靶机的 TCP 服务。

  1. 初始连通性测试：在未配置任何阻断规则前，分别从 Kali（192.168.200.6）和 Metasploitable（192.168.200.5）执行命令 telnet 192.168.200.4。两台机器均能成功连接并跳转至 Ubuntu 靶机的登录提示界面，证明基础网络与 Telnet 服务均正常。
    image
    image

  2. 全局阻断配置：在 Ubuntu 靶机中执行命令 sudo iptables -A INPUT -j DROP（或设置默认策略 sudo iptables -P INPUT DROP），拒绝一切外部数据包的流入。
    image

  3. 阻断效果验证：再次从 Kali 和 Metasploitable 尝试 Telnet 访问 Ubuntu。此时两台机器的连接请求均被直接丢弃，终端卡死在“正在连接...”阶段直至超时，说明全局阻断生效。
    image
    image

  4. 特定IP放行（白名单）：在 Ubuntu 靶机中执行命令开启对 Kali 虚拟机的 TCP 服务放行：
    sudo iptables -A INPUT -p tcp -s 192.168.200.6 -j ACCEPT
    image

  5. 最终测试验证：

    • Kali 攻击机 (.6)：再次执行 telnet 192.168.200.4，能够秒连并正常提示登录，说明放行规则匹配成功。
    • Metasploitable (.5)：执行相同命令，由于其 IP 无法匹配第一条白名单规则，最终落入默认的 DROP 规则中，依然无法对靶机进行访问。
      image

image

2.2 动手实践：Snort 入侵检测

任务描述：使用 Snort 对 listen.pcap 进行分析，获取报警日志。

  1. 执行离线分析：
    使用命令 snort -r listen.pcap -c /etc/snort/snort.conf -K ascii。发现大量tcp包
    image
    image

  2. 日志分析：

    • 配置文件修改：首先打开 Snort 的配置文件（如 snort.lua），找到 -- alert_fast = {} 所在的行，去掉前面的 -- 注释符号，并将其修改为 alert_fast = { file = true, limit = 64 }，以启用快速报警模式并将日志输出到文件。
      image

    • 执行离线检测：保存配置后，直接运行 Snort 读取 pcap 文件进行离线检测（例如执行 snort -c snort.lua -r listen.pcap -l /var/log/snort）。由于已在配置文件中开启了模块，此时不需要在命令行中再额外追加 -A alert_fast 参数。
      image

    • 查看报警日志：运行结束后，进入日志目录查看生成的 alert_fast.txt（或 alert）文件。可以看到主要是172.31.4.178对172.31.4.188进行的nmap扫描
      image

2.3 分析配置规则：Roo Honeywall 的防御逻辑

本部分通过对底层配置文件与运行状态的逐层排查，深入剖析 Roo Honeywall 是如何统筹“数据控制（Data Control）”与“数据捕获（Data Capture）”机制的。

  1. 查看防火墙初始化脚本：

    • 指令执行：在 Honeywall 终端使用命令 vim /etc/init.d/rc.firewall 查看防火墙配置文件。
    • 分析：该脚本是 Honeywall 防火墙规则的源头配置。它定义了系统在启动阶段如何加载访问控制策略以及构建网桥的过滤逻辑，为整个蜜网的“数据控制”体系奠定了底层基石。
      image

  2. 分析当前生效的防火墙规则（数据捕获与控制核心）：

    • 指令执行：使用命令 iptables -t filter -L | more 分屏查看当前内存中生效的过滤表规则。
    • 观察与深度分析（结合实验截图）：
      • 网关自身隔离保护（INPUT 链）：从截图可以看出，靶机网关的 INPUT 链仅显式放行了 ssh（TCP 22）和 https（TCP 443）端口，并在末尾设置了无条件的全局 DROP。这种“白名单”机制确保了 Honeywall 管理接口的绝对隐蔽与安全，防止高水平攻击者在渗透蜜罐后“反客为主”直接攻陷网关。
      • 蜜网数据控制 / 外发限速机制（FORWARD 链灵魂）：FORWARD 链体现了蜜网“防止作为跳板攻击外网”的核心控制思想。系统针对各类可能被恶意利用的外发协议设置了极其严格的连接频率限制（Rate Limiting）：
        • 对 smtp（防止发垃圾邮件）、http、icmp（防止 Ping 泛洪）、udp 流量限制为：limit: avg 20/hour burst 5（平均每小时允许 20 个连接，最大突发 5 个）。
        • 对 ftp、pop3、ssh 及其他常规 tcp 流量限制更为严格：limit: avg 10/hour burst 5。
        • 分析结论：一旦蜜罐被黑客完全控制，并试图向外部真实网络发起 DDoS 攻击或大范围端口扫描，其产生的海量并发连接将迅速触碰这些阈值。超出限制的异常流量将无法匹配到 ACCEPT 规则，最终被拦截，从而在允许黑客“表演”的同时，将其危害完美隔离在沙盒之内。
      • 数据捕获与审计（LOG 联动）：在截图的 FORWARD 链中，还清晰可见一条规则：LOG all -- anywhere anywhere LOG level info prefix "[HW] "。这意味着在数据包穿越网桥接受限速审查的同时，其关键报文信息会被打上 [HW] 标签并被内核级记录到日志中，实现了“控制”与“捕获”的无缝联动，为后续还原攻击路径保留了法医级证据。
        image

  3. 审查核心服务运行级别状态：

    • 指令执行：执行命令 chkconfig --list | grep iptables（也可以将 iptables 替换为 snort 等其他关键服务）来查看服务的启动情况。
    • 运行级别（0~6）原理解析：该命令会展示服务在 Linux 系统的 7 个不同运行模式下的开关状态：
      • 0：关机模式（系统停机状态，不响应服务）
      • 1：单用户模式（仅供 root 进行系统维护）
      • 2：多用户模式（不支持 NFS 网络文件系统）
      • 3：完全多用户模式（最常见的服务器纯文本终端模式）
      • 4：系统保留（未分配，通常供用户自定义）
      • 5：图形化桌面模式（带 X Window 系统）
      • 6：重启模式
    • 分析：作为核心安全网关，必须确保 iptables 等访问控制服务在级别 3 和 5 下处于开启（on）状态，以此保证系统无论在何种常规工作模式下，数据控制策略都能自启动并持续生效。
      image

  4. 查看 Snort 监听与网卡配置（底层数据捕获机制）：

    • 指令执行：执行命令 vim /etc/rc.d/init.d/snortd 查看 Snort 守护进程（Daemon）的启动与初始化脚本。
    • 观察与深度分析（结合实验截图）：
      • 网卡接口硬绑定：从截图中脚本的开头可以清晰地看到变量定义 INTF="eth0" 以及对应的进程文件路径 PIDFILE="/var/run/snort_eth0.pid"。这表明 Snort 入侵检测引擎被显式绑定在了 eth0 网络接口上。在 Honeywall 的拓扑中，eth0 通常是直面外部攻击者或作为透明网桥一端的核心物理接口。将探针部署在此处，确保了能够第一时间、无遗漏地捕获所有进出蜜网的流量。
      • 隐蔽的守护进程模式（Daemon）：观察脚本的 start 函数逻辑块，可以看到其核心执行命令包含了 daemon /usr/sbin/snort ... -D -i $INTF。其中，-D 参数指示 Snort 以完全静默的后台守护进程模式运行，而 -i $INTF 则将其实际挂载到了之前定义的 eth0 上。
      • 分析结论：这段脚本解释了蜜网“数据捕获”高度隐蔽性的工程实现。Snort 以旁路嗅探的形态依附于网桥接口，它不需要该网卡配置任何可被路由的 IP 地址（从而在网络层对黑客实现了彻底的“隐身”）。只要攻击流量流经物理网卡，就会被底层的抓包机制截获并交由 Snort 规则库进行特征匹配。这也从底层逻辑上印证了在任务二中能够获取到高保真 pcap 文件与详尽扫描报警日志的原因。
        image

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

  • 问题 1：配置防火墙规则后，原本在白名单的 Linux 攻击机也无法访问 Telnet。
  • 解决方案：检查规则顺序发现，全局 DROP 规则被放到了 ACCEPT 规则之前。iptables 是从上到下匹配的，一旦匹配到 DROP 就直接结束。调整顺序，将放行规则移至最顶部后问题解决。
  • 问题 2：Snort 报警日志中出现了大量的 SMB 误报。
  • 解决方案：这是由于实验环境中存在背景流量。通过结合 listen.pcap 的 Wireshark 协议分析，筛选出特定的攻击特征码，并在 Snort 规则中添加了更精确的偏移量（Offset）检测，过滤掉了正常的 NetBIOS 查询干扰。

4.实践总结

本次实践不仅是技术的操练，更是对安全工程思维的深度训练。通过手动配置 iptables 并分析 Honeywall 的防护规则，我深刻体会到：真正的安全不在于单点的坚固，而在于对流量流动性的精准掌控。

在 Roo Honeywall 的分析中，我看到了其在“诱敌深入”与“风险隔离”之间的精妙平衡，这对我目前正在研究的关于复杂系统安全管理和审计机制提供了宝贵的实战灵感。同时，Snort 的实战应用也再次证明了，在面对海量数据包时，精准的规则定义才是还原攻击真相的关键。这些实验数据和心得也将作为我后续学术研究和向导师汇报的重要实践依据。

参考资料

posted @ 2026-04-19 04:01  后生许令  阅读(19)  评论(0)    收藏  举报