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

20253901 2025-2026-2 《网络攻防实践》实践5报告

news 2026/4/19 10:20:12

1. 实践内容

本次实践主要完成三个部分的内容：防火墙配置实验、Snort 离线入侵检测实验，以及蜜网网关防火墙与 IDS/IPS 规则分析。实验目标是通过动手配置和测试，理解主机级访问控制、基于规则的入侵检测方法，以及蜜网环境中攻击流量的捕获与控制机制。

本次实验环境如下：

角色	虚拟机	IP地址	MAC地址	说明
受害机	Kali Linux	192.168.200.5	00:0c:29:67:38:33	防火墙配置对象
测试主机	SEEDUbuntu9	192.168.200.3	00:0c:29:e8:58:db	用于白名单访问测试
攻击机	Windows XP	192.168.200.4	00:0c:29:8b:b9:52	用于未授权访问测试
蜜网网关	Honeywall	192.168.200.8	-	防火墙与 IDS/IPS 规则分析对象

本周实验中，首先在 Kali Linux 主机上配置 iptables 防火墙规则，实现两个要求：一是过滤 ICMP 数据包，使主机不再响应 Ping 请求；二是只允许特定 IP 地址访问 Kali 上的某一网络服务，而其他主机无法访问。随后，使用 Snort 对给定的 pcap 文件进行离线入侵检测，分析其中的异常流量并生成报警日志。最后，对蜜网网关中的防火墙和 IDS/IPS 规则进行分析，理解其如何在记录攻击行为的同时控制风险扩散。

2. 实践过程

2.1、防火墙配置实验

2.1.1 查看当前 iptables 规则

首先在 Kali Linux 主机上查看当前系统中的防火墙规则：

iptables -L

该命令用于显示系统当前已经生效的 iptables 规则，包括 INPUT、OUTPUT 和 FORWARD 三条链的默认策略以及已有规则内容。查看结果显示，INPUT、FORWARD 和 OUTPUT 三条链的默认策略均为 ACCEPT，且当前未配置额外规则，说明系统处于默认放行状态，符合实验开始前的预期。

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

首先确认 Kali Linux 主机的 IP 地址为：

192.168.200.5

实验开始前，先从 Windows XP 攻击机对 Kali 主机进行 Ping 测试。此时 Kali 可以被正常 Ping 通，说明当前主机能够接收 ICMP 回显请求。

随后在 Kali 主机上配置如下防火墙规则：

iptables -A INPUT -p icmp -j DROP

含义：在 INPUT 链中追加一条规则，将所有进入主机的 ICMP 数据包直接丢弃。

参数说明：

-A：Append，表示在链末尾追加规则。
INPUT：表示该规则作用于进入主机的数据包。
-p icmp：指定匹配的协议为 ICMP。
-j DROP：指定匹配成功后直接丢弃数据包。

图中可以看到，在 INPUT 链中已经新增了一条 DROP icmp 规则，表示所有进入 Kali 主机的 ICMP 数据包都会被丢弃，从而使主机无法响应 Ping 请求。

配置完成后，再次从 Windows XP 攻击机对 Kali 主机发起 Ping 测试，此时发现 Kali 已经无法响应 Ping 请求，说明该规则已经成功生效。

为了恢复实验前的状态，在 Kali 上执行如下命令删除该规则：

iptables -D INPUT -p icmp -j DROP

含义：从 INPUT 链中删除一条“丢弃 ICMP 数据包”的规则，使主机恢复对 ICMP 报文的正常处理。

-D：Delete，表示删除规则。

删除规则后，再次从 Windows XP 对 Kali 进行 Ping 测试，可以看到 Kali 又恢复了对 Ping 请求的响应。

分析

该实验通过在 INPUT 链中添加丢弃 ICMP 的规则，实现了禁止主机接收 Ping 请求的效果。由于 Ping 命令依赖的是 ICMP 协议中的 Echo Request 和 Echo Reply 报文，因此当所有进入主机的 ICMP 数据包都被丢弃后，目标主机就不会再对外部的 Ping 请求进行回应。

ICMP 常被用于网络连通性测试和主机存活探测，因此禁止主机响应 Ping，可以在一定程度上减少主机被发现和被扫描的概率。

2.1.3 限制特定 IP 访问主机服务

