Radius动态黑名单功能的实现

爱卫生

本文摘自《电子技术》2011年06期。【作者】 朱惠龙； 【机构】 上海电信NOC业务平台维护中心；

【摘要】 上海电信认证计费系统担负着上海电信400多万宽窄带用户的认证授权功能,在宽带业务中占有非常关键的地位。本文简要分析了上海电信认证计费系统目前存在的认证问题,通过数据分析,找到目前影响系统性能的原因,并提出了解决方案。通过在Radius中增加动态黑名单的功能,对那些异常认证数据进行判断,并加以拦截,从而减少异常认证数据对认证系统的影响。

0引言

基于宽带互联网的增值应用和服务发展迅速，最近几年，上海电信宽带业务也进入了大发展时期。截止到2010年1月，上海电信的宽带用户已突破400万，覆盖了上海所有区域。而且随着宽带技术的发展，从最早单纯的ADSL、FTTBLAN接入，发展到现在FTTH、FTTO、PON+ADSL、PON+LAN等多种接入方式，业务也从单纯的上网发展到IPTV、VOIP、绿色上网、VPDN等多种增值业务。

目前担负上海宽带业务认证的是1998年开始建设的上海电信认证计费系统，经过多年的发展，目前已经能容纳450万用户'每秒3000个报文处理能力。该系统主要是使用Radius协议(Remote Authentication Dial in User Service)，即远程拨号用户认证协议，为宽带用户提供认证和计费功能。Radius主要用于用户的身份认证、授权与计费，也就是我们俗称的3A(验证Authentication、授权Authorization和记账Accounting的简称）。

- 验证：验证用户是否可以获得访问权可以选择使用Radius协议；

- 授权:授权用户可以使用哪些服务；

- 记账:记录用户使用网络资源的情况;

Radius是一种C/S结构的协议，规定了客户端(作为Radius Client)和认证服务器(Radius Server)以及认证服务器之间传送身份认证信息和计费信息的消息格式和流程，
采用UDP方式传输消息，通过定时器管理机制、重传机制、备用服务器机制，确保Radius服务器和客户端之间交互消息的正确收发[3]。

1认证中存在的问题

随着用户增加及业务的发展，上海电信认证计费系统的认证压力变得非常大，而且还有逐渐增多的趋势，在2009年5月份，每天认证次数还只有1500万次，到了11月份，已经增加到了2000万次以上。但相对而言，每天的使用记录只有1000万条不到，和认证次数明显无法匹配。

对此，我们在2009年8月份在5/6/7三个月中各抽了3天的数据，对认证报文进行了统计，如表1和表2所示。

从表1和2可以看出:

(1)不管是根据端口还是根据帐号统计，认证次数超过1000次的帐号或者端口认证次数要占认证总次数的50%左右；而认证次数超过10000次的帐号或者端口，则占总认证次数的30%左右；

