1 情况概述

\r\n
1.1 拓扑结构
\r\n

\"点击查看原图\"

\r\n

   如上拓扑所述，省厅A的客户端1和客户端2属于两个不同的安全域，通过防火墙代理，经过互联网，访问省厅B一台层层安全防护的预算系统服务器。

\r\n

1.2 情况简介

\r\n

\r\n

   预算系统分别使用B/S、C/S架构对外提供服务，服务端域名是xxx.com，解析后的公网IP分别是X.X.X.155和X.X.X.22，浏览器访问比客户端访问多一个get请求。据反映，该系统在省厅A内网无法正常使用，有个别单位同省厅A现象一样，其他用户使用各自的网络访问该系统都正常，无其他异常现象。

\r\n

1.3 分析思路

\r\n

   根据拓扑结构与情况简介，判断该异常现象不属于全局故障，针对个别网络无法正常使用该系统的问题，大致的处置思路如下：

\r\n

   在省厅A抓包对比分析，位置分别是客户端1与出口防火墙外网口，通过对比可以发现客户端1请求的数据包有没有到达公网，服务器应答的数据包有没有一个不少的返回客户端。从而发现问题出在哪里，例如：

\r\n

   A 客户端1请求的数据包没有到达公网，说明问题出在省厅A内网；

\r\n

   B 服务器返回的数据包防火墙公网口接收到了，但是客户端1没有接收到，说明问题出在省厅A内网；

\r\n

   C 出口防火墙公网口没有收到服务器应答的数据包，说明问题和省厅A无关。

\r\n


\r\n

\r\n

   如果故障现象和省厅A无关，协调省厅B，在服务器端抓包，检查服务器回应了客户端1的请求还是没有回应，从而发现问题出在哪里，例如：

\r\n

   A 服务器收到了客户端1的请求并进行了回应，但省厅A出口防火墙公网口没有收到该回应，那么需要逐个分析是否是服务器的安全软件或省厅B的某个安全设备对回应的数据包进行了过滤；

\r\n

   B 服务器没有收到客户端1的请求，但在省厅A出口防火墙的公网口发现该请求包已经出去了，那么需要逐个分析是否是服务器的安全软件或省厅B的某个安全设备对请求的数据包进行了过滤。

\r\n

2 登陆预算系统异常分析处置

\r\n

2.1 测试访问

\r\n

\"点击查看原图\"
\r\n

\r\n
   省厅A内网中客户端1分别使用浏览器与客户端进行访问测试，浏览器可以正常打开登陆页面，输入账号密码点击登陆时会出现如上图的故障现象，与客户端登陆故障现象一致，客户端1使用手机共享的4G网络，分别使用同一个浏览器和同一个客户端进行测试，则可以正常访问与登陆。如下图所示：
\r\n
\"点击查看原图\"
\r\n
\r\n

   打开登陆页面正常，由此可证明数据包没有被网络层拦截，登陆会提交POST表单，表单数据属于应用层数据，会被安全软件或安全设备的应用层策略匹配。

\r\n

2.2 客户端数据包分析

\r\n

\r\n

\r\n

   由于该故障现象从客户端的报错信息来看无法检查出具体的原因，又因为中间设备过多，先检查中间设备的日志、策略就会显得盲目没有针对性而且不效率，所以根据分析思路，在客户端1和出口防火墙公网口进行抓包，确定故障范围。

\r\n

\"点击查看原图\"
\r\n

\r\n

   客户端x.x.x.204与服务端x.x.x.22通过28361、28362、28363包建立3次握手。随后发送了28364包进行POST请求（登陆动作）并通过28365包向服务器确认该包有数据不放入缓冲区直接进行处理，在28403包中可以看到“服务器端”确认收到了客户端1的POST请求（28364包），在数据包详细里也可以看到这个ACK是用来确认28364包的。

