FTP服务器连接数突然暴涨，绝大多数时候不是业务量上去了，而是暴力破解、客户端重连失控和端口资源耗尽这三件事同时发生了。 连接数爆多只是表象，真正要命的是服务器被拖垮、正常用户挤不进来，今年的重点不是继续加连接数上限，而是把每一路连接当成一个真实访客，先查清楚它从哪来、想干什么,再决定放行还是拦截。
为什么FTP服务器好好的，连接数突然就爆了
FTP服务器的连接数并不会无缘无故增多，每一次连接背后都有明确的目的，只不过大部分“访客”既不想下载文件，也不打算上传资料，它们只想撞开大门。 站长的直觉往往是“是不是被攻击了”，但实际拆开连接日志,会发现情况更复杂。
暴力破解是连接数暴涨的第一大来源
攻击者会用字典库对FTP账号做循环尝试，每试一组密码就建立一次或多次连接，如果FTP服务器没有做失败次数限制及IP封禁,短时间内就会有成百上千个半开连接堆积在服务器上。
一位长期做运维的专家指出，对外暴露在公网的FTP服务器，平均存活时间不超过24小时就会收到第一轮扫描尝试，扫描工具的成本极低,但服务器为此承受的连接压力却很大。
平时连接数几百个不算稀奇，但如果用ss -atnp | grep 21 | wc -l查看，发现大量连接正处于SYN_RECV或ESTABLISHED状态，且来源IP分散,基本可以断定是撞库扫描。
客户端配置不当导致连接“自己给自己加负载”
很多内网用户习惯用FileZilla、FlashFXP这类客户端下载文件，默认设置是单文件多线程、无限重试，一旦网络出现抖动，客户端会自动重连,重连动作又会触发新的握手流程。
更常见的情况是大量客户端同时开启了“文件夹目录缓存”功能，每隔几十秒就重新请求一次目录列表，每次目录刷新就是一次数据连接建立，一栋办公楼里几十个用户这么干,服务器连接数轻松摸到几百。
主动模式下端口范围耗尽引发虚假连接堆积
被动模式（PASV）早已是主流配置，但仍有不少旧系统沿用主动模式，主动模式下服务器主动连客户端端口，如果客户端在NAT设备后面，握手会反复失败重试,每次失败都会在服务器端留下一个短暂的TIME_WAIT状态连接。
这个状态不占用户资源，但会堆积到系统连接数统计里，让你误以为“连接很多”，行业共识认为，设置FTP服务器时优先选择被动模式，并且把被动端口范围控制在
30000-40000这个区间,能减少大量无意义的连接残留。
Ftp服务器连接数量上限怎么设置，得看服务对象是谁
连接数上限是FTP服务器最核心的限制参数，但不同部署环境、不同使用人群，最优值差异很大，不能照搬网上的“默认500”,更不能直接设成10000图省事。
Linux下vsftpd的推荐参数组合
vsftpd里与连接数直接相关的参数有三个：
max_clients：全局最大并发连接数max_per_ip：单IP允许的最大连接数local_max_rate：单用户传输速率上限
实际配置中，max_per_ip的价值远高于max_clients，因为攻击流量通常集中来自少量IP,限制单IP连接数能直接切断暴力破解的通道。
推荐初始配置：max_clients=200，max_per_ip=5，等运行两周后看服务器负载和用户投诉，再逐步微调。如果配置了虚拟用户，还需要在/etc/vsftpd/vsftpd.conf里检查max_clients是否对所有虚拟用户全局生效。
修改完参数，执行systemctl restart vsftpd生效，同时观察/var/log/vsftpd.log里的断连记录，如果大量正常用户被拒，说明上限设低了，适当上调；如果日志里出现频繁的拒绝记录但业务不受影响,说明封堵策略有效。
Windows环境下的连接数审批逻辑
Windows上使用FileZilla Server的话，连接数限制写在“Edit-Settings-General”菜单里，核心是Max number of users，默认值是0（不限制）。
这里要特别注意：不限制不等于免费通行。 不限制连接数后，服务器内存和带宽会被毫无节制的连接耗尽，最终导致系统无响应，建议把Max number of users设置为100-300之间，同时启用No transfer timeout选项,避免空闲连接长时间挂着不释放。
Windows自带的IIS FTP连接限制藏在“FTP认证”和“FTP SSL设置”的父级菜单里，不如FileZilla直观，但小站点够用，IIS的瓶颈不在连接数，而在于工作进程回收机制，默认20分钟回收一次会导致长连接频繁断开，出现“连接被重置”的误报。
ftp服务器连接数太多怎么收敛，核心是分清正常与异常
连接数多不可怕，可怕的是不知道哪路连接是正常的。
收敛的前提是先把连接识别清楚。
用Netstat和ss命令快速定位连接来源
登录服务器执行：
ss -antp | grep :21 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
这行命令会把当前FTP连接按来源IP做统计排序，前几位就是“大户”。
如果前几个IP的连接数占整体的一半以上，且这些IP分布在不同网段、归属不同地区，大概率是扫描行为，如果连接数主要来自几个固定内网IP,则是客户端配置问题。
业务侧带宽表面的“假连接”
很多连接在ss输出里显示ESTABLISHED，但其实没有传输数据，这往往是客户端软件开启了“空闲等待”机制，每隔一段时间发送一次NOOP命令保持连接可用，几十个用户保持这种空连接,也占满了连接数上限。
应对办法是启用FTP服务器的空闲超时：
# vsftpd配置 idle_session_timeout=300 data_connection_timeout=120
这组配置表示空闲5分钟断开会话，数据连接2分钟没有任何动作就断开。结合之前提到的max_per_ip=5，能有效清除僵尸连接。
防火墙和账号权限的双重收敛
如果服务器直接暴露在公网,建议用防火墙限制FTP服务端口只能从公司出口IP访问。
iptables -A INPUT -p tcp --dport 21 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 21 -j DROP
账号权限的收敛同样重要，很多FTP目录本身就带有可写权限，攻击者一旦解开密码就能上传恶意文件，反向利用你的服务器对内网渗透，建议将FTP账号按部门或项目拆分，权限内容缩到最小目录，同时开启chroot限定用户只能在自家目录活动。
FTP服务器并发连接数狂涨时，硬件层面的应对
连接数上去了，CPU、内存、带宽的消耗跟着上，观察top输出和iftop的实时流量，如果CPU占用率接近拆分核心数，比如4核机器跑到90%以上,业务侧的收敛命令再快也赶不上新连接的涌入速度。
这时需要先做最后一道防线修改被动模式端口范围并限制并发传输速率：
pasv_min_port=30000 pasv_max_port=30050 anon_max_rate=1024000
pasv_max_port和pasv_min_port的差值建议在50到200左右，值越少，服务器建立的被动连接数越可控，这个操作能快速减少带宽压力,给排查留出时间。
如果是云主机，还可以登录云控制台，给FTP服务器加一个“安全组规则”，只允许指定IP访问21端口，这比服务器内的防火墙更靠近流量入口,拦得也更快。
让FTP服务器在纷杂链接里保持稳定的两个习惯
长期维持FTP服务器稳定运行,下面两个习惯值得保留。
定期查看日志，不做事后灭火
开设好FTP服务器后，每周花十分钟看日志,重点关注三类异常：
- 来自境外IP的反复登录失败
- 同一个账号在短时间内从多个IP登录
- 非工作时间段的批量文件下载
如果出现以上任意一种情况，建议直接封禁账号或IP，等到连接数爆了再处理,已经晚了。
连接数上限要动态调整，一次设置用终身的做法不可取
服务器配置会随业务、用户数量、带宽规模不断变化，建议每季度检查一次连接数设置，结合服务器实际负载调整数值。没有哪个固定数字是永远正确的，FTP服务器的健康状态是修出来的，不是设出来的。
FTP服务器常见连接问题速答
Q：为什么没人访问，服务器显示还有几十个连接？
A：大概率是FTP客户端的“自动重连”功能在起作用，如果客户端打开文件列表后关闭窗口，连接并没有立刻断开，而系统默认的CLOSE_WAIT要等几十秒才能释放，可以缩短idle_session_timeout到60秒,快速回收这类空闲资源。
Q：ftp服务器连接不上是什么原因导致的？
A：常见的三个原因依次是21端口没放行、被动模式端口被防火墙拦截、客户端与服务器时间差过大导致认证失败，逐一排查时，先用telnet 服务器IP 21看端口通不通，通的话再从客户端改用被动模式,并关闭系统自带的防火墙进行测试。
Q：并发连接数设置到多少才不会被攻击拖垮？
A：没有绝对防攻击的数字，更实际的思路是单独安装一个轻量级反向代理，前面学FTP协议，后面转发到真实的数据端口，这样攻击流量会被代理层吸收，核心FTP服务相对安全，如果不想用反向代理，那么max_clients=200和max_per_ip=5是小型业务稳妥的起步组合,等确认正常流量高于这个数值再往上加。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/580586.html
