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
認證的大致流程可以從圖1中看到。下面結合代碼的實現與圖1來說下wifidog 的工作過程。
1、在網關上配置好wifidog.conf 后，運行wifidog程序。此時wifidog對wifidog.conf進行解析，並獲取其中的配置選項。如：認證服務的地址或url 項Hostname 192.168.2.103 還有認證服務下的文件選項。如果為根目錄下就是認證服務的處理程序，那么就設置為 Path /。Wifidog啟動時會將這些參數讀取，並保持在一個數組中，以供之后使用。然后調用iptables加入防火牆規則，阻止所以連接網關的用戶上網。但是到達認證服務器的規則是打開的狀態。
①0 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
... ...
Referer: http://192.168.2.103/authpuppy/web/login/?gw_address=192.168.2.1&gw_port=2060&gw_id=default&url=http%3A//quietmadman.blog.51cto.com/3269500/1384761
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, */*
Referer: http://192.168.2.103/authpuppy/web/login/?gw_address=192.168.2.1&gw_port=2060&gw_id=default&url=http%3A//quietmadman.blog.51cto.com/3269500/1384761
... ...
Host: 192.168.2.103
... ...
Location: http://quietmadman.blog.51cto.com/3269500/1384761
Wifidog返回信息到認證服務器的portal，portal返回給網關的信息如上。最后重定向到用戶最初始訪問的url上。
Wifidog 的client代碼大致是這些。
三、認證服務端簡介
服務端官方推薦的有兩個，一個是authpuppy，還有一個是wifidog-auth。兩個環境都已經搭建成功。
Authpuppy主要是一個authpuppy.core.php ，類似Linux的管理方式，中心是一個內核文件。擴展功能是以plugin插件的方式進行加載、卸載管理的。
優點：可管理性比較好，隨用隨加載；不用既可以卸載掉。
缺點：代碼不易閱讀。因要求易於管理，插件模塊形式要求嚴格。對於小型功能來說浪費時間。
Wifidog-auth顯得就是“全面”，理解起來稍微簡單。
認證主要分為三塊，ping保活、login認證、portal認證。代碼可能有不同，但是有相同的協議，以及相同的回復內容。下面是wifidog與服務端通信協議的幾個例子。
網關心跳（Ping協議）
Wifidog將ping協議作為心跳機制向認證服務器發送當前狀態信息。這可以實現為認證服務器每個節點的狀態生成中央日志。
Wifidog客戶端在conf文件中進行設置，目的是通過http定期啟動thread(ping_thread.c)向認證服務器發送狀態信息。信息格式如下：
http://auth_sever/ping/?
gw_id=%s
sys_uptime=%lu
sys_memfree=%u
sys_load=%.2f
wifidog_uptime=%lu"
通過系統調用wifidog客戶端收集的數據
Headers/
HTTP/1.0\r\n"
"User-Agent: WiFiDog %s\r\n"
"Host: %s\r\n"
一個典型的HTTP需求應該是：
GET /ping/?gw_id=001217DA42D2&sys_uptime=742725&sys_memfree=2604&sys_load=0.03&wifidog_uptime=3861 HTTP/1.0( k# O# X) };
User-Agent: WiFiDog 1.1.3_beta62 T. R"
Host: auth.ilesansfil.org
認證服務器認證協議
這個頁面描述了當用戶已經被認證並允許訪問互聯網時，為了認證用戶和進程，wifidog網關和認證服務器之間的信息傳送。
Wifidog客戶端將定期的啟動一個thread來報告每個用戶的連接狀況。目前它被用來報告每個用戶輸入/輸出計數器，以顯示用戶依然在現，並允許認證服務器將不再連接的用戶斷開。
以下是發給每個在線用戶的信息
auth_server:/auth/index.php?
stage=
ip=
mac=
token=
incoming=
outgoing=
注意：stage=計數器/登錄，取決於是否是新客戶端
即使輸入輸出變量會在所有信息中出現，但他們只對處於*counter*階段的信息有效。其它情況下輸入輸出經常設置為0。
在做回復時，認證服務器會以有效身份或新用戶信息，或者認證服務器錯誤提示形式進行回復。
回復格式如下：
Auth: <number from user status list>
新用戶狀態為：
0 - AUTH_DENIED - User firewall users are deleted and the user removed.% u) i D; j: i4 J' X) \/ P
6 - AUTH_VALIDATION_FAILED - User email validation timeout has occured and user/firewall is deleted7 A% n+ s. z3 O9 r
1 - AUTH_ALLOWED - User was valid, add firewall rules if not present! A" _/ B* a8 ~$ g
5 - AUTH_VALIDATION - Permit user access to email to get validation email under default rules
-1 - AUTH_ERROR - An error occurred during the validation process
注意：認識服務器錯誤一般不會改變防火牆或用戶狀態
標准的URL為：
GET /auth/?stage=counters&ip=7.0.0.107&mac=00:40:05:5F:44:43&token=4f473ae3ddc5c1c2165f7a0973c57a98&incoming=6031353&outgoing=827770 HTTP/1.0
User-Agent: WiFiDog 1.1.3_beta6
Host: auth.ilesansfil.org
網關重定向瀏覽器
客戶端瀏覽器在不同情況下會被重定向到其它頁面：
初始化請求：
基於捕捉，客戶端會被網關重定向到以下URL：
l login/?gw_address=%s&gw_port=%d&gw_id=%s&url=%s
例如：https://auth.ilesansfil.org/login/?gw_id=0016B6DA9AE0&gw_address=7.0.0.1&gw_port=2060
初始化請求之后
當請求被處理並且客戶端已經被重定向到網關時
如果服務器回復AUTH_DENIED：注意你通常在標准認證服務器上看不到這樣的提示。客戶端將不會被重定向回網關。
l gw_message.php?message=denied
如果服務器回復AUTH_VALIDATION:
l gw_message.php?message=activate
如果服務器回復AUTH_ALLOWED:這是門戶重定向
l portal/?gw_id=%s
如果服務器回復AUTH_VALIDATION_FAILED:注意你將不會在標准認證服務器看到此回復。客戶端將不會重定向回網關。
l gw_message.php?message=failed_validation
認證服務器重定向瀏覽器
基於成功登錄，客戶端將被重定向到網關。 http://" . $gw_address . ":" . $gw_port . "/wifidog/auth?token=" . $token
URL示例：http://7.0.0.1:2060/wifidog/auth?token=4f473ae3ddc5c1c2165f7a0973c57a98