|
|
|
RADHACK is a little patch I threw together for INN 1.7.2 (the Insync 1.1d version specifically, but it should work with plain 1.7.2) to enable nnrpd to do user authentication against RADIUS servers. So far I have only used it a short time on a Solaris 2.5.1 machine, but no problems have shown up (yet). It is very much based on Livingston (now Lucent) RADIUS 1.16 and, in particular, radtest from Cistron RADIUS 1.5.4.2 by Miquel van Smoorenburg. RADHACK does not (well, should not) change the authentication methods currently used by nnrpd it only adds support for RADIUS. This is accomplished by adding (or changing) an entry in the nnrp.access file. The format of the entry remains the same as it is now. An example entry looks like this: ## This is from the standard INN samples ## <host> Wildcard name or IP address ## <perm> R to read; P to post ## <user> Username for authentication before posting ## <pass> Password, for same reason ## <groups> Newsgroup patterns that can be read or not read ## Foo, Incorporated, hosts have no password, can read anything. *.foo.com:Read Post:::* ## The same entry to do local passwd file lookup *.foo.com:Read Post:+::* ## The same entry allowing only the specified user to authenticate *.foo.com:Read Post:joeblow:joespwd:* ## Finally, the same entry to do RADIUS lookup *.foo.com:Read Post:<radius>:111.111.111.111;222.222.222.222;radiussecret:* The first two examples use the authentication methods built into INN now. The first authenticates against a host or IP address (and is commonly used...in my system at least), but makes it difficult for remote users to read their news (like if they want to read it from their office). For situations like that I have to rely on one of the following two authentication methods. The second only authenticates against a local passwd file and is useless if you use a shadow file for passwords (unless you run nnrpd as setuid root, which it won't easily do...copy the passwords for everyone you want to authenticate this way into your passwd file [lame]...or make your shadow file readable by the news user [bad idea]). The third allows a user named "joeblow" with the password "joespwd" access. The problem here is you would have to enter each user into this file individually (both username and password) and the passwords are in plain text which could be a security risk. The other problem I have with this system is that when the username/password are verified they aren't checked against the host/IP so if another user connects from a system that has read permissions only, they could enter joeblow/joespwd and get his permissions. This makes it a bit difficult to limit user "joeblow" to a single network (or host). The fourth, and final, example shows how RADIUS authentication is used. It addresses the deficiency with the first method above in that it can allow remote users access to your news server (the example I've shown only allows "*.foo.com", but could be changed to just "*" to allow everyone to use RADIUS for access. It checks the users host/IP against the nnrp.access file to make sure they are allowed to use RADIUS from that host/IP before the lookup is done. The fields in the nnrp.access file remain the same as they do now except for the following two changes: The 3rd (<user>) field must be "<radius>" (without the quotes of course). The 4th (<pass>) field contains, in order, the IP address of the primary RADIUS server, the secondary RADIUS server and the common RADIUS secret. Only IP addresses can be used since I didn't make the buffer large enough to hold FQDN's. The RADIUS secret is limited to 16 characters (which I believe is what the RFC allows). All three bits of information must be separated by semicolons (;) and must be present (so if you only have one RADIUS server put its IP address twice). So the above example (number 4) would allow anyhost in the foo.com domain to authenticate using RADIUS. The primary RADIUS server is 111.111.111.111, the secondary is 222.222.222.222 and the secret is radiussecret. You can have multiple entries that use RADIUS authentication, but like the other authentication methods, they are used on a last match basis. I think that's enough explaining for what is really a pretty simple patch (I just like to be as clear as possible). All you need to do is unTAR the archive into your "nnrpd" directory, do a "patch < radhack.diff" and then a "make" to compile the new version. After it (hopefully) compiles you can just copy nnrpd into the same place as the existing copy (make a backup of it first though...just in case). Like I said, I have used it without any problems on a Solaris 2.5.1 machine, but as with all patches like this...You use this at your own risk. I do not take any responsibility for any problems that you might have with this patch (or anything else really). ;) A couple of final things about this patch. It only sends a RADIUS authentication request to the defined servers and then waits for a response. The actual process is: Send to primary No accounting is done, so these logins will not appear in your RADIUS detail files. I did this on purpose. I didn't want to have my detail logs bloated up by non-dialup customers (since RADIUS is really for that and not what I'm making it do here) and nnrpd already tracks readers so the RADIUS accounting would just duplicate that effort. So here it is in compressed and gzip tar archives... I'd love to hear from anyone who uses this patch (good and bad comments are welcome). I would also be interested in seeing any enhancements anyone makes. [NOTE: This patch is no longer supported] |
|
This website is hosted by NetQuest |