本实验要求实现：只允许特定 IP 地址访问主机的某一网络服务，而其他主机无法访问。结合当前环境，将 Kali Linux（192.168.200.5） 作为受害机，将 SEEDUbuntu9（192.168.200.3） 设为允许访问的主机，将 Windows XP（192.168.200.4） 设为不允许访问的主机。

这里以 Kali 主机上的 Telnet 服务（23 端口） 为测试对象。

首先，在 SEEDUbuntu9 和 Windows XP 上分别尝试连接 Kali 主机：

telnet 192.168.200.5

如果 Kali 上相应服务已经开启（本次实验未开启，该情况已经在遇到的问题中说明），则两台主机都可以尝试连接该主机，说明这时系统对来源主机没有做额外限制。

接下来，在 Kali 上设置防火墙规则，只允许 SEEDUbuntu9 访问 Kali 的 Telnet 服务。

首先清空已有实验规则，并配置基础规则：

iptables -F
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.200.3 --dport 23 -j ACCEPT
iptables -P INPUT DROP

上述规则的含义如下：

清空当前链中的已有规则，避免旧规则影响实验；
允许本机回环接口通信；
允许已经建立或相关联的连接继续通信；
只允许源地址为 192.168.200.3 的主机访问 Kali 的 23 端口；
将 INPUT 链默认策略设置为 DROP，拒绝其他进入 Kali 的流量。

配置完成后，再次分别从 SEEDUbuntu9 和 Windows XP 发起连接测试。

在 SEEDUbuntu9 上执行：

telnet 192.168.200.5

此时应能够成功连接 Kali 主机。

在 Windows XP 上执行相同测试：

telnet 192.168.200.5

由于 Windows XP 的源地址不是被允许的 192.168.200.3，因此连接将失败。

分析

该实验实现了基于源 IP 地址和服务端口的访问控制。通过将 INPUT 链默认策略设置为 DROP，主机默认拒绝所有进入流量；然后再添加白名单规则，只允许 SEEDUbuntu9 访问 Kali 的 23 端口。这样就实现了“只允许特定 IP 地址访问主机某一网络服务，而其他主机无法访问”的实验目标。

与只限制源地址相比，这种写法进一步限定了具体服务端口，因此更符合题目中“访问主机的某一网络服务”的要求。实验结果表明，防火墙不仅可以控制谁能访问主机，还可以精确控制访问的是哪一种服务。

2.1.4 恢复实验环境

实验结束后，为避免影响后续实验，可以将 Kali 的防火墙策略恢复为默认允许状态：

iptables -P INPUT ACCEPT
iptables -F

2.2 Snort 离线入侵检测实验

2.2.1 实验目的

本实验使用 Snort 对给定的 pcap 文件进行离线入侵检测分析，识别其中是否存在异常流量或扫描行为，并生成报警日志。通过本实验，可以掌握 Snort 的基本使用方法，理解其基于规则匹配的检测机制，并学会根据报警信息分析攻击行为。

2.2.2 实验环境与实验文件

本实验在 Kali Linux 主机上完成，使用 Snort 对给定的离线数据包文件进行分析。待检测的文件为：

listen.pcap

该文件中包含大量网络通信数据，用于模拟网络扫描或攻击场景。实验中通过自定义本地规则，使 Snort 能够识别 pcap 文件中的扫描流量，并输出报警结果。

2.2.3 配置本地检测规则

在默认配置下，Snort 加载的规则主要与 file_id 相关，不能直接完成本实验所需的扫描检测。因此，需要在本地规则文件中手动添加自定义规则。

首先编辑本地规则文件：

sudo nano /etc/snort/rules/local.rules

在文件中加入如下规则：

alert tcp any any -> any any (msg:"TCP Scan Detected"; sid:1000001; rev:1;)
alert icmp any any -> any any (msg:"ICMP Packet Detected"; sid:1000002; rev:1;)

其中，第一条规则用于检测 TCP 数据包，第二条规则用于检测 ICMP 数据包。由于本次实验使用的 pcap 文件中主要包含大量 TCP 扫描流量，因此实际触发报警的主要是第一条规则。

2.2.4 运行 Snort 进行离线检测

配置好本地规则后，使用以下命令让 Snort 对 listen.pcap 进行离线入侵检测：

sudo snort -r /home/kali/Desktop/listen.pcap -c /etc/snort/snort.lua -R /etc/snort/rules/local.rules -A alert_fast -l /var/log/snort

该命令中各参数的作用如下：

