http隐蔽信道简单归纳.docxVIP

* * 隐蔽通道 Covert Channel, CC 基于 HTTP 协议构造隐蔽信道（从数据包特征，协议头部和数据收发行为） HTTP 协议语法定义较为宽松，存在着很多冗余部分，可以用来嵌入隐蔽信息 不论是怎样的 HTTP 隧道软件 ,他都必须保证有两条 TCP 连接，且服务器端一 般使用 80 或 8080 等具有迷惑性的端口（使用这种 web 服务端口只是增加 其迷惑性， HTTP 隧道并不一定必须要使用这种端口， 它可以使用任何一个可用 的端口建立连接）。HTTP 隧道客户端和服务器端的配合，有如下两种目前已实 际采用的方式 简单 http 模型 * * 1 达更清楚，只示出了两台主机上的 HTTP 隧道软件担任自己各自的功能时的 一种情况，当然反过来， A 也能扮演图中 B 的角色 ,即成为服务器， B 扮演图 中 A 的角色 ,即成为客户端，效果一样。如图所示，客户端和服务器端各自与本 地主机建立至少一条 TCP 连接。主机应用进程将原始数据发送到本机的HTTP 隧道客户端或服务器端， 经隧道软件用 HTTP 协议包装，然后发送到对方主机。 对方主机收到数据后，拆封 HTTP 包，然后把原始数据转发给本地的相应进程 代理模型 A：基于协议的检测：（基于 HTTP 协议头部标识） 协议头部的检测应该属于基于协议的检测（PROTOCOL-BASED DETECTION ）范畴。但是目前有相当一部分基于协议的检测是探测某种协议 的状态是否是处于约定的正常范围之内， 如有异常状态发生就报警。 这种检测 协议状态的方法适用于有状态的协议，如 TCP， DHCP 等协议。对于无状态 * * 的 HTTP 协议则不能使用这种检测方法。那么，我们就需要从其他方面来考 虑怎么检测 HTTP 隧道。在面对这个问题时我们都会想到从 HTTP 协议首部的异常来进行检测， 其实针对这个异常， 我们首先应明确什么是正常的状态或者说 HTTP 的头部： 在特定用户和特定环境下 ，浏览器所体现出的 HTTP 协议使用情况 一般的存在的 http 的协议隐藏信息的存在点： 1、重排序法：需要统计这些头部的各个字段的顺序（这些 host 标记位应一 致，可以根据五元组， 在一个会话里面对协议头标的顺序进行统计 （可以通过数 组的方式来存储（动态分配数组） ）） * * 2、 大小写变换法： （需要分析协议头标名称中的大小写， 正常情况协议头部信息的标识都不会异常 的，一般都会符合正常通信的规则，例如 Connection ：Keep-Alive -- 可以 改 为 ConnECtion ： Keep-Alive 即 可 代 表 0111001111 ， 或 者 是 1000110000 ，这个我们是可以不用深究它这个具体是啥意思， 只需要匹配出它 这个协议的标识不正常即可） 通过这些信息， 我们可以进行估计这些信息所传送的信息的值， 比如说上面所说 的 ConnECtion ：Keep-Alive 即可代表 0111001111 ，也就是可以代表 0x72 即 R 或者是 1000110000 ，但是这个没意思的一个值，所以很可能是代表 R， 所以我们可以做一个估计， 一般估计的值应该是比较常见的东西， 比如说字母或 者是数字之类的，一般就是说常见的 ASSIC 码值（如果是调制出来的信息为 0~9 ，A~Z ，a~z 我们都可以提示，如果是其他信息，我们就可以不做处理或者 是其他处理（根据相应情况提示加密之类的） ） * * 需要的数据有： Http 协议头部的各个字段 （可以用一个数组保存这些首部名称， 然后进行匹配这些信息）（头部名称《具体的大小写匹配》 ）的信息，大小写如下 先转换为小写，然后匹配在这些数据中是否存在首部信息的完整信息， 如果存在， 然后把没转换的来匹配（标准的 http 协议的协议头部）如果匹配命中，则没问 题，如果匹配不成功， 则说明可能存在这种大小写的调制信息的可能 （这里可以 取出各个首部名称出来，然后尝试调制这些信息） * * * * 3、可选的头标 / 值 / 标志（最主要的是去判断 Accept 这个字段 ，在同一个 host 时候，统计这个 Accept 是否变化了，一般情况是不会发生变化的，这个我们 也可以做一个初步的解析， 根据我们所掌握的可能的调制的二进制数字， 大概 * * 解析一下它这个解析的值的大概的意思， 给用户一个提示作用， 这个隐蔽信道 可能是调制一种啥信息出去， 这个不一定是正确，也就是给用户一个提示作用， 让用户能够感觉到这个信息确实是在传送隐蔽信息） 4、添加新头标： 这里最主要的识别出那些不是 RFC 上面的请求与响应字段， 一般的