(RADIATOR) Redback is sending too many Access-Requests
Hugh Irvine
hugh at open.com.au
Wed Feb 1 16:36:55 CST 2006
Hello Mishari -
OK understood - here is another version for you to try.
----------------------------------------------------------------------
This hook allows you to do conditional flood control to rate limit
radius requests.
The hook saves the time of the last Access-Request for each user
and conditionally returns an Access-Accept if the time is less than a
preset limit.
Special reply attributes can be added to the conditional access
accept by using
an AddToReply to restrict access to a maintenance web site for example.
# RequestHook for AuthBy INTERNAL
# This hook saves the time of the last Access-Request for each user,
and returns
# Access-Accept if the time difference between requests is less than
5 seconds.
# A Session-Timeout reply attribute is added to the reply with a random
# value between 1 and 1200 seconds(20 minutes).
#
# Note: these values should be altered as required.
#
# Hugh Irvine, Open System Consultants, 20060202
sub
{
my $p = $_[0];
my $code = $p->code;
return ($main::IGNORE, 'Continue processing other requests')
unless $code eq 'Access-Request';
my $user = $p->get_attr('User-Name');
my $this_request_time = time;
my $last_request_time = &main::getVariable($user);
# save the time of this request for this user
&main::setVariable($user, $this_request_time);
if ($this_request_time - $last_request_time < 5)
{
$p->{rp}->add_attr('Session-Timeout', int(rand(1200)
+ 1));
return ($main::ACCEPT, 'Conditional flood control');
}
return ($main::IGNORE, 'Continue normal processing');
}
Please let me know how you get on.
regards
Hugh
On 1 Feb 2006, at 20:34, Mishari Al-Faris wrote:
> Unfortunately the users aren't that consistent. Its not the same
> users all the time. Which users/ports are sending the requests is
> directly related to which of them have their PCs on or off, and to
> be honest we're still not sure what causes which customers to start
> sending the requests. So when another user starts having the same
> problem, I'd rather use the hook to dynamically isolate him than to
> have to gather their names from the log file and enter them manually.
>
> On 2/1/06, Hugh Irvine <hugh at open.com.au> wrote:
> Hello Mishari -
>
> Well in this case I would suggest you use cascaded AuthBy clauses
> instead.
>
> Something like this:
>
> # configuration file
>
> <AuthBy FILE>
> Identifier CheckUsers
> Filename %D/users
> </AuthBy>
>
> <AuthBy PLSQL>
> Identifier CheckDatabase
> .....
> </AuthBy>
>
> ......
>
> #Realm or Handler
>
> <Handler .....>
> ......
> AuthBy CheckUsers
> .....
> </Handler>
>
>
> Then the file "%D/users would contain something like this:
>
>
> # users file - DEFAULT will be used for all users not explicitly
> listed
>
> DEFAULT Auth-Type = CheckDatabase
>
> # list of the 50 or so users that cause problems
>
> username1 Auth-Type = Reject
>
> username2 Auth-Type = Reject
>
>
> This way the users who are known to cause problems are listed in the
> file, which is cached in memory and is hence very fast.
>
> Obviously you will need to maintain the file, but this seems to me a
> much better solution, and doesn't require a hook.
>
> regards
>
> Hugh
>
>
> On 1 Feb 2006, at 18:19, Mishari Al-Faris wrote:
>
> > Hello Hugh,
> >
> > I understand that it will "accept" and spread them randomly over
> > 1-20 mins. That is fine with me, as long as I treat the offending
> > users differently than the normal ones. My problem is that my
> > oracle DB behind radiator can not handle all the requests, the good
> > and the bad ones. The bad requests are relentless and can
> > constitute over +95% of the incoming requests. I have about 7500+
> > DSL customers and they stop complaining once I manually do "AuthBy
> > AllowAll" temporarily, however, I have around 200+ customers who
> > require static IPs obtained from the DB, and once I turn off
> > authentication those static-IP customers start getting dynamic IPs
> > and start complaining, so I can't stop authentication for long.
> >
> > The amount of usernames that produce the bad requests is very small
> > compared to the total amount of users, say around 50+. And those
> > are the ones I want to exclude, also, I'm not sure what's common
> > between them that causes them to send so many requests. So far what
> > I see from these users is that they send 1 Access-Request every 1-5
> > seconds, consistently and without stopping, regardless of what
> > response I send them, Accept or Reject doesn't matter, they keep on
> > sending. And even when I use AllowAll, which is the fastest
> > response I can achieve, they still send the requests, so I'm ruling
> > out that the radius is slow to respond to them.
> >
> > Also, the requests that come from the same user each has a
> > different "Acct-Session-Id". And the Redback is configured for 60
> > seconds timeout and only 1 retry. So this makes me rule out that
> > the Redback is retrying for the same user. Instead what I think is
> > happening is that the user connection to the Redback is unstable
> > and disconnecting and connecting again quickly, which causes the
> > Redback to create a new request for him.
> >
> > So, I'm willing to try this solution even if the per-user counters
> > take up alot of memory, if it doesn't work I'll stop using it, but
> > in the meantime I'm in trouble and am willing to try anything :(
> >
> > Ofcourse it goes without saying that I'm not holding any guarantees
> > against anyone either. If it works it works.
> >
> > So what I want to do is to exclude the few users that send that
> > many requests and either Accept them, or Ignore them, or Reject
> > them, doesnt really matter, as long as I don't go to the AuthBy
> > PLSQL clause for these guys. hence protecting my DB from the
> > onslaught.
> >
> > On 2/1/06, Hugh Irvine <hugh at open.com.au> wrote:
> > Hello Mishari -
> >
> > You should note first of all that this hook code will not "ignore"
> > the access requests - the hook is designed to "accept" all access
> > requests over a certain number with a variable session timeout that
> > will cause the resulting temporary session to drop after some random
> > time. The idea being to spread the requests over a longer period of
> > time. Also note that this is an idea only - I make no guarantees
> > about the success or otherwise of using this code.
> >
> > I am also not sure about maintaining per-user counters, as this will
> > lead to greatly increased memory usage.
> >
> > Can you tell me exactly what you are wanting to do?
> >
> > regards
> >
> > Hugh
> >
> >
> >
> > On 31 Jan 2006, at 22:53, Mishari Al-Faris wrote:
> >
> > > Dear Hugh,
> > >
> > > This is an example that you suggested a while back to mitigate
> > > excessive requests coming from DSL NASes.
> > > I've been trying to modify it to our needs but have been getting
> > > compilation errors. Let me just explain what I wish to do instead
> > > of going through what I did wrong.
> > >
> > > I'd like to count the access trials per "user" not per "NAS". If a
> > > certain username is seen trying more than say 1 request per 5
> > > seconds, I want to ignore the request, and not go through my
> > > AuthPLSQL AuthBy clause. Is this possible? thanks.
> > >
> > > # RequestHook for AuthBy INTERNAL
> > > # This hook counts the number of access requests that are received
> > > for a
> > > # particular NAS, and returns an ACCEPT if there are more than 100
> > > per second.
> > > # A Session-Timeout reply attribute is added to the reply with a
> > > random
> > > # value between 1 and 1200 seconds(20 minutes).
> > > #
> > > # Note: these values should be altered as required.
> > > #
> > > # Hugh Irvine, Open System Consultants, 20050829
> > >
> > > sub
> > > {
> > > my $p = $_[0];
> > > my $time = time;
> > > my $code = $p->code;
> > > my $nas = $p->{Client};
> > > if ($time == $nas->{last_throttle_time} && $code eq 'Access-
> > Request')
> > > {
> > > if (++$nas->{throttle_count} > 100)
> > > {
> > > $p->{rp}->add_attr('Session-Timeout', int (rand(1200) + 1));
> > > return ($main::ACCEPT, 'Conditional flood control');
> > > }
> > > }
> > > else
> > > {
> > > $nas->{throttle_count} = 0;
> > > }
> > > $nas->{last_throttle_time} = $time;
> > > return ($main::IGNORE, 'Continue to proxy');
> > > }
> > >
> > >
> > >
> > > Here is an example of how to use the hook.
> > >
> > >
> > > <Handler .....>
> > >
> > > AuthByPolicy ContinueWhileIgnore
> > >
> > > <AuthBy INTERNAL>
> > > RequestHook file:"throttle.pl"
> > > AddToReply .....
> > > </AuthBy>
> > > # normal AuthBy
> > > <AuthBy .....>
> > > .....
> > > </AuthBy>
> > > </Handler>
> >
> >
> > 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?
> >
> > --
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> > -
> > 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.
> >
> >
> >
>
>
> 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?
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> -
> 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.
>
>
>
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?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
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.
--
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