(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