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

TCP保活（TCP keepalive）

作者：易隐者 发布于：2012-10-15 11:30 Monday 分类：网络分析

TCP保活的缘起

       双方建立交互的连接，但是并不是一直存在数据交互，有些连接会在数据交互完毕后，主动释放连接，而有些不会，那么在长时间无数据交互的时间段内，交互双方都有可能出现掉电、死机、异常重启等各种意外，当这些意外发生之后，这些TCP连接并未来得及正常释放，那么，连接的另一方并不知道对端的情况，它会一直维护这个连接，长时间的积累会导致非常多的半打开连接，造成端系统资源的消耗和浪费，为了解决这个问题，在传输层可以利用TCP的保活报文来实现。

TCP保活的作用

1， 探测连接的对端是否存活
        在应用交互的过程中，可能存在以下几种情况：
（1）， 客户端或服务器端意外断电、死机、崩溃、重启
（2）， 中间网络已经中断，而客户端与服务器端并不知道
        利用保活探测功能，可以探知这种对端的意外情况，从而保证在意外发生时，可以释放半打开的TCP连接。

2， 防止中间设备因超时删除连接相关的连接表

       中间设备如防火墙等，会为经过它的数据报文建立相关的连接信息表，并为其设置一个超时时间的定时器，如果超出预定时间，某连接无任何报文交互的话，中间设备会将该连接信息从表中删除，在删除后，再有应用报文过来时，中间设备将丢弃该报文，从而导致应用出现异常，这个交互的过程大致如下图所示：

       这种情况在有防火墙的应用环境下非常常见，这会给某些长时间无数据交互但是又要长时间维持连接的应用（如数据库）带来很大的影响，为了解决这个问题，应用本身或TCP可以通过保活报文来维持中间设备中该连接的信息，（也可以在中间设备上开启长连接属性或调高连接表的释放时间来解决，但是，这个影响可能较大，有机会再针对这个做详细的描述，在此不多说）。

常见应用故障场景：

       某财务应用，在客户端需要填写大量的表单数据，在客户端与服务器端建立TCP连接后，客户端终端使用者将花费几分钟甚至几十分钟填写表单相关信息，终端使用者终于填好表单所需信息后，点击“提交”按钮，结果，这个时候由于中间设备早已经将这个TCP连接从连接表中删除了，其将直接丢弃这个报文或者给客户端发送RST报文，应用故障产生，这将导致客户端终端使用者所有的工作将需要重新来过，给使用者带来极大的不便和损失。

TCP保活报文格式：

1， TCP keepalive probe报文

       我们看到，TCP保活探测报文是将之前TCP报文的序列号减1，并设置1个字节，内容为“00”的应用层数据，如下图所示：

发送keepalive probe报文之前的TCP报文

 TCP keepalive probe报文

2， TCP keepalive ACK报文

        TCP保活探测确认报文就是对保活探测报文的确认， 其报文格式如下：

TCP keepalive ACK报文

TCP保活报文交互过程

        TCP保活的交互过程大致如下图所示：

TCP保活可能带来的问题

1， 中间设备因大量保活连接，导致其连接表满

       网关设备由于保活问题，导致其连接表满，无法新建连接（XX局网闸故障案例）或性能下降严重
2， 正常连接被释放

       当连接一端在发送保活探测报文时，中间网络正好由于各种异常（如链路中断、中间设备重启等）而无法将该保活探测报文正确转发至对端时，可能会导致探测的一方释放本来正常的连接，但是这种可能情况发生的概率较小，另外，一般也可以增加保活探测报文发生的次数来减小这种情况发生的概率和影响。

TCP保活的设置

        一般而言，保活探测主要在服务器端实现，如果应用层有相应的保活机制时，传输层的TCP保活就可以不用。

        在windows系统中，我们可以通过修改注册表等来达到开启、调整保活相关
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
KeepAliveInterval
项：Tcpip\Parameters
数值类型：REG_DWORD - 时间（以毫秒为单位）
有效范围：1 - 0xFFFFFFFF
默认值：1000（1 秒）
说明：此参数确定在收到响应之前，保活重传之间的时间间隔。一旦收到一个响应，将由 KeepAliveTime 值重新控制在下一次保活传输之前的延迟。如果经过 TcpMaxDataRetransmissions 指定的重新传输次数后仍无响应，将放弃连接。
KeepAliveTime
项：Tcpip\Parameters
数值类型：REG_DWORD - 时间（以毫秒为单位）
有效范围：1 - 0xFFFFFFFF
默认值：7,200,000（两个小时）
说明：此参数控制 TCP 试图通过发送保活数据包来验证空闲连接是否仍然保持的次数。如果远程系统仍然可以连接并且正在运行，它就会响应保活传输。默认情况下不发送保活数据包。应用程序可以在连接上启用此功能。

       关于Linux、HP UNIX、IBM AIX、SUN solaris等系统keepalive参数的设置和修改，请大家自行百度谷歌，在此我就不做简单搬砖的事情了。

阅读全文>>

标签: 防火墙 保活 keepalive 连接表 TCP保活 TCP keepalive

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

网页打开慢但HTTP下载快故障分析案例

作者：易隐者 发布于：2012-10-10 16:06 Wednesday 分类：网络分析

【说在之前】：

1，用到了疑难杂症网络分析过程中最基本、最核心的两个分析方法：对比分析法和关联分析法；

2，该案例涉及到的知识点主要有SYN重传、连接数限制等，大家可参考本博客中相关知识点的文章。

【我的案例】：

故障环境

       某单位大体的网络结构如下图所示： 

内部办公人员通过交换机到流控设备，再通过防火墙做NAT访问互联网。

故障现象

1，在地矿局进行互联网时，打开网页的速度非常的慢，有的网页要刷新几次才可以正常显示；
2，但是使用下载工具或是基于HTTP的下载速度却很快。

故障分析

1 确认故障原因

        我们找一台主机，访问互联网的某网站，发现的确比较慢，我们抓取故障时的交互数据包，如下图所示： 

       通过上图，我们可以发现，客户端在与服务器建立TCP连接时，其SYN请求报文被客户端重传了一次，这个重传导致了2.88秒的延时。TCP重传一般是中间设备丢包导致的，那么到底是在什么地方丢包的呢？我们首先需要界定一下可能丢包的故障关键点。

2 选择故障关键点

       该故障环境相对简单，在办公用户访问互联网时，数据包只通过了交换机、流控设备和防火墙，而交换机主要负责转发数据，不会对数据包进行深度的检测和过滤等操作，所以在该环境下主要的关键故障点是流控设备和防火墙，如下图所示：

 

3分析流控设备是否丢包

       关键故障点确定之后，我们首先在流控设备的前后同时抓包做对比分析，以确定是否是流控设备丢包，如下图所示： 

       通过我们还原故障现象时，在流控设备前后抓取数据包的对比分析，结论显示，流控设备前后数据包交互的过程是一样的（这个对比分析通过五元组关联同一会话之后，对比查看数据交互过程的差异即可，由于流控设备前后的数据交互过程完全一样，在此不做具体详细的分析说明），这说明，在打开页面较慢时，流控设备并未丢弃任何交互的数据报文。

4 分析防火墙是否丢包

       同样，我们再在防火墙的进出口同时抓包，通过比较防火墙前后数据包的交互情况来确定造成故障的原因，部署图如下所示： 

1， 在访问某网站出现缓慢现象时，在防火墙前后同时抓取数据包，并保存，为下面的对比分析提供原始的数据报文。
2，我们先分析防火墙内网口抓取的数据，在科来网络分析系统的“TCP会话”视图，我们发现了一个web连接持续的时间为6秒，并且其在三次握手过程中，存在重传现象，如下图所示： 

这个TCP会话的源端口是1124，目的地址为58.30.236.11，目的端口是80
3，我们通过关联分析法，在进行网页访问时，我们在防火墙前后同时进行抓包，下图就是在防火墙出口处抓取到的数据包： 

       我们知道防火墙在网络运行中起到防护作用，会将未经授权的报文过滤，但是防火墙一般不会阻止正常的数据包，我们在比较上面两张图发现，在防火墙后捕获到的数据包第一次发送同步请求没有成功，然后又重传了一次同步数据包，才成功建立了连接；而在防火墙前面抓取到的数据包却没有看到重传的数据包（黑框标记的部分），这很清晰的说明，第一个SYN报文被防火墙丢弃了。

4 分析结论

       通过上面的分析，我们可以得出如下结论：

       由于防火墙在转发数据包时，随机丢弃了客户端发送的SYN报文而造成的。可能是防火墙配置不当（连接数限制）或防火墙BUG（在处理TCP新建连接时不稳定）导致的。

总结

       经过分析知道是由于防火墙不规律丢弃SYN报文导致的网页打开慢现象，但是为什么HTTP下载的速度却很快？这是因为防火墙仅随机丢弃SYN报文，而HTTP下载在刚开始建立TCP连接时，防火墙有可能会丢弃其SYN报文，但是下载行为决定其会不断发起SYN报文进行连接建立的尝试，而一旦连接建立成功，则防火墙不会丢包，给用户的感觉就是速度也非常快。

阅读全文>>

标签: TCP 对比分析法 关联分析法 丢包 SYN 防火墙 重传 BUG NAT 连接数限制 SYN报文