-r /home/kali/Desktop/listen.pcap：指定离线分析的 pcap 文件；
-c /etc/snort/snort.lua：指定 Snort3 的主配置文件；
-R /etc/snort/rules/local.rules：额外加载本地自定义规则文件；
-A alert_fast：使用 fast 模式输出报警信息；
-l /var/log/snort：指定日志输出目录。

运行完成后，Snort 会对 pcap 文件中的网络数据包逐条进行分析，并根据规则匹配情况输出检测结果。

2.2.5 查看报警日志

检测完成后，在日志目录中查看生成的报警日志文件：

cd /var/log/snort
ls -lh
cat alert.txt

实验结果表明，Snort 成功生成了报警日志文件 alert.txt，并在其中记录了多条报警信息。

日志中出现了大量：

TCP Scan Detected

这说明 Snort 已经成功识别出 pcap 文件中的 TCP 扫描流量。

2.2.6 检测结果分析

- [0] /home/kali/Desktop/listen.pcap
--------------------------------------------------
Packet Statistics
--------------------------------------------------
daqpcaps: 1received: 135580analyzed: 135580allow: 135580rx_bytes: 8139156
--------------------------------------------------
codectotal: 135580       (100.000%)discards: 45           (  0.033%)arp: 20           (  0.015%)eth: 135580       (100.000%)ipv4: 135560       ( 99.985%)tcp: 135512       ( 99.950%)udp: 3            (  0.002%)
--------------------------------------------------
Module Statistics
--------------------------------------------------
ac_fullsearches: 28matches: 42bytes: 398
--------------------------------------------------
appidpackets: 135515processed_packets: 135505ignored_packets: 10total_sessions: 67660service_cache_adds: 7bytes_in_use: 1176items_in_use: 7
--------------------------------------------------
arp_spoofpackets: 20
--------------------------------------------------
back_orificepackets: 3
--------------------------------------------------
binderraw_packets: 75new_flows: 67660service_changes: 7inspects: 67735
--------------------------------------------------
detectionanalyzed: 135580hard_evals: 135531alerts: 135518total_alerts: 135518logged: 135518alert_limit: 13
--------------------------------------------------
dnspackets: 3requests: 3dns_over_udp: 3
--------------------------------------------------
http_inspectflows: 6scans: 12reassembles: 12inspections: 12requests: 6get_requests: 5options_requests: 1max_concurrent_sessions: 3total_bytes: 88
--------------------------------------------------
ips_actionsalert: 135518
--------------------------------------------------
port_scanpackets: 135515trackers: 6
--------------------------------------------------
search_enginequalified_events: 135531
--------------------------------------------------
streamflows: 67660total_prunes: 67659
idle_prunes_proto_timeout: 120closed_prunes: 67539tcp_timeout_prunes: 117udp_timeout_prunes: 3no_flow_tcp_rst: 3no_flow_unwanted: 7
--------------------------------------------------
stream_tcpsessions: 67657max: 67657created: 67657released: 67657instantiated: 67657setups: 67657restarts: 7syn_trackers: 67657segs_queued: 19segs_released: 19segs_used: 19rebuilt_packets: 25rebuilt_bytes: 263client_cleanups: 1server_cleanups: 12syns: 67657syn_acks: 83rsts: 67549rsts_ok_rfc5961: 46rsts_ack_ok: 67503fins: 72max_segs: 1max_bytes: 23
--------------------------------------------------
stream_udpsessions: 3max: 3created: 3released: 3total_bytes: 129
--------------------------------------------------
telnettotal_packets: 1max_concurrent_sessions: 1
--------------------------------------------------
wizardtcp_scans: 19tcp_hits: 7
--------------------------------------------------
Appid Statistics
--------------------------------------------------
detected apps and servicesApplication: Services   Clients    Users      Payloads   Misc       Referred  unknown: 7          3          0          0          0          0         
--------------------------------------------------
Summary Statistics
--------------------------------------------------
timingruntime: 00:00:03seconds: 3.452154pkts/sec: 39274Mbits/sec: 19
o")~   Snort exiting

从报警日志和检测统计结果可以看出，Snort 对 listen.pcap 中的异常流量做出了有效识别。日志中多次出现 “TCP Scan Detected” 报警，说明数据包中存在大量 TCP 探测行为。

结合 pcap 文件的实验背景，可以判断该攻击属于TCP 端口扫描。攻击者通过向目标主机的多个端口发送 TCP 探测报文，试图发现目标主机上开放的服务端口，为后续攻击做准备。这类扫描行为通常是入侵过程中的前期侦察阶段，具有明显的探测性质。

