Dealing with Public Ethernet Jacks - Switches, Gateways, and Authentication.

Bob Beck
- University of Alberta

Abstract

This paper describes the tools and techniques developed and deployed to address the problem of blocking unauthorized users on unprotected Ethernet jacks. Our solution is being deployed to control public labs at the University of Alberta during the summer of 1999. In this environment, we have a mix of "walk up" Ethernet connections used for laptop computers, and public Windows 95 and 98 workstations. By themselves, none of these provided adequate facilities for preventing unauthorized Internet usage and enabling us to track Internet abuses originating from the facilities. Prior to this new deployment these networks were not routed off of our campus due to these problems. Our new deployment consists of MAC-locked switches behind a gateway in which Kerberos logins control an IP filter that allows access out when authenticated. Now, we allow the legitimate users full access to the internet once authenticated, and can keep unauthorized people from plugging in for free internet access. This also gets us a record of activity for the legitimate users so that abuses can be easily tracked. We also have several transparent proxies on the gateway machine to assist us in handling particularly troublesome security and configuration issues relating to the internal lab. This allows us to proxy outbound IMAP, SMTP, and HTTP requests, as well as answering IDENT requests coming in to the lab with the real user. The solution is inexpensive and easy to deploy, using off-the-shelf switches and a gateway router running a free operating system and software.

The Problem of Public Labs and Unsecure Ethernet Jacks.

Public labs and their use by students has always been an issue in a university environment. The first goal of the labs is always to allow students to learn, and offer them every amount of freedom possible to do so. At the same time, there is great potential for abuse where public lab machines can be used to attack other sites. If there are no access restrictions and no monitoring, people off the street can walk in and obtain free Internet access. University students can also usually be counted on to take advantage of a chance to cause mischief that they won't be held responsible for. Before the days of laptops, this problem had been addressed in our environment by allowing unrestricted net access only via machines running multiuser operating systems such as Unix, assigning logins, and using a variety of tools to enable the behavior of the users to be monitored to some degree. This also ensured that only someone in possession of a legitimate login id and password could use the facilities. In this traditional model, system administrators maintained administrative control of the machines, and ran an Operating System (OS) allowing them to control the privileges of the users. Access to the Internet was controlled by access to the machine. With the more common use of laptops and the requirement to run unsecure PC desktop operating systems like Windows 95/98 in public places, this solution was no longer possible. A new solution was needed that preserved the ability of the users to do what they like on the net, but maintain accountability for what they do, even with users plugging their own machines into the local network.

The Requirements for a Solution.

We decided early on that a solution for us would need to have the following properties:

Our solution uses an authenticating gateway router. The gateway is configured using packet filters to block all traffic from the lab network by default. The switches in the lab allow the user to connect to the gateway router. A user gets Internet access by opening a telnet connection to the gateway, and then authenticating with a Kerberos id and password. Successful authentication creates a packet filter rule that permits the user to route through to the Internet, as long as the telnet connection remains open. When the authenticating telnet connection is closed, the filters are removed, so Internet access from the connecting address is no longer allowed. The gateway logs all the TCP connections to the internet, as well as the login/logouts of each user.

Switches

All our public labs have been configured to use a switched Ethernet network. Properly configured, these will normally ensure that traffic will remain separated, and that a user on one port of the switch will not be able to see or gain control of traffic from a user on another port of the switch.

For the public PC labs, the configuration of the switch is relatively simple. We set our switches to enable sticky learned port security, effectively tying each port to one Ethernet address. The port is then disabled if the Ethernet address is changed. [Cisco1997]

For the unsecure Ethernet Jacks used with a laptop, this doesn't work. We need to have the ability for an Ethernet address on a port to change, so the switch must be set to learn new addresses as someone plugs a new machine into a port. This creates a problem. Most switches (including ours) will by default flood unknown unicast packets to all ports. This means that if an attacker can make a legitimate user's Ethernet address unknown (usually by sending many new addresses down a port for a switch to learn) he will then see traffic for the legitimate user as it is broadcast out all ports. This can cause problems with our use of an un-encrypted telnet session. To prevent this we disable unicast flooding on the switches. [Cisco1997] With unicast flooding disabled, unknown unicast packets are dropped by the switch, changing this sort of attack from a potential attack to compromise user passwords and authentication to a merely annoying denial of service.

An Authenticating Gateway

For the gateway we had to implement software to authenticate users and manage the packet filters. We chose to do this on OpenBSD, as it was the only free choice that had all the relevant pieces we needed in the OS, and had an emphasis on source code audited for security, with the sources available for us to modify to suit our needs. We configure the ipf packet filtering facilities in OpenBSD to, by default, block all traffic originating from the lab side of the network. We then wrote a small program and modifications to /usr/bin/login so that the users could telnet to the gateway and authenticate to get Internet access.

When the user authenticates, a program authipf is run which does the following:

For authentication, our campus already makes use of Kerberos. We have an existing user base of approximately 50,000 accounts, one for every student and staff member. We did not, however, want to manage accounts on the lab gateways, since users there did not require login access to the machine, only the ability to authenticate. We modified OpenBSD's login program slightly for our purposes. The changes were very simple:

