佐须之男 发布的文章

Wifidog流程网关协议v2

线路协议
回复形式

在线路协议中有以下说明:

  • 紧凑表示(当浏览分散式网络时,宽带也不便宜)
  • 用户可读
  • 能够为C语言和PHP提供快速的解析器,并且比较理想的是能够多语言化
  • 适用于与配置文件分享解析器和格式
  • 适用于清晰的显示树结构(例如认证服务器列表)

请求格式

必须遵循请求格式:

  • 每个http请求都有多个操作(例如为多个用户更新统计数据)
  • 保持http传送,因为这能允许完整的NAT和透明代理阻力

以上的一些需求没有适用于RESTFull ROA。然而,保持现有格式事实上把我们限制在了tag-value对列表。理论上即使可以将action=whatever放在列表中间并在协议中申明以下每个参数都是那个action的参数,这将使大多数网络服务器与框架完全混淆。

  Acv:另一个可能性是从PHP进行URL-parsing的方式借用一个页面。将get请求设置到一个数组表示,这将允许公平的逻辑请求捆绑。也就是:

 /page?req[0][action]=Action1&req[0][Param1]=param&req[0][Param...]=param...&req[0][Paramn]=paramn&\


req[...][action]=Action...&req[...][Param1]=param&req[...][Param...]=param...&req[...][Paramn]=paramn&\


req[n][action]=Actionn&req[n][Param1]=param&req[n][Param...]=param...&req[n][Paramn]=paramn

  Acv:当比较容易进行解析的时候,这个格式会保持用户可读

功能性需求

  • 允许认证服务器发送一些主要的配置变更
  • 允许基于MAC认证的非连接关系
  • 允许per-connection防火墙政策
  • 允许per-connection宽带管理,不只限于设置数量
  • 允许全球宽带管理
  • 指定围墙花园
  • 指定最初连接用户列表

指令
NOOP
基本上只为网关心跳。可能会指定操作间很短的延迟,并且如果在实际操作之间延迟的话,就会发送NOOP。
AUTH_VERIFY
STATS_UPDATE

提议方案
  Philippe:

 I think we could have a Hash kind of structure like this:

 * protocol_version: 1 (start with this to identify protocol)

 * wifidog_version: ...

 * status:

   * uptime, etc.

 * connected_clients:

   * stats, etc.

  简单回复:

 {

    "protocol_version": 1,

    "config": {

        "login_url": "https://auth.server/login.php",

        "portal_url": "http://portal.server/",

        ... },

    "clients": [

        { "mac": "00aabbccdd22", "ip": "10.0.0.1", ... },

        { "mac": "00aabbccdd22", "ip": "10.0.0.1", ... },

        ... ]

}

网关和认证服务器通信
2.png

配置

  • 醒目页面,如果auth-server=down(URL)
  • 醒目页面,如果internet=down(内容)
  • 围墙花园(考虑一下DNS超时)
  • 静态MAC黑/白名单
  • 全球防火墙/QOS配置

本文章由 http://www.wifidog.pro/2015/03/31/wifidog%E6%B5%81%E7%A8%8Bwifidog%E5%8D%8F%E8%AE%AE.html 整理编辑,转载请注明出处

Wifidog认证稳定性测试方法及说明

下面是我所使用的测试方法,有其他更好测试方法的网友也可以共享出来。

测试方法:
通过软件发送多个连接请求来达到测试wifidog处理请求的能力,也就是其稳定性。
通过http_load软件发送网站连接请求,查看后台监控wifidog异常,逐渐增加 发送连接请求次数直到wifidog死掉或者重启。

测试环境:
将刷好的带wifidog认证的路由接入Internet和测试机(电脑或者手机)。使用电脑连接到路由后台,以调试模式运行wifidog,以便随时监控wifidog。

测试条件:
wifidog启动中并且测试机没有进行过认证。

预期结果:
wifidog死掉或者重启。

测试步骤:
测试工具链接:http://pan.baidu.com/s/1i36B8ED
将路由器接入外网,确认wifidog启动之后,在不认证的条件下,将http_load.zip压缩包解压到C盘根目录下。打开http_load文件夹,双击运行“wifidog稳定性测试.bat”批处理程序。等待程序运行完毕,打开文件夹下的result.txt即可查看到结果。
1.jpg

