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

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

1. 知识点梳理与总结

本次实验围绕 网络防御机制的工程化实现 展开，核心内容不再只是“识别攻击行为”或“理解协议漏洞”，而是进一步进入“如何通过防火墙、入侵检测系统和蜜网网关，对真实网络流量实施访问控制、攻击识别与行为约束”这一层面。若把前几次实验串联起来看，第二次作业主要解决“目标有哪些资产、开放了什么服务、存在哪些风险面”，第三次作业主要解决“网络中真实发生了什么通信与攻击行为、如何通过流量证据把它们识别出来”，第四次作业则进一步说明“协议本身为什么会被利用、攻击为什么能够成功”。而本次第五次实验，则把课程视角从“看见攻击、理解攻击”推进到了“配置防御、识别攻击并控制攻击”。

从知识结构上看，本次实验主要涉及三个层面的内容：

  • 主机级访问控制（Host-based Access Control）：以 iptables 为核心，通过规则链对 ICMP 与 TCP 服务访问进行控制；
  • 基于特征的入侵检测（Signature-based Intrusion Detection）：以 Snort 为核心，对离线 pcap 流量进行规则匹配、攻击识别与告警输出；
  • 蜜网防御架构分析（Honeynet Defense Architecture）：以 Honeywall 为核心，理解其如何在透明桥接环境中同时完成数据捕获（Data Capture）与数据控制（Data Control）。

也就是说，本次实验并不只是“敲几条防火墙命令”或“跑一遍 Snort”，而是在验证：当网络中真实存在攻击流量时，防御系统如何分层响应、如何记录证据、又如何避免蜜罐环境反过来成为新的攻击跳板。

1.1 防火墙、入侵检测与蜜网技术的基本认识

在现代网络防御体系中，防火墙（Firewall）、入侵检测系统（IDS）和蜜网（Honeynet）分别承担不同的职责。

首先，防火墙 的核心任务是做 访问控制（Access Control）。它关心的问题是：某个数据包是否应该被允许进入主机、离开主机或经过主机转发。像 iptables 这样的 Linux 防火墙，本质上是一个基于规则的包过滤引擎。它能够根据协议类型、源地址、目的端口、连接状态等条件，对流量做 ACCEPT（放行）、DROP（丢弃）、REJECT（拒绝） 等处理。

其次，入侵检测系统（IDS） 的核心任务是做 攻击识别（Attack Detection）。它并不直接负责所有流量的放行与阻断，而是通过规则、特征和协议行为分析，从数据包中识别可疑模式，例如端口扫描、异常 TCP 标志位组合、已知漏洞利用特征等。像 Snort 这样的开源 IDS，正是典型的 Signature-based Detection（基于特征的检测） 工具。

最后，蜜网（Honeynet） 的核心任务不是单纯“拒绝攻击”，而是“接纳、记录、分析并控制攻击”。蜜网并不追求把所有攻击都挡在外面，而是有意识地暴露一定攻击面，让攻击者愿意进入；与此同时，通过 Honeywall 这样的网关设备，对攻击流量进行抓取、记录、分析，并限制蜜罐主机继续向外攻击，从而实现研究攻击行为、提取攻击证据和降低扩散风险的目的。

因此，三者在体系中的作用可以概括为：

  • 防火墙负责“谁能进、谁能出”；
  • IDS 负责“谁可疑、谁在攻击”；
  • 蜜网负责“谁来了、做了什么、能否被控制住”。

1.2 iptables 的规则链思想与访问控制逻辑

本次实验中的防火墙实践，核心是理解 Linux iptables 的规则链（Chain）与匹配逻辑。

从工作机制上看，iptables 的常用链包括：

  • INPUT：处理进入本机的数据包；
  • OUTPUT：处理本机发出的数据包；
  • FORWARD：处理经过本机转发的数据包。

实验中用到的主要是 INPUT 链，因为我们关心的是“外部主机能否访问本机服务”。当执行：

