20253902 吴晨宇 2025-2026-2 《网络攻防实践》第三周作业

知识点总结

第三周的作业本质上是对第二周作业的扩展，我们将要学习网络嗅探与协议分析，通过扫描端口分析业务面，以及作为蓝方，如何进行初步安全审计和分析。
tcpdump、
arp
rarp arp欺骗 DNS 负载均衡

1）tcpdump与Web访问分析的基础知识

网络嗅探（Sniffing）与 tcpdump 简介
- 嗅探原理： 简述网卡混杂模式（Promiscuous Mode）的概念，即允许网卡接收流经该网络接口的所有数据包，而不仅仅是发给本机的数据包。
- tcpdump 原理： 简述其作为基于命令行的网络数据包分析工具的作用，以及常用的过滤表达式（BPF，如 host、port、tcp 等）。
Web 访问与 HTTP/TCP 协议交互过程
- DNS 解析： 浏览器如何将域名（如 www.tianya.cn）转换为 IP 地址。
- TCP 三次握手： 客户端与 Web 服务器建立连接的过程（SYN $\rightarrow$ SYN+ACK $\rightarrow$ ACK）。
现代 Web 站点的分布式架构（重点核心）
- 多服务器响应原理： 解释为什么访问一个网站首页会涉及多个 IP。现在的网页包含了大量的外部资源（如图片服务器、CDN 加速节点、第三方广告联盟、外部 CSS/JS 脚本库等）。浏览器解析 HTML 源码后，会自动向这些不同的服务器发起连接请求。

2）Wireshark与Telnet协议分析的基础知识

Wireshark 工作原理与功能
- 简述 Wireshark 作为图形化抓包与协议分析软件的特点，特别是其强大的“协议解析（Dissection）”和“数据流重组（TCP Stream Tracking）”功能。
Telnet 协议及其安全缺陷
- 工作机制： 简述 Telnet 是一个基于 TCP 的应用层协议（默认端口号 23），用于提供远程登录和虚拟终端交互。
- 明文传输特性： 重点指出 Telnet 协议在传输用户名、密码及所有交互命令时，不进行任何加密。这也是为什么你能通过抓包直接看到账号密码的原因。
- 字符回显机制： 解释在 Telnet 登录时，客户端每输入一个字符，服务器如何回显，以及这些交互在数据包层面是如何体现的（通常一个字符对应一个 TCP 数据包）。

3）网络扫描与取证分析的基础知识

端口扫描（Port Scanning）的原理与分类
- TCP Connect 扫描（全连接扫描）： 攻击者完成完整的 TCP 三次握手。特点是准确但容易被日志记录。
- TCP SYN 扫描（半开扫描/隐蔽扫描）： 攻击者发送 SYN 报文，若目标回复 SYN/ACK（代表端口开放），攻击者随即发送 RST 报文断开连接；若目标回复 RST/ACK，则代表端口关闭。特点是速度快且隐蔽（通常也是 Nmap 的默认方式）。
如何通过数据包判定扫描工具（指纹特征）
- 解释不同的扫描工具（如 Nmap、Masscan 等）在发送探测包时有特定的“指纹”或行为模式。例如 Nmap 扫描前通常会进行主机发现（Ping 扫段、ARP 请求），并且其构造的 TCP 报文的窗口大小（Window Size）、TCP 选项（Options）具有特定特征。
如何通过响应包判断端口状态
- Open（开放）： 收到 SYN/ACK。
- Closed（关闭）： 收到 RST/ACK。
- Filtered（被过滤）： 没有收到响应，或收到 ICMP 目标不可达报文。

二、操作流程

2.1 tcpdump

2.1.1 实验目的

本实验旨在利用开源网络嗅探软件 tcpdump，对本机访问指定网站的过程进行流量捕获与分析。通过对捕获数据包的溯源，解答以下具体问题：

在访问网站时，浏览器将访问多少个 Web 服务器？它们的 IP 地址分别是什么？

2.1.2 实验工具与环境

操作系统与环境： 本地计算机（具备公网访问能力）
抓包工具： tcpdump（开源命令行网络嗅探工具）
应用层软件： Web 浏览器

