欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

策略误报导致应用保存失败的分析案例

作者:易隐者 发布于:2013-4-20 14:13 Saturday 分类:案例讨论

       某用户应用,需要将一些修改信息提交保存至业务服务器,在这个保存过程中出现无法保存的现象(保存失败,点击保存按钮后,IE页面进度条长时间处于加载状态),我出于帮忙,到用户现场捕获了业务保存时的交互报文,如下图所示:
点击查看原图

       查看这个交互的过程,我们可以非常清晰的看到,客户端与服务器TCP三次握手正常,问题出在客户端提交POST请求的报文被中间设备丢弃了。比较有趣的是,客户端在尝试两次重传之后,较为聪明的将这个POST请求字段(长度为859B)拆分为两个长度分别为536B和323B的字段,并先将长度为536B的应用字段重传给服务器,我们清楚的看到服务器对这个应用字段作出了确认,这说明这个长度的应用字段正常到达了应用服务器,但是后续长度为323B的应用字段一直被丢弃,这很容易想到是中间设备策略误报一直丢弃某些固定报文导致的,我们来看一下这个应用字段里到底封装的是什么应用数据,我们首先看这个报文的应用字段解码如下:

点击查看原图

       这个看得有点头晕,我们将这段字符解码一下,如下图所示:
点击查看原图
       解码之后,我们可以看到这个应用字段中存在“varchar(60)”等关键字,这可能引起WAF、IPS等设备将此报文误报为SQL注入的尝试。      

阅读全文>>

标签: 应用故障 IPS 策略误报 POST WAF SQL注入

评论(7) 引用(0) 浏览(5431)

可能的URL超长导致丢包案例

作者:易隐者 发布于:2012-12-10 14:03 Monday 分类:案例讨论

       上周五,有网友兄弟给我发了一个报文,让我帮忙查看是否存在什么异常问题。我查看其TCP会话交互过程,如下图所示: 

点击查看原图

       单从这个报文交互来看,客户端与服务器的TCP连接建立正常,客户端已经向服务器发送过get请求,并得到了服务器的确认,问题出在客户端向服务器发送的第二个get请求:“
http://192.168.0.12/Default_Login.aspxusercode=x6x9&password=81xx9xxx52x04xx20036xxx8313xx055&

MyCurrentCompany=&rdnum=0.5966797953405811”。

       客户端发出这个get请求之后,在37秒的时间内重传了5次,服务器端无应用数据需要主动的发给客户端,因此在这个时间段内我们未见来自于服务器的报文,而如果客户端的发送的这个get请求到达了服务器端,则服务器会根据其请求内容作出应用响应,最起码服务器端会对客户端的TCP报文发送ACK确认。但是这些都没有出现,这能够说明客户端的get请求报文根本未到达服务器端,即客户端的这个get请求报文被中间设备丢弃了,我们查看客户端的发送的第二个get请求报文的解码

点击查看原图

       我们发现这个报文除了其请求的URL长度较长(420字节)外,其他似乎也没什么特别的,因此,个人推测其被中间设备丢弃的原因可能是其URL超出了防火墙/负载均衡/WAF/IPS等设备的限制,或者是URL中包含“uesr”、“password”等敏感字段而被中间设备丢弃了。

阅读全文>>

标签: TCP 负载均衡 解码 ACK确认 防火墙 IPS get URL超长 get请求

评论(3) 引用(0) 浏览(6508)

TCP/IP 数据包处理路径

作者:易隐者 发布于:2012-11-13 16:09 Tuesday 分类:参考资料

简介

       随着 Microsoft® Windows® XP Service Pack 2 和 Windows Server™ 2003 Service Pack 1 新增了 Windows 防火墙,以及 Internet 协议安全 (IPsec) 在公司 Intranet 中日益广泛的应用,信息技术 (IT) 专业人士需要了解 TCP/IP 协议及 Windows 中的相关组件处理单播 Internet 协议 (IP) 数据包的具体方式。有关 IP 数据包处理路径的详细知识,可以让您更轻松地掌握配置数据包处理和筛选组件,以及进行相关疑难解答的具体方法。

        本文所介绍的内容如下:

• 用于 IP 版本 4 的 TCP/IP 协议的基本体系结构以及其它一些用于处理数据包的组件。
• 基于 Windows 的计算机所发送、接收和转发的单播流量的数据包处理路径。

         注意:为了简要起见,本文将不讨论多播、广播、分段或隧道数据包。

