分类 wifidog原理 下的文章

wifidog接口文档

ifidog是搭建无线热点认证系统的解决方案之一,他比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:cnrouterwifidog
Host: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:cnrouterwifidog
Host: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:cnrouterwifidog
Host:wifidog.pro

注册协议
平台确定成功注册用户,开通互联网权限,将用户请求重定向到路由器,完成注册。
请求格式:
http://gw_ip/wifidog/auth?
token=
例子:
GETwifidog/auth?token=12312412124
User-Agent:iphone
Host:路由器ip
注册请求成功,以307的方式跳转平台的portal/?gw_id=

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

wifidog认证

前段时间使用wifidog进行wifi强制认证,现在做个小结。
1.首先简单说说wifidog认证的过程
客户端首次连接到wifi后,浏览器请求将会被重定向到:
login/?gw_address=%s&gw_port=%d&gw_id=%s&url=%s
验证通过后,客户端被重定向到网关,url格式如下:
http://网关地址:网关端口/wifidog/auth?token=
wifidong会启动一个线程周期性地报告每一个用户的状态信息,并通过如下地址发送给认证
服务器:
auth_server:/auth/?stage=
ip=
mac=
token=
incoming=
outgoing=
认证服务器根据该状态信息决定是否允许该用户继续连接,并回复网关,回复格式为:Auth:状态码,
如:Auth:1
常用状态码:
0:AUTH_DENIED,表示拒绝
1:AUTH_ALLOWED,验证通过
验证通过后,将重定向到如下地址:
portal/?gw_id=%s
wifidog的ping协议
wifidog通过ping协议将当前状态信息发送给认证服务器,发送地址为:
http://auth_sever/ping/?
gw_id=%s
sys_uptime=%lu
sys_memfree=%u
sys_load=%.2f
wifidog_uptime=%lu
认证服务器须返回一个“Pong”作为回应。
2.实战应用
struts配置文件:

<package name="index" namespace="/" extends="interceptorMy,struts-default">
<action name="login/" class="goodsAction" method="login">
<result name="success" type="redirect">/Login/index.jsp</result>
<result name="input">/error.jsp</result>
</action>
<action name="ping/" class="goodsAction" method="ping">
</action>
 <action name="auth/" class="goodsAction" method="auth">
</action>
<action name="portal/" class="goodsAction" method="portal">
</action>
</package>

Action方法

public String login() {
    try{
        System.out.println("login start!");
                System.out.println("gw_port:"+gw_port);
        System.out.println("login end!");

     }
    catch(Exception e)
    {
        e.printStackTrace();
        return INPUT;
    }
    return "success";
}
public void ping() {
    try{
        System.out.println("ping start!");
        System.out.println(gw_id);
        ServletActionContext.getResponse().getWriter().write("Pong");
        System.out.println("ping end!");
         }
    catch(Exception e)
    {
        e.printStackTrace();
    }
}
public void portal() {
    try{
        System.out.println("portal start");
        System.out.println("protal"+token);
    ServletActionContext.getResponse().sendRedirect("/demo/listAction");
        System.out.println("portal end");
     }
    catch(Exception e)
    {
        e.printStackTrace();
    }
}
public void auth() {
    try{
        System.out.println("auth start!");
        System.out.println("mac"+mac);
        System.out.println("stage"+stage);
        System.out.println("token"+token);
        ServletActionContext.getResponse().getWriter().write("Auth: 1");
        System.out.println("auth end!");

     }
    catch(Exception e)
    {
        e.printStackTrace();
    }
}

/Login/index.jsp代码:

<%
String path = request.getContextPath();
String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
    DateFormat format=new SimpleDateFormat("yyMMddHHmmss");
    String formatData=format.format(new Date());
    int ramdom=new Random().nextInt(1000);
    String token=formatData+ramdom;
    if(session.getAttribute("token")==null)
       session.setAttribute("token",token);

%>
<form method="GET" action='http://192.168.1.1:2060/wifidog/auth'>
<input type='hidden' name='token' value="<s:property value="#session.token" />" />
<input type='submit' value='Welcome!'/>
</form>

上面的192.168.1.1为网关的ip,2060为网关端口。
当然,完全可以在处理完login后直接跳到该地址。我们这里为演示其认证流程,故跳到该页面
效果:
客户端连接到wifi后,打开任何连接均跳到上面的index.jsp中,点击"Welcome"后,跳到/demo/listAction,即我们的目标地址。此后点击其他连接将不再拦截。
提示:安装wifidog的路由器必须可以访问Internet,否则wifidog拦截失败,无法跳到我们设定的页面。

