How to Reject Anonymous Identity

[Selahattin Cilek]

On 2.11.2018 20:02, Alan DeKok wrote:
> On Nov 2, 2018, at 12:49 PM, Selahattin Cilek <selahattin_cilek at hotmail.com> wrote:
>> "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:
>    OK.  I understand all that.  Given the vagueness of the message, I wasn't sure what *you* meant by it.
>
>> ... But the problem is that the user can hide his true user name in the outer request.
>    That's sort of the point of the anonymous outer identity.
>
>> Yes, but a user can choose to supply another false user name in the outer request, can't he?
>    Which is why you only authenticate the user via the *inner* identity.
>
>> 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.
>    Just look for the anonymous identity in the outer session.  This is why we tell people to read the debug output.  It *tells you* what's going on.
>
>    In sites-enabled/default, do:
>
> authorize {
> 	...
> 	if (User-Name =~ /^anom/) {
> 		reject
> 	}
>
> 	...
> }
>
>    Though the user can just change the outer identity to anything else.

So Is the MySQL stored procedure approach is my best option? Is there 
not a way to check the inner identity against the outer identity?

>
>    The question here is why do you care what the outer identity is?  All of the default configuration uses the inner identity for authenticating users.
>
>    Again, the default configuration *works*.  If you've done something to allow weird things, then it's due to your local changes.  Don't do that...

I do care because:
1. The Unifi APs that are employed on the site sometimes allow multiple 
access from laptops to the network despite that fact that 
"Simultaneous-Use" is set to "1" for every user in the database and I 
suspect that is somehow connected with the cursed anonymous identity. To 
illustrate, some users can first log in on their Android phones and then 
leave the laptop open, which tries to log in again and again and some 
time later, somehow, are connected to the network. As if that is not 
enough, I receive no accounting packets for the laptop. There is one 
particular user that confessed to once having downloaded 150GBs a night 
from his laptop. He does that almost every night. My goal is to 
distribute the connectivity and fairly as possible.
2. The Unifi APs do not know what is going on the FreeRADIUS server and 
send back accounting packages that contain lines like "User-Name: 
anonymous" or "User-Name: some_garbage"; that is why I use the "Class" 
attribute to circumvent this problem. I do not want to have to 
circumvent anything. I want everything to be correct and in place.
3. This is a public and *FREE* network. The users do not have the luxury 
of remaining anonymous. If they want to remain anonymous, they can buy 
one of those LTE packages.

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


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus