蚂蚁网-多维人生，三实而立！

ACK flood攻击的影响

作者：易隐者 发布于：2012-10-8 10:14 Monday 分类：网络安全

       我们在分析ACK flood攻击对端系统和中间系统的影响之前，首先需要了解端系统和中间系统一般情况下是如何处理其收到的ACK报文。

端系统对ACK flood报文的处理

       端系统在收到一个ACK报文时，如果目的端口未开放，那么端系统会直接向源IP发送RST报文，其交互过程大致如下图所示： 

       如果端系统的相关端口是对外开放的，那么其在收到ACK报文时，首先会检查这个ACK报文是否属于TCP连接表中的一个已有连接（这个过程会对端系统主机CPU资源造成一定的消耗），如果是的话，则正常处理，如果不属于任何一个已有连接，那么端系统会向源IP发送RST报文，交互过程如下图所示： 

       根据上面两个过程的分析，我们可推论ACK flood攻击对端系统性能的影响并不会非常大，至少跟SYN flood（端系统需要给每个SYN报文分配相应连接表空间，会消耗端系统内存资源）攻击相比，其攻击效果似乎难上台面。

中间系统对ACK flood报文的处理

       路由器和防火墙的工作机制决定了路由器和防火墙在处理ACK报文的时候是完全不同的，我们分别将路由器与防火墙对ACK flood攻击的处理过程做简单描述。
       路由器是网络层的设备，其主要功能是选路和转发，其选路的依据大部分都是基于网络层信息（目的IP、源IP等），因此路由器在处理ACK报文的时候，其并不关心它是不是ACK报文，它主要关心其目的地址，需要根据其目的地址来进行选路，如果ACK flood攻击的目的主机都是固定的，那么路由器其实只需要在收到第一个ACK flood攻击报文时，调用CPU资源实现选路和转发，后续的ACK flood攻击报文由于目的主机是固定的，其甚至不需要调用CPU资源，直接使用快速转发表即可实现对ACK flood报文的转发，路由器对ACK报文的处理过程大致如下： 

       防火墙对ACK报文的处理主要跟连接状态表有关，防火墙在收到ACK报文时，首先检查该ACK报文是否属于连接状态表中的已有连接，如果是，防火墙转发该ACK报文，如果未命中任何一个已有连接，防火墙会将该ACK报文丢弃，如下图所示： 

ACK Flood攻击对系统的影响

       由此来看，ACK flood攻击对端系统与中间系统的影响相对于其他攻击来说都不是非常明显，至于网上有相关资料讲其需要配合SYN flood攻击产生较好的攻击效果，原因为针对防护SYN flood攻击的一种技术 ——SYN cookie技术。
       当某些启用SYN cookie技术进行SYN flood攻击防护的中间设备（专业抗DOS设备、防火墙、IPS、负载均衡、路由器等），在收到ACK报文时，需要计算cookie值，这个过程会消耗一部分中间设备的CPU资源，如果大量的ACK报文过来的话，很可能很快就会导致设备资源耗尽，达到拒绝服务的效果。

关于SYN cookie的工作机制，我在互联网上找到一篇文章，文章链接为：
http://blog.csdn.net/force_eagle/article/details/5348946，作者：droplet，现全文引用至此：

“

Cookie如何计算？
cookie = MD5(srcip,dstip,sport,dport)
端口是否需要考虑哪？没有端口的话，可以少一点计算。
Syn-cookie是无状态的，在Gateway上，不会保存任何与connection相关的东西，所以不会占用gateway的资源，缺点就是需要计算cookie，CPU占用会高一点。
如果不考虑端口的话，cookie是不是可以cache哪，如果cache了，就有查找的开销，并不一定比MD5的hash快多少。
在Syn-cookie之前，先要检查一下srcip是不是spoofing的，这里需要做一个反向的路由查找，看看是不是从错误的接口进来的，也可以确认一下源地址是否可达。
是不是也应该做一个源端口的检查哪？如果是0~1024的端口，就默认是非法的，因为这些端口在操作系统里面，一般是保留的，不会分配给应用程序。
Syn attack是否有signatue? 不同的syn flood工具，生成的工具包，应该有一定的模式，如果能够找到这个signature，就可以通过signature来直接drop这个syn，不用再做syn-cookie的检查了。
Syn-cookie会strip掉client和server的tcp option，对client，可疑在cookie里面带上tcp option，但是对server来说，就比较难办一点。strip掉tcp option，对connection的性能有影响。
对syn-flood的防范，目前还是threshold based，因为不能区分正常包和攻击包，但是如果能够定义攻击的signature，就可以做signature based的防范，这样可以更有效一点。”

       在这里有个疑问，启用SYN cookie技术的中间设备在收到SYN报文的时候会建立cookie序列，在收到ACK报文的时候会计算cookie是否合法，那么是不是任何一个ACK报文都计算cookie值呢？从全文的描述来看，应该是在收到三次握手的最后一个ACK报文时才进行计算。
       如果是对所有ACK报文都进行cookie值计算，这个中间设备对SYN cookie技术的实现是不是非常不科学呢？如果仅针对三次握手时的第三个ACK报文进行cookie值计算，那么中间设备应该直接丢弃随机伪造的ACK flood攻击报文。如果是丢弃随机伪造的ACK flood报文，那么对中间设备资源的消耗也是有限的。

        需要申明的是，以上仅为我个人站在技术原理的角度作出的推论，实际环境下没有亲见ACK flood攻击带来的影响。欢迎各位兄弟姐妹一起做进一步的探讨。

