can you internally proxy a request more than once?

[Phil Mayers]

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.