转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://wxhhbdx.blog.51cto.com/2986356/1338059

本文章由 http://www.wifidog.pro/2015/01/26/wifidog%E8%AE%A4%E8%AF%81-1.html 整理编辑,转载请注明出处

wifidog 源码初分析(4)

在上一篇《wifidog 源码处分析(3)》的流程结束后,接入设备的浏览器重定向至 路由器 上 wifidog 的 http 服务(端口 2060) /wifidog/auth 上(且携带了 认证服务器 为此接入设备分配的 token),本篇就是从 wifidog 接收到 /wifidog/auth 的访问后的 校验流程。

根据《wifidog 源码初分析(2)》中描述的,在 wifidog 启动 http 服务前,注册了一个针对访问路径 /wifidog/auth 的回调,如下:

httpdAddCContent(webserver, "/wifidog", "about", 0, NULL, http_callback_about);
httpdAddCContent(webserver, "/wifidog", "status", 0, NULL, http_callback_status);
    // 注册了针对 /wifidog/auth 的访问回调 http_callback_auth
httpdAddCContent(webserver, "/wifidog", "auth", 0, NULL, http_callback_auth);

这样对于 接入设备(or 客户端) 重定向过来的 /wifidog/auth 就进入了 http_callback_auth 函数中,如下:

http_callback_auth(httpd *webserver, request *r)
{
    t_client    *client;
    httpVar * token;
    char    *mac;
    // 1, 获取条件参数中的 logout 值
    httpVar *logout = httpdGetVariableByName(r, "logout");

    // 2, 获取条件参数中的 token 值
    if ((token = httpdGetVariableByName(r, "token"))) {
        /* They supplied variable "token" */
        // 3, 可以看到, 这里要求必须能够通过 ARP 协议获取到 接入设备 的 MAC 地址
        if (!(mac = arp_get(r->clientAddr))) {
            /* We could not get their MAC address */
            debug(LOG_ERR, "Failed to retrieve MAC address for ip %s", r->clientAddr);
            send_http_page(r, "WiFiDog Error", "Failed to retrieve your MAC address");
        } else {
            /* We have their MAC address */
            LOCK_CLIENT_LIST();
            // 4, 检查该客户端(接入设备)是否已经在 wifidog 维护的接入客户端列表中
            if ((client = client_list_find(r->clientAddr, mac)) == NULL) {
                debug(LOG_DEBUG, "New client for %s", r->clientAddr);
                client_list_append(r->clientAddr, mac, token->value);
            } else if (logout) {
                // 5, 退出处理
                t_authresponse  authresponse;
                s_config *config = config_get_config();
                unsigned long long incoming = client->counters.incoming;
                unsigned long long outgoing = client->counters.outgoing;
                char *ip = safe_strdup(client->ip);
                char *urlFragment = NULL;
                t_auth_serv *auth_server = get_auth_server();

                fw_deny(client->ip, client->mac, client->fw_connection_state);
                client_list_delete(client);
                debug(LOG_DEBUG, "Got logout from %s", client->ip);

                /* Advertise the logout if we have an auth server */
                if (config->auth_servers != NULL) {
                    UNLOCK_CLIENT_LIST();
                    auth_server_request(&authresponse, REQUEST_TYPE_LOGOUT, ip, mac, token->value,
                                        incoming, outgoing);
                    LOCK_CLIENT_LIST();

                    /* Re-direct them to auth server */
                    debug(LOG_INFO, "Got manual logout from client ip %s, mac %s, token %s"
                    "- redirecting them to logout message", client->ip, client->mac, client->token);
                    safe_asprintf(&urlFragment, "%smessage=%s",
                        auth_server->authserv_msg_script_path_fragment,
                        GATEWAY_MESSAGE_ACCOUNT_LOGGED_OUT
                    );
                    http_send_redirect_to_auth(r, urlFragment, "Redirect to logout message");
                    free(urlFragment);
                }
                free(ip);
            }
            else {
                // 6, 已经登录校验通过
                debug(LOG_DEBUG, "Client for %s is already in the client list", client->ip);
            }
            UNLOCK_CLIENT_LIST();
            if (!logout) {
                // 7, 到 auth server 上进一步校验 token
                authenticate_client(r);
            }
            free(mac);
        }
    } else {
        /* They did not supply variable "token" */
        // 8, 未携带 token, 直接拒绝
        send_http_page(r, "WiFiDog error", "Invalid token");
    }
}

