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

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

1.知识点梳理与总结

1.1 实验内容及相关知识点

  1. 防火墙配置实践

    • 防火墙基本概念： 防火墙是在内部可信网络与外部不可信网络之间建立的一道安全屏障。本次实验重点使用的是“包过滤防火墙”，它就像一个门卫，通过检查每个数据包的头部信息（如源 IP、目的 IP、协议类型和端口号）来决定是放行（ACCEPT）还是丢弃（DROP）。
    • iptables 结构逻辑： iptables 是 Linux 系统中配置防火墙规则的工具。它的核心结构可以概括为“表包含链，链包含规则”。
      • 实验中最常使用的是 filter 表，它主要负责数据包的过滤。
      • filter 表中包含了 INPUT 链（控制进入本机的数据）和 OUTPUT 链（控制本机发出的数据）。
    • 规则匹配原则： iptables 的规则是“自上而下逐条匹配”的。当数据包与某条规则匹配成功后，就会立刻执行动作，不再向下检查。因此，在配置白名单（先允许特定 IP，再拒绝所有）时，规则的先后顺序不能弄错。

  2. Snort入侵检测实践

    • IDS 的核心作用： 入侵检测系统（IDS）相当于网络中的“监控探头”。它不直接阻断网络连接，而是通过监听流经网卡的数据包，识别出潜在的恶意扫描或攻击行为并发出告警。
    • Snort 的工作机制： 本次实验使用的 Snort 是一款经典的开源 IDS 工具。它主要采用基于特征的“误用检测”方法。简单来说，就是把网络流量与系统中预先写好的“黑客攻击特征库”进行比对，一旦发现吻合的恶意字符串或异常标志位，就会触发报警。
    • 规则与离线分析： Snort 的规则由“规则头”（定义源/目的地址和协议）和“规则选项”（定义具体的攻击特征）组成。在本次实践中，我们利用 Snort 对抓包文件（.pcap）进行离线分析，成功提取出了隐藏在海量流量中的 TCP SYN 隐蔽端口扫描行为。

  3. 蜜网网关规则分析实践

    • 风险与挑战： 蜜网系统的主要目的是“诱敌深入”以收集黑客的攻击手法，但如果不加控制，蜜罐主机一旦被黑客攻陷，很容易沦为攻击其他网络节点的“跳板”。

    • 双重防御机制： 为了解决上述风险，蜜网网关采取了“防火墙粗粒度控制 + 入侵检测细粒度阻断”的协同策略：

      • iptables 限制： 网关的 rc.firewall 脚本中配置了严格的流量管控规则（如限制对外发包的频率和连接数），从宏观上防止蜜罐被用于发起 DoS 拒绝服务攻击。

      • Snort_inline 阻断： 网关内部还将 Snort 调整为了 IPS（入侵防御）模式。在记录黑客攻击日志的同时，只要发现蜜罐试图向外发送包含已知攻击特征的数据包，就会立刻将其丢弃（Drop），完美实现了数据的完整捕获与出站风险的严格控制。

1.2 实验环境

主机 IP地址 Mac地址
Kali虚拟机2025.4 192.168.200.9 00:0c:29:f1:93:ac
Kali虚拟机2021.1 192.168.200.4 00:0c:29:b4:1b:a1
SEEDUbuntu9-Aug-2010 192.168.200.3 00:0c:29:7d:32:12
VMNet8网卡 192.168.200.1 00:50:56:f6:45:a5

2.实验过程

2.1 防火墙配置实践

​ 实验环境如下

  • 靶机（被保护的服务器）： SEEDUbuntu (IP: 192.168.200.3)
  • 信任主机（授权客户端）： Kali 2021.1 (IP: 192.168.200.4)
  • 非信任主机（模拟攻击机）： Kali 2025.4 (IP: 192.168.200.9)

子任务 1：过滤 ICMP 数据包（防御 Ping 探测）

  1. 目的是通过配置 iptables 规则丢弃 ICMP 回显请求（Echo Request）数据包，使靶机对外部的 Ping 探测无响应，实现网络隐蔽。

  2. 初始连通性测试：在非信任主机（Kali 2025.4, 192.168.200.9）的终端中执行 Ping 命令探测seed靶机：

    ping 192.168.200.3

    image-20260413151150860

  3. 在seed靶机中配置防火墙拦截规则：利用 iptables 向 INPUT 链中添加针对 ICMP 协议的丢弃规则：

    sudo iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