iptables -A INPUT -p icmp -j DROP

其实就是在告诉系统：凡是进入本机、协议为 ICMP 的数据包，一律丢弃。这样，外部主机虽然还能发出 ping 请求，但由于目标主机不再回应 Echo Request，于是从攻击机角度看就会表现为“目标主机不响应 Ping”。

而在“只允许特定 IP 访问服务”的实验中，则体现了防火墙的 默认拒绝（Default Deny） 与 白名单放行（Whitelist Allow） 思想。先把 INPUT 链默认策略设为 DROP，意味着所有未被显式允许的入站流量都会被丢弃；再通过指定源 IP 的 ACCEPT 规则，为某一主机开出访问权限。这样就能实现“只有白名单主机能访问，其他主机都不行”的访问控制效果。

这一步非常重要，因为它让我们真正理解了：防火墙不是靠‘认识攻击’来工作的，而是靠‘定义规则边界’来工作的。 只要边界定义清楚，即使对方不是明显的攻击流量，也同样可以被限制。

1.3 Snort 的检测思路与 IDS 的作用

Snort 是本次实验中最核心的 IDS 工具。它的本质是一个 规则驱动型流量分析引擎，能够对网络流量进行解码、预处理和规则匹配，并在发现特征命中后输出告警。

在本实验中，Snort 不是直接监听网卡，而是对离线的 pcap 文件进行分析，这属于典型的 Offline Traffic Analysis（离线流量分析） 场景。其意义在于：

  • 不影响现场网络；
  • 可重复分析同一份流量证据；
  • 便于在实验环境中对规则命中结果进行复盘。

从检测结果上看，Snort 识别到了 TCP 端口扫描、异常 TCP 标志位组合、XMAS 扫描等特征。这说明 IDS 在网络防御中的价值，不只是“看到一个包”，而是能够把零散流量组织成带有安全意义的结论，例如：

  • 某个主机正在做主机发现；
  • 某个源地址正在对多个端口进行探测；
  • 某些报文不符合正常 TCP 会话行为。

如果说第三次实验更偏向“人工看流量并分析攻击”，那么本次实验中的 Snort 更偏向“让规则引擎代替人工，自动识别攻击模式”。

1.4 Honeywall 在蜜网中的作用

Honeywall 是蜜网环境中的核心安全网关。它的价值不在于把蜜罐“保护得很安全”，而在于在不破坏攻击观察价值的前提下，对攻击流量进行 透明捕获、证据保留和外联控制。

在经典蜜网结构中，Honeywall 通常工作在 透明桥接（Transparent Bridge） 模式下，这意味着：

  • 从攻击者视角看，它不像传统三层路由器那样显眼；
  • 它可以旁路观察经过桥接接口的数据包；
  • 它能够在二层位置对流量实施过滤、限速、记录和控制。

从本次实验分析看，Honeywall 的核心能力主要包括：

  1. 数据捕获（Data Capture）：通过桥接接口上的 Snort/日志机制，尽可能完整地记录攻击行为；
  2. 数据控制（Data Control）：通过 iptables 与 Snort_inline，对蜜罐对外发起的恶意连接进行限制或阻断；
  3. 隐蔽性（Stealth）：由于工作在桥接层，攻击者较难从常规 IP 层探测中发现 Honeywall 的存在。

也就是说，Honeywall 代表的是一种防御哲学：不是简单拒绝所有攻击，而是在可控条件下让攻击发生，并把它完整地看清楚、记下来、约束住。

1.5 与第二次、第三次、第四次作业之间的联系

（1）与第二次作业的联系：从“识别攻击面”到“限制攻击面”

第二次作业重点在于网络信息收集、资产识别和漏洞评估，主要回答的是：

  • 目标有哪些主机和服务；
  • 开放了哪些 TCP/UDP 端口；
  • 哪些组件和服务存在潜在风险；
  • 目标的攻击面（Attack Surface）是什么。

