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

MOTS攻击之TCP攻击

作者:飞鸟 发布于:2017-11-15 21:08 Wednesday 分类:网络安全

1.  概述

继续进行MOTS类型攻击方式的进展。这里再次强调一下,MOTS是指Man-On-The-Side,是一种在旁路监听模式下的攻击方式;MITM不同,MITM是指Man-In-The-Middle,是中间人攻击。MOTS其原理是监听与构造响应数据包,并在正常数据包返回之前插入伪造的数据包。其实现的核心条件是TCP/IP协议本身实现时并没有考虑这方面的安全问题。MOTS...

阅读全文>>

标签: TCP RST reset MOTS 旁路中间人攻击 TCP劫持 中间人

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

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

【转】爱情就像TCP/IP

作者:易隐者 发布于:2014-2-6 21:44 Thursday 分类:其 他

【说在之前】
蛮有意思的小文,转载至此,供各位一乐。
【原文链接】:
http://www.lijingquan.net/love-to-ansy-tcpip.html
【原文作者】:

Tater,一个93年的开发者(忽然发现我们都老了)。


    第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;

    第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入 SYN_RECV状态;

    第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

    完成三次握手,客户端与服务器开始传送数据。

    四次握手用来关闭已建立的TCP连接。有时,如果主机需要尽快关闭连接(或连接超时,端口或主机不可达),RST (Reset)包将被发送。由于RST包不是TCP连接中的必须部分,可以只发送RST包(即不带ACK标记)。
  
    一心想要握手成功,却被RST的男人是彻底的杯具...

    暗恋是发送未知单播报文,杳无音讯,却期待总有一天,对方能够回应,那就变成已知单播了;

    花心就是发送多播和广播报文,贪心地想flooding所有的端口;

    Ping MM,Request timed out

    Ping Money,Request timed out

    有时候需要加上“-t”,总会Ping通的。(-t是持续进行的意思)

»版权所有© TaterLi → 《爱情就像TCP/IP》;
»本文网址:http://www.lijingquan.net/love-to-ansy-tcpip.html
»除特别标注,本博客所有文章均为原创. 互联分享,尊重版权,转载请以链接形式标明本文地址。

阅读全文>>

标签: TCP RST 三次握手 TCP/IP

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

服务器经网关地址映射访问时的注意事项

作者:易隐者 发布于:2013-6-20 22:05 Thursday 分类:网络分析

        有朋友在用户现场遇到一个故障无法定位,网上找我帮忙,大概情况是某内网用户将一台服务器端口映射出去供互联网访问,内部主机通过互联网地址进行访问测试时,发现无法正常连接。

       我让其在服务器区域前端防火墙上抓客户端与服务器交互的报文,如下:

