This technical report describes the physical and configurative set up of FreeBSD machines to simulate Remote Authentication Dial-In User Service (RADIUS) authentication and authorisation for the LIFE project. This set up will be used to conduct user identity traffic interception tests.
In real-world Point-to-Point (PPP) dial-up connections customers use modems to dial-in to their Internet Service provider (ISP) and access network resources. To initiate dial-up a customer enters their username and password then dials-in to their ISP via a specified telephone number. The dial-up request is directed to an ISP's Network Access Server (NAS). The NAS will not allow the customer to access network resources until they confirm the customer has an account. The NAS contacts a RADIUS server to request authentication of the customer and upon confirming the customer username and password are valid, the customer is allowed to complete their PPP connection. Typically the customer is also allocated an IP address by the RADIUS server.
In this report we simulate a user machine initiating a PPP connection to an ISP NAS and having their username and password authenticated by a RADIUS server, upon which they are allowed to access network resources through the NAS. The configuration and set up were kept simple and the accounting feature of RADIUS was not used as it is not important to our aim.
Equipment and Setup
In order to simulate user dial-in we used PPP to create a tunnel (tun0) between the user machine and the NAS. During PPP dial-in, the username and password is sent to the NAS via either Challenge Authentication Protocol (CHAP) or Password Authentication Protocol (PAP). The NAS fowards an Access-Request message to the RADIUS server. If the username/password combination is not listed in the "/usr/local/etc/raddb/users" file, the RADIUS server will send an Access-Reject message to the NAS and the user machine is denied dial-in. If the RADIUS server approves the username/password combination it will send the NAS an Access-Accept message and the PPP connection will be completed. The private IP addresses used for the PPP tunnel are translated by Internet Protocol Network Address Translation (IPNAT) to the public 188.8.131.52 IP address and the user is then able to access the Swinburne University ITS network through the NAS.
Figure 1 shows the physical and logical IP address set up used.
Figure 1: Hardware Setup and IP Address Allocation
The following is a list of hardware and protocols used:
- User Machine
- OS: FreeBSD 4.9-RELEASE
- PAP and CHAP enabled
- NAS / RADIUS Client
- OS: FreeBSD 4.8-RELEASE
- PAP and CHAP enabled
- RADIUS Server
- OS: FreeBSD 4.9-RELEASE
- FreeRADIUS 0.8.1
- Alloy NS-08C 8-Port 10/100Mbps NWay
The following are the configurations used to achieve RADIUS authentication and authorisation for the set up in Figure 1:
RADIUS Server Configuration
RADIUS Client Configuration on the NAS
IP Network Address Translation on the NAS
User Machine Configuration
There are some alternatives to our set up that were not explored. Our aim was to create a small, minimum configuration PPP/RADIUS system using FreeBSD machines. Some alternative ideas are explored below.
Most real-world NAS' aren't built with FreeBSD. They are dedicated machines that a vendor can develop to, for example, have inbuilt DHCP servers for address allocation. To provide this level of simulation on FreeBSD, we would need either more configuration effort or modification of the FreeBSD PPP source. Also, some real-world NAS' have multiple Ethernet ports so that they can have an interface to the "network resources" that a user would access and another interface to the ISP's private servers.
Serial links may have been used to connect the user machine to the NAS. This would be implemented if the NAS did not have more than one NIC and is a viable alternative, even though it would limit the NAS to support one user connection.
In our system we only incorporated one user machine. To support multiple machines, the fxp1 interface of the NAS would be subnetted and the user machines allocated IP addresses on this subnet for their PPP connections.
Since our system supports only one user, the FreeBSD machine acting as our RADIUS server is not required to be high performance nor run the latest FreeRADIUS version. It would, of course, be appropriate for a real-world RADIUS server to be a dedicated machine with enough performance capabilities to easily support all users with accounts. It would also be ideal for the RADIUS server to have a separate database of users and their accounting information, as well as the ability to allocate IP addresses upon user authentication.
The set up described in this technical report is a simple dial-in and RADIUS authentication and authorisation system. It is comprised of a user machine initiating a PPP session to a NAS which then authenticates the user by contacting the RADIUS server. It was seen in this report that the private IP addresses created by the PPP tunnel must be translated to a public IP address in order for the user to communicate with network machines via the NAS. The system was set up in order to simulate a simple ISP and how the identity of a user is established and to demonstrate how it could be done with FreeBSD machines.
Further investigation will include conducting lawful interception trials using this set up by attempting to mask the identity of a dial-in user to avoid traffic detection. This will involve using tcpdump to capture packets as they pass over the NAS or on a separate machine connected to the switch.
Grenville Armitage, Director of Centre for Advanced Internet Architectures and Daniel Trembath for their ideas and assistance.