IP及IPSEC协议数据包的捕获与分析

1、IP及IPSEC协议数据包的捕获与分析为了掌握掌握IP和IPSEC协议的工作原理及数据传输格式，熟悉网络层的协议。我进行了以下实验：首先用两台PC互ping并查看其IP报文，之后在两台PC上设置IPSEC互ping并查看其报文。最终分析两者的报文了解协议及工作原理。一、用两台PC组建对等网：将PC1与PC2连接并分别配置10.176.5.119和10.176.5.120的地址。如图1-1所示。10.176.5.11910.176.5.120PCIPC2图1-1二、两PC互ping：IP数据报结构如图1-2所示。比特01234567比特Q4816192431优先级DTRC未用首部数摇部分IP数据

2、报图1-2我所抓获的报文如图1-3，图1-4所示：Id-fl致伯曲：编号:护数据包长度：卜車捕義长度：Lg时同戳：包带以太网-:【EthernetTypeII:卜母？目标地址DestinationAddress:源地址SourceAddress:；伸协议类型Protocol:EJ-T3IP一因特两协议IP一InternetProtocol:版本Version:；“回头部长HeaderLength:区分服务宇段DifferentiatedServicesField:$.0不同的服务代码DifferentiatedServicesCodepoint:：Q传箍协议忽珞CEfeTransportPro

