Using NoCat with Raven and NAT logging on the CUDN

Note: This page is likely to have dated somewhat. I was disatisfied enough with NoCat to write my own (open source) network authentication system; my efforts are now focused on it.

This page attempts to document the steps required to modify the open source NoCat (often wireless) network authentication system for use within the CUDN (or at least my experiences in doing so). I'm also hoping to provide some documentation about how (at least some parts of) NoCat works internally, but haven't written this material up yet. There are two main areas of modification, numbered *1 and *2 in the diagram below:

  1. Creating a Raven-protected path to the appropriately modified cgi-scripts for performing NoCat login, renewal, logout, etc.
  2. Ensuring that the Network Address Translation (NAT) performed by the network gateway logs connections made through it as required by the University of Cambridge Information Technology Syndicate (ITS), so that if you are contacted by CERT, say, you will be in a position to forward any fire and brimstone related to network abuses to the individuals responsible rather than it landing on you because it's your NoCat server.

I am very keen that these pages might help others employ NoCat for their various dynamic user registration network authentication purposes, so please do send me (dme26) feedback about what's you've found lacking in these pages. I have been pleased with the functionality provided by it and the opportunity to bring out of retirement those older machines we all have lying around.

Note that I am not currently and indeed never have been employed as a sys-admin. If something obvious appears to be amiss, you're very likely right, and I'd be keen to hear from you so I can fix these directions and/or how I've configured my servers and/or my brain as appropriate. Thus I will not spend time here trying to suggest how to best maintain the Linux boxes used within a NoCat system with respect to security, primarily because I'd not be able to give you the best answers.

What's all this about?

NoCat is an open source package (extreme thanks to its authors for releasing it for the benefit of all!) which is primarily aimed at placing a gateway between an open wireless network and your network (and from there probably the Internet). From my perspective it provides a way for me to avoid users having to faff around with network settings that they (rightly) don't care about, and shouldn't have to - they just want their Internet access to "work". At the same time, I can collect enough information to mean that any abuse of the network can be traced back to them for as long as the NAT logs are maintained. Of course the downside of the auto-configuration is that in a wireless context, the network is open. I always put a comment to this effect on the authentication page reminding users to use HTTPS and SSH/SFTP in preference to HTTP, telnet and FTP if they're worried about the security of their data.

The NoCat infrastructure involves these components:

|<---- Internal network ---->:<----- External network ----->>
                .-----------.   .----------------.
  Unknown User--+-.         |.  |      NoCat     |
                |  :--only--+---+ Authentication |
  Unknown User--+-'         |.  |     Server     |
                |           |   '-+--------------'
(after users    |   NoCat   |.    |
 authenticate   |  Gateway  |     +- User/password stores
 they move down |           |.    |  (LDAP,DB,RADIUS,etc)
 outside this   |           |     |
 upper-left     |           |.  RAVEN(*2)
 '/. contained  |           |     |
 region)        |           |'    '- dummy password check
  '   '   '   ' | '   '   ' |
                |   (*1)    |
    Known User--+-Log SNAT--+------> (your network, thence
                |           |         the Internet probably)

Comments on this diagram:

  • It is possible to run the authentication server on the same computer as the gateway, but doing so is probably not being suitably paranoid security-wise - it's best to separate the two functions (I've set up systems in both configurations without problems so far however). NoCat is designed so that gateway machines can be quite modest in performance - ye olde 486s with 32Mb RAM and such like [ramble 1].
  • Actually you have almost full control over the servers and ports accessible prior to authentication. For example I obviously need to permit users to be able to reach if they're going to be able to authenticate that way.

