网络数据包截获与还原http.docx
- 文档编号:11189840
- 上传时间:2023-02-25
- 格式:DOCX
- 页数:55
- 大小:348.36KB
网络数据包截获与还原http.docx
《网络数据包截获与还原http.docx》由会员分享,可在线阅读,更多相关《网络数据包截获与还原http.docx(55页珍藏版)》请在冰豆网上搜索。
网络数据包截获与还原http
摘要:
在因特网日益发展壮大的今天,万维网在其上的通信量已经超过90%,万维网信息的安全问题已经越来越被人们所重视,而作为万维网应用层核心协议的http协议是基础。
当网络发生异常时,对网络上传输的数据进行监视和分析,是网管人员解决网络故障的一种常用方法。
本文介绍应用层HTTP数据包的截获与还原技术的实现,并简要介绍其中所涉及的数据包截获、数据包分析、应用数据重组以及数据包解码等关键技术。
该系统可以监听网管人员感兴趣的数据包,通过对其进行分析和研究,分析出其遵守的协议以及其应用层数据,恢复到被监视用户所看到数据的格式。
该系统的实现,为网管人员有效地管理网络提供了一种直观的工具。
关键词:
http数据包;截获;还原
Abstract:
WiththeincreasingdevelopmentandexpansionofInternet,thetrafficofWorld-Wide-Webhasoccupiedmorethan90percentonInternetatpresent.Therefore,peoplehaveattachedmoreandmoreimportancetothesecurityoftheWWWinformation.WhileHTTP(HypertextTransferProtocol)asthecentralprotocolofWWW’sapplicationlayerformsthefoundationofit.Monitoringandanalysingthedatatransferredonnetworkisthedailyworksfornetworkmanager
Thewriterofthispaperintroducedthedesignandimplementationforcapturingapartofhttpdatapackets,recoveringthecapturedhttpdatapackets,andanalyzedsomekeytechnologiesaboutcapturingdatapacketbrief,packetanalyzing,reconstructingapplicationdataandpacketdecodingandsoon.Thissystemcanmonitorthepackageswhichnetworkmanagerisinterestedin,analyzetheprotocolswhichthepacketuses,recovertheformatwhichtheendusersee.Theimplementationofthesystemprovidesavisualtoolfornetworkmanagers.
KeyWords:
httppackets;capture;recover
前言
在短短的二十几年时间里,万维网(WordWideWeb)从一种发布高能物理数据的方式演变为如今人们头脑中的因特网,它之所以如此流行是由于它有一个丰富多彩的界面,初学者很容易使用,并且提供了大量的信息资源,几乎涉及人们所能想象的所有主题。
HTTP是一个属于应用层的面向对象的协议,而http协议作为www的主要协议,由于其简捷、快速的方式,适用于分布式超媒体信息系统。
它于1990年提出,经过几年的使用与发展,得到不断地完善和扩展。
目前在WWW中使用的是HTTP/1.0的第六版,HTTP/1.1的规范化工作正在进行之中,而且HTTP-NG(NextGenerationofHTTP)的建议已经提出。
但HTTP协议存在许多安全漏洞,比如说允许远程用户向远程服务器请求连接,并且执行远程命令.这个安全漏洞可以以许多方式损坏Web服务器和客户机,这些危害信息还包括对远程请求的武断认证;破坏请求和应答的保密性;滥用服务器功能和资源等。
而在网络上传送的不良信息,也影响人们的身心健康,包括色情、迷信和暴力等信息。
对危害信息和不良信息在应用层的还原可以很明确的知道该信息传送的具体信息,具有很直观的效果,可以帮助网络管理人员较好的监视网络。
对于网络数据包的截获和还原是网络行为监视的一部分,本文主要介绍HTTP数据包的截获与还原技术,该技术涉及到数据包截获、数据包分析、应用数据重组和字符编码解码等关键技术。
该技术的实现可以帮助网管人员监听感兴趣的HTTP数据包,分析出其遵守的协议以及其应用层数据,同时将应用层数据进行重组,恢复到原始的数据格式,达到与被监视用户相同的显示效果。
该系统的实现,为网管人员有效地管理网络提供了一种直观的工具。
本文所介绍的基于HTTP协议的截获和还原信息主要是万维网信息,而这些信息包括文本、图象和声音等,本文主要是针对文本信息的还原,而大多数的嗅探器并不支持的数据在应用层的还原。
本文所提出的应用层数据的还原技术是针对大多数嗅探器的局限性提出来的。
第一章http网络数据包截获与还原的理论基础
1.1网络体系结构
1.1.1网络参考模型概述
OSI的七层协议体系结构既复杂又不实用,但其概念清楚,体系结构理论较完整。
TCP/IP的协议现在得到了广泛的应用,但它原先并没有一个明确的体系结构。
TCP/IP是一个四层的体系结构,它包含应用层、运输层、网际层和网络结构层。
不过从实质上讲,TCP/IP只有三层,即应用层、运输层和网际层,因为最下面的网络接口层并没有什么具体内容。
下面的图片反应了两台计算机进行通信时的各层数据流结构。
图1.1
应用层应用层是体系结构中的最高层。
应用层确定进程之间通信的性质以满足用户的需要。
应用层不仅要提供应用进程所需要的信息交换和远地操作,而且还要作为相互作用的应用进程的用户代理,来完成一些为进行语义上有意义的信息交换所必须的功能。
应用层直接为用户的应用进程提供服务。
在因特网中的应用层协议很多,如支持万维网应用的HTTP协议,支持电子邮件的SMTP协议,支持文件传输的FTP协议等等。
运输层运输层的任务就是负责主机中两个进程之间的通信。
因特网的运输层可使用两种不同协议。
即面向连接的传输控制协议TCP,和无连接的用户数据报协议UDP。
面向连接的服务能够提供可靠的交付,但无连接服务则不保证提供可靠的交付,它只是“尽最大努力交付”。
这两种服务方式都很有用,各有其优缺点。
在分组交换网内的各个交换接点机都没有运输层。
运输层只能存在于分组交换网外面的主机之中。
运输层以上的各层就不再关心信息传输的问题了。
正因为如此,运输层就成为计算机网络体系结构中非常重要的一层。
网络层网络层负责为分组交换网上的不同主机提供通信。
在发送数据时,网络层将运输层产生的报文段或用户数据报封装成分组或包进行传送。
在TCP/IP体系中,分组也叫作IP数据报,或简称为数据报。
因特网是一个很大的互联网,它由大量的异构网络通过路由器相互连接起来。
因特网主要的网络协议是无连接的网际协议IP和许多路由选择协议,因此因特网的网络层也叫网际层或IP层。
数据链路层在发送数据时,数据链路层的任务是将在网络层交下来的IP数据报组装成帧,在两个相邻接点间的链路上传送以帧为单位的数据。
每一帧包括数据和必要的控制信息。
控制信息使接受端能够知道一个帧从哪个比特开始和到哪个比特结束。
控制信息还使接受端能够检测到所收到的帧中有无差错。
如发现有差错,数据链路层就丢弃这个出了差错的帧。
物理层物理层的任务是透明地传送比特流。
在物理层上所传数据的单位是比特。
传递信息所利用的一些物理媒体,如双绞线、同轴电缆、光缆,并不在物理层之内而是在物理层的下面。
TCP/IP协议族(如下图所示),它的特点是上下两头大而中间小:
应用层和网络接口层都有多种协议,而中间的IP层很小,上层的各种协议都向下汇聚到一个IP协议中。
这种很象沙漏计时器形状的TCP/IP协议族表明:
TCP/IP可以为各式各样的应用提供服务,同时也可以连接到各式各样的网络上。
正因为如此,因特网才会发展到今天的这种全球规模。
图1.2
整个通信网络的任务,可以划分成不同的功能块,即抽象成所谓的”层”。
用于互联网的协议可以比照TCP/IP参考模型进行分类。
TCP/IP协议栈起始于第三层协议IP(互联网协议)。
所有这些协议都在相应的RFC文档中讨论及标准化。
重要的协议在相应的RFC文档中均标记了状态:
“必须“(required),“推荐“(recommended),“可选“(elective)。
其它的协议还可能有“试验“(experimental)或“历史“(historic)的状态。
1.2http协议概述
我们在浏览器的地址栏里输入的网站地址叫做URL(UniformResourceLocator,统一资源定位符)。
就像每家每户都有一个门牌地址一样,每个网页也都有一个Internet地址。
当你在浏览器的地址框中输入一个URL或是单击一个超级链接时,URL就确定了要浏览的地址。
浏览器通过超文本传输协议(HTTP),将Web服务器上站点的网页代码提取出来,并翻译成漂亮的网页。
Internet的基本协议是TCP/IP协议,然而在TCP/IP模型最上层的是应用层(Applicationlayer),它包含所有高层的协议。
高层协议有:
文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和HTTP协议等。
HTTP协议(Hypertext Transfer Protocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议。
它可以使浏览器更加高效,使网络传输减少。
它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。
这就是你为什么在浏览器中看到的网页地址都是以“http:
//”开头的原因。
自WWW诞生以来,一个多姿多彩的资讯和虚拟的世界便出现在我们眼前,可是我们怎么能够更加容易地找到我们需要的资讯呢?
当决定使用超文本作为WWW文档的标准格式后,于是在1990年,科学家们立即制定了能够快速查找这些超文本文档的协议,即HTTP协议。
经过几年的使用与发展,得到不断的完善和扩展,目前在WWW中使用的是HTTP/1.0的第六版。
1.2.1http协议的几个重要概念
1.连接(Connection):
一个传输层的实际环流,它是建立在两个相互通讯的应用程序之间。
2.消息(Message):
HTTP通讯的基本单位,包括一个结构化的八元组序列并通过连接传输。
3.请求(Request):
一个从客户端到服务器的请求信息包括应用于资源的方法、资源的标识符和协议的版本号
4.响应(Response):
一个从服务器返回的信息包括HTTP协议的版本号、请求的状态(例如“成功”或“没找到”)和文档的MIME类型。
5.资源(Resource):
由URI标识的网络数据对象或服务。
6.实体(Entity):
数据资源或来自服务资源的回映的一种特殊表示方法,它可能被包围在一个请求或响应信息中。
一个实体包括实体头信息和实体的本身内容。
7.客户机(Client):
一个为发送请求目的而建立连接的应用程序。
8.用户代理(Useragent):
初始化一个请求的客户机。
它们是浏览器、编辑器或其它用户工具。
9.服务器(Server):
一个接受连接并对请求返回信息的应用程序。
10.源服务器(Originserver):
是一个给定资源可以在其上驻留或被创建的服务器。
11.代理(Proxy):
一个中间程序,它可以充当一个服务器,也可以充当一个客户机,为其它客户机建立请求。
请求是通过可能的翻译在内部或经过传递到其它的服务器中。
一个代理在发送请求信息之前,必须解释并且如果可能重写它。
代理经常作为通过防火墙的客户机端的门户,代理还可以作为一个帮助应用来通过协议处理没有被用户代理完成的请求。
12.网关(Gateway):
一个作为其它服务器中间媒介的服务器。
与代理不同的是,网关接受请求就好象对被请求的资源来说它就是源服务器;发出请求的客户机并没有意识到它在同网关打交道。
网关经常作为通过防火墙的服务器端的门户,网关还可以作为一个协议翻译器以便存取那些存储在非HTTP系统中的资源。
13.通道(Tunnel):
是作为两个连接中继的中介程序。
一旦激活,通道便被认为不属于HTTP通讯,尽管通道可能是被一个HTTP请求初始化的。
当被中继的连接两端关闭时,通道便消失。
当一个门户(Portal)必须存在或中介(Intermediary)不能解释中继的通讯时通道被经常使用。
14.缓存(Cache):
反应信息的局域存储。
1.2.2http协议结构
HTTP报文由从客户机到服务器的请求和从服务器到客户机的响应构成。
请求报文格式如下:
请求行
通用信息头
请求头
实体头
报文主体
表3.1
请求行以方法字段开始,后面分别是URL字段和HTTP协议版本字段,并以CRLF结尾。
SP是分隔符。
除了在最后的CRLF序列中CF和LF是必需的之外,其他都可以不要。
有关通用信息头,请求头和实体头方面的具体内容可以参照相关文件。
响应报文格式如下:
状态行
通用信息头
请求头
实体头
报文主体
表3.2
状态码元由3位数字组成,表示请求是否被理解或被满足。
原因分析是对原文的状态码作简短的描述,状态码用来支持自动操作,而原因分析用来供用户使用。
客户机无需用来检查或显示语法。
有关通用信息头,响应头和实体头方面的具体内容可以参照相关文件。
HTTP(HyperTextTransferProtocol)
HTTP(HyperTextTransferProtocol)是超文本传输协议的缩写,它用于传送WWW方式的数据,关于HTTP协议的详细内容请参考RFC2616。
HTTP协议采用了请求/响应模型。
客户端向服务器发送一个请求,请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。
服务器以一个状态行作为响应,相应的内容包括消息协议的版本,成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。
这两种类型的消息由一个起始行,一个或者多个头域,一个只是头域结束的空行和可选的消息体组成。
HTTP的头域包括通用头,请求头,响应头和实体头四个部分。
每个头域由一个域名,冒号(:
)和域值三部分组成。
域名是大小写无关的,域值前可以添加任何数量的空格符,头域可以被扩展为多行,在每行开始处,使用至少一个空格或制表符。
通用头域
通用头域包含请求和响应消息都支持的头域,通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。
对通用头域的扩展要求通讯双方都支持此扩展,如果存在不支持的通用头域,一般将会作为实体头域处理。
下面简单介绍几个在UPnP消息中使用的通用头域。
Cache-Control头域
Cache-Control指定请求和响应遵循的缓存机制。
在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。
请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached,响应消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。
各个消息中的指令含义如下:
Public指示响应可被任何缓存区缓存。
Private指示对于单个用户的整个或部分响应消息,不能被共享缓存处理。
这允许服务器仅仅描述当用户的部分响应消息,此响应消息对于其他用户的请求无效。
no-cache指示请求或响应消息不能缓存
no-store用于防止重要的信息被无意的发布。
在请求消息中发送将使得请求和响应消息都不使用缓存。
max-age指示客户机可以接收生存期不大于指定时间(以秒为单位)的响应。
min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
max-stale指示客户机可以接收超出超时期间的响应消息。
如果指定max-stale
息的值,那么客户机可以接收超出超时期指定值之内的响应消息。
Date头域
Date头域表示消息发送的时间,时间的描述格式由rfc822定义。
例如,Date:
Mon,31Dec200104:
25:
57GMT。
Date描述的时间表示世界标准时,换算成本地时间,需要知道用户所在的时区。
Pragma头域
Pragma头域用来包含实现特定的指令,最常用的是Pragma:
no-cache。
在HTTP/1.1协议中,它的含义和Cache-Control:
no-cache相同。
请求消息
请求消息的第一行为下面的格式:
MethodSPRequest-URISPHTTP-VersionCRLFMethod表示对于Request-URI完成的方法,这个字段是大小写敏感的,包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。
方法GET和HEAD应该被所有的通用WEB服务器支持,其他所有方法的实现是可选的。
GET方法取回由Request-URI标识的信息。
HEAD方法也是取回由Request-URI标识的信息,只是可以在响应时,不返回消息体。
POST方法可以请求服务器接收包含在请求中的实体信息,可以用于提交表单,向新闻组、BBS、邮件群组和数据库发送消息。
SP表示空格。
Request-URI遵循URI格式,在此字段为星号(*)时,说明请求并不用于某个特定的资源地址,而是用于服务器本身。
HTTP-Version表示支持的HTTP版本,例如为HTTP/1.1。
CRLF表示换行回车符。
请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信息。
请求头域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。
对请求头域的扩展要求通讯双方都支持,如果存在不支持的请求头域,一般将会作为实体头域处理。
典型的请求消息:
GEThttp:
//class/download.microtool.de:
80/somedata.exe
Host:
download.microtool.de
Accept:
*/*
Pragma:
no-cache
Cache-Control:
no-cache
Referer:
http:
//class/download.microtool.de/
User-Agent:
Mozilla/4.04[en](Win95;I;Nav)
Range:
bytes=554554-
Host头域
Host头域指定请求资源的Intenet主机和端口号,必须表示请求url的原始服务器或网关的位置。
HTTP/1.1请求必须包含主机头域,否则系统会以400状态码返回。
Referer头域
Referer头域允许客户端指定请求uri的源资源地址,这可以允许服务器生成回退链表,可用来登陆、优化cache等。
他也允许废除的或错误的连接由于维护的目的被追踪。
如果请求的uri没有自己的uri地址,Referer不能被发送。
如果指定的是部分uri地址,则此地址应该是一个相对地址。
Range头域
Range头域可以请求实体的一个或者多个子范围。
例如,
表示头500个字节:
bytes=0-499
表示第二个500字节:
bytes=500-999
表示最后500个字节:
bytes=-500
表示500字节以后的范围:
bytes=500-
第一个和最后一个字节:
bytes=0-0,-1
同时指定几个范围:
bytes=500-600,601-999
但是服务器可以忽略此请求头,如果无条件GET包含Range请求头,响应会以状态码206(PartialContent)返回而不是以200(OK)。
User-Agent头域
User-Agent头域的内容包含发出请求的用户信息。
响应消息
响应消息的第一行为下面的格式:
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
HTTP-Version表示支持的HTTP版本,例如为HTTP/1.1。
Status-Code是一个三个数字的结果代码。
Reason-Phrase给Status-Code提供一个简单的文本描述。
Status-Code主要用于机器自动识别,Reason-Phrase主要用于帮助用户理解。
Status-Code的第一个数字定义响应的类别,后两个数字没有分类的作用。
第一个数字可能取5个不同的值:
1xx:
信息响应类,表示接收到请求并且继续处理
2xx:
处理成功响应类,表示动作被成功接收、理解和接受
3xx:
重定向响应类,为了完成指定的动作,必须接受进一步处理
4xx:
客户端错误,客户请求包含语法错误或者是不能正确执行
5xx:
服务端错误,服务器不能正确执行一个正确的请求
响应头域允许服务器传递不能放在状态行的附加信息,这些域主要描述服务器的信息和Request-URI进一步的信息。
响应头域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。
对响应头域的扩展要求通讯双方都支持,如果存在不支持的响应头域,一般将会作为实体头域处理。
典型的响应消息:
HTTP/1.0200OK
Date:
Mon,31Dec200104:
25:
57GMT
Server:
Apache/1.3.14(Unix)
Content-type:
text/html
Last-modified:
Tue,17Apr200106:
46:
28GMT
Etag:
"a030f020ac7c01:
1e9f"
Content-length:
39725426
Content-range:
bytes554554-40279979/40279980
Location响应头
Location响应头用于重定向接收者到一个新URI地址。
Server响应头
Server响应头包含处理请求的原始服务器的软件信息。
此域能包含多个产品标识和注释,产品标识一般按照重要性排序。
实体
请求消息和响应消息都可以包含实体信息,实体信息一般由实体头域和实体组成。
实体头域包含关于实体的原信息,实体头包括Allow、Content-Base、Content-Encoding、Content-Language、Con
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 网络 数据包 截获 还原 http