用于数据包处理的 TCP/IP 体系结构

         下图为 TCP/IP 协议驱动程序 (Tcpip.sys) 及其用于在 Windows XP Service Pack 2 和 Windows Server 2003 Service Pack 1 中处理 IP 数据包的相关组件的简要示意图。 

点击查看原图

         下列组件可处理 IP 数据包:

• IP 转发 为发送或转发的数据包确定下一跃点接口和地址。
• TCP/IP 筛选 允许按 IP 协议、TCP 端口或 UDP 端口,指定可为传入的本地主机流量(发往主机的数据包)所接受的流量类型。可以在“网络连接”文件夹中,从 Internet 协议 (TCP/IP) 组件高级属性的“选项”选项卡,配置 TCP/IP 筛选。
• 筛选器挂钩驱动程序 该 Windows 组件可使用筛选器挂钩 API,筛选传入和传出的 IP 数据包。在运行 Windows Server 2003 的计算机上,筛选器挂钩驱动程序为 Ipfltdrv.sys,属于“路由和远程访问”的一个组件。启用后,“路由和远程访问”允许用户使用路由和远程访问管理单元,对每个接口配置单独的入站和出站 IP 数据包筛选器。Ipfltdrv.sys 会同时检查本地主机和中转 IP 流量(不发往主机的数据包)。
• 防火墙挂钩驱动程序 该 Windows 组件可使用防火墙挂钩 API,检查传入和传出的数据包。在运行 Windows XP 的计算机上,防火墙挂钩驱动程序为 Ipnat.sys,由 Internet 连接共享和 Windows 防火墙双方共享。Internet 连接共享是一种基础网络地址转换器 (NAT)。Windows 防火墙是一种基于主机的状态防火墙。Ipnat.sys 可同时检查本地主机和中转 IP 流量。在运行 Windows Server 2003 的计算机上,Ipnat.sys 由 Internet 连接共享、Windows 防火墙和路由和远程访问的 NAT/基本防火墙组件三方共享。如果启用了路由和远程访问的 NAT/基本防火墙组件,就不能再启用 Windows 防火墙或 Internet 连接共享了。
• IPsec IPsec 组件——Ipsec.sys——是 IPsec 在 Windows 中的实现,可对 IP 流量提供加密保护。Ipsec.sys 可同时检查本地主机和中转 IP 流量,并可允许、阻止或保护流量。

数据包处理路径

       下面几节介绍了针对以下流量的具体的数据包处理路径:
• 源流量 由基于 Windows 的发送主机发起。
• 目标流量 达到最终的基于 Windows 的目标主机。
• 中转流量 由基于 Windows 的 IP 路由器转发。
       这里只讨论 Windows Server 2003 或 Windows XP 所附带的组件,不涉及 Windows 套接字分层服务提供程序或 NDIS 中间微型端口驱动程序。

源流量

        源流量的数据包处理路径如下图所示。 

点击查看原图

1. IP 数据包形成后,Tcpip.sys 就会将其传递给防火墙挂钩驱动程序 (Ipnat.sys) 进行处理。

        Windows 防火墙检查该流量是否属于所要阻止的特定的 Internet 控制消息协议 (ICMP) 消息类型。如果 ICMP 消息被阻止,Windows 防火墙就将丢弃该数据包。
       Windows 防火墙检查该流量是否属于点对点隧道协议 (PPTP) 隧道维护流量。如果属于的话,Windows 防火墙将分析该流量,确定用于识别特定 PPTP 隧道的通用路由封装 (GRE) 调用 ID,从而允许 PPTP 隧道的基于 GRE 的传入流量。
       如果需要,Windows 防火墙会在例外列表中添加一个动态项目,来允许响应流量。
       处理完后,Ipnat.sys 会将该 IP 数据包传回给 Tcpip.sys,而后者会使用 IP 转发组件,确定下一跃点 IP 地址和接口。有关详细信息,请参阅认识 IP 路由表。

2. Tcpip.sys 将数据包传递给筛选器挂钩驱动程序 (Ipfltdrv.sys) 进行处理。

       Ipfltdrv.sys 根据下一跃点接口,将该数据包与已配置的出站 IP 数据包筛选器进行对比。
       若出站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该数据包。若出站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该数据包传回给 Tcpip.sys。