阅读全文>>

标签: TCP RST 防火墙 ACK flood SYN flood 连接表 SYN cookie ACK报文 连接状态表

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

【转】某加密机经天融信防火墙后应用异常故障案例

作者：易隐者 发布于：2012-9-24 14:10 Monday 分类：案例讨论

【写在前面】：

1，该案例是一个特殊应用、特殊环境下的疑难故障案例，给我们的启示是在故障现场，我们需要充分了解清楚跟故障有关的应用特性，比如此案例中的加密机的工作机制；

2，该案例涉及到以下知识点：IP报头校验和、IP分片（请参考本博《IP分片》一文）、防火墙对分片报文的处理等；

3，此案例在整理文档时，应该简化了很多的分析测试过程，我按照我的理解做一些梳理：

（1），IP报头校验和只跟IP报头有关，跟IP封装的数据无关，因此，如果原文中的描述的“收到报文是否进行校验和检查”是指IP报头检验和的话，那么应该不会存在校验和错误而被防火墙丢弃的问题，如果是指TCP校验和或UDP检验和的话，那么，每个来自于加密机的报文其TCP或UDP校验和都是错误的（因为多了33字节），因此防火墙肯定会直接丢弃这个报文，根本不存在文档中描述的在防火墙转发接口抓到1460字节数据包的情况；

（2），防火墙不对收到的报文进行校验和计算，那么这个报文才会进入防火墙的内核处理流程，因为来自于加密机的报文是IP分片报文，因此防火墙会对此分片报文进行处理（选择直接转发分片报文还是重组后匹配策略再转发），如果防火墙直接转发，则没什么问题，如果是重组转发，这里就存在一个问题：防火墙能否完成这个报文的重组？因为IP分片的重组是根据IP报头中的相关信息来完成的，其中非常重要的一个参数就是分片偏离量，这个值决定了分片报文在原始报文中的位置，而在这个故障环境下，每个报文都被加密机在尾部添加了只有加密机能够识别的特征码，防火墙并不能识别，那么防火墙在重组这些报文的时候，如何处理正常分片报文跟前一分片报文尾部添加的33字节部分的重叠呢？这是值得思考的。如是覆盖33字节的尾部识别码，则到达对端加密机后，加密机会丢弃这个报文，并不是因为文中所说的“认为加密数据被篡改”，而是由于被覆盖了数个识别码导致接收端加密机无法正常识别加密报文（篡改的识别是通过校验和得到的，接收方根据报头信息可以计算出校验和，也就是说只要报头信息没错，校验和就不会错，而防火墙在重组完毕后转发前肯定会重新计算转发报文的报头校验和）。

4，各位读者兄弟根据自己的理解，自由参考我上面的分析和下面的案例原文，欢迎探讨和交流。

【原文全文】：

一、拓扑 

二、环境描述

       该拓扑使用的VPN链路是某公司的产品，该VPN在做加密处理时，TCP头和IP头都不做加密，只对数据区做加密，通过在加密机的抓包，发现加密机把所有MTU大于1300的数据包做了分片处理，并且在所有包的末尾加入自己的N字节加密识别码，这样从加密机发出的数据包MTU值最大1333，对于大于1333的报文（如1460）的数据包加密机都是分2个包进行传送，在没接防火墙时一切正常，接入防火墙后导致访问不正常；
       拓扑中客户端172.16.1.22在访问服务器172.16.1.33时，服务器回应的MTU值1460数据包被服务器端加密机拆成2个包（第一个包1300），并在每个包的末尾加入33位，而防火墙在接收时将两个包合并转发，具体表现为防火墙接收口（接服务器端加密机）收到的报文数据长度是1333，而转发口（接客户端加密机）转发的报文数据长度是1460，这样客户端加密机就认为加密数据被篡改，导致VPN加密通讯错误；

三、分析过程与解决方式

1、 由于加密机的特殊性，所以加密封包后的数据在通过防火墙时，会被认为是错误报文，
解决方法：将防火墙“选项设置”---“安全设备系统参数”---“系统参数开关”下的“收到报文进行是否效验和检查”选项取消，如下图所示 

