(RADIATOR) Redback is sending too many Access-Requests

Mark Mackay - Orcon mark at orcon.net.nz
Wed Mar 1 12:27:47 CST 2006


Hi Mishari - 
 
You've got a "return"  before you write to the logfile, which will mean the
"open FLOOD..." line is never executed. Move the return after the "close
FLOOD;" and I think you'll get what you need.
 
Regards,
Mark Mackay.

  _____  

From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au] On
Behalf Of Mishari Al-Faris
Sent: Wednesday, 1 March 2006 11:49 p.m.
To: Hugh Irvine; Radiator MailingList
Subject: Re: (RADIATOR) Redback is sending too many Access-Requests


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
<http://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/20060302/9d4a3909/attachment.html>


More information about the radiator mailing list