3、tocolwillignoretheCEbit:i；QCongestion:孝总长宜TotalLength:挣1标识Identification:(j-分段标志FragmentFlagg:?O保Reserved:分Fragment:：“O更多分段MoreFragment:护分段倫移FragmentOffset:|生存时(ajTimeToLive:?.上层Protocol:卜車校验和6ecksum:包源店地址SourceIP:L.目标IF地址DestinationIP:自年TCMP因特网担制消息协议ICMP一InternetControlMessagesProtocol:j“类型Type:“代码

4、Code:L挣校验和6ecksum:挣标识Identifier:討存字列号Sequence:L圍回显.数据EchoData:fi-T3FCS:】圍FCS:2378742016/04/1113:41:49.1103430/14FO:DE:F1:E3:93:CFD8:CB:8A:0E:33:2FOxOSOO(WistronInfoComm(Kunshan)Co)C/6(InternetIP(IPv4)12/2414/10 xF05(20宇节)14/10 x0F0000000015/1OxFF000000.,.15/1OxFC(忽珞)15/10 x02(不拥塞)15/10 x0160(60宇节)16

5、/20 x0953(2387)18/200020/10 xE020/10 x30（可能分段）20/10 x40（最后一个段）20/10 x20020/20X1FFF6422/1123/10 x0000（错误，应该是0 x5120）24/210.176.5.11926/410.176.5.12030/434/4014/2000 x4D3A0 x00010 x0021（回显）34/135/1（正钿36/238/240/242/3232宇节（计算出的）0 x65379CC9图1-3请求包NH縮号：卜等数据包长度：卜挣捕義长宜：圉时间戳：3-T3以太网-IIEthemetTypeII：i觀目标地址De

6、stinationAddress:IMP源地址SourceAddress:L护协议类型Protocol:丁育IP-因特网协议IP-InternetProtocol:“Version:i头部长宜HeaderLength:申.区分服务宇段DifferentiatedServicesField:不同的服务代码DifferentiatedServicesCodepoint:“O传输协议忽珞CE&TransportProtocolwillignoretheCEbit:Q拥SCongestion:淨总长TotalLength:存Identification:分段标FragmentFlags:iQ保WRes

7、erved:Q分段Fragment:Q更多分段MoreFragment:分段佝移FragmentOffset:|o生存时间TimeToLive:上层曲玫Protocol:亭狡验和6ecksum:9源IP迪址SourceIP:；目标IP地址DestinationIP:耳祈ICMP一因特网揑制消息协议TCMP一InternetControlMessagesProtocol:|类型Type:|代码Code:討洋狡验和Checksum:存标识Identifier:j淨序列号Sequence:L园回显数据EchoData:3-FCS:L渝FCS:24742016/04/1113:41:49.111239

8、0/14De：CB:8A:0E:33:2FFO：DE：F1：E3：93：CF0 x080014/2040/60/6(WistronInfoComm(Kunshan)Co)(InternetIP(IPv4)12/214/10 xF0(20宇节)14/10 x0F000015/1OxFF0015/1OxFC.0.（思珞）15/10（不拥塞）15/000000000 x0260(60宝节)16.0 x0557(1367)18/200020/10 xE020/10 x80（可能分段）2（最后一个段）020/20 x1FFF6422/1123/10X551C（正确）24/210.176.5.12026/

9、410.176.5.11930/434/40034/1020/10 x200 x553A0 x00010 x002132宇节(回显应答)35/1(正确)36/238/240/242/320X0218CCED(计耸出的)6/60 x010 x40图1-4回应包分析抓获的IP报文：版本：IPV4（2）首部长度：20字节（3）服务：当前无不同服务代码，传输忽略CE位，当前网络不拥塞报文总长度：60字节标识该字段标记当前分片为第1367分片三段标志分别指明该报文无保留、可以分段，当前报文为最后一段片偏移：指当前分片在原数据报(分片前的数据报)中相对于用户数据字段的偏移量，即在原数据报中的相对位置。生存

10、时间：表明当前报文还能生存64上层协议：1代表ICMP首部校验和：用于检验IP报文头部在传播的过程中是否出错报文发送方IP：10.176.5.120报文接收方IP：10.176.5.119之后为所携带的ICMP协议的信息：类型0指本报文为回复应答，数据部分则指出该报文携带了32字节的数据信息，通过抓获可看到内容为：abcdefghijklmnopqrstuvwabcdefghi三、IPSec协议配置：1、新建一个本地安全策略。如图1-5。图1-52、添加IP安全规则。如图1-6.图1-63、添加IP筛选器。如图1-7，图1-8，图1-91F需礙划丸步JU1日左全證看9tti户羞晤4Titgff

11、iW醫迦左全window,站阳网翹尿理瞬距，.二公钥乐晤.Ki3.VlSK应用屁曲削勰見JP古全隹略在不把计貫.JiESiswats养或F可叟All.：;下F.图1-7图1-14图1-8图1-94、设置筛选器操作，如图1-10，图1-11所示图1-10图1-115、设置身份验证方法，预共享密钥：123456789，如图1-12所示亘新ip去錄聒可性窑全觇则向与1?击全阪：測览血IK4S6789wrn画f上七怎)T-oi身旳笙吐方法辭加多身悄鲨证方这、済在芫磁If专全躱口向导：t后s编畴全规为此圭全规则设舌初身忖雉证方法：ActinDirctorySt认値OCrbarsVS协迫）如使用由碗书额发

12、机枸町显的证申KJ:U证书请求中翳供冊Q启用证书郢味怖映射期&使用上碌串I活屉葫立挨（菽址宜静月JCS）IF口施图1-126、将设置好的本地安全策略分配，如图1-13所示爲10势屋J?X!国新IP除全策电否2016PFSStK)遐世E1日卄图1-13四、两PC配置IPSEC互ping，并抓获报文分析:所抓取报文如下图1-14所示編号绝对时间源目标协议大小解码学段概要815:31:45.28038010.176.5.11910.176.5.120ICMPEchoReq78回显请求10.176.5.120915:31:45.28135710.176.5.119:50010.176.5.120:50

13、0ISAKMP274源55口=500;目标86口=500：长S=236;檢验?Q=0 x214C错1015:31:45.28486610.176.5.120:50010.176.5.119:500ISAKMP254源第口=500;目标洪口=500;长度=216;检验和=0乂77卩1正确1115:31:45.28709110.176.5.119:50010.176.5.120:500ISAKMP306源離口=500;目标鋳口=500;长=268;检验和=0 x216C错1215:31:45.32585710.176.5.120:50010.176.5.119:500ISAKMP306源55口=5

14、00;目标86口=500：长度=268：检验和=0 x086E正确1315:31:45.32696510.176.5.119:50010.176.5.120:500ISAKMP114源第口=500;目标洪口=500;长度=76;检验和=0 x20AC错误1415:31:45.32300110.176.5.120:50010.176.5.119:500ISAKMP114源離口=500;目标演口=500;长度=76;检验和=0 x6051正确1515:31:45.32919510.176.5.119:50010.176.5.120:500ISAKMP24255口=500;目186口=5OO：KS=

15、2O4;檢?Q=Ox212C1615:31:45.33369610.176.5.120:50010.176.5.119:500ISAKMP242源第口=500;目标洪口=500;长度=204;检验和=0 x0BFl正1715:31:45.33412610.176.5.119:50010.176.5.120:500ISAKMP106=500;1口=500;feS=68;检ffl=0 x20A41815:31:45.33586910.176.5.120:50010.176.5.119:500ISAKMP122痴5口=500;目儘6口=500：长S=84：检尉0=0 x5466正确1915:31:4

16、5.33619210.176.5.11910.176.5.120ESP114SPI:1051598720,SN:12015:31:45.33745410.176.5.12010.176.5.119ESP114SPI:3233094376,SN:12215:31:46.28209510.176.5.11910.176.5.120ESP114SPI:1051598720,SN:22315:31:46.28391110.176.5.12010.176.5.119ESP114SPI:3233094376,SN:22515:31:47.28415110.176.5.11910.176.5.120ESP1

17、14SPI:1051598720,SN:32615:31:47.28571810.176.5.12010.176.5.119ESP114SPI:3233094376.SN:32815:31:48.28715710.176.5.11910.176.5.120ESP114SPI:1051598720,SN:42915:31:48.28802310.176.5.12010.176.5.119ESP114SPI:3233094376,SN:4下图1-15为协议协商部分报文：丿InternetSecurityAssociationandKeyManagementProtocolInitiatorSPI:

18、Icfela3b68487806ResponderSPI:0000000000000000Nextpayload:SecurityAssociation(1)lVersion:1.0Exchangetype:IdentityProtection(MainMode)(2)lFlags:0 x00MessageID:0 x00000000Length:228TypePayload:SecurityAssociation(1)Nextpayload:VendorID(13)Payloadlength:56Domainofinterpretation:IPSIEC(1)Situation:000000

19、01JTypePayload:Proposal(2)#1Nextpayload:NONE/NoNextPayload(0)Payloadlength:44Proposalnumber:1ProtocolID:ISAKMP(1)SPISize:0Proposaltiransforms:1鼻TypePayload:Transf(3)#1Nextpayload:NONE/NoNextPayload(0)Payloadlength:36Transformnumber:1TransformID:KIEY_IKIE(1)TransformIKIEibutEType(t=ljl=2)Encryption-A

20、lgorithm:3DES-CBCTransformIKEAttributeType(1=21=2)Hash-Algorithm:SHAlTransformIKIEAttributeType(t=4l=2)Group-Description:Alternate1024-bitMODPgroup0TransformIKIEAttributeType(t=3jl=2)Authentication-Method:PSK0TransformIKIEibutmType(t=llJl=2)Life-Type:SecondsTransformIKIEibutE分析：发起方的SPI为：lcfela3b6848

21、7806响应方的SPI为：未知本报文作用为协商IKE策略交换模式为主模式有效载荷类型：策略协商载荷长度：56解释域为IPSEC协议第二段有效载荷类型为建议部分第二段有效载荷类型为传输，内容是IKE策略下图1-16为KEY交换部分报文:JInternetSecurityAssociationmndKeyManagementProtocolInitiatorSPI:Icfela3b68487806ResponderSPI:6d37a230952c50eaNextpayload:KeyExchange(4)Version:1.0Exchangetype:IdentityProtection(Main

22、Mode)(2)Flags:0 x00MessageID:0 x00000000Length:260“TypePayload:KeyExchange(4)Nextpayload:Nonce(10)Payloadlength:132KeyExchangeData:C9361d05e59a6a62c75f77683f31f2a09cl8ca56c074f88f.TypePayload:Nonce(10)Nextpayload:NAT-D(RFC3947)(20)Payloadlength:52NonceDATA:fed265f33e2a232bfl858863953878aea99fcbea824

23、el319.TypePayload:NAT-D(RFC3947)(20)Nextpayload:NAT-D(RFC3947)(20)Payloadlength:24HASHofth己addressandport:2433b7565d26012d29fa024fffdad603G136fc68TypePayload:NAT-D(RFC3947)(20)Nextpayload:NONE/NoNextPayload(0)Payloadlength:24HASHofth己addressandport:e82dd9f49c008f828de54f6901aee4e363f93e92图1-16分析：作用为

24、通过协商DH产生第一阶段的密码。本报文作用为密钥交换交换模式为主模式说明了所用到的RFC及加密后的数据下图1-17为认证部分报文：tFrame24:110bytesonwire(880bits)f110bytescaptured(880bits)oninterface0tEthernetIIjSrc:Micro-St_0e:33:2f(d8:cb:8a:0e:33:2f)fDst:V/istronI_e3:93:cf(fB1:de:fl:e3:93:cf)0InternetProtocolVersion4,Src:10.176.5.119jDst:10.176.5.120tUserDatagr

25、amProtocolSrcPort:500(500)DstPort:500(500)，IntenmtSecuityAssociationandKeyManagementotocolInitiatorSPI:Icfela3b68487806ResponderSPI:6d37a230952c50eaNextpayload:Identification(5)0Version:1.0Exchangetype:IdentityProtection(MainMode)(2)Flags:0 x011=Encryption:Encrypted0.=Commit:Nocommit0=Authentication

26、:NoauthenticationMessageID:0 x00000000Length:68EncryptedData(40bytes)图1-17分析：本报文作用为认证交换模式为主模式标志位说明：1当前加密，0未提交状态，0未完成认证三部进行完后发送方会把IPSEC策略发给对方，有对方选择合适的策略，报文如下图1-18所示：lFrame26:238bytesonwire(1904bits),238bytescaptured(1904bits)oninterface0EthernetIIjSrc:Micro-St_0e:33:2f(d8:cb:8a:0e:33:2f)3Dst:Wistronl

27、_e3:93:cf(fB:de:fl:e3:93:cf)tInternetProtocolVersion4,Src:10.176.5.119Dst:10.176.5.120tUserDatagramProtocoljSrcPort:500(500)DstPort:500(500)InternetSecurityAssociationandKeyManagementProtocolInitiato5PI:Icfela3b68487806ResponderSPI:6d37a230952c50eaNextpayload:Hash(8)Version:1.0Exchangetype:QuickMode

28、(32)丿Flags:0 x011=Encryption:Encrypted0=Commit:Nocommit0.=Authentication:NoauthenticationMessageID:0 x00000001Length:196EricyptEdData(168bytes)图1-18分析：有效载荷类型为HASH载荷交换模式为快速模式表示当前已经是安全环境了完成IPSEC的交互后，后面的报文变为了ESP报文：如图1-19所示Enchilada据段已验证已拥空新IP头ESP头原IP头原IP数据报文ESP尾ESPMACSPISeq#値呑填充Next唄允长度HeaderFrame30:11

29、0byteson(880bits)j110bytescaptured(880bits)oninterface0鼻EthernetIISrc:Micro-St_0e:33:2f(d8:cb:8a:Be:33:2f)fDst:Wistronl_e3:93:cf(f0:de:f1:e3:93:cf)0Destination:WistnonI_e3:93:cf(f0:de:fl:e3:93:cf)0Source:Micro-St_0e:33:2f(d8:cb:8a:0e:33:2f)Type:IPv4(0 x0800)JInternetProtocolVersion铁Src:10.176.5.119D

30、st:10.176.5.1200100.=Version:4.0101=HeaderLength:20bytes-DifferentiatedServicesField:0 x00(DSCP:CS0,IECN:Not-IECT)000000=DifferentiaServicesCodepoint:Default(0)00=ExplicitCongestionNotification:NotECN-CapableTransport(0)TotalLength:96Identification:0 x775b(30555)Flags:0 x000=Reservedbit:Not.0=Dont-F

31、ragment:Not亏Et0=恂fragments:NotFragmentoffset:0Timetolive:64Protocol:EncapSecuityPayload(50)，Headerchecksum:0 xe2c2validationdisabledGood:FalseBad:FalseSource:10.176.5.119Destination:10.176.5.120SourceGeoIP:UnknownDestinationGeoIP:UnknownEncapsulatingSecurityPayloadESPSPI:0 x6ae74dca(1793543626)ESPSequence:1图1-19分析：(1)所加ESP头中的SPI和Sequence分别为1793543626和1(2)上层协议为ESP(50)说明其为一个IPSEC报文五、实验中的问题抓获ISAKMP包时用科来网络分析系统所抓获的报文如下图1-20所示。可以看出少了一段InternetSecurityAssociationandKeyManagementProtocol的解析，导致无法看到IPSEC的协商过程。最终改用wireshark抓包，顺利的解决了这个问题，找到了该过程。曰“冲収诽也伯尽；卜护数据包长度：卜岸捕获长度:；圉时冋戳：申T*以太两-IIEthemetTypeII