wifidog 源码初分析(三)
2016-04-05 15:31
295 查看
上一篇分析了 接入设备 在接入路由器,并发起首次 HTTP/80 请求到路由器上时,wifidog 是如何将此 HTTP 请求重定向至 auth-server 的流程。
之后接入设备的浏览器接收到 wifidog 返回的 302 重定向请求后,会将页面重定向至 auth-server 的 /login 页面,并且在此 URL 中会携带一些路由器/网关 参数,以及接入设备的 MAC 地址和客户端访问的源URL(如示例中的 baidu.com)。
POST /login/?gw_address=192.168.1.1&gw_port=2060&gw_id=default&mac=44:94:fc:ef:28:40&url=http%3A//www.baidu.com/ HTTP/1.1
auth-server 收到请求后处理,并返回重定向到 wifidog 的响应(注:同时携带了为此接入设备的用户分配了 token),接入设备的浏览器重定向至路由器上 wifidog 的 http 服务(端口 2060) /wifidog/auth 上(且携带了认证服务器为此接入设备分配的 token),下面介绍下 wifidog 接收到 /wifidog/auth 的访问后的校验流程。
在 wifidog 启动 http 服务前,注册了一个针对访问路径 /wifidog/auth 的回调,如下:
这样对于 接入设备(or 客户端) 重定向过来的 /wifidog/auth 就进入了 http_callback_auth 函数中,如下:
在该函数中主要处理了 客户端退出,非法校验,以及 客户端校验等流程,下面分别描述注释中的各个步骤:
1,对于客户端退出,则会携带 logout 参数信息,并走到第 5 步(当然,如果连 token 参数都没有的话,会直接走到第 8 步,也就是拒绝);
2,按照正常的认证流程,会携带由认证服务器分配的 token 参数;
3,正如注释说明的,这里要求必须能够通过 ARP 协议获取到 接入设备 的 MAC 地址;(其实通过查看 arg_get 的实现,可以看到是直接解析 /proc/net/arp 文件 -- ARP cache -- 来获取对应客户端 IP 地址的
MAC 信息的),类似如下:
[asd@ubuntu ~]#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
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 函数中:
这里主要是两大步骤:
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中实现的,如下:
同样的,我们这里主要分析一下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-markFW_MARK_KNOWN
2)在mangle表中追加一条[接受所有目的地址为此客户端IP地址的] WifiDog_$ID$_Incoming输入过滤链;
iptables -t mangle -AWiFiDog_$ID$_Incoming -d 客户端IP地址 -j ACCEPT
最后,Auth server重定向客户端浏览器到www.baidu.com
之后接入设备的浏览器接收到 wifidog 返回的 302 重定向请求后,会将页面重定向至 auth-server 的 /login 页面,并且在此 URL 中会携带一些路由器/网关 参数,以及接入设备的 MAC 地址和客户端访问的源URL(如示例中的 baidu.com)。
POST /login/?gw_address=192.168.1.1&gw_port=2060&gw_id=default&mac=44:94:fc:ef:28:40&url=http%3A//www.baidu.com/ HTTP/1.1
auth-server 收到请求后处理,并返回重定向到 wifidog 的响应(注:同时携带了为此接入设备的用户分配了 token),接入设备的浏览器重定向至路由器上 wifidog 的 http 服务(端口 2060) /wifidog/auth 上(且携带了认证服务器为此接入设备分配的 token),下面介绍下 wifidog 接收到 /wifidog/auth 的访问后的校验流程。
在 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 信息的),类似如下:
[asd@ubuntu ~]#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
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 函数中:
/** Authenticates a single client against the central server and returns when done * Alters the firewall rules depending on what the auth server says @param r httpd request struct */ void 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(); client = client_list_find_by_ip(r->clientAddr); if (client == NULL) { debug(LOG_ERR, "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. */ 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 */ client = client_list_find(r->clientAddr, mac); if (client == NULL) { debug(LOG_ERR, "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: /* Error talking to central server */ debug(LOG_ERR, "Got %d from central server authenticating token %s from %s at %s", auth_response, client->token, client->ip, client->mac); send_http_page(r, "Error!", "Error: We did not get a valid answer from the central server"); break; case AUTH_DENIED: /* Central server said invalid token */ debug(LOG_INFO, "Got DENIED from central server authenticating token %s from %s at %s - redirecting them to denied message", client->token, client->ip, client->mac); safe_asprintf(&urlFragment, "%smessage=%s", auth_server->authserv_msg_script_path_fragment, GATEWAY_MESSAGE_DENIED ); http_send_redirect_to_auth(r, urlFragment, "Redirect to denied message"); free(urlFragment); break; case AUTH_VALIDATION: /* They just got validated for X minutes to check their email */ debug(LOG_INFO, "Got VALIDATION from central server authenticating token %s from %s at %s" "- adding to firewall and redirecting them to activate message", client->token, client->ip, client->mac); client->fw_connection_state = FW_MARK_PROBATION; fw_allow(client->ip, client->mac, FW_MARK_PROBATION); safe_asprintf(&urlFragment, "%smessage=%s", auth_server->authserv_msg_script_path_fragment, GATEWAY_MESSAGE_ACTIVATE_ACCOUNT ); http_send_redirect_to_auth(r, urlFragment, "Redirect to activate message"); free(urlFragment); 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; case AUTH_VALIDATION_FAILED: /* Client had X minutes to validate account by email and didn't = too late */ debug(LOG_INFO, "Got VALIDATION_FAILED from central server authenticating token %s from %s at %s " "- redirecting them to failed_validation message", client->token, client->ip, client->mac); safe_asprintf(&urlFragment, "%smessage=%s", auth_server->authserv_msg_script_path_fragment, GATEWAY_MESSAGE_ACCOUNT_VALIDATION_FAILED ); http_send_redirect_to_auth(r, urlFragment, "Redirect to failed validation message"); free(urlFragment); break; default: debug(LOG_WARNING, "I don't know what the validation code %d means for token %s from %s at %s - sending error message", auth_response.authcode, client->token, client->ip, client->mac); send_http_page(r, "Internal Error", "We can not validate your request at this time"); 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 */ 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-markFW_MARK_KNOWN
2)在mangle表中追加一条[接受所有目的地址为此客户端IP地址的] WifiDog_$ID$_Incoming输入过滤链;
iptables -t mangle -AWiFiDog_$ID$_Incoming -d 客户端IP地址 -j ACCEPT
最后,Auth server重定向客户端浏览器到www.baidu.com
相关文章推荐
- 访问对方oracle数据库
- Android 反编译二进制AndroidManifest.xml文件的方法
- c++小记
- html内容垂直居中
- JavaScript中双叹号(!!)作用
- CodeForces 652E Pursuit For Artifacts 边双连通分量
- django之创建第8-2个项目-数据库数据提取之过滤操作符相关
- 使用json-lib包,实现xml转json时空值被转为中括号的解决办法
- java.lang.SecurityException: sealing violation: package javax.servlet is sealed
- setNeedsDisplay和setNeedsDisplay和layoutIfNeeded关系
- Win7系统开机提示"可能需要其他登入信息"的解决方法
- ArchLinux mount U盘
- Android 简单的图片渐变(变亮)和handler的使用
- Java虚拟机的JVM垃圾回收机制
- git设置忽略文件
- 关于链表、树等数据结构中常见的二级指针
- javascript保存excel
- 大数据 --> Spark和Hadoop作业之间的区别
- iOS-Bug收集:CocoaPods 错误 target overrides the `OTHER_LDFLAGS`...
- nginx-nginx环境下润乾报表“+”号重复请求