RADIUS client-server connection across internet
I'm looking to connect a Point to Site VPN endpoint to a RADIUS server across the internet, and I'm looking for some guidance on whether my understanding is correct. My understanding is having a RADIUS server listening directly on the internet would be bad security-wise, and should not be done, is this correct? Instead, a better architecture would be to connect the RADIUS server and client over a secured channel, like a Site to Site VPN connection. Is my understanding correct here? Would it be fine to connect a client to the server over the internet directly? Is there an alternative simpler solution that I am overlooking? Thank you, -Aaron Peschel
On Oct 10, 2019, at 3:34 AM, Aaron Peschel <aaron.peschel@gmail.com> wrote:
I'm looking to connect a Point to Site VPN endpoint to a RADIUS server across the internet, and I'm looking for some guidance on whether my understanding is correct.
My understanding is having a RADIUS server listening directly on the internet would be bad security-wise, and should not be done, is this correct?
Yes.
Instead, a better architecture would be to connect the RADIUS server and client over a secured channel, like a Site to Site VPN connection.
Yes.
Is my understanding correct here? Would it be fine to connect a client to the server over the internet directly? Is there an alternative simpler solution that I am overlooking?
RADIUS over TLS. FreeRADIUS supports it, as does radsecproxy. Alan DeKok.
On Thu, Oct 10, 2019 at 09:01:08AM -0400, Alan DeKok wrote:
My understanding is having a RADIUS server listening directly on the internet would be bad security-wise, and should not be done, is this correct?
Yes.
Yes, because the communication between radius server and radius client (AP, switch,...) would be unencrypted? Or yes, because you consider the radius server to have a high attack surface and thus should never be publicly reachable, even though access to it is controlled via the clients.conf file? -HC
On Oct 11, 2019, at 9:45 AM, Hans-Christian Esperer <hc@hcesperer.org> wrote:
On Thu, Oct 10, 2019 at 09:01:08AM -0400, Alan DeKok wrote:
My understanding is having a RADIUS server listening directly on the internet would be bad security-wise, and should not be done, is this correct?
Yes.
Yes, because the communication between radius server and radius client (AP, switch,...) would be unencrypted? Or yes, because you consider the radius server to have a high attack surface and thus should never be publicly reachable, even though access to it is controlled via the clients.conf file?
Both. There is simply no reason to send RADIUS traffic unencrypted when a secure alternative exists. A RADIUS server is a critical piece of infrastructure, and should never be publicly reachable. Alan DeKok.
On Fri, Oct 11, 2019 at 10:11:42AM -0400, Alan DeKok wrote:
A RADIUS server is a critical piece of infrastructure, and should never be publicly reachable.
Hmm, if you use radius for a huge public site such as eduroam, couldn't you argue that the RADIUS server is also publicly available here? Sure, not directly via IP but through the wifi's authentication mechanism. At least, to everyone within reach of an eduroam WIFI hotspot, which happen to be quite a lot of people? I fully agree with the encryption aspect, and perhaps a (D)DoS aspect, but aside from that imho running freeradius on a public IP shouldn't be something to forbid due to security concerns, if at the same time you allow it to be used for authenticating publicly available wifis. Sure, on the public IP range there are more people than there are people with access to a wifi such as eduroam. But that's besides the point, or am I missing something here? -HC
On Oct 11, 2019, at 10:34 AM, Hans-Christian Esperer <hc@hcesperer.org> wrote:
On Fri, Oct 11, 2019 at 10:11:42AM -0400, Alan DeKok wrote:
A RADIUS server is a critical piece of infrastructure, and should never be publicly reachable.
Hmm, if you use radius for a huge public site such as eduroam, couldn't you argue that the RADIUS server is also publicly available here? Sure, not directly via IP but through the wifi's authentication mechanism. At least, to everyone within reach of an eduroam WIFI hotspot, which happen to be quite a lot of people?
Sending WiFi packets (i.e. EAP) is a bit different than sending RADIUS packets. Security isn't about doing one magical thing to make your systems secure. It's about doing every little thing to reduce the attack surface. For RADIUS, there is simply no good reason to make the servers publicly available. So they shouldn't be publicly available.
I fully agree with the encryption aspect, and perhaps a (D)DoS aspect,
Absolutely a DoS aspect.
but aside from that imho running freeradius on a public IP shouldn't be something to forbid due to security concerns, if at the same time you allow it to be used for authenticating publicly available wifis. Sure, on the public IP range there are more people than there are people with access to a wifi such as eduroam. But that's besides the point, or am I missing something here?
You can choose which security tradeoffs you make for the systems you administer. My opinion is that in general, there's no reason to make RADIUS servers publicly available. Alan DeKok.
There are a lot of little boxes you can deploy to create tunnels and encrypt this traffic. This box: https://mikrotik.com/product/hex_s Is only $60 on amazon and will do 450Mbps/40kpps of AES-128 in an IPsec tunnel. Absolutely agree with Alan, you should tunnel this with very few or no exceptions. schu On 10/11/19 7:38 AM, Alan DeKok wrote:
On Oct 11, 2019, at 10:34 AM, Hans-Christian Esperer <hc@hcesperer.org> wrote:
On Fri, Oct 11, 2019 at 10:11:42AM -0400, Alan DeKok wrote:
A RADIUS server is a critical piece of infrastructure, and should never be publicly reachable. Hmm, if you use radius for a huge public site such as eduroam, couldn't you argue that the RADIUS server is also publicly available here? Sure, not directly via IP but through the wifi's authentication mechanism. At least, to everyone within reach of an eduroam WIFI hotspot, which happen to be quite a lot of people? Sending WiFi packets (i.e. EAP) is a bit different than sending RADIUS packets.
Security isn't about doing one magical thing to make your systems secure. It's about doing every little thing to reduce the attack surface.
For RADIUS, there is simply no good reason to make the servers publicly available. So they shouldn't be publicly available.
I fully agree with the encryption aspect, and perhaps a (D)DoS aspect, Absolutely a DoS aspect.
but aside from that imho running freeradius on a public IP shouldn't be something to forbid due to security concerns, if at the same time you allow it to be used for authenticating publicly available wifis. Sure, on the public IP range there are more people than there are people with access to a wifi such as eduroam. But that's besides the point, or am I missing something here? You can choose which security tradeoffs you make for the systems you administer. My opinion is that in general, there's no reason to make RADIUS servers publicly available.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
In systems like eduroam is expected that yes, the local wireless infrastructure (or usually just the controller's) can talk to the RADIUS server, just add is the case for broadband routers we they can all talk to. But on the internet public facing side is expected that the RADIUS server only has remote access to/from the national radius proxy servers for that federation. Obviously that changes with RADSEC but then it's all better encrypted so ... For local attacks, most wireless vendors have pretty good controls to stop/limit attacks (eg password ones) in the EAP authentication channel alan
Aaron Peschel <aaron.peschel@gmail.com> wrote:
I'm looking to connect a Point to Site VPN endpoint to a RADIUS server across the internet, and I'm looking for some guidance on whether my understanding is correct.
My understanding is having a RADIUS server listening directly on the internet would be bad security-wise, and should not be done, is this correct?
Depends on what protocol is running inside the RADIUS session. If it is a naked CHAP or something like that, then this would not be advisable. If it is an EAP session carrying an encrypted tunnel, we do this all the time with federated authentication systems such as eduroam, which is safe as long as certificate validation is performed. (If you only perform validation on one side and the client is not validated, then extra hardening of the RADIUS server is probably in order... we actually have an FreeRADIUS process instance dedicated to receiving EAP sessions which runs at lower privilege and aggressively strips all unnecessary TLVs from a session before allowing it through to the back end.)
Instead, a better architecture would be to connect the RADIUS server and client over a secured channel, like a Site to Site VPN connection.
This design is also in use. Some NASes/clients support RADSec for end-to-end certificate-validated TLS tunnels to carry RADIUS traffic. Other devices support IPSec for all control plane traffic including RADIUS. Another option if your architecture allows for it is to have the client talk to a local RADIUS relay that supports RADSEC and can proxy the RADIUS request over a TLS tunnel.
participants (6)
-
Aaron Peschel -
Alan Buxey -
Alan DeKok -
Brian Julin -
Hans-Christian Esperer -
Matthew Schumacher