A free HOTP soft-token for J2ME based mobile phones and PDA's can be found on the Data Security Systems Solutions site (or locally from here, the manual (1.4MB) is here).

On the server-side we use the OTP daemon from Tri-D systems (website no longer available). On that site you could find the source tarball for the HOTP daemon (otpd, now avalailable locally) which is prepared for the debian build tools (and rpm-based systems for that matter). Starting with version 3.0.0, the local state manager daemon (lsmd) is integrated, but with earlier versions this should also be built.

Building the OTP daemon

Unpack the otpd tarball and change to the otpd-3.0.0 directory. We need to make two minor changes, but the files lack the write-bit, so we can just make everything writable with "chmod -R u+w ." The two fixes that we apply are changing a small typo in the debian/changelog and add the install of the otppasswd manpage. Apply the following patch:

After this, the package can be built with

The pre-build package for the i386 architecture is available here.

If all you want is to use the OTP daemon on a single server, you might install Tri-D's PAM module from their download page. This too is prepared with the debian build files and a spec file for rpm-based systems. I opt for a central server with freeradius and otpd running and having a RADIUS PAM module on the separate systems.

Building the freeradius package

Version 3.0.0 of otpd requires at least version 1.1.7 of freeradius. The rlm_otp module is included, but the debian rules file excludes that module. So to build that we should get the source files from testing. Make sure your /etc/apt/sources.list contains a the line:

deb-src http://ftp.debian.nl/debian/ testing main

then update the apt database and get the source files with

Alternately, you can get the .orig.tar.gz, .diff and .dsc from the debian packages repository and unpack it with

Change to the freeradius-1.1.7 directory and apply the following patch:

and build the package. Aside from the package itself, various modules are built as separate packages . I only install the basic package (freeradius_1.1.7-1_i386.deb) since flat files are sufficient for my needs.

Combining the two

There was a minor problem I ran into when trying to have freeradius actually use the otpd for verifying the responses: file permissions. otpd has the option of running as a user other than root but then some files and directories have to be readable and/or writable by that user. If you install the package they are not. freeradius runs as user "freerad" by default, and this is the user that will access the socket file in /var/run/otpd. There are two solutions: have freeradius run as root, or have otpd run as freerad and change the file ownerships. I opted for the latter. For this reason I postponed configuring otpd until after I installed freeradius. I also ran into a small bug in the otpd package: the /etc/otpd.conf has an empty "state" section, which is considered a syntax error so the debian post-install script failed. I just unhashed the "mode = local" line and issued "dpkg --configure --pending" to make it happy.

Configuring otpd

First, we stop both the freeradius and otpd daemons. Some files and directories need to be created and the correct permissions set. Execute the following commands:

Generate a token on the J2ME client. The seedlength may be any value from 16 to 20 (I use the maximum), but the OTP length should be 6. This is because of a limitation of the "resynctool" that we will see later. After this the seed is displayed. Make sure you see the complete seed (i.e. opening and closing bracket should both be visible). I use a Windows Mobile based PDA and I need to use landscape mode to prevent the seed being truncated. The seed is displayed only once. Be cautious in copying it in the next step. After this, you are opted to place a PIN code on the token you just created. You might want to do that to have real 2-factor authentication.

Now create an entry in /etc/otppasswd with the following syntax:

user:hotp-d6:key

where "user" is the loginname of the user that will be authenticated via RADIUS, and "key" is the seed you just generated on the soft-token. So the line might look like this:

Now we need a state file for this user. Calculate 2 consecutive passwords with the token, and use "resynctool" to generate state information like this:

This results in output of the form:

5:foo:0000000000000002:::0:0:0:

Copy this into the file "/etc/otpstate/user" where "user" is the same as the second field from the pasted text (in this case: "foo"). Make sure user freerad has read and write access to the file.

Now start the otpd daemon (/etc/init.d/otpd start) and test it with the "otpauth" command:

If you get the output "5 (service error)", your configuration is still incorrect. Review /var/log/auth.log for clues what should be fixed. The error the we should expect here is "3 (authentication error)". Try the same command with a newly generated password, and you should get "0 (ok)".

Configuring freeradius

