Eduroam accounting

CESNET technical report number 38/2007
also available in PDF, PostScript, and XML formats.

Daniel Studený
27.12.2007

1   Abstract

The eduroam network is based on mutual trust of interconnected organisations; still, avoiding improper network behaviour of all WiFi workstations is impossible. Such a behaviour may be caused by malware which has infected some workstation and which its user does not know about. For fast incident resolution and for early disconnection of compromised workstation till the problem is solved, a system should be ready in which local supervisor can easily and quickly find all information needed. This report describes a possible solution of an eduroam accounting system implemented at the CESNET Association headquarters.

Keywords: Eduroam, RADIUS accounting, DHCP, dynamic DNS updates, zone change notification

2   Introduction

Raw accounting information comes from access points via the RADIUS protocol to a configured RADIUS server. Any RADIUS server can log accounting records using several methods, e.g., by storing them in a file or database where the records can be browsed using text viewing and processing utilities or using an SQL client, respectively. This solution is very simple but it has several disadvantages. The most significant is that access point does not know the IP address of the workstation being connected and so this IP address can not appear in accounting records. This is because the 802.1x protocol performs user authentication before the IP address assignment using the data link layer of OSI model. Accounting records contain only hardware addresses and this often does not suffice to look up the compromised workstation. As a result, IP addresses must be drawn manually from other sources, e.g., from the DHCP server leases file.

Another significant disadvantage is the need for skilled staff to solve the problem. Therefore, an application is needed whereby its operators find compromised workstation owners using just the reported time of incident and workstation IP address to hand over the problem to the appropriate realm administrators.

3   System Design

A system is needed which processes start and stop accounting records, couples them and appends an IP address obtained from the DHCP server. In addition to the RADIUS accounting data, records of the webpage user registration system previously known as eduroam-simple, currently detached from roaming for security reasons, must also be processed. The system must contain a viewer part which presents the accounting data in a user-friendly form. A simplified system data flow diagram is shown in Figure.

[Figure]

Figure 1: Eduroam accounting data flow diagram

3.1   RADIUS Server Configuration

The RADIUS server which is used primarily for user authentication should be configured to transmit the accounting records. For Radiator, the RADIUS daemon used in our eduroam implementation, this could be done by customising the accounting handler lines in the RADIUSd configuration file as follows: 

<Handler Request-Type=Accounting-Request>
        AcctLogFileName /var/log/radiator/radiator.acc

        <AuthBy RADIUS>
                <Host 172.16.16.16>
                        AuthPort                1812
                        AcctPort                1813
                        Secret                  xxxx
                </Host>
        </AuthBy>
</Handler>

Request-Type=Accounting-Request in handler configuration ensures that all incoming accounting records will be processed by the handler. AcctLogFileName saves accounting information in a RADIUS server local file. AuthBy Radius section simultaneously transfers records to a specified accounting server running Radiator too. AuthPort may seem unnecessary because no authentication requests are sent but still it must be given.

3.2   Webpage Registration Firewall Configuration

Webpage WiFi registration has many possible implementations. Basically, the user authentication data together with the MAC address in firewall filtering rules is used. Successful registrations may be recorded in firewall local accounting and again simultaneously transferred to the accounting server. Various protocols for transferring the accounting information can be used. In our implementation, accounting data is sent to accounting server using HTTPS POST requests for historical reasons. The RADIUS protocol would be more suitable but HTTPS is safe and it is easy to support it on the accounting server side.

3.3   DHCP Server Configuration

Appending the IP addresses to accounting records was the biggest problem of the eduroam accounting system design. As mentioned before, the IP address is not known at time of user 802.1x authentication; it must be obtained from a DHCP server. The DHCP server is the first system which knows about IP address assignment and which must invoke the accounting record supplementing. In our eduroam implementation we have a linux box with ISC DHCP server, so we had two alternatives: Either we could patch the ISC dhcpd, or we could somehow use the dynamic DNS update mechanism which - in conjunction with DNS notification - is the only way for the dhcpd how to inform about a new IP address assignment. In order to have the whole system upgradable, we chose the second alternative.

Dynamic DNS update as described in [rfc-update] allows adding A records to a DNS domain during DNS server runtime. That directly allows recording an assigned IP address but not the MAC address which is also needed for coupling with an appropriate accounting record. As ISC dhcpd allows using the workstation MAC address in its name definition, hardware addresses can be saved in the A record domain names. In our implementation, domain name server for domain containing these MAC - IP address pairs is running on the DHCP server as well. Domain names for records are chosen from non-Internet, translation.table.mac (??). The dhcpd configuration for a sample WiFi network 192.168.168.0/24 is shown below: 

ddns-updates off;
ddns-update-style none;
update-optimization off;
deny client-updates;

on commit {
    set new-ddns-fwd-name = concat(
	binary-to-ascii(16, 8, ":", hardware), ".",
	pick(config-option server.ddns-domainname, config-option domain-name));
    switch(ns-update(delete(IN, A, new-ddns-fwd-name, null),
	add(IN, A, new-ddns-fwd-name, leased-address, lease-time / 2))) {
        case NOERROR:
            unset ddns-fwd-name;
            on expiry or release;
    }
    unset new-ddns-fwd-name;
}

