FreeRadius unauthorized access

[Alan DeKok]

Mike Diggins wrote:
> It came to my attention recently that some users may be gaining
> unauthorized access. An account was seen to be granted access (according
> to the FreeRadius log) even though the account does not exist within the
> AD, nor is it a local FreeRadius account (not that I can see anyway).
> What I see in my logs is:
>
> Jan 15 12:23:34 xxxxx radiusd[20330]: Login OK: [whoiswho] (from client
> xxxx port 13 cli xx-xx-xx-xx-xx-xx)
> Jan 18 08:07:58 xxxxx radiusd[22212]: Login OK: [hi] (from client xxxx
> port 13 cli xx-xx-xx-xx-xx-xx)

  I'll put in my $0.02.  FreeRADIUS allows authorized users only.
Unauthorized users are never allowed access.  There is no back door in
FreeRADIUS, and there are no security issues which let random people log in.

  So the issue is one of logs.  The user is authorized, but the logs
show the wrong name.

  This means your next step should be to determine *how* the wrong name
gets in there.  Use "raddebug" to look for logins for those users.  Look
at the rest of your configuration to see what authentication methods are
allowed.

> The same accounts also appear on the wireless controller. To the best of
> my knowledge those accounts do not exist anywhere but somehow they are
> being authenticated. Blocking the account with an Auth-Type := Reject
> prevents it from authenticating. I've tested with the same account names
> using no password and various random passwords but I'm correctly denied
> access each time. I'm attempting to capture some more extensive logging
> during one of these logins

  Debug mode.  Really.  It's 2014, you should be able to run the server
in debug mode (radiusd -xxf -l stdout) in a terminal, and have it dump
the logs to a text file.  The file will be huge, but disk space is
cheap.  You can then root through the logs looking for something
interesting.

  i.e. you can guess what's going wrong, which is hard.  Or, you can
find out more about what's going on.

> but until I do, does anyone recognize a
> scenario where this might happen?

  Odds are you're using PEAP for authentication.  This means that the
inner user is authorized, so that's OK.  The outer username, however,
can be anything.  It's usually ignored for PEAP authentication.

  You probably don't want to block these names.  The users can just type
something new, and you'll have to block the new names.

  Instead, *require* the users to have a sane name outside of the
tunnel.  Usually "anonymous at yourdomain", or just "@yourdomain".  Odds
are that most users are *already* doing this.  Again, check with the
debug logs to verify this.

  When you require a proper name for the outer tunnel, it won't affect
the normal users.  They're already behaving politely.  It will only
affect the idiots who are using stupid names.

  As you see above, it's not really *knowledge* that gets you to the
solution.  It's a *process*.  A process of tracking down the problem.  A
process of informing yourself.

  Once you learn that process you can do anything.

  Alan DeKok.