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

PSH|RST同置位，系统应用共沉寂!

作者：易隐者 发布于：2014-2-7 14:34 Friday 分类：案例讨论

       年前一位技术兄弟维护的站点遇到异常流量，导致无法正常访问站点。其将捕获到的报文发给我，让我帮其分析一下大致是什么情况。年前杂事较多，未来得及写分析文档，年后将未完成的部分补充完全，放在此供各位兄弟讨论。

       我首先查看其TCP会话数较多（8500多个），而且大部分的TCP会话是219.140.167.122与X.X.254.18之间产生的，并且这些会话具有较为明显的流量特征，如下图所示： 

       我们在报文 中任意查看其中一个TCP会话的交互报文，如下图： 

       我们可以发现，其在完成三次握手之后，219.140.167.122主机与X.X.254.18发起了一个PSH、RST同时置一的报文，如下图：

       这个报文的解码和follow TCP Stream显示其为一个http  get请求报文，如下： 

       将其解码，如下： 

        可见这是一个针对站点某个pdf文档进行访问的操作。

        在这个TCP交互过程中，我们可发现服务器在收到这个PSH、RST位同时置一的get请求之后，并没有立即RST释放这个TCP连接，而是在72秒之后，服务器才向客户端发送RST报文释放该TCP连接。

        一般情况下，在收到RST报文之后，系统传输层会立即释放对应的TCP连接，为什么要等到72秒之后才发送RST报文呢？TCP协议栈在收到PSH，RST位同时置一的报文时，应该如何处理？？

       Google百度均未找到相关的说明资料。

       我们不妨自己先大胆推测一下服务器在收到PSH、RST位同时置一的报文时时如何处理。
三种假设：
1，如果服务器先处理RST位，则服务器端会立即释放相关的TCP连接表信息。PSH位置一应该会失去应有的意义，传输层不会将客户端的应用字段递交给应用层处理。
2，如果服务器先处理PSH位，后处理RST位，则服务器将get请求提交应用层之后，释放TCP连接。服务器及时向应用层在处理完客户端的get请求之后，应用层向传输层提交应用层响应数据，这时，会发现在服务器传输层已有的TCP连接表信息中找不到对应的TCP连接，传输层向应用层报错，应用层放弃。
3，如果服务器先处理PSH位，忽略RST位，则服务器会将应用层的响应字段正常发送给客户端。

       我们再来仔细的看看上述报文交互的情况：

       我们可以发现，服务器在72秒之后向客户端发送的RST报文其ACK位是置一的，ACK相对确认号是1，这说明这个RST报文发送出来的时候，服务器端的TCP连接表信息是正常的，并且传输层并未处理PSH、RST位置一的报文，否则ACK相对确认号应该是805而不是我们看到的1。

        我们再来看一下这个服务器发送的RST报文的解码，如下图所示： 

        该报文TTL=64，可说明两点：

1，这个报文的确是服务器发送的，不会是第三方进行TCP会话劫持伪造发送的；

2，这个服务器可能是linux的服务器。

       上面的这些说明了什么呢？

       我个人认为，造成上述情况出现的原因是服务器过滤了RST位置一的报文！

       服务器要做到对TCP标识位进行过滤并不是一件难事，iptables就可以。iptables如下命令即可实现对RST位置一报文的过滤：
　　iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP

       服务器过滤了PSH/RST位置一的报文，它不管PSH是否置一，因此那个客户端发送给服务器的PSH/RST位置一的http get报文并未被服务器传输层收到，服务器传输层在等待了72秒未收到客户端的任何请求之后，主动RST释放了这个TCP连接。

       这些流量特征一致的TCP会话基本都是一样的，在三次握手建立TCP连接之后，向服务器发送PSH、RST位同时置一的http get请求报文，如下图所示：  

       客户端短时间内大量的这种报文，导致服务器的连接表骤增而在一定时间内难以释放，从而给服务器造成了DOS攻击的效果。

阅读全文>>

标签: TCP RST TTL get push DOS攻击 连接表 异常流量 HTTP PSH RST过滤 iptables PSH/RST位同时置一

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

由TCP保活引起的业务访问故障案例

作者：易隐者 发布于：2012-12-7 15:18 Friday 分类：网络分析

1 故障环境

1.1  故障拓扑

       故障发生的网络拓扑结构如下图所示： 

1.2  业务报文交互路径

1，客户端通过网闸映射地址218.X.X.151访问内部业务服务器10.X.X.209；
2，客户端经过网闸后，源地址变为网闸内口地址10.X.X.160访问真实的业务服务器。

2  故障现象

       故障现象主要表现为：
 客户端访问业务服务器出现中断现象，并且故障基本都发生是在夜间12点以后；
 第二天重启网闸后，业务访问恢复正常，但是到夜间12点左右业务连接会再次中断；
 在业务访问出现中断以后，偶尔会不定时的可以成功进行连接，但是持续时间不长就再次中断；
 仅此业务应用存在这个异常，其他的业务基本正常。

3 故障分析

3.1 分析思路

       考虑到故障都发生在夜间12点左右，因此在网闸内外网口同时部署网络分析产品，对内外网口交互的报文进行长时间的捕获存储，第二天，我们分别选取故障发生时间内的报文进行关联分析和对比分析。

