We've run into a potential problem with our FreeRadius setup. We currently use per-client keys for security. We have begun testing dynamic DNS updates and have run into the problem of having the radius server fail to start because an entry in clients.conf refers to a DNS entry which doesn't exist. We could use only IP addresses in clients.conf, but that means we can't have dynamic addresses for clients. We could also use per-subnet keys but we really want to keep the increase in security afforded by having unique keys for each host. My question is two-fold. One, does anybody know of a workaround with the current code base I haven't thought of? Two, what sorts of requirements should I include if I code up patch to add this feature? Certainly I would guess that there would have to be a way to keep the current functionality where responding to authentication requests would not require any DNS requests. But in our dynamic DNS case, I would like the server to look up the reverse DNS entry of the source IP address on an incoming request and use that result to determine which clients.conf entry to use. This would mean caching the FQDN names from the clients.conf file somewhere and then searching that list with the results of the DNS query. Or alternatively doing something more sophisticated such as determining the key to use based on attributes in the request itself. Any feedback on the direction I should take before I start trying to code something up would be appreciated. Thanks in advance, -David Mitchell -- ----------------------------------------------------------------- | David Mitchell (mitchell@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | -----------------------------------------------------------------
David Mitchell wrote:
We've run into a potential problem with our FreeRadius setup. We currently use per-client keys for security. We have begun testing dynamic DNS updates and have run into the problem of having the radius server fail to start because an entry in clients.conf refers to a DNS entry which doesn't exist. We could use only IP addresses in clients.conf, but that means we can't have dynamic addresses for clients. We could also use per-subnet keys but we really want to keep the increase in security afforded by having unique keys for each host.
Is it difficult to configure the clients with static IP's? If so, why?
My question is two-fold. One, does anybody know of a workaround with the current code base I haven't thought of? Two, what sorts of requirements should I include if I code up patch to add this feature? Certainly I would guess that there would have to be a way to keep the current functionality where responding to authentication requests would not require any DNS requests. But in our dynamic DNS case, I would like the server to look up the reverse DNS entry of the source IP address on an incoming request and use that result to determine which clients.conf entry to use.
This would mean that an attacker can send you packets where the source IP has no DNS entry. The RADIUS server would then try to resolve DNS, and fail, potentially causing a DoS attack. Remember, it has to do the right thing both for the cases you want it to work, AND for the cases where you don't want it to die.
This would mean caching the FQDN names from the clients.conf file somewhere and then searching that list with the results of the DNS query. Or alternatively doing something more sophisticated such as determining the key to use based on attributes in the request itself. Any feedback on the direction I should take before I start trying to code something up would be appreciated. Thanks in advance,
I would suggest having a two-level client definition. One, define a network/mask for such dynamic clients. Two, define a mapping of secrets, based on the attributes in the packet. Alan DeKok.
Alan DeKok wrote:
David Mitchell wrote:
We've run into a potential problem with our FreeRadius setup. We currently use per-client keys for security. We have begun testing dynamic DNS updates and have run into the problem of having the radius server fail to start because an entry in clients.conf refers to a DNS entry which doesn't exist. We could use only IP addresses in clients.conf, but that means we can't have dynamic addresses for clients. We could also use per-subnet keys but we really want to keep the increase in security afforded by having unique keys for each host.
Is it difficult to configure the clients with static IP's? If so, why?
We do manage the clients now with static IP addresses, but using dynamic addresses gives us additional flexibility with respect to managing our address space. It's not a mandatory requirement for us, but I've been asked to look into it since I'm the most familiar with the code.
My question is two-fold. One, does anybody know of a workaround with the current code base I haven't thought of? Two, what sorts of requirements should I include if I code up patch to add this feature? Certainly I would guess that there would have to be a way to keep the current functionality where responding to authentication requests would not require any DNS requests. But in our dynamic DNS case, I would like the server to look up the reverse DNS entry of the source IP address on an incoming request and use that result to determine which clients.conf entry to use.
This would mean that an attacker can send you packets where the source IP has no DNS entry. The RADIUS server would then try to resolve DNS, and fail, potentially causing a DoS attack.
That's a good point. Perhaps it would be possible to handle the DNS request in a non-blocking manner? It would make the implementation trickier but should prevent any bogus requests from blocking legitimate ones.
Remember, it has to do the right thing both for the cases you want it to work, AND for the cases where you don't want it to die.
This would mean caching the FQDN names from the clients.conf file somewhere and then searching that list with the results of the DNS query. Or alternatively doing something more sophisticated such as determining the key to use based on attributes in the request itself. Any feedback on the direction I should take before I start trying to code something up would be appreciated. Thanks in advance,
I would suggest having a two-level client definition. One, define a network/mask for such dynamic clients. Two, define a mapping of secrets, based on the attributes in the packet.
That should be fairly straightforward, possibly at the expense of making the client.conf syntax more complex. As long as the clients can all be configured to get something unique yet consistent into the attribute list of request packets, it would probably be a pretty flexible tool. Thanks for the feedback, that helps give me some guidance on what direction to start out in as I look into how to implement this. -David Mitchell
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- ----------------------------------------------------------------- | David Mitchell (mitchell@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | -----------------------------------------------------------------
Hi, all On Fri, 9 Nov 2007, Alan DeKok wrote:
David Mitchell wrote:
We've run into a potential problem with our FreeRadius setup. We currently use per-client keys for security. We have begun testing dynamic DNS updates and have run into the problem of having the radius server fail to start because an entry in clients.conf refers to a DNS entry which doesn't exist. We could use only IP addresses in clients.conf, but that means we can't have dynamic addresses for clients. We could also use per-subnet keys but we really want to keep the increase in security afforded by having unique keys for each host.
Is it difficult to configure the clients with static IP's? If so, why?
I imagine that wifi hubs on Verizon DSL would have issues with this, because they don't have static IPs.
This would mean that an attacker can send you packets where the source IP has no DNS entry. The RADIUS server would then try to resolve DNS, and fail, potentially causing a DoS attack.
Attackers usually have no choice of whether they have reverse DNS or not. In the case where they do have control over reverse DNS, (and you do DNS 'authentication checking'), then attack is much worse because they can make the PTR be a.b.c.d.e.f.g.h.i.j.k.l.m.... (256 characters) and that can take a long, long time to resolve to an IP address.
Remember, it has to do the right thing both for the cases you want it to work, AND for the cases where you don't want it to die.
I suggest a custom module to configure the clients in the server dynamically, and then a way to update the client database (rather just like some dynamic DNS is updated with a http query)
I would suggest having a two-level client definition. One, define a network/mask for such dynamic clients. Two, define a mapping of secrets, based on the attributes in the packet.
I can't speak for this poster, but that won't work for the guy using certain providers' DSL lines. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
participants (3)
-
Alan DeKok -
David Mitchell -
Dean Anderson