此外，Snort 输出的统计信息中还显示：

alerts 数量很多，说明命中了大量检测规则；
port_scan 模块已经对扫描流量进行了处理；
wizard 模块中出现 tcp_scans 和 tcp_hits，进一步说明 pcap 中存在 TCP 扫描行为。

因此，可以认定本次离线入侵检测实验已经成功完成，Snort 不仅识别出了 pcap 文件中的扫描流量，还通过报警日志为后续分析提供了依据。

2.2.7 小结

通过本实验，我掌握了使用 Snort 对离线 pcap 文件进行检测的基本流程，包括配置本地规则、运行离线分析命令、查看报警日志以及解释攻击类型。实验结果表明，Snort 能够根据自定义规则识别出 pcap 文件中的 TCP 扫描行为，并生成相应的报警日志。这说明基于规则的入侵检测方法在发现网络扫描和异常探测行为方面具有较好的效果。

2.3 蜜网网关规则分析

2.3.1 实验目的

本部分实验旨在分析虚拟网络攻防环境中蜜网网关的防火墙与 IDS/IPS 配置规则，理解其在整个蜜网体系中的作用，并说明蜜网网关如何借助流量控制与入侵检测技术完成攻击数据捕获与攻击行为约束这两个核心任务。

2.3.2 查看蜜网网关防火墙规则

进入蜜网网关后，可以先使用 root 权限查看当前系统中生效的防火墙规则：

iptables -L -n -v

该命令能够以数字形式显示 iptables 规则的详细内容，同时给出每条规则对应的数据包计数和字节计数。通过查看这些信息，可以了解哪些流量被允许通过，哪些流量被丢弃，以及流量主要经过哪些规则链。

从截图可以看出，蜜网网关对不同类型的流量设置了专门的处理链，并在数据包放行前结合日志记录与队列处理机制进行控制。这说明网关对外发流量并不是直接放行，而是先记录、再交由后续模块进一步处理，体现了“先监测、后决策”的安全控制思路。

除了直接查看当前内核中已经生效的规则外，还可以继续查看蜜网网关的防火墙启动脚本：

vim /etc/init.d/rc.firewall

该文件通常用于定义蜜网网关开机时自动加载的主要防火墙策略。通过分析该脚本，可以更清楚地看到蜜网环境中的规则设计思路，而不仅仅是查看最终加载后的结果。

本次分析的 /etc/init.d/rc.firewall 脚本，是 HoneyWall 蜜网网关的核心防火墙配置文件。其中 create_chains() 函数的主要作用，是根据预设配置变量动态创建 iptables 自定义链，为后续安全规则执行搭建模块化框架。该函数主要完成以下几类关键链的创建：

黑白名单控制链
当 HwBWLIST_ENABLE 配置为 yes 且对应的黑白名单文件存在时，脚本会创建 BlackList 和 WhiteList 链，用于实现对进出流量的 IP 黑白名单过滤。
防外渗围栏链
这是 HoneyWall 蜜网的核心安全机制之一。当 HwFENCELIST_ENABLE 启用时，脚本会创建 FenceList 与 FenceLogDrop 链，前者用于定义蜜罐主机禁止主动访问的外部 IP 地址，后者用于集中记录并丢弃违规数据包，从而防止攻击者利用蜜罐作为跳板发起对外攻击。
流量速率控制链
根据配置文件中定义的 HwTCPRATE、HwUDPRATE、HwICMPRATE 及 HwOTHERRATE 等参数，当速率限制值大于 0 时，脚本会为 TCP、UDP、ICMP 及其他协议分别创建 tcpHandler、udpHandler、icmpHandler 和 otherHandler 链，用于后续实现流量限速，防止蜜罐被滥用于发起拒绝服务攻击或大规模扫描。

脚本中的 default_policy() 用于设置 HoneyWall 网关的基础默认策略，其作用是为 INPUT、OUTPUT 和 FORWARD 等核心链建立统一的安全基线，使未被后续规则明确允许的流量默认受到限制，从而体现“默认收紧、按需放行”的设计思想。

分析

蜜网网关中的防火墙并不是为了单纯阻止所有攻击，而是为了在“允许观察攻击”与“防止攻击失控”之间取得平衡。其规则设计通常体现出以下几个特点：