# 查看已生效的规则列表：
sudo iptables -L INPUT -n -v

    image-20260413151855366

  4. 验证规则有效性，用Kali 2025.4，重新执行 Ping 探测：

    ping 192.168.200.3

    image-20260413152017944

    SEED靶机的防火墙因为配置了拦截规则，底层识别到了数据包头部的 ICMP 协议及 请求标识，根据规则链匹配将其静默丢弃，未返回 应答报文，防御探测成功。但是SEED虚拟机依然可以ping通kali2025.4。

    image-20260413153647429

  5. 实验完成后，在 SEEDUbuntu 上清空防火墙配置，避免干扰后续实验，可以看见防火墙配置被清空了。

    sudo iptables -F

    image-20260413154010196

3. 子任务 2：基于 IP 地址的特定访问控制

  1. 实验目的是模拟真实业务场景中的“白名单”安全机制。要求 SEEDUbuntu 开启的 Web 服务仅允许信任主机 (192.168.200.4) 访问，其他任意 IP (192.168.200.9) 的访问均被拒绝。

  2. 在SEED靶机部署测试 Web 服务在靶机（SEEDUbuntu, 192.168.200.3）上开启一个临时的 HTTP 服务，监听 8080 端口：

    python -m SimpleHTTPServer 8080

    image-20260413161341521

  3. 新开一个 SEEDUbuntu 的终端窗口，依次配置允许和拒绝规则。基于 Netfilter 框架“顺序匹配，命中即退出”的特性，必须确保 ACCEPT 规则位于 DROP 规则之前：

    # 规则1：允许来自受信任 IP 的 TCP 8080 端口访问请求
sudo iptables -A INPUT -p tcp --dport 8080 -s 192.168.200.4 -j ACCEPT

# 规则2：丢弃其他所有访问 TCP 8080 端口的请求
sudo iptables -A INPUT -p tcp --dport 8080 -j DROP

# 查看当前规则配置状态：
sudo iptables -L INPUT -n -v

    image-20260413161951746

  4. 在信任主机（Kali 2021.1, 192.168.200.4）的终端中发起 HTTP 请求：

curl http://192.168.200.3:8080

image-20260413162154027

由于kali2021.1的数据包源 IP 为 200.4，成功匹配防火墙第一条规则，动作执行 ACCEPT，连接建立，能够成功显示html网页。

  1. 在非信任主机（Kali 2025.4, 192.168.200.9）的终端中发起相同的 HTTP 请求：

    curl http://192.168.200.3:8080

    image-20260413162647584

    可以看见由于防火墙配置的准入规则中没有配置kali2025.4的ip地址，数据包源 IP 为 200.9，第一条白名单规则不匹配；数据包继续向下流转，命中第二条全局丢弃规则，动作执行 DROP，连接被阻断，白名单机制生效所以它访问不了seed靶机的http服务。

  2. 在 SEEDUbuntu 终端中使用 Ctrl+C 终止 Python Web 服务，并执行 sudo iptables -F 清理防火墙规则，可以看见防火墙规则被清空了，实验环境恢复如初。

    image-20260413163006787

2.2 Snort入侵检测实践

  • 实验目的： 通过分析给定的listen.pcap 流量文件，熟练掌握开源入侵检测系统 Snort 的基本使用方法；理解并识别隐蔽的 TCP SYN 端口扫描特征。
  • 分析环境： Kali Linux 2025.4 (内置 Snort 3 引擎)。

  1. 首先，在 Kali 2025.4 环境中找到待分析的离线抓包文件 listen.pcap。在终端中切换到该文件所在的目录，并确认文件存在。

    image-20260413163711225

  2. 利用 Snort 引擎对该 pcap 文件进行离线审计。通过指定 -c 参数加载核心配置文件（包含预处理指令和社区规则集），并使用 -A alert_fast 参数将告警信息以精简格式输出到日志目录中。

    # 执行分析命令
snort -r listen.pcap -c /etc/snort/snort.lua -R /etc/snort/rules/local.rules -A alert_fast

    终端中显示内容如下：

                                                                           -----------------------------------------------
o")~   Snort++ 3.11.1.0
--------------------------------------------------
Loading /etc/snort/snort.lua:
Loading snort_defaults.lua:
Finished snort_defaults.lua:
        stdout_trace
        syslog_trace
        stream_ip
        stream_user
        arp_spoof
        dns
        netflow
        iec104
        modbus
        s7commplus
        dce_tcp
        dce_http_proxy
        gtp_inspect
        port_scan
        active
        alerts
        decode
        host_cache
        host_tracker
        hosts
        network
        packets
        process
        search_engine
        ips
        classifications
        references
        appid
        file_id
        http2_inspect
        http_inspect
        ftp_data
        ftp_client
        ftp_server
        smtp
        dce_http_server
        dce_udp
        dce_smb
        opcua
        mms
        dnp3
        cip
        telnet
        ssl
        ssh
        socks
        sip
        rpc_decode
        pop
        normalizer
        imap
        back_orifice
        stream_file
        stream_udp
        stream_tcp
        stream_icmp
        stream
        so_proxy
        daq
        output
        file_policy
        js_norm
        trace
        wizard
        binder