(2)剔除超过1000次的账号或者端口的认证次数，其认证报文数和计费结束报文数大致相当；所以我们把这些一天超过1000次的认证账号或者端口定义为异常账号和异常端口(下文中所称的异常认证就是指异常账号和异常端口）；

(3)由于Radius报文分认证报文、计费起始包、计费结束包三种，正常情况下，一条完整的使用记录各包含认证报文、计费起始包、计费结束包三个报文，考虑到目前80%的宽带用户的计费报文都是准实时处理的，不占用认证计费系统性能，所以由此推断，整个电信认证计费系统大概有40%的系统性能被异常认证所占用；

(4)本论文主要是研究如何减少认证次数，释放被这些认证占用的系统性能。

2 原因分析

到了2009年11月份，每天的认证次数增加到了2400万次以上，系统压力进一步加大。为此我们对11月份的数据再次进行了分析，如表3所示。

根据表3的统计来看，超过1000次的认证端口，其认证次数占当天总次数的50%左右，基本上和5/6/7三个月相同。

我们对这些端口上发出的认证请求报文中的帐号进行了初步分析，结果如表4所示。

从上面的分析来看，不存在的账号、已经拆机的账号、绑定不一致的账号和欠费账号占了83%，这4类账号都是应该认证失败的，但由于用户设置或其他原因端口没有关闭，导致用户不停发起拨号认证请求，每次认证请求又是失败的。这些始终失败的认证请求，占用了大量的系统资源，影响了正常的认证请求。
这些每天超过1000次的认证请求，平均下来每分钟就有一次，严重的甚至每几秒钟就有一次认证请求，和正常的上网认证请求相比，这些认证应该是异常的，而且也不排除是恶意的攻击行为，也有可能是用户系统受到木马等影响变成了他人攻击工具。

3解决方案

由于认证计费过程上的限制，传统做法是通过事后分析数据，将异常认证的账号或者端口加入到黑名单中，从而来进行系统防护，但这样是非常被动的，而且黑名单数据更新不及时，会影响正常的用户，因此我们提出了通过在RADIUS服务器中建立动态黑名单机制来准实时地实现对异常认证攻击的系统保护。

3.1设计方案

动态黑名单的实现，通过在RADIUS中加载一个“动态黑名单”的处理模块，对异常认证数据进行收集，然后定时统计分析形成黑名单列表，依据黑名单对认证报文进行分析处理，对异常认证的请求进行拦截，从而形成对后面认证计费系统的保护。

动态黑名单可以依据帐号或端口加以实现：

a.依据帐号，可以对不同端口上，同样的帐号攻击进行拦截；

b.依据端口，可以对同一端口上的，不同的帐号攻击进行拦截。

异常认证数据的收取会存在二个来源：
(1)在没有进入到黑名单的情况下：对由后端系统通过RADIUS回应给NAS/BAS的ACCESS-REJECT回应报文(认证拒绝)进行处理，获得的异常认证的帐号或者端口数据，加入统计队列一作为新黑名单的判断依据。
(2)在已经进入黑名单的情况下：对于进入黑名单的新认证请求，由于直接由RADIUS进行拦截处理了，这些被拦截的认证请求，也可以当作异常认证的账号或者端口数据加入统计队列。在此情况下，对于异常认证账号或者端口，可以维持在黑名单中；对于误判的非异常认证账号端口，如果没有达到阀值限制，可以脱离黑名单，但仍达到阀值限制，将继续被误判在黑名单中。

3.2实现方法

动态黑名单的机制实现是在原有的每台RADIUS架构的基础上，进行有关功能模块的扩展。整个流程如图2所示，方案的具体说明如下：

(1)初始化。

1)动态黑名单的参数初始化。动态黑名单的参数包括：

a.黑名单参数：

0，不启用动态黑名单100-2000，黑名单的最大长度控制

b.统计间隔参数：

单位：S，范围：120~3600

c.次数阀值：

单位：次，范围：1〜1000

参数存放位置：Config文件中参数初始化方法：修改read_core函数：a.增加全局变量；b.从CONFIG文件$core中读取参数

2)动态黑名单的队列初始化。根据参数(如果启用黑名单)，进行黑名单、异常认证数据统计队列的初始化。

3)动态黑名单的生成线程初始化。根据参数(如果启用黑名单)，进行定时器配置，定期触发黑名单生成线程。

(2)黑名单检测。

1)根据参数判断是否使用黑名单检测功能；

2)黑名单检测处理功能模块的调用放在mod_run的调用之前执行；

3)黑名单检测模块：

函数名：intcheck_unnormal_bylogin(char*login)intcheck_unnormal_byport(char*port)

参数：登录名或端口

返回值：表示检测结果：0，表示正常；1，表示在黑名单中函数功能：根据全局变量所定义的黑名单指针，进行登录名校验，若登录名不存在，返回0;若存在，返回1。

