(RADIATOR) Redback is sending too many Access-Requests
Mishari Al-Faris
mishari26 at gmail.com
Wed Mar 1 04:49:03 CST 2006
Hello all,
I ended up having to use IGNORE to the requests coming from the DSL users,
because ACCEPT was making them send more requests!
But once I did that, I can't see how many bad requests are coming in the
Authlog. Is there a way to make the hook log the ones that it ignores?
thanks.
sub
{
my $p = $_[0];
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 < 15)
{
# $p->{rp}->add_attr('Session-Timeout', int(rand(1200) + 1));
return ($main::IGNORE, 'Conditional flood control');
open FLOOD, ">> /root/log.flood";
print FLOOD "$user : Conditional flood control\n";
close FLOOD;
}
return ($main::ACCEPT, 'Continue normal processing');
}
On 2/4/06, Hugh Irvine <hugh at open.com.au> wrote:
>
>
> Hello Mishari -
>
> Thanks for sharing your solution.
>
> The hook code I sent is much more efficient and runs as part of
> Radiator (at the expense of using some memory).
>
> If you do get a chance to test the hook I would be very interested in
> the results.
>
> regards
>
> Hugh
>
>
> On 3 Feb 2006, at 16:38, Mishari Al-Faris wrote:
>
> > Hello Hugh,
> >
> > Thanks so much for the help. However I had to make a solution 2
> > days ago and wrote this crude program to watch the authlog:
> >
> > #!/usr/bin/perl
> > open FILEDB, "> /etc/radiator/DSLbadboys";
> > print FILEDB "DEFAULT Auth-Type = qualitynet-authplsql\n";
> > close FILEDB;
> > open(INPUT, "tail -f /var/log/radius/qualitynet/authlog |");
> >
> > while (<INPUT>) {
> > $ll=$_;
> > chomp($ll);
> > @line=split(/\s+/,$ll);
> > $timestamp=$line[0];
> > $username=$line[7]; #this depends on how your authlog is
> > setup to output data
> > if (($timestamp - $buff1{$username}) < 5) {
> > if ($buff2{$username} < 4) {
> > $buff2{$username}++;
> > }
> > elsif ($buff2{$username} == 4) {
> > print "$username\n";
> > $buff2{$username}++;
> > open FILEDB, ">> /etc/radiator/DSLbadboys";
> > print FILEDB "$username Auth-Type =
> > Reject\n";
> > close FILEDB;
> > }
> > elsif ($buff2{$username} > 4) {
> > };
> > };
> > $buff1{$username}=$timestamp;
> > };
> >
> > And I used the AuthBy File you advised on the /etc/radiator/
> > DSLbadboys file. Works swell so far :)
> >
> > Just have to run the program as "nohup ./logwatcher.pl &" for it to
> > stay running as I log off.
> >
> > Very similar to what you provided. incidently, I tried before to
> > rewrite the hook as you did it, but had problems with the "$p-
> > >get_attr('User-Name');" bit. kept giving me compilation errors.
> > Thats when I decided to ask for help here on the forum.
> >
> > So again, thanks to everyone who replied you have been of
> > immeasurable help.
> >
> > P.S. Do you think using the hook you provided will be better?
> >
> > On 2/2/06, Hugh Irvine <hugh at open.com.au> wrote:
> > 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.
> >
> >
> >
>
>
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20060301/b7a1c2a9/attachment.html>
More information about the radiator
mailing list