(RADIATOR) Tarpitting agressive users

Dave Kitabjian dave at netcarrier.com
Tue Sep 28 13:29:39 CDT 2004



> -----Original Message-----
> From: Robert Blayzor [mailto:noc at inoc.net]
> Sent: Tuesday, September 28, 2004 12:35 PM
> To: Dave Kitabjian
> Cc: Robert Blayzor; radiator at open.com.au
> Subject: Re: (RADIATOR) Tarpitting agressive users
> 
> Dave Kitabjian wrote:
> > 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.
> 
> Not really.  I'm saying inspect the request for user at realm and keep
> track of it, then reply to the NAS immediately with a NAK.  The idea
is
> to keep it from creating endless amounts of accounting requests....
> authorization requests use almost no time, however, millions of SQL
> INSERT records gobble up tons of resources.

[dhk] Oh sorry, I didn't realize you wanted to NAK immediately. But
that's not really "tarpitting"; it's just discarding. It's not going to
slow him down, which is what "tarpitting" is about. But it will keep
your accounting logs from getting clogged. 

If you just want to discard the accounting request, use the
AccountingHandled tag in your Handler:

	http://www.open.com.au/radiator/ref.html#pgfId=363868

But like Hugh said, you're going to have to write a hook to keep track
of who has logged in recently. And you're going to want to do so in a
way that isn't more resource intensive than the problem you're trying to
solve. (I may be preaching to the choir, here). 

Maybe someday Radiator can keep an internal or other high-speed cache of
recent requests and give us configurable options on how to handle
requests that are coming too fast.

> > 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?
> 
> That won't work really.  The problem we have is the client IS
> connecting, but then hanging up immediately, then reauthing.  So even
if
> we give him a bogus IP address or a filter, it will probably do the
same
> thing.

[dhk] I see.  Too bad we can't send a Reply Item like
Upload-Fatal-Virus-To-Modem...

Dave


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


More information about the radiator mailing list