C：数据收发行为检测
HTTP 隧 道 可 以 分 为 非 专 业 个 人 开 发 的 和 专 业 性 开 发 的 两 种 。HTTP-TunnelClient.exe 属于专业性开发的隧道，在反探测方面作了许多考究。而其他各种个人开发的 HTTP 隧道就并没有这么多的考究。它或者在协议头部信息上，或者在数据收发行为上都会出现不同程度的可测出的异常。这里，我们还是以浏览器的 HTTP 包收发行为作为衡量标准，把跟它的差异叫做异常。从收发行为上分析，未经改良的 HTTP 隧道会存在如下两小节所述的两个特点
1、未经改良的 HTTP 隧道为了缩短收发延时，会采取“即来即发”的方式接受和发送数据包。“即来即发”指的是在一条本地（远程）连接上一接受到一个数据包，就马上用 HTTP 协议头打包（对于远程来的 HTTP 包，就马上拆封还原数据），紧接着把这个封包（原数据）马上又发送到远程主机（本地主机）。也就是说这一系列动作是连续发生的，中间没有其他诸如缓冲之类的行为参与。事实上，大部分隧道都会采取这种行为。特别是在不清楚哪个进程使用隧道的时候，隧道软件为了尽可能实现其透明性，保证进程和远程主机通信的流畅，都会采取这种“即来即发”的行为模式。从接受到一个数据包，到处理完后把这个数据包发送出去所经历的时间，对于未改良 HTTP 隧道而言，一般不会超过 3 秒，偶尔由于系统资源调度原因会超过 5 秒，但可能性非常小。因此，当我们在 3 秒内检测 HTTP隧道的收发数据包比率的话，理论上就会得到很接近 1:1 的比值（虽然按这种收发行为工作的 HTTP 隧道应该体现出收发数据包比为定值 1:1，但实际中会因为偶发的异常原因或其他原因，如系统资源调度等，致使我们的样本采集会在一些收发包上出现较大误差，故这个比值不是定值 1:1，而是接近 1:1）。另外，由于浏览器不具有 HTTP 隧道的传输模式，故不会有这种收发行为出现。这里多次强调是未经 改 良 的 HTTP 隧 道 才 会 有 这 个 比 例 。 经 过 改 良 的 HTTP 隧 道 如 HTTP-TunnelClient.exe，比如内部使用了缓存技术，它的收发包比率就不会接近1:1，而会低于这个值。HTTP-TunnelClient.exe 的开发者曾说，他的 HTTP 隧道并不是一接受到数据包就简单的打包发送出去，而是要等到约定的缓冲填满之后才发送到服务器端。实际上他是专业的 HTTP 隧道提供商，采用的是 HTTP 隧道中转模式提供服务。他们的 HTTP 隧道服务器端经常负荷很大，如果在客户端采用缓冲，等缓冲区填满了才发送，就能减小服务器端的开销。当然这一举动不只仅仅减小了服务器开销，还改变了 HTTP 隧道原有的收发数据包比率，给检测增加了难度，无疑是一举两得（虽然这样减小了服务器负荷，但是这样会影响 HTTP客户端的响应速度，影响用户的使用，所以实际上为了满足用户需要，缓冲耽搁的时间不能太长，因此改良的 HTTP 隧道收发数据包比值也不会很小或很大）。后边的试验中，将讨论一下 HTTP-TunnelClient.exe 扰乱数据收发行为检测的情况。我们后边将讨论的检测方法并不是把样本和比值 1:1 对照，而是仍然和浏览器的比值对照来求差异。这样就要求 HTTP 隧道又要再一次消耗自己效率去模仿浏览器才能避过检测。目前，除很少部分 HTTP 隧道外，大部分都是个人为了某种意图而开发的,不会考虑打包的过程中诸如增加许多缓冲的情况，故都会很大程度上落
入上面所提到的收发行为之中去。下一节讨论的检测方法，就是在这个行为模式的基础上，结合浏览器样本实现检测的
1、本地连接上传输的数据尺寸总和小于远程连接上传输的数据尺寸总和的可能性大。本地连接就是 HTTP 隧道进程和本地某一进程的连接。远程连接就是 HTTP隧道进程和远程 HTTP 隧道进程的连接。直观上讲，由于本地连接上传输的是原数据，远程连接上传输的是增加了 HTTP 协议头部的数据，所以远程连接上传输的数据比本地连接上传输的数据尺寸总和要大。对于许多未经改良的 HTTP 隧道来说，这的确是一个很明显的特征。但是对于经过加密或压缩后的数据，就不能体现这个特征了。一是因为它间接的和加密或压缩等具体的数据处理方法相联系，失去了通用性，二是如果采用本地和远程连接的数据包尺寸总和比较大小的方法来求可疑度，由于只有两种选择（不大就小），且不能通过两方面数据包尺寸总和之差距来衡量可疑度大小（HTTP 隧道封包时头部加得多或少完全是作者自己的随机意图，也就是说就算远程连接上的数据包总尺寸比本地连接上的数据包总尺寸大 1000 倍，都不能说它比两方面之比只大 1 倍的更具高的可疑度，因为大多少完全是随机的，不能去用可疑度量化），因此就不能用来求对象进程的可疑度。总之，但对大部分未采用加密和压缩的 HTTP 隧道来说，这个特征是非常显著的。
分析模块中暂时分了8个模块 Http_changecaseAnalyse();//大小写变换 Http_headchangeAnalyse();//Http协议头部利用空格字符与制表符进行隐蔽信道的构建 Http_headmaxerroAnalyse();//http协议搭配错误 Http_methodmaxerroAnalyse();//http方法统计 Http_autographAnalyse();//http协议签名统计 Http_headorderAnalyse();//http协议头部的顺序统计 Http_headAcceptAnalyse();//http协议的头部的Accept字段接受文件的类型统计 Http_AddheadAnalyse();//http协议头部信息的重新添加
在这每个模块中，分别对我们的数据进行判断处理，分析出在数据中是否会存在可疑的地方，然后给出报警信息，在大小写变换与空格符制表符调制信息这一类的隐蔽信道的构建过程的检测中，目前做了基于单个节点的统计（这里估计会有重复的信息报出，原因我已经给出（我是替换了数据包中所有的某一头部标志字段，所以会存在这样的情况）），在会话中，如果存在这样的信息，我们就给出预警信息，并且简单的给出相应的调制信息，在后面的针对协议头部顺序，重新添加头部信息这一类的报警模块，是针对会话来报警，即在会话结束后，我们再给出报警信息。详细的操作在代码中有相应的注释