2.1.3 实验步骤与数据分析

步骤一：确认本机网络接口与 IP 地址

在启动数据包嗅探之前，首先需要明确本机的网络配置环境，提取本机的 IP 地址，以便在后续的抓包日志中准确分离出双向通信流量。

在命令行终端中执行网络配置查看命令ifconfig：

经查询确认，本次实验中使用的本机内网 IP 地址为 172.16.230.202。

步骤二：部署监听与触发 Web 访问

在后台终端中启动 tcpdump 进程，针对相应的网络接口进行全流量监听。随后，在百度浏览器中任意打开一个网站

浏览器成功发起请求，并接收到目标服务器返回的网页响应数据。在此期间，tcpdump 持续捕获进出本机的网络数据包。

步骤三：停止嗅探与目标流量提炼（含问题解答）

网页完全加载后，停止 tcpdump 监听。针对捕获到的海量日志，以本机 IP (172.16.230.202) 为基准，过滤出本次 Web 访问相关的 TCP 数据流。

捕获到的核心通信日志如下：

通过对上述捕获日志中数据包报头的提取与整理，我们得到以下通信特征表，并据此直接得出实验结论：

数据包字段	捕获值记录	字段说明
源 IP 地址	`172.16.230.202`	发起访问的本机地址。
目的 IP 地址	`113.200.2.51`、`113.200.2.156`	本次通信指向的外部目标地址。
网络层协议	`IPv4`	数据包封装格式。
传输层协议	`TCP`	通信使用的传输层协议。
目的端口	`80`	指向目标服务器的 HTTP 服务标准端口。
源端口	`60372`、`60373`、`60380`、`60381`	本机建立多个并发连接时分配的随机高位端口。

本机产生的出站流量分别指向了两个不同的目标 IP，因此浏览器总共访问了 2 个 Web 服务器。这两个 Web 服务器的公网 IP 地址确切为：113.200.2.51 和 113.200.2.156。多个IP大概率是浏览器开启了CDN分流或者DNS负载均衡。

2.2 Telnet实验

2.2.1 利用水木清华

如下图所示，Telnet 连接建立后，终端界面出现了大量乱码。

这是因为 macOS 终端默认使用 UTF-8 编码，而许多早期 BBS 系统（如水木清华）通常采用 GBK 或 GB2312 编码。两者编码格式不一致，就会导致中文显示异常。
不过，这种乱码只影响字符显示，不会影响底层网络数据包的抓取与分析。

随后，切回后台运行的 Wireshark，在过滤栏中输入 telnet，即可快速筛选出本次会话的交互流量：

为了查看完整的通信内容，可以任意选中一个数据包，右键依次选择 追踪流（Follow）→ TCP 流（TCP Stream），即可还原整个交互过程：

2.2.2在云服务器上自行搭建 Telnet 服务

前面通过水木清华 BBS 完成了实验，但在抓包分析过程中发现字符重复现象比较明显。
因此我想到自己还有一台之前学生优惠购买的阿里云服务器尚未到期，于是决定在这台服务器上自行搭建 Telnet 服务，测试更换实验环境后现象是否会有所改善。

1. 安装相关服务

首先安装 Telnet 服务端及其依赖。

2. 配置 `inetd`

编辑 /etc/inetd.conf，写入以下内容：

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

3. 配置 `xinetd`

编辑 /etc/xinetd.conf，写入以下内容：

# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
    # Please note that you need a log_type line to be able to use log_on_success
    # and log_on_failure. The default is the following :
    # log_type = SYSLOG daemon info
    instances = 60
    log_type = SYSLOG authpriv
    log_on_success = HOST PID
    log_on_failure = HOST
    cps = 25 30
}

接着编辑 /etc/xinetd.d/telnet，增加如下配置：

# default on
# description: The telnet server serves telnet sessions; it uses
# unencrypted username/password pairs for authentication.
service telnet
{
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    server = /usr/sbin/in.telnetd
    log_on_failure += USERID
}

最后，在 xinetd.conf 中添加 includedir 行，确保子配置目录能够被正确加载：

# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
    # Please note that you need a log_type line to be able to use log_on_success
    # and log_on_failure. The default is the following :
    # log_type = SYSLOG daemon info
    instances = 60
    log_type = SYSLOG authpriv
    log_on_success = HOST PID
    log_on_failure = HOST
    cps = 25 30
}

includedir /etc/xinetd.d

这里最关键的有两点：

/etc/xinetd.d/telnet 中要将 disable 设置为 no；

/etc/xinetd.conf 中必须添加 includedir /etc/xinetd.d，否则 Telnet 子配置不会生效。

4. 开放服务器 23 端口

配置完成后，还需要在阿里云服务器安全组中放行 23 端口，否则外部主机无法建立 Telnet 连接。

5. 检查 23 端口是否开放

完成安全组配置后，可以先检查服务器的 23 端口是否已经成功开放：

6. 在服务器本地进行连接测试

在正式远程抓包之前，可以先在服务器本机上做一次连接测试，确认 Telnet 服务已经正常启动：

7. 本地抓包分析自建 Telnet 服务

确认服务正常后，先在 Wireshark 中启动抓包，再在本地终端中使用以下命令连接远程服务器：

telnet 47.104.236.198

连接过程如下图所示：

随后，在 Wireshark 中继续使用 telnet 作为过滤条件，即可快速定位本次会话的数据包：

继续通过 Follow → TCP Stream 查看完整会话内容，可以清楚地看到账号和密码在传输过程中是明文出现的：

这也正是 Telnet 协议最大的安全问题之一：
用户名、密码以及交互内容默认均以明文方式在网络中传输。
只要攻击者能够监听链路上的数据包，就有可能直接还原敏感信息。

2.3 取证分析实践

2.3.1 使用显示过滤器定位扫描流量

在进行网络流量分析时，首先需要从海量数据中筛选出可疑的扫描请求。请在 Wireshark 的显示过滤器输入框中输入以下表达式：

tcp.flags.syn == 1 && tcp.flags.ack == 0

** 原理说明：** 用于严格筛选出仅设置了 SYN 标志位而未设置 ACK 标志位的 TCP 数据包。这是攻击者在发起 TCP SYN 扫描（半连接扫描）时最典型的初始探测请求特征。

2.3.2 分析通信对与确认主机角色

应用过滤条件后，重点观察数据包列表中的 Source（源地址） 列和 Destination（目标地址） 列。可以明显发现，大量单向数据包密集集中在两个特定的 IP 地址之间。

根据流量“主动发起”与“被动接收”的特征，我们可以清晰地界定两台主机的角色：

角色分配	IP 地址	流量特征
攻击主机（扫描源）	`172.31.4.178`	高频、大量发送 SYN 探测请求的源头
目标主机（被扫描对象）	`172.31.4.188`	被动接收扫描请求的靶机

2.3.3 辅助验证：通过会话统计佐证

为了进一步验证上述两台主机之间通信的异常密集程度，我们可以借助 Wireshark 的全局统计功能来进行佐证：

操作路径： > 依次点击顶部菜单栏的 Statistics（统计） -> Conversations（会话） -> 选择 IPv4 选项卡。

在弹出的会话列表中，点击 Packets（数据包数量）进行降序排列。排在首位、包数最多的通信对，进一步坐实了上述两台主机的角色分配及异常交互行为。

2.3.4 探查目标主机的端口状态

在确认了攻击源与目标后，分析的重点转向扫描结果。我们需要观察目标主机对这些探测包的响应情况（如返回 SYN, ACK 还是 RST, ACK）。

梳理确认已开放的端口

通过追踪目标主机 (172.31.4.188) 成功返回了握手确认包的数据流，我们可以汇总出该靶机当前暴露在外网的监听端口：

** 最终确认目标主机开放的端口列表如下：**

21 (FTP), 22 (SSH), 23 (Telnet), 25 (SMTP), 53 (DNS), 80 (HTTP), 139 (NetBIOS), 445 (SMB), 3306 (MySQL), 3632 (distccd), 5432 (PostgreSQL), 8009 (AJP13), 8180 (HTTP-Alternate)

(注：从上述端口列表可以看出，目标主机同时暴露了数据库、文件共享、远程登录等多种高危服务，存在较大的安全面风险。)

关闭