而本次第五次实验则进一步解决：

  • 当这些服务已经暴露出来后，能否通过防火墙收缩其访问面；
  • 是否可以仅允许指定主机访问某项服务；
  • 能否把原本“对谁都开放”的服务改造成“只对白名单开放”。

因此，第二次作业更偏向 Attack Surface Discovery（攻击面发现），而第五次实验更偏向 Attack Surface Reduction（攻击面收缩）。两者正好是一前一后的关系：先知道暴露了什么，再决定如何限制暴露。

（2）与第三次作业的联系：从“人工分析流量”到“自动识别攻击”

第三次作业主要围绕网络嗅探、协议分析和流量取证展开，重点是：

  • 用 tcpdump 和 Wireshark 看清楚真实通信过程；
  • 识别明文认证、主机探测、端口扫描等行为；
  • 从 pcap 文件中还原攻击者的动作路径。

本次第五次实验中的 Snort，则是在这个基础上进一步推进：

  • 不再只依靠人工观察过滤器结果；
  • 而是通过 IDS 规则自动匹配扫描特征与异常报文；
  • 从“人工取证”进化到“规则驱动的自动检测”。

换句话说，第三次作业让我们学会“人眼怎么看流量”，第五次实验让我们理解“规则引擎如何看流量”。

（3）与第四次作业的联系：从“理解攻击机制”到“部署防御机制”

第四次作业主要围绕协议缺陷利用、连接破坏与会话接管展开，重点说明：

  • ARP、ICMP、TCP 等协议为什么会被利用；
  • SYN Flood、TCP RST、会话劫持为什么能成功；
  • 攻击者如何从路径控制逐步发展到连接破坏和会话接管。

而本次第五次实验，则进一步回答防御方问题：

  • 能否通过防火墙限制某类协议流量；
  • 能否通过 IDS 识别攻击者正在发起的扫描与异常探测；
  • 能否通过 Honeywall 既“看见攻击”又“防止攻击扩散”。

因此，第四次作业更偏向 Offensive Mechanism Understanding（攻击机制理解），而第五次实验更偏向 Defensive Mechanism Deployment（防御机制部署）。它们共同体现了网络攻防课程的双视角训练：不仅要知道攻击为什么能成功，也要知道防守为什么能有效。

（4）几次实验的连续实践链路

如果把第二次到第五次实验连起来，可以形成一条非常清晰的课程实践主线：

第二次作业：信息收集与漏洞评估
第三次作业：网络嗅探、协议分析与流量取证
第四次作业：协议缺陷利用与主动攻击验证
第五次实验：防火墙、IDS 与蜜网网关防御机制实现

它们对应的能力层次可以概括为：

  • 先发现目标与风险；
  • 再观察证据与攻击流量；
  • 然后理解攻击如何成立；
  • 最后学习如何进行防御与控制。

这也说明，本次实验在整门课程中的位置非常关键：它把前几次偏攻击、偏分析的训练，和真正的防御部署能力连接了起来。

1.6 知识拓扑图

下图对本次实验涉及的知识体系进行了结构化整理：

image-20260426160906455

2. 实践过程

2.1 防火墙配置实验

本部分实验的目标，是在 Linux 平台上使用 iptables 实现两类最基础也最具有代表性的访问控制策略：一是丢弃 ICMP 数据包，使目标主机不响应 Ping；二是采用白名单机制，只允许指定源地址访问指定服务。这里保留原始实验中的全部截图，并结合第二个文件中的实验逻辑，对每一组图像现象作更细化的专业解释。

在本任务中，我将一台 Linux 虚拟机作为防御主机，并在实验环境中准备了 Linux 攻击机与 Windows 攻击机作为访问测试端。实验关注的不是“命令能不能执行”，而是“规则配置前后，网络可达性与服务可达性的差异是否与预期一致”。

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

  1. 初始状态测试

在施加防火墙规则之前，首先从攻击机执行 ping 测试，确认目标主机在默认状态下是可达的。这一步的意义，是建立一次 Normal Baseline（正常通信基线），确保后续现象变化确实由防火墙规则触发，而不是网络本身故障导致。