允许外部流量进入蜜罐
如果将所有来自外部的访问请求全部拦截，那么攻击者就无法接触到蜜罐主机，蜜网也就失去了诱捕和观测的意义。因此，蜜网网关通常会允许一定范围内的访问流量进入内部蜜罐系统。
严格限制蜜罐向外主动发起连接
一旦攻击者成功控制蜜罐主机，就有可能试图利用该主机继续扫描、传播恶意程序或攻击其他目标。为了避免蜜罐被用作新的跳板，防火墙会对蜜罐的对外连接行为进行限制。
对关键流量进行记录与约束
通过规则匹配、计数和流量方向控制，蜜网网关既能够为后续分析保留网络行为痕迹，又能对异常流量施加必要限制，避免实验环境影响外部真实网络。

因此，蜜网网关中的防火墙规则并不是简单的“全拦截”或“全放行”，而是围绕两个目标展开：一方面让攻击行为能够发生，便于研究；另一方面控制攻击范围，防止风险扩散。

2.3.3 查看 IDS/IPS 配置与规则

1. 查看 `snortd` 启动脚本

vim /etc/init.d/snortd

该脚本是 Snort IDS 的系统启动脚本，主要负责加载 Snort 的配置文件、解析运行参数并控制 Snort 服务在系统指定运行级别下启动。通过该脚本，Snort 能够以入侵检测系统（IDS）的方式持续监控经过蜜网网关的网络流量，并对可疑攻击行为进行识别和记录，从而为蜜网环境提供攻击流量捕获与入侵检测能力。

2. 查看 `hw-snort_inline` 启动脚本

vim /etc/init.d/hw-snort_inline

该脚本是 HoneyWall 专用的 Snort Inline 启动脚本，用于以 Inline 模式调用 Snort，使其直接工作在网络流量转发路径中。与普通 IDS 仅进行检测和告警不同，Snort Inline 还能对匹配攻击特征的恶意流量进行实时阻断或修改，因此具备入侵防御系统（IPS）的功能。该脚本是 HoneyWall 实现攻击行为控制与主动防护的重要组成部分，也是蜜网网关核心安全机制之一。

3. 查看服务开机自启情况与当前运行状态

chkconfig --list | grep iptables
chkconfig --list | grep snort
service hw-snort_inline status
service snortd status

从截图结果可以直接得到以下信息：

service hw-snort_inline status 显示 snort_inline (pid 4376) running，说明 hw-snort_inline 当前正在运行；
service snortd status 显示 snort (pid 3569) is running...，说明 snortd 当前也正在运行；
chkconfig --list | grep iptables 显示 iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off，说明 iptables 在 2、3、4、5 运行级别下配置为开机自启；
chkconfig --list | grep snort 显示 hw-snort_inline 0:off 1:off 2:on 3:on 4:on 5:on 6:off，而 snortd 0:off 1:off 2:off 3:off 4:off 5:off 6:off，说明 hw-snort_inline 配置了开机自启，而 snortd 没有配置为开机自启。

根据上述结果可知，hw-snort_inline 与 snortd 当前均处于运行状态；其中，iptables 与 hw-snort_inline 已配置为开机自启，而 snortd 未配置为开机自启。

其中，iptables 防火墙承担基础的流量过滤与转发控制功能，是蜜网网关实现网络访问控制的重要基础。hw-snort_inline 已配置为开机自启，说明其属于系统默认启用的核心安全服务。该服务基于 Snort Inline 模式运行，直接工作在网络流量转发路径中，能够对经过网关的数据包进行实时检测，并对识别出的恶意流量进行主动阻断或控制，因此体现了入侵防御系统（IPS）的功能。

与此同时，snortd 虽未配置为开机自启，但当前处于运行状态，说明标准 Snort 服务在本实验环境中也被启用。结合其服务名称和常规工作方式，可以认为其主要承担入侵检测、告警生成和日志记录等 IDS 功能，为后续攻击分析提供支持。

2.3.4 蜜网网关如何实现攻击数据捕获

蜜网网关位于攻击者与蜜罐主机之间，是攻击流量进入内部蜜网的必经节点。因此，外部攻击者发起的扫描、连接、登录尝试以及漏洞利用流量，都会先经过蜜网网关，再转发至蜜罐系统。

