1. FTP审计基础：协议、日志与审计概念
1.1 FTP协议的核心要点
FTP这东西，说白了就是文件传输的“老炮儿”。从1971年诞生到现在，还在大量使用。我见过不少人觉得它过时了，但在内网批量传大文件、设备日志备份、甚至工业控制系统里，FTP依然是主力。
FTP的核心就两个连接：
- 控制连接（21端口）：负责发命令，比如USER、PASS、LIST、RETR、STOR。它不走业务数据，说白了就是“指挥所”。
- 数据连接（20端口或随机端口）：真正传文件用的。嗯，这里容易搞混，因为有两种模式：主动模式和被动模式。
| 模式 | 建立方式 | 常见坑 |
|---|---|---|
| 主动模式（PORT） | 服务端主动连客户端的高位端口（20→客户端随机端口） | 客户端有防火墙时就拜拜了 |
| 被动模式（PASV） | 服务端开一个随机端口，客户端连过去 | 服务端防火墙得放开高位端口范围 |
1.2 审计日志的概念
审计日志是什么？就是记录“谁、在什么时间、从哪里、做了什么操作、结果如何”。对于FTP来说，这些信息都在日志里躺着。但关键问题在于——怎么把原始日志变成可追查的证据链。
FTP审计日志的核心字段：
- 时间戳（精确到毫秒，最好带时区）
- 客户端IP与端口
- 用户名（如果是匿名登录，就是anonymous）
- 操作类型（PUT/GET/DELETE/LIST等）
- 文件路径与文件名
- 传输大小与耗时
- 最终状态码（200成功？550失败？）
你想想看，如果这些字段不全，事后追查的时候你根本搞不清是谁传了什么文件。我在项目里见过一个经典案例：日志里只有IP和操作码，没有文件名，结果安全事件来了根本没法定位恶意文件——这就是典型的日志设计缺陷。
1.3 为什么FTP日志如此重要
说实话，很多公司对FTP日志的态度就是“能存就存，丢了拉倒”。但真出事了，例如内部员工泄露代码、外部攻击者偷走配置文件，日志往往是唯一的线索。
FTP日志的四大价值：
- 事中监控：实时发现异常行为，比如凌晨三点往海外IP传大文件。
- 事后追溯：出了事能还原整个攻击路径。
- 合规审计：很多行业标准（如等保2.0、SOX）明确要求保存文件传输日志不少于6个月。
- 故障排查：比如传文件老是断，日志能告诉你是不是超时还是被防火墙拦截了。
1.4 FTP审计与安全事件的关系
很多安全事件的入口就是FTP。为什么？因为FTP的认证方式太简单了，只有用户名和密码。如果密码弱，或者干脆就没禁掉匿名登录，那基本等于把服务器大门敞开。
典型的FTP攻击路径：
- 蠕虫扫描开放21端口的服务器
- 暴力破解弱口令（admin/admin、root/123456这种）
- 登录成功后，上传webshell或恶意脚本
- 或者直接下载数据库配置文件
这些攻击步骤，每一步都会在审计日志里留痕。但前提是你的日志配得够全、够细、够久。我记得有一次攻防演练，红队从FTP日志里发现了蓝队的一台备机IP——就因为他们日志里记录了尝试连接的源IP，而那个IP不属于任何已知设备。你说细节重要不重要？
下面这张图总结了FTP审计金字塔的关系：底层是原始日志，中间层是结构化记录，顶层才是我们真正需要的可解释的审计线索。
1.5 日志审计的基本概念
聊到这儿，我得把审计的三个基本概念说清楚：日志记录、日志分析、日志审计。很多人混为一谈，其实不一样。
三者区别：
- 日志记录：就是服务器吐出来的原始数据，存到文件或者数据库里。这一步只管“有没有记到”。
- 日志分析：对原始日志做格式解析、字段提取、统计报表。比如统计某用户今天传了多少个文件。
- 日志审计：在分析的基础上，对照安全策略或合规要求，去判断“这个行为是否合规、是否异常、是否需要告警”。这是更高一层的事。
说实话，很多公司在日志记录这一步就卡住了。比如vsftpd默认日志格式很简陋，只记录日期、IP、操作和文件名，连用户都不记——这种日志基本没法做审计。我建议至少要启用扩展日志模式，把所有字段都吐出来。