[RADIATOR] Multiple auth failure handling

Hugh Irvine hugh at open.com.au
Fri Jun 26 18:06:28 CDT 2009


Hello Jim -

If the AuthBy SQL clause cannot contact the database it will return  
IGNORE.

See section 5.29 in the Radiator 4.4 reference manual ("doc/ref.pdf").

regards

Hugh


On 27 Jun 2009, at 01:34, Jim wrote:

> I think I have it sussed now.  I have configured Authlog to log  
> failures to a MySQL database, and then in my handler I have:
>
> <Handler Realm = blah.com>
>  ContinueWhileReject
>  <AuthBy LDAP2>
>      LDAP Stuff
>  </AuthBy>
>  <AuthBy SQL>
>               DBSource dbi:mysql:Radius:10.0.0.1
>               DBUsername username
>               DBAuth pass
>               AuthSelect SELECT USERNAME FROM Radius.authlog WHERE  
> USERNAME = %0 GROUP BY USERNAME HAVING COUNT(*) > 25
>               AddToReplyIfNotExist Framed-Protocol="PPP",Framed-IP- 
> Address="255.255.255.254",RB-Context-Name="garden",
>               AuthColumnDef   0,User-Name,check
>               NoDefault
>  </AuthBy>
> </Handler>
>
> Now a normal user still gets authenticated via LDAP, but if that  
> check fails it tries to auth against MySQL and if it finds the user  
> in the table more than 25 times it will accept the connection and  
> put them in the walled garden setup.  Hopefully everyone will be  
> happy with this solution as users generally still get the failed  
> authentication message, but if they continue to be bad action is  
> taken.
>
> Not sure how the extra SQL inserts and selects effect performance  
> but it should reduce authentication requests %50.
>
> What would happen if the MySQL was not responding?  I guess radiator  
> would ignore the request due to the AuthBy SQL timeout rather than  
> fallback to sending the reject from the AuthBy LDAP?
>
> I've only just really started using Radiator but its great what you  
> can do with it. :)
>
> Thanks.
>
> Jim.
>
> Hugh Irvine wrote:
>>
>> Hello Jim -
>>
>> Could you clarify what you are wanting to do?
>>
>> You cannot both accept and reject the same RADIUS request(s).
>>
>> regards
>>
>> Hugh
>>
>>
>> On 26 Jun 2009, at 18:21, Jim wrote:
>>
>>> I would but apparently we want our customers to get the standard
>>> authentication failure responses normally, and thats what our main
>>> resellers want.
>>>
>>> Jim.
>>>> -----Original Message-----
>>>> From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au 
>>>> ]
>>>> On Behalf Of Kiernan Mccoll
>>>> Sent: 26 June 2009 02:59
>>>> To: radiator at open.com.au
>>>> Subject: Re: [RADIATOR] Multiple auth failure handling
>>>>
>>>> Why not just walled garden all failures?
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au 
>>>> ]
>>>> On Behalf Of Jim Tyrrell
>>>> Sent: Thursday, June 25, 2009 7:35 PM
>>>> To: radiator at open.com.au
>>>> Subject: [RADIATOR] Multiple auth failure handling
>>>>
>>>> Hi,
>>>>
>>>> I have been looking at our accounting logs and realised that 50%  
>>>> of all
>>>> the radius traffic is authentication failures for a relatively  
>>>> small
>>>> number of users.  I want to implement a solution to put the users  
>>>> into a
>>>> walled garden if they continue to fail and was thinking of somehow
>>>> logging failed auths to MySQL and using a handler such as:
>>>>
>>>> <Handler Realm = blah.com>
>>>>   ContinueWhileReject
>>>>   <AuthBy LDAP2>
>>>>       LDAP Stuff
>>>>   </AuthBy>
>>>>   <AuthBy SQL>
>>>>        If user in SQL DB then auth and setup for walled garden with
>>>> session timeout
>>>>   </AuthBy>
>>>> </Handler>
>>>>
>>>> So if the session is reject it then checks against MySQL to see  
>>>> if the
>>>> user is in there, or in there X number of times and if so accept  
>>>> and
>>>> return attributes to put them into a walled garden.
>>>> Does this make sense?  I have done some searching and other  
>>>> solutions
>>>> were generally using hooks and I want to avoid using my shoddy perl
>>>> skills if possible.
>>>>
>>>> What would be the best way to get failed authentications into  
>>>> MySQL?  I
>>>> could then either query for count of failed sessions or have a  
>>>> job on
>>>> the MySQL server to produce a table of top failing users.
>>>>
>>>> Failing that I could just have a script on each radius server to  
>>>> get the
>>>> frequent users from the Radiator logs and put into a text file  
>>>> and then
>>>> have my 2nd authby look at this file but MySQL would give me more
>>>> flexibility and would be visible to support staff.
>>>>
>>>> Thanks.
>>>>
>>>> Jim.
>>>> _______________________________________________
>>>> radiator mailing list
>>>> radiator at open.com.au
>>>> http://www.open.com.au/mailman/listinfo/radiator
>>>> _______________________________________________
>>>> radiator mailing list
>>>> radiator at open.com.au
>>>> http://www.open.com.au/mailman/listinfo/radiator
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> radiator mailing list
>>> radiator at open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>>
>>
>>
>> NB:
>>
>> Have you read the reference manual ("doc/ref.html")?
>> Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
>> Have you had a quick look on Google (www.google.com)?
>> Have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>> Have you checked the RadiusExpert wiki:
>> http://www.open.com.au/wiki/index.php/Main_Page
>>
>



NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.




More information about the radiator mailing list