10:33:28.747771 R@eth3 IP 172.16.7.68.8525 > 172.16.2.146.3389: S 3134287530:31
34287530(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//客户端发起SYN请求
10:33:28.747786 X@eth4 IP 172.16.7.68.8525 > 172.16.2.146.3389: S 3134287530:313
4287530(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//防火墙内口转发客户端的SYN请求
10:33:28.748165 R@eth4 IP 172.16.2.146.3389 > 172.16.7.68.8525: S 3568427973:356
8427973(0) ack 3134287531 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//服务器响应客户端的SYN报文
g10:33:28.748172 X@eth3 IP 172.16.2.146.3389 > 172.16.7.68.8525: S 3568427973:356
8427973(0) ack 3134287531 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//防火墙转发服务器响应报文
10:33:28.749519 R@eth3 IP 172.16.7.68.8525 > 172.16.2.146.3389: R 3134287531:313
4287531(0) win 0
10:33:28.749523 X@eth4 IP 172.16.7.68.8525 > 172.16.2.146.3389: R 3134287531:313
4287531(0) win 0
//客户端发送RST报文

       客户端发起SYN连接请求,防火墙转发,服务器响应SYN/ACK报文,这个过程都是正常的,但是紧接着却是客户端发送RST报文,异常释放了这个TCP连接。单从这个数据包交互的过程来看,大部分的人都会认为是客户端的问题。

       但是其实跟客户端完全无关。我很早以前在天融信做工程师时曾今在用户 处遇到过同类型的问题,当时解决完之后曾打算将其作为一个经典案例写下来供大家分享,后来由于时间问题,拖时间长了,原始报文找不到了,只能作罢,今天就 这个案例,我来做一个简单的分析和说明,以供大家参考。

        我们在用户现场经常会遇到这样的客户需求:

1,用户希望通过通过防火墙等设备的端口映射/地址映射功能实现内网服务器对互联网访问者提供服务的需求;

2,为了使用方便,用户一般都会同时要求内部客户端也可以直接通过服务器映射后的互联网地址进行访问。

       第一点需求非常容易实现,在防火墙上做一个常规的地址映射/端口映射,再将服务器对外提供服务的端口放行即可。但是在实现用户第二点需求时,我们需要注意一个关键的问题,那就是客户端与服务器端的报文来回路径不一致问题。

        我们先将故障发生时的报文互过程跟大家一起分析一下,其交互过程大致如下图所示:
 点击查看原图
       这个交互的过程具体描述如下:
1)    客户端访问经网关设备映射出去的服务器的互联网地址,向其发送SYN报文;
2)    客户端访问的目的地址经网关转换为内网服务器真实地址之后,转发至内网服务器,此时报文的源IP地址是真实的内网地址(另外一种处理情况为出口网关将该报 文经NAT后至转发出互联网接口,然后再匹配识别为内网服务器的映射的策略,再次将该报文转发至内网服务器,此时报文的原IP、目的IP地址均发生变化 了,此种情况下由于报文原IP地址已经改变为NAT后的互联网地址,因此不在我们的讨论的范畴之内,这个跟网关设备对数据报文处理的流程有关,在此不详细 讨论,有兴趣的同学可仔细思考思考。);
3)    内网服务器在接受到这个报文之后,直接向客户端内网IP发送SYN/ACK报文;
4)    内网客户端接收到服务器的SYN/ACK报文,但是客户端的TCP连接表中并没有与之相应的信息(因为客户端是与服务器映射后的互联网地址发送SYN请求报文的),因此,客户端向服务器发送RST报文。

5)    服务器端收到这个RST报文之后,其会将这个TCP连接释放,因此客户端连接服务器失败。

       那么,在这种情况下,我们如何解决这个问题呢?

       其实,解决的方式就是在网关处增加一条源地址转换策略,将访问服务器的客户端地址转换为一个互联网地址或网关内部接口地址,如此巧妙的让服务器回包给网关(防火墙),从而保证客户端、服务器的报文来回路径一致。

       NAT在很多复杂环境下的确能够帮助我们巧妙的解决很多令人头疼的问题,我在博客文章某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例》中曾今在文章后面留下一个思考问题,至今无人应答,我也没给出答案,其实答案就是NAT。有兴趣的兄弟自行去查看那篇文章吧,在此我不做展开了,当然NAT也可能会带来一些意想不到的问题,以前遇到过一个案例,等我有空的时候再整理发布吧。

       这个用户现场案例,我们通过在防火墙中增加一条源地址转化策略之后,再次以互联网地址访问服务器,正常,数据包交互如下:

