Wifidog初分析(一)
一、综述
wifidog是搭建无线热点认证系统的解决方案之一，他比nocat、nodog更适合互联网营销思路。常见的使用在openwrt系统上，它实现了路由器和认证服务器的数据交互，在路由器方（客户端）是用C 语言代码，通过wifidog程序和linux iptables防火墙实现接入用户的认证跳转和控制。在认证服务器方（服务端）是通过php（还有java版本的）实现用户的认证流程和管理。
优点：有开源代码，可以很方便的搭建认证系统。方便用户进行需求定制。
缺点：通过iptables方式实现，性能比较差，整体拉低了路由器的数据包处理速度，协议比较繁琐，对认证服务器的造成性能损耗比较大。
二、wifidog 结构分析
Wifidog 客户端代码简析：
├── libhttpd
│ ├── api.c
│ ├── httpd.h
│ ├── httpd_priv.h
│ ├── ip_acl.c
│ ├── Makefile.am
│ ├── protocol.c
│ ├── README
│ └── version.c
├── src
│ ├── auth.c
│ ├── auth.h
│ ├── centralserver.c
│ ├── centralserver.h
│ ├── client_list.c
│ ├── client_list.h
│ ├── commandline.c
│ ├── commandline.h
│ ├── common.h
│ ├── conf.c
│ ├── conf.h
│ ├── debug.c
│ ├── debug.h
│ ├── firewall.c
│ ├── firewall.h
│ ├── fw_iptables.c
│ ├── fw_iptables.h
│ ├── gateway.c
│ ├── gateway.h
│ ├── http.c
│ ├── httpd_thread.c
│ ├── httpd_thread.h
│ ├── http.h
│ ├── Makefile.am
│ ├── ping_thread.c
│ ├── ping_thread.h
│ ├── safe.c
│ ├── safe.h
│ ├── util.c
│ ├── util.h
│ ├── wdctl.c
│ ├── wdctl.h
│ ├── wdctl_thread.c
│ └── wdctl_thread.h
这是wifidog的部分源码。
下面再来看看wifidog的认证流程图：
认证的大致流程可以从上图中看到。下面结合代码的实现与图1来说下wifidog 的工作过程。
1、在网关上配置好wifidog.conf 后，运行wifidog程序。此时wifidog对wifidog.conf进行解析，并获取其中的配置选项。如：认证服务的地址或url 项Hostname 192.168.2.103 还有认证服务下的文件选项。如果为根目录下就是认证服务的处理程序，那么就设置为 Path /。Wifidog启动时会将这些参数读取，并保持在一个数组中，以供之后使用。然后调用iptables加入防火墙规则，阻止所以连接网关的用户上网。但是到达认证服务器的规则是打开的状态。
0 ACCEPT all -- * * 0.0.0.0/0 192.168.2.103
55 2772 REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 2060
小结：此节主要用到conf.* 解析配置文件，firewall.* fw_iptables.* 进行防火墙规则添加 。
2、程序运行起来后，当有用户进行外网访问时。根据②中的防火墙规则，会将HTTP请求的外部IP地址和端口通过NAT方式重定向至本地wifidog内嵌HTTP服务器的地址和端口上，并由内嵌HTTP服务器进行服务，而内嵌HTTP服务器的路径和回调处理。然后将具体的请求信息发送给认证服务器。代码不详谈，下面看个实例URL：
POST /authpuppy/web/login/?gw_address=192.168.2.1&gw_port=2060&gw_id=default&url=http%3A//quietmadman.blog.51cto.com/3269500/1384761 HTTP/1.1
当我访问时，wifidog 将我访问的url重定向到上述的url上。目的就是去服务端做认证。
可以看到这里有这几个参数信息：
gw_address，路由器的LAN地址
gw_port：为wifidog的监听端口
gw_id：路由器的标识名
mac：客户端设备的MAC地址
url：为客户端访问的原URL（以便于重定向）
3、接步骤2，wifidog发送上述的url给认证服务器。这里我们使用的认证服务器是authpuppy。安装了apAuthSplashOnlyPlugin 插件。该插件无需输入用户名、密码，但需要点击按钮方可上网，也算是无秘钥认证。
接下来说下抓包看到的认证过程：
POST /authpuppy/web/login/?gw_address=192.168.2.1&gw_port=2060&gw_id=default&url=http%3A//quietmadman.blog.51cto.com/3269500/1384761 HTTP/1.1
... ...
Cookie: authpuppy=3oft24lljrish4731dibh2ji80
gw_id=default&gw_address=192.168.2.1&gw_port=2060&authenticator=apAuthSplashOnly&submit%5BapAuthSplashOnlyConnect%5D=Connect&apAuthSplashOnly%5Boptional_name%5D=HTTP/1.1 302 Found
... ...
Location: http://192.168.2.1:2060/wifidog/auth?token=8eb3aae0ade3492cad361443ac54b9dcb644dbb2
上述过程是wifidog给认证服务器发送请求认证的URL，服务器收到后回送一个带token值的url到网关上。此段处理在服务端。网关收到后再次发送信息给认证服务器，如下报文：
GET /wifidog/auth?token=8eb3aae0ade3492cad361443ac54b9dcb644dbb2 HTTP/1.1
... ...
HTTP/1.0 307 Redirect to portal
Server: Hughes Technologies Embedded Server
Location: http://192.168.2.103:80/authpuppy/web/portal/?gw_id=default
Date: Mon, 07 Jul 2014 15:16:00 GMT
... ...
GET /authpuppy/web/auth/?stage=login&ip=192.168.2.222&mac=64:27:37:e1:c3:d3&token=8eb3aae0ade3492cad361443ac54b9dcb644dbb2&incoming=0&outgoing=0&gw_id=default HTTP/1.0
... ...
网关GET到token后，陆续的向认证服务器发送相关认证信息。
这里主要是两大步骤：
1)通过调用 auth_server_request(&auth_response, REQUEST_TYPE_LOGIN, r->clientAddr, mac, token, 0, 0); 让 认证服务器 对该客户端的 token 进行校验；
2)根据 认证服务器 返回的 token 校验结果进行不同的处理（主要是对该客户端的防火墙过滤规则进行不同的设置），这里主要以 AUTH_ALLOWED 校验结果进行分析，这里主要是两个动作：
2).1，通过 fw_allow 函数调用对此客户端"放行"；
2).2，返回重定向至 认证服务器的 portal 路径访问的响应
GET /authpuppy/web/portal/?gw_id=default HTTP/1.1
Accept: image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, /
... ...
Host: 192.168.2.103
... ...
Location: http://quietmadman.blog.51cto.com/3269500/1384761
Wifidog返回信息到认证服务器的portal，portal返回给网关的信息如上。最后重定向到用户最初始访问的url上。
Wifidog 的client代码大致是这些。
本文章由 http://www.wifidog.pro/2014/12/25/wifidog%E5%88%86%E6%9E%90.html 整理编辑，转载请注明出处