分类 wifidog流程 下的文章

wifidog认证服务器用户角色和权限架构(2)

API
对于大多数开发者来说只有两个问题:权限(定义权限)和安全(进行使用)
这些函数在processAdminUI进行权限检测时经常被使用,因为他们将避免异常的允许用户进行登录或重新尝试操作:

Security::requirePermission(Permission $permission, $target_object, $user=null);  
Security::requireAnyPermissions(Array $permissionsArray, $target_object, $user=null);
Security::requireAllPermissions(Array $permissionsArray, $user=null);

Mirror function的存在可以简单检测用户是否有此权限。一般应用在displayAdminUI(如果指定选项不可得,但用户仍然可以编辑对象的其它部分)。

Security::hasPermission(Permission $permission, $target_object, $user=null);
Security::hasAnyPermissions(Array $permissionsArray, $target_object, $user=null);
Security::hasAllPermissions(Array $permissionsArray, $user=null);

内部执行和临界情况(网关的相互作用)

Security::getObjectsWithPermission(Permission $permission, $user=null);  //TO find an object on which the user has the permissions.  Especially usefull to build lists in menus and select boxes.
Security::hasRole($role, $targetObject, $user);  //user is optional, if unspecified, the current user is used.  User can also be null, meaning that there is no user currently logged-in

主要用于进行报告(还没有执行)

Security::getUsersWithPermission($permission, $targetObject); //Return list of users with this permission
Security::getUsersWithRole($role, $objectId); //Return an array of users with the given role.  If objects_id is null, all users with the specific role are returned, along with an array of objects for which they have this role.  Maybe this function won't actually be implemented, as it's there mostly for reporting and sending notification of hotspots going down.
Security::getPermissions($user);  //returns array of PERMISSION constants for this user.

数据模型
stakeholder_type table:

  • stakeholder_type_id

permission table:

  • permission_id REFERENCES permission_type stakeholder_type_id
  • REFERENCES stakeholder_types

roles table:

  • role_id text NOT NULL,
  • role_description_content_id text,
  • is_system_role bool NOT NULL DEFAULT false,
  • stakeholder_type_id text NOT NULL REFERENCES stakeholder_types,
  • role_creation_date

role_has_permissions:

  • role_id REFERENCES roles
  • permission_id REFERENCES permissions

每个利害关系人类型都会从利害关系人表格那得到一个表格:
利害关系人

  • user_id text NOT NULL
  • role_id text NOT NULL
  • object_id text NOT NULL

这些表格要依据利害关系人类型来命名。例如:对于节点来说,表格名为node_stakeholders:
解决的问题
允许进行的操作实例

  • 允许所有者拥有更多的粒度权限来编辑内容(一些人可以编辑登录,一些人不能,等等)
  • 限制用户访问单独节点(user_can_access_all_nodes,网格权限)
  • Fon_like:用户只能在他的节点在线时才能登录
  • 使用互联网的时间限制

本文章由 http://www.wifidog.pro/2015/03/16/wifidog%E8%AE%A4%E8%AF%81%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%94%A8%E6%88%B7%E8%A7%92%E8%89%B2%E5%92%8C%E6%9D%83%E9%99%90%E6%9E%B6%E6%9E%84-2.html整理编辑,转载请注明出处

wifidog认证服务器用户角色和权限架构(1)

新用户权限架构,一般模式
利害关系人(角色和权限类型)

每个角色和权限都关系到下面其中一个对象类型或静态对象:

  • 节点
  • 网络
  • 服务器
  • 内容

这些限定了利害关系人的类型
注:访问指定内容类型的权限也将会是网络权限。这样我们能够指定一个“Beginer editor”和“Advanced editor”角色。

权限
权限是在代码中被指定的,所有在大的PHP查找表中的都允许进行简单的翻译。举个权限的例子:NODE_PERM_EDIT_METADATA。做为Node权限类型,用户得获得此权限就是被允许编辑适用于这个权限的指定节点实例的元数据。权限被定义在Permission::getPermissionArray()。
$PERMISSIONSPERMISSION_ID=array(_(“permission description”),//权限的描述
Stakeholder::Node,//权限类型
True//是否那个类型目前的所有角色应该获得权限。这只有当同步权限时才使用。如果逻辑上所有角色应该获得默认权限的话,就应该为NOT。它必须要保持服务器的优先功能直到管理员能够检测出不同角色。一般情况下为限制目前功能而添加新权限类型时,它应该被设置成TRUE。当添加全新功能时,它可以设置成与默认操作逻辑相符的任何选项。

添加或移除权限

  • 当添加或移除权限时,你无需升级数据库架构。数据库是被每次运行的脚本(Permission::synPermissions())保持同步的,当权限实例化时就除外。这样的话就不会有操作成本,维护负担也减轻了。只要明确你的权限并使用,数据库关系就会自动升级。
  • 权限粒度:角色系统的一个特点是拥有许多粒度权限,然后用角色系统管理潜在权限类型。当其它粒度权限添加不成功时,请删除旧的,大的权限。
  • 权限检测位置:一般情况下是用对象的接口方法:getAdminUI(),processAdminUI()和delete()。不要将它们放在调节器和接收器,因为代码的其它部分可能会用到它们。

角色
角色是管理员定义的作为角色的相同类型权限组。例如,如果我们定义“Tech support”Node角色,我们就可以为这个角色分配各种各样的节点权限(但只是节点权限)。
如果我们为一个用户分配指定节点的 “Tech support”角色,那么这个用户就成为此节点的“Tech support”利害关系人。
Node:(例如:节点技术支持,节点拥有者等等)
Network:(例如:用户被允许多次登录,内容管理员(可以编辑其它用户内容),内容编辑器等等)
用户类型(系统角色)(未执行)
当管理员可以定义新角色时,就会需要定义常用角色系统。

  • Anyone(匿名)
  • 也许特殊情况只是一个ID,像SPLASH_ONLY_USER
  • 服务器,网络,节点等等
  • 已登录用户
  • 已认证用户
  • 正在认证用户

用户认证等级(授权,认证等等)将会映射到系统角色,并且可能最终被弃用。

组群
为了简单起见,传统意义上没有组群这个概念。角色允许进行相同的操作,并且更易于执行。

隐式权限
为了简单起见,将不支持定义隐式权限。虽然这是值得保留的特性,但为此执行一个简单的UI却并不容易,并且自从为指定对象提供权限时,对权限进行检测的代码将会很复杂,性能也会很低。
这意味着当在代码中使用权限时,两者都需要被指定为已授权。API会使这一点比较容易实现。
注意的是,恰当的定义角色来做同样的事。(例如一个节点拥有者可以获得许多隐式节点权限)。

Sudo支持
用管理员伪装成其它用户的办法来测试或进行技术支持是很有用的。退出系统此时会将他变回原始用户。因为都是集中处理用户,所以这点很容易执行。

处理不足的权限
在通常状况下,缺失权限应该通过免责条款来处理(使用Security::require*()methods)。这会解决两个比较麻烦的问题,摆脱目前所有权限错误的处理代码:

  • 如果用户没有登录(因为超时或没进行登录操作),它允许用户再次登录。
  • 如果用户没有必需的权限,会对他进行提醒并允许做为其它用户进行登录。

这两种情况下,如果用户成功登录(用正确的权限),会再次产生get和post参数并会再次尝试最初操作。
异常执行
目前有由MainUI外部的MainUI.php所定义的全球化异常处理程序。当遇到异常情况时,它会用恰当格式的错误提示信息和请求回复代码调用一个新的MainUI。现在不必在半释放页面进退两难,也不需要在try-catch模块将顶级脚本打包。

本文章由http://www.wifidog.pro/2015/03/16/wifidog%E8%AE%A4%E8%AF%81%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%94%A8%E6%88%B7%E8%A7%92%E8%89%B2%E5%92%8C%E6%9D%83%E9%99%90%E6%9E%B6%E6%9E%84-1.html 整理编辑,转载请注明出处

wifidog配置网关注意事项

用户超时
跟其它解决方法不同,Wifidog无需一直打开认证页面用脚本来保持连接。网关只会在数秒中没有获得任何来自客户端的流量时,才判断为超时断开连接。确保客户端没有因为闲置而超时,网关将会在每个时间间隔来重新ping每个客户端来检测流量。遗憾的是,有些所谓防火墙设置很讨厌,防ping,造成检测时完全丢包被误判为离线。这也是经常超时的原因。

Wifidog网关网站界面
网关只有最小化的网站界面,为用户提供了很少的信息。这样就不会与门户相混淆,门户必须由认证服务器进行管理。以下信息可以直接从网关得到:

http://gateway_ip:gateway_port/wifidog/

  • 网关版本
  • 节点ID

http://gateway_ip:gateway_port/wifidog/status

  • 网关版本
  • 网关正常运行时间
  • 网关是否具有网络连通性
  • 是否与认证服务器相连接
  • 获得此服务的用户编码
  • 已连接的用户编码
  • 用户列表
      IP
      MAC
      Token
      下载字节
      上传字节
  • 目前使用的认证服务器

http://gateway_ip:gateway_port/wifidog/about

OLSR和Wifidog网关
问题:如果你选择只安装一个Wifidog网关服务器,那么所有用户的MAC地址都将被最近的OLSR路由器所“掩饰”。
解决办法:
在OLSR节点安装Wifidog。允许HTTP在OLSR节点间流动,可以通过用Cron在所有节点启用以下脚本来实现。

ipkg install ip
#!/bin/sh
#
# Script to bypass HTTP interception for traffic forwarded by OLSR
# bms 9-Aug-2005
# Licensed under GPL
#

rm -f /tmp/get_neighbors.awk
cat > /tmp/get_neighbors.awk <<__HERE1__
BEGIN {
 while("route -n"|getline) {
    if (/^[0-9]/) {
        if (0 < \$5) {
           if (\$3 == "255.255.255.255 <http://255.255.255.255>") {
             printf "%s\n", \$1;
                 }
               }
             }
           }
        }
__HERE1__

iptables -t nat -D WiFiDog_Unknown -j OlsrNeighbors 2>&1 >/dev/null
iptables -t nat -F OlsrNeighbors 2>&1 >/dev/null
iptables -t nat -X OlsrNeighbors 2>&1 >/dev/null
iptables -t nat -N OlsrNeighbors

neighbors=$(awk -f /tmp/get_neighbors.awk)

for _neighbor in ${neighbors} ; do

   _mac=$(grep "^${_neighbor}" /proc/net/arp | awk '{print $4}')
   echo ${_mac}
   iptables -t nat -A OlsrNeighbors -m mac --mac-source ${_mac} \
          -p tcp --dport 80 -j ACCEPT

done

iptables -t nat -I WiFiDog_Unknown -j OlsrNeighbors

本文章由 http://www.wifidog.pro/2015/03/13/wifidog%E9%85%8D%E7%BD%AE%E7%BD%91%E5%85%B3%E6%B3%A8%E6%84%8F%E4%BA%8B%E9%A1%B9.html整理编辑,转载请注明出处

wifidog 实现无线热点认证

<Wifi有一种web方式认证方案,当连接到某些不加密的热点之后,会跳转到一个网页来认证登陆,大家熟悉的CMCC就采用了这种web的验证方式。>
它的原理是在得到正确的认证之前,会把所有的流量重定向到认证服务器上,通过认证后,便可以正常使用。
如果说仅仅想获取web验证时其他用户的用户名和密码,arp欺骗然后嗅探足够了。因为此时攻击者已经分配到了ip,且同一网关下产生的流量是不会重定向的。
但是目前的情况是,认证服务器用的https加密传输,无法嗅探到明文密码。
于是萌生了伪造热点及web认证服务器,然后记录密码的想法。

客户端在接受WiFi信号的时候有一个特点,在ssid相同的时候,会只保留信号强的那一个无线路由的ssid。
这样,只要伪造热点的ssid与原热点的相同,会有部分人搜到伪造的热点,从而登陆,记录密码。

本无线路由用的ddwrt的系统,装了wifidog来进行辅助web认证。

至于如何搭建web认证系统,百度一大把,但主要是用了wiwiz和wifiap这两个成熟的网站提供的方案。
但是,利用第三方的网站无法拦截到用户名和密码,而且无法控制认证的过程。
最好的解决方法是自己搭建一个简单的系统。

Wifidog的认证流程如下:
1、客户端发出一个http请求(http://www.xxx.com)
2、网关将该请求信息以及网关本身的一些信息作为参数,将原始的请求重定向到web认证服务器(http://auth_server/login/)
3、Web认证服务器通过客户端的认证之后,返回一个一次性的token,客户端带着这个token去网关上的wifidog开放的端口去做验证(http://GatewayIP:GatewayPort/wifidog/auth?token=[auth token])
4、Wifidog拿到token后,到web认证服务器检测token是否有效,如果有效则通过客户端的验证,开放访问权限,并将客户端重定向到web认证服务器的欢迎界面(http://auth_server/portal/);如果token无效,则需要继续验证

Wifidog官方推荐的web认证服务软件为authpuppy (http://www.authpuppy.org),不过其代码比较复杂,可以参考wifidog之前的web认证服务软件。获取方式为:

svn checkout https://dev.wifidog.org/svn/trunk/wifidog-auth

web认证服务软件用php写成,重点文件为wifidog-auth\wifidog\login\index.php(客户端web认证、产生token以及重定向到wifidog的开放端口)、wifidog-auth\wifidog\auth\index.php(wifidog验证token)、wifidog-auth\wifidog\portal\index.php(认证成功后页面重定向)。宏定义在wifidog-auth\wifidog\include\common.php文件中。

了解了基本流程就可以DIY出一个简单的web认证服务器了。在认证的过程中可以顺便记录下客户端的密码。
路由器上Wifidog配置如下图。重点配置的地方为端口号(port),认证服务器(AuthServer Hostname), 认证服务器web端口(AuthServer HTTP Port),路径(AuthServer Path)。

web认证服务器端代码大家自己发挥吧。我个人只是实现了记录用户名密码这样一个简单的功能,如果要做的好的话可以用用户提交的密码到真正的认证服务器做一次认证来返回合适的结果,以及自己搭建dns服务器伪装的更加逼真,但是对于那些比较敏感的用户,还是不容易进行欺骗的,比如用回会发现ssl加密不见了。

考虑到功耗和实用问题,我的web认证服务器是搭建在树莓派上的。配置好无线路由的WLAN确保能联网之后,设置路由器的ip为10.1.1.1,手工配置树莓派静态ip为10.1.1.2。树莓派上安装nginx和php,配置好webserver的环境,上传自己的代码。开启无线路由的wifidog就可以守株待兔了。

当用户连接到自己搭建的无线路由器之后,可以说所有的网络流量都在控制之中了。不过怎么拿到这些流量成了一个问题。在此有三种拿到流量的方法。

1、ARP欺骗
这个不多说,大家都懂。不过有种偏离正题的感觉。
2、网线嗅探
当所处的环境通过网线来连到互联网时可用这个方法。将网线接入自制的硬件并将另一端插到无线路由的WLAN口,做好相应的配置。所需硬件参见我之前的一个帖子。原理类似于Throwing star lan tap,直接监听网线上的数据(无线路由的WLAN口)。
3、通过笔记本做中介
当所处的环境只有无线网连到Internet时,可用笔记本来搭建一个中介。
其连接关系为:
AP—无线网卡—有线网卡—自己的无线路由—受害者
这时用笔记本就可以直接嗅探到所有的数据。

这里以windows环境为例,演示如何搭建这个数据流链条。
在无线网卡连接到无线网之后,在属性中选择Internet连接共享,共享给以太网卡(有线网卡)。

此时有线网卡的ip会被设置为192.168.137.1

用网线连接有线网卡的网口和无线路由的WLAN。在无线路由的配置页面,将WLAN口配置静态ip为192.168.137.2,子网掩码255.255.255.0,网关为192.168.137.1。
这时整个数据流链条便搭建成功。

至于在linux下的搭建,注意打开ip_forward功能,并配置好iptables。因为没有linux环境,不在此详细演示。

对于流经网卡的数据包,可以收集的信息主要有两种:密码和session。
windows下的cain用来嗅探并提取得到的用户名密码,改下规则也能得到特定的cookie。
linux下的ettercap设置好规则能获取到几乎所有想要的信息,还能用来更改返回的web页面、挂马、添加cookie等等,可谓神器。

至于开启了ssl加密的服务器,可以用ssltrip来得到明文传送的数据。
如果不怕麻烦的话,还可以自己搭设dns服务器来钓鱼,不过这样就有些杀鸡用牛刀了。

PS:最近出了个叫极路由的东西,号称自动翻墙。目测是内置了一个vpn。大家有兴趣可以去了解下~
PPS:利用web认证方式的热点是挂马利器哦

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