How to Reject Anonymous Identity

[Selahattin Cilek]

On 2.11.2018 19:15, Alan DeKok wrote:


On Nov 2, 2018, at 12:08 PM, Selahattin Cilek <selahattin_cilek at hotmail.com><mailto:selahattin_cilek at hotmail.com> wrote:



I use FreeRADIUS 3.0.17 to provide services on a site. Ever since I
stepped into the world of RADIUS, I have been dealing with the issue of
"anonymous" users.



  What do you mean by anonymous users?

"Anonymous" users those who use another user name in the outer EAP request. The option to use an anonymous (or "outer" or "secret" or "hidden") identity is enabled default on SecureW2 and  Windows 10's Microsoft EAP-TLS implementation and almost all devices can be configured to use it. This is a measure designed to prevent an attacker from getting a user's true user name by sniffing the packets that go between the NAS and the RADIUS server. Of course, when the request enters the the TLS tunnel, the server gets the user's true user name. I think these two lines from the log should make it clear:

Nov 2 19:44:32  radiusd         65078   Login OK: [anonymous] (from client DAIRE_703 port 0 cli 34-23-87-7B-28-FF)
Nov 2 19:44:32  radiusd         65078   Login OK: [60643462528] (from client DAIRE_703 port 0 cli 34-23-87-7B-28-FF via TLS tunnel)

This user is using anonymous identity.




  The normal operation is to only authenticate *known* users.  Everyone else is unknown, and un-authenticated.

Yes, of course, obviously. But the problem is that the user can hide his true user name in the outer request.






I have been abusing the *Class* attribute work around
the problem, but after some deliberation, I've decided that it would be
best if I could reject anonymous users right away.



  Perhaps there's debug output you could share...

I did not want to deluge the message with debug output since this is not about an error I am getting. I just want to improve my configuration a little bit.






Currently, this store procedure can check if a user with a given name
exists in the database, and if not, return *0* to make FreeRADIUS to
reject access to that user.



  The default *is* to reject unknown users.  So if your system is allowing unknown users, then it's because of local changes you made to allow that.

Yes, but a user can choose to supply another false user name in the outer request, can't he?






What I'd like to know though is that if there is a better, more elegant
FreeRADIUSy way of achieving the same goal. For example, would something
like below work?



  If you could describe in more detail what you're doing, we could help.

I want to check if a user is using anonymous identity and reject access to him in the FreeRADIUS configuration, that is, without the help of MySQL. Something like: If he is using anonymous identity, do not let him in.




  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>      Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>