With these pieces in place, we have everything we need to control and log the outbound Internet access from the lab, ensuring only authorized users are able to access the Internet. Legitimate users simply open a telnet connection to the gateway and authenticate. As long as the user leaves open the telnet connection to the gateway, the gateway allows their traffic to pass. As soon as the user is disconnected from the gateway, traffic is no longer allowed to pass. The user needs nothing special beyond a telnet client on their machine.

Problems, and Solutions.

One problem we encounter with Ethernet jacks in a public place is that of users unplugging their laptop from the net and walking away without closing the session. In this case, we need the gateway to know that the user has gone away, and to remove filter rules allowing their machine access to the Internet. We tuned the TCP KEEPALIVE values on the gateway machine to ensure that sessions would be expired promptly should the user unplug a laptop and walk away. We decided that for our purposes it was adequate for connections of this type to go away in under a minute.

Another possible problem is a user injecting bogus ARP replies into the network to take over an IP address. This is a problem, since our authentication of a user is based on the IP address they are using. OpenBSD itself watches and notices in the syslog when ARP values change. While this is a regular occurrence in a plug-in environment, it can also be used as an attack. To handle this, we can use Swatch [Hansen1993] to watch the logs for the ARP entry being overwritten for a particular IP address, and then ensure that any running authipf process for a particular IP address is killed, so the IP address is not allowed to pass to the Internet until it authenticates again. While this creates a possible denial-of-service attack within the lab, it does not allow a user to inject bogus ARP replies into the network and take over an authenticated IP address to gain Internet access. As soon as the gateway detects the change in the ARP table entry, any old authentication info and filters for that IP address are removed.

Further support for the lab environment.

With one gateway machine and switches, we now have a "one-box" solution to our public laptop needs. We simply run dhcpd on our OpenBSD gateway to provide DHCP [RFC2131] service to laptop clients, in addition to acting as the authenticating gateway.

The gateway machine also proxies inbound IDENT [RFC1431] requests, and answers them on behalf of the internal clients. We run IDENT servers on most of our centrally administered machines so other on-campus machines may query the IDENT server to learn the identity of a remote user. On our gateways, we capture IDENT requests for the client addresses and we then answer them with the username used to authenticate out, enabling remote system administrators to query for and obtain user names using IDENT when they receive connections from our labs.

For some of our locations, we gain some additional security and ease of client configuration by storing the user and password information on the gateway and using this in transparent proxies. On the gateway we are able to catch and proxy IMAP [RFC2060] protocol connections to our central IMAP server. We have a simple proxy which watches for the IMAP LOGIN command, and replaces the arguments to the command with the user's real login ID and password, as used to authenticate from the connecting address. We also intercept outbound SMTP [RFC821] access to our central SMTP server, replacing the sending address with the user's real e-mail address (derived from the login they used to authenticate). While the ability to do this has some interesting security implications, we do it mainly to allow easy set up of an e-mail client in the PC labs, so that the configurations of the client don't need to change from user to user.

Problems this doesn't solve

Many people have been, and continue to be, concerned that this does not address the issue of "What if the user gets up and walks away". The filter rules are not tied to any sort of activity monitoring to detect an active or idle connection and timeout, although authipf has an optional overall timeout value. We chose not to implement an activity based timeout for several reasons:

This does not address several denial-of-service issues or problems of intra-lab abuse (from one workstation to another). These are addressed by more traditional (technical and non-technical) means in our labs.

It is important to remember that this is a method for providing authenticated Internet access. It does little (or nothing) for the security of the individual client stations. (If the bad guy is already on the user's laptop or PC, this doesn't help much).

Conclusions

We have so far been very happy with the level of control this system has given us when deployed in front of our unsecure public places. It is entirely based on free software, works well in our fully switched environments. It integrates well with our Kerberos authentication (and could be easily made to work with others). It allows the users full network access, and does not require any custom software on the client machines at all. User training has been relatively painless, consisting of a poster at the front of the lab, as well as an icon added to the standard desktops of the workstations. The system completely prevents unauthenticated users from using public Ethernet jacks to gain Internet access. The logging produced as a bonus is thorough and usable to track abuse by authenticated users very effectively when a complaint is received. With the addition of the IDENT proxy, many complaints have already been resolved without even resorting to the logs ("Yes, you can believe the IDENT - thanks"). If you are looking for a solution to dealing with public Ethernet jacks and Internet access, this is a great solution that scales very well, at very little cost.

References

[Cisco1997] Catalyst 1900 Series Installation and Configuration Guide, Part Number 78-4362-01, 1997, Cisco Systems Inc.
[Hansen1993] ``Automated System Monitoring and Notification with Swatch'', Stepen E. Hansen, E. Todd Atkins USENIX Association's Proceedings of the Seventh Systems Administration (LISA VII) Conference pp. 145-155
[RFC2060] RFC2060: Internet Message Access Protocol - Version 4rev1 , M. Crispin, December 1996.
[RFC2131] RFC2131: Dynamic Host Configuration Protocol , R. Droms, March 1997.
[RFC1431] RFC1431: Identification Protocol , M. St. Johns, February 1993
[RFC821] RFC821: Simple Mail Transfer Protocol , J. Postel, August 1982.