3.2 分析过程

3.2.1 异常出现时，网闸外口的报文交互情况
       我们选取故障发生时，网闸外网口的交互报文进行查看，我们在“TCP会话”视图中，发现了大量交互报文少、流量小、收发报文特征明显的TCP会话，如下图所示： 

       我们选取其中任意一个TCP会话，查看其详细的报文交互情况，如下图所示： 

       我们可以清楚地看到，客户端与服务器映射的外网地址通过三次握手建立TCP连接之后，服务器映射地址立即向客户端发送了FIN报文，主动释放TCP连接，后续的带有应用字段的客户端报文到达后，服务器直接向客户端回应RST报文。
       我们查看了其他的TCP会话的详细报文交互情况，基本与上述情况一样。由此来看，似乎是网闸主动发送FIN报文导致了业务应用出现异常，网闸为什么会在已经建立三次握手之后立即主动发送FIN报文呢？难道是服务器主动发送的FIN报文？或者是网闸的BUG导致网闸主动发送FIN报文？我们需要在内网端做个关联对比分析才能确定。

3.2.2 在网闸内口发现保活报文
       当我们取故障时内网的报文时，发现内网在做捕包存储时出现异常，抓包工具在故障出现之前崩溃了，并未将故障发生时的网闸内口报文捕获保存下来，而由于时间紧急，我们没有机会再花费一天的时间去捕获内网的报文，这些故障现场的不确定性现象发生了，我们只能抓取当下的网闸内口报文进行辅助分析。
       我们在网闸内网口抓包发现大量的特征明显的TCP会话，如下图所示：

       这些TCP会话仅有几个报文的交互，不像正常的业务数据交互报文，我们选择其中一个TCP会话查看其具体的交互报文，如下图所示： 

       这是服务器发给客户端的报文，下面是客户端给服务器的报文： 

       结合这两个报文，我们可以肯定，这是一个TCP保活报文。这些仅交互2个报文的TCP会话是服务器发给客户端的TCP保活行为！

3.2.3合理推测
       这些数量众多的保活行为的TCP会话，引起了我们的关注，那么是否是保活行为导致业务应用出现问题呢？保活的功能之一是维持已有TCP连接，关于TCP保活的详尽描述大家可参考我博客的文章《TCP保活（TCP keepalive）》。
       TCP保活的这个特性很自然的让我们想到可能是TCP保活功能引起网闸连接表满从而导致业务异常。但是网闸作为一个网关类设备一般都支持几十万甚至数百万的连接数，在无异常攻击报文的情况下不至于24小时连接表就全部满了，并且也只有这个业务应用出现异常，其他应用都是正常的。
       我们发现外网的客户端访问到内网时，其源地址全部转换为网闸内口地址10.X.X.160，至此我们恍然大悟：源IP、源端口、目的IP、目的端口、协议类型等五元组信息决定一个连接，而在网闸内口，源IP、目的IP、目的端口、协议类型都已经确定，只有源端口是变换的，而端口范围只能在0-65535之间，还要去除一些常用的端口，如此一来，网闸内口跟服务器之间能够建立的TCP连接数只能在65535以内！
       在这种情况下，客户端访问业务服务器的TCP连接在24小时内达到近65535个，从而导致后续的客户端与业务服务器无法正常建立连接，引起业务访问故障。
       至于故障后又能偶尔连接正常但很快再次异常的原因也很好解释，那就是网闸内口在维护如此众多的连接时，总会由于各种原因导致几个连接异常释放，如此一来则紧接着的业务访问连接会正常建立，但是一旦用完为数不多的几个连接后，后续的业务连接将再次出现异常。
       整个交互过程涉及到的客户端、网闸外口、网闸内口、服务器的状态变化如下图所示： 

3.2.4验证
       我们建议用户在下班后手动清空网闸内口已有连接，观察夜间12点故障是否出现来验证我们的推测。后经用户反馈，在清空连接后夜间12点左右故障未再现，如此充分证明我们上述的推测是正确的。

3.3 分析结论

       服务器端设置了TCP保活功能，对所有的TCP连接主动实行TCP保活探测，这导致网闸内口与服务器建立的TCP连接无法得到释放，在24小时以内，TCP连接数接近65535个，而此时客户端再次发起与服务器之间的业务连接之后，网闸内口已经无法再与服务器新建TCP连接，如此导致业务连接无法建立。

4 故障解决

       在找到导致此业务故障的真正原因之后，我们就可以对症下药，通过任意选择如下几种方式之一来彻底解决这个故障：
1， 可以在服务器上关闭TCP保活功能；
2， 在网闸内口关闭源地址转换（SNAT）功能；
3， 将网闸内口TCP连接释放时间调整至小于服务器发送TCP保活的间隔时间，这样可以在服务器发送保活报文之前，让网闸内口提前释放该连接；
4， 网闸内口使用TCP连接复用功能，让大部分的外网客户端访问连接仅通过少量的内部连接实现正常的业务交互，而服务器则可以与网闸内口之间少量连接保持保活。

阅读全文>>

标签: 疑难故障 五元组 连接表 TCP保活 TCP keepalive 连接复用 网闸 SNAT

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

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

多次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) 浏览(37056)

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