防代理协议.docx

上传人:b****7 文档编号:26641642 上传时间:2023-06-21 格式:DOCX 页数:14 大小:26.27KB
下载 相关 举报
防代理协议.docx_第1页
第1页 / 共14页
防代理协议.docx_第2页
第2页 / 共14页
防代理协议.docx_第3页
第3页 / 共14页
防代理协议.docx_第4页
第4页 / 共14页
防代理协议.docx_第5页
第5页 / 共14页
点击查看更多>>
下载资源
资源描述

防代理协议.docx

《防代理协议.docx》由会员分享,可在线阅读,更多相关《防代理协议.docx(14页珍藏版)》请在冰豆网上搜索。

防代理协议.docx

防代理协议

 

以太网交换机防代理协议

技术白皮书

 

武汉烽火网络有限责任公司

文档版本:

V1.0

时间:

2006-10-12

撰写:

交换机项目组相关人员,技术支持部

审核:

技术支持部

发布:

武汉烽火网络有限责任公司市场部

读者对象:

烽火网络客户,烽火网络市场及客服所有人员

修订记录

修订序号

修订日期

修订内容描述

修订者

版本

 

声明:

1.本文仅作市场宣传参考,不作合同签定、技术配置的依据。

由于编者技术水平有限,欢迎批评和指导。

2.版权所有,保留一切权力

非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本书的部分或全部,并不得以任何形式传播。

3.有任何疑问请垂询市场部技术支持部。

摘要

本文介绍武汉烽火网络有限公司F-Engine系列以太网交换机的防代理功能。

Proxy技术给网络运营商和各类ISP们带来了很大的损失。

烽火网络推出了以太网交换机防代理技术,来力求满足运营商的功能需求以及保障运营商的利益。

本文对防代理(Proxy)技术协议做了详细的描述。

关键词

ProxyNAT

目录

一、简述5

二、协议描述5

1、报文描述6

2、状态机描述9

3、防代理协议在以太网上的格式11

4、PC上是否运行代理软件的检测11

一、简述

网络接入技术虽然有了各种各样的认证机制,比如PPPoE、IEEE802.1x,但是身份认证技术并不能防止非法用户PC通过合法用户PC上的代理软件上网,因为非法用户的数据经过代理软件后对于网络接入设备来说是不能区分这个数据与合法用户发出的数据有任何明显的区别,因此代理软件让运营商蒙受了巨大的经济损失。

本协议希望提供一种办法来防止这种情况的出现。

现有的认证机制已经可以确保对合法用户的验证,如果能够确认合法用户的PC没有安装代理软件,那么网络就可以接受合法用户的数据。

所以解决的办法就是让用户的PC机上安装防代理软件,如果发现用户安装了代理软件、那么就禁止这台PC机向网络发送数据,同时为了防止用户不启用防代理软件,所以还需要确保用户的PC运行了防代理软件。

二、协议描述

防代理协议分为client部分与server部分,client部分运行在用户的PC机上,server部分运行在交换机或者路由器等接入设备上。

建链过程:

APClient上的客户端软件首先并不使能防代理功能;

然后APClient向网络发送AP-Discover消息,APServer接收到之后以AP-Check或者AP-Auth-Request进行应答,AP-Check携带一个随机序列,APClient发送AP-Check-Response作为应答,如果APServer发现Check-Response失败,那么说明用户使用的client软件有问题,直接release这个用户、不用发送AP-Disconnct消息、并且这个用户需要等待一段时间之后才能再次连接。

如果AP-Check-Response结果正确,APServer发送AP-Start消息给客户,APClient收到该消息后启动防代理功能,此时APClient进入已连接状态,APServer可以接收这个用户发出的普通数据,然后APServer周期的发送AP-Check消息给APClient(此时AP-Check消息不能携带认证指示)、并等待客户端的AP-Check-Response以防止客户中途关闭客户端软件。

如果APServer需要认证用户的身份、那么收到APClient的Discover消息时,以AP-Auth-Request消息做答,AP-Auth_Request消息中包含一个随机的序列,APClient接收到AP-Auth-Request后发送AP-Auth-Response消息给APServer、其中使用密码计算后的结果,然后APServer再发送AP-Auth-Result消息给APClient,如果用户验证成功,那么APServer接着发送AP-Check消息,等待APClient的应答,如果AP-Check-Response正确、APServer发送AP-Start消息给APClient,此时该客户进入已连接状态,然后APServer周期的发送AP-Check消息与APClient上的软件进行通信以确保该软件在继续运行。

拆链过程:

APClient与APServer均可以发起拆链过程,拆链的发起方首先发送AP-Disconnect-Req消息,该消息的接收方收到之后发送AP-Disconnect-Check消息,AP-Disconnect-Check该消息中包含一个随机序列,拆链的请求者需要对随机序列进行计算后发送AP-Disconnect-Response消息给对方,如果拆链的接收方发现AP-Disconnect-Response计算结果正确,那么断开连接,否则则不断开连接。

拆链过程加入认证过程主要是为了防止有恶意用户伪造拆链消息来拆除其它正在上网的用户。

1、报文描述

AP协议的头部定义:

协议字段

报文总长

消息……

协议字段:

本字段为1字节,本版本为第一版本,填入1;

报文总长:

本字段为2字节,指示本报文包含的消息的总长度,即本字段的值不包含“协议字段”与“报文总长”占用的字节数。

消息的格式定义:

消息类型

消息长度

消息内容

消息类型:

本字段长度为2字节,指示消息的类型;

消息长度:

本字段长度为2字节,指示消息内容的长度,本字段指示的长度值不包含“消息类型”与“消息长度”字段占用的字节数。

(1)AP-Discover

本消息由APclient发送,APserver接收到之后以AP-Response或者AP-Check进行应答。

AP-Discover的消息格式:

AP-Discover

长度

AP-Discover消息编码:

1

长度:

0,即AP-Discover消息不包含其它内容

(2)AP-Check

本消息由APServer发送。

AP-Check

长度

随机序列

AO-Check消息编码:

2

长度:

16,

随机序列:

长度为16个字节。

注:

每次AP-Check的“随机序列”包含的内容一定要改变,APServer需要记录每个发送的“随机序列”。

(3)AP-Check-Response

本消息由APClient发送。

AP-Check-Response

长度

随机序列

校验码

AP-Check-Response消息编码:

3

长度:

32

随机序列:

APserver发送过来的序列,在response中包含此序列是可以让APserver进行匹配判断,以防止恶意用户将网络上正确的response消息使用抓包攻击截取下来之后、再发送给APserver。

校验码:

16字节的对收到的AP-Check中“随机序列”进行AP校验后生成的结果。

APServer收到AP-Check-Response后,查看校验码是否正确。

(4)AP-Start

本消息由APServer发送,告诉APClient防代理软件开始生效。

AP-Start

长度

内容

AP-Start消息编码:

4

长度:

0,即本消息没有特殊内容。

(5)AP-Stop

本消息由APServer发送,告诉APClient防代理软件停止防代理操作。

AP-Stop

长度

内容

AP-Stop消息编码:

5

长度:

0,即本消息不包含特殊内容

(6)AP-Disconnect-Req

本消息可由APServer或APClient发送,以发起拆链请求。

AP-Disconnect-Req

长度

内容

AP-Disconnect-Req消息编码:

6

长度:

0,即本消息不包含特殊内容

(7)AP-Disconnect-Check

本消息由拆链的接受方发送,用以验证发起方不是恶意用户。

AP-Disconnect-Check

长度

随机序列

AP-Disconnect-Check消息编码:

7

长度:

16

随机序列:

16字节的随机序列

(8)AP-Disconnect-Response

本消息由拆链的发起方发送,对AP-Disconnect-Check进行应答。

AP-Disconnect-Response

长度

校验码

AP-Disconnect-Response消息编码:

8

长度:

16字节

校验码:

通过对收到的AP-Disconnect-Check中的“随机序列”进行AP计算后的结果。

拆链的接收方如果发现AP-Disconnect-Response中校验码不正确,那么就不拆链。

如果AP-Disconnect-Response中的校验码正确,则断开连接。

(9)AP-Auth-Request