2、 加密机对大于1300的数据包做分片处理，到防火墙时，发现数据是分片包，防火墙又给重组后转发，导致对端加密机认为数据被篡改，不再对该数据包做解密处理；
解决方法：启用防火墙中的分片处理，将经过防火墙的数据都不做分片重组处理；
3、 以上两点设置好后，TCP报文可以正常通讯，但UDP报文（如视频报文）由于数据量大的缘故在通过防火墙时，经常丢包；
解决方法：研发根据该问题给了一个特殊的补丁，专门解决UDP报文处理的，只要打上该补丁即可；

四、总结

1、 将防火墙“选项设置”---“安全设备系统参数”---“系统参数开关”下的“收到报文进行是否效验和检查”选项取消；
2、 启用防火墙中的分片功能，将经过防火墙的数据都不做分片重组处理；
3、 打上专用的补丁；

阅读全文>>

标签: ip分片 天融信 分片 防火墙 重组 校验和 IP报头检验和

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

关于vista系统机器无法通过防火墙上网的故障分析解决案例

作者：易隐者 发布于：2012-9-17 13:53 Monday 分类：网络分析

【说在之前】：

1，该案例为误开启ARP代理功能导致的疑难故障；

2，该故障的触发是由于XP与vista操作系统发送的免费ARP报文格式不一致导致的；

3，关于ARP代理请参考本博客《ARP代理（Proxy ARP）》一文；关于免费ARP，请参考《免费ARP（gratuitousARP）》一文；

4，跟这个案例分析的原因有关的类似故障案例还有netyourlife论坛上的《为什么VISTA不能穿过ASA》，大家可自行查看比较；

5，针对该案例做的相关实验，请大家参考本博客《关于防火墙的arp代理功能对不同格式的arp报文的处理情况的实验》一文；

【我的案例】：

故障环境

1 网络拓扑 

2 说明

1、内部机器全部在同一网段，经过一个二层交换机接入防火墙，通过防火墙的NAT访问互联网；
2、以前内部办公机器都是xp操作系统，现在新采购了一批vista操作系统新机器。

故障现象

1、 vista操作系统的办公机器在接入网络时，本地连接便显示网络连接正在识别，提示找不到网络；
2、 使用ifconfig/all命令查看vista系统的ip地址情况如下图所示： 

       通过上图，我们发现：vista系统的首选地址变成了169.254.180.208，而不是先前收到设置的192.168.0.23了；
3、 用户反馈，如果vista系统的办公机器只接入交换机不会出现这种情况，但一旦接入防火墙，故障现象就会出现。
4、 XP系统的办公机器一切正常。

故障分析

1、 首先根据用户反馈的故障现象，从自己的经验出发，个人认为这个跟网络应该没有什么关系，估计是操作系统的问题，于是打microsoft OEM厂商的800电话咨询关于vista系统ip地址“突变”的原因，得到的回复是：从未出现过此类问题，可能跟现场环境有关。
2、 根据用户反馈的情况测试：首先，设好vista系统机器的ip地址后，将其接入一台普通的交换机，查看vista机器的ip地址，的确正常，如下图所示： 

       难道真的跟防火墙有关？
3、 既然怀疑跟防火墙有关，我们便将注意力放到防火墙上来，telnet到防火墙上，使用使用tcpdump –i eth2 host 192.168.0.23 –n命令抓取测试vista主机的数据包。
4、 重启vista主机，发现vista主机在系统启动后，发送了一个源ip为0.0.0.0、目的ip为其配置的ip的arp请求包，同时，防火墙回应了该arp请求包，如下图所示： 

5、防火墙为什么会回应该数据包？我们检查防火墙配置，发现防火墙上手动将内部办公网段设为静态arp代理。跟用户确认该问题，原来用户误认为该功能可能会解决arp欺骗问题，尝试设置后，忘记将其删除了。

故障解决

       删除防火墙上手动添加的arp代理项，故障现象消失，故障解决。

引申问题

1、通过抓取数据包，我们可以发现vista系统与xp系统在网卡引导阶段发送的“免费”arp报文格式的差别：
VISTA 系统发送的免费ARP请求包格式为：

下图为wireshark抓取的vista系统网卡引导阶段发送的arp数据包格式：                      
 

XP系统中发送的免费ARP请求包格式为：

下图为xp系统发送的免费arp包格式： 

       为什么VISTA系统在网卡地址加载期间发送这种格式的ARP数据包呢？关于这个问题已经有人做过相关的测试，我也验证了这个实验，下面为实验的过程，引用自netexpert的gwdwx：
