Playing with XTRadius

  • I´m playing with XTRadius on a PCBSD machine and i finally got it running and autenticating users against an external app. One of my tests included sending WISPr attributes to a monowall machine. All working fine.

    I have two questions :

    1 - XTRadius is distributed as source code only. How to create a binary package for it ?

    2 - I want to run some CGI app to control XTRadius, where should i put the cgi app as to have it accessible via webGUI ?

    Thank you.

  • I would be the last person to discourage anyone offering alternatives - but why put so much effort into a RADIUS server on which development stopped over six years ago with the final version being marked as a beta version, and for which there isn't a FreeBSD port?

    XTRadius is a fork of Cistron RADIUS, which has managed a couple of further maintenance releases since the XTRadius fork. However, development on Cistron RADIUS has ended too, apart from a bit of maintenance. Miquel, the developer behind Cistron RADIUS helped merge much of his code into FreeRADIUS. See here for more details.

    I maintain the FreeRADIUS ports for FreeBSD; there's a lot of development going on with that server (version 2 came out a few months ago - I'm just about to submit the FreeBSD port update for FreeRADIUS 2.0.4), and there's already a pfSense package for FreeRADIUS.

    If you really want to make XTRadius available for use with pfSense, you'll need to retrieve the old XTRadius FreeBSD port from the Attic of the FreeBSD CVS, find out what security vulnerability was never fixed and that led to the XTRadius port being deleted in December 2002. You will need to fix that security issue in XTRadius (if you're lucky, the problem was fixed in Cistron RADIUS and you can backport the fix), and ideally submit the fixed port back to the FreeBSD ports tree. Once you've done that, you'll need to create a pfSense package on top.

    I suspect that the FreeBSD XTRadius port was deleted in December 2002 because it was felt to be not worth fixing with the other RADIUS server alternatives out there. I think many people will struggle to believe it's worth fixing five years later when other RADIUS servers have moved on.

    Within the Free Open Source Software community, there is room for several competing products that do the same job. I use Postfix for mail, but that's not to say that qmail, Sendmail or Exim don't have strengths. I use FreeBSD on my other servers (not just my pfSense box), but there's plenty that's good in OpenBSD, NetBSD and Linux. Dovecot is my favourite email server, but cyrus and Courier-IMAP have their place as well. For RADIUS, the main FOSS offerings are FreeRADIUS, GNU RADIUS and OpenRADIUS - though my belief is that FreeRADIUS is developing the fastest and has the best feature set.

    There comes a point where software is best abandoned because it is no longer maintained. Without developers to keep an eye on it, bit rot sets in, and it's better to look for alternatives. The FreeBSD ports tree does deprecate and eventually remove ports when they are felt to be obsolete.

    I wonder if your efforts wouldn't be better diverted to helping improve the existing pfSense FreeRADIUS package rather than fixing another RADIUS server on which development stopped so long ago.

  • Well the only reason for playing with xtradius its because it allow the use of external programs to authenticate users and do the rest of the stuff (well, i dont know if FreeRADIUS can do that…).

    IF FreeRADIUS can handle all tasks to external applications (And become simply a "proxy" capable of decoding-encoding RADIUS packets) i will drop xtradius and use freeradius.

    Ah, i have a small setup with XTRadius, pfSense and Monowall. XTRadius is running at pfsense box and monowall authenticates against it.

    XTRadius calls a binary program called radiusrequest that reads a textfile (its just a test, i will use sqlite later).

    another binary, called radiusedit.cgi is able to edit the textfile with the format :

    <login><pasword><upload><download>ps.: i searched and now i know about XTRadius vulnerabilities... maybe freeradius is worth another check. Can it invoke external apps to do the work instead of trying to parse the request itself ?

    ps2 : anyone knows how to make pfsense lighttpd ask for login/password when you add ".cgi" binaries to /usr/local/www ?

    radiusedit.cgi is open, lighttpd doesnt asks for password when i access it...

    ps3 : found some info about how to call external app :

    while im not using perl, the info is usefull.</download></upload></pasword></login>

  • There's many different ways of authenticating using FreeRADIUS.

    You can invoke an external application, but this is the last resort, owing to the time taken to fork another process. FreeRADIUS is capable of processing thousands of packets per second - but not if its forking another process to deal with each one.

    rlm_perl and rlm_python are both much better options if you need full flexibility; much scripting is done in one of these two popular scripting languages (note that rlm_python is only classed as stable in FreeRADIUS 2). FreeRADIUS 2 has its own 'unlanguage' which gives a lot of flexibility without the need to resort to perl, python or rlm_exec (see the man page for unlang). The users text file is more than just a straightforward text file; it has a richness of its own.

    There are also facilities to use PAM, various flavours of SQL (MySQL, PostgreSQL, Oracle, Microsoft SQL Server) with customisable queries - and don't forget the ability to use custom procedures, OpenLDAP, Apple OpenDirectory (on Apple operating systems), Microsoft Active Directory and Kerberos. SQLite support has just been contributed, but documentation is lacking on that at the moment.

    For your application, do you need anything more than recreating the users file with your front end, then HUPping the server? This will need FreeRADIUS 2; FreeRADIUS 1 doesn't behave well with HUP. If you want to parse pfSense style configuration files, rlm_perl and one of the many XML libraries available might be a good way ahead.

    Whatever you need, there should be the necessary richness available in FreeRADIUS. The documentation that comes bundled with the server, the comments in the configuration files and the FreeRADIUS Wiki should help fill you in. I'd rely on that far more than 6 year old posts from the FreeRADIUS user lists. Similarly, many HOWTO and similar guides around on the net for FreeRADIUS are out of date - they're written for early 1.x versions of FreeRADIUS. Any advice to set Auth-Type or to use User-Password instead of Cleartext-Password is almost certainly obsolete.

    CGI doesn't feel very pfSense to me; the pfSense UI is in PHP. To that end, there's PHP code already available that builds on top of FreeRADIUS, including the dialupadmin system shipped with the server.

  • Hm, if forking is a problem, how about having the program permanently loaded, like some kind of fastCGI ?

  • The whole point of rlm_perl and rlm_python in FreeRADIUS is that they keep the interpreter and script loaded and ready to go, so there's no need to fork. It's exactly the same issue as mod_perl versus an external perl CGI program in apache or using Net::Server for a server in perl rather than using inetd to start a perl script to handle the request.

    If you really can't make rlm_perl, rlm_python, the various supported LDAP directory and SQL database options or the users file (with unlang in version 2) do what you want, you can develop a custom module in C or a language that can be linked with C and slot that into FreeRADIUS. I would look at the users file (though to use HUP, you'll need FreeRADIUS 2), rlm_perl or rlm_python first - one of those sounds ideal for your application. rlm_perl may be the best fit, especially as the 'pfSense way' is to keep configuration data in XML and perl handles XML well.

    Usually, if unlang suffices, it's the best option. If the processing needed is too complicated for unlang, then, unless you're using an SQL database (in which case customise the queries and/or consider using an SQL custom procedure), rlm_perl or rlm_python is the way ahead. The idea is only to resort to Exec-Program-Wait if none of the other options are feasible.

  • [It's exactly the same issue as mod_perl versus an external perl CGI program in apache or using Net::Server for a server in perl rather than using inetd to start a perl script to handle the request.]

    Actually this is sort of a myth.

    Most modern OSes do caching, and if a program is called thousands of times it will surely stay cached all the time. We tested some FreePascal CGI binaries against PHP ones (using openload) and the results of both were similar - for a hello world program. The same comparision using complex math programs made PHP grind while the binary kept almost the same speed (the difference from a hello world and a complex math was negligible).

    I need to write some custom app for small wireless ISPs and asking my users to use something like radadmin will not work…

  • Caching will undoubtedly help - as will the ever increasing hardware speeds and amounts of memory. However, if you can avoid the overhead of forking completely, it seems wise to do so, especially when you're eliminating multiple forks per second.

    For your application, my preferred way ahead - assuming you want to implement this in pfSense - would be to use FreeRADIUS's mod_perl. It's then up to you to implement the management side of things - I'd make the administration interface use pfSense's CoreGUI / PHP capabilities and keep the user list in XML. Top it off with a perl monitoring / user list tidy up daemon running from cron, and you should be there.

    Alternatively, you could use MySQL or PostgreSQL for the user list and accounting information (which may be important for you), with FreeRADIUS's rlm_sql. For security reasons, I'd be tempted to keep the SQL database off the pfSense machine unless there's no alternative. I'd still use the pfSense CoreGUI / PHP capabilities as much as possible.

    A third possibility is to deploy a system built on top of FreeRADIUS such as daloRADIUS or FreeRADIUS's own dialupadmin. If one of the 'off the shelf' systems meets your needs, why take the time to develop a whole new UI?

    You must do what you're comfortable with - but I wouldn't want to deploy any live system based on an AAA daemon that is five years old and no longer supported when there's viable alternatives around. Of course, you don't have to use FreeRADIUS - if you decide FreeRADIUS is not the right tool, there's OpenRADIUS and GNU RADIUS, both of which continue to receive developer attention.

  • i´ll try those tools you mentioned, but, one of my tasks is to make the current accounting software (that accounts most things in the company) compatible with the RADIUS backend (currently they do everything using a small software developed using Delphi, but this software cannot enforce anything upon users, the network owner must manually do everything, from blocking users to creating logins… this sux) so i thought freepascal was a nice way to go, extending the software and porting (actually, just copy and paste) some of its functions to the radius backend running at pfSense... and the current setup (using monowall captive portal user list) cannot even give per user bandwidth... Everyone has the same network speed (bad comercial model).

    These people wont understand RADIUS reply, RADIUS bla bla bla, this is out of this world for them...

Log in to reply