key MACTBL {
    algorithm HMAC-MD5.SIG-ALG.REG.INT;
    secret XXXXXXXXXXXXXXXXXXXXXXXX;
}

zone translation.table.mac. {
    primary 127.0.0.1;
    key MACTBL;
}

subnet 192.168.168.0 netmask 255.255.255.0 {
    ddns-domainname "translation.table.mac.";
    ddns-hostname = config-option host-name;
    range 192.168.168.10 192.168.168.250;
    ...
}

First, automatic DNS updates in the above sample configuration must be disabled. We perform the updates ourselves after the commit event section which creates the host domain name from the workstation hardware address and updates the corresponding A record. Deleting expired and released records is not necessary. The zone and key sections define the domain for dynamic updates, its nameserver and shared key for communication with it. Last, dynamic DNS domain name and hostname are specified within subnet definitions.

DNS server configuration must be set up accordingly. If the ISC BIND is used, the following lines must appear in our sample network named.conf file: 

key MACTBL {
    algorithm HMAC-MD5.SIG-ALG.REG.INT;
    secret "XXXXXXXXXXXXXXXXXXXXXXXX";
};

zone "translation.table.mac" IN {
        type master;
        file "mac.table";
        allow-update { key MACTBL; };
        notify explicit;
        also-notify { 172.16.16.16; };
};

Sample IP address 172.16.16.16 in the above configuration belongs to the accounting server. Due to the also-notify statement, the accounting server is informed about zone changes, i.e., in our model, about new IP address assignments. It is done using the DNS notify message as described in [rfc-notify].

3.4   Accounting Server Configuration

3.4.1   RADIUS Server Configuration

As mentioned before, a RADIUS server must be configured and running on the accounting server to receive records. The Radiator runs on the RADIUS server as well as on the authentication server, a MySQL database engine is used for accounting records storage. The following Cisco-AP attributes are stored in each SQL record:

Wireless routers by Cisco store the workstation MAC address in the Calling-Station-Id attribute. Start and stop records differ in the Acct-Status-Type attribute.

3.4.2   Receiving Accounting Records from the Webpage Registration System

An Apache HTTPS server and PHP script receive the webpage registration accounting data. Incoming records are simply written into the MySQL table in a format similar to Radiator. The only difference is in the IP address field: it is filled in the webpage registration table but initially empty in the 802.1x table.

3.4.3   IP Address Assignment - the notifyd Daemon

A notifyd daemon written by this author adds the workstation IP address to the RADIUS records. This daemon implements a small part of DNS server - it listens on UDP port 53 and waits for an incoming DNS NOTIFY message. Having received it, i.e., after new DHCP request is processed, a reply is sent to the nameserver and an external script is executed which performs DNS lookups for all accounting records with IP addresses missing.

3.4.4   Accounting Records Coupling

To be able to present full information about connected users, all accounting data must be processed and corresponding start and stop records must be joined. This is a task for a standalone PHP script in our system which is launched periodically. It couples records according to the Acct-Session-Id and NAS-IP-Address attributes and also according to the authenticated user name and its hardware address.

RADIUS is a UDP protocol and wireless routers sometimes do not send accounting packets; as a result, not every start record has its stop record and vice versa. Hence, e.g., a start record followed later by another start record with the same key attributes such as Acct-Session-Id and NAS-IP-Address but, e.g., with another hardware address is regarded as a start record with lost stop record and with reason for disconnection set as unknown. Similar orphaned accounting records often occur if the user switches to another access point; they can not be processed easily.

3.4.5   Accounting records received from Wireless Controller

Wireless controller is a device which manages all access points within the premises. It performs everything on behalf of access points and it also sends the accounting packets. The entire communication between access point and user station goes through the wireless controller and so it can and does catch also the DHCP requests and replies. In our WiFi network, a Cisco 4402 Wireless LAN Controller is used which sends differently filled accounting records. While the Acct-Session-Id attribute hides hardware addresses, the Calling-Station-Id attribute contains an IP address captured from DHCP communication. Just like in case of webpage registration accounting, inserting these records is sufficient.

3.5   User Interface

This author has also developed a record browser application which allows the operational staff to easily find any information about the owner of the compromised station. The second version of this application allows paging with user-settable count of records per page, record filtering and realm administrator contact lookup for national roaming users. Figure shows lookup of one IP address utilisation during a given day.

[Figure]

Figure 2: Eduroam accounting record browser (large image)

4   Conclusion

The eduroam accounting system described above and developed by this author has been used successfully by the CESNET Association for almost two years. It helps looking up compromised workstations in case of abuse reports from Intrusion Detection Systems. It also helps solving connectivity problems caused by 802.1x supplicant misconfiguration or WiFi network malfunction. The whole system is still being improved and its development has not finished yet by far. I hope our solution will help other eduroam administrators in building their own accounting systems.

References

[rfc-notify] Vixie P.: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY), RFC 1996, IETF, August 1996.
[rfc-update] Vixie P., Thomson S., Rekhter Y., Bound J.: Dynamic Updates in the Domain Name System (DNS UPDATE), RFC 2136, IETF, April 1997.
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz