此文总结了当WifiDog跑在OpenWRT上的常见隐患和解决方案：

1)关闭UPNP功能，UPNP简单来说就是一个自动端口映射，此功能会导致QQ等程序在未认证时绕过WifiDog上传和下载数据。

有点累了，改天再完善...

本文章由:http://www.wifidog.pro/2016/12/30/WifiDog%E5%9C%A8OpenWRT%E4%BD%BF%E7%94%A8%E8%BF%87%E7%A8%8B%E4%B8%AD%E7%9A%84%E4%B8%80%E4%BA%9B%E6%B3%A8%E6%84%8F%E7%82%B9.html

RADIUS协议特点
RADIUS协议具有灵活、安全、可扩展性好的特点，具体包括：通过网络传输的认证信息都经过加密，安全性高； 认证方式灵活，支持Unix Passwd、CHAP、挑战－回答认证等多种认证方式， 还支持认证转接（Authentication Forwarding）；协议扩展性好，通过变长 的属性串（Attribute Pair）能够进一步扩展RADIUS协议。RADIUS的认证过程如下图：

如上图所示，NAS（Network Access Server，网络访问服务器）被看成RADIUS的客户端，当用户登录到NAS 时，客户端将用户提供的认证信息（如用户名和口令）发送给指定的RADIUS Server，并根据Server的回应作出相应的“允许/不允许登录”的决定。 RADIUS Server 负责接收认证请求并进行认证，然后将认证结果（包括连 接协议、端口信息、 ACL 等授权信息）发送回RADIUS Client，Client根据 授权信息限制用户对资源的访问。 一个RADIUS Server可以作为另一个RADIUS Server的客户端要求认证（即认证转接），以提供灵活的认证方式。 RADIUS Server和Client之间传递的认证信息用一个事先设置的口令进行加密，防止敏感信息泄露。当用户成功的登录后，NAS会向RADIUS Server发送一个连接开始的记账信 息包，其中包括用户使用的连接种类、协议和其他自定义信息；当用户断开连接后，NAS会向RADIUS Server发送一个连接结束的记账信息包，RADIUS Server根据设置为用户记账。

RADIUS登录过程
　下面是一个典型的RADIUS登录过程：
　　远程用户登录NAS；
　　NAS发送“RADIUS Access－Request”到RADIUS Server，其中包括用户名、密码等信息；如果该用户使用“挑战－回答”认证，RADIUS Server 将发送包含挑战信息的“RADIUS Access－Challenge”消息，NAS将挑战信息显示给用户；
　　用户将回答提交给NAS，NAS将发送第二个“RADIUS Access－Request”，Server 将根据此信息进行认证，这个过程类似于前面介绍过得CHAP认证方式；
　　RADIUS Server 将根据事先设置的认证方式（CHAP、用户名口令、挑战应答等）认证该用户，并发回“RADIUS Access－Accept”；或拒绝该用户，并发回“RADIUS Access－Reject”消息；
　　NAS通知Server开始Accounting，用户访问进程开始，当用户结束进程时，NAS通知Server结束Accounting进程。
　　基于RADIUS协议的认证方式由于其安全、灵活、可扩展性等特点被广泛应用，其认证机制的实现包括了用户名＋口令、基于对称加密、基于非对称加密等多种方式，可以根据实际的安全需求具体实施。

本文章由 http://www.wifidog.pro/2015/03/26/wifidog%E9%85%8D%E7%BD%AE%E6%B5%81%E7%A8%8B.html 整理编辑，转载请注明出处

RADIUS认证服务器(Remote Authentication Dial In User Service，远程用户拨号认证系统)是目前应用最广泛的AAA协议(AAA=authentication、Authorization、Accounting，即认证、授权、计费)。AAA协议的典型操作是验证用户名和密码是否合法(认证)，分配IP地址(授权)，登记上线/下线时间(计费)，电信业窄带/宽带拨号都使用大型RADIUS认证服务器。而随着网络安全需求提高，中小企业的局域网集中用户认证，特别是使用VPDN专网的也逐渐需要建立自己的认证服务器以管理拨号用户。这些用户不需要使用昂贵的专业系统，采用PC服务器和Linux系统的Freeradius+MySQL可靠地实现。本文着重介绍RADIUS系统在VPDN拨号二次认证中的应用。