10:37:54.637923 R@eth3 IP 172.16.5.253.9182 > 172.16.2.146.3389: S 223750126:
223750126(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
10:37:54.637943 X@eth4 IP 172.16.5.253.9182 > 172.16.2.146.3389: S 223750126:223
750126(0) win 58400 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//客户端发起SYN报文
10:37:54.638373 R@eth4 IP 172.16.2.146.3389 > 172.16.5.253.9182: S 892121112:892
121112(0) ack 223750127 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
10:37:54.638379 X@eth3 IP 172.16.2.146.3389 > 172.16.5.253.9182: S 892121112:892
121112(0) ack 223750127 win 16384 <mss 1460,nop,wscale 0,nop,nop,sackOK>
//服务器响应SYN报文
10:37:54.639048 R@eth3 IP 172.16.5.253.9182 > 172.16.2.146.3389: . ack 1 win 584
00
10:37:54.639052 X@eth4 IP 172.16.5.253.9182 > 172.16.2.146.3389: . ack 1 win 584
00

//客户端确认,连接建立   

        这个案例就到这吧,大家自己多去体会。

阅读全文>>

标签: TCP RST SYN 防火墙 NAT 地址转换 网关 来回路径不一致 映射

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

《某公司QQ掉线分析案例》之我见

作者:易隐者 发布于:2013-4-14 17:52 Sunday 分类:案例讨论

       前段时间看到CSNA论坛上有一篇QQ掉线故障分析的案例,原文是PDF格式的,我就不转载其全文了,其链接如下 : http://www.csna.cn/network-analyst-50520-1-1.html,大家可自行通过上述链接下载查看。

       大致看了分析过程之后,觉得其中存在一些疑问,特地找时间针对这个案例做一个大致的分析,以便大家讨论参考。原本准备做相关交互图示的,由于个人时间问题,这次就免了,还望各位见谅。

1, QQ多人同时掉线,大约1秒就自动连上,浏览网页和其他应用没有问题  

       QQ属于一种终端的应用,一般情况下,局域网内某应用出现同时掉线、缓慢等问题,基本上可以排除是单个终端的问题,因为从这个现象上来看,这是一个全局问题,可能是业务应用本身、业务服务器或者承载业务的网络系统出现了问题。在此故障分析案例中,作者提到QQ同时掉线但是浏览网页和其他应用没有问题。通过这个故障现象的描述,我个人首先可能会想到整个互联网出口是否会出现网络瞬间中断的情况?这是我个人的猜想,因为如果真是互联网出口出现网络瞬间中断,那么HTTP等基于TCP的应用由于TCP的重传机制,在出口网络中断1秒左右的时间内,终端使用者不会有明显的异常感受,而基于UDP等应用,可能会出现掉线等现象,在网络出口恢复正常之后,QQ再次自动上线。这个猜想的原因至少可以很好的解释该案例作者一开始描述的故障现象。

2, QQ掉线是QQ服务器主动RST连接导致的,腾讯给出的解释是由于用户端IP地址出现了变化。

1),QQ大部分情况下应该是使用UDP协议的,少数情况下使用TCP协议。

       QQ是一个较为复杂的应用,其为了满足使用者在各种复杂的环境对QQ的正常使用,其会存在多种模式和网络交互行为,大部分情况下,QQ默认会使用UDP协议进行交互,少数情况下会使用TCP甚至TCP的80端口、443端口进行交互,特殊情况下,根据需要和设置,其还可以通过代理的方式进行交互。

       正是QQ这种特殊应用工作机制的多样性和复杂性,导致我们在遇到其故障时,给我们的分析定位带来了难度。在该案例中,由于QQ是大规模的出现掉线现象,我们在分析处理时,其实根本搞不清楚不同使用者的QQ到底是工作在何种模式之下,其网络行为特征千差万别,因此,我们很难通过某一台测试机来全面分析验证QQ故障的原因。

       在该案例中,测试机的QQ似乎使用的是TCP443端口进行交互的,但其实绝大部分情况下,QQ都是基于UDP协议进行交互的。因此在此案例中,按照我个人较为严谨的分析习惯,测试机的选择非常值得做进一步的商榷。

