问题描述

某金融机构防火墙安全运维人员根据开发人员需求开通了一个目标端口是tcp 2000的网络权限，当天telnet测试成功。但是过几天开发人员反馈，地市机构他页面无法打开，但是可以telnet通。并将结果截图反馈回来，为分析清楚问题，求助于网络抓包人员进行分析。

图1 异常现象

分析过程

抓包人员根据开发人员描述，将访问过程用拓扑图描述如图2所示：

图2 访问网络拓扑
客户端可以telnet通F5设备的负载端口，同时在F5上查看存在相应会话，说明F5已经把请求转发到内部后台服务器，但是客户端发送HTTP的GET请求时，会超时。由于在客户端和服务器经过多道交换机、路由器、防火墙和F5设备，排查难度较大，但是因为有科来回溯分析系统，对防火墙、负载均衡和路由器前后进行多点部署，应该可以找到蛛丝马迹。
抓包人员首先在终端进行抓包，通过对终端进行抓包，发现可以通过TCP三次握手建立会话，如图所示：这就解释了为什么可以telnet成功。但是再仔细一看这个数据包交互过程，发现客户端发送了数据包请求，服务器回应了ACK，但是等待了10s，还是未见服务器发送数据包。

由于多处部署了科来回溯分析系统硬件设备，抓包人员充分利用该条件，将多处数据包综合进行分析。发现客户端发送的数据包在第I、II处均未看到该数据包，通过该数据包对比，可以清楚了，客户端可以telnet通2000端口，但是客户端发起HTTP请求的时候，被中间未知设备丢掉了。

那是哪里把这个应用数据包丢掉了呢？我们还是仔细回到图3中在客户端处数据包进行仔细研究。telnet可以通，三次握手可以建立，说明SYN+ACK包是F5设备回应的，但是后面应用数据包未到达F5设备，说明后面应用数据包的ACK是中间未知设备回应的，相当于中间设备做了一个应用代理，同时中间设备并未将应用数据包转发到F5，仔细检查SYN+ACK和应用ACK有什么不一样，我们发现除了TTL，其他基本是一样，SYN+ACK的TTL是53，而应用数据包ACK的TTL是60，说明中间设备和最终F5之间经过了7跳，同时根据在负载均衡前面抓包可以看到，负载均衡使用的默认TTL值是64。

根据不同操作系统默认TTL，可以大胆猜测中间设备使用的TTL是64（图6），那就是说，中间设备经过4跳到达客户端，那我们通过在客户端traceroute F5地址（图7），看经过4跳的后到达什么IP地址。


通过定位，我们确认第四跳就是X.X.X.254这个地址了，通过ssh 、telnet和http登录，最终发现该中间设备是Netscreen防火墙（图8）。

综合防火墙四层设备，最终可以判定是防火墙把应用数据包给代理了，并返回一个ACK，那防火墙为什么会这样干呢？通过想起来，是否2000端口为某些固定协议使用呢？通过搜索相关资料，知道2000端口被用于思科的SCCP，同时查看Netscreen防火墙，发现在防火墙上面开通了SCCP的应用级网关（ALG）功能（图9），那是不是该ALG导致TCP 2000端口应用数据被过滤了呢，本身开发人员仅仅需要一个TCP 2000的四层功能，但是ALG将该TCP 2000提升为七层，根据ALG应用简介：允许合法应用数据通过防火墙的平安检测，另外将严格限制不符合它有限过滤规范的运输流，可以确定是ALG罪魁祸首。将该ALG功能关闭，发现可以正常访问了，大功告成！！！

分析结论与解决方案

本案例中，由于客户端和服务器之间经过多道防火墙、防火墙、交换机、路由器和负载均衡，通过科来回溯分析系统进行多点部署回溯抓包对比分析，获取基础数据包文件。进一步采用TTL进行对比分析，发现路由跳数之间的不同点，可以发现为防火墙ALG将TCP 2000数据包丢弃。
根据以上分析，由于防火墙ALG功能，将TCP 2000强制为七层，导致访问异常。解决的方法固然有两种：一是关闭防火墙SCCP ALG功能，二是更换负载均衡服务端口。方法一中由于涉及到多道防火墙，而且不确定将来SCCP是否需要在网络中传输，所以采用第二种方法，即更换F5服务端口。