评论(4) 引用(0) 浏览(11889)

多次RST以及不同场景下的RST报文的差异

作者：易隐者 发布于：2012-10-9 11:27 Tuesday 分类：网络分析

      在某个TCP交互过程中，我们发现在交互的后期，客户端多次向服务器端发送RST报文，如下图所示： 

        我们首先来看客户端发出的第一个RST报文的解码： 

       RST与ACK标志位都置一了，并且具有ACK number，非常明显，这个报文在释放TCP连接的同时，完成了对前面已接收报文的确认。

       我们再来看看客户端发出的后续RST报文的解码： 

       我们可以看到，这些后续的RST报文仅Reset位置一，ACK位未置一，在这种情况下，该报文的ACK确认号应该为0，但是我们留意到在这个报文中，其ACK确认号与序列号是一致的。

       这是为什么呢？

       因为ACK位未置一，ACK确认号也就失去了意义，因此，不论ACK确认号是什么值都不会对接收端产生影响，因此大部分的系统都会将ACK确认号设置为0，之所以在这个报文中出现ACK确认号非0而是与序列号一致的情况，个人认为应该是该主机端系统的处理机制与大部分系统不一样导致的。

       另外，我们也看到了wireshark的专家系统在此处给出了提示，由此可见wireshark在传输层的专家系统的强大之处。

       为什么前后RST报文会出现这种差异？

       原因为第一个RST报文是异常释放TCP连接的，在端系统发送RST报文之前，这个TCP连接尚在端系统的连接表中，因此其ACK位置一并且具有ACK确认号。而客户端后续收到DATA报文，因其连接表中已经没有相关信息与之对应，此时客户端发送的RST报文ACK位无需置一。

       也许有朋友会问：服务器端为什么在收到客户端的RST报文后，还继续给客户端发送报文呢？

       原因只有一个，那就是TCP成块数据流。服务器端一次性向客户端发送数个数据块，在客户端发出第一个RST报文之后，后续的报文已经在网络中传输了，并陆续达到客户端。

       其交互过程大致如下： 

阅读全文>>

标签: TCP wireshark RST ACK 连接表 TCP成块数据流 端系统 ACK确认号 连接

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

端系统对RST报文的过滤

作者：易隐者 发布于：2012-10-8 17:00 Monday 分类：网络分析

       前段时间在分析网上一个兄弟传给我的报文时，发现了几个有意思的现象，我觉得值得分析讨论，我们首先来看一个服务器与客户端交互的会话： 

       在这个交互的过程中，我们可以看到一个比较奇怪的现象，那就是客户端10.16.137.56在收到来自服务器的FIN报文之后，紧接着向服务器端发送RST报文，但是服务器给其回应了一个ICMP主机管理性禁止差错报文，并且不断尝试向服务器发送FIN报文。
       我们来看一下服务器给客户端回应的ICMP主机管理性禁止差错报文的解码： 

       Type 3，Code 10——主机管理性禁止差错，其封装的原始报文报头信息显示，该ICMP差错报文正是由客户端发往服务器端的RST报文引起的。下图为客户端发往服务器端的RST报文解码： 

       另外，我们注意到，服务器发送给客户端的ICMP差错报文的TTL值为48，而服务器端发送给客户端的FIN报文报头中的TTL值也是48，如下图所示： 

       这从侧面说明这个ICMP差错报文的确是服务器端系统发送的，而不是中间设备发出的。

       那么为什么服务器端系统会过滤掉客户端的RST报文呢？

       想想TCP会话劫持和TCP RST攻击，大家就能够体会，服务器管理员为什么这么做了。

       TCP会话劫持的实施者经常会扮演对端的身份分别向客户端或服务器端发送RST报文，以达到干扰客户端与服务器端正常交互的目的。有些服务器的管理员可能遇到过这种TCP会话劫持的攻击，因此在服务器端系统上利用相关工具设置了过滤RST报文的策略，当服务器收到RST报文时，直接忽略掉，因此服务器端系统的传输层并不会收到这个RST报文。

       其交互过程大致如下图所示：

过滤RST报文可能带来的影响

       服务器传输层无法收到客户端的RST 报文，只能在多次尝试重传FIN报文直至超时，然后主动向客户端发送RST报文。如此带来的影响就是执行过滤策略的端系统无法正常处理来自于TCP连接对端的异常释放行为（RST），这将导致端系统的TCP连接释放需要更长的时间，在有大量对端通过RST报文异常释放TCP连接的场景下，可能会对性能产生一定的影响。

阅读全文>>

标签: TCP RST icmp差错 会话劫持 TTL FIN type 3 code 10 端系统

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

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