Freeradius的安装

　　笔者采用FC4 for x86_64系统上的freeradius-1.1.2，在中档PC服务器上运行，系统运行稳定可靠。Linux FC4自带Freeradius和MySQL，不过实测不理想。FC4 MySQL对中文支持不好，而freeradius则仅支持其自带MySQL。所以，在编译MySQL时要加入选项“--with-charset=gb2312”以支持中文字符编码。编译Freeradius时可使用缺省选项。在64位Linux系统上编译前配置时需要加入选项“—with-snmp=no”，因为与库文件snmp相关的库对64位支持有问题，最新的FC7也许没有这些问题。Freeradius提供了MySQL建库脚本——db-MySQL.sql，不过建nas库有1个语法错误，将“id int(10) DEFAULT ‘0’;”中的“DEFAULT ‘0’”去掉即可正常建立Radius库。

Freeradius的设置

　　简单少数用户可使用Freeradius缺省的users文件配置用户，根据文件制定的规则和用户工作。安装完毕后启动Radius服务：/usr/loca

　　l/sbin/radiusd –X。本机运行radtest test test localhost 0 testing123发认证请求，得到回应表示Radius服务器工作正常。

　　Radius服务器缺省使用/usr/local/etc/raddb/users文件工件认证，简单易行，但仅适用于少数用户。如果管理几十个或更多用户，应使用数据库，对于少于一万用户而言，MySQL是合适选择。

MySQL认证的设置

　　在配置文件radiusd.conf中，在authorize{}和accountingt{}设置中去掉sql前注释符。在sql.conf中设置MySQL的连接信息，用户/密码和地址，本机用localhost即可。www.linuxidc.com还需要在users中对DEFAULT用户做如下设置：Auth-Type = Local，Fall-Through = 1。这样，才可正确使用MySQL进行认证。

　　在MySQL中设置用户的规则与users文件用户设置有对应关系。Radius认证是以Attribute = Value的形式提供认证和应答消息。在users文件中，与用户名位于同一行，以“，”分隔的各个属性是认证请求必须提供而且需要验证的属性。下面各行属性如IP地址等加入应答包中。在MySQL中不分组情况下，只要在radcheck表中加入密码，在radreply中加入应答信息如IP地址即可。

　　实际使用时，往往使用username@domain形式用户进行认证。用文件方式时，可以通过设置剥离域名，只建立username认证即可。需要在radiusd.conf中加入一项realm domain { format=suffix… }域说明，并在proxy.conf中realm DEFAULT使用LOCAL认证。用MySQL认证时，缺省的sql.conf中使用带域名的全名进行认证。使用剥离域名的用户认证，注释掉缺省的sql_user_name = "%{User-Name}"，开放原来注释掉的sql_user_name = "%{Stripped-User-Name:-%{User-Name:-DEFAULT}}"定义语句，则优先使用剥离域名的用户名进行认证。表中用户名一项只需写用户名即可，不需要域名。

　　最后，打开防火墙是必要的。缺省Radius认证服务器使用UDP 1812端口认证，UDP1813端口计费，应该开放UDP包的进出。

Iptables –A OUTPUT –p udp –d 192.168.10.3 --sport 1812 –j ACCEPT

　　Iptables –A INPUT –p udp –s 192.168.10.3 --dport 1812 –j ACCEPT

　　其中192.168.10.3是认证客户端的地址，通常是LNS路由器，同理开放UDP 1813计费端口。

　　CISCO路由器的设置

　　CISCO 路由器是经典的RADIUS客户端，在VPDN拨号系统中LNS作为二次认证客户端。在clie