3. Tcpip.sys 将该数据包传递给 Ipsec.sys 进行处理。

       Ipsec.sys 根据 IPsec 筛选器组,决定是否允许、阻止或保护该数据包。若允许的话,Ipsec.sys 会在不修改该数据包的情况下,将其发回给 Tcpip.sys。若阻止的话,Ipsec.sys 会在不发出任何提示的情况下,丢弃该数据包。若要进行保护的话,Ipsec.sys 会在将数据包传回给 Tcpip.sys 之前,对其添加适当的 IPsec保护。Tcpip.sys 随后会通过下一跃点接口,将该数据包发送到下一跃点 IP 地址。

目标流量

       目标流量的数据包处理路径如下图所示。 

点击查看原图

1. 接收到 IP 数据包后,Tcpip.sys 会将其传递给 Ipsec.sys 进行处理。

       若数据包带有 IPsec 保护(指示验证头 [AH] 或封装式安全措施负载 [ESP] 的 IP 协议字段值),将对其进行处理并加以移除。若对计算机应用了“Windows 防火墙:允许已验证的 IPSec 跳过”组策略设置,Ipsec.sys 将设置一个与该数据包相关联的 IPsec Bypass 标记。Ipsec.sys 将结果数据包传回给 Tcpip.sys。
若数据包不带有 IPsec 保护,Ipsec.sys 就会根据 IPsec 筛选器组,决定是否允许、阻止或保护该数据包。若允许的话,Ipsec.sys 会在不修改该数据包的情况下,将其发回给 Tcpip.sys。若数据包被阻止或需要保护,Ipsec.sys 就会在不发出任何提示的情况下,丢弃该数据包。

2. Tcpip.sys 将该数据包传递给 Ipfltdrv.sys 进行处理。

       Ipfltdrv.sys 根据接收数据包的接口,将该数据包与已配置的入站 IP 数据包筛选器进行对比。若入站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该数据包。 若入站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该数据包传回给 Tcpip.sys。

3. Tcpip.sys 将该数据包传递给 Ipnat.sys 进行处理。

       若启用了 Internet 连接共享或 NAT/基本防火墙,并且接收数据包的接口是连接到 Internet 的公共接口,Ipnat.sys 就会将该数据包与其 NAT 转换表进行对比。若找到了匹配项,就将转换该 IP 数据包,并将结果数据包视为源流量。
       Windows 防火墙检查与该数据包相关联的 IPsec Bypass 标记。若设置了 IPsec Bypass 标记,Windows 防火墙就会将该数据包传回给 Tcpip.sys。
       若未设置 IPsec Bypass 标记,Windows 防火墙就会将该数据包与其例外列表进行对比。若数据包与某个例外匹配,Ipnat.sys 就会将该 IP 数据包传回给 Tcpip.sys。若不匹配,Ipnat.sys 会在不发出提示的情况下,丢弃该 IP 数据包。

4. Tcpip.sys 将 IP 数据包与已配置的 TCP/IP 筛选允许的那组数据包进行对比。

       若 TCP/IP 筛选不允许该数据包,Tcpip.sys 将在不发出提示的情况下,丢弃该数据包。若 TCP/IP 筛选允许该数据包,Tcpip.sys 将继续对其进行处理,并最终将该数据包有效负载传递给 TCP、UDP 或其它上层协议。

中转流量

       中转流量的前半部分路径如下图所示。 

点击查看原图

1. 接收到 IP 数据包后,Tcpip.sys 会将其传递给 Ipfltdrv.sys 进行处理。

       Ipfltdrv.sys 根据接收 IP 数据包的接口,将该数据包与已配置的入站 IP 数据包筛选器进行对比。
若入站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该 IP 数据包。若入站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该 IP 数据包传回给 Tcpip.sys。Tcpip.sys 将数据包传递给 IP 转发组件,由后者确定用于转发该数据包的下一跃点接口和地址。

       中转流量的后半部分路径如下图所示。 

点击查看原图

2. Tcpip.sys 将该数据包传递给 Ipnat.sys。

       若启用了 Internet 连接共享或 NAT/基本防火墙,并且接收数据包的接口是连接到 Intranet 的专用接口,Ipnat.sys 就会将该数据包与其 NAT 转换表进行对比。若 Internet 连接共享或 NAT/基本防火墙找到了匹配项,将转换该 IP 数据包,并将结果数据包当作源流量。若 Internet 连接共享或 NAT/基本防火墙未找到匹配项,将创建一个新的 NAT 转换表项,转换 IP 数据包,并将结果数据包当作源流量。若未启用 Internet 连接共享,Ipnat.sys 就会将 IP 数据包传回给 Tcpip.sys。

