can you internally proxy a request more than once?
Hi, I have been using FreeRADIUS to authenticate visitors onto a wireless network using LDAP against Active Directory. I now need to also deploy eduroam. I thought it would be sensible to do this as two separate virtual servers, so I created a new minimal 'default' server that proxies to a 'visitors' or 'eduroam' virtual server based on the wireless SSID, which the wireless NAS adds to an attribute in the Access-Request. The default server sets the Proxy-To-Realm attribute in the list of control items. The Realm then maps to a home_server in proxy.conf which has an associated virtual server e.g. home_server virtual_server_for_eduroam { type =auth+acct virtual_server = eduroam } home_server_pool virtual_server_for_eduroam_pool { home_server = virtual_server_for_eduroam } realm EDUROAM_VIRTUAL_SERVER { pool = virtual_server_for_eduroam_pool } The 'visitors' virtual server works fine. The 'eduroam' virtual server proxies the Access-Request to LOCAL or our National RADIUS Proxy Servers depending on whether the realm in the User-Name attribute is our realm or not. Local authentications are performed against Active Directory, and so we are using PEAP-MS-CHAPv2. For local authentications the inner MS-CHAPv2 authentications are proxied to the 'inner-tunnel' virtual server. If (for testing) I configure clients.conf so that Access-Requests from the wireless NAS are always sent to the 'eduroam' virtual server, then it works fine. The 'eduroam' virtual server doesn't work if it is called from the new 'default' server using internal proxying. In that case I get an error saying "Multiple levels of TLS nesting is invalid". I'm running FreeRADIUS 2.1.11. I may not have provided enough detail, but am I doing something that obviously won't work? I don't know if it's possible to internally proxy a request more than once, e.g. to two different virtual servers. If it isn't possible, do I have any other options? Would a solution be to make the virtual servers listen on two different IP addresses, and configure the NAS to use a different RADIUS server IP address for each SSID? Alternatively, could the NAS continue to send all RADIUS packets to one IP address, and the default server proxy to virtual servers listening on different IP addresses? Thanks in advance of any help you can give, Have a good weekend, Mark. -- Scanned by iCritical.
Not sure, but you should consider running non-virtual instances (not that hard to do) and using privilage separation such that there is little potential for exposure of your internal authentication structure or internally-utilized crypto material to an externally presented service. Also, it is possible to get your local users to have local privileges when using their eduroam-formatted credentials on the eduroam SSID, just a bit tricky. Here we run 4 instances for eduroam, two for IDP and two for SP (one each 3.0 radsec proxy/filter and one 2.x internal.) Only the internal sessions have any interaction with LDAP/SQL/AD. ________________________________ From: freeradius-users-bounces+bjulin=clarku.edu@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku.edu@lists.freeradius.org] On Behalf Of mark.leese@stfc.ac.uk Sent: Friday, March 23, 2012 10:13 AM To: freeradius-users@lists.freeradius.org Subject: can you internally proxy a request more than once? Hi, I have been using FreeRADIUS to authenticate visitors onto a wireless network using LDAP against Active Directory. I now need to also deploy eduroam. I thought it would be sensible to do this as two separate virtual servers, so I created a new minimal 'default' server that proxies to a 'visitors' or 'eduroam' virtual server based on the wireless SSID, which the wireless NAS adds to an attribute in the Access-Request. The default server sets the Proxy-To-Realm attribute in the list of control items. The Realm then maps to a home_server in proxy.conf which has an associated virtual server e.g. home_server virtual_server_for_eduroam { type =auth+acct virtual_server = eduroam } home_server_pool virtual_server_for_eduroam_pool { home_server = virtual_server_for_eduroam } realm EDUROAM_VIRTUAL_SERVER { pool = virtual_server_for_eduroam_pool } The 'visitors' virtual server works fine. The 'eduroam' virtual server proxies the Access-Request to LOCAL or our National RADIUS Proxy Servers depending on whether the realm in the User-Name attribute is our realm or not. Local authentications are performed against Active Directory, and so we are using PEAP-MS-CHAPv2. For local authentications the inner MS-CHAPv2 authentications are proxied to the 'inner-tunnel' virtual server. If (for testing) I configure clients.conf so that Access-Requests from the wireless NAS are always sent to the 'eduroam' virtual server, then it works fine. The 'eduroam' virtual server doesn't work if it is called from the new 'default' server using internal proxying. In that case I get an error saying "Multiple levels of TLS nesting is invalid". I'm running FreeRADIUS 2.1.11. I may not have provided enough detail, but am I doing something that obviously won't work? I don't know if it's possible to internally proxy a request more than once, e.g. to two different virtual servers. If it isn't possible, do I have any other options? Would a solution be to make the virtual servers listen on two different IP addresses, and configure the NAS to use a different RADIUS server IP address for each SSID? Alternatively, could the NAS continue to send all RADIUS packets to one IP address, and the default server proxy to virtual servers listening on different IP addresses? Thanks in advance of any help you can give, Have a good weekend, Mark. -- Scanned by iCritical.
On 03/23/2012 04:02 PM, Brian Julin wrote:
Not sure, but you should consider running non-virtual instances (not that hard to do) and using privilage separation such that there is little potential for exposure of your internal authentication structure or internally-utilized crypto material to an externally presented service.
I'm curious about what you mean here. I don't see the difference between a single server performing attribute filter & auth, versus two separate processes. Can you explain what threat model you think this addresses?
Phil Mayers [p.mayers@imperial.ac.uk] wrote
I'm curious about what you mean here. I don't see the difference between a single server performing attribute filter & auth, versus two separate processes.
Can you explain what threat model you think this addresses?
It limits the exposed fuzzable surface. Any vulnerabilities present or introduced in the low level RADIUS packet processing compromise only the external server. The packets that reach the internal server post-filter have been cleanly regenerated. The option also exists at that point to place the external server on an entirely different host, for DoS mitigation. You still have some unnecessary code surface exposure what with EAP being processed on the internal server (unless you were to manage to somehow get tunneling of unwrapped MSCHAP working and do the EAP unwrap on the external server.) Normally I wouldn't be quite so bug-paranoid, but RADIUS is tied pretty tightly to the most security-sensitive and mission-critical systems we have. (As an aside, while the virtual server functionality is very useful when it comes to providing an integrated inner/outer tunnel solution, I've found it much more convenient to administer discrete usage cases with individual instances. Then you can do work on one server without worrying that a change will somehow have unintended consequences on other services when you reload the config.)
On 03/24/2012 10:26 PM, Brian Julin wrote:
Can you explain what threat model you think this addresses?
It limits the exposed fuzzable surface. Any vulnerabilities present or introduced in the low level RADIUS packet processing compromise only the external server. The packets that reach the internal server post-filter have been cleanly regenerated. The option also exists at that point to place the external server on an entirely different host, for DoS mitigation.
Ok, interesting. I'm not entirely sure I buy that it ensures only the outer server is affected; once compromised, the outer server can be used to send arbitrary UDP packets to the inner server since the sockets are already open. But I guess the same could be said of any perimeter defence architecture. It does of course allow you to lock the outer server down considerably tighter I guess, since it has a much lower functionality; run under a separate UID, SELinux-confined, chroot-ed, whatever.
You still have some unnecessary code surface exposure what with EAP being processed on the internal server (unless you were to manage to somehow get tunneling of unwrapped MSCHAP working and do the EAP unwrap on the external server.)
If you were going to do that, I would strongly recommend *not* transforming EAP-MSCHAPv2 into plain MSCHAP; the code that does this is hairy. But I guess you could limit all the TLS-based processing (and thus attack surface) to the outer server; but of course then the outer server must be able to access your private key, so you've traded TLS vulnerability potential for private key access potential.
Normally I wouldn't be quite so bug-paranoid, but RADIUS is tied pretty tightly to the most security-sensitive and mission-critical systems we have.
As in... what? It authenticates against your password database? I would have thought that all the internet-facing web properties would be rather more of a risk than radius requests coming from hosts with a shared secret. I'm wondering if you would feel all this was necessary if RadSec were in use?
(As an aside, while the virtual server functionality is very useful when it comes to providing an integrated inner/outer tunnel solution, I've found it much more convenient to administer discrete usage cases with individual instances. Then you can do work on one server without worrying that a change will somehow have unintended consequences on other services when you reload the config.)
This is something that we *do* use. Basically I have separate processes for wired macauth, local wireless/wired 802.1x, eduroam visited/SP, eduroam home/IdP, vpn mschap and so on. The main reason is fault isolation; a long while ago (several years now) the occasional crash bug would surface in either the TLS or SQL code, and it was useful for this to be confined. It also lets you control resource usage a bit better without having to define copies of the SQL module - in the top of each "instance.conf" file I have: svopts { num_sql_socks = x outer_status_port = 18nnn inner_status_port = 18mmm num_threads = y } ...then in e.g. sql.conf I have: sql { num_sql_socks = ${svopts.num_sql_socks} } ...and each process starts up with a pool size appropriate to its needs.
Phil Mayers wrote:
I'm not entirely sure I buy that it ensures only the outer server is affected; once compromised, the outer server can be used to send arbitrary UDP packets to the inner server since the sockets are already open. But I guess the same could be said of any perimeter defence architecture.
True, it's just one layer.
You still have some unnecessary code surface exposure what with EAP being processed on the internal server (unless you were to manage to somehow get tunneling of unwrapped MSCHAP working and do the EAP unwrap on the external server.)
If you were going to do that, I would strongly recommend *not* transforming EAP-MSCHAPv2 into plain MSCHAP; the code that does this is hairy.
In an exercise of folly I did try that. Then I tried letting it rewrap the EAP, but it didn't seem up for the task. Left it for future dull days.
Normally I wouldn't be quite so bug-paranoid, but RADIUS is tied pretty tightly to the most security-sensitive and mission-critical systems we have.
As in... what? It authenticates against your password database? I would have thought that all the internet-facing web properties would be rather more of a risk than radius requests coming from hosts with a shared secret.
Well, I shouldn't go into that on a public forum. As far as SSO web services, there are things I'm responsible for, and things I am not. I don't worry too much about the latter :-)
I'm wondering if you would feel all this was necessary if RadSec were in use?
It is. Some decade from now it is also possible RadSec within eduroam will migrate to a more (PKI-based) peer-to-peer model, so if anything that's more hosts we'd be talking to.
(As an aside, while the virtual server functionality is very useful when it comes to providing an integrated inner/outer tunnel solution, I've found it much more convenient to administer discrete usage cases with individual instances. Then you can do work on one server without worrying that a change will somehow have unintended consequences on other services when you reload the config.)
This is something that we *do* use. Basically I have separate processes for wired macauth, local wireless/wired 802.1x, eduroam visited/SP, eduroam home/IdP, vpn mschap and so on.
Same here, but the eduroam instances are each split into two (a 3.0 for radsec/filter and a system stock version for the internal.) The SP instance also allows our users to gain the same privileges (and be subject to the same NAC criteria) as they would on the normal SSID. That way they can configure for eduroam and never have to mess with changing profiles, but it also means that a crash of the instance that does this local authentication will strand my users and then the pitchfork closets will be raided, so I'd rather any problems that might occur when a guest makes us talk to the federation were isolated to guests only.
The main reason is fault isolation; a long while ago (several years now) the occasional crash bug would surface in either the TLS or SQL code, and it was useful for this to be confined.
This is the most tangible benefit, yes. Helps me sleep much sounder.
mark.leese@stfc.ac.uk wrote:
I may not have provided enough detail, but am I doing something that obviously won’t work? I don’t know if it’s possible to internally proxy a request more than once, e.g. to two different virtual servers.
It's not. It will likely work (eventually) in 3.0. The 2.1 code base just isn't suitable for multiple proxying.
If it isn’t possible, do I have any other options? Would a solution be to make the virtual servers listen on two different IP addresses, and configure the NAS to use a different RADIUS server IP address for each SSID?
That works, too.
Alternatively, could the NAS continue to send all RADIUS packets to one IP address, and the default server proxy to virtual servers listening on different IP addresses?
That works, too. Alan DeKok.
On 03/23/2012 02:12 PM, mark.leese@stfc.ac.uk wrote:
isn’t possible, do I have any other options? Would a solution be to make the virtual servers listen on two different IP addresses, and configure the NAS to use a different RADIUS server IP address for each SSID?
That is the common solution, based on what I've seen. It's what we do.
participants (4)
-
Alan DeKok -
Brian Julin -
mark.leese＠stfc.ac.uk -
Phil Mayers