On-line debugging tool
I've put a debugging tool online at: http://networkradius.com/ Click on the "debug tool" link on the left, under "News". The page contains instructions for how to get debug output into the form. The main purpose of the tool is to teach people what is important in the debug output, and what can be safely ignored. Important data is highlighted (red, yellow, blue), and less important data is de-emphasized (text is light grey). Each packet received / sent is put into its own text box. This separation allows you to quickly find the output for just one packet out of many. The tool is in "beta", and likely produces less useful output when the server is proxying packets. It's best used to debug local authentication issues. We hope you find the web tool useful. Please send any feedback privately to me. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
I've put a debugging tool online at:
Click on the "debug tool" link on the left, under "News". The page contains instructions for how to get debug output into the form.
Is there a plan to add to FreeRADIUS a debug output mangling option? So things like Cleartext-Password and User-Password are obscured. For example, you get the user to run FreeRADIUS with '-XO', then just before printing to the screen the value of the 'secret' attributes are md5'd and the hashes are shown instead (should be a constant, unless there is actually a mismatch). Of course you could have a '-o attr1,attr2' to protect other attributes at runtime too. Only something to add to the wishlist. :) Cheers -- Alexander Clouter .sigmonster says: Straw? No, too stupid a fad. I put soot on warts.
Alexander Clouter wrote:
Is there a plan to add to FreeRADIUS a debug output mangling option? So things like Cleartext-Password and User-Password are obscured.
Send a patch. ;)
For example, you get the user to run FreeRADIUS with '-XO', then just before printing to the screen the value of the 'secret' attributes are md5'd and the hashes are shown instead (should be a constant, unless there is actually a mismatch). Of course you could have a '-o attr1,attr2' to protect other attributes at runtime too.
The problem is that it's hard to do. The passwords can be used in multiple places, so knowing *when* to mangle them is awkward. We could do a few simple things like not print client secrets or User-Passwords from the received packets. But anything past that quickly becomes very, very, difficult. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Is there a plan to add to FreeRADIUS a debug output mangling option? So things like Cleartext-Password and User-Password are obscured.
Send a patch. ;)
Yeah yeah...however as you are not ACK'ing my gtc/ldap patches it's hardly a motivator to contribute :-/ *sigh* ...alternatively we create a FreeRADIUS debug equilivent to the kernels 'checkpatch.pl' which would be better still I would argue. Then no need to worry about privacy of the spiel outputed, plus we *all* can then add extra clauses/checks ourselves as we find them. This means the checking tool comes with FreeRADIUS. It can also gives the users something to paste to the mailing list incase of problems (although it probably be less useful than the raw '-X' output, and if they are including anything they might aswell give us the full spiel).
For example, you get the user to run FreeRADIUS with '-XO', then just before printing to the screen the value of the 'secret' attributes are md5'd and the hashes are shown instead (should be a constant, unless there is actually a mismatch). Of course you could have a '-o attr1,attr2' to protect other attributes at runtime too.
The problem is that it's hard to do. The passwords can be used in multiple places, so knowing *when* to mangle them is awkward.
We could do a few simple things like not print client secrets or User-Passwords from the received packets. But anything past that quickly becomes very, very, difficult.
I was not really thinking past the common ones, however thinking about things more so, I actually prefer the checkpatch.pl-esque approach, then we can all contribute and fix things :) Cheers -- Alexander Clouter .sigmonster says: I'm so broke I can't even pay attention.
Alexander Clouter wrote:
Yeah yeah...however as you are not ACK'ing my gtc/ldap patches it's hardly a motivator to contribute :-/ *sigh*
I've looked at them. Now that 2.1.x is "stable", I am less worried about pulling them into a 2.2.x branch. i.e. they should be applied in the coming weeks, along with a lot of other patches.
...alternatively we create a FreeRADIUS debug equilivent to the kernels 'checkpatch.pl' which would be better still I would argue. Then no need to worry about privacy of the spiel outputed, plus we *all* can then add extra clauses/checks ourselves as we find them.
Sure..
This means the checking tool comes with FreeRADIUS. It can also gives the users something to paste to the mailing list incase of problems (although it probably be less useful than the raw '-X' output, and if they are including anything they might aswell give us the full spiel).
Yes. And the tool could *also* take care of running the server in debugging mode, and doing a bunch of sanity checks.
I was not really thinking past the common ones, however thinking about things more so, I actually prefer the checkpatch.pl-esque approach, then we can all contribute and fix things :)
Sure. That's a lot easier to integrate than server patches. Alan DeKok.
Hi,
Is there a plan to add to FreeRADIUS a debug output mangling option? So things like Cleartext-Password and User-Password are obscured.
For example, you get the user to run FreeRADIUS with '-XO', then just before printing to the screen the value of the 'secret' attributes are md5'd and the hashes are shown instead (should be a constant, unless there is actually a mismatch). Of course you could have a '-o attr1,attr2' to protect other attributes at runtime too.
Only something to add to the wishlist. :)
agreed - yes, understand that debug mode should show ervything - because then you can prove the password is wrong etc etc.... but if that debug is then being put somewhere is needs to be obfuscated or <removed> - heck, even just replaced with the word PASSWORD (and hope some people arent that dumb! ;-) ) - likewise any other 'sensitive' data. alan
participants (3)
-
Alan Buxey -
Alan DeKok -
Alexander Clouter