NoCat's usual work involves this approximate series of steps:

  1. Some non-identified user appears connects to your network. Commonly they will appear on your internal network via an open wireless access point, but there's no reason they couldn't use a wired socket either of course.
  2. The user's computer will be issued with a temporary internal network IP address care of the DHCP server running on your NoCat gateway.
  3. The user attempts to visit a web page (note that if they try to use SSH, say, this will fail since the NoCat gateway won't SNAT their connection until after they authenticate).
  4. The NoCat gateway captures their HTTP connection attempt, notes their presence, issues them with a unique session token, and redirects them to make an HTTPS connection to the NoCat authentication server.
  5. The authentication server presents them with the login web-page. The simplest NoCat configurations just display a splash screen and let them click through after agreeing to conditions printed on that page. Clearly this isn't sufficient for CUDN use. The next level up in terms of security configuration requires users to register, but lets anyone do so. Again that's not enough for us. The most secure configuration requires users to enter a username and password. It is at this point that I have added the Raven authentication option (and in some deployments remove the username / password option).
  6. Assuming the user successfully authenticates, they will be added to the list of hosts permitted SNATing (i.e. forwarding of outward connections) between the internal and the external network. At this point I have added the iptables LOG target which records where internal connections originate from.
  7. In the previous step, a pop-up window is opened which contains a logout button. In fact behind the scenes this pop-up is making fairly regular HTTPS reload requests to the authentication server to keep the user's connection active. NoCat will notice if ARP requests stop appearing from a given client and will remove them from the set of active sessions - of course this isn't sufficient to prevent malicious users nicking the MAC address of an authenticated user just after they turn off their computer assuming they forget to click the log off button. Said malicious user will be able to "tail-gate" but only until the next scheduled HTTPS reload from the pop-up. Of course people who block the NoCat pop-up will end up getting booted off at each HTTPS reload time - hence I plan to make the pop-up optional (evidently it wasn't expected how quickly pop-ups fell out of vogue!).

Creating your UCam NoCat system

This section describes my logging of the steps I've been through to create a NoCat gateway. I've only done this a few times so far, so hope to expand many of the choice points as I repeat the process myself, and hopefully from when I (dme26) here from you regarding where there are good shortcuts, and/or other useful alternative paths. When a preformatted section is entitled "modifications to" some file, I don't necessarily mean you can just cut and paste my output below - better to search through the file for each option and ensure you've made an appropriate modification with reference to what I've suggested.

Setting up a NoCat gateway

On most of the networks I've configured, I've only used a single gateway machine. If your network is likely to involve a large number of clients, it may make sense to use a number of gateways to effect load-balancing and/or fail-over. I've not investigated whether DHCP can easily do a round-robin, say, allocation of a number of NoCat gateways to your clients. Note that because I tend to have difficulty avoiding making side-comments, I've just formatted them slightly differently so that you can see which parts of a step are actually important, and which parts are me erring on the side of rambling.

I've tried to collect the files I've used, so that if you're in a real hurry you can get your network up and running with the minimum of distraction caused by configuration differences between your and my setup. Many of my files contain the text dme26 in an appropriate type of comment to indicate where I've made changes (except when they're standard configuration files in which case one would expect there to be lots of changes). Let me know if I've missed out anything vital/useful. Most of the directions below probably require you to be logged in as root.

  1. Make sure your gateway computer has two network cards installed. Alternatively use 802.11Q VLAN tagging on a single NIC, but I'm assuming if you've figured you want to do that, you're not going to have any difficulty figuring out what you need to do where it's different from these directions.
  2. Install Linux on your gateway computer(s). I used Debian Sarge. I'd be interested hearing from those who alter the directions for other Linux distributions so I can incorporate the necessary alternatives in this documentation. I was happy to use a testing Debian distribution since I figured it would be stable enough for the relatively straightforward operations required by the NoCat servers, plus it gave me technologies such as the EXT3 file-system for zero effort. Note that you'll need to install Linux on your authentication server too, so parallel installation is probably in order here...
  3. Configure your internal (eth1 in my case) and external (eth0) networks. Given that you'll most likely configure eth0 during the Debian install process, I just had to do the following:

    Added to /etc/network/interfaces

    auto eth1
    iface eth1 inet static
  4. Set up a DHCP server on your internal network. For me: apt-get install dhcp3-server to install the package, and then do the following:

    Modifications to /etc/dhcp3/dhcpd.conf

    # The IP address here is of your gateway. I've not yet set up
    # a deployment with multiple gateways, but this option can deliver
    # multiple gateways to your clients in order of preference.
    option routers;
    # This is the internal WiFi subnet.
    subnet netmask {
    # Change the MAC address below to match your Access Point!
    # (of course you can add multiple host blocks for ap2, ap3,
    # or whatever naming scheme you give your access points)
    host ap1 {
       hardware ethernet 00:e0:63:89:a3:32;
  5. Download and decompress the NoCat package. I used, and thus mirrored locally NoCatauth-0.82.tar.gz. The nightly builds have been changing since this release, but the stable releases don't seem to have changed in many years.
  6. Build your gateway. The instructions for doing this are in the NoCat package, but if you don't want to read them I did:
    # cd /where/you/downloaded/nocat
    tar zxf NoCatauth-0.82.tar.gz
    cd NoCatauth-0.82
    make gateway
  7. Modify your NoCat gateway's configuration file. These options are all I needed to change, although they are distributed throughout nocat.conf, which itself contains plenty of comments to describe what the various options mean.

    Modifications to /usr/local/nocat/nocat.conf

    GatewayName     Your NoCat network name here
    # By default NoCat puts its log under /usr/local/nocat 
    # which I thought was a bit odd, although this option
    # is redundant since I subsequently request syslog
    # logging anyway...
    GatewayLog      /var/log/nocat_gw.log
    # This is the homepage of your organisation
    # This option is the hostname (if DNS is accessible to your 
    # clients) or the IP address of your NoCat authentication server.
    #  Configuration details for the internal network
    # You could well choose to allow unauthenticated browsing
    # of your organisation, although I figured the simplest way
    # to avoid unexpected undue CUDN impact was not to. Clearly
    # access to Raven is necessary if your clients are going to
    # authenticate that way...
    # This option prevents users from being able to skip the
    # need to authenticate.
    MembersOnly     1
    # I'd recommend picking one of these two options. The first
    # will only allow SSH, HTTP, and HTTPS. The second option 
    # allows your users to use any ports, but blocks SMTP.
    IncludePorts    22 80 443
    # ExcludePorts    25
    # I'd prefer to log to the syslog, since the SNAT tracking
    # from iptables ends up there too.
    LogFacility     syslog
    SyslogSocket unix
  8. Modify the NoCat gateway initialisation to enable logging of SNAT so you can track abuse back to the internal IP addresses from your gateway's IP address + port. I also changed masquerading to SNAT since in this sort of deployment you're likely to have a fixed gateway IP, and thus it doesn't make sense to incur the extra lookup cost. This file is the replacement /usr/local/nocat/bin/initialize.fw I use, although you will need to modify the snatIP=... line near the top of this file to include your gateway address! Of course I'd recommend you look at the `diff` between mine and the original to make sure you agree with my other changes too.
  9. Install the NoCat authentication server keys on your gateway(s). I put this step here because your gateway won't work until this is done, although I describe what to do to achieve this step under the authentication server setup directions below (since that's when you'll actually create the keys used).
  10. Get your NoCat gateway up and running. I also made the appropriate Debian changes to the startup environment to ensure it stays up and running...
    # The steps below start NoCat at startup
    # cd /where/you/downloaded/nocat/NoCatauth-0.82
    cp nocat.rc /etc/init.d/nocat.rc
    update-rc.d nocat.rc defaults 99

If you've had to change configuration settings, you may well need to restart the NoCat gateway (which will reset all iptables rules too). For me on Debian this just involved running /etc/init.d/nocat.rc restart.

Setting up a NoCat authentication server

  1. Install Linux on your authentication server computer (if it's not the same machine as your NoCat gateway). As above I used Debian Sarge.
  2. Install NTP (the Network Time Protocol) on your authentication server. I must admit that I haven't actually done this for all of the systems on which I have set up NoCat. Apart from being a good idea with respect to not having to think about keeping your clock correct, the Raven module requires good time synchronisation between the central Raven service and your local Apache Raven module.
  3. Install apache-ssl on your machine. Note that I've just suggested this for homogeneity - I should update these directions to use Apache version 2 configuration instead of the older 1.3 stuff. On Debian this just required me to apt-get install apache-ssl
  4. Download and decompress the same NoCat package as used above in the gateway setup directions.
  5. Build your authentication server. Use the commented-out line and not the uncommented line if you're running the authentication server on your gateway box - hopefully the desired effect is clear.
    # This will default to installing in /usr/local/nocat
    # although the set of files at this path will be different
    # from the files at the equivalent path on the gateway
    make authserv
    # This will place the authserver at a subdirectory of
    # the gateway. Some files are duplicated, but that's
    # because the same machine configuration is not the
    # recommended one.
    # make PREFIX=/usr/local/nocat/authserv authserv
  6. Create an authentication server key. This key is used by the authentication server to securely encode messages aimed at the NoCat gateway but actually delivered by your (untrusted in this respect) clients. Again the make line below needs to have the appropriate PREFIX set if you've installed your authentication server in an unusual place.
    make pgpkey
    # instead of the above use a make PREFIX argument if
    # you've installed auth and gateway on the same machine
    #make PREFIX=/usr/local/nocat/authserv pgpkey
  7. Install your authentication server keys in the appropriate place on your gateway computers. This is done by placing a copy of trustedkeys.gpg within the directory /usr/local/nocat/pgp on your gateway computer(s). If I install auth server and gateway on the same computer, the file in question is in the directory /usr/local/nocat/authserv. Otherwise you'll need to (e.g.) SFTP the original file across from under the directory /usr/local/nocat.
  8. Check the permissions on the trustedkeys.gpg file on your gateway computer(s). In my case I needed to do a chown www-data:www-data * within the /usr/local/nocat/pgp directory to ensure that the UID CGI scripts run as can read (but not write) these files.
  9. Make appropriate changes to the NoCat configuration file on the authentication server (add in an authserv/ as per usual if gateway and authentication server are on the same computer).

    Modifications to /usr/local/nocat/nocat.conf

    # I left the simple NoCat password database active so that
    # I could create a administrative login users, and userIDs
    # for conference guests whose sessions are routed down a
    # non-CUDN ISP.
    DataSource	Passwd
    # Uncomment the suggestions presented for the three NoCat
    # simple password-based authentication system if you plan
    # to use it (or at least be able to).
    # If you are running the authserver on the gateway computer,
    # you'll need to uncomment an option indicating this.
  10. Configure the httpd.conf options specific to the NoCat authentication server. In my case, I included the /usr/local/nocat/httpd.conf file from my main Apache configuration files, although of course you could place the appropriate configuration options directly in there...

    Modifications to /usr/local/nocat/httpd.conf

    # find the nocat cgi-bin <Directory> directive and within 
    # it insert the following <Files> directive. This will
    # indicate that the file "loginr" should be Raven
    # protected.
         <Files loginr>
             AACookieKey "put your own random string here"
             AADescription "Your Raven service description"
             AAMaxSessionLife 14400
             AuthType Ucam-WebAuth
             Require valid-user
  11. Ensure that accessing your authentication server via HTTPS will actually display the NoCat authentication pages. I did this by just symbolic linking the htdocs subdirectory of the authentication server to replace where you'd otherwise put a real directory under /var/www.
    cd /var/www
    ln -s /usr/local/nocat/authserv/htdocs https
  12. Create the loginr script in your authentication server's cgi-bin directory. If you do a `diff` from the normal login file, you'll see the modifications to this file just parse the Raven cookie to pick out the user's CRSID, avoid actually doing any real NoCat authentication and optionally filter the permitted CRSIDs via a file containing one CRSID per line (dodgy implementation, but sufficiently effective).
  13. Create appropriate login.html and login_ok.html pages. I've linked examples from one of the organisations I've done NoCat deployment within. These files actually present your organisation's image to your prospective users.
  14. Configure your Apache SSL settings.

    Modifications to /etc/apache-ssl/httpd.conf

    # Give these variables appropriate assignments.
    # not applying the above symbolic link, this would
    # need to be set to where your NoCat authentication
    # server HTTP documents actually are.
    DocumentRoot /var/www/https
    # I have this line mentioned but don't remember why
    <Directory /var/www/https>
    # comment out the default /cgi-bin/ alias. This option
    # was near the IfModule mod_alias.c chunk in my Debian
    # install's default Apache setup.
    # Insert references to wherever you installed the
    # Raven authentication module.
    LoadModule ucam_webauth_module /usr/lib/apache/1.3/
    AddModule mod_ucam_webauth.c
    # Insert an include line to catch the configuration
    # options in your authentication server's NoCat
    # httpd.conf file if you haven't made all the necessary
    # changes to your global httpd.conf file.
    Include /usr/local/nocat/httpd.conf
  15. Download, compile and install the Raven module. When you're done you'll have a file built. I achieved this step with the following shell commands:
    # I needed these packages to compile properly
    apt-get install apache-perl
    apt-get install apache-dev
    apt-get install libssl-dev
    # possibly not this one, but I need to run through 
    # these directions again to check.
    apt-get install apache
    #cd /your/work/directory
    # download the Raven module
    cd mod_ucam_webauth-1.0.7
    # I needed to add the APXS option - you might not
    make APXS=/usr/bin/apxs
  16. Having built your Raven module, copy it to where your other Apache modules are. For me this involved:
    #cd /your/work/directory/mod_ucam_webauth-1.0.7
    cp /usr/lib/apache/1.3/
  17. Finally, for Raven to work, you need to set up the appropriate webauth_keys. The directions for doing so are on the Raven developers' pages (specifically here). In my case, I needed to place the keys into the directory conf within Apache SSL's directory within /etc.
  18. Restart Apache to pick up all the changes you've made above. For me this involved /etc/init.d/apache-ssl restart after which hopefully all is well and your NoCat network will be up and running.

Testing your NoCat setup

If all the above has gone to plan, you should be in a position to make use of your shiny new NoCat network. Here are the sorts of steps I'd follow for testing, although I suspect these will be obvious to many of you.

  1. Grab a machine (hopefully a laptop) configured to use DHCP on its ethernet interface.
  2. Use a cross-over cable or hub/switch to connect to your laptop to the gateway's internal network, and check that DHCP is working.
  3. Swap over to wireless for the physical network layer (i.e. plug your access point into the internal network socket of the gateway). Swap your laptop over to wireless operation and check that DHCP is still working.
  4. Open your browser of choice and navigate to a page using HTTP. You should see the status message from your browser indicate the redirection to the authentication server. If this does not happen, it is likely to be a configuration error on the part of your gateway.
  5. Assuming that you have reached the authentication server logon page, try using the Raven login option. Error messages before any mention of the Raven URL probably indicate that your Raven Apache module is not configured correctly.
  6. If you get error messages after using the Raven login page, it is possible that there is some configuration error with respect to the modified version of the login CGI scripts.

[ramble 1] Apparently 486s with 32Mb RAM work fine, although I've been lucky enough to have spare P3s. The one exception to this luck was a Tiny brand P3 - because of completely hopeless configuration, the thing behaves as if it's a P2. I was intrigued how a P3 700Mhz could run slower than my P3 450Mhz, so had a look around the box. It uses some revision 0.00 MicroStar International (MSI) motherboard, but most strangely has an AMI BIOS when all the MSI website documentation for that board indicate they use Award BIOSes (except in the earliest revision - but then that has a different date from the AMI BIOS I saw in this box). Anyway, the AMI BIOS basically had no coverage of most of the necessary steps in getting the motherboard's CPU, memory and I/O interfaces up to an appropriate speed at boot time. I've successfully cross-flashed the BIOS in one such box over to Award, which works on the unacceptable side of OK. For poking around with such BIOS configuration stuff on Windows, I highly recommend wcredit/wcrset which allow you to do all sorts of unrecommended things to I/O registers after your system has booted up (actually wcrset is a boot-time utility to poke I/O registers during early Windows boot stages) - please don't blame me if you destroy your computer with it!

Tiny had constructed a stunningly poorly configured machine, which didn't get anywhere near meeting its basic advertised performance specifications. I believe Tiny has since gone bankrupt and been bought by someone else, however all this was before my arrival in the UK. My theory is that the AMI BIOS might have made it easier to display the Tiny boot-time splash screen at the expense of all other aspects of the computer's performance - well, I couldn't think of any more sane reason anyway.