http隐蔽信道简单总结
- 格式:doc
- 大小:3.46 MB
- 文档页数:20
浅析网络隐蔽信道的原理与阻断技术作者:陶松来源:《电脑知识与技术》2014年第22期摘要:隐蔽信道可以在不违反系统安全策略的情况下进行信息泄露,该文解释了网络隐蔽信道的概念,介绍了网络隐蔽信道的分类和一般工作原理。
然后,针对计算机网络各层次分别介绍了常见的隐蔽通道,并对各种隐蔽通道的工作原理和实现方法做了详细的分析,在此基础上给出了一些检测和阻断网络隐蔽信道的方法和思路。
关键词:隐蔽信道;计算机网络;隐蔽信道检测中图分类号:TP393 文献标识码:A 文章编号:1009-3044(2014)22-5198-031942年,英国军方截获一封“休伯特”写给“珍妮特阿姨”的信,这封内容看似普通的家信引起了英军的怀疑,但他们一直百思不得其解。
直到后来抓获了两名德国间谍后,据这两名间谍介绍,把信的每个字的首字母组合在一起,就是情报的内容。
英军照间谍所说的方法读出了一条重大军情:14架“波音堡垒”战斗机昨日飞抵伦敦,准备进攻德国。
这里间谍采用“藏头信”的方式秘密传输信息,实质为隐蔽信道的传送信息思想。
隐蔽信道主要就是完成从受保护的网络传输数据出来,近年来,“棱镜门”事件等信息安全事件的发生,已经暴露了网络数据窃密的冰山一角,网络隐蔽信道安全防范不容忽视。
1 隐蔽信道的定义1973年Lampson最初提出隐蔽信道概念,将其定义为:不是被设计或本意不是用来传输信息的通信信道。
Lampson最初主要关注操作系统中程序的限制问题,他的这个定义没能完全反映隐蔽信道实质,其后来Tsai、Gligor等人给出一个较为全面的定义:给定一个强制安全策略模型M和它在一个操作系统中的解释I(M),I(M)中两个主体I(Si)和I(Sj)之间的任何潜在通信都是隐蔽的,当且仅当模型M中的相应主体Si和Sj之间的任何通信在M中都是非法的[2]。
隐蔽信道广泛存在于部署了强制访问控制机制的安全操作系统、安全数据库和完全网络中。
当研究计算机网络中的隐蔽信道,更为公认的观点认为:隐蔽通道是一个将信息隐藏在公开通讯媒介中通讯信道。
隐蔽通信及安全检测防护技术探究本文从网络收集而来,上传到平台为了帮到更多的人,如果您需要使用本文档,请点击下载按钮下载本文档(有偿下载),另外祝您生活愉快,工作顺利,万事如意!1 绪论恶意的隐蔽通信(也称隐蔽信道)是网络攻击者进行网络攻击成功关键。
通过攻击者通过对受控主机的控制,通过使用恶意程序或修改正常程序,在看似正常的网络通信中嵌入消息并混合在正常的网络流量中。
这样帮助攻击者绕过传统通过访问控制列表、利用签名、信誉列表及沙箱识别等传统安全防护产品的检测,从而进行控制指令执行、恶意代码传播、敏感数据窃取等攻击行为。
隐蔽信道最早在1973 年由美国Lampson 提出。
美国国防部对隐蔽信道研究高度重视,在1993 年发布了可信系统的隐蔽信道分析的指南。
随着互联网通信协议的广泛使用和互联网应用的蓬勃发展,隐蔽通信也得到了越来越广泛的研究和利用。
针对隐蔽通信的检测和预防,信息安全界也展开了大量的研究和实践工作。
本文将针对隐蔽通信的攻击和防护进行分析研究并根据现有方式的不足提出相应的安全应对措施。
2 隐蔽信道攻击研究互联网协议版本(IPV4)报头隧道是隐蔽信道在网络层的第一个实例。
因为IP 是广泛使用的协议,因此利于目标协议的数据隐藏。
IP 数据包包含一个协议报头,它有23 个字段组成并用于各种目的,如携带的路由信息、服务质量系统信息,分段信息的。
但是这些信息可用来传输非网络管理是信息。
尽管这些报头中的这些信息是公开且可被检测,但是里面的数据并不被认为是异常的。
16bit 的IP 标示(ID)字段也是最常见的可用于隐蔽数据传输的选择。
一个隐蔽信道可以将编码数据分隔成16bit 字节并封装于IP 的标示字段中进行隐蔽传输。
此外,IP 协议还有许多通过操作利用IP 报头进行隐蔽信道传输的漏洞,例如24bit 的可选字段、8bit 的字段填充位、3bit的不分段标示(DF flag)以及生存时间字段(TTL)。
网络安全是当今社会中一项至关重要的任务。
随着科技的发展,网络安全问题也愈发严峻。
黑客攻击、网络诈骗等问题层出不穷,给人们的生产和生活带来了巨大的威胁。
因此,保护网络安全成为了每个网络使用者都应该重视的问题。
在这个过程中,网络隐蔽通道检测成为了一项至关重要的技术手段。
首先,我们需要了解什么是网络隐蔽通道。
网络隐蔽通道是指利用一些未被授权的手段,在网络中传输信息的通道。
黑客可以利用网络隐蔽通道,通过各种方式在网络中传送恶意代码、盗取数据等。
因此,检测和防范网络隐蔽通道成为了保护网络安全的一项重要工作。
网络隐蔽通道检测的第一步是识别网络中的异常流量。
异常流量可能是黑客利用网络隐蔽通道传输数据的表现。
为了识别这些异常流量,我们可以借助一些网络安全工具,比如IDS/IPS系统、防火墙等。
这些工具可以监控网络流量,及时发现异常情况,并对其进行处理。
其次,还可以利用数据包分析技术进行网络隐蔽通道检测。
数据包分析是通过对网络中的数据包进行深度分析,从而识别异常情况。
通过对数据包的源地址、目的地址、传输协议等信息进行分析,可以发现潜在的隐蔽通道。
此外,还可以通过数据包的内容进行深入分析,识别其中可能存在的恶意信息。
另外,更加先进的技术手段是利用机器学习和人工智能技术进行网络隐蔽通道检测。
随着人工智能技术的发展,机器学习模型可以通过对大量数据的学习,识别出网络中的异常情况。
利用机器学习和人工智能技术进行网络隐蔽通道检测,可以大大提高检测的准确性和效率。
这种方法可以及时发现新型的网络隐蔽通道,从而更好地保护网络安全。
除了上述技术手段,还可以通过加强网络安全意识,提高网络用户的安全意识来加强网络隐蔽通道检测。
网络用户应该注意密码安全、不随意点击可疑链接、不下载未经验证的软件等,从而避免自身成为网络隐蔽通道的一部分。
同时,网络管理员也需要加强对网络安全的管理和监控,对网络中的异常情况及时作出反应。
总的来说,网络隐蔽通道检测是保护网络安全的重要手段。
用于隐藏信道攻击利用的常见协议隐藏信道攻击是一种隐蔽而危险的攻击手段,通过利用常见协议中的漏洞或设计缺陷,攻击者可以在通信过程中传输隐藏的信息。
这些协议通常是为了实现特定的功能而设计,并未考虑安全和防御机制。
本文将介绍几种常见的用于隐藏信道攻击利用的协议。
第一个常见的协议是DNS(域名系统)。
DNS是用于将域名转换为IP地址的协议,在互联网通信中起着重要的作用。
攻击者可以通过伪装DNS查询和响应的内容来传输隐藏的信息。
例如,攻击者可以通过修改域名查询来传输二进制数据,然后通过DNS响应来接收数据。
这种隐藏信道攻击方式相对隐蔽,因为DNS查询和响应是常见的网络流量,很难被检测和阻止。
另一个常见的协议是HTTP(超文本传输协议)。
攻击者可以利用HTTP协议中的请求和响应头字段来传输隐藏的信息。
例如,攻击者可以通过修改HTTP请求头字段的值来传输二进制数据,然后通过HTTP响应头字段接收数据。
这种隐藏信道攻击方式更加隐蔽,因为HTTP通信在互联网中非常普遍,很难被怀疑和阻止。
另外,电子邮件协议(如SMTP和POP3)也常被攻击者用于隐藏信道攻击。
攻击者可以通过在电子邮件头字段中插入隐藏的信息来传输数据。
例如,攻击者可以利用电子邮件主题、发送者和接收者等字段来传输隐藏的信息。
这种隐藏信道攻击方式相对隐蔽,因为电子邮件通信在日常工作和社交中广泛使用,很难被怀疑和阻止。
此外,VoIP(Voice over Internet Protocol,互联网电话)协议也是隐藏信道攻击的常见载体。
攻击者可以通过在VoIP数据包的头部或载荷中插入隐藏的信息来传输数据。
这种隐藏信道攻击方式在语音通信中具有很高的隐蔽性,很难被察觉和阻止。
对于保护系统免受隐藏信道攻击的威胁,以下是一些建议:1. 实施网络流量监测和分析:定期监测和分析网络流量,包括DNS、HTTP、电子邮件和VoIP等协议,以检测可疑的通信模式和异常数据传输。
网络安全问题一直是互联网发展过程中必须重视的一个问题,随着网络技术的不断发展,网络安全问题也愈加突出。
特别是在信息安全领域,网络隐蔽通道检测成为一项至关重要的工作。
本文将探讨如何使用网络安全网络隐蔽通道检测保护网络安全。
首先,网络安全的重要性不言而喻。
随着互联网的普及和信息化的快速发展,网络攻击的频率和手段不断升级,给网络安全带来了更大的挑战。
因此,保护网络安全,防范网络攻击已经成为每个网络从业者和用户必须面对的问题。
而网络隐蔽通道检测作为网络安全的一项重要技术,可以有效地保护网络安全,避免网络隐蔽通道的悄然侵入。
其次,网络隐蔽通道是指利用网络协议的漏洞或者其他技术手段,在网络传输中隐藏数据。
这种隐藏数据的方法,往往能够绕过传统的网络安全防护策略,给网络安全带来了极大的隐患。
因此,检测和阻断网络隐蔽通道成为了网络安全中不可或缺的一环。
接下来,我们将从技术层面和管理层面两个角度来探讨如何使用网络安全网络隐蔽通道检测保护网络安全。
首先从技术层面来看,网络隐蔽通道检测的关键在于对网络流量进行深度分析和监控。
通过对网络数据包的内容、大小、时序等多个维度的分析,可以有效地识别和定位潜在的网络隐蔽通道。
目前,各种网络隐蔽通道检测技术层出不穷,包括基于机器学习的检测方法、基于行为分析的检测方法等。
这些技术手段可以帮助网络管理员及时发现和处理网络隐蔽通道,提高网络安全的保护能力。
其次,从管理层面来看,网络隐蔽通道检测需要建立完善的网络安全管理体系。
这包括加强对网络安全设备的投入,确保网络安全设备能够全面地覆盖整个网络;加强对网络隐蔽通道检测技术的研发和应用,不断提高网络安全防护的水平;建立网络安全意识教育体系,提高网络用户的网络安全意识和防范能力。
只有在技术手段和管理体系的双重保障下,才能更好地保护网络安全。
总之,网络安全网络隐蔽通道检测是保护网络安全的一项重要工作。
在不断发展的网络安全威胁和攻击手段面前,我们需要不断提高网络安全防护能力。
不安全的http方法在网络安全领域,HTTP方法是一个重要的话题。
HTTP(HyperText Transfer Protocol)是一种用于传输超文本的应用层协议,常用于万维网上的数据传输。
然而,一些HTTP方法存在安全隐患,可能会给网络安全带来风险。
本文将讨论一些不安全的HTTP方法,并探讨它们可能带来的安全风险。
首先,我们来看一下GET方法。
GET方法用于请求访问已被URI识别的资源,它是HTTP最常用的方法之一。
然而,GET方法的参数是以明文形式出现在URL中的,这就意味着用户的敏感信息可能会被暴露在URL中,容易被恶意攻击者截获。
另外,GET方法的请求参数会被保存在浏览器历史记录中,也容易被他人获取,进而导致安全问题。
其次,POST方法也存在一些安全隐患。
POST方法用于向服务器提交数据,通常用于表单提交。
然而,一些网站在使用POST方法时,并没有对数据进行合适的验证和过滤,这就为恶意攻击者提供了可乘之机。
他们可以通过构造恶意的POST请求来进行CSRF(跨站请求伪造)攻击,冒充用户提交数据到服务器,从而导致安全问题。
另外,PUT方法和DELETE方法也存在安全风险。
PUT方法用于向服务器上传资源,DELETE方法用于删除指定的资源。
然而,一些服务器对PUT和DELETE方法的权限控制不够严格,可能会导致恶意用户对服务器资源进行未授权的操作,从而造成安全问题。
为了解决这些安全问题,我们可以采取一些措施。
首先,对于GET方法,我们可以尽量避免在URL中传递敏感信息,可以使用加密技术对参数进行加密,或者将敏感信息存储在Session中。
其次,对于POST方法,我们可以在服务器端对提交的数据进行合理的验证和过滤,避免恶意数据的提交。
另外,对于PUT和DELETE方法,我们可以加强权限控制,只允许有权限的用户进行操作,避免未授权的操作。
总之,不安全的HTTP方法可能会给网络安全带来风险,我们需要对其进行充分的了解并采取相应的安全措施。
什么是http暗藏通道?什么是局域网安全,系统管理员怎样才能保障局域网的安全?这是一个不断变化的安全概念,很长的一个时期以来,在局域网与外界互联处放置一个防火墙,严格控制开放的端口,就能在很大程度上掌握安全的主动权,方便的控制网内外用户所能使用的服务。
比如,在防火墙上仅仅开放80,53两个端口,那么无论是内部还是外面的恶意人士都将无法使用一些已经证明比较危险的服务。
但要注意一点,防火墙在某种意义上是很愚蠢的,管理员对防火墙的过分依赖以及从而产生的懈怠情绪将不可避免的形成安全上的重大隐患,作为一个证明,"通道"技术就是一个很好的例子,这也是本文要讨论的。
那么什么是通道呢?这里所谓的通道,是指一种绕过防火墙端口屏蔽的通讯方式。
防火墙两端的数据包封装在防火墙所允许通过的数据包类型或是端口上,然后穿过防火墙与对端通讯,当封装的数据包到达目的地时,再将数据包还原,并将还原后的数据包交送到相应的服务上。
举例如下:A 主机系统在防火墙之后,受防火墙保护,防火墙配置的访问控制原则是只允许80端口的数据进出,B主机系统在防火墙之外,是开放的。
现在假设需要从A系统Telnet到B系统上去,怎么办?使用正常的telnet肯定是不可能了,但我们知道可用的只有80端口,那么这个时候使用Httptunnel通道,就是一个好的办法,思路如下:在A机器上起一个tunnel的client端,让它侦听本机的一个不被使用的任意指定端口,如1234,同时将来自1234端口上的数据指引到远端(B机)的80端口上(注意,是80端口,防火墙允许通过),然后在B 机上起一个server,同样挂接在80端口上,同时指引80端口的来自client的转发到本机的telnet服务端口23,这样就ok了。
现在在A机上telnet本机端口1234,根据刚才的设置数据包会被转发到目标端口为80的B机,因为防火墙允许通过80端口的数据,因此数据包畅通的穿过防火墙,到达B机。
隐蔽通道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上面的请求与响应字段,一般的http的请求字段有:Authorization,Date,From,If-Modified_Since,MIME-Version,Pragma Referer,User-Agent响应字段:Date,Location,MIME-Version,Pragma,Server,对于如果就是添加了其她头标,则比较可疑(备注:添加了新头标过后http还就是能够正常请求处理的,如果就是标准的http软件就是不能够进行监听这些隐蔽信息,对于这个添加了新头标的,直接告警,因为正常的HTTP协议就是不会搞出这样的不正常的头标的(这个可以依据HTTP协议的规范来,没有的协议头部这个就是不正常的,由于HTTP协议本身的特点,它对这个自定义的这些头部就是不会干涉的,所以就会对这些自定义的这些信息放行通过),一些隐蔽信道就可以通过这样的一些的增加头标的方式来传送隐蔽信息,如果就是没加密的信息直接把这个新头标的信息给出,如果就是加密的乱码我们直接提示出这个东西就是加密了的(这里就涉及到了加密与没加密的判断了))(针对添加了新头标的这种,我们需要做的就就是判断,给RFC规定的http的协议类型做对比,如果就是在http的协议报头出现了我们不能够识别的协议报头则可以报警处理,并且输出其中的信息,尝试解调出信息的内容)5、利用连续的空白字符串+制表符进行隐蔽消息的传送我们在用http的时候,对于其头部标识形如,在这些标识后面还有一个空格符,首部字段名:空格字段值,由于对于web浏览器瞧来,这样的一个或者多个空格它就是不会有所影响的,这样就为隐蔽信道的实现提供了可能,这样我们需要检测其中的空格符+制表符的多少,正常情况下,这些就是不会出现的,如果就是异常则有可能在进行隐蔽信息的传输,具体传输如下所示,这里我们也可以调制出它所要表达的意思来,比如说我们要调制信息Hi,就可以用如下的方式来调制,用这些空格,制表符,与换行符来调制这些值下面给出几种涉及到http的协议头部异常的情况(区别上面所提到的直接瞧协议异常):HTTP-TunnelClient、exe(特别关注)1、请求方法与首部,首部与首部的搭配异常这种只需要的就是匹配,比如说一个if(A && B)即可多数HTTP 隧道在设计时只考虑使用HTTP 协议封装数据,忽略了方法与首部,首部与首部的搭配。
于就是就会出现诸如HEAD 方法的响应会带消息主体,If-Modified-Since 与If-Not-Modified-Since 首部同时出现在一个报文头部等等非常荒谬的情况。
当然这已经就是比较极端的例子了。
大多数情况下,这些在设计上没有考虑方法-首部,首部-首部搭配规范的HTTP 隧道,会不知不觉的用一些很少出现的方法-首部或首部-首部的搭配。
这里说很少出现,就是相对于“正常HTTP 协议的使用情况”而言的,即某用户在使用浏览器的过程中,浏览器接收到的HTTP报文中很少出现的方法-首部,或首部-首部搭配。
那么哪些属于为数较多的搭配,哪些又就是为数较少的搭配呢?下表就是关于浏览器的HTTP 协议首部-首部搭配的部分样本数据。
如下所示统计信息:从表中我们可以瞧到,为数较多的匹配就是首部 1 与同一行的首部 2 的出现次数相当的匹配。
如Server 与Date,Accept 与Connection,User-Agent 与Accept等匹配都属于为数较多的。
从这些为数较多的匹配的出现次数上瞧,首部 1 与首部2 几乎都就是成对出现的。
也就就是说如果首部 1 出现了,那么首部 2 就几乎没有不出现的可能性。
反过来对于较少出现的匹配,如Server 与Vary 等,首部 1 的出现几乎不伴有首部 2 的出现。
匹配出现的较多或较少就是受到多方面因素制约(如大多数WEB 服务器遵守的HTTP 协议规范,WEB 服务器自身的个性特点,用户喜好上的那些网站等等都会影响匹配的出现频度),因此在另一个环境中采集到的浏览器首部-首部匹配样本可能不会体现出表5-1 的情况,而体现出样本所在的环境的情况。
下图给出了报文中的首部的各个字段在请求,应答,与主体中出现与否对于设计上未考虑这些正常匹配的HTTP 隧道来说,它们在封装数据时可能就是随机的挑选某个方法与某些首部,也可能就是固定的就用某个方法与某些首部,还可能就是在自己已选中的方法与首部中随便的挑选。
这样,这些“胡乱”搭配的组合就不可能出现类似表5-1 列出的那些匹配情况。
这里关键在于“胡乱”搭配的组合体现HTTP 隧道自身的特点,它完全不顾,也不可能顾及到实际环境中用户的行为特点。
因此由用户实际行为产生的浏览器标准样本中的匹配情况就一定会与这些“胡乱”搭配的组合情况有很大的差距。
根据“正常HTTP 协议的使用情况”的定义,这个差距越大,就越就是异常方法-首部,首部-首部匹配异常就是针对大多数非专业的HTTP 隧道而言的方法-首部匹配,首部-首部匹配可疑度计算的具体分析:(需要用到下图)2、某一种方法的高频出现(比如说post提交数据的方法(例如HTTP-TunnelNG中,就就是完全使用POST 方法打包与传输数据的),还比如说PUT,因为PUT 也可以带消息主体,而且HTTP 隧道也可以把需要传输的数据放到首部的赋值里,这样一来不但会使非POST,非PUT 方法高频出现,也会引起首部赋值异常)虽然如今HTTP-TunnelClient、exe在HTTP 协议头部的构造方面也更加考究了,但在样本数据瞧来,POST 的使用还就是相当频繁(浏览器50 天的样本含有301 个POST,HTTP-TunnelClient、exe 3 天就3234 个POST)在浏览网页时,我们有时会向服务器提交一些表单,或者在bbs 论坛上发帖子。
这些时候,浏览器会使用HTTP 协议的POST 方法来提交数据;但就是,我们提交表单也好,还就是发帖子也好,都不会经常连续不断的提交数据;因此在正常情况下,POST 方法不会经常连续出现。
但就是有些“模仿过分”的HTTP 隧道,为了假装浏览器在提交数据,也使用POST 方法(其实她完全可以不使用POST 也照样传递数据,所以说它“模仿过分”);但这些HTTP 隧道经常有连续不断的数据要打包发送出去,这就造成POST 方法的泛滥。