某省厅门户网站A市局访问异常应急处置

2017-11-28 · 网络分析 · 网络分析 · 6390 次阅读

1 情况概述

1.1 网络拓扑结构

梳理省厅网络拓扑结构，了解WEB服务器通过接入交换机、WAF、抗D，经防火墙对外映射提供服务，其中交换机、抗D、WAF均为二层部署，如下图所示：

1.2 情况简介

A市局近期有无法访问省厅门户网站的现象，换个IP即可正常访问，与省厅沟通后发现其他市局和互联网用户均能正常访问。

1.3 分析思路

A市局能正常访问互联网其他网站，说明A市局的网络应该没有问题。同时其他单位和用户能正常访问省厅门户网站，也可初步排除是网站业务发布故障的可能。考虑到只出现了某一IP无法正常访问的现象及最近上线的抗DDOS设备，判断应该是中间设备对相关访问的拦截或者防火墙以及安全软件等黑名单设置导致的业务无法正常访问。具体流程如下：

A 因为用户告知的拓扑结构可能与真实环境存在出入，所以到现场之后应该先梳理门户网站对外提供服务的关键路径，摸排相关设备；

B 了解问题现象，然后通过在服务器与客户端之间抓包对比分析逐步确定故障点，确定包在哪里丢的；

C 检查相关日志、策略、配置；

D 定位问题并解决。

2 具体分析流程

2.1 抓包位置选择

在出口交换机下行口做镜像流量抓取A市局访问省厅门户网站的web流量，同时在web服务器上抓包，对比分析还原整个会话过程。

抓包位置

2.2 故障分析

抓包位置部署完毕后联系A市局进行访问测试，同时进行数据包抓取工作，无法访问的情况再次出现。这时提取两处抓取的数据包过滤发现，接入交换机的下行口出现了A市局访问省厅门户网站的HTTP流量，A市局的IP地址：x.x.x.58，省厅门户网站公网IP地址：x.x.x.148。

出口交换机镜像抓包

可以看到A市局通过TCP三次握手和服务器建立了连接，随后向服务器进行了get请求，但是服务器只针对get请求做了ACK确认，后续并无应用层的响应以及应用层数据的返回。

服务器端抓包

在服务器端抓包过滤后并没有发现A市局流量。

通过简单对比，说明A市局的数据包到达出口交换机是没有问题的，但服务器网卡并没有收到，所以开始对中间设备进行排除。

因为抗D和WAF、接入交换机都是二层，跳过检查比登陆设备检查要快捷，所以先跳过抗DDOS设备，发现地市单位依然无法访问，随后继续跳过服务器前面的WAF和接入交换机依旧不能访问。最终让防火墙和服务器直连，同时在防火墙上抓包：

防火墙抓包

可以看到A市局向服务器发送的syn请求包，可是服务器并没有进行回应，那么在WAF、抗D、接入交换机还没有跳过时，为什么“服务器”进行了TCP响应？

在这里需要回顾一个知识点，诸如负载均衡、WAF这类硬件设备是存在代理行为的，例如WAF，在防御TCP半连接攻击时，就会代理服务器向客户端进行应答，根据这个知识点可以发现，之前服务器的TCP应答报文在该网络环境中其实是WAF代理服务器向客户端返回的应答，并不是真实服务器响应的。

中间设备已全部跳完，由此看来问题是出在服务器上的，进一步检查服务器操作系统，首先排查系统防火墙配置，因为本地防火墙就是基于五元组进行访问控制的，但检查结果为正常。

排查安全软件，发现服务器安装了安全狗，但并没有运行。

最后排查到网卡属性时，发现安全狗的网络层驱动正在运行。删除驱动后测试，发现A市局已经能正常访问，启动安全狗软件进入黑名单设置，发现了A市局的IP。至此找到了A市局无法访问省厅门户网站的原因，是由于安全狗黑名单设置后，虽然安全狗并没有运行，但底层驱动依然工作对A市局进行拦截所导致的问题现象。

安全狗黑名单

3 反思总结

为什么wireshark没有抓到A市局的数据包？