(RADIATOR) Redback is sending too many Access-Requests
Mishari Al-Faris
mishari26 at gmail.com
Thu Feb 2 23:38:58 CST 2006
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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20060203/001a5bd8/attachment.html>
More information about the radiator
mailing list