Re: Eduroam & FreeRadius not working so well
In the first instance, upgrade. There is a major security problem with 2.1.x release. Get 2.2.x onto your system asap. What are your NAS (cisco controllers) timeouts? Is this box a pure proxy or does it do authentication too? Have you enabled ciscos status-check system so it knows the RADIUS server isn't dead but just hasn't had a remote response yet? Around 67% of eduroam sites in the UK use freeradius alan
On Wed, 5 Dec 2012, Alan Buxey wrote:
In the first instance, upgrade. There is a major security problem with 2.1.x release. Get 2.2.x onto your system asap.
This is the RedHat RPM which I believe are maintained by RedHat. Hopefully they've back ported any major security issues!
What are your NAS (cisco controllers) timeouts? Is this box a pure proxy or does it do authentication too? Have you enabled ciscos status-check system so it knows the RADIUS server isn't dead but just hasn't had a remote response yet?
It does both autentication and proxy and I do have status-check enabled. On the contraller I increased the default timeout from 2 seconds up to 8 seconds. At the same time I lowered the response_window for the two Home Servers from 20 seconds to 5 seconds, thinking the proxy would give up trying and respond to the controller before it timed out. That hasn't helped though. Perhaps I need to increase the controller timeout further.
Around 67% of eduroam sites in the UK use freeradius
I assumed it should work better than it is. -Mike
Hi,
This is the RedHat RPM which I believe are maintained by RedHat. Hopefully they've back ported any major security issues!
got the changelog for the 2.1.12 RPM release you are running?
It does both autentication and proxy and I do have status-check enabled. On the contraller I increased the default timeout from 2 seconds up to 8 seconds. At the same time I lowered the
2 seconds is very low for international RADIUS proxying...the traffic needs to get to the end site...and then be dealt with by the end site (which may take 1 - many seconds to actually authenticate the user once the tunnel is created). somewhere around 10 seconds is the maximum I would expect for global roaming authentication via multple proxy peers the RADIUS server is at the mercy of the controller and the remote sites... who might not be answering at all...they could just reject. I havent seen a sanity error message like that since the troublesome 2.1.7 - 2.1.9 days when the proxy code got some rewrites in places..... I wonder if your proxy.conf for the home server stuff is correct and not flipping requests between remote proxys? what does the server show/say in full debug mode with a test remote account? alan
This is my proxy.conf. The only value I've adjusted so far is response window (from 20 down to 5). Otherwise, I believe it's configured correctly to failover between the two home servers. I'll have to work on the debugs. proxy server { default_fallback = yes } home_server proxy1 { type = auth+acct ipaddr = x.x.x.x port = 1812 secret = xxxxxxxxxx response_window = 5 zombie_period = 40 revive_interval = 60 status_check = status-server check_interval = 30 num_answers_to_alive = 3 } home_server proxy2 { type = auth+acct ipaddr = x.x.x.x port = 1812 secret = xxxxxxxxxxxx response_window = 5 zombie_period = 40 revive_interval = 60 status_check = status-server check_interval = 30 num_answers_to_alive = 3 } home_server_pool EDUROAM-FTLR { type = fail-over home_server = proxy1 home_server = proxy2 } realm mydomain.ca { strip } realm LOCAL { nostrip } realm NULL { nostrip } realm DEFAULT { pool = EDUROAM-FTLR nostrip } -Mike On Wed, 5 Dec 2012, Alan Buxey wrote:
Hi,
This is the RedHat RPM which I believe are maintained by RedHat. Hopefully they've back ported any major security issues!
got the changelog for the 2.1.12 RPM release you are running?
It does both autentication and proxy and I do have status-check enabled. On the contraller I increased the default timeout from 2 seconds up to 8 seconds. At the same time I lowered the
2 seconds is very low for international RADIUS proxying...the traffic needs to get to the end site...and then be dealt with by the end site (which may take 1 - many seconds to actually authenticate the user once the tunnel is created). somewhere around 10 seconds is the maximum I would expect for global roaming authentication via multple proxy peers
the RADIUS server is at the mercy of the controller and the remote sites... who might not be answering at all...they could just reject.
I havent seen a sanity error message like that since the troublesome 2.1.7 - 2.1.9 days when the proxy code got some rewrites in places.....
I wonder if your proxy.conf for the home server stuff is correct and not flipping requests between remote proxys?
what does the server show/say in full debug mode with a test remote account?
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
home_server_pool EDUROAM-FTLR { type = fail-over home_server = proxy1 home_server = proxy2 }
I would use: type = client-port-balance to balance between the 2. (that method ensures the EAP goes to one remote server)
realm DEFAULT { pool = EDUROAM-FTLR nostrip }
hmmmm, this isnt best practice if thats all you have for throwing stuff upstream. woulf strongly recommend using unlang to validate that the user has valid realm etc and then update the request to use a realm identifier (eg eduroam) and use that in proxy.conf instead - thus you are only sending valid users upstream (and not all the random typos and junk) as the upstream servers will like you more for that - and wont be dropping requests and messing you up. alan
On 12/06/2012 10:16 AM, Alan Buxey wrote:
Hi,
home_server_pool EDUROAM-FTLR { type = fail-over home_server = proxy1 home_server = proxy2 }
I would use:
type = client-port-balance
to balance between the 2. (that method ensures the EAP goes to one remote server)
realm DEFAULT { pool = EDUROAM-FTLR nostrip }
hmmmm, this isnt best practice if thats all you have for throwing stuff upstream. woulf strongly recommend using unlang to validate that the user has valid realm etc and then update the request to use a realm identifier (eg eduroam) and use that in proxy.conf instead - thus you are only sending valid users upstream (and not all the random typos and junk) as the upstream servers will like you more for that - and wont be dropping requests and messing you up.
To expand on Alan's statement a bit here - it's possible that users are associating with your eduroam SSID and sending all kinds of nonsense (I think the best I've seen is: <space>user@domain<newline><space>user@domain</newline><repeat 3 times> ...and that the upstream RADIUS servers are not replying, which is causing you to get these dropouts. You probably want something like this: authorize { if (User-Name =~ /^([^@]*)@([-A-Z0-9]+(\\.[-A-Z0-9]+)+)$/) { # user has a valid-looking realm update request { Stripped-User-Name := "%{1}" Realm = "%{toupper:%{2}}" } } else { # malformed NAI update reply { Reply-Message := "malformed username" } reject } if (Realm == MY.REALM) { ... } else { update control { Proxy-To-Realm := DEFAULT } }
On Thu, 6 Dec 2012, Phil Mayers wrote:
On 12/06/2012 10:16 AM, Alan Buxey wrote:
Hi,
home_server_pool EDUROAM-FTLR { type = fail-over home_server = proxy1 home_server = proxy2 }
I would use:
type = client-port-balance
to balance between the 2. (that method ensures the EAP goes to one remote server)
realm DEFAULT { pool = EDUROAM-FTLR nostrip }
hmmmm, this isnt best practice if thats all you have for throwing stuff upstream. woulf strongly recommend using unlang to validate that the user has valid realm etc and then update the request to use a realm identifier (eg eduroam) and use that in proxy.conf instead - thus you are only sending valid users upstream (and not all the random typos and junk) as the upstream servers will like you more for that - and wont be dropping requests and messing you up.
To expand on Alan's statement a bit here - it's possible that users are associating with your eduroam SSID and sending all kinds of nonsense (I think the best I've seen is:
<space>user@domain<newline><space>user@domain</newline><repeat 3 times>
...and that the upstream RADIUS servers are not replying, which is causing you to get these dropouts.
You probably want something like this:
authorize { if (User-Name =~ /^([^@]*)@([-A-Z0-9]+(\\.[-A-Z0-9]+)+)$/) { # user has a valid-looking realm update request { Stripped-User-Name := "%{1}" Realm = "%{toupper:%{2}}" } } else { # malformed NAI update reply { Reply-Message := "malformed username" } reject }
if (Realm == MY.REALM) { ... } else { update control { Proxy-To-Realm := DEFAULT } }
This looks like something I should be doing but I have no idea where to insert this section. Is it in proxy.conf or somewhere else? And that last section for my own realm, would it look like this (you're converting the Realm to upper case, right?) if (Realm == MY.REALM) { update control { Proxy-To-Realm := MY.REALM } } else { update control { Proxy-To-Realm := DEFAULT } } With this configuration, I guess I don't need realm's LOCAL or NULL? -Mike
Hi,
This looks like something I should be doing but I have no idea where to insert this section. Is it in proxy.conf or somewhere else? And
in the authorize section of your virtual server, straight after the preprocess/suffix/realm module calls (ie before any real authorization action)
With this configuration, I guess I don't need realm's LOCAL or NULL?
correct - you will deal with your LOCAL realm by handling your defined realm, with eduroam you dont want to EVER authenticate a user you hasnt provided a realm - because , for your own users, they may work fine....when they are at your site....they then think/believe their configuration works...and then find it doesnt work when they go to another eduroam site...and then they'll blame that site, your site or eduroam. best policy for eduroam is ALWAYS ensure a realm is defined on the client alan
On Sun, 9 Dec 2012, Alan Buxey wrote:
Hi,
This looks like something I should be doing but I have no idea where to insert this section. Is it in proxy.conf or somewhere else? And
in the authorize section of your virtual server, straight after the preprocess/suffix/realm module calls (ie before any real authorization action)
With this configuration, I guess I don't need realm's LOCAL or NULL?
correct - you will deal with your LOCAL realm by handling your defined realm, with eduroam you dont want to EVER authenticate a user you hasnt provided a realm - because , for your own users, they may work fine....when they are at your site....they then think/believe their configuration works...and then find it doesnt work when they go to another eduroam site...and then they'll blame that site, your site or eduroam. best policy for eduroam is ALWAYS ensure a realm is defined on the client
ok, both the default and inner-tunnel, I assume? I added the section to "authorize", but the DEBUG output indicates the regular expression is rejecting a valid user. Is there someone that could confirm the RE? if (User-Name =~ /^([^@]*)@([-A-Z0-9]+(\\.[-A-Z0-9]+)+)$/) { ... [suffix] Looking up realm "domain.ca" for User-Name = "mdiggins@domain.ca" [suffix] Found realm "DEFAULT" [suffix] Adding Realm = "DEFAULT" [suffix] Proxying request from user mdiggins to realm DEFAULT [suffix] Preparing to proxy authentication request to realm "DEFAULT" ++[suffix] returns updated [eap] No EAP-Message, not doing EAP ++[eap] returns noop [files] users: Matched entry DEFAULT at line 3 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop ++? if (User-Name =~ /^([^@]*)@([-A-Z0-9]+(\\.[-A-Z0-9]+)+)$/) ? Evaluating (User-Name =~ /^([^@]*)@([-A-Z0-9]+(\\.[-A-Z0-9]+)+)$/) -> FALSE ++? if (User-Name =~ /^([^@]*)@([-A-Z0-9]+(\\.[-A-Z0-9]+)+)$/) -> FALSE ++- entering else else {...} +++[reply] returns noop +++[reject] returns reject ++- else else returns reject -Mike
On 11 Dec 2012, at 03:14, Mike Diggins <mike.diggins@mcmaster.ca> wrote:
On Sun, 9 Dec 2012, Alan Buxey wrote:
Hi,
This looks like something I should be doing but I have no idea where to insert this section. Is it in proxy.conf or somewhere else? And
in the authorize section of your virtual server, straight after the preprocess/suffix/realm module calls (ie before any real authorization action)
With this configuration, I guess I don't need realm's LOCAL or NULL?
correct - you will deal with your LOCAL realm by handling your defined realm, with eduroam you dont want to EVER authenticate a user you hasnt provided a realm - because , for your own users, they may work fine....when they are at your site....they then think/believe their configuration works...and then find it doesnt work when they go to another eduroam site...and then they'll blame that site, your site or eduroam. best policy for eduroam is ALWAYS ensure a realm is defined on the client
ok, both the default and inner-tunnel, I assume?
I added the section to "authorize", but the DEBUG output indicates the regular expression is rejecting a valid user. Is there someone that could confirm the RE?
if (User-Name =~ /^([^@]*)@([-A-Z0-9]+(\\.[-A-Z0-9]+)+)$/) { ...
Why not just use the filter_username policy in the policy.conf In filter_username in policy.conf you probably want to comment out the "reject mixed case" test and make sure your version has the fixed "realm begins with a dot" # # Realm begins with a dot # e.g. "user@.site.com" # if (User-Name =~ /@\\./) { Broken ones have: # # Realm begins with a dot # e.g. "user@.site.com" # if (User-Name !~ /@\\./) { To call filter_username policy just add "filter_username" to your authorise section. Regards Scott Armitage
On 11 December 2012 03:14, Mike Diggins <mike.diggins@mcmaster.ca> wrote:
ok, both the default and inner-tunnel, I assume?
default only - you don't want to proxy the inner bit - if the inner realm doesn't match blank or <yours>, you need to reject.
I added the section to "authorize", but the DEBUG output indicates the regular expression is rejecting a valid user. Is there someone that could confirm the RE?
if (User-Name =~ /^([^@]*)@([-A-Z0-9]+(\\.[-A-Z0-9]+)+)$/) { ...
add the case-insensitive flag i.e. end the line with $/i) { instead of your current: $/) { Kind regards, James -- James J J Hooper Senior Network Specialist, University of Bristol http://www.wireless.bristol.ac.uk --
On 12/05/2012 12:02 PM, Mike Diggins wrote:
On Wed, 5 Dec 2012, Alan Buxey wrote:
In the first instance, upgrade. There is a major security problem with 2.1.x release. Get 2.2.x onto your system asap.
This is the RedHat RPM which I believe are maintained by RedHat. Hopefully they've back ported any major security issues!
Red Hat takes security issues very seriously and we immediately addressed this issue, as we do all security issues. However simply stating it's a Red Hat RPM does not answer the question as to whether you've been updated. For RHEL customers security fixes are one of the benefits of having a valid current subscription. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Wed, 5 Dec 2012, John Dennis wrote:
On 12/05/2012 12:02 PM, Mike Diggins wrote:
On Wed, 5 Dec 2012, Alan Buxey wrote:
In the first instance, upgrade. There is a major security problem with 2.1.x release. Get 2.2.x onto your system asap.
This is the RedHat RPM which I believe are maintained by RedHat. Hopefully they've back ported any major security issues!
Red Hat takes security issues very seriously and we immediately addressed this issue, as we do all security issues.
However simply stating it's a Red Hat RPM does not answer the question as to whether you've been updated. For RHEL customers security fixes are one of the benefits of having a valid current subscription.
I have a valid current subscription and yum reports no updates for my freeradius install, so I'm assuming it's okay. I didn't want to dwell on the version though as I just upgraded from a much older release which didn't help with my problem. -Mike
Hi,
I have a valid current subscription and yum reports no updates for my freeradius install, so I'm assuming it's okay. I didn't want to dwell on the version though as I just upgraded from a much older release which didn't help with my problem.
2.1.12-4 appears to have the required TLS fix - however, not sure why 2.2.0 isnt provided now anyway - this backporting of random things doesnt help in diagnosis alan
participants (6)
-
Alan Buxey -
James JJ Hooper -
John Dennis -
Mike Diggins -
Phil Mayers -
Scott Armitage