4)黑名单检测结果处理。根据黑名单检测结果，进行处理：a.加入异常认证数据的队列（见“异常认证数据加入的函数，，的说明）；b.发送access-reject的回应包(调用原先NAK的处理函数）。

(3)处理等待的队列的数据对象调整。Waiting结构中加入USER_NAME和端口信息。端口信息由RADIUS报文中的有关属性值根据一定的规则进行拼接。

(4)回应包处理。

1)在search_waiting后，增加异常认证数据处理：a.对access-reject的"回应进行处理，（access-accept不进行处理）；b.根据search_waiting的调用，获取用户的帐号或端口；c.调用“异常认证数据加入的函数”，将帐号加入异常认证的数据队列。

2)异常认证数据加入的函数。

函数名：intadd_unnormal_account(char*login)intadd_unnormal_port(char*port)

参数：登录名或端口

返回值：表示检测结果：0，加入正常；1，存在异常

函数功能：根据全局变量所定义的异常认证数据指针，进行登录名校验，若登录名不存在，则加入链表；若存在，将其统计数据+1。（登录名和端口独立）

(5)黑名单生成处理线程。

1)黑名单维护线程是一个定时触发执行的维护线程，此线程由初始化程序，根据参数要求进行配置触发。

2)黑名单维护线程处理过程：a.进行“异常认证数据”的指针交换；b.对异常认证数据进行统计分析；c.根据参数进行黑名单的生成；d.打印黑名单数据；e.进行“黑名单”的指针交换；f.对已经无用的“异常认证数据”和“黑名单”进行空间释放。

3)对于一些测试使用的帐号或端口进行屏蔽。认证计费系统中有一些用户监控维护的测试帐号，会进行有关的测试检查，对于此类帐号或端口，不纳入黑名单的控制范围。

4结论及下一步工作

本文主要是针对目前宽带认证中存在的异常认证，提出了一个学习、判断和拦截方案。通过在RADIUS中增加动态黑名单功能，第一时间进行拦截，从而降低这些异常报文到后台数据库中进行认证占用系统资源的影响。

由于上网账号是用户可以配置的，而端口是网络上的数据，用户无法篡改，所以目前我们是基于端口进行异常认证数据的统计，同时在初期，我们设定为单台服务器每5分钟收到5个报文就作为黑名单。

该功能上线运行后，效果也比较明显，如表5所示。

目前我们的黑名单功能是在每台服务器自行判断自行拦截的，由于负载均衡的关系，有关的异常认证数据可能会分散在不同的RADIUS上，因此有关的统计分析也是分散的，会存在一定的误判局限性；而且黑名单情况是在各台机器上的，对维护管理不太方便。

所以在下一阶段我们将研究统一黑名单控制的方案。黑名单信息统一管理之后，就可以形成一个整体，有效地对整个环境的状态进行统一计算和管理，真正实现有效、准确的拦截。另外我们可以将高CPU占用的黑名单计算工作放在后台完成，同时RADIUS主机上也不必保存异常监控数据，可以节省大量的内存空间以及对内存的操作工作，综合运行效率和效果要比原来的模式好很多，另外还可以强化人工干预的能力，通过将配置信息、状态监控信息放到数据库服务器上，同时提供黑名单的手工维护功能，尤其是可以实现黑名单的分级管理机制，将动态黑名单和静态黑名单有机地结合起来，形成更加强大的管理能力。

但统一黑名单方案必须要解决黑名单的管理机制、性能和安全冗余等问题，否则会影响正常的认证功能，所以对该方案的研究，必须慎重对待。

参考文献：

[1] IETF RFC2058-Remote Authentication Dial In User Service(Radius)[S/OL].l997,1.http://tools.ietf.org/html/rfc2058

[2] IETFRFC2059-Radius Accounting[S/OL].l997,1.http://tools.ietf.org/html/rfc2059

[3] RigneyC,WillensS,RubensA,etal.Remote Authentication Dial In User Service Accounting(RADIUS Accounting).RFC2866、[S/OL].June2000,6.http://www.ietf.org/rfc/rfc2866.txt