Finished /etc/snort/snort.lua:
Loading file_id.rules_file:
Loading file_magic.rules:
Finished file_magic.rules:
Finished file_id.rules_file:
--------------------------------------------------
ips policies rule stats
              id  loaded  shared enabled    file
               0     219       0     219    /etc/snort/snort.lua
--------------------------------------------------
rule counts
       total rules loaded: 219
               text rules: 219
            option chains: 219
            chain headers: 1
--------------------------------------------------
service rule counts          to-srv  to-cli
                  file_id:      219     219
                    total:      219     219
--------------------------------------------------
fast pattern groups
                to_server: 1
                to_client: 1
--------------------------------------------------
search engine (ac_bnfa)
                instances: 2
                 patterns: 438
            pattern chars: 2602
               num states: 1832
         num match states: 392
             memory scale: KB
             total memory: 71.2812
           pattern memory: 19.6484
        match list memory: 28.4375
        transition memory: 22.9453
appid: MaxRss diff: 2956
appid: patterns loaded: 300
--------------------------------------------------
pcap DAQ configured to read-file.
Commencing packet processing
Retry queue interval is: 200 ms
++ [0] listen.pcap
-- [0] listen.pcap
--------------------------------------------------
Packet Statistics
--------------------------------------------------
daq
                    pcaps: 1
                 received: 135580
                 analyzed: 135580
                    allow: 135580
                 rx_bytes: 8139156
--------------------------------------------------
codec
                    total: 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_full
                 searches: 28
                  matches: 42
                    bytes: 398
--------------------------------------------------
appid
                  packets: 135515
        processed_packets: 135505
          ignored_packets: 10
           total_sessions: 67660
       service_cache_adds: 7
             bytes_in_use: 1176
             items_in_use: 7
--------------------------------------------------
arp_spoof
                  packets: 20
--------------------------------------------------
back_orifice
                  packets: 3
--------------------------------------------------
binder
              raw_packets: 75
                new_flows: 67660
          service_changes: 7
                 inspects: 67735
--------------------------------------------------
detection
                 analyzed: 135580
--------------------------------------------------
dns
                  packets: 3
                 requests: 3
             dns_over_udp: 3
--------------------------------------------------
http_inspect
                    flows: 6
                    scans: 12
              reassembles: 12
              inspections: 12
                 requests: 6
             get_requests: 5
         options_requests: 1
  max_concurrent_sessions: 3
              total_bytes: 88
--------------------------------------------------
port_scan
                  packets: 135515
                 trackers: 6
--------------------------------------------------
stream
                    flows: 67660
             total_prunes: 67659
idle_prunes_proto_timeout: 120
            closed_prunes: 67539
       tcp_timeout_prunes: 117
       udp_timeout_prunes: 3
          no_flow_tcp_rst: 3
         no_flow_unwanted: 7
--------------------------------------------------
stream_tcp
                 sessions: 67657
                      max: 67657
                  created: 67657
                 released: 67657
             instantiated: 67657
                   setups: 67657
                 restarts: 7
             syn_trackers: 67657
              segs_queued: 19
            segs_released: 19
                segs_used: 19
          rebuilt_packets: 25
            rebuilt_bytes: 263
          client_cleanups: 1
          server_cleanups: 12
                     syns: 67657
                 syn_acks: 83
                     rsts: 67549
          rsts_ok_rfc5961: 46
              rsts_ack_ok: 67503
                     fins: 72
                 max_segs: 1
                max_bytes: 23
--------------------------------------------------
stream_udp
                 sessions: 3
                      max: 3
                  created: 3
                 released: 3
              total_bytes: 129
--------------------------------------------------
telnet
            total_packets: 1
  max_concurrent_sessions: 1
--------------------------------------------------
wizard
                tcp_scans: 19
                 tcp_hits: 7
--------------------------------------------------
Appid Statistics
--------------------------------------------------
detected apps and services
              Application: Services   Clients    Users      Payloads   Misc       Referred  
                  unknown: 7          3          0          0          0          0         
--------------------------------------------------
Summary Statistics
--------------------------------------------------
timing
                  runtime: 00:00:01
                  seconds: 1.372092
                 pkts/sec: 98813
                Mbits/sec: 47
