(RADIATOR) Tarpitting agressive users

[Dave Kitabjian]

I don't have the answer, but I have a comment... :)

The first thing to consider is whether the NAS will be doing the
tarpitting or Radiator. Since RADIUS is UDP, if Radiator waits too long
to send a reply, the NAS will simply send a reject or go to a backup
Radiator box. In essence, you would be tarpitting the NAS as much as the
user.

However, if you have a long enough failover threshold on the NAS,
tarpitting via Radiator will work fine.

I'd be surprised if NASes offer any type of explicit "tarpitting"
feature, but it might be nice :) If there is such a feature, I'd love to
know.

There may also be clever, inadvertent ways of tarpitting the user using
some clever choice of RADIUS Reply Items. What if, eg, we send him back
some sort of Filter-Id or some other attribute that makes him feel like
he's connected, but nothing works. Other choices might include a
black-hole Framed-Route or Framed-Address. Thoughts?

Dave

> -----Original Message-----
> From: Robert Blayzor [mailto:noc at inoc.net]
> Sent: Tuesday, September 28, 2004 11:38 AM
> To: radiator at open.com.au
> Subject: (RADIATOR) Tarpitting agressive users
> 
> I know we bought this up in the past, but I'm not really sure we ever
> discussed an "end all" solution for this problem.
> 
> The problem we see from time to time is a "run away" PPPoE client just
> loses it's mind and consantly auths, disconnects, auths, disconnects,
> ... every second or two.
> 
> I just found a user or two that have been doing this for weeks and
it's
> polluting our RADIUS accounting SQL logs with MILLIONS of rows just
from
> this one user.
> 
> I'm wondering if Radiator can be modified or configured to tarpit
these
> types of run away clients.  I'm looking for something I can set a
> threshhold within a certain period of time and then set a "lock out
> period".  ie:
> 
> If a user logs in more than 100 times within an hour, fail auth for
two
> hours.  Ideally it would be nice to log (only once) that the user has
> been tarpitted and then log send anything to the auth log until the
> period expires.
> 
> I know this is probably not that easy to do and I'm not looking for
> something that will create more SQL transactioins.  I'm willing to
> consume more RAM (which is available) over doing a SQL table to keep
> track of this.
> 
> Are there any good examples to maybe write a PreHandler hook that can
> use a persistant hash of arrays where I could store the user at realm in
> the hash with the number of logins, etc.  I'd need to have this hash
> survive each time the sub is exited.  Something tells me this would
> require a Radiator modification.  Am I wrong?
> 
> TIA
> 
> -Robert
> 
> --
> 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.


--
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.