SPLIT- An ISPs Interception
Tool based on RADIUS Authentication
CAIA Technical Report 040220B
February
20th, 2004
Introduction
This report summarizes the rationale, design and use of the split tool. split stands for Service Provider's Lawful Interception Tool.
The tool supports the analysis of typical ISP solutions for Lawful Interception. It performs the same role as current proprietary LI solutions in that it will allow the interception of a user's traffic based on the IP address reported via the RADIUS protocol.
The tool is based on the use of the pcap library and is part of the LIFE (Lawful Interception For Everyone) project at the Centre for Advanced Internet Architectures (CAIA) at Swinburne University of Technology.
Background
Lawful Interception (LI) is a requirement placed on communications providers by governments. LI is an important tool for government agencies and is used to intercept the communications of targets for the purposes of criminal investigation and national security.
For decades LI was the responsibility of telecommunications carriers. However, with the increased use of the Internet and the variety of ways that users can access the different communications methods that it provides, the requirement for interception is shifting from access networks to service provider's networks.
As elaborated in Lawful Interception of the Internet, the products that are being used to provide LI functionality to service providers are a cause for concern as they are proprietary, complex and non standardised.
In a typical situation and one which the split tool examines, a special traffic sniffer is installed in an ISP's network which captures RADIUS messages between the NAS (Network Access Server) and the RADIUS server. RADIUS (Remote Access Dial-In User Service) is a protocol used by ISPs that verifies and authenticates a user based on the method of challenge/response and allocates an IP address to that user. RADIUS is described in a set of RFCs of which RFC2865 is a starting point. RADIUS by Hassell is a good resource for everyday use.
The ISPs sniffer listens for a RADIUS Access-Request and Access-Accept message pair for the user(s) that it is configured to intercept. Inside the Access-Accept message, the IP address that is assigned to the user is present and is used by the sniffer to reconfigure itself to also capture any traffic to and from that IP address.
Rationale
The principle reason to implement a tool which would mimic the functionality found in existing proprietary solutions to LI for ISPs is as a learning experience. Although the proprietary solutions are to an extent hardware based, designing a software based tool which is similiar in function is an important first step in understanding the complexity of LI solutions which are based on RADIUS authentication.
The tool could also play a part in supporting the LIFE project at CAIA which aims at researching secure, robust and open solutions to LI for ISPs. The tool could be used in performing tests which could provide an insight into how effective or robust the scheme of deriving an IP address of a target based on RADIUS authorisation is.
It should be noted that the tool is not intended to be actually used by an ISP to provide it's LI function. The tool is too naive and has not been tested to a production standard.
Design Outline
The tool's design is composed of a number of small modules, shown in figure 1. Each module is summarised in the following paragraphs.
Figure 1 - split
architecture
The split_client module is responsible for analysing command line arguments, presenting the user interface and updating the model with usernames that should be added or removed. The user interface is launched as a separate thread so that it is independent from any processing done by packet handling. Adding and removing usernames to/from the model is also achieved through separate threads so that there is no delay to the user interface.
The split_model module has the responsibility of managing which usernames are being intercepted. It is implemented simply by having an array in memory with the usernames currently being monitored. A mutex lock is also used to prevent multiple threads accessing the list at the same time from corrupting it's contents.
The split_backend module is concerned with the management of the pcap library. It starts packet capturing when at least one username is to be monitored, stops packet capturing when there is no usernames to be monitored, and also sets the dynamic filter string that the pcap library uses to select packets. This filter string is dynamic in that it can be affected by the number of usernames being monitored, and also by the interception of a RADIUS Access-Accept message with an assigned IP address for one of the usernames being monitored. When one of these IP addresses is reported (by the split_radius module) the filter string is updated. The module also handles the saving of a user's traffic into their respective traffic files.
The split_pkthandler module receives all communication about captured packets from the pcap library: it implements the pcap "callback" as needed by the pcap library (pcap is maintained by the tcpdump group , man page) . When a packet is reported by the pcap library, split_pkthandler will analyse the packet's link layer information, check whether it is an IP datagram and also resolves to hand the packet to the split_radius module if RADIUS/UDP is being carrired over IP. It will then ask split_backend to save the packet into it's corresponding file. Link layers which are supported are ethernet and loopback (for testing purposes).
The split_radius module, as the name suggests, handles the analysis of RADIUS packets. It will examine Access-Request RADIUS messages, checking for a "User-Name" attribute and cross-referencing the attribute value with the usernames being maintained by split_backend. If there is a match then split_radius waits to receive an Access-Accept RADIUS message in reply to the Access-Request for this username (there is a convenient ID in RADIUS messages which enables the matching of requests to replies) .
When split_radius receives an Access-Accept, it checks for a "Framed-IP-Address" attribute and then asks split_backend to start capturing packets for the IP address found therein.
There are some limits that have been defined in the implementation (see split_model.h) which may be modified. For example, the number of monitored users has been capped at 10 and the maximum length of usernames is 30 characters.
Installation
The split source can be downloaded from http://www.caia.swin.edu.au/life/life-techniquesandtools.html. It can then be installed as follows.
The distribution should be unpacked into a directory which is normally used for keeping source code. For example:
%cd ~/src
%gzip -dc split-x.x.x.tar.gz | tar xvvf -
This should have created a directory called split-x.x.x in which all the source code of split is stored.
Edit "Makefile", enabling/disabling any options which seem necessary for what you intend to do. It's a very simple Makefile, so there aren't too many options to fiddle with.To compile, simply use "make" from the command line. If all goes well, a binary will appear in ./bin called "split". You can move this binary to wherever you want (eg. /usr/local/bin ).
There is also a ./doc directory in which there is some moderate documentation on the use of the utility.
Operation
The split tool maintains a list of usernames to be intercepted. Usernames can be added/removed/listed using the tool. If a username is added, the tool will listen for the RADIUS Access-Accept packet which corresponds to the user's login attempt being accepted and which carries an IP address to be assigned to the user. The tool will then capture all traffic to/from that address and save the traffic in a file.
The split tool should be installed on a machine which can "see" the traffic to/from the RADIUS server. In a typical ISP network it would be installed on the same network segment as the NAS and RADIUS server.
There are some command line options that change the default behaviour. The command line syntax of the tool is shown in the following screen shot.
-i <device> Specifies the device to use for packet capture, just like in tcpdump.
-u <user files dir> Specifies the directory to place users' traffic capture files. The format of the filename generated is username.pkts.XXXX where XXXX is a random string. This is to prevent a user's traffic file from being overwritten if the tool is re-launched or a username is removed and then added. The file is a tcpdump/pcap compatible dump file.
-f <log file> Specifies the file to use for debugging information generated by the tool.
When the split tool is invoked the user enters the split shell, denoted by the character ']'. From this shell, usernames can be added, removed or listed. The following screen shot shows the help message which is printed when the user types the 'h' command (help) within the shell.
Use the 'a' command to add a username, and the 'r' command to remove a username. The 'l' command will list all username's being monitored. The 'q' command is used to quit.
Since the tool is designed to work with a loopback link layer, to test the tool we can use it on a machine, and install FreeRADIUS on the same machine to provide both a RADIUS client to simulate the NAS (radtest) and the RADIUS server itself. FreeRADIUS can be installed from the ports collection under freeBSD.
The first step in testing the tool is to configure FreeRADIUS and start the RADIUS server. Configuration of FreeRADIUS is beyond the scope of this report. The usage page at freeradius.org contains some quick help, though probably the best information is found in the radiusd.conf and users configuration files.
After modifying the "users" file with an entry for username "steve" with password "testing" (existing example in the file can be un-commented), the RADIUS server can be started using the following command.
%/usr/local/sbin/radiusd -d /usr/local/etc/raddb
In the next screen shot, split is launched using lo0 (loopback device) as the device to use for capturing packets, and the username "steve" is added using the split 'a' command. To confirm this, a listing of all usernames that are being monitored is requested using the split 'l' command.
To simulate "steve" attempting to login to use the ISP's services, we can use the radtest utility which comes with FreeRADIUS. When the following command is executed, a RADIUS Access-Request message is sent to the RADIUS server, and an Access-Accept message is sent back (if server is properly configured).
split should intercept both these messages and re-configure itself to capture traffic to and from the IP address reported in Access-Accpet's Framed-IP-Address attribute. Both messages can be seen in the next screen shot.
At this point, steve's traffic is being intercepted and saved in a file called /tmp/steve.pkts.XXX. To test this simply generate some traffic on the lo0 interface, for example, by pinging 127.0.0.1. The traffic file can be viewed by tcpdump, ethereal or any other packet analyser which supports the pcap/tcpdump format.