3. Tcpip.sys 将该数据包传递给 Ipfltdrv.sys。

       Ipfltdrv.sys 根据下一跃点接口,将该数据包与已配置的出站 IP 数据包筛选器进行对比。若出站 IP 数据包筛选器不允许该数据包,Ipfltdrv.sys 就会在不给出提示的情况下,丢弃该 IP 数据包。若出站 IP 数据包筛选器允许该数据包,Ipfltdrv.sys 就会将该 IP 数据包传回给 Tcpip.sys。

4. Tcpip.sys 将该数据包传递给 Ipsec.sys 进行处理。

       Ipsec.sys 根据 IPsec 筛选器组,决定是否允许、阻止或保护该数据包。若允许的话,Ipsec.sys 会在不修改该数据包的情况下,将其发回给 Tcpip.sys。 若阻止的话,Ipsec.sys 会在不发出任何提示的情况下,丢弃该数据包。若要进行保护的话,Ipsec.sys 会在将数据包传回给 Tcpip.sys 之前,对其添加适当的 IPsec保护。
       Tcpip.sys 随后会通过下一跃点接口,将该 IP 数据包发送到下一跃点地址。

       对于运行 Windows XP SP2 或 Windows Server 2003 SP1 并采取常规配置的客户端或服务器计算机(不充当路由器或 NAT,并禁用了 TCP/IP 筛选),源流量的数据包处理路径涉及以下组件:
1. Windows 防火墙
2. IPsec
       对于上述采用常规配置的基于 Windows 的计算机来说,目标流量的数据包处理路径涉及以下组件:
1. IPsec
2. Windows 防火墙

       若使用了 IPsec,并启用了 Windows 防火墙,那么可能需要配置这两个组件,以允许想要的流量。譬如,要是您正在配置一台 Web 服务器,并使用 IPsec 保护发往该服务器的 Web 流量,就必须配置以下项目:
1. 一个 IPsec 规则(要求发往和发自该服务器的 IP 地址和 TCP 端口 80 的安全性)。
2. 一个 TCP 端口 80 的 Windows 防火墙例外。
       该 IPsec 规则可确保发往 Web 服务器服务的流量受到保护。该 Windows 防火墙例外可确保 Windows 防火墙不会丢弃未经请求的传入请求,来通过 TCP 端口 80 创建到 Web 服务器的连接。由于 IPsec 和 Windows 防火墙都作为单独的组件处理 IP 数据包,因此必须同时配置这两个组件。要是不想让 Windows 防火墙处理受 IPsec 保护的数据包,请配置“Windows 防火墙:允许已验证的 IPSec 跳过”组策略设置。有关详细信息,请参阅对 Microsoft Windows XP Service Pack 2 部署 Windows 防火墙设置。

阅读全文>>

标签: TCP 防火墙 安全 IPS UDP NAT TCP/IP API IPsec Windows 数据包 数据包处理路径 路由转发 IP转发

评论(0) 引用(0) 浏览(110350)

异常流量分析方法——发现-定位-管控

作者:易隐者 发布于:2012-11-8 21:50 Thursday 分类:网络分析

       我们在实际工作环境中遇到各种影响网络系统和业务正常运行的异常流量的概率远远高于遇到疑难故障的概率,在我的博客里已经将疑难杂症的分析方法和思路做了非常深入的阐述(大家可参考《疑难故障分析常规流程和思路》、《疑难网络故障的分析方法和原理之关联分析法》、《疑难网络故障的分析方法和原理之对比分析法》等文),并且我为此撰写了大量的疑难故障的实际分析和解决的案例,我在《疑难故障分析常规流程和思路》一文中,仅仅简单的提到“全局捕包确认异常类型和源头”等寥寥数字,这并不是我疏忽,而是当这些异常流量足以对网络和业务应用产生较为严重影响的时候,其在流量的特性上往往具有较为明显的特征,因此站在网络分析技术的角度,我认为针对这些异常流量的分析是一件非常简单的事情,只要通过简单几个分析步骤和流程,即可快速的定位。
       但是这些看似简单的方法和流程,对于一些不了解网络分析技术或网络分析初学者来说,却是一件令人头疼的事情,我曾在工作中数次遇到朋友问我:为什么不把这些最常遇到的异常流量问题的分析方法和思路,简单明了的写出来,以助初学者快速入手呢?
       我想的确有道理,把这些东西写出来,让更多的朋友能够利用我写的分析方法和思路解决实际工作过程中遇到的问题,岂不是一件快事?但是考虑到高彦刚老师在其《实用网络流量分析技术》一书中,已经对蠕虫、P2P、环路、ARP病毒等常见异常流量的分析案例做了专业的介绍,在此我将不再将高老师已经做过的、非常优秀的事情再做一遍,我主要将异常流量分析的方法和思路总结为一个简单易懂的、通用的分析流程。据此流程,你可以快速的分析定位大部分的异常流量。
       该方法并不局限于任何一款具体的网络分析产品和工具,只要你熟练掌握某一种网络分析工具(wireshark、omnipeek、科来或其他),都可以按照这个分析方法,快速的分析定位大部分的异常流量。