o")~   Snort exiting

    image-20260413230022445

    根据提取出的 Snort 告警日志，观察到大量密集触发的 TCP SYN Portscan 报警。

    • 原理推断： 结合理论知识可知，这是典型的半开连接端口扫描行为。攻击机向目标主机的各个端口发送带有 SYN 标志位的 TCP 握手包。

    • 结论： Snort 底层的预处理器（如 stream_tcp 和 port_scan 模块）正是敏锐地捕捉到了这种“短时间内大量只有 SYN 请求而未完成完整三次握手”的异常协议状态模型，从而准确判定该 pcap 文件中包含一次针对性的 TCP 端口扫描攻击行为。尽管 Snort 因默认规则未开启端口扫描检测功能而未触发告警，但该异常流量已明确存在安全风险。

2.3 蜜网网关规则分析实践

  • 实验目的： 了解蜜网网关的设计思路
  • 分析目标： Honeywall 虚拟机。
  • 分析重点： /etc/init.d/rc.firewall 脚本与 /etc/hflow/snort.conf 配置文件。

  1. 登录 Honeywall 虚拟机的控制台，查看负责底层网络包过滤的防火墙核心启动脚本 rc.firewall。

    vim /etc/init.d/rc.firewall

    Honeywall 在网关处使用了 iptables 构建了三道基础防线：

    1. 黑/白名单机制： 定义了不受监控的管理 IP（白名单）和直接丢弃的已知恶意 IP 源（黑名单）。
    2. 协议限速链： 为了防止内部的蜜罐主机被黑客攻陷后，反向对互联网发起 DoS（拒绝服务）攻击或大范围端口扫描，脚本内部利用 iptables -m limit 模块对蜜罐对外发包的频率（如 ICMP 请求、TCP SYN 包）进行了严格的硬性阈值限制。这体现了蜜网网关对于“出站风险”的严格管控。

    image-20260414084958961

  2. 在文件中找到黑名单、白名单以及防护名单的相关内容

    image-20260414085255688

  3. 找防火墙的默认防护策略

    image-20260414085414198

  4. 找黑名单加载模块，阻断所有恶意IP的通信

    image-20260414085535151

  5. 找白名单加载模块，信任IP的通信都不受限

    image-20260414085656820

  6. 在xinXP虚拟机中，输入https://192.168.200.10/打开网关的图形化管理界面。输入账号密码。

    image-20260414090908012

  7. 在图形化界面中也可以看见和修改防火墙规则

    image-20260414091108457

  8. 在honeywall中输入指令查看snort的脚本文件

    vim /etc/init.d/snortd # 编辑Snort入侵检测系统的启动服务脚本

    image-20260414091314833

    image-20260414091403339

  9. 在终端中中输入指令查看honeywall的脚本配置文件

    vim /etc/honeywall.conf

    image-20260414091741787

    image-20260414091922463

  10. 查看服务启动脚本hw-snort_inline，寻找防火墙与 IPS 联动的关键参数。

    vim /etc/init.d/hw-snort_inline

    image-20260414093154927

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

问题1：在最初执行离线检测时，发现 Snort 引擎能够完整解析十万余个数据包，但未触发任何告警。经排查运行日志发现，Kali 默认的 local.rules 文件为空（加载前后 Rule count 均为 219）。

解决办法：为此，我深入分析了 listen.pcap 中隐蔽端口扫描的底层逻辑，在AI的帮助下手动编写了一条基于 TCP 标志位异常的检测规则：alert tcp any any -> any any (msg:"TCP SYN Portscan..."; flags:S; sid:1000001;) 并将其追加至本地规则库。再次运行检测引擎后，成功捕获了大量 SYN 扫描行为。

image-20260413231103324

4.学习感悟、思考等

在这次实验过程中，在配置 iptables 防火墙时，我认识到安全策略容不得半点马虎，如果ACCEPT 规则位于 DROP 规则之后，则配置就毫无意义，让我了解了在实验过程中要更加仔细认真的。而在使用 Snort 进行流量检测时，我起初因为默认规则库为空而一无所获。但后来慢慢通过查阅资料、以及在AI的帮助下手动编写了一条规则成功捕获到扫描行为，让我真切感受到了学知识不仅要知其然更要知其所以然。这次实验虽然遇到了不少配置上的小波折，但正是这些真实的排错过程，极大夯实了我的底层网络基础，让我受益匪浅。

posted @ 2026-04-15 13:10  copyxu  阅读(39)  评论(0)    收藏  举报