We should enable the otp module in freeradius. That means removing the hash to include otp.conf and adding "otp" to both the authorize and authenticate modules of /etc/freeradius/radiusd.conf (or apply the following patch):

Now we can start the RADIUS daemon (/etc/init.d/freeradius start) and test if it works with the otp module:

"testing123" is the default secret for localhost in /etc/freeradius/clients.conf. You should change that. We also don't use a NAS server so the NAS port (10) doesn't matter. We used a wrong password so the output looks like this:

Sending Access-Request of id 177 to 127.0.0.1 port 1812
        User-Name = "foo"
        User-Password = "123456"
        NAS-IP-Address = 255.255.255.255
        NAS-Port = 10
Re-sending Access-Request of id 177 to 127.0.0.1 port 1812
        User-Name = "foo"
        User-Password = "123456"
        NAS-IP-Address = 255.255.255.255
        NAS-Port = 10
rad_recv: Access-Reject packet from host 127.0.0.1:1812, id=177, length=20

With a correct password we get the following output:

Sending Access-Request of id 172 to 127.0.0.1 port 1812
        User-Name = "foo"
        User-Password = "752230"
        NAS-IP-Address = 255.255.255.255
        NAS-Port = 10
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=172, length=20

Now we need to allow clients to connect to the RADIUS server. For that we edit /etc/freeradius/clients.conf and assign shared secrets to the various clients and/or networks that will be accessing the server. The pre-installed file has comments that should make the syntax clear. Reload the freeradius daemon after you finished editing clients.conf.

Configuring the clients

On each client, install libpam-radius-auth:

Then edit /etc/pam_radius_auth.conf and add a line for the RADIUS server with the secret assigned to the specified client and a timeout value.

Now you need to edit those PAM files in /etc/pam.d where you want to allow RADIUS authentication. In debian, there is a single file (/etc/pam.d/common-auth) that is sourced by all modules that allow standard Unix authentication. I edited the file to allow both standard Unix authentication and RADIUS authentication. The file now reads:

so I can choose my method of authentication depending on the circumstances.

Caveat emptor

First, the RADIUS daemon requires UDP port 1812 to be open. Make sure your firewall configuration allows that.
Second, since the username used by the authentication module is specified on the RADIUS server, do note that there is a risk of clashing usernames. Either make sure that identical usernames on various clients belong to the same person or that different clients with the same usernames don't share access to the RADIUS server.
Third, since the HOTP protocol is an event-based system, a brute force attack on a simple numerical 6-digit password is very possible! The reason for this is that wrong password probes or a timeslot don't invalidate the current password. Make sure that the service which you use HOTP for is not freely accessible from untrusted networks and/or use something like fail2ban. Also make sure that you do not generate many superfluous passwords with your token that are not communicated to the otpd daemon on the RADIUS server. The server will calculate 6 consecutive passwords and give up if none qualify. If this happens, you will should use "resynctool" to calculate a new content for the state file.

Enjoy!

I first took a look at vserver but that was lacking a proper virtualization of the network. I like the idea of running a system on the host's kernel as a set of jailed processes, but since network security was the point of focus, the possibilities did not suffice. I read up on UserMode Linux and Xen and settled for the latter because of better performance and better overall possibilities of separating the functionalities. The next image shows the final configuration (the VOIP part still needs to be done):

The purpose of this configuration is to create small and tightly locked DMZ systems that will host related network services and be disallowed to start any other network service. No internet initiated connection can get directly onto the firewall unless I temporarily allow that (see the later chapter on the Sesame web front-end). The DMZ systems are locked down with the lcap tool to prevent the possibility of adding modules to the system or changing critical files. The fact that the system disks are visible from the firewall (which is the Xen Dom0) enables periodical scans for malware that the DMZ hosts are completely unaware of.

Hardware

Not all that much actually. I have a dual P3/1GHz with 1.5 GiB memory, 2 160GB ATA disks in RAID1 all in a 4U rack-mountable that generates way too much noise. It does suffice nicely for the job, partly because of the efficiency of the Xen hypervisor on standard hardware.

Xen configuration

In this setup there was no need for multiple domU's to share the same virtual network, so I opted for routing i.o. bridging scripts in xend-config.sxp. I modified the vif script to assign a C-net to the various internal interfaces. This is the "diff" with the vif-route script:

