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

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) 浏览(107030)

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

作者:易隐者 发布于: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) 浏览(12589)

基于UDP 7000端口的DOS攻击案例

作者:易隐者 发布于:2012-9-24 11:12 Monday 分类:网络安全

       在某某用户现场捕获到基于UDP 7000端口实施DOS攻击的报文。

我们简单的看一下大致的分析过程:

1,通过对报文的统计,我们可以看出流量较大,平均包长1266.6字节,大包居多: 

点击查看原图

2,我们查看数据包交互情况,发现基本上都是192.168.218.112的5444端口发往121.10.173.106的UDP 7000端口的报文,这些报文大小都是1070字节,IP标识逐步递增,在15秒的时间内发送了12192个UDP报文: 

点击查看原图

3,我们查看其UDP封装的应用字段,发现全部为“AAAAAAAAAAA”的无意义填充数据: 

点击查看原图

小结:
       无论是基于什么端口的,大部分的基于UDP的攻击都是利用UDP无连接的特性,向被攻击者发送大流量的垃圾报文,导致被攻击者的网络带宽资源被占用,造成拒绝服务的攻击效果,这个案例当然也不例外。 

阅读全文>>

标签: UDP 拒绝服务攻击 DOS DOS攻击 UDP 7000端口

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

iPhone与Multicast DNS

作者:易隐者 发布于:2012-9-21 20:58 Friday 分类:案例讨论

        前两天看到CSNA论坛上有一个求助帖,原帖连接为:http://www.csna.cn/network-analyst-49133-1-1.html,故障现象大致为:网络经常出现断网情况,抓包发现断网时有大量的DNS包,楼主认为是IPHONE或IPAD在连接公司无线网络时出现的数据包。

       我下载了其数据包文件,并选其中的一个数据包文件进行了大致的分析:
1, 在数据包视图中查看其发包频率,如下图: 

点击查看原图

在1秒的时间内 发送了15542个IPv6的多播报文,这种发包频率,足以影响相关无线路由、交换机等设备的处理性能,而接收方对多播报文的处理流程决定了过多的多播报文对网络和主机的影响,大家可参考本人个人博客中《基于UDP组播实施分片攻击的可能性》一文。

2,我们查看其详细解码: 

点击查看原图

IPV6封装UDP 5353端口的DNS请求行为,经网络搜索相关信息,确认为Multicast DNS(组播DNS)报文;

       经查阅相关资料,苹果系列产品在本地局域网内缺少DNS服务器的环境下,使用Multicast DNS,实现名字和IP地址的解析,每个主机都知道自己的名字,并且会自动响应来自多播报文中针对该名字的请求。 使用Multicast DNS的设备大致工作过程如下:

1,在“.local.”子域下,挑选所需的名字;
2,使用Multicast DNS进行名字查询,看是否有主机已经使用了这个名字;
3,如果收到来自与其他主机的名字解析响应,则在“.local.”子域下重新选择一个名字,直至确认本地局域网内无其他设备使用该名字为止。

       大家可参考苹果支持主页中关于“Multicast DNS”的相关页面:http://support.apple.com/kb/TA20999?viewlocale=en_US

       这些都明确说明这个报文是iPhone发出的Multicast DNS报文,但是异常之处在于设备发包的频率太快了,而楼主反馈说,“不是每次连接都出现这个问题,只是偶尔会出现”,这也从侧面说明这个异常行为应该是属于iPhone本身跟“Multicast DNS”有关的进程异常导致的,可能是iPhone的BUG亦未可知。

       我在搜索相关信息的时候,竟然找到了一篇跟MAC OS相关的DNS异常问题的帖子,应该属于相关内容了,感兴趣的可以自行查看下面连接:http://blog.sina.com.cn/s/blog_539a3a320100q5dq.html

阅读全文>>

标签: 交换机 分片 解码 故障 UDP 多播 DNS iPhone Multicast DNS 多播DNS 组播DNS IPv6

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

基于UDP 80端口的DOS攻击案例

作者:易隐者 发布于:2012-9-10 17:16 Monday 分类:网络安全

       在某用户实际环境下,捕获了交互的报文,在“UDP会话”中,我们发现了大量的UDP 80端口的UDP会话,如下图所示:

点击查看原图

       这些UDP会话都是来自于同一个源主机,目的主机IP也是固定的,并且交互的报文都是单向的。

       我们随便找了几个UDP会话,通过UDP会话重组功能,我们可以发现,其发送的都是明显填充的字段,如下图所示:

点击查看原图

点击查看原图

       以此判断为基于UDP 80端口的DOS攻击行为无疑。

      黑客这样做主要考虑两点:

1, 利用UDP无连接特性,发送大量UDP大包,消耗攻击目标的网络带宽资源,造成DOS攻击效果;

2, UDP 80端口被过滤的可能性更小;

      TCP 80端口为最为常见的HTTP应用,基本上,绝大部分的运营商、用户都会放行TCP 80端口的报文,而其他不常见的端口则很可能被运营商、用户的安全设备、ACL过滤,而利用UDP 80 端口实施该攻击,则主要利用很多网络管理员在制定安全防护过滤策略时的不严谨性,很多人图省事,在制定相关策略时,只选择放行80端口,而不选择TCP协议或UDP协议,这样默认情况下,设备会放行TCP 80端口和UDP 80端口。这就给黑客提供的可乘之机。

阅读全文>>

标签: UDP DOS 80端口 DOS攻击 UDP 80 拒绝服务

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

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