ip.src == 172.31.4.188 && ip.dst == 172.31.4.178 && tcp.flags.reset == 1

2.3.5 判断 SYN 半开放扫描

SYN 半开放扫描（SYN Scan，又称 Half-Open Scan）是一种常见的端口扫描方式，其特点是：扫描端只发送 SYN 报文来探测目标端口状态，在收到目标主机返回的 SYN/ACK 报文后，并不会继续发送 ACK 完成三次握手，而是直接发送 RST 报文中断连接。
正因为没有真正建立完整连接，所以这种扫描方式相较于全连接扫描更加隐蔽，也更常被攻击者或扫描工具使用。

（1）扫描结果图

利用p0f工具进行扫描，可以看到扫描结果如下图所示，可以看到具体的扫描结果

（2）抓包关键过程分析

从该图可以看到，攻击主机首先向目标主机某一端口发送 SYN 报文，请求建立 TCP 连接。若目标端口开放，目标主机会回复 SYN/ACK 报文，表示该端口可以建立连接。

按照正常 TCP 三次握手流程，此时攻击主机应该继续回复 ACK 报文，完成连接建立；但在图中并没有看到完整握手被建立，而是出现了异常终止行为，这正是 SYN 半开放扫描的重要特征。

从该图可以进一步确认：在目标主机返回 SYN/ACK 之后，攻击主机并未继续完成三次握手，而是直接发送 RST 报文复位连接。这说明攻击者的目的并不是建立真正的通信连接，而只是通过目标主机的响应来判断端口是否开放。因此，可以据此判断该扫描方式属于 SYN 半开放扫描。

（3）判断依据总结

判断步骤	抓包现象	说明
第一步	攻击主机发送 SYN 报文	发起端口探测
第二步	目标主机返回 SYN/ACK 报文	说明目标端口开放
第三步	攻击主机发送 RST 报文	直接中断连接
最终判断	未完成三次握手	属于 SYN 半开放扫描

（5）SYN半开放扫描原理

（5）结论

综合扫描结果和抓包过程可以判断：攻击主机采用的是 SYN 半开放扫描，使用的工具是NMAP。

2.3.6 判断攻击主机的操作系统

在网络安全分析中，可以通过操作系统指纹识别技术来判断攻击主机的操作系统类型。常见的判断依据包括：TTL 初始值、TCP 窗口大小、TCP 选项字段排列、扫描工具的 OS Detection 结果 等。
不同操作系统在 TCP/IP 协议栈实现上存在差异，因此在抓包和扫描结果中会表现出不同的特征。

（1）扫描过程图

我们可以通过下列命令进行扫描

（2）操作系统识别结果图

下图给出了扫描工具对目标主机或攻击主机进行操作系统识别后的结果。通常，这类工具会根据主机返回的数据包特征，将其与已有的操作系统指纹库进行比对，从而推测出最可能的操作系统类型。从图中结果可以看到，系统识别结果偏向 Linux 2.6.x。

三、遇到的问题

3.1 mac在进行telnet的会出现乱码

3.2 字符重复的原因分析

在 TCP 流追踪界面中，可以看到输入的账号信息变成了类似 g gu ue es st t 这样的重复字符。
这一现象的根本原因在于 Telnet 的回显机制（Echo）。

可以通过下表理解这一过程：

环节	数据方向	现象	原因说明
客户端发送	本机 → 服务器	输入一个字符就立即发出一个数据包	当我们在终端中敲下 `g` 时，客户端会立刻将该字符发送给服务器
服务端回显	服务器 → 本机	服务器返回同样的字符	Telnet 默认通常不进行本地回显，需要由服务器把收到的字符原样发回，用于终端显示
Wireshark 聚合展示	双向合并显示	看起来像每个字符都被输入了两次	Wireshark 的 Follow TCP Stream 会按时间顺序拼接双向数据，因此“发送字符”和“服务器回显字符”会紧挨着显示

简单来说：
我们敲一次键，客户端发一次；服务器再回显一次。
Wireshark 把这两个方向的数据合并后展示，于是就形成了“字符重复”的视觉效果。

四、心得体会

实验心得体会