在该函数中主要处理了 客户端退出,非法校验,以及 客户端校验等流程,下面分别描述注释中的各个步骤:
1,对于客户端退出,则会携带 logout 参数信息,并走到第 5 步(当然,如果连 token 参数都没有的话,会直接走到第 8 步,也就是拒绝);
2,按照正常的认证流程,会携带由认证服务器分配的 token 参数;
3,正如注释说明的,这里要求必须能够通过 ARP 协议获取到 接入设备 的 MAC 地址;(其实通过查看 arg_get 的实现,可以看到是直接解析 /proc/net/arp 文件 -- ARP cache -- 来获取对应客户端 IP 地址的 MAC 信息的),类似如下:

[steven@sasd ~]$ more /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.1.203    0x1         0x2         18:03:73:d5:1b:a2     *        eth0
192.168.1.1      0x1         0x2         00:21:27:63:c0:ce     *        eth0
[steven@sasd ~]$

4,在能够获取到该客户端的 MAC 地址后,根据客户端的 IP 和 MAC 地址检查该客户端是否已经在 wifidog 维护的接入设备(or客户端)列表中,如果不在,则追加到此列表中(关于此列表的数据结构在后面再详细描述);
5,如果该客户端已经存在,且本次访问是要求 logout 退出的,则进入此退出处理的流程,该流程主要包括几个步骤:关闭该客户端 ip/mac 的出口(outgoing)规则 --> 从客户端列表中删除该客户端记录 --> 通知 认证服务器 该客户端退出(且携带该客户端的token, 上下行流量等信息) --> 返回重定向至 认证服务器 的 #define DEFAULT_AUTHSERVMSGPATHFRAGMENT "gw_message.php?" 访问路径(携带一个已退出的 message);
6,如果该客户端已经登录校验过,且本次访问非 logout 退出,则直接跳转到第 7 步;
7,这一步就是 token 校验的过程,具体实现在 authenticate_client 函数中:

authenticate_client(request *r)
{
    t_client    *client;
    t_authresponse  auth_response;
    char    *mac,
        *token;
    char *urlFragment = NULL;
    s_config    *config = NULL;
    t_auth_serv *auth_server = NULL;
    LOCK_CLIENT_LIST();
    // 根据 IP 地址获取 客户端的 MAC 地址以及本次会话分配的 token
    // 主要用于 token 校验过程
    client = client_list_find_by_ip(r->clientAddr);
    if (client == NULL) {
        debug(LOG_ERR, "authenticate_client(): Could not find client for %s", r->clientAddr);
        UNLOCK_CLIENT_LIST();
        return;
    }

    mac = safe_strdup(client->mac);
    token = safe_strdup(client->token);

    UNLOCK_CLIENT_LIST();

    /*
     * At this point we've released the lock while we do an HTTP request since it could
     * take multiple seconds to do and the gateway would effectively be frozen if we
     * kept the lock.
     */
    // 通过 "login" 到 认证服务器 上进行客户端的 token 校验
    auth_server_request(&auth_response, REQUEST_TYPE_LOGIN, r->clientAddr, mac, token, 0, 0);

    LOCK_CLIENT_LIST();

    /* can't trust the client to still exist after n seconds have passed */
    // 这里主要防止在到 认证服务器 上进行 token 校验的过程中
    // 该客户端已经退出的情形, 此时就不需要再进行处理
    client = client_list_find(r->clientAddr, mac);
    if (client == NULL) {
        debug(LOG_ERR, "authenticate_client(): Could not find client node for %s (%s)", r->clientAddr, mac);
        UNLOCK_CLIENT_LIST();
        free(token);
        free(mac);
        return;
    }

    free(token);
    free(mac);
    /* Prepare some variables we'll need below */
    config = config_get_config();
    auth_server = get_auth_server();
    // 根据返回的校验结果做不同的处理
    switch(auth_response.authcode) {
    case AUTH_ERROR:
    case AUTH_DENIED:
    case AUTH_VALIDATION:
    case AUTH_VALIDATION_FAILED:
        ... ...
        break;
    case AUTH_ALLOWED:
        /* Logged in successfully as a regular account */
        debug(LOG_INFO, "Got ALLOWED from central server authenticating token %s from %s at %s - "
                "adding to firewall and redirecting them to portal", client->token, client->ip, client->mac);
        client->fw_connection_state = FW_MARK_KNOWN;
        fw_allow(client->ip, client->mac, FW_MARK_KNOWN);
        served_this_session++;
        safe_asprintf(&urlFragment, "%sgw_id=%s",
            auth_server->authserv_portal_script_path_fragment,
            config->gw_id
        );
        http_send_redirect_to_auth(r, urlFragment, "Redirect to portal");
        free(urlFragment);
        break;
    }
    UNLOCK_CLIENT_LIST();
    return;
}