　　nts.conf中定义客户端IP地址和共享密钥。对单网口的低级路由器来说，客户端的IP地址就是网口IP。对于中高级路由器来说，路由器缺省使用第一个网口IP作为客户端源IP，如果是不可路由的内网地址，则客户端无法收到认证应答包。要指定IP，使用如下语句：

　　ip radius source-interface FastEthernet0/1

　　其中FastEthernet0/1的IP指定作为认证客户端的源地址。一般做法是在VPDN-GROUP定义中使用source-ip 语句指定IP，不过重启路由器后必须重新设置RADIUS服务器才能生效。

　　另一个关于CISCO设置是使用多个认证服务器。中高档路由器通常可支持不同的拨号接入。不同拨号接入使用不同的认证服务器。CISCO中使用不同的server-group实现。

　　aaa authorization network aaa-radius1 start-stop group radius1

　　aaa authorization network aaa-radius2 start-stop group radius2

　　也可根据需要定义authentication/accounting使用的server-group。

　　在每个接入的PPP Virtual-Template模板中，ppp可选择不同的server-group进行AAA认证。

　　interface Virtual-Template1

　　ppp authorization aaa-radius1

　　……

　　interface Virtual-Template2

　　ppp authorization aaa-radius2

　　……

　　这样实现一个路由器作为多个使用不同RADIUS服务器的拨号LNS路由器功能。

　　用户物理绑定的实现

　　实现用户物理绑定，特定用户只能在特定的电话号码或端口号上发起连接才能认证成功，可以大大提高认证安全性。在窄带系统中，LAC在拨入接入服务器LAC进行一次认证时，就向RADIUS服务器提供主叫号码，二次认证时该属性就被提交给RADIUS服务器。如电话号码为1234567，用户拨号，请求中包含属性Calling-Station-Id = "1234567"。为了实现主叫号码绑定，首先在radiusd.conf配置文件中起用对主叫号码的检查，即checkval {}中的内容。在使用users文件认证时，在用户名定义的同一行内加入Calling-Station-Id = "1234567"即可。使用MySQL认证时，在radcheck表中加入“Calling-Station-Id，”+=”，”1234567””这条记录即可。

　　对于ADSL宽带来说，不能使用电话号码绑定。不同宽带设备可提供不同的绑定方式。其实现要点也是必须在发出认证请求中包含其物理端口或其它物理信息，Radius服务器在字典定义该属性，在users文件或MySQL中加入约束值即可。

本文章由 http://www.wifidog.pro/2015/03/26/wifidog%E6%9C%8D%E5%8A%A1%E5%99%A8.html 整理编辑，转载请注明出处

Token，一般模式
目前连接令牌都是弱实体，直接保存在连接表格里。一些利害关系人喜欢向连接添加特性（限时，稳定性令牌等等）来支持不同的无线社区模式。为了不搬起石头砸自己的脚，我们需要一个数据模式来解决连接处理和重新使用的问题，不只是它退化的情况。
以下是进行此操作的第一部分草稿。

数据模式

• Token_templates
• Token_template_id
• Token_template_network(注：Server-wide令牌不予以支持，但代码会查找你同步的网络的令牌)
• Token_template_creation_date
• Token_max_incoming_bytes 如：允许覆盖带宽
• Token_max_outgoing_bytes 如：允许覆盖带宽
• Token_max_total_data 如：允许覆盖带宽
• Token_max_connection_duration： 如：允许限制单独连接的长度
• Token_max_usage_duration: 如：允许以小时计算出售访问（只有在使用时开始计算）
• Token_max_wall_clock_duration: 如：允许出售日执照，周执照或月执照（当令牌第一次使用时开始计算）
• Token_max_age: 如：允许在期满之前设置最长时限（当令牌被发布时开始计算）
• Token_is _reusable:当期满时创建的令牌还可以重新使用吗？（能常情况下是可以的）

Tokens_template_valid_nodes(遗憾的是，酒店向他们的客户出售24小时访问权，我们考虑到他们的网络也许包括不只一个节点。如果令牌不准进入表格，它就会在网络的任何位置被认为是有效的)

• Token_template_id
• Token_valid_at_node

Token_lots:

• Token_lot_id
• Tonken_lot_comment:关于lot的自由形态评论
• Token_lot_creation_date

Lot是被同时发布的令牌组，例如预付卡。
Token_status

• Token_status
• Tokens
• Token_id
• Token_template_id
• Token_status:
• Token_lot_id:参考token_lots
• Token_creation_date(与连接起始时间不同)
• Token_issuer:系统里的用户。为所创建令牌负责的用户（不必与使用者一致）
• Token_owner:可以使用此令牌的用户（如果为空那就可以是任何人）

当建立连接时，token_templates表格中的数值连同网络策略或节点策略一同被使用，目的是用来计算连接表格里的max_data_transfer和expiration_date。这个计算比较贵，但是一旦完成，所有服务器所需要做的validate max_data_transfer和expiration_data几乎都是免费的。

连接（已存在表格中新的或重新定义的字段）

• Connection_status(被删除了，现在应在token_status中查找)
• Token_id 现在参考token table
• Max_total_bytes(token_max_data_transfer—SUM（为此令牌的所有连接传送数据）)
• Max_incoming_bytes 同上
• Max_outgoing_bytes 同上
• Expiration_date(MIN(NOW+token_max_connection_duration,NOW+token_max_total_duration-SUM(为此令牌的所有连接传送数据），token_expiration_date))
• Logout_reason 解释是什么导至连接关闭

如何运作，构思

告诉我我是否错了，但这就是我具体如何看待令牌结构的。
有了这个新的令牌结构，令牌本身在连接进程和管理上发挥的作用远比现在要大。
目前，认证服务器将用户作为是连接的中心点。用户是一个实体，拥有用户名和密码，这代表了一个物理上的人。在无用户模式下这个概念是无效的。例如一个splash_only网络只有一个用户，SPLASH_ONLY_USER并且每个用户之间并没有多少差别，也不能从滥用控制机制获益等等。此外，为此，当目前用户是splash-only用户时，代码需要添加特例脚本。
Token2.0中，令牌将会扮演现在用户的角色：代表物理人来连接到网络，然而用户将仅仅是一个认证方案。
以下是服务器端在登录进程中是如何运作的

1. 可选的 显示登录页面
2. 可选的 用户输入他的认证信息（用户/执照，访问代码，NIP,当日密码）
3. 基于成功认证
   　　为令牌目的获取认证信息（例如splash-only节点的user_id,代替SPLAHS_ONLY_USER id的应该是MAC地址）
   　　用此用户/MAC来删除连接
   　　目前用户已拥有可再用的有效的令牌吗？
   　　　　是的，使用此令牌
   　　　　没有，此用户可以获得新令牌吗？
   　　　　　　是的，创新一个新令牌并使用
   　　　　　　不能，此用户无法连接，告诉他原因和应该如何操作（滥用违规控制，需要购买新令牌等等）
   　　为此令牌创建新连接
   　　根据网络策略为此连接计算数据
   　　将令牌返回网关

需要以下所有支持：

• 欢迎页面个性化的简单方法（登录界面：用户/执照，访问代码，路径选择等等）
• 增加网络/节点管理界面来管理它允许的连接/令牌类型。也许我们想要splash-only节点，用户名/密码和/或访问代码节点的混合网络，对吗？
• 改变会话对象（并引用它），这样才能引用现在被称为令牌的对象。
• 编写大量的代码来支持所有一切!（执行是自然而然的事）

本文章由 http://www.wifidog.pro/2015/03/16/wifidog%E8%AE%A4%E8%AF%81%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%BB%A4%E7%89%8C%E7%BB%93%E6%9E%84.html 整理编辑，转载请注明出处