通过这次实验，我对网络攻防中“数据包抓取、协议分析、服务搭建与安全风险验证”这几个环节有了更加直观和深入的认识。以往在课堂上学习 tcpdump、Wireshark、Telnet 等内容时，更多停留在概念层面，知道它们分别用于抓包、分析协议和远程登录，但真正亲手操作之后，我才感受到这些工具在网络安全实践中的实际价值，也更加理解了“攻”与“防”往往都建立在对网络通信细节的深入掌握之上。

在 tcpdump 抓取 Web 访问流量的实验中，我最大的收获是理解了“访问一个网站并不只是访问一个服务器”这一点。以前我会下意识地认为浏览器打开一个网页就是和单一目标主机通信，但通过抓包发现，浏览器在访问网页时会同时与多个 IP 建立连接。这让我更加清楚地认识到现代 Web 服务通常具有分布式架构特征，网页背后可能涉及主站服务器、CDN 节点、静态资源服务器等多个实体。通过对抓包结果中源 IP、目的 IP、端口号和 TCP 通信过程的分析，我不仅学会了从大量原始日志中提取有效信息，也进一步理解了 TCP 在实际业务场景中的作用。这种从“看到流量”到“读懂流量”的过程，让我感受到网络协议分析并不是单纯看数据，而是一个从现象推导系统行为的过程。

在 Wireshark 对 Telnet 协议进行分析的实验中，我对“明文传输的风险”有了非常深刻的体会。教材中常说 Telnet 不安全，是因为用户名、密码和交互内容都会以明文形式在网络中传输，但只有当自己在抓包结果里真正看到这些内容时，这种风险才会变得非常具体、非常有冲击力。尤其是在追踪 TCP 流之后，能够直接看到完整的登录过程和会话内容，这使我真正意识到：如果通信协议本身不具备加密能力，那么攻击者只要有机会进行流量嗅探，就可能轻易窃取敏感信息。相比抽象地记住“Telnet 不安全”，这种通过实验亲眼验证后的认识更加牢固，也让我更加理解为什么在现代网络环境中，SSH 会取代 Telnet 成为远程管理的主流方案。

另外，这次实验中我还尝试在自己的云服务器上搭建 Telnet 服务，这一过程让我对“实验环境搭建”本身有了新的认识。相比直接使用已有平台，自己部署服务虽然更麻烦，但能够更全面地接触到系统配置、服务启动、端口开放以及云平台安全组策略等细节。这让我意识到，网络安全实验不仅仅是会使用某个工具，更重要的是理解整套环境是如何被配置和运行起来的。比如在配置 xinetd 和 inetd 时，一个小小的参数设置错误，或者遗漏 includedir，都会导致服务无法正常生效；而即使本地服务正常，如果安全组没有放行 23 端口，外部依然无法访问。这些问题说明，真实网络环境中的故障和安全问题往往不是单点造成的，而是系统配置、网络控制和服务行为共同作用的结果。

从攻防思维的角度来看，这次实验也让我进一步体会到“攻击者关注可见信息，防守者关注暴露面和风险点”的区别。对于攻击者来说，只要能够获取网络流量，就可能从中发现主机、端口、协议类型甚至账号口令等信息；而对于防守者来说，恰恰要尽可能减少敏感信息的明文暴露，关闭不必要的服务端口，避免使用存在明显安全缺陷的协议，并通过日志、加密和访问控制等手段提升防护能力。也就是说，同一份流量数据，对于攻方是情报来源，对于守方则是风险映射。这种双重视角使我对“网络攻防实践”这门课程的理解更加全面。

在实验过程中我也发现了自己的一些不足。比如面对抓取到的大量原始数据时，最开始我对信息筛选还不够熟练，需要花较多时间定位关键内容；在分析协议交互细节时，也容易只停留在表面现象，而没有进一步从协议机制层面深入思考。这说明我在今后的学习中还需要继续加强对 TCP/IP、应用层协议以及网络行为特征的理解，不只是会操作工具，还要真正具备解释现象、分析原因和发现问题的能力。

posted @ 2026-03-25 16:30 20253902吴晨宇阅读(40) 评论(0) 收藏举报

刷新页面返回顶部

wuuuu