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

网站劫持案例分析

作者：飞鸟 发布于：2017-11-17 20:37 Friday 分类：网络安全

1.    概述

上段时间一直忙于处理大会安全保障与应急，借助公司云悉情报平台，发现并处置几十起网站被劫持的情况。对黑客SEO技术颇有感觉。正好这段时间有时间，把以前遇到比较有趣的案例和大家分享一下。里面很多技术其实早已被玩透，只是网上搜了一下并无太多这方面的介绍。所以在这里共享一下相关的案例，案例主要分享一下思路。

1.1    ...

阅读全文>>

标签: 日志 wireshark 安全 抓包 ACK 页面劫持 劫持 网站劫持 JS劫持 服务器劫持 SEO 黑帽 黑帽SEO 寄生虫程序 云悉 UA判断 referer判断 劫持分析 劫持案例

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

TCP确认机制异常案例

作者：易隐者 发布于：2012-12-8 15:06 Saturday 分类：案例讨论

缘起
        一个好友通过Sina微博转发了一个兄弟的问题给我，其问题如下：
“AB机器tcp，A发送100字节给B，B返回数据但是其ACK=1，这期间A均正确ACK B的所有序列号，B置FIN位，A发 FIN+ACK 给B，此后B返回的ACK=2，那么此时A是应该重传之前的99字节，还是直接重传之前的FIN+ACK包给B？”。

       通过这样的描述我认为这在实际环境中应该不会存在，结果这个兄弟告诉我是在实际环境中发生的，并将交互的报文传一份给我。

       好奇之余，对这个报文进行了仔细的分析，接下来跟我一起来看一下整个分析的过程。

分析产生这个交互的原因

       选取其中一个TCP会话，查看其具体的报文交互情况，如下图所示： 

点击查看原图

       这个报文交互的情况截图结合下面的TCP交互流图一起，看起来更清晰一些：

点击查看原图

        通过交互报文的解码，我们可以清晰的看到，服务器192.168.104.229已经对客户端发送的get请求作出了应用层的响应，如下图所示：

点击查看原图

       其响应为：HTTP/1.0 403 Forbdden
       但是其ACK号却为1，接收并处理了客户端的应用请求报文，但却并未对其进行确认，这充分证明服务器192.168.114.229的TCP确认机制出现了异常！

       我们再来一起看看客户端主动发送FIN报文之后的交互情况：
 点击查看原图
       客户端在发送FIN报文之后，服务器的ACK号变为2，这对于客户端来说，这是对其应用字段的确认，这说明服务器端仅收到客户端1字节的应用字段，因此客户端将剩下的303字节的应用字段放在FIN报文中一起发给服务器端，而服务器在收到这个报文后，回应客户端的ACK号变为3，客户端接着将剩下的302字节的应用字段放在FIN报文中再次重传给服务器端，如此反复。
       至此，我们已经能够意识到，服务器端的ACK确认并不是针对客户端的应用字段的，而是针对客户端的FIN报文的，服务器的确认机制出现了异常，服务器不再确认客户端的应用字段，而只确认客户端的SYN报文和FIN报文。

分析结论

       此问题产生的原因为：服务器的TCP确认机制出现异常，其只确认SYN报文和FIN报文而不对应用数据进行确认。

       另外，我们还留意到一个有意思的现象：正常情况下，端系统一般都会在发送的数据段获得对端确认之后，才会主动发送FIN报文，释放TCP连接，如果在多次重传之后仍未得到对端的确认，通常会向对端发送RST报文，异常释放TCP连接，但是此处可能为了提高交互的效率，客户端与服务器在发送的数据段未收到对端的确认报文就主动发送FIN报文释放TCP连接。

阅读全文>>

标签: TCP SYN FIN ACK TCP确认机制

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

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

经受时延的确认（Delay ACK）

作者：易隐者 发布于：2012-9-12 21:05 Wednesday 分类：网络分析

       通常TCP在接收到数据时并不立即发送ACK，相反，它推迟发送，以便将ACK与需要沿该方向发送的数据一起发送（有时称这种现象为数据捎带ACK），这样做的目的是尽量减少发往网络的报文，以提高传输的效率，节省网络资源。

经受时延的确认工作过程

      下图清晰的展示了Delay ACK的工作过程：

点击查看原图


       我们一起来看一个实际环境中的Delay ACK实例： 

点击查看原图

 

Delay ACK与响应时间

       在实际工作环境下，我们做应用性能分析时，有时会遇到应用程序处理时间较长（一般超过200ms）时，我们经常会看到服务器先向对端发送了TCP ACK报文（无应用层数据），这个确认的报文一般就是TCP的Delay ACK，如下图所示： 

点击查看原图

       我们在遇到此类现象时，千万不能简单的将此处的Delay ACK当成应用响应时间。

Delay ACK的可能影响

       另外需要注意的是，Delay ACK虽然能够提高传输效率，节约网络资源，但是在某些情况下，其会给应用带来难以想象的延时问题（假想一下这样的场景：服务器单向向客户端间歇发送一些数据，但是客户端无应用数据需要提交给对方，此时，如果客户端每收到对端包含有应用字段的报文时，都等待200ms才对其进行确认，那么如果服务器与客户端的交互次数为1000的话，那么整个应用交易或应用会话将要持续1000*200=200S，而200秒对于绝大多数的应用来说是不可接受的）。

Delay ACK补充

1，绝大多数实现采用的时延为200ms，也就是说，TCP将以最大200ms的时延等待是否有数据一起发送，但是这个200ms的值并不是必须的，开发者可以根据自己的需要来设定这个数值，因此，我们在实际工作过程如果发现非200ms但是工作机制与Delay ACK一致的TCP交互过程，那基本上就是Delay ACK机制了。

2，如果连续收到对端两个数据段，则一般立即回应ACK数据包，如下图所示：

点击查看原图

阅读全文>>

标签: TCP 应用字段 延时 响应时间 应用响应时间 ART delay ack ACK 捎带ACK 经受时延的确认

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

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