“A机－B机两台xp对联测试：
1）按照xp的arp包格式（源ip＝目的ip＝a机ip），用sniffer伪造arp包向b机发包，b机不断提示ip冲突；
2）按照vista的arp包格式（源ip＝0.0.0.0），用sniffer伪造arp包向b机发包，b机不提示。
这就是最明显的区别，看来vista比xp还谦虚，它不仅让出ip，而且还不让对方发现有ip冲突，宁可牺牲自己”。

关于这个问题的详细讨论，可以参考如下链接：
http://www.netexpert.cn/viewthread.php?tid=19463&pid=125237&page=1&extra=page%3D1#pid125237

2、细心的兄弟应该会发现这样一个问题：既然是防火墙启用了针对内部办公网段的arp代理功能，使得vista在网卡加载地址期间发生了ip地址冲突，导致了vista系统机器无法访问互联网，那么，为什么xp系统在网卡加载地址期间没有出现地址冲突呢？
       实验证明：防火墙虽然启用了针对办公网段的arp代理功能，但是，防火墙只响应vista系统格式的arp请求报文，而不响应xp系统网卡加载地址时发送的免费arp报文。

阅读全文>>

标签: 疑难故障 ARP 防火墙 免费ARP ARP代理 VISTA

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

关于防火墙的arp代理功能对不同格式的arp报文的处理情况的实验

作者：易隐者 发布于：2012-9-16 10:42 Sunday 分类：网络分析

1 实验环境

       构建如下图所示的简单的实验环境即可，测试机为xp系统。 

2 实验目的

       验证防火墙的arp代理功能对不同格式（主要指xp系统免费arp格式和vista系统在网卡加载地址时发送的arp报文格式）的arp报文的响应情况。

3 实验工具

       在此实验中使用到的工具主要有：
1、wireshark，主要用于实验时的报文捕获；
2、科来网络分析系统，主要用于构造vista系统网卡加载地址时发送的arp报文。

4 实验步骤

一、验证防火墙对xp系统免费arp报文的响应情况

实验步骤：
1、配置防火墙的arp代理功能；
2、在测试机器上开启wireshark，抓取本地网卡的数据包；
3、更改测试机网卡地址，以便测试机发送免费arp报文；
4、地址更改成功后，查看数据包。
实验现象：
      通过分析数据包，我们发现，防火墙没有响应xp系统的免费arp报文。

二、验证防火墙对vista系统网卡加载地址期间发送的arp报文的响应情况

实验步骤：
1、配置防火墙的arp代理功能；
2、在测试机器上开启wireshark，抓取本地网卡的数据包；
3、使用科来网络分析系统，构造vista系统网卡加载地址期间发送的arp报文并向本地网卡发送；
4、地址更改成功后，查看数据包。
实验现象：
       通过分析数据包，我们发现，防火墙以下图所示的报文格式响应的这个arp请求报文： 

       同时，测试机弹出地址冲突提示窗口。

5 实验总结

       以上实验证明：防火墙的arp代理功能，不会响应标准的免费arp请求包，而正如七哥所说的“Vista的ARP报文似乎不符合ARP请求的规范，所以不能算做免费的ARP”，因此防火墙对vista系统网卡地址加载期间发送的arp请求包进行了回应。

阅读全文>>

标签: wireshark ARP 防火墙 科来 免费ARP ARP代理 VISTA 实验

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

非标准TCP三次握手建立连接过程一例

作者：易隐者 发布于：2012-8-17 20:23 Friday 分类：案例讨论

          我们都知道，在正常情况下的，TCP的连接建立是通过三次握手过程来完成的，如下图展示的一样:
 

我们首先来看一个正常的TCP三次握手交互过程的数据报文： 

通过wireshark的“Flow Graph”功能，我们可以清楚的看到这个TCP会话建立交互的数据据流图： 

        我在某用户现场捕获的数据报文里，发现了一个非标准的TCP三次握手过程的TCP应用，其在建立TCP连接时，在客户端确认服务器的SYN/ACK报文时，并不是仅仅回应ACK报文，而是直接回应应用数据顺带确认服务器的SYN/ACK报文，如下图所示：  

其数据流图如下所示： 

        这种非标准的TCP三次握手过程的TCP应用，能够提高TCP交互的效率，但是实际环境中并不常见，难得遇到，特写在这里供技术兄弟参考。

        以前做防火墙时，听说还存在一些非标准的TCP应用，其在交互时，并不通过SYN三次握手的方式建立连接，而是直接交互应用数据，只是到现在一直并未亲见这种非标准的TCP应用交互，现在想想，这种非标准的TCP应用真的存在吗？或许只是遇到了长期保活的TCP连接交互的情况？这个暂时还真不得而知，如果有遇到这种非标准TCP应用的交互报文的兄弟，记得跟我联系，大家一起长长见识。

阅读全文>>

标签: TCP wireshark SYN 防火墙 非标准TCP 三次握手

评论(2) 引用(0) 浏览(40636)