The domU's each have two LVM volumes assigned as swap and as the main disk. Here's the configuration of elektra as an example:

Each domU is "debootstrapped" with a minimal version of debian etch and the packages specific for each domU are added. The firewall runs on dom0 (also debian etch). I actually planned to run the firewall in a domU but there is a hardcoded limit of 3 network devices per domU in xen 3.0.

General concept of the firewall rules

• The internal net is white-listed to allow a few protocols (like HTTP and FTP). A few trusted clients are completely white-listed.
• The wireless net is exclusively allowed to start an OpenVPN connection (this is actually the way I protect the wireless net, I don't do WEP or WPA). If an OpenVPN connection is established, that connection is treated like an internal net.
• Internet-initiated connections that are allowed are send directly to the DMZ. With the exception of temporarily allowed connections (see the part on Sesame), no direct connections from the internet or the DMZ to the firewall are allowed (with the exception of UDP connections for OpenVPN sessions).
• The DMZ hosts have varying rules (enforced via the FORWARD table):
  • All hosts can send NTP packets to the internet and send syslog packets to the firewall
  • The mailhost can receive IMAPS, and SMTP from anywhere and can send SMTP to the internet
  • The webhost can receive HTTP, HTTPS and DNS from anywhere and send DNS to the internet, and send a "sesame" string to the firewall.
  • The Proxy host can start any connection to the internet (for SOCKS purposes) and receive SOCKS connections from internal and VPN hosts and SQUID from internal, VPN and DMZ hosts.
  • The database server can receive mysql and LDAP connections from internal, VPN and DMZ hosts
• VOIP has not been configured yet, the interface is idle as of this writing.

The firewall script can be found here.

Sesame web-frontend

There is a conflict of not allowing direct connections to the firewall and needing remote administration. I worked around this by creating a CGI page on the webserver that verifies a one-time password (OPIE) and if the verification succeeds, send the originating IP address to a specific port on the firewall.

There are a few requirements on the webserver for this to work. At the very least, the opie-server tools and the Authen::OPIE perl module are required. The latter is not packaged by default in debian, so this needs to be created with dh_perl (part of debhelper). The opie libraries (package libopie-dev) are required for making the package. My ready-built package is available here. The CGI script also makes use of the HTML::Template module (package libhtml-template-perl). I created a special user named opie and changes the ownership of /etc/opiekeys to that user. The CGI script runs at that user via the suexec mechanism of Apache. Except the OPIE challenge response, the user can also override the IP address that should be added in the table. This is done to prevent the address of a proxy server to be added to the rules i.o. your own. By default, the IP address of the connecting system is used. This is the content of the CGI script:

The template file is very straight-forward:

On the firewall end we have inetd listen to the specified port and send any incoming string to the script to add firewall rules. Because of the latter task this script needs to run as root. You can specify multiple tcp and/or udp ports in this script and for each of these, a firewall rule will be added to allow packets for that rule from the specified IP address, then the script will sleep for some time (default 5 minutes) and then all added rules are deleted again. Existing sessions stay active because of the stateful checks of iptables. The script:

Security issues

The S/Key system (which OPIE implements) is not terribly secure. It uses MD5 hashes on top of each other and then splits the hash in two 64-bit parts and "xor"s the two parts together. Cracking the system means doing a preimage attack on 64 bits with the MD5 algorithm. If you are limited to brute-force, a modern server (2 quad-core CPUs with 5kMIPS per core) runs for 2500 years. This may sound as much but really isn't. Last I heard there was a less-than brute force system available for finding MD5 collisions (I'm not talking about a birthday attack here, just the algorithm) and using multiple parallel systems which could bring down the time quite a bit.

Personally, I don't think we need to resort to any paranoia in this particular case. Even if a hash collision is found, the only thing a black hat can gain is opening up ports where another level of authentication waits (or should wait). The security can also be enhanced by having the HTTP traffic encrypted by SSL to prevent a black hat of sniffing the net. I wouldn't use S/Key for logging into a system on its own, but combined with a second authentication vector (e.g. using a challenge response sent via SMS to a cell phone) would create a nice 2-vector authentication mechanism (handy for situations like Internet Cafe's where you run the risk of being subjected to a key-logger).