什么是异常流量

       严格的来讲,正常业务流量之外的流量,都应该归类为异常流量的范畴。但是,除了在工业控制系统等生产网络环境中,可以这样定义异常流量之外,其他的办公网络环境如此严格的定义异常流量都是不合适的。因为在普通的办公网环境下很难保证网内交互的都是业务流量。
       在办公网络环境下,办公端系统的应用和管理是非常丰富和复杂的,我们难以做到让每个办公终端在固定的时间内只运行某些固定的业务系统,相反,这些办公终端会根据不同的使用者特性和个人偏好,在不同的时段运行的大量的应用进程,这些进程中可能包含正常的办公应用的进程,也可能包含大量依托于互联网的非业务应用进程,甚至可能包含使用者自己都不知道的第三方插件、木马、病毒等进程。因此,我们还需要定义一个应用更为广泛的狭义上的异常流量。

       狭义范畴上的异常流量主要指:病毒、蠕虫、木马、垃圾应用(P2P下载/在线视频/在线游戏等)、攻击(各种DOS攻击流量)等影响网络和业务正常运行的流量。
       如此一来,我们便明确了我们需要分析的对象了,如果你是一个初学者,这样是不是感觉更具体一点?是不是有种找到靶心的感觉,哈哈。话不多说,还是跟我一起来开启这趟分析之旅吧。

异常流量分析方法和思路

       按照我个人的经验,我将异常流量的分析方法归纳为三大步骤和五个过程,分别为
发现-定位-管控三大步骤和Whether-Who-What -Where-How五个过程。如下图所示: 

点击查看原图

发现-定位-管控三大步骤

点击查看原图

Whether-Who-What -Where-How五个过程

发现-定位-管控三大步骤:
发现(Discovery):及时发现当前网络环境中是否存在异常流量。
定位(Location):通过分析定位出异常流量的根源、类型、运作模式以及具体的主机位置,为下一步的管控提供全面的信息。
管控(Control):利用现有资源,及时实现对异常流量的管理和控制,消除异常流量对网络和业务正常运转的影响。

Whether-Who-What -Where-How五个过程:
Whether:通过分析,大致判断网络内部是否存在异常流量?
Who:若存在异常流量,异常流量都与谁有关?
What:异常流量是什么类型的?异常流量的运作机制怎样?
Where:异常流量相关的主机都在什么位置?
How:如何实现对异常流量的及时管理和控制?
       这三大步骤和五个具体分析过程是相互关联的。下面我们将这三大步骤和五个具体分析过程关联起来进行阐述。

阅读全文>>

标签: 交换机 TCP wireshark omnipeek 防火墙 IPS 科来 中间设备 UDP 抓包 DOS 攻击 行为特征 发包频率 异常流量 蠕虫 木马 P2P 扫描 TCP会话 UDP会话 平均包长 平均每秒包数 利用率

评论(0) 引用(0) 浏览(17279)

视频点播服务间歇性中断故障分析案例

作者:易隐者 发布于:2012-8-1 22:15 Wednesday 分类:网络分析

故障环境

1 网络拓扑

点击查看原图

2 说明

1、VOD在线视频是通过web页面观看的,通讯流全部使用HTTP的80端口传输数据;
2、客户端与服务器是纯路由环境下完成数据交互的。

故障现象

1、客户端通过浏览器在线观看VOD视频时,不定时(有时几分钟、有时十几分钟,没有规律)的出现中断情况;
2、使用ping命令长时间测试VOD服务器的连通性,一直正常;
3、异常时,VOD服务器的web页面访问正常。

阅读全文>>

标签: IP标识 sack tcpdump 重传 IPS 策略误报 视频点播故障 IPID

评论(1) 引用(0) 浏览(10065)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1