Lately I've been brainstorming some ways to improve management of the community lab. Foremost on my list of things to do is implementing a more automated method of deterring lab abusers, and I wanted to share my ideas with the community before moving along with implementation.
See, the problem with making a collection of several thousand dollars worth of hardware accessible by anyone, anywhere, for free is this: some people are douchebags. For these people, six hours of free lab time every couple weeks apparently just isn't enough. They opt to create two, three, or more reservations for themselves under multiple user accounts. I've gotten word that some people are so bold that they then attempt to sell their reserved lab time on certification forums.
Up until now, I have been dealing with lab abuse manually. Whenever I get an alert informing me that a lab reservation looks suspicious, I log into the administrative interface and determine whether it looks like someone is creating multiple reservations If so, the reservations and associated user accounts are deleted, and the IP prefix(es) from which the reservations were made are blacklisted, both from the reservation system and from the lab console server itself. This has worked fairly well over the last year or so, but is rather annoying and time-consuming (more so lately, as the frequency of lab abuse seems to be increasing).
It also results in part-amusing, part-enraging emails like this one:
today i was shocked when i saw that my prefix is banned for abuse
really i didn't know that if i create more than one account to make more reservation, it means abuse.
really i didn't know and i didn't mean that
I've come up with a few potential solutions, some more practical than others. Others have also suggested solutions which I'll list here.
Charge a fee for lab access
I hear this suggested a lot, and I always turn it down for three reasons. First, charging a fee, however minute, would defeat the concept of a free training lab. There are a number of professional lab providers for people interested in a paid service. Second, many people, particularly those in developing countries, don't have the means to pay even a minimal charge (e.g. a credit card accepted by a US payment processor). And finally, I don't want the headache of dealing with demands for refunds when people can't access the lab or don't care enough to show up for their reservations.
Tie user accounts to something unique and not easily duplicated
If you can think of such a thing that is unique and easily verified worldwide, for free, I'm all ears.
Block a handful of /8s from problematic regions
At the time of writing, 78 IPv4 prefixes are blacklisted from accessing the lab. 41 of these originate in the APNIC region; at the top of list are India, Pakistan, and China. Blacklisting all /8s from this region would be trivial to accomplish and reduce the number of manual investigations I have to perform by more than half. It would also mean the lab would be inaccessible to anyone in that region of the world.
Is it fair? Absolutely not. But I'm mentioning it here as a possible solution so people understand the difficulty of the problem.
Tie lab authentications to the IP addresses from which reservations are made
Before exploring this solution, let's recap how the lab scheduling system works. Lab reservations are created via the online interface; all you need to use the lab is a free account on the site registered to a valid email address. When I first brought the lab online, I considered limiting reservations to one per global IPv4 address as a way to prevent people from making multiple reservations. About a quarter of a second later, I realized that such an effort would amount to little, as an offender could simply use a number of open HTTP proxies to create seemingly unique reservations, then log in from his real IP address.
But what about restricting access to the lab based on the IP address used to create each reservation? There's an HTTP proxy under every rock, so to speak, but it's much harder to find server which openly relays both HTTP and Telnet or SSH traffic to a given destination.
After some research, I talked with Opengear, who sponsored the lab's console server, about improving support for the RADIUS Calling-Station-ID attribute which is necessary to put the source IP restriction in place. 48 hours later they had a polished firmware build ready for me. Many thanks to Ken at Opengear for the quick turnaround!
The lab authentication system now logs the source IP addresses from which it is accessed, and with a very minor addition to the scheduling software, can be made to enforce source IP address along with username and password as part of the authentication process.
To me, this seems the preferable solution. However, when I mentioned this possibility on Twitter, a number of people observed that this will be inconvenient for people trying to make a reservation while at work to use the lab from home, and for people whose IP addresses change frequently.
I'm leaning toward implementing the last discussion above, though I'll spend at least a week or two gathering some statistics first. I'd also like to hear feedback from lab users reading this. Please let me know what you think of the proposed solution, or if you have any additional potential solutions to consider.