晚上十点值班电话响了客户反馈FTP服务器上的ACL策略明明配好了可非办公区的电脑还是能连上去传文件。我到现场一看ACL已经下发到接口规则也写在明面上逻辑看着没问题。问题就出在FTP这个协议不是一条连接那么单纯——很多网工在ACL限制FTP访问权限这件事上栽跟头通常不是ACL语法不会写而是没有把FTP的双通道机制和流量路径搞清楚。这篇文章写给两类人一类是刚接触华为/华三设备、想通过ACL给内网FTP服务器做访问控制的网工另一类是已经配了ACL但发现“单向访问不管用”“数据通道防不住”的排错玩家。我会从FTP协议本身的坑讲起给出一套可落地的配置步骤和完整的排错链路最后聊聊ACL之外FTP安全还缺什么。1. 先从FTP的双通道机制说起ACL限制FTP绕不开的底层逻辑1.1 为什么FTP的“访问权限”比HTTP难管HTTP很简单客户端发请求到服务器的80端口服务器从同一个端口回数据一来一回都是一条TCP连接。你限制访问某个网站ACL只需要盯住源地址和目的端口80就行。FTP完全不是这个套路。一个FTP会话至少包含两条TCP连接控制连接客户端主动连服务器的TCP 21端口所有登录指令、目录列表指令都走这条通道。数据连接真正传文件内容的那条连接端口取决于工作模式。打个比方FTP的21端口是“前台接待”你打电话先约好要什么东西数据端口是“仓库发货口”货从另一个地方直接出去。很多ACL策略只封了前台忘了仓库发货口结果客户照样能拿到货。这就是为什么ACL限制FTP访问权限不能只想着“限制21端口”核心难点在于数据连接的目标端口在一个FTP会话里是动态变化的传统ACL如果不做端口范围固化根本没法精确匹配。1.2 主动模式和被动模式下的数据端口差异FTP有PORT主动模式和PASV被动模式两种工作模式ACL设计必须区分对待主动模式PORT流程客户端向服务器21端口发起控制连接登录成功后客户端告诉服务器“我在某个端口等你”然后服务器从自己的20端口主动向客户端的指定端口发起数据连接。被动模式PASV流程客户端向服务器21端口发起控制连接登录成功后客户端发PASV命令服务器返回一个随机的数据端口比如40123客户端再去连接服务器的这个端口来传数据。区别一句话总结主动模式是“服务器连客户端”被动模式是“客户端连服务器”。企业内网环境里FTP服务器绝大多数配置为被动模式因为如果服务器在NAT或防火墙后面主动模式的“服务器外连”几乎必被防火墙拦。这就意味着ACL要限制的重点变成了“客户端主动访问服务器的高端口”这个高端口的范围就是ACL规则里最关键的可变因素。1.3 “配了ACL不管用”的根因数据链路根本没走你限制的那条路很多网工在eNSP或真实设备上配好ACL后发现非授权网段照样能访问FTP第一反应是“ACL是不是没生效”但根因往往不是ACL没生效而是限制的路径不对。标准ACL只匹配源IP时它作用在接口上后能挡住非授权网段对21端口的连接请求。但被动模式下客户端登录成功后从控制连接里拿到数据端口号如果ACL没有针对这个数据端口做限制客户端直接连数据端口就能传输文件。在华为设备上表现得尤其典型你配了rule 10 deny source 192.168.100.0 0.0.0.255非授权PC访问21端口被拦但假如在ACL生效之前就建立了控制连接或者数据连接里的目的端口根本没被ACL检查文件传输照常发生。碰到这种问题先别急着怀疑设备先看数据端口。2. 配置ACL之前的三件事模式确认、端口固化、位置选择2.1 第一件事确认FTP服务器工作在什么模式如果你连FTP服务器的工作模式都没确认ACL配置就是在蒙着眼睛开车。确认方法很简单在FTP客户端连接服务器时抓包看服务器返回的响应。协议交互长这样 PASV 227 Entering Passive Mode (192,168,20,10,156,49)最后两个数字156,49代表数据端口号计算方式是156 * 256 49 39985。看到227响应说明服务器工作在被动模式数据端口是39985。如果看到的是类似PORT 192,168,10,5,171,17的命令则是主动模式服务器会从20端口往外连ACL限制思路完全不同。Windows IIS自带FTP、FileZilla Server、Linux的vsftpd绝大多数默认启用被动模式且被动端口是动态范围。这一步确认做完你才知道ACL需要放行的端口池是多少。2.2 第二件事把被动模式端口范围固化成一个窗口ACL用端口段匹配时端口范围越精确越好。很多FTP服务器默认被动端口范围是1024-65535甚至直接用系统随机端口这种范围对ACL来说几乎没法封堵——你不能为了放FTP数据流把上千个高端口全部放给某个网段那和裸奔没有区别。所以在配ACL前一定要去FTP服务器端把被动端口固化到一个小窗口。FileZilla Server配置被动模式进入“被动模式设置”填写端口范围40000-40099。 vsftpd的配置文件加两行pasv_min_port40000 pasv_max_port40099Windows IIS FTP如果用的是内置被动端口范围需要在IIS管理器的“FTP防火墙支持”里设置数据通道端口范围。这个窗口多大合适取决于并发文件传输数量。一个数据连接占用一个端口100个并发就需要至少100个端口窗口。内网办公场景开100个窗口通常足够溢出如果大规模并发建议配合服务器端限制会话数一起考虑。为什么要固化因为ACL里可以这样写放行源地址为办公网段、目的地址为FTP服务器、目的端口为40000-40099的TCP流量。窗口不固化这条规则就是空谈。2.3 第三件事选ACL类型和应用位置华为/华三设备上ACL有两类常用类型标准ACL编号2000-2999只能匹配源IP地址适合粗粒度控制“哪个网段能访问FTP服务器”。优点是简单、CPU压力小缺点是无法精确到端口同一网段内所有流量都会被放行或拦截。扩展ACL编号3000-3999可以同时匹配源IP、目的IP、协议类型、目的端口适合精确控制FTP的21端口和被动端口池。我的建议是企业场景优先扩展ACL因为你需要同时限制21端口和40000-40099的数据端口标准ACL完全做不到端口级控制。只有当需求简单到“只允许某个网段访问服务器、网段内其他流量也已经管控”时标准ACL才够用。应用位置也很讲究。常见的应用方式是在服务器所在VLAN的三层接口VLANIF上做traffic-filter inbound还能在服务器接入的二层物理口上做接口ACL。如果你打算只限制跨网段访问把ACL挂到VLANIF的inbound方向即可如果服务器和客户端在同一VLAN内注意二层转发流量不会经过VLANIF的traffic-filter必须把ACL挂到接入端口或网关下的其他位置。3. 以华为/华三设备为例的ACL配置实战从网段限制到端口级限制3.1 最简单的网段级限制标准ACL配置假设FTP服务器IP是192.168.20.10允许办公网段192.168.10.0/24访问其他网段全部禁止。用华为VRP语法acl number 2001 rule 5 permit source 192.168.10.0 0.0.0.255 rule 10 deny source any quit interface Vlanif20 traffic-filter inbound acl 2001 quit华三Comware体系语法略有差别acl basic 2001 rule 0 permit source 192.168.10.0 0.0.0.255 rule 5 deny quit interface Vlan-interface20 packet-filter 2001 inbound quit必须说清楚这个方案的局限它只限制“从哪里来”不管“到哪个端口去”。如果办公网段里某台机器被攻陷攻击者可以用这台机器作为跳板访问FTP服务器如果非授权网段内的PC借用办公网段的源IP比如改地址也能蒙混过关。标准ACL适合快速止血不适合精细控制。3.2 端口级精确控制扩展ACL同时限制21和被动数据口在FTP被动模式端口已固化为40000-40099的前提下配置扩展ACLacl number 3001 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 21 rule 10 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port range 40000 40099 rule 100 deny ip quit interface Vlanif20 traffic-filter inbound acl 3001 quit解释一下三条规则的含义rule 5允许办公网段访问FTP服务器的21端口建立控制连接。rule 10允许办公网段访问FTP服务器的40000-40099端口建立数据连接。rule 100其余流量全部丢弃。不写这条也行华为ACL末尾隐含deny all但写出来便于后续排错时看命中次数。如果FTP服务器上还开了其他服务比如SSH或RDP不要让这些端口被ACL放行通道一并放掉。ACL匹配规则只针对这两个目的端口做白名单其他端口默认丢弃是更稳妥的安全姿态。3.3 配置下发与方向核对别把inbound和outbound搞反ACL的inbound和outbound方向理解是新手最容易出问题的地方。以服务器所在VLANIF的traffic-filter inbound为例它过滤的是“从客户端进入这个三层接口的流量”。从PC发往FTP服务器的报文在进入VLANIF时就被匹配服务器回给PC的报文如果没在outbound方向做限制会被交换机正常转发。很多人在排“FTP能登录但打不开目录”时发现数据连接的返回报文被拦了。原因往往是他们把同一份ACL既挂在inbound又挂在outbound而ACL里没有放行服务器返回给办公网段的流量。服务器从40001端口回包给PC源IP是服务器IP目的IP是PC IP如果outbound方向的ACL只有“办公网段访问服务器”的规则返回报文不匹配就会被deny掉。正确做法通常是入方向做源地址和目的端口的白名单出方向保持默认放行。防火墙有状态检测有去就有回交换机的traffic-filter没有状态检测必须人为保证对称性。如果你确实需要在出方向也做ACL应该单独写一条放行“源地址为FTP服务器、目的地址为办公网段”的返回流规则。3.4 设备自身的FTP管理通道另一个容易忽略的场景我们前面讨论的是“限制别人访问FTP服务器”。但还有一种场景限制别人通过FTP协议登录交换机/路由器本身来管理设备。这个场景用的不是接口traffic-filter而是设备自身的FTP服务ACL。华为和华三设备都支持类似下面的配置把FTP管理源限制在管理网段acl number 2002 rule 5 permit source 192.168.10.0 0.0.0.255 rule 10 deny quit ftp server acl 2002命令细节在不同版本里略有差异但核心逻辑一致给设备自身的FTP服务绑定一个源地址ACL只有管理网段能登录设备传配置文件。如果不限制设备管理IP暴露在内网任何网段都能被FTP登录配合弱口令就是灾难。4. 排错实录配了ACL之后FTP仍然能访问的完整排查链路4.1 现象一ACL没命中流量从二层直接绕过了三层过滤客户报障“ACL配了、非授权网段还是能访问FTP”。我到现场第一件事先不看ACL规则先看拓扑FTP服务器和客户端是不是在同一个VLAN里。如果是问题已经找到一半。交换机上VLANIF的traffic-filter只过滤三层转发的流量而同一VLAN内的PC和服务器通信报文在交换机内部直接二层转发根本不经过VLANIF接口。ACL挂在VLANIF上自然永远不被命中。这个问题在真实网络和eNSP模拟器里都很常见。排查方法display acl 3001看规则后面的命中次数。如果所有规则后面都是0再结合“同一VLAN互访”的拓扑判断基本可以确认流量走了二层。修复方式把ACL下推到服务器接入的物理端口例如interface GigabitEthernet0/0/1 traffic-filter inbound acl 3001 quit这样无论客户端和服务器是否同一VLAN只要进到服务器这个端口都要被ACL检查。代价是这个端口上所有发往服务器的流量都要被匹配一遍注意规则顺序不要误伤正常管理流量。4.2 现象二控制连接被放行、数据连接被拦截表现为“登录成功但列表不出来”这是FTP被动模式下最经典的ACL问题。客户端能登录能输入用户名密码但一执行LIST或下载文件客户端就卡住过一会儿超时。抓包看交互会看到服务器返回了227响应里面携带着数据端口比如(192,168,20,10,156,41)算出端口是40041。然后客户端发SYN到服务器的40041端口——如果ACL只放行了21端口没有放行40000-40099这个SYN包就会被末尾的deny丢弃数据连接永远建立不起来。排查方法依然看ACL计数display acl 3001如果发现rule 10 permit tcp ... destination-port range 40000 40099的命中次数始终是0而rule 100 deny ip在快速增长基本可以确认数据端口池没有对上。去服务器端看被动模式实际分配的端口和ACL放行范围做比对。还有一种更隐蔽的情况ACL放行的端口范围是对的但FTP客户端没有使用被动模式而是用了主动模式。主动模式下数据连接从服务器20端口发起如果服务器侧ACL只放行办公网段到服务器的流量服务器往客户端方向回包就可能被回程ACL拦掉。这时候需要检查客户端软件传输设置把主动模式改成被动模式或者在服务器侧放行20端口的出方向流量。4.3 排错工具组合display acl display traffic-filter 抓包验证遇到ACL相关故障我的固定排错三板斧display acl 3001看规则命中次数明确哪条规则在实际起作用。display traffic-filter applied-record或display packet-filter确认ACL真正下发到了哪些接口、哪个方向防止配置写到接口但没下发成功。抓包在FTP服务器侧抓包重点看SYN包是否到达服务器网卡。如果交换机ACL已经把SYN丢弃服务器侧抓不到任何连接尝试如果服务器侧能看到TCP SYN说明ACL没有拦到这个方向的流量。抓包时用Wireshark过滤规则写tcp.port 21 || tcp.port 40000 tcp.port 40099重点关注是否有来自非授权网段的SYN报文。如果有SYN到达但服务器没响应说明ACL没问题是服务器本身或中间链路的问题。4.4 修复与验证的完整流程不管故障根源在哪修复后一定要按下面这个清单做回归验证缺一项都不算闭环授权网段PC能登录、能列目录、能上传下载文件。非授权网段PC不能登录任何端口都无法访问FTP服务器。授权网段PC主动模式下同步测试是否恢复正常如果不支持客户端切换被动模式。服务器侧查看被动端口使用范围确认40000-40099内的端口正常分配。查看ACL命中计数确认permit规则有增长、deny规则拦住了非授权流量。另外提一个经常被忽略的分支如果客户端是Windows且报错类似“failed to start login server: 以一种访问权限不允许的方式做了一个访问”别光盯着交换机ACL。这个错误通常是Windows本地防火墙拦截了FTP客户端进程或者FTP客户端所需的端口被本地策略禁用。排查时先把本机Windows防火墙临时关闭测试一下能连上就说明是客户端本机策略问题和网络ACL无关。5. 除了ACLFTP访问控制还需要补齐的几块短板5.1 弱口令和明文传输怎么处理ACL解决了“谁能访问FTP”的问题但没有解决“口令是否安全”和“传输是否加密”的问题。FTP协议本身是明文传输用户名密码在网络上抓包就能看到。ACL把访问源限制到办公网段后攻击面小了但内网中如果有一台主机被控制照样能通过抓包获取FTP口令。对付弱口令建议顺序如下禁止匿名登录强制强密码策略。开启登录失败锁定连续失败5次锁定账号10分钟。对FTP服务器做源地址白名单和ACL里允许访问的网段保持一致。传输敏感文件时优先使用FTPS或SFTP。ACL承担“门禁”职责但这些服务器侧的加固措施才是真正的“保险柜”。门禁再严保险柜密码是123456一样危险。5.2 FTP监控与登录审计的配合ACL不会告诉你谁在尝试登录FTP但它能通过deny规则的命中次数告诉你“有人在被限制的网段尝试访问”。把这些数据接进监控体系能发现很多异常。华为设备上定期查看ACL命中计数是一个朴素但有效的监控手段display acl 3001在服务器端配合看日志Windows IIS的FTP日志、vsftpd的日志里面记录了每次登录尝试的IP、用户名、成功与否。把这些日志汇聚到日志平台设置告警规则比如“10分钟内同一源IP登录失败5次”自动触发告警配合ACL的deny命中变化基本能及时发现扫描行为。5.3 长期演进用FTPS/SFTP替代FTP的过渡思路ACL限制FTP只是第一步如果业务允许我建议尽早规划向FTPS或SFTP迁移。FTPS是FTP over SSL端口通常是990隐式或21显式改动最小SFTP是SSH协议族的一部分走22端口服务器和客户端支持都很好。迁移期间可以先用ACL把FTP限制在内网公网访问一律走隧道或跳板再逐步把内部客户端的连接方式切换过去。如果你用的是飞牛OS这类NAS设备设置FTP后同样建议把公网端口映射收掉只保留内网访问必须公网访问时优先用NAS自带的WebDAV/TLS或SFTP而不是把FTP直接暴露出去。家庭和小型办公场景没有企业级交换机ACL能做的有限更多要靠服务端配置和路由器端口策略来完成访问控制。最后说一点个人体会ACL限制FTP访问权限这件事表面上是几条配置命令实际考验的是对FTP双通道工作原理的理解。我见过太多人在ACL规则里纠结得与失最后发现数据通道端口没固化、ACL位置挂错、方向搞反——只要先把被动端口池固化、再把源地址白名单和端口白名单组合好这个需求其实很简单。真正用心做完一次后面再遇到类似的需求基本就是按模板五分钟搞定的事。