(右侧为修改后wifidog版本测试结果)
结果分析:

   30 fetches, 15 max parallel, 50527 bytes, in 0.140625 seconds
   1684.23 mean bytes/connection
   213.333 fetches/sec, 359303 bytes/sec
   msecs/connect: 1.04167 mean, 31.25 max, 0 min
   msecs/first-response: 46.3542 mean, 78.125 max, 15.625 min
   HTTP response codes:
   code 302 – 30


   1.30 fetches, 15 max parallel, 50527 bytes, in 0.140625 seconds
        说明在上面的测试中运行了30个请求,最大的并发进程数是15,总计传输的数据是50527bytes,运行的时间是0.140625秒
   2.1684.23 mean bytes/connection
        说明每一连接平均传输的数据量50527/30=1684.23
   3.213.333 fetches/sec, 359303 bytes/sec
        说明每秒的响应请求为213.333,每秒传递的数据为359303 bytes/sec
   4.msecs/connect: 1.04167 mean
        说明每连接的平均响应时间是1.04167 msecs,31.25 max, 0 min,最大的响应时间31.25msecs,最小的响应时间0 msecs;
   5.msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
   6、HTTP response codes: code 200 — 49 
        说明打开响应页面的类型,如果403的类型过多,那可能要注意是否系统遇到了瓶颈。

   特殊说明:
          测试结果中主要的指标是 fetches/sec、msecs/connect 这个选项,即服务器每秒能够响应的查询次数,用这个指标来衡量性能。

命令参数如下:
-parallel 简写-p :含义是并发的用户进程数。
-fetches 简写-f :含义是总计的访问次数。
-rate 简写-p :含义是每秒的访问频率。
-seconds简写-s :含义是总计的访问时间。

本文章由 http://www.wifidog.pro/2015/03/31/wifidog%E7%A8%B3%E5%AE%9A%E6%80%A7%E6%B5%8B%E8%AF%95.html 整理编辑,转载请注明出处

Wifidog认证wifidog路由接口文档

概述

wifidog是搭建无线热点认证系统的解决方案之一,他比nocat更适合互联网营销思路。目前支持openwrt系统,他实现了路由器和认证服务器的数据交互,在路由器方是用C语言代码,通过wifidog程序和linux iptables防火墙实现接入用户的认证跳转和控制,在认证服务器方是通过php实现用户的认证流程和管理。
优点:有开源代码,可以很方便的搭建认证系统。
缺点:通过iptables方式实现,性能比较差,整体拉低了路由器的数据包处理速度,协议比较繁琐,对认证服务器的造成性能损耗比较大,在安全方面都是明文传输,有一定的安全隐患。

认证流程图:

wifidog-flow-2009.png

网关心跳协议

Wifidog将ping协议作为心跳机制向认证服务器发送当前状态信息。实现认证服务器和每个节点的状态双向健康监测的机制。
请求信息:

http://auth_sever/ping/?gw_id=%s&sys_load=%lu&sys_memfree=%u&sys_load=%.2f&wifidog_uptime=%lu

回复格式:

Pong

例子:

GET /ping/?gw_id=001217DA42D2&sys_uptime=742725&sys_memfree=2604&sys_load=0.03&wifidog_uptime=3861HTTP/1.0 User-Agent:wifidog Host:www.wifidog.pro

用户状态心跳协议

请求格式:

http://auth_server/auth/?stage= &ip= mac= &token= &incoming= &outgoing=

注意:
ip,mac,token为用户的基本信息,incoming/outgoing为用户的连接计数信息。 stage=counter|login|logout,分别表示:已认证,新认证用户,超时需要删除的用户。

回复格式:

Auth:状态码(注意中间冒号和状态码之间有个空格)

状态码:

0-AUTH_DENIED-Userfirewallusersaredeletedandtheuserremoved. 1-AUTH_ALLOWED-Userwasvalid,addfirewallrulesifnotpresent

例子:

GET /auth/?stage=counters&ip=7.0.0.107&mac=00:40:05:5F:44:43&token=4f473ae3ddc5c1c2165f7a0973c57a98&incoming=6031353&outgoing=827770HTTP/1.0 User-Agent:wifidog Host:www.wifidog.pro

跳转协议

对于新连接用户,路由器将其产生的任意url请求通过302重定向到认证平台。

请求格式:

http://auth_server/login/?gw_id= &gw_address= &gw_port= &mac= &url=

例子:

GET /login/? gw_id=808100949391&gw_address=192.168.81.1&gw_port=80&mac=aa:bb:cc:dd:cc:ee&url=http://www.sina.com.cn/HTTP/1.0 User-Agent:wifidog Host:www.wifidog.pro

注册协议

请求格式:

http://gw_ip/wifidog/auth?token=

例子:

GET wifidog/auth?token=12312412124 User-Agent:iphone Host:路由器ip 注册请求成功,以307的方式跳转平台的portal/?gw_id=

本文章由 http://www.wifidog.pro/2015/03/27/wifidog%E6%8E%A5%E5%8F%A3-1.html 整理编辑,转载请注明出处