2),就算这个客户网络中所有使用的QQ都是基于TCP协议的,如果真是如腾讯所说,是由于QQ服务器发现用户IP出现了变化,才向客户端发送RST报文的,那么:

       其一,不同的QQ客户端与QQ服务器是单独建立连接的,暂且不论QQ服务器的多样性(不同的QQ客户端很可能会与网络中的N个不同的QQ服务器之间建立交互链接),不同的QQ客户端与QQ服务器之间建立不同的交互连接,那么即使防火墙在做NAT时出现BUG,突然改变了某些已有连接的源IP地址,也应该绝少出现同时改变N个不同QQ客户端与服务器之间已有连接的源IP,换句话说,如果原因真是如该案例作者所说,很难解释QQ同时掉线的现象。
       其二,那么我们站在QQ服务器的角度来分析一下此种情况真的发生时,QQ服务器会作何处理?QQ服务器收到源IP地址变化的QQ客户端报文后,QQ服务器会把他作为一个新的TCP连接来处理(因为五元组不一样),而QQ服务器并没有这个TCP连接信息,因此服务器会直接RST该报文,而这种RST报文,其ACK位肯定不会置一的,但是我们看到这个案例中作者的截图如下:
 点击查看原图

该RST报文ACK位是置一的,因此这个RST报文并不是如作者想象的情况下产生的。

       其三,我们再来看另外一张截图:

点击查看原图
        看此交互截图,QQ服务器已经对客户端的报文作出了确认(序号2230的包),紧接着(0.000045秒后),QQ服务器向客户端发送RST报文(序号 2232的包),这个报文可以肯定在服务器紧接着发出序号2230的包之后发出的,如果按照作者的说法,RST报文至少应该是序号为2231的客户端报文经防火墙源地址转换之后(源IP变化),到达QQ服务器,QQ服务器发现源地址变化,再向客户端发送RST报文,这样整个过程方才合理,但是上面这张截图已经充分说明:事实并非如此。

3,如果真的是防火墙的NAT出现了这种低级的错误和BUG,那么对用户影响最大的应该是HTTP等基于TCP应用。因为很多HTTP应用的动态口令、验证码等都需要通过数个不同的TCP连接与服务器进行交互,一旦出现该案例作者所说的防火墙处理BUG,将导致这些应用出现访问故障。而不会仅仅是无关紧要的QQ应用出现问题。

4,QQ掉线而其他TCP应用正常,很可能是防火墙的UDP会话保持时间过短导致的。

       因为很多人挂QQ并不一直与好友聊天。而一般情况下,防火墙等为节约设备资源,会将UDP的会话超时时间设置为一个较短的数值,如60秒,那么如果用户在这个超时时间内无任何数据交互的话,防火墙会将这个UDP会话从防火墙连接表中删除,当QQ客户端再次尝试与QQ服务器交互时,其发送的QQ状态更新报文就会被防火墙丢弃,导致QQ客户端掉线。QQ掉线后,客户端会再次发起新的连接,此时防火墙将其作为一个新建的UDP连接进行处理,QQ因此再次成功上线。当然这个很难解释QQ同时掉线的现象。

       另外一种情况是,如果防火墙的UDP连接表出现异常,防火墙突然清空其UDP连接表,也可能会导致该案例中故障现象的产生。

5,在NAT POOL情况下,NAT设备会根据不同的算法(基于源IP的、基于连接的等)实现NAT POOL的地址复用,大部分算法应该都是基于源IP等计算的,如果是基于数据包、连接等进行计算,则很可能会导致各种问题的产生,我以前有一个非常经典的案例——《移动无线VPN客户端隧道建立故障分析》,下次我发布到我的博客,大家可去参考。 

简单总结:

       防火墙在NATPOOL情况下,变化地址是正常的,关键看防火墙的NAT算法。QQ掉线应该跟这个无关,案例中分析来自于QQ服务器的RST报文跟NAT后源地址变化无关。

阅读全文>>

标签: TCP RST 五元组 重传机制 防火墙 BUG NAT QQ掉线

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

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