FTP 抓包分析实战，命令、被动主动模式要点、FTPS 与 SFTP 区别及真机取证流程

FTP 仍然广泛用于文件传输与设备上报，但它既有明文传输的一面，也有通过 TLS/SSH 加密的多种变体（FTPS、SFTP）。抓包分析 FTP 问题时，需要对协议的控制/数据通道、主动（PORT）与被动（PASV）模式、以及中间网络（NAT、ALG、防火墙）对端口的影响有清晰认识。下面给出工程化的排查流程、常用 tcpdump / wireshark 命令、典型故障定位方法，以及在移动真机或代理受限时的补救方案。文章以实战为导向，便于工程师直接套用。

一、先理解 FTP 的两个通道与模式

控制通道（默认 TCP/21）：传输命令（USER/PASS/PASV/PORT/RETR/STOR 等），通常为明文或用 TLS 加密（AUTH TLS）。
数据通道（任意端口或被动分配端口）：实际传输文件或目录列表。
主动（PORT）模式：服务器向客户端指定端口发起连接（客户端需能被服务器访问）。
被动（PASV）模式：客户端向服务器请求一个端口，随后由客户端连接该端口（更适合 NAT/防火墙环境）。

二、抓包前的准备与采样策略

明确抓点：优先在最接近问题的一端抓包（客户端或服务器），复杂场景做双端抓包以比对。
snaplen 必须为 0：完整包是后续重组与文件恢复的前提。
过滤表达式：先抓控制通道（port 21）确认交互，再抓与 PASV/PORT 响应对应的数据端口。
时间同步：NTP 同步便于把 pcap 与日志对齐。

示例抓控制通道与主机 10.0.0.5 的 tcpdump：

bash 复制代码

sudo tcpdump -i any host 10.0.0.5 and port 21 -s 0 -w ftp_ctrl.pcap

若怀疑被动数据端口范围（如 50000-51000）：

bash 复制代码

sudo tcpdump -i any host 10.0.0.5 and portrange 50000-51000 -s 0 -w ftp_data.pcap

三、用 Wireshark 快速定位关键信息

显示过滤器 ：ftp（解析 control 协议）、tcp.port==21、或 ip.addr==10.0.0.5 && tcp.port>=50000 && tcp.port<=51000。
Follow TCP Stream：在控制通道上用 Follow TCP Stream 可以看到完整的 FTP 命令交互（包括 PASV 返回的 IP:port、PORT 指令的数据）。
查看 PASV/PORT ：PASV 的响应通常是 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)，数据端口 = p1*256 + p2。PORT 指令则包含客户端提供的 IP/port。
提取文件：若是明文 FTP，数据流可直接用 Follow TCP Stream 导出二进制并保存为文件；Wireshark 也可导出对象（File → Export Objects → FTP）。

四、FTPS（FTP over TLS）与 SFTP（SSH）注意事项

FTPS (implicit/explicit)
- Explicit FTPS（FTP over TLS，AUTH TLS，在控制通道 21 上先明文再升级到 TLS）------如果控制通道被 TLS 加密，你将看不到 PASV/PORT 命令，无法直接知道数据端口，除非在服务器端或客户端拿到会话密钥进行解密（通常不可行）。
- Implicit FTPS（通常在 990 端口直接 TLS）------同样会隐藏控制明文。
SFTP（基于 SSH，端口 22）不是 FTP 协议的变体，所有会话都在 SSH 隧道内，必须使用 SSH 级别的密钥或服务器日志来定位/审计，不能像明文 FTP 那样直接从 pcap 中恢复文件。

对策：若面对 FTPS/SFTP，优先在可控测试环境：

在服务器上启用会话密钥记录（若可行）或临时使用测试证书以便代理解密；或
在应用层（服务器日志、应用端）收集会话信息；或
在无法修改的真机场景下，采用设备侧抓包并与服务端日志比对 ClientHello/Certificate/Alert，确认握手层次问题。

五、常见故障与定位方法

目录列表（LIST）能返回但文件传输失败
- 多半为数据通道被防火墙阻断或 PASV 端口范围未放行。排查：查看控制通道的 PASV 响应并在网关上允许该端口范围；用 tcpdump 抓对应端口看是否 SYN/ACK 完成。
客户端报 425 Can't open data connection / 426 Connection closed
- 表示数据通道建立失败。查看控制通道是否有 PORT/PASV 命令及其参数，并抓数据端口的 SYN 包确认是否到达。
被 NAT 或 FTP ALG 破坏
- 某些 NAT/ALG 会篡改 PASV 返回的 IP 或端口；对比客户端看到的 PASV 信息与服务器实际返回的包，以判断是否被中间设备修改。多点抓包（客户端侧与服务器侧）能很快定位是否存在中间变换。
FTPS 握手失败 / 证书异常
- 在控制通道观察 TLS Alert（如 certificate_unknown），或利用 openssl s_client -connect host:990 / -starttls ftp 做手工握手测试以获取证书链信息与错误细节。

示例 openssl 命令（explicit FTPS）：

bash 复制代码

openssl s_client -connect ftp.example.com:21 -starttls ftp

六、自动化与批量分析建议

用 tshark 提取 PASV 返回与端口：

bash 复制代码

tshark -r ftp_ctrl.pcap -Y ftp.response.code==227 -T fields -e ftp.response

用脚本统计 425/426/550 等 FTP 错误码的出现频率并报警。
若需恢复明文文件，写脚本解析 Follow TCP Stream 输出并把数据部分保存为二进制文件，或使用 Wireshark 的 Export Objects→FTP。

七、移动真机/代理受限时的补救（务必合规）

移动端 FTP 客户端或设备常在受限网络或启用证书 pinning 时无法用桌面代理抓到完整交互。工程实践中的稳妥办法是：从设备侧抓取原始网络包然后与服务器侧 pcap 对比。在无法安装代理或不能修改 App 的场景下，把设备侧抓包作为标准证据流程：

将设备与开发机 USB 直连，使用可做设备侧抓包的工具抓取该 App 的流量（包括控制与数据通道）。在此类场景里，像 抓包大师（Sniffmaster） 这样的工具可以按 App 精确抓包并导出 pcap，无需在设备上安装代理证书或越狱。
导出后在 Wireshark 中对控制通道做 tls/ftp 分析，或直接在明文 FTP 情况下导出数据流恢复文件。
将设备侧 pcap 与服务端 pcap 对齐，比较时间线和五元组，定位是否为 NAT、运营商中间件或客户端配置导致的问题。

注意：设备侧抓包会包含敏感数据（用户名、密码、文件内容），采集与保存前务必征得授权并做脱敏与受控保管。

八、实战小结（排查模板）

抓控制通道（port 21）并用 Follow TCP Stream 观察命令交互。
根据 PASV/PORT 响应定位数据端口并抓取对应端口流量。
若数据通道未建立，检查防火墙/NAT/ALG，做多点抓包对比。
面对 FTPS/SFTP，转向服务端日志、openssl 手工握手或设备侧抓包比对 ClientHello/Certificate。
在移动真机或代理无能为力时，用设备侧抓包工具（抓包大师 Sniffmaster）导出 pcap，与服务端证据联合分析，得出可靠结论后再实施修复（放通端口、修复 NAT、调整被动端口范围或更新证书等）。