\r\n

   随后客户端重传了7次28365包（28981、29592、30399、30405、30406、30408、30413），由于客户端1长时间收不到服务端的回应，通过30444包主动向服务端释放TCP连接。服务端通过30542包向客户端关闭了连接，客户端1通过通过30543包再次主动向服务端释放连接。

\r\n

\r\n

   30542包说明客户端提交的28365包以及重传的数据包服务端一个都没有收到，并且在等待了很长一段时间后回应客户端要关闭这个会话了。

\r\n

2.3 省厅A出口防火墙内网口数据包分析

\r\n
\"点击查看原图\"
\r\n
\r\n
   说明：由于出口防火墙配置问题，公网口并没有做镜像，是在出口防火墙内网口抓的包。
\r\n
   客户端x.x.x.204通过81838包、81845包、81847包与服务端x.x.x.155建立三次握手，随后客户端通过81850包向服务端提交POST请求，随后服务端通过81894包确认收到了该请求包。
\r\n
   看现象可以看出服务端收到客户端的POST请求后进行了确认，然后无后续数据包交互。
\r\n
   可是对比客户端，防火墙内网口没有接收到POST请求的载荷数据，以及重传7次的载荷数据包。
\r\n
   由此判断故障范围应该是省国资委内网的安全设备导致的。
\r\n
\r\n
2.4 省厅A内网再次深入分析
\r\n
\"点击查看原图\"
\r\n
\r\n
   A 尝试在另外一个区域的客户端2进行访问，判断是否是客户端1至出口防火墙之间的设备进行了过滤。
\r\n

   B 在不影响省厅A内网上网和对外提供服务的前提下，对出口防火墙闲置的接口X进行配置，接口X新增一个172.16.16.16的接口地址，出口防火墙代理172.16.16.17地址上网，并且只放通172.16.16.17访问互联网的权限，客户端3配置172.16.16.17地址连接出口防火墙的接口X，做测试访问。

\r\n

测试结果

\r\n

   A 客户端2访问服务端故障现象与客户端1一致。

\r\n

\r\n

   B 客户端3可以正常访问并登陆服务端，测试结束后删除了出口防火墙的相关配置，并测试省厅A内网上网和对外提供服务均正常。

\r\n

3 故障定位

\r\n

   结合上面拓扑结构，客户端1与客户端2使用预算系统存在登陆异常，客户端3直连出口防火墙可以正常访问并登陆预算系统，因此问题原因排除出口防火墙，客户端1与客户端2的访问路径，唯一一个共同点就是都要经过一台入侵防御。随后登陆设备检查日志，如下图所示：

\r\n
\"点击查看原图\"
\r\n
\r\n
\"点击查看原图\"
\r\n
\r\n
   客户端对服务器的访问被认为是SQL注入攻击，并进行了拦截。
\r\n
\r\n
   至此可以确认客户端登陆预算系统异常的原因是入侵防御导致，但为什么正常的访问会被当做攻击？入侵防御拦截了客户端登陆服务端的数据包为什么打开预算系统却正常？
\r\n
   通过数据包分析追踪流的概述，搜索和数据库相关的字段发现原因，数据包中含有Select…from…where语句、如下图所示：
\r\n
\"点击查看原图\"
\r\n
\r\n
5 分析结论
\r\n
\r\n

   客户端访问预算系统时，登录请求的POST 载荷中含有敏感的SQL注入语句，数据包经过省厅A内网入侵防御的时候匹配到了“Web服务远程SQL注入攻击可疑行为”规则，该规则进行了拦截，导致客户端无法正常登陆预算系统。

\r\n

6 处理建议

\r\n

   A 预算系统将查询数据库的流程放在服务端处理，客户端只提交经过加密的权限字段给服务器，由服务器做拼接或其他方式的表单处理。

\r\n

\r\n

   B 预算系统在前置的Nginx上做SSL卸载，使用HTTPS对外提供登陆服务，其他页面通过HTTP访问。

\r\n

\r\n
\r\n

\r\n