wifidog分析-Radius协议

从事Radius协议开发有段时间了,小弟不怕才疏学浅,卖弄一下,从RADIUS协议谈谈对身份认证的认识,也总结一下自己。

一.RADIUS协议原理

    RADIUS(Remote Authentication Dial In User Service) 用户远程拨入认证服务,它主要针对的远程登录类型有:SLIP、PPP、telnet和rlogin等。RADIUS协议应用范围很广,包括普通电话、上网业务计费,对VPN的支持可以使不同的拨入服务器的用户具有不同权限。

RADIUS典型应用环境如下:
clip_image002.jpg

RADIUS数据包分为5个部分:
(1) Code:1个字节,用于区分RADIUS包的类型:常用类型有:
接入请求(Access-Request),Code=1;接入允许(Access-Accept),Code=2;接入拒绝(Access-Reject),Code=3;计费请求(Accounting-Request),Code=4等。
(2)Identifier:一个字节,用于请求和应答包的匹配。
(3)Length:两个字节,表示RADIUS数据区(包括Code, Identifier, Length, Authenticator, Attributes)的长度,单位是字节,最小为20,最大为4096。
(4)Authenticator:16个字节,用于验证服务器端的应答,另外还用于用户口令的加密。RADIUS服务器和NAS的共享密钥(Shared Secret)与请求认证码(Request Authenticator)和应答认证码(Response Authenticator),共同支持发、收报文的完整性和认证。另外,用户密码不能在NAS和RADIUS 服务器之间用明文传输,而一般使用共享密钥(Shared Secret)和认证码(Authenticator)通过MD5加密算法进行加密隐藏。
(5)Attributes:不定长度,最小可为0个字节,描述RADIUS协议的属性,如用户名、口令、IP地址等信息都是存放在本数据段。
各个属性的详细编码信息,以及数据格式,限于篇幅,这里不作具体介绍,感兴趣的,可以参看RFC文档,或与我交流。

二.RADIUS协议实现

目前,开源软件包freeRadius , tinyRadius,可以下载到其实现的源码。freeRadius是目前功能最强大的开源RADIUS 服务器软件,采用C语言实现,采用了多进程,进程池的处理方法,拥有很好的吞吐处理能力,同时,提供了连接各种数据库的应用接口,方便用户根据自己的需要进行适当的扩展。值得一提的是,它采用模块化处理,用户可以定做适合自己的认证计费处理模块。
freeRadius的功能强大,也造成了它模块的庞大,不易维护,对安装环境有一些要求。tinyRadius采用Java开发,短小精悍,能接收各种标准协议中的数据包,可以快速的完成对RADIUS数据包的封装与解包,我们可以自己的需要进行某些处理,具有很大的自由度,唯一的缺陷是单线程,没有数据库接口。

三.RADIUS协议对安全的考虑

RADIUS采用UDP协议基于以下几点原因:
1. NAS和RADIUS服务器大多在同一个局域网中,使用UDP更加快捷方便。
2. 简化了服务端的实现。
事实证明,采用UDP协议可行,RADIUS有自己的机制,来解决UDP丢包特点。
如果NAS向某个RADIUS服务器提交请求没有收到返回信息,那么可以要求备份RADIUS服务器重传。由于有多个备份RADIUS服务器,因此NAS进行重传的时候,可以采用轮询的方法。如果备份RADIUS服务器的密钥和以前RADIUS服务器的密钥不同,则需要重新进行认证。
下面重点从RADIUS协议来谈下它在身份认证中如何确保安全认证的。
1. Authenticator:鉴别码,分为请求鉴别码,回应鉴别码。
在“Access-Request”数据包中,Authenticator是一个16字节的随机数,称为“Request Authenticator”。 在机密的整个生存周期中(如RADIUAS服务器和客户端共享的机密),这个值应该是不可预测的,并且是唯一的,因为具有相同密码的重复请求值,使黑客有机会用已截取的响应回复用户。因为同一机密可以被用在不同地理区域中的服务器的验证中,所以请求认证域应该具有全球和临时唯一性。
为防止数据包中数据被截获被篡改,回应鉴别码采用如下方式生成:
ResponseAuth = MD5(Code+ID+Length+RequestAuth+ Attributes+Secret);
回应鉴别码是对整个数据包进行MD5演算产生的16字节索引,防止伪造服务器的回应。
2.加密方式。PAP,CAHP,EAP以及Unix登录认证三种加密认证方式。最常用的是前两种,下面介绍下:
PAP加密,采用此加密方法时,密码存放在User-Password属性中。
User-Password加密方法:
1.在密码的末尾用nulls代替填补形成多个十六个字节的二进制数;
2.把密码按16个字节为一组划分为p1、p2等等;
b1=MD5(Secret + Authenticator) c(1) = p1 异或 b1
b2 = MD5(S + c(1)) c(2) = p2 异或b2
bi = MD5(S + c(i-1)) c (i) = pi 异或 bi
c(1)+c(2)+...+c (i)
在接收时,这个过程被反过来,由于采用异或方式贯穿在每16个字节之间,同样的算法再异或一次,然后配合MD5演算,从而生成原始的密码,尽管这种加密方式是可逆的,黑客截获到密文后,能通过一定的手段来破解出密码,但如果共享密钥未知的情况下,很难破解,也就只能采用蛮力破解方法。使用共享密钥应采用合适的长度,来防止破解,不应过短。

