[RADIATOR] Top level radius servers problems

[Esmeralda Pires]

Hi Alan

We add to all our peers handler configurations a “NoReplyHook”
(Paul Dekkers from Surfnet is also helping us on this problem)

<Handler Realm=/^(id|corp)\.fccn\.pt$/,Client-Identifier=/^(?!FCCN$)/>
<AuthBy RADIUS>
Host x.x.x.x
Secret zzzzzzzzzzzz
AuthPort 1812
AcctPort 1813
Retries 1
UseExtendedIds
NoReplyHook file:"/etc/radius/RejectNotIgnore.pl"
</AuthBy>
AuthLog roamingstats
AcctLogFileName %L/Accounting/FCCN/%Y-%m-detail
RejectHasReason
</Handler>
------------------------------------------
== RejectNotIgnore.pl ==
------------------------------------------
sub
{ my $p = ${$_[0]};
my $fp = ${$_[1]};
my $rp = ${$_[2]};
&main::log($main::LOG_DEBUG, \
"Sending Access-Reject instead of ignoring");
$rp->set_code('Access-Reject');
$p->{Client}->replyTo($p);
return;
}

Is this similar to the first fix you mentioned?

We have already try to check the values of “Retries” and “RetryTimeout” 
from our radius institutions, we have recommend this values:
• RetryTimeout ( 5s)
• Retries ( 0 or 1)
Do you have any recommendations on this?

About :“the visited site should have EAP login limits on their NAS to 
stop brute-force etc attacks - eg 3 logins in 60 seconds for a client etc….”
Do you have a configuration already to limit this type of brute-force 
attacks?

We really appreciate that you can send us the entire configurations that 
you used to resolve this problem.

Thank you for your help
Regards
Esmeralda



On 25-05-2011 09:39, Alan Buxey wrote:
> Hi,
>
>>     If this was a problem related to the client running out of ID REQUEST
>>     where can I look on the logs for a warning or something alerting that this
>>     is happening?
> welcome to the party. in the UK we have seen this issue to - and it doesnt take
> that much until the server is all backlogged up and then other people to other
> RADIUS servers get all messed up too.
>
>>     And what are the recommendations to solve this kind of problem?
> from looking at the behaviour and working out the 'hit' that the RADIATOR
> daemon takes for different issues I have found that dealing with incorrect
> names (people sending junk to the national proxy) whilst annoying, a Reject
> is quite 'cheap' for resources...its done quick and clears the socket for
> use. a non responsive homesite causes the daemons UDP socket pipe to fill and disrupts
> service for others...so, we recommend that sites have at least 2 RADIUS servers
> (for resiliency) and have local monitoring so that they can see that their
> site has issues..... its amazing how many still have just 1 RADIUS
> server and no monitoring for it (!)  :-(
>
>
> the 'fix' that I have done is to implement a handler in the AuthBy clause for
> noresponse - similar to the one supplied in goodies.txt - but not failing back to UNIX
> local handler etc - therefore the user trying to connect to an unresponsive site
> is just rejected.  whilst not the best ultimate solution (their dumb client will
> say something like 'wrong password' or such - it does stop the requests whacking
> the server....up until the server is ready to retry the home site - about 60 seconds
> IIRC from our config.
>
> the OTHER issue - which I will be raising at higher level is that sites have got their NAS
> kit bvadly configured - when this event happens we see thousands of requests for those
> users coming in - the visited site should have EAP login limits on their NAS to stop brute-force
> etc attacks - eg 3 logins in 60 seconds for a client etc.  instead it looks like the kit
> just keeps going anf going and going. relentless  :-(
>
> I can provide you config/snippet etc - and after discussion I hope for this (and a non related
> FreeRADIUS config snippet I did for Japan earlier this week) to be in the european
> eduroam wiki
>
> alan