(RADIATOR) Tarpitting auth requests from naughty users..

[Hugh Irvine]

Hello Robert, Hello Hylke -

Thanks for your thoughtful comments.

As Hylke rightly points out this problem really needs to be addressed 
outside Radiator, because by the time the requests get to Radiator it 
is already too late. Anything that you ask Radiator to do will simply 
add to an already unacceptable load.

Keep in mind that radius is a stateless protocol and what you are 
asking is for some form of stateful overhead that in and of itself will 
only increase the processing that Radiator has to do.

regards

Hugh


On Friday, May 9, 2003, at 23:16 Australia/Melbourne, Robert Blayzor 
wrote:

>> In our large DSL network we don't have just one customer
>> that's doing this,
>> we have many. It's a general DSL problem. We developed a process that
>> periodically scans the (compact) authentication logfile. If
>> there are too
>> many failed logins for a certain customer this process tells
>> the NAS to
>> remove the VC of this customer and restores it after one hour.
>> As an alternative you could think of a "CacheRejects"
>> parameter in Radiator
>> (similar to CachePasswords). This could at least lower the
>> load on database
>> checking due to these never ending failed logins.
>
> I've searched through the manual and have found no mention of a
> "CacheRejects" option in Radiator.  I've thought about what Hugh
> mentioned, but in order to do what we want, it would add way to many 
> CPU
> cycles to already busy RADIUS servers.
>
> So I'm thinking an option (perhaps feature) can be added to RADIUS to
> help us protect RADIUS servers in wild west type of large broadband 
> user
> networks.
>
> Perhaps a directive in the AuthBy similar to:
>
> CacheRejects
> CacheRejectThreshold X  (default to 5)
> CacheRejectPeriod X (default 60 seconds)
> CacheRejectExpiry X (default to 3600 seconds, 1 hr)
>
> In this case CacheRejects tells Radiator to start caching Rejects if 
> the
> CacheRejectThreshold has been met or exceeded within the
> CacheRejectPeriod timeframe.  If it's a positive hit by the criteria
> above, the cache entry stays until it expires.  Radiator should do
> nothing with these requests other than to immediately send a NAK back 
> to
> the RADIUS client. (no lookups or logging other than a log entry to 
> show
> the first time someone makes it into the cache)
>
> I know it seems like a lot, but seems like a useful feature.
>
> --
> Robert Blayzor, BOFH
> INOC, LLC
> rblayzor at inoc.net
>
> My computer NEVER cras
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.