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

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

【转】爱情就像TCP/IP

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

Tater，一个93年的开发者（忽然发现我们都老了）。

阅读全文>>

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

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

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

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

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

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

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

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

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

该RST报文ACK位是置一的，因此这个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同时掉线的现象。

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

简单总结：

阅读全文>>

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

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