这里主要是两大步骤:
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 路径访问的响应;
这里就简要分析一下 fw_allow 函数的实现,查看fw_allow的实现可以看到真正设置allow客户端通过防火墙的动作是在iptables_fw_access中实现的,如下:

/** Set if a specific client has access through the firewall */
// 针对上面的流程,这里的输入参数
// type 为 FW_ACCESS_ALLOW,tag 为 FW_MARK_KNOWN
int iptables_fw_access(fw_access_t type, const char *ip, const char *mac, int tag)
{
    int rc;
    fw_quiet = 0;
    switch(type) {
        case FW_ACCESS_ALLOW:
            iptables_do_command("-t mangle -A " TABLE_WIFIDOG_OUTGOING " -s %s -m mac --mac-source %s -j MARK --set-mark %d", ip, mac, tag);
            rc = iptables_do_command("-t mangle -A " TABLE_WIFIDOG_INCOMING " -d %s -j ACCEPT", ip);
            break;
        case FW_ACCESS_DENY:
            iptables_do_command("-t mangle -D " TABLE_WIFIDOG_OUTGOING " -s %s -m mac --mac-source %s -j MARK --set-mark %d", ip, mac, tag);
            rc = iptables_do_command("-t mangle -D " TABLE_WIFIDOG_INCOMING " -d %s -j ACCEPT", ip);
            break;
        default:
            rc = -1;
            break;
    }
    return rc;
}

同样的,我们这里主要分析一下ALLOW时的iptables的防火墙设置规则,对执行的两个iptables命令展开来就是下面两个步骤:

1) 在mangle表中追加WiFiDog_$ID$_Outgoing外出过滤链,该链的规则如下几条:
a) IP 地址为该客户端的IP地址;
b) MAC地址为该客户端的MAC地址;
c) 设置MARK为FW_MARK_KNOWN;

iptables –t mangle –AWiFiDog_$ID$_Outgoing  -s 客户端IP地址 -m mac --mac-source 客户端MAC地址 -j MARK --set-mark FW_MARK_KNOWN

2)在mangle表中追加一条[接受所有目的地址为此客户端IP地址的] WifiDog_$ID$_Incoming输入过滤链;

iptables -t mangle -AWiFiDog_$ID$_Incoming -d 客户端IP地址 -j ACCEPT

最后,看一下 wifidog 返回的重定向请求到 认证服务器 的请求报文 以及 认证服务器 返回给 客户端的(重定向到原始访问 baidu.com 的)响应报文:
1.jpg

转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://quietmadman.blog.51cto.com/3269500/1386291

本文章由 http://www.wifidog.pro/2015/01/23/wifidog%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90-4.html 整理编辑,转载请注明出处

wifidog 源码初分析(3)

上一篇分析了 接入设备 在接入路由器,并发起首次 HTTP/80 请求到路由器上时,wifidog 是如何将此 HTTP 请求重定向至 auth-server 的流程。
之后 接入设备 的浏览器接收到 wifidog 返回的 302 重定向请求后,会将页面重定向至 auth-server 的 /login 页面,并且在此 URL 中会携带一些 路由器/网关 参数,以及 接入设备的 MAC 地址 和 客户端访问的源URL(如示例中的 baidu.com)。
下面几个步骤就是 接入设备 到 auth-server 上的认证过程,因本系列主要分析 wifidog 源码,这里只截取了 接入设备 与 auth-server 之间的通信报文:
1.jpg

本示例对应的 auth-server 是使用 authpuppy 搭建的认证服务器,且使用了 localUser 插件,该插件是需要用户输入用户名/密码的方式来认证的,下图即为输入正确的用户名/密码后,auth-server 返回重定向到 wifidog 的响应(注:同时携带了为此接入设备的用户分配了 token):
2.jpg

同样的,接入设备的浏览器会继续重定向到 路由器的 wifidog 的 /wifidog/auth 服务上。

转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://quietmadman.blog.51cto.com/3269500/1385590

本文章由 http://www.wifidog.pro/2015/01/23/wifidog%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90-3.html 整理编辑,转载请注明出处