在这一过程中，网关一方面通过防火墙规则对流量方向和访问路径进行控制，另一方面通过 Snort 相关服务对经过的数据包进行协议分析、特征匹配和告警记录。这样，攻击源地址、目标地址、协议类型、访问端口、规则命中情况以及攻击发生时间等信息都可以被保留下来，从而实现对攻击行为的持续观测和数据捕获。

因此，蜜网网关能够实现攻击数据捕获的关键，不在于其本身是攻击目标，而在于它位于流量通路的关键位置，并具备检测、记录和留存攻击流量的能力。

2.3.5 蜜网网关如何实现攻击行为控制

除了捕获攻击数据外，蜜网网关还承担对攻击行为进行控制的重要任务。蜜网的设计目标并不是单纯“让攻击发生”，而是在保证实验可观测性的同时，防止被攻陷的蜜罐继续危害外部网络。

这种控制主要体现在三个方面：

允许一定范围内的外部流量进入蜜罐
以保证攻击行为能够被真实触发。
严格限制蜜罐主机主动向外发起连接
避免攻击者将其作为跳板继续实施扫描、传播或攻击。
对异常流量进行记录、排队、阻断或限速处理
结合防火墙与 Snort Inline 机制降低风险扩散的可能性。

因此，蜜网网关的控制策略本质上是一种“入口适度开放、出口严格约束”的安全设计。它既保证了攻击样本的真实性，又确保了整个实验环境始终处于可控范围之内。

2.3.6 小结

通过对蜜网网关防火墙和 IDS/IPS 配置规则的分析可以看出，其工作机制并不是简单的访问限制，而是一套围绕攻击数据采集与风险控制设计的综合安全策略。

其中，iptables 防火墙主要负责流量方向、连接权限与访问路径的约束，决定哪些流量可以进入、哪些流量需要限制；Snort IDS/IPS 则负责对经过网关的流量进行特征匹配、异常识别和日志告警，并在 Inline 模式下对高风险流量进行实时控制。两者协同作用，使蜜网网关能够在保证实验安全的前提下，对攻击行为进行持续观测、有效记录和必要约束，从而同时满足攻击数据捕获与风险控制两方面需求。

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

问题1：kali的telnet服务打不开

没有任何输出，说明当前 Kali 上还没有程序在监听 23 端口，也就是说 Telnet 服务还没有真正启动。
继续执行：

sudo grep telnet /etc/inetd.conf

如果看到前面有 #，例如：

#<off># telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd

就说明 Telnet 服务被注释掉了。
执行：

sudo nano /etc/inetd.conf

找到 telnet 那一行，把前面的 # 去掉，改成类似：

telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd

保存后再执行：

sudo service openbsd-inetd restart
sudo netstat -antp | grep :23

这时候就会看到 23 端口开始监听。

问题2：snort扫描后日志无法保存

修改 /etc/snort/snort.lua

打开文件：

sudo nano /etc/snort/snort.lua

找到 alert_fast，如果是注释的，比如：

-- alert_fast = { }

改成：

alert_fast =
{
file = true
}

这是官方文档给出的启用 alert_fast 写文件的方法。

4. 实践总结

通过本次实践，我对防火墙访问控制、Snort 入侵检测以及蜜网环境中的安全策略有了更加直观的理解。

在防火墙配置实验中，我掌握了使用 iptables 对 ICMP 协议、源 IP 地址以及目标服务端口进行控制的方法，也体会到规则顺序和默认策略设置对实验结果有很大影响。通过 ICMP 过滤实验，可以看到主机如何拒绝外部的 Ping 探测；通过白名单访问控制实验，则可以更清楚地理解“只允许指定主机访问某一服务”的细粒度控制思路。

在 Snort 离线检测实验中，我初步掌握了利用 Snort 读取 pcap 文件、加载规则并生成报警日志的基本流程，也对基于规则的入侵检测机制有了更清晰的认识。Snort 不直接负责流量放行或阻断，而是侧重于对异常行为进行识别和记录，这一点与防火墙的功能形成了明显互补。

在蜜网网关分析部分，我认识到蜜网环境并不是简单地把主机暴露出来等待攻击，而是依靠防火墙、IDS/IPS 和日志审计等技术，在允许攻击发生的同时实现可观测、可记录、可控制的安全目标。

总体来看，本次实验将主机防火墙、入侵检测和蜜网机制联系在了一起，使我对网络攻防实践中的基础防御技术有了更系统的理解，也为后续继续学习网络扫描分析、攻击检测和安全策略设计打下了基础。

查看全文

http://www.jsqmd.com/news/665401/