本消息由APServer发送,用以验证客户是否是合法用户。

AP-Auth-Request

长度

“随机序列”

AP-Auth-Request消息编码:

9

长度:

16

随机序列:

16字节的随机序列

(10)AP-Auth-Response

本消息由APClient发送,对APServer的AP-Auth-Request中的“随机序列”进行MD5计算,然后返回运算结果。

AP-Auth-Response

长度

校验码

用户名长度

用户名

AP-Auth-Response消息编码:

10

长度:

可变长,最长不超过81、最小不小于18。

校验码:

16字节,使用用户的密码用MD5算法对收到的AP-Auth-Request中的“随机序列”运算后的结果;

用户名长度:

1字节;

用户名:

长度由“用户名长度”指示,用户名最长不能超过64字节、不得小于1。

(11)AP-Auth-Result

本消息由APServer发送,返回认证的结果。

AP-Auth-Result

长度

认证结果

AP-Auth-Result消息编码:

11

长度:

1字节

认证结果:

1字节,值为1表示认证成功、为2表示认证失败。

2、状态机描述

APServer上针对每个APClient的状态机:

Init(0)

Chk-Sent

(1)

Open

(2)

AuthReq-Sent(3)

Rel-Sent(4)

RelChk-Sent(5)

Dead(6)

Discover

F1

Chk-Res

F2

F3

Auth-Res

F4

Rel

F5

Rel-Res

F6

Rel-Chk

F7

ChkTimeout

F8

ChkRes-Timeout

F9

Auth-Timeout

F10

RelChk-Timeout

F9

RelRes-Timeout

F11

Remove

F12

F13

F14

F15

F16

处理描述:

F1:

发送AP-Check消息、启动chkRes定时器,状态改变为Chk-Sent;或者发送AP-Auth-Req、启动auth定时器、状态改变为AuthReq-Sent;

F2:

首先查看check-Response中的“随机序列”是否与发送的相同,如果不相同则什么都不做。

如果相同,则:

停止check定时器,进行check校验,如果校验成功则启动check定时器、发送AP-Start消息、进入状态Open;如果校验失败则进入状态dead;

F3:

首先查看check-Response中的“随机序列”是否与发送的相同,如果不相同则什么都不做。

如果相同,则:

停止check定时器,进行check校验,如果校验成功则启动check定时器;如果校验失败则进入状态dead;

F4:

停止auth定时器,并根据用户名查找密码进行验证,如果验证失败则:

发送验证失败消息、进入状态dead;如果验证成功则:

发送验证成功消息、发送AP-Check消息、启动check定时器,进入状态Chk-Sent;

F5:

停止check定时器、发送AP-Disconnect-Check、启动定时器relRes,进入状态RelChk-Sent;

F6:

如果“随机序列”不匹配则什么都不做;否则,停止relRes定时器,如果验证正确则进入状态dead;如果验证不正确则:

启动check定时器,进入状态open;

F7:

停止relChk定时器,发送AP-Disconnect-Response,进入状态dead;

F8:

发送AP-Check,启动check定时器;

F9:

进入状态dead;

F10:

发送验证失败消息,进入状态dead;

F11:

启动check定时器,进入状态open;

F12:

停止chkRes定时器,进入状态dead;

F13:

停止check定时器,发送AP-Disconnect-Req、启动relChk定时器、进入状态Rel-Sent;

F14:

停止auth定时器,进入状态dead;

F15:

停止定时器relChk,进入状态dead;

F16:

停止定时器relRes,进入状态dead。

说明:

进入状态dead,需要将对该用户的记录彻底删除,并让该用户等待一段时间之后才能再次发起连接。

APClient的状态机:

Init

Discover-Sent

ChkRes-Sent

open

AuthRes-Sent

Rel-Sent

RelChk-Sent

connect

F1

close

F2

F3

F4

F5

F6

F7

Check

F8

ApStart

F9

F10

ApStop

F11

AuthReq

F12

DiscoverTimeout

F13

ChkRestimeout

F14

Authtimeout

F14

Rel

F15

Relcheck

F16

RelRes

F17

RelChk-Timeout

F14

RelChkRes-Timeout

F18

