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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