image-20260413141847787

图示解释： 上图展示了攻击机在攻击前能够收到正常的 ICMP Echo Reply 回显，这说明目标主机当前既在线，也未对 ICMP 请求做额外过滤。从安全运维角度看，这一状态代表目标对最基础的主机发现行为完全可见。

  1. 查看规则链初始状态

在防御主机上查看当前 iptables 规则链：

iptables -L

image-20260413135828837

图示解释： 该截图反映的是规则添加前的链表状态。这里的重点不是单纯展示命令，而是确认 INPUT 链中尚未出现针对 ICMP 的 DROP/REJECT 项。也就是说，此时目标主机仍处于相对开放的默认通信状态。

  1. 配置 ICMP 丢弃规则

在防御主机终端输入以下命令：

iptables -A INPUT -p icmp -j DROP

命令释义如下：

  • -A INPUT：在入站规则链尾部追加规则；
  • -p icmp：匹配 ICMP 协议；
  • -j DROP：直接丢弃数据包，不返回拒绝信息。

再次查看规则链：

image-20260413141613756

图示解释： 该图最核心的证据是 INPUT 链新增了针对 ICMP 的 DROP 动作。从专业角度看，这一步实现的是 ICMP Echo Suppression（ICMP 回显抑制）。它并不会让主机真的离线，但会让最基础的 Ping 探测失效。

  1. 验证规则生效结果

再次从攻击机执行 ping，此时终端不再收到正常回显：

image-20260413141817030

图示解释： 请求超时说明目标主机已经不再对 Echo Request 进行响应。从网络现象上看，目标“像是掉线了”；但从安全语义上看，这实际上是主机主动采用防火墙策略对 ICMP 做了过滤。换句话说，这不是“主机不可达”，而是“主机可达但拒绝回显”。

2.1.2 只允许特定 IP 访问主机服务

原始报告中使用了浏览器或 telnet 对 Web 服务进行连通性验证，这里保留全部原图，同时结合第二个文件中的“默认拒绝 + 白名单放行”思路，把这部分解释得更完整。

  1. 初始状态测试

在两台攻击机上访问目标服务，均可正常连通。

Kali：

image-20260413150540579

Win 攻击机：

image-20260413143529094

图示解释： 这两张图共同构成了服务访问控制实验的“攻击前基线”。它们说明目标服务在未加限制前对不同来源主机都是开放的。这种状态在安全上意味着：一旦服务暴露，任何能到达该主机的客户端都具备发起连接的机会。

  1. 设置 INPUT 默认策略为 DROP

在防御主机终端输入：

iptables -P INPUT DROP

此后两台攻击机均失去连接能力。

Win 攻击机：

image-20260413151250835

Kali：

image-20260413151304933

图示解释： 这组截图体现的是 Default Deny Policy（默认拒绝策略）。一旦 INPUT 链默认策略被设为 DROP，所有未被显式允许的入站流量都会被丢弃。因此，此时不只是恶意流量进不来，正常流量也同样被挡住了。这正是白名单策略的前提：先全部关上，再按需打开。

  1. 配置白名单规则

为了只允许特定来源主机访问目标服务，添加如下规则：

sudo iptables -I INPUT -p tcp --dport 80 -s 192.168.5.2 -j ACCEPT

image-20260413165301046

图示解释： 这一截图对应的是 Source-based Access Control（基于源地址的访问控制）。-I 把规则插入链首，确保其优先于默认拒绝策略被匹配；-s 限定访问源；--dport 80 则把放行范围约束到具体服务端口。从防御设计上看，这比“全局放行某台主机”更精细。

  1. 验证白名单效果

Kali 成功进入：

image-20260413164910655

Win 攻击机无法进入：

image-20260413172927258