PAP加密方法使密码以密文的方式在网络中进行传输,使黑客仍有有机可乘的机会,但CHAP加密方法阻止了密码的传输。
CHAP加密,采用此加密方法时,密码存放在Chap-Password属性中。
这种加密方法的原则是不是密码在网络中进行传输,而只是传输一个索引值,从而增加了安全性,但这样做的代价是,RADIUS服务端必须要知道用户的密码,从而再现密码索引值来和发来的认证请求中的密码索引值比对。
Chap-Password加密方法:
Md5(chapId+password+chapChallenge);
chapId :可以是随机产生的一字节码;
chapChallenge :NAS生成一个随机挑战字(16个字节比较合适)
该字段有时缺失,读取Authenticator域作为挑战字。
3.共享密钥(Secret):共享密钥在密码加密以及数据包的鉴别码部分都参与了运算,即使RADIUS数据包被截获,但不知道共享密钥,很难破解用户的密码伪造数据。共享密钥应采用合适的长度,不应过短,宽大密码范围能有效提供对穷举搜寻攻击的防卫,随着密钥长度的增加,其破解花费的时间将大大增加。
4.为防止非法用户的重放攻击,造成服务器瘫痪。如果在一个很短的时间片段里,一个请求有相同的客户源IP地址、源UDP端口号和标识符,RADIUS服务器会认为这是上一个重复的请求,将直接丢弃,不做任何处理。

四.总结

Radius协议本身比较易掌握,在应用中,可以结合其自身的密码方式,实现满足企业需要的更高强度的强认证,比如结合各种令牌卡,手机短信等等。对协议进行开发,离不开各种抓包工具,像sniffer,tcpdump,ethereal等抓包工具的使用。
外部用户要访问某局域网络中计算机设备,其访问方式有多种,比如采用VPN拨号,Telnet等等。如用户Telnet登陆时,产生用户名和密码信息,而NAS服务器AAA配置中指定了采用RADIUS作为认证服务器,则将其封装成RADIUS请求数据包发送到RADIUS服务器进行身份认证,RADIUS服务器通过NAS和用户进行交流,以提示用户认证通过与否,以及是否需要Challenge身份认证。

其工作原理为:用户接入NAS (Net Access Server),NAS一般为路由器等设备,NAS向RADIUS服务器使用Access-Request数据包提交用户信息,包括用户名、密码等相关信息,其中用户密码是经过MD5加密的,双方使用共享密钥,这个密钥不经过网络传播;RADIUS服务器对用户名和密码的合法性进行检验,必要时可以提出一个Challenge,要求进一步对用户认证,也可以对NAS进行类似的认证;如果合法,给NAS返回Access-Accept数据包,允许用户进行下一步工作,否则返回Access-Reject数据包,拒绝用户访问;如果允许访问,NAS向RADIUS服务器提出计费请求Account-Require,RADIUS服务器响应Account-Accept,对用户的计费开始,同时用户可以进行自己的相关操作。
RADIUS还支持代理和漫游功能。简单地说,代理就是一台服务器,可以作为其他RADIUS服务器的代理,负责转发RADIUS认证和计费数据包。所谓漫游功能,就是代理的一个具体实现,这样可以让用户通过本来和其无关的RADIUS服务器进行认证。
RADIUS能够实现其功能依赖于它自身的数据包结构。RADIUS采用的是UDP传输协议,认证和计费监听端口一般分别为:1812,1813。
以太网上的RADIUS封装后的包结构如下:
以太帧头|IP包头|UDP包头|RADIUS数据包|以太网FCS

在这里我们关心的是红色RADIUS数据包部分。
RADIUS数据包的格式如下:
2.gif

本文章由 http://www.wifidog.pro/2015/03/27/wifidog%E5%88%86%E6%9E%90-2.html整理编辑,转载请注明出处