ARP这个协议的作用是:当源主机知道目的主机的IP地址而不知道对方的MAC地址的话可以使用ARP这个广播协议来获得对方的MAC地址,获得硬件地址的原因是主机通信是通过MAC地址来实现的。
这是以太网中的ARP报文格式。
(1):以太网目的地址:是硬件地址,包含六个字节的地址。例如: 00 1f 3c d1 b6 7d 。
(2):以太网源地址: 是发出给ARP包的主机地址。格式与目的地址相同 。
(3):以太帧类型: 用来表明上层协议的类型,如果是ARP协议的话就为:0806 。
以上者三部分为数据链路层中以太帧的首部格式,其实在以太帧的尾部还有一个字段(图中未标出)是:
(4):帧检查序列:用于对数据帧中数据的差错检查的 。
如图所示的ARP帧结构中:
硬件类型:如果是以太网则硬件类型为:0001 。
协议类型:这里一般写的是:0800 表示IP类型,ARP是IP协议族中的一个。
硬件地址长度:指的是MAC地址的长度,长度为6 单位是字节 。
协议地址产度:如果是IP4则这个值为4,单位是字节 。
op为操作符:如果为1则为请求包;如果为2则为回应包。
这里假设源主机为:A ,目的主机为:B 。其请求和回应这个都不变。
如果是请求包的话:
以太网首部的目的MAC地址为:FF:FF:FF:FF:FF:FF表示广播包。
ARP字段中的目的主机MAC地址字段为:00:00:00:00:00:00(十六进制表示) 起到填充的作用。
op操作符字段为:0001
如果是回应包的话:
以太网首部的目的MAC地址为:源主机的MAC地址。
ARP字段中的源主机MAC地址字段为:目的主机的MAC地址。
op操作符字段为:0002。
参考文献:http://blog.sina.com.cn/s/blog_66a13c610100hqr6.html
一次完整的ARP欺骗
A的地址为:IP:192.168.10.1 MAC: AA-AA-AA-AA-AA-AA
B的地址为:IP:192.168.10.2 MAC: BB-BB-BB-BB-BB-BB
C的地址为:IP:192.168.10.3 MAC: CC-CC-CC-CC-CC-CC
A和C之间进行通讯.但是此时B向A发送一个自己伪造的ARP应答,而这个应答中的数据为发送方IP地址是192.168.10.3(C的IP地址),MAC地址是BB-BB-BB-BB-BB-BB(C的MAC地址本来应该是CC-CC-CC-CC-CC-CC,这里被伪造了)。当A接收到B伪造的ARP应答,就会更新本地的ARP缓存(A被欺骗了),这时B就伪装成C了。同时,B同样向C发送一个ARP应答,应答包中发送方IP地址四192.168.10.1(A的IP地址),MAC地址是BB-BB-BB-BB-BB-BB(A的MAC地址本来应该是AA-AA-AA-AA-AA-AA),当C收到B伪造的ARP应答,也会更新本地ARP缓存(C也被欺骗了),这时B就伪装成了A。这样主机A和C都被主机B欺骗,A和C之间通讯的数据都经过了B。主机B完全可以知道他们之间说的什么:)。这就是典型的ARP欺骗过程。
掐断A 与 c的通讯,实现原理:b 向A 发送一条ARP 数据包,内容为:c的地址是00:00:00:00:00:00 (一个错误的地址),那么A 此后向c发的数据包都会发到00,而这个地址是错误的,所以通讯中断了,但是要注意了,这里只是A --> c 中断了,c --> A 没有中断,所以这个叫单向欺骗。
掐断c与A 的通讯,实现原理和第一条一样,如果和第一条一起发,那么A 和c 的通讯就完全中断了,即:A <-- ×--> c.
嗅探A 与c 的通讯,实现原理:b 向A 发送一条ARP 数据包,内容为:c的地址是AA:BB:CC:DD:EE:FF (b自己的地址),也就是说,b 对 A 说:我才是c,于是A 把向c发送的数据都发给b 了,b得到数据后就可以为所欲为了,可以直接丢弃,那么通讯中断,也可以再次转发给c,那么又形成回路,B当了个中间人,监视A 和c 的通讯.此时你就可以用CAIN等任何抓包工具进行本地嗅探了.
参考文献:http://hi.baidu.com/fycouk/item/47dfb689a7d92c59850fabd7
DHCP协议的工作原理
根据客户端是否第一次登录网络,DHCP的工作形式会有所不同。 第一次登录的时候:
1寻找 Server
当 DHCP客户端第一次登录网络的时候,也就是客户发现本机上没有任何IP数据设定,它会向网络发出一个 DHCPDISCOVER 封包。因为客户端还不知道自己属于哪一个网络,所以封包的来源地址会为 0.0.0.0 ,而目的地址则为 255.255.255.255 ,然后再附上 DHCPdiscover 的信息,向网络进行广播。
在 Windows 的预设情形下,DHCPdiscover 的等待时间预设为 1 秒,也就是当客户端将第一个 DHCPdiscover 封包送出去之后,在 1 秒之内没有得到响应的话,就会进行第二次 DHCPdiscover 广播。若一直得不到响应的情况下,客户端一共会有四次 DHCPdiscover 广播(包括第一次在内),除了第一次会等待 1 秒之外,其余三次的等待时间分别是 9、13、16 秒。如果都没有得到 DHCP服务器的响应,客户端则会显示错误信息,宣告 DHCPdiscover 的失败。之后,基于使用者的选择,系统会继续在 5 分钟之后再重复一次 DHCPdiscover 的过程。
2提供IP租用地址
当DHCP协议服务器监听到客户端发出的 DHCPdiscover 广播后,它会从那些还没有租出的地址范围内,选择最前面的空置IP,连同其它TCP/IP设定,响应给客户端一个DHCPOFFER封包。
由于客户端在开始的时候还没有IP地址,所以在其 DHCPdiscover 封包内会带有其 MAC 地址信息,并且有一个 XID 编号来辨别该封包,DHCP服务器响应的 DHCPoffer 封包则会根据这些资料传递给要求租约的客户。根据服务器端的设定,DHCPoffer 封包会包含一个租约期限的信息。
3接受IP租约
如果客户端收到网络上多台DHCP协议服务器的响应,只会挑选其中一个 DHCPoffer 而已(通常是最先抵达的那个),并且会向网络发送一个DHCPrequest广播封包,告诉所有 DHCP服务器它将指定接受哪一台服务器提供的IP地址。
同时,客户端还会向网络发送一个 ARP 封包,查询网络上面有没有其它机器使用该IP地址;如果发现该IP已经被占用,客户端则会送出一个 DHCPDECLIENT 封包给 DHCP服务器,拒绝接受其 DHCPoffer ,并重新发送 DHCPdiscover 信息。
事实上,并不是所有 DHCP客户端都会无条件接受 DHCP服务器的 offer ,尤其这些主机安装有其它TCP/IP相关的客户软件。客户端也可以用 DHCPrequest 向服务器提出 DHCP选择,而这些选择会以不同的号码填写在 DHCPOption Field 里面: 换一句话说,在 DHCP服务器上面的设定,未必是客户端全都接受,客户端可以保留自己的一些TCP/IP设定。而主动权永远在客户端这边。
参考文件:http://blog.csdn.net/daviwin/article/details/3365161
路由器(Router):工作在OSI第三层(网络层)上、肯有连接不同类型网络的能力并能够选择数据传送路径的网络设备。
(1)SSL协议实现的安全机制包括:
l 数据传输的机密性:利用对称密钥算法对传输的数据进行加密。
l 身份验证机制:基于证书利用数字签名方法对服务器和客户端进行身份验证,其中客户端的身份验证是可选的。
l 消息完整性验证:消息传输过程中使用MAC算法来检验消息的完整性。
对称密钥算法和MAC算法要求通信双方具有相同的密钥,否则解密或MAC值验证将失败。因此,要建立加密通道或验证消息完整性,必须先在通信双方部署一致的密钥。
(2)握手协议过程
1建立安全能力
作用双方都可以知道:
(1)SSL版本
(2)密钥交换、信息验证和加密算法
(3)压缩方法
(4)有关密钥生成的两个随机数。
2服务器鉴别和密钥交换
3客户端鉴别和密钥交换
若采用RSA,会产生一个新的随机数作为premaster secret,将该随机数通过证书中公钥或者server_key_exchange消息内的临时RSA密钥加密发过去客户端根据premaster secret,ClientHello.random, ServerHello.random三个值算出master secret作为对称密钥服务器端收到premaster secret以后,也根据这三个值算出master secret。
若采用DH,证书中已包含了DH算法需要的两个整数p,g,直接通过算法根据已经交换的两个随机数可以算出premaster secret,服务器端也可以算出同样的premaster secret。
4终止结束
根据密码套件中协商的结果进行通信,master secret不用来加密验证密码。需要再次整合出密料实现双向安全。
(3)应用技术及理论
Diffie-Hellman:一种确保共享KEY安全穿越不安全网络的方法,它是OAKLEY的一个组成部分
http://www.doc88.com/p-695165344931.html
以太帧:可以看到MAC
网络层:可以看IP
TCP :可以看到端口
参考文献:http://ieee802.blog.hexun.com/17537283_d.html
参考文献: TCP协议中的三次握手和四次挥手(图解)
参考文献:http://blog.csdn.net/chelp/article/details/12969907