图示解释： 这两张图的对比是本实验最关键的结果证据。它说明防火墙不仅能“整体阻断访问”，还能实现“差异化准入控制”：同一服务面对不同来源地址，会呈现不同的访问结果。也就是说，防火墙的价值不只是拦截攻击，更在于建立边界策略，让服务只对被信任的主体开放。

2.2 Snort 入侵检测实验

本部分实验的核心，是使用 Snort 对离线 pcap 文件进行分析，从而自动识别扫描与异常报文行为。与第三次实验中主要依赖人工观察 Wireshark 不同，这里体现的是 规则驱动的自动化检测 思路。

2.2.1 安装与版本确认

首先在攻击机上安装 Snort，并检查版本：

sudo apt update && sudo apt install snort
snort -V

安装过程：

image-20260413174221316

版本信息：

image-20260413174149425

图示解释： 这两张图并不只是“证明工具装上了”，更是在确认实验环境的 IDS 引擎版本与配置体系。从实验角度讲，Snort 版本会影响配置文件格式、规则兼容性和输出样式，因此版本确认属于 IDS 实践中的基础步骤。

2.2.2 初始运行与参数理解

先尝试对离线流量文件进行检测：

snort -r /home/kali/Desktop/listen.pcap

image-20260413175050679

图示解释： 该图对应的是 Offline Packet Inspection（离线报文检测） 的初步尝试。离线分析模式的好处在于，同一份流量可以重复复盘，不会影响线上网络，也更适合实验教学与规则调试。

随后结合配置文件、输出格式和日志目录，进一步完善 Snort 的运行方式。

配置界面：

image-20260413175414049

运行命令：

sudo snort -r /home/kali/Desktop/listen.pcap -c /etc/snort/snort.lua -A full -l /var/log/snort

image-20260413175537523

图示解释： 这组图说明 Snort 进入了更标准的实验运行模式：-c 指定配置文件，-r 指定离线证据源，-A full 使告警输出更完整，-l 指定日志目录。换句话说，这一步已经不是“能不能跑起来”，而是“让检测结果以适合分析的方式落地”。

2.2.3 告警日志分析

运行结束后，查看告警文件：

cat /var/log/snort/alert

检测结果分析说明：

在告警日志中，可以看到多类与扫描和异常报文有关的检测结果，例如：

  • ICMP PING NMAP：说明流量中存在主机发现类探测行为；
  • TCP Portscan：说明同一源地址在短时间内对多个端口发起探测，符合端口扫描特征；
  • 异常 TCP 标志位组合：例如 XMAS、SYN+FIN 等，说明探测者试图利用非常规标志位组合绕过简单检测；
  • 会话语义异常：这类告警反映某些报文不符合正常 TCP 建链与确认逻辑。

图示解释： 虽然原始报告未放出 alert 文件截图，但结合命令与实验结果，可以明确地把这一步解释为：Snort 通过规则和预处理器，把原本需要人工盯着流量才能发现的“扫描意图”自动识别出来。也就是说，Snort 在这里完成的不是普通抓包，而是 Threat Detection（威胁检测）。

从体系角度看，iptables 负责的是“能不能进”，Snort 负责的是“像不像攻击”。这两类机制并不冲突，而是边界防御与行为检测的典型分工。

2.3 蜜网网关防火墙和 IDS/IPS 操作与配置验证

本部分是本次实验最有“体系化”特点的部分。与前两个任务的单机操作不同，Honeywall 代表的是一套完整的蜜网网关防御思路：既要让攻击者进来，便于观察与研究；又要防止被攻陷的蜜罐继续向外部网络发起恶意攻击。

2.3.1 数据控制（Data Control）

① 验证网桥模式（隐身机制）

查看网桥状态：

brctl show

image-20260413181518556

查看桥接接口：

ifconfig br0

image-20260413181559074

图示解释： 这两张图最值得强调的是“Honeywall 工作在透明桥接模式”。透明桥接意味着它并不像普通三层路由器那样显式参与 IP 层转发，因此从攻击者视角看更不显眼；但在二层位置上，它又可以完整观察经过桥接接口的数据帧。这正是蜜网网关实现“隐蔽接入链路”的关键基础。

