2023年夏天，授权我在一个攻防演练项目里碰到一台暴露在公网的访问服务器。打开浏览器，漏洞输入 ftp://x.x.x.x，授权回车。访问没有弹窗，漏洞没有登录框，授权直接列出了根目录下的访问所有文件——backup.sql、config.php.bak、漏洞整个 www 目录的授权压缩包。那一刻我就知道，访问这台机器已经不属于它自己了。漏洞

这就是授权FTP未授权访问。不是访问漏洞CVE里那种需要精心构造payload的攻击，它甚至算不上"攻击"——你只需要知道目标IP，漏洞然后用浏览器或者一条 ftp 命令连上去。服务器会热情地告诉你：欢迎，请随便看。

问题出在FTP协议本身的设计年代。1971年诞生的东西，那会儿ARPANET上都是互相认识的大学和军方节点，没人想过要在协议层面强制认证。匿名访问（anonymous）甚至是FTP的一项功能，本意是让管理员开放公共文件下载。但配置失误的时候，匿名用户的权限可能跟管理员差不多。

常见的翻车姿势有几种。一种是管理员在 vsftpd.conf 里写了 anonymous_enable=YES，同时又给了 anon_upload_enable=YES 和 anon_mkdir_write_enable=YES。匿名用户不光能看，还能传文件、建目录。更离谱的是 anon_root=/，直接把整个文件系统挂出去。另一种是 ftpusers 和 user_list 文件没配好，系统账号（比如 root、www）可以通过FTP登录，密码就是系统密码。还有一种是FTP服务跟Web服务共用目录，FTP能写，Web能解析，等于给webshell开了后门。

我见过最夸张的一台机器，FTP根目录直接指向了 /home。匿名登录后，每个用户的 .ssh 目录都躺在那里，id_rsa 私钥文件权限是644。下载下来，直接SSH登录，全程不到三分钟。服务器管理员大概一直以为FTP只是个"内部文件共享工具"。

怎么发现这类问题？最直接的方式是用 nmap 扫21端口，然后跟一个 ftp-anon 脚本：

nmap -p21 --script ftp-anon <target>

如果返回 Anonymous FTP login allowed，基本就确定了。接下来用 ftp 客户端连上去，试试 ls、cd，看看能走多远。有时候匿名用户被限制在某个目录，但那个目录里放着数据库备份或者源码压缩包，照样致命。

修复这件事其实不复杂。不需要匿名访问就直接 anonymous_enable=NO。需要匿名访问的，把 anon_root 指向一个专门的、干净的目录，权限设为只读。检查 ftpusers 和 user_list，确保系统账号不能登录。如果FTP和Web同目录，把上传目录的执行权限去掉，或者干脆用不同的目录。再狠一点，把FTP换成SFTP，21端口直接关掉。

但现实是，很多老系统还在跑FTP，因为"一直这么用的"。工控网络、内部文件服务器、甚至某些云服务商的默认镜像里，FTP服务开着，匿名访问开着。没人注意到，直到有人用浏览器打开了那个地址。

我后来在Shodan上搜了一下 port:21 anonymous，结果数量让人不太舒服。那些IP背后是真实的服务器，真实的文件，真实的数据。它们就那样挂在网上，等着被 ls 一下。