about-core

22 - STUDENT - Layer 2 user isolation in Eduroam.si

Marko Dolničar (University of Ljubljana)

Layer 2 attacks on IPv4 and IPv6, such as MITM with ARP poisoning, rouge Router Advertisements, spoofed Neighbor Advertisements and other similar attacks are still a threat to modern computer networks. The problem persists, because the layer 2 protocols (ARP) were not designed with security in mind. In our previous work we have shown that these attacks are still possible in most of the eduroam networks in Slovenia. The use of PVLANs can help us achieve Layer 2 host isolation for wired clients. The major drawback of PVLANs is that they cannot be used for Layer 2 isolation on autonomous access points. Since Eduroam networks are wireless in most cases this technique cannot be used for user separation. Another way to achieve user Layer 2 separation would be the bridge-group port-protected command on Cisco access points. Most autonomous access points used in Slovenian eduroam networks support this command. The port-protected command disables all unicast, broadcast or multicast traffic between hosts and thus also breaks legitimate traffic between them. In our test we have connected 2 hosts to the access point and started the Filezilla FTP server on host A and the Filezilla FTP client on host B. Without the bridge-group port-protected command the connection and file transfer were both successful. With the command enabled the connection was not possible. When we enabled the command during a file transfer, the transfer would stop. Our test showed us, that bridge-group port-protected was not suitable for eduroam networks. The concept of assigning each user to a separate VLAN and thus creating the Layer 2 separation between different users was presented at TNC2012. Our idea emerged during the discussion of our previous work with the author of the presentation – Eric Vynke as the concept of user VLAN separation would prevent our attacks. In an environment where VLAN separation is used, user A connects to the access point and is assigned to a VLAN (e.g. 200). When another user B connects to the same access point he is assigned to a different VLAN (e.g. 201). They can communicate with each other only through Layer 3. This way the Layer 2 based attacks should become impossible. We have set up our testbed eduroam environment following our NREN’s instructions. The equipment used was a Cisco Catalyst 3560G switch and a Cisco Air-AP1242AG access point. For the one VLAN per user scenario to work in our testbed we had modified the settings on the switch and the access point. The access point needs to have a separate VLAN enabled for each user. VLANs have to be configured on the Dot11Radio interface as well as on the FastEthernet interface. The same VLANs must be configured on the switch to successfully route and terminate the VLANs. One problem of using a separate VLAN for each user is the waste of the public IP address space that is usually used by the eduroam networks. Each VLAN requires at least two IP addresses – one for the client and one for the Layer 3 switch. In practice a /30 netmask has to be used to preserve the network and broadcast addresses, which means 4 IP addresses are used per user.
This problem can be solved with NAT, so users are assigned an IP addresses from the private address space. The use of NAT has its drawbacks as all incoming connections are terminated at the device doing the address translation and so our services, like the FTP server in previous example, would not be accessible from the public Internet. This limitation could be solved with the use of 1:1 NAT, which would map a single public IP address to the user’s private address. In this scenario the user keeps the public IP connectivity and the infrastructure (VLANs) does not waste any extra public address space. Due to the limitations of our setup we have not yet been able to test this thoroughly. With the access point and the switch configured for multiple VLANs we extended the DHCP server configuration with as many subnets as we had configured VLANs. Next, we wrote a small python script that maps free subnets (subnets not currently leased to clients through DHCP server) to free VLANs and writes the free VLANs to a text file. The identification of free subnets in the script is done by parsing of the output of dhcpstatus. FreeRADIUS configuration was modified to execute a bash script which determines the next available VLAN from the text file and echoes it back to FreeRADIUS. The script then deletes this VLAN from the text file so it cannot be assigned again. FreeRADIUS assigns the VLAN, which was echoed from the script, to the user in the “Post-Auth” process by updating the reply message with VLAN attributes.
Once the setup worked and each user was assigned in their own subnet we tested the MITM attack with ARP poisoning on IPv4 and the Rouge RA attack on IPv6. As expected the attacks were not successful any more.

Download file

Posters