FreeRadius unauthorized access
I'm running a FreeRadius server which authenticates to a Microsoft Windows 8 Active Directory via winbind and NTLM_AUTH. The service is used by a Cisco wireless network which uses WPA2 for user authentication (MS PEAP). My software versions are: Red Hat Enterprise Linux (v. 5 for 64-bit x86_64) freeradius2-2.1.12-4.el5_8 (RedHat) samba3x-winbind-3.5.10-0.110.el5_8 (RedHat) 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) 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 but until I do, does anyone recognize a scenario where this might happen? -Mike
Mike, You've snipped single lines from your logs to illustrate, but I suspect that there may be adjacent log entries that tell the story. Looks like you're seeing the outer identity, which is not what FR passes on to AD for authentication. Steve -----Original Message----- From: freeradius-users-bounces+steven.lovaas=colostate.edu@lists.freeradius.org [mailto:freeradius-users-bounces+steven.lovaas=colostate.edu@lists.freeradius.org] On Behalf Of Mike Diggins Sent: Friday, January 31, 2014 12:33 PM To: FreeRadius users mailing list Subject: FreeRadius unauthorized access I'm running a FreeRadius server which authenticates to a Microsoft Windows 8 Active Directory via winbind and NTLM_AUTH. The service is used by a Cisco wireless network which uses WPA2 for user authentication (MS PEAP). My software versions are: Red Hat Enterprise Linux (v. 5 for 64-bit x86_64) freeradius2-2.1.12-4.el5_8 (RedHat) samba3x-winbind-3.5.10-0.110.el5_8 (RedHat) 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) 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 but until I do, does anyone recognize a scenario where this might happen? -Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks for the replies everyone. If I understand correctly I likely don't have a security breach, just a lack of understanding with the authentication process. A "normal" authentications look like this: Jan 31 17:43:08 rad01 radiusd[702]: Login OK: [justme] (from client wlc-6 port 0 via TLS tunnel) Jan 31 17:43:08 rad01 radiusd[702]: Login OK: [justme] (from client wlc-6 port 13 cli xx-xx-xx-xx-xx-xx) So these odd looking ones are missing the "TLS tunnel" line and apparently that is the inner tunnel - the one sent to AD for authentication, correct? If the outer identity name is not valid then why does FR log "Login OK" and under what situation would I see one without the other? Is it possible to set the inner/outer identity to be different just using a regular client OS? -Mike On 1/31/2014 3:19 PM, Lovaas,Steven wrote:
Mike,
You've snipped single lines from your logs to illustrate, but I suspect that there may be adjacent log entries that tell the story. Looks like you're seeing the outer identity, which is not what FR passes on to AD for authentication.
Steve
-----Original Message----- From:freeradius-users-bounces+steven.lovaas=colostate.edu@lists.freeradius.org [mailto:freeradius-users-bounces+steven.lovaas=colostate.edu@lists.freeradius.org] On Behalf Of Mike Diggins Sent: Friday, January 31, 2014 12:33 PM To: FreeRadius users mailing list Subject: FreeRadius unauthorized access
I'm running a FreeRadius server which authenticates to a Microsoft Windows 8 Active Directory via winbind and NTLM_AUTH. The service is used by a Cisco wireless network which uses WPA2 for user authentication (MS PEAP). My software versions are:
Red Hat Enterprise Linux (v. 5 for 64-bit x86_64) freeradius2-2.1.12-4.el5_8 (RedHat) samba3x-winbind-3.5.10-0.110.el5_8 (RedHat)
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)
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 but until I do, does anyone recognize a scenario where this might happen?
-Mike
- List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html
Mike Diggins wrote:
A "normal" authentications look like this: Jan 31 17:43:08 rad01 radiusd[702]: Login OK: [justme] (from client wlc-6 port 0 via TLS tunnel) Jan 31 17:43:08 rad01 radiusd[702]: Login OK: [justme] (from client wlc-6 port 13 cli xx-xx-xx-xx-xx-xx)
So these odd looking ones are missing the "TLS tunnel" line and apparently that is the inner tunnel - the one sent to AD for authentication, correct?
Yes. The two lines above are the same user, inner + outer tunnel.
If the outer identity name is not valid then why does FR log "Login OK"
Because the inner tunnel authenticated the user. The name in the outer tunnel is informative. It's not really used without the other.
and under what situation would I see one without the other?
You won't. Where the user is authenticated via PEAP, you should ALWAYS see two "Login OK" lines. However, the names may be different.
Is it possible to set the inner/outer identity to be different just using a regular client OS?
Yes. Alan DeKok.
If the outer identity name is not valid then why does FR log "Login OK" and under what situation would I see one without the other?
It's not invalid, you haven't defined any rules to determine it's validity so it's not really valid nor invalid. It's logging auth ok, because the inner server authenticated the user based on the inner identity, and the outer server is using the inner server's response to determine whether to send back an Access-Accept or Access-Reject. Outer identities are often used for request routing, as in eduroam. The user may not want the institution they're visiting to know their identity, so they configure the outer identity to be anonymous@<home institution>, all the intermediary proxies just get anonymous@<home institution>, as the inner identity is protected by the TLS tunnel, but the home server receives the real identity as it terminates the TLS tunnel.
Is it possible to set the inner/outer identity to be different just using a regular client OS?
Yes, since Windows Vista I believe, and Apple supplicants even further back... wpa_supplicant has supported it for a long time too. The supplicants aren't the problem here, it really is the server configuration you're using. So just to clarify, there are a few things you can do if you want to have valid identities everywhere: * Enforce that the inner/outer identity match in the inner server. or * Enforce that either the inner/outer identity match, or the outer identity is anonymous. or * Set the outer identity from the inner identity and return the inner identity to the NAS, which should then use it for accounting and diagnostic/show commands. update outer.request { User-Name := "%{User-Name}" } update outer.reply { User-Name := "%{User-NAme}" } You probably shouldn't set the reply for users authenticating at visited sites (if you're implementing Eduroam), they might get grumpy. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
If the outer identity name is not valid >then why does FR log "Login OK" and under what situation would I see >one without the other?
Because the outer id means nothing really. You can't really trust it as it can be manipulated. In most systems is just used to get the request to the correct RADIUS for authentication. ... The server that the client expects to be talking to/trusts. If you don't like your current visibility then use linelog and log the inner/outer on your own chosen logging format.
Is it possible to set the inner/outer >identity to be different just using a regular client OS?
In all modern OSes yes. Certainly. This question suggests that you haven't looked at the client end of the system? alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 31 Jan 2014, at 19:33, Mike Diggins <mike.diggins@mcmaster.ca> wrote:
I'm running a FreeRadius server which authenticates to a Microsoft Windows 8 Active Directory via winbind and NTLM_AUTH. The service is used by a Cisco wireless network which uses WPA2 for user authentication (MS PEAP). My software versions are:
Red Hat Enterprise Linux (v. 5 for 64-bit x86_64) freeradius2-2.1.12-4.el5_8 (RedHat) samba3x-winbind-3.5.10-0.110.el5_8 (RedHat)
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)
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.
Yes, you're not enforcing outer/inner identity consistency. The Access Point and Outer server only know about the User-Name provided in the EAP-Identity-Response, whereas you're authenticating on the identity sent through the EAP-Tunnel. In the inner tunnel server would prevent this from occurring. Without that check a user could set the outer identity to anything, so long as the inner identity was valid. This can be particularly nasty, say, if you're doing dynamic VLAN assignment in the outer server, as a user can spoof the name of an administrative user, and get assigned to a VLAN they shouldn't. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 31 Jan 2014, at 20:26, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 31 Jan 2014, at 19:33, Mike Diggins <mike.diggins@mcmaster.ca> wrote:
I'm running a FreeRadius server which authenticates to a Microsoft Windows 8 Active Directory via winbind and NTLM_AUTH. The service is used by a Cisco wireless network which uses WPA2 for user authentication (MS PEAP). My software versions are:
Red Hat Enterprise Linux (v. 5 for 64-bit x86_64) freeradius2-2.1.12-4.el5_8 (RedHat) samba3x-winbind-3.5.10-0.110.el5_8 (RedHat)
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)
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.
Yes, you're not enforcing outer/inner identity consistency.
The Access Point and Outer server only know about the User-Name provided in the EAP-Identity-Response, whereas you're authenticating on the identity sent through the EAP-Tunnel.
a check like if (User-Name != outer.User-Name) { reject }
In the inner tunnel server would prevent this from occurring.
Without that check a user could set the outer identity to anything, so long as the inner identity was valid.
This can be particularly nasty, say, if you're doing dynamic VLAN assignment in the outer server, as a user can spoof the name of an administrative user, and get assigned to a VLAN they shouldn't.
But the best way it probably just to override the outer id with the inner one and sent the inner id in the Access-Accept, unless it's going out over eduroam. IIRC there are weird encoding issues with the MSCHAPv2 identity which can make it very hard, to automcatically determine whether all the IDs tie up. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Be very careful about the sorts of enforcing suggested... They can cause issues with certain types of authentication. .. eg EAP-TLS where there is no innerID... or eduroam where you don't know the real innerID of visitors. I'd only do VLAN assignments on the inner ID ... Either in the inner tunnel or set an internal attribute based on inner ID and base outer VLAN assignment on that hint. Alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 31 Jan 2014, at 22:03, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Be very careful about the sorts of enforcing suggested... They can cause issues with certain types of authentication. .. eg EAP-TLS where there is no innerID...
ok if (User-Name && outer.User-Name && (User-Name == outer.User-Name)) :)
or eduroam where you don't know the real innerID of visitors.
Wouldn't be going through the inner server. There's no way you can enforce this from the outer server. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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@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.
participants (5)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Lovaas,Steven -
Mike Diggins