Is there a way to force a silent drop of a packet instead of sending Access-Reject ? I am interested in both doing this through configuration file(s) and doing this from a module (e.g. with some special return code or attribute). On a somewhat related note: is there way to make FreeRADIUS server drop/reject all incoming packets without Message-Authenticator the same way it does this for packets with invalid/incorrect value in that attribute ? Preferably through configuration, without changes in code. -- Andriy Gapon
Andriy Gapon <avg@icyb.net.ua> wrote:
Is there a way to force a silent drop of a packet instead of sending Access-Reject ?
No.
On a somewhat related note: is there way to make FreeRADIUS server drop/reject all incoming packets without Message-Authenticator the same way it does this for packets with invalid/incorrect value in that attribute ? Preferably through configuration, without changes in code.
$ man users DEFAULT Message-Authenticator !* 0x00, Auth-Type := Reject Alan DeKok.
Alan, thank you very much for your reply. Sorry if my reply breaks message threading for you - I am replying based on the web-archive as I don't receive this list by email. Alan DeKok wrote:
Andriy Gapon <avg at icyb.net.ua> wrote:
Is there a way to force a silent drop of a packet instead of sending Access-Reject ?
No.
On a somewhat related note: is there way to make FreeRADIUS server drop/reject all incoming packets without Message-Authenticator the same way it does this for packets with invalid/incorrect value in that attribute ? Preferably through configuration, without changes in code.
$ man users
DEFAULT Message-Authenticator !* 0x00, Auth-Type := Reject
It seems that I was a little bit confused in my assumptions about dropping and rejecting. Do I understand correctly now that a packet is dropped only if rad_recv() returns NULL and in all other cases reply is sent ? If this is correct, then a packet is dropped only in two cases related to Message-Authenticator - (1) if length of this attribute is invalid; (2) if EAP-Message is present but Message-Authenticator is not. I think that it would be nice if list of such situations could be configurable and extensible. For example, there are some RADIUS-related solutions/drafts out there that require requests being silently dropped if they don't have Message-Authenticator or have incorrect value of Message-Authenticator. Neither can be done now with FreeRADIUS without modifying its source code. Please note that I am talking now only about dropping requests, not rejecting them. Rejecting is very easy as your example shows (thanks a lot for it!). Maybe the following would be good enhancements (if they are not too hard to implement): 1. have a configurable list of attributes that require Message-Authenticator (so that I could put Message-Digest there, for example, in addition to EAP-Message) 2. have a configuration knob that could tell "drop all incoming messages without Message-Authenticator" 3. do Message-Authenticator value validation in rad_recv() (this could be configurable too, defaulting to current behavior) Even more flexible would be a capability to silently drop packet in any (auth) module, but I think that it would require a lot of work. BTW, there is a bug report in FreeRADIUS bugzilla related to this (it's not mine): http://bugs.freeradius.org/show_bug.cgi?id=313 What do you think about such extensions ? Will code contributions be welcomed for them ? -- Andriy Gapon
Andriy Gapon <avg@icyb.net.ua> wrote:
I think that it would be nice if list of such situations could be configurable and extensible.
No. Dropping the packet is a security decision and there is no reason to make it configurable.
For example, there are some RADIUS-related solutions/drafts out there that require requests being silently dropped if they don't have Message-Authenticator or have incorrect value of Message-Authenticator. Neither can be done now with FreeRADIUS without modifying its source code.
Then we will modify the source code to add those cases, like we did when EAP support was added.
1. have a configurable list of attributes that require Message-Authenticator (so that I could put Message-Digest there, for example, in addition to EAP-Message)
Then people will edit the list to break the server. No.
2. have a configuration knob that could tell "drop all incoming messages without Message-Authenticator"
That could be done.
3. do Message-Authenticator value validation in rad_recv() (this could be configurable too, defaulting to current behavior)
No. It's a perfomance issue.
Even more flexible would be a capability to silently drop packet in any (auth) module, but I think that it would require a lot of work. BTW, there is a bug report in FreeRADIUS bugzilla related to this (it's not mine): http://bugs.freeradius.org/show_bug.cgi?id=313
It's a bad idea, it violates the RFC's, and it makes your network more unstable. Alan DeKok.
Alan, thanks your answers. You give quite good reasons, but somehow they don't satisfy me :-) (they don;t have to, of course). If you don't mind, let me ask you some a little bit more general questions: 1. What is FreeRADIUS (as a project) general feeling and attitude towards entities that use FreeRADIUS as a RADIUS server in conjunction with their own private (closed-source) modules ? 2. Does FreeRADIUS (as a project) trust such entities to know what they are doing ? 3. Does FreeRADIUS (as a project) mind giving such entities more control over FreeRADIUS server behavior either through configuration options or through module interface, so that they don't have to modify "main" source code to achieve what they want ? And it doesn't, then to what degree ? I feel that discussing technical details and possibilities may be without any merit if I don't understand your and other project members opinion on the above topics. -- Andriy Gapon
Andriy Gapon <avg@icyb.net.ua> wrote:
1. What is FreeRADIUS (as a project) general feeling and attitude towards entities that use FreeRADIUS as a RADIUS server in conjunction with their own private (closed-source) modules ?
So long as you're following the GPL, it's your business. This usually means that if you redistribute the binaries, your modules must also be distributed under the GPL/.
2. Does FreeRADIUS (as a project) trust such entities to know what they are doing ?
If you're running your own code on your own systems, it's not our problem.
3. Does FreeRADIUS (as a project) mind giving such entities more control over FreeRADIUS server behavior either through configuration options or through module interface, so that they don't have to modify "main" source code to achieve what they want ?
If you want to control the server, you have source. You can edit it yourself. The issue appears to be that you want the server to do something special in your site, and you also want to force those patches back to FreeRADIUS. That's a problem.
And it doesn't, then to what degree ?
We'll accept patches that make sense, and which are useful to a wide audience. If the patches you send in are useful only to you, then they probably won't go in. Alan DeKok.
Alan DeKok wrote:
[snip]
So long as you're following the GPL, it's your business. [snip]
If you want to control the server, you have source. You can edit it yourself.
The issue appears to be that you want the server to do something special in your site, and you also want to force those patches back to FreeRADIUS. That's a problem. [snip] We'll accept patches that make sense, and which are useful to a wide audience. If the patches you send in are useful only to you, then they probably won't go in.
Alan, thank you for the answers. This is a very reasonable approach. I'll try to do some work/coding now and then I'll get back here to continue arguments about what is useful to general FreeRADIUS audience and what is my whim :-) Thanks again! -- Andriy Gapon
participants (2)
-
Alan DeKok -
Andriy Gapon