On Mar 19, 2025, at 6:11 AM, David Herselman via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I'd like to thank everyone that contributes to the RADIUS standards and particularly FreeRADIUS developers for their tireless efforts. I realise that the Blast RADIUS protocol vulnerability (CVE-2024-3596) could have been avoided should the standards have adopted recommendations put forward in the past, it must be very frustrating to work on things to have users asking questions more than a year later.
I was pointing out the problem in 1997. I wrote RFC 5080 in 2007 which suggested that clients always send Message-Authenticator. To my knowledge, FreeRADIUS was the only implementation which did that. So it's a bit more than "a year later". :(
We're diligently upgrading vendor equipment to support message authenticator, where CheckPoint, FortiNet and MikroTik have recently backported support to LTS versions. Whilst security devices (eg firewalls) have unique client definitions to match fixed IPs, we have approximately 1500+ routers that live in non-publicly accessible management subnets, although these are arguably still public as they are reachable from client environments. The main issue with these is that they connect via LTE mobile APNs.
There's a simple answer here: don't do that. You're allowing random IPs on the Internet to send UDP traffic to your RADIUS server. The original design of RADIUS was that both clients and servers would have fixed IPs. So this use-cases is outside of the normal situation. The better thing to do is to use RADUUS/TLS, You can then authenticate the client by a certificate, independent of IP address. The only downside is that RADIUS/TLS is only about 12 years old, so many NAS vendors don't implement it.
We configured client prefix definitions that cover hundreds of routes (eg 198.19.200.0/23), where we can't simply blindly upgrade these in large batches, requiring client scheduled maintenance windows. Due to how mobile operators assign IPs out of pools for the APNs, it's not possible for us to configure individual client statements.
The correct approach is RADIUS/TLS, or even IPSec.
Any possibility of there being an additional option to augment the auto setting? So that each individual IP in a defined range is flipped to enforcing message-authenticator?
Sure. Send a patch. :)
Let me try to explain in way of example, let's say we have a client configured as follows: client managed.routers { ipaddr = 198.19.200.0 netmask = 23 secret = **************** nastype = cisco require_message_authenticator = auto-per-IP }
We're hoping that other networks would benefit from an option whereby FreeRADIUS would possibly use a bloom filter to mark individual IPs in those subnets to requiring message authenticator should they receive a request which includes the M-A attribute. We would actually prefer FreeRADIUS to additionally flip on enforcement should a request contains the M-A attribute, irrespective of whether or not it's the first packet to arrive after FreeRADIUS was restarted.
You have the source, and can make that change. My concern with such behavior is that it's likely to be very site-specific, and of less use to anyone else. Remember, FreeRADIUS doesn't run on just your own network. That means any feature which goes in has to work for everyone, everywhere, all of the time.
This way technicians could schedule and upgrade equipment and thereafter enforce M-A validation without having to reach out to people that have access to restart FreeRADIUS thereafter.
What you want here is a way to dynamically change that flag in a running server. That's possible, but requires code changes.
Any suggestions from anyone that's walked this road before? Have we completely missed the boat or simply unaware of clever ways to handle this scenario?
The concern here is that this is an unusual use-case, and one which is known to be problematic. For clients with network/mask, it's somewhat reasonable to make "require_message_authenticator = auto" to mean "auto per IP". Except what happens then the network changes? You have an "old" machine at IP X, and a "new" machine at IP Y. After some network change, they could switch IP addresses, Since IP address Y was sending Message-Authenticator, the server will require it. But that IP is now being used by "old" machine, which doesn't support it. And the network breaks. You then decide, "OK, we'll filter by some other field, like Called-Station-Id, or NAS-Identifier". Except replacing a machine changes its MAC address and thus Called-Station-Id. Changing the configuration of firmware image could change NAS-Identifier. Because, implementations are "inventive". All of those choices are ad hoc ways to identity a particular client. They might work, but they're not guaranteed to work. Or, you could identify a client with a client certificate. Which was designed to identity things. So... it's RADIUS. Almost anything you want to do is a hack, Almost anything you want to do might work, or might not, or might break randomly "just 'cause". But all of that likely doesn't matter. The routers aren't proxies, and the RADIUS packets won't contain Proxy-State. So just set "limit_proxy_state = yes" in the configuration, and go for coffee. That will stop the attack, even if the packets don't contain Message-Authenticator. If the routers do send Proxy-State, then you're out of luck. You are 100% vulnerable without Message-Authenticator. No amount of setting "auto" flags, or "auto-by-IP" flags will help you. The packets can be forged, and sending UDP over the Internet is a major problem. Alan DeKok.