处理描述:

F1:

发送APDiscover消息,启动discover消息,进入状态discoversent;

F2:

停止discover定时器,进入状态init;

F3:

停止chkRes定时器,进入状态init;

F4:

发送APDisconnect消息,停止防代理功能,启动RelChk定时器,进入状态Rel-Sent;

F5:

停止Auth定时器,停止防代理功能,进入状态init;

F6:

停止RelChk定时器,进入状态init;

F7:

停止防代理功能,停止RelRes定时器,进入状态init;

F8:

停定时器discover,发送AP-Check-Response消息、启动ChkRes定时器,进入状态ChkRes-Sent;

F9:

停止定时器chkRes,启动防代理功能,进入状态open;

F10:

启动防代理功能;

F11:

停止防代理功能;

F12:

停止discover定时器,发送AP-Auth-Response消息,启动auth定时器,进入状态AuthRes-Sent;

F13:

如果超时次数大于等于3,则进入状态init;如果超时次数小于3,那么发送APDiscover消息,并启动discover定时器,状态不变;

F14:

进入状态init;

F15:

发送AP-Disconnect-Check消息,启动定时器RelChkRes,进入状态RelChk-Sent;

F16:

停止RelChk定时器,发送AP-Disconnect-Response,进入状态init;

F17:

如果check正确,那么停止防代理功能、停RelChkRes定时器,进入状态init;如果check不正确,则继续维持在本状态;

F18:

进入状态open;

3、防代理协议在以太网上的格式

本协议在编写时期望能够在不同的物理链路上运行。

目前只能在以太网上运行,因此本节主要介绍防代理协议在以太网上的格式。

防代理协议的以太网类型字段为十六进制的FFF7,在发送APDiscover时使用的目的mac地址为01-80-c2-00-00-0F,后续的防代理协议帧的目的mac地址都是确定的单播帧,即对于APClient而言、目的mac地址是APServer的mac地址;对于APServer而言,目的mac地址是APClient的mac地址。

4、PC上是否运行代理软件的检测

APClient上的客户端程序在启动时并不进行防代理操作,只有在收到APStart消息时才进行防代理操作。

首先说说如何判断代理软件在PC中运行,本协议只简单说明几种方法:

(12)是否有代理软件运行。

即客户端程序判断当前是否有知名的代理软件程序在运行,但由于代理软件种类很多,因此防代理功能可能对于某些不知名的代理软件失效。

(13)检测PC是否已绑定在一些知名端口上,以此判断该pc是否在运行代理软件。

此种方法也可能带来一些负作用,比如,有PC开了htpp或者ftp网站,那么防代理客户端程序就可能进行误判,以为PC是在运行代理软件。

(14)发包进行检测。

防代理客户端程序发出一个连接请求给本PC机(连接请求中的目的IP地址由防代理程序设定为一个特殊地址),如果本PC机接受了本连接、并且向网关发送连接请求、并且该连接请求的目的IP地址是防代理程序设定的IP地址,那么就可以确定这台PC机上运行了代理软件。

但是本方法在实现上可能比较麻烦。

5、防代理软件如何进行防代理

本协议对如何防代理不作特别说明,实现者可以通过禁止该PC机向外发送数据、或者丢弃非法用户发送到这台合法PC机的数据来实现防代理功能。

6、收到check时的处理

APCheck消息的功能主要是用于keepalive、以及确保代理客户端软件仍然在运行,为了避免使用者在使用客户端软件正常连接到网络中之后将代理客户端软件关掉、然后使用某种工具将曾经应答过的AP-Check-Response发回,因此对于checkresponse消息需要进行某种验证。

目前的考虑是客户端软件与服务器软件之间共享一个密码,AP-Check消息中携带一个随机序列,AP-Check-Response消息需要使用这个共享密码来对随机序列进行加密,然后将结果返回。

这个机制本省不是很安全,因为所有的客户端软件都需要事先知道这个密码,所以如果这个密码泄漏之后、恶意用户可以开发一个自己的客户端软件来欺骗APServer,因此这个密码需要进行严格保密。

目前对于收到check消息时使用的加密算法选用MD5。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 教育学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1