② 验证入站放通与出站限制规则

查看 FORWARD 链规则：

iptables -L FORWARD -n -v

image-20260413181632710

再查看与限速/限制相关的项：

iptables -L FORWARD -n -v | grep limit

image-20260413181724941

图示解释： 这组图体现的是 Honeywall 的 Data Control（数据控制） 能力。它的思路并不是“完全拒绝攻击者进入”，而是允许一定范围内的入站攻击流量进入蜜罐，同时对蜜罐对外发起的连接进行约束、限速或阻断。这样可以保证研究价值，同时避免实验环境成为新的攻击跳板。

2.3.2 数据捕获（Data Capture）

在桥接环境中，Snort 必须监听桥接接口 br0：

snort -i br0 -c /etc/snort/snort.conf -l /var/log/snort -D

图示解释： 这一步对应 Honeywall 的 Data Capture（数据捕获） 能力。与普通单机抓包不同，这里强调的是“在不改变原网络拓扑、且尽量不暴露网关存在的前提下，对流量进行高保真记录”。这正是蜜网环境中“既要观察攻击，又不能打草惊蛇”的关键要求。

从防御体系角度看，这部分可以概括为：

  • 透明桥接解决“如何隐蔽地进入链路”；
  • iptables FORWARD 链解决“如何控制经过网桥的流量”；
  • Snort 解决“如何记录与识别攻击行为”。

三者叠加，才构成 Honeywall 的完整能力。

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

问题1：iptables 规则配置后现象与预期不一致

问题表现： 在配置白名单访问控制后，最初出现了“规则明明添加了，但访问结果不符合预期”的情况：有时应该允许的主机无法访问，有时应该拦截的主机却没有被正确限制。

原因分析： 这是典型的 规则顺序（Rule Ordering） 问题。iptables 按自上而下顺序匹配规则，一旦前面的规则命中，后续规则就不会继续执行。如果先写了过于宽泛的 DROP 规则，再写更具体的 ACCEPT 规则，就可能导致白名单规则永远没有机会被匹配到。

解决方法：

  1. 使用 iptables -L 先查看当前链表顺序；
  2. 必要时先执行 iptables -F 清空已有规则；
  3. 按“先定义默认策略，再补充白名单放行”的思路重新配置；
  4. 每次配置后都立刻做一次验证测试，确保规则效果与预期一致。

收获： 这个问题让我真正理解了：防火墙不是“命令敲对了就一定有效”，而是“策略逻辑 + 规则顺序 + 实际验证”三者都要成立才行。网络防御很多时候不是不会写规则，而是规则之间的优先级没处理好。

问题2：Snort 运行时日志目录或配置环境不完整

问题表现： 在离线分析 pcap 文件时，Snort 曾出现日志目录不存在、配置路径不完整或输出方式与预期不符等问题，导致虽然工具成功启动，但结果文件没有按预想落地。

原因分析： 这类问题本质上不是“规则不会匹配”，而是 运行环境准备不完整（Runtime Environment Preparation Incomplete）。Snort 是一个相对工程化的 IDS 工具，它对配置文件、日志路径、规则文件、输出参数都有明确依赖，任何一个环节缺失都可能影响最终结果。

解决方法：

  1. 先确认 Snort 版本和配置体系；
  2. 检查配置文件路径与规则加载方式是否正确；
  3. 提前创建日志输出目录，并确认权限；
  4. 用较简单的命令先验证 Snort 是否能成功读取 pcap，再逐步增加输出参数。

收获： 这让我认识到，安全工具不是“装好就能用”，尤其是 IDS/IPS 这类系统，对环境依赖很强。很多时候排障的重点并不在“攻击是什么”，而在“检测引擎有没有正确跑起来”。

问题3：对 Honeywall 的“透明网桥 + 控制能力”理解不够直观

问题表现： 在分析 Honeywall 规则时，最开始很容易陷入一个疑问：既然它工作在透明桥接模式下，看起来像“隐形”的，那么它到底是怎么在不显眼的情况下，又实现流量控制和攻击限制的？

原因分析： 这是因为二层桥接、三层路由和传统主机防火墙的工作层次不同。如果只从普通路由器思维去理解 Honeywall，就很难看出它为什么既能“看见包”，又能“管住包”。

解决方法： 结合实验中对 br0、FORWARD 链、Snort 旁路监听机制等内容的分析，我逐步理清了 Honeywall 的工作方式：

  • 桥接模式解决的是“隐蔽接入链路”；
  • iptables FORWARD 链解决的是“桥上流量控制”；
  • Snort 解决的是“流量记录与攻击识别”。

收获： 这让我第一次真正理解了“蜜网网关不是普通防火墙，也不是普通 IDS，而是二者叠加后的研究型防御装置”。它既要让攻击者愿意进入，又要防止攻击者出去捣乱，这种平衡思路比单纯“全部拦截”更有策略性。

4. 实验总结

通过这次实验，我对网络防御的理解一下子从“概念会背、命令会敲一点”变成了“开始知道这些东西在实际网络里是怎么配合起来工作的”。

前几次实验更多是在学怎么发现目标、怎么看流量、怎么理解攻击为什么能成功，而这一次最大的变化是：我开始站在防守方视角去想问题了。比如在 iptables 实验里，我真正体会到了什么叫“不是所有人都应该能访问我”，以及“默认拒绝、按需放行”为什么会成为防火墙设计的经典思想。以前看书时觉得防火墙规则很枯燥，但这次自己一条条加完、再看不同主机访问结果真的不一样，那种“规则能改变网络行为”的感觉特别直观。

Snort 实验也让我很有感触。第三次作业里我还是靠自己盯着 Wireshark 过滤器一点点找流量特征，这次换成 Snort 以后，就像是第一次看到“安全规则引擎”真正工作起来。看着它自动把端口扫描、异常 TCP 标志位这些行为标出来，我会很自然地想到：原来企业里的安全运营中心并不是每个人都一直手工盯着流量，而是依赖这类系统不断替人筛查异常。也正因为这样，我更能理解为什么 IDS 的难点不只是“能不能报”，而是“报得准不准、会不会一堆误报”。

对我来说，最有意思的还是 Honeywall 这一部分。因为它让我第一次意识到，防御并不总是“把门关死”。有时候更高明的做法，是故意留出一个受控空间，让攻击者进来，然后把他的动作全都录下来，同时又不让他继续危害外部环境。说白了，这就像给黑客搭了一个“透明鱼缸”：他以为自己在自由活动，其实每一步都在被观察。这个思路特别让我觉得网络安全不只是技术，更是一种策略设计。

这次实验还让我有一个很真实的体会：防守比攻击更讲究体系。 攻击的时候，很多时候一条命令、一种漏洞利用就能看到现象；但防守的时候，你得同时考虑规则顺序、默认策略、日志输出、检测能力、服务启动、网关模式、外联控制……少一个环节，整个系统效果都可能打折扣。也正因为这样，我开始理解为什么现实中的安全工作不只是“找漏洞”，更多是“搭体系、做边界、留证据、控风险”。

总的来说，这次实验让我把第二次到第四次作业里的很多内容真正串了起来：先知道目标有什么风险，再知道攻击流量长什么样，再知道攻击为什么能成立，最后再回到防守方视角去思考怎么限制、怎么发现、怎么控制。我觉得这次实验最大的收获，不只是会了几条 iptables 命令、跑通了一次 Snort，而是开始慢慢建立起一种完整的攻防思维：不仅要会看风险，也要会收边界；不仅要能看见攻击，也要能设计好防御。

posted @ 2026-04-13 18:22  Haut_XXS  阅读(41)  评论(0)    收藏  举报