The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

Dealing with Community Lab Abuse

By stretch | Thursday, February 24, 2011 at 3:39 a.m. UTC

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:

dear sir
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.

Posted in Announcements


February 24, 2011 at 3:50 a.m. UTC

How much dead time does your lab actually have? Is it used pretty consistantly 24 x 7?

February 24, 2011 at 3:52 a.m. UTC

"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."

What is your current criteria for "suspicious alert" and what's your hit/miss ratio?

February 24, 2011 at 3:55 a.m. UTC

A fourth reason for not implementing a fee: it probably won't work. I don't think a nominal fee is going to deter anyone from making multiple reservations.

I like the proposed solution. I guess you would have to determine which impacts users more: having to make reservations from the same address they will be using to access the equipment, or having entire /8 blocks banned. Tough call. I think users in the APNIC region would prefer the former, whereas American users would probably prefer the latter.

I think the IP-to-account authentication option will be less intrusive and people will just have to get into the habit of thinking about where they will be using their reservations before they make them. This will also prevent those pesky reservation resellers (do people really do that? How low can you get?)

Anyway, just my 2 cents.


February 24, 2011 at 3:58 a.m. UTC

Its a free lab so there is no reason why it should be without having to jump through hoops. If you. Register your ip and its your work ip, I guess that means you have to do your lab at work then or wait and register at home. There is being nice and accommodating and then theres not protecting yourself first and being a pushover. Lock it down. If people don't appreciate it they can go pay for it.

February 24, 2011 at 3:58 a.m. UTC

By "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." you mean useless, right? There doesn't seem to be any recourse in that plan for someone whose IP has changed in the meantime due to whatever reason. Now you've gone from spammers tying up the lab to the lab sitting unused.

When I saw this on twitter I thought it was an unworkable solution. However, combine that with more open access for folks who donate to your lab and it might be a winner.

February 24, 2011 at 4:24 a.m. UTC

I have not made use of the lab (yet) but I did drop a few duckets into the hopper to help fund it. No offense to anyone who is a hard-core user, but I think the solution that is best is the one that puts the least onus on Stretch to make it work. He put the time and effort into the lab, it's gotta be a solution that doesn't break his back (or bank).

If you want to use the free lab, you may need to jump through a few hoops (as hankito already mentioned) such as making the reservation fro tim efrom the same workstation you plan to use the reservaton from.

Just my $.02

February 24, 2011 at 4:39 a.m. UTC

+1 for donation based solution. The fee should be non-refundable (cause it is a donation, not service fee of any sort), so it solves all potential issues with refunds, no show events etc.

Every technical solution would have a "backdoor" and could be compromised (VPN services, socks proxies etc). I think, at some certain point the lab can't be free anymore, cause people don't treat anything which is free as "valuable" and can't behave towards it properly in some cases. I had a beta project few years ago, free lab based on dynamips, I just had a multi-CPU server powerful enough to provide it as a test lab for anyone who wants to have some basic practice, but don't know how to run dynamips or doesn't have a suitable hardware for it. But due to the reason of people abusing it with multiple accounts and reservations, so I had to shut it down, cause it caused more management effort than I'd expected.

Speaking of developing countries, it is quite affordable to run even CCIE-level multi-router topologies on any modern desktop PCs. So, I don't see any reasons why let's say a student or just a networking newbie can't run it on it's PC for free. If you don't want to master GNS due to your own reasons, you are free to use commercial rack rentals which is more than affordable today, I think starting at ~$2.5 per hour or so.

Jeremy, you are doing a great job with this blog and free lab. But, all I want to say, is just with some nice and simple solution that could isolate you from spending your valuable time to solving abuse problems, you can spend it to something more valuable, like new blog entries or your family.

February 24, 2011 at 5:03 a.m. UTC

One thing that probably could work, is to force users to login via telnet/SSH to confirm their reservation (by entering some command + code sent via email, which confirms the reservation). This login/confirmation would have to be done from the very same IP-address they made the reservation from. This would substantially reduce the possibility for abuse.

This could be done fairly easy by having a single, common account (password-less login, to simplify things for the user), with a chrooted environment, and a script as login-shell (so you can't do anything else than entering the code you got via email). This would be really simple to setup/script/integrate.

February 24, 2011 at 5:23 a.m. UTC

Stretch, ask yourself if you personally are getting any benefit out of giving APNIC users a free lab. If the answer to that is "no" then make it easy on yourself and ban APNIC. With the knowledge and the drive I'm sure that region can produce a handful, if not many Stretch's.

If the answer is "yes" then the IP/username/password sounds viable. Just realize that where there's a will there's a way. Folks will find ways around it, you're just raising the bar a little bit higher.

February 24, 2011 at 5:41 a.m. UTC

Banning APNIC hurts.

What about the Australian Dingos? :(

February 24, 2011 at 7:21 a.m. UTC

Why not adding the possibility to register multiple IP addresses, say at least 2 maybe 3 or 4 to give some flexibility (work, home, etc) and limit access to those addresses?

You will not only limit the problems but have a record of who owns which IP address making it even easier for you to deal with abuses.

February 24, 2011 at 8:05 a.m. UTC

Hi Stretch,
i'm a lurker here and appreciate your work, which is a great help to networkers like me all over the world.
I always thought that giving away free lab access for quite a lot of hardware -which has to be powered up and mantained- was a little too much, and of course some scumbags are taking advantage of it.
You know what? just shut it down for 2 weeks. Then put a disclaimer that every time you detect an abuse you'll just shut it down again. This community needs a bit of strong leading if you want to solve the problems.
Keep up the fantastic work you're doing Stretch. But remember, time is money. And wasting money on a free service you're providing to others is just plain unconvenient.

February 24, 2011 at 8:06 a.m. UTC

just a little thought.. what do people, who abuse such services, avoid? personal contact.
you could verify accounts by a small phonecall. and even if its an automated system, maybe this might help.
set up an asterisk server, add an ID to the account creation, let people call the asterisk, type in the ID by phone and unlock the account. and allow only phonecalls, that send their own number.

i have no idea how much work this might be and if asterisk can be used for that.

.. if you like to talk to people all over the world and want to hear everyone using your lab say, that it rocks - forget the asterisk and go for personal calls ;)

February 24, 2011 at 8:21 a.m. UTC

Unique: A credit card number just to get 0.01$
Unique: A paypal verified acccount. Also just to get a small amount.

February 24, 2011 at 8:50 a.m. UTC

I second broc's solution, perhaps combined with the donation suggestion - with a donation comes the ability to register several (no more than 5, I can't imagine) IPs.

February 24, 2011 at 9:54 a.m. UTC

I've been following this site for ... I don't know, it feels like years now. When it was still small, no talk of a lab, I followed the stories while Jeremy was in Irak. (right? I'm not American =)

I feel that Jeremy is really one of the most straight up guys you may ever meet. And I've never even seen or spoken to him. Just the fact that he builds all this, keeps us all informed (cheat sheets anyone?) and teaches us some tricks says enough for me. And he does it without gain to himself.

So the least one could do is jump through some hoops as some say it. And, not to mention, just be fair! "I didn't know that using multiple accounts is abuse" ... please.

But I also understand and support his train of thought. A free lab in the essence of the word means free, no charge at all. And what he says is true, even the smallest fee for us Westerners means food for a few days for other people in the world. I've been to places like that, I know what he is talking about. And I applaud him for realizing that!

Now, I'm not an expert in this. I'm a Unix System admin with a CCNA, a few home servers, a couple of Catalysts to play with, that's it. I'd like to have the time to train more, but hey ... that's life, right? =)

So today I felt like I should speak up. To thank Jeremy for all the work he has done and keeps doing so far (nobody blames you if things should change man!). And to call out to all, if you have a good idea, help the guy out. If I come up with something I'll let you know.

By the way, opening up an extra host, even if it's chrooted, means extra risk in security.

Also, registering 1 or more ip's is difficult for people outside of the USA. I don't know how it works over there. Perhaps you have fixed IP addresses. But in many parts of the world IP addresses are dynamic. Personally I have a 36 hour lease. After that, I get reconnected with a new address. There is no predicting which IP I will have. So, for a large part of the world this is unfeasable.

I hope this sheds some more light on the situation.

February 24, 2011 at 10:01 a.m. UTC

just a little thought.. what do people, who abuse such services, avoid? personal contact.

you could verify accounts by a small phonecall. and even if its an automated system, maybe this might help.
set up an asterisk server, add an ID to the account creation, let people call the asterisk, type in the ID by phone and unlock the account. and allow only phonecalls, that send their own number.

i have no idea how much work this might be and if asterisk can be used for that.

.. if you like to talk to people all over the world and want to hear everyone using your lab say, that it rocks - forget the asterisk and go for personal calls ;)

February 24, 2011 at 10:03 a.m. UTC

Broc's solution is what i think is best, you can even try to secure the changing IP method with some captcha or something like that.

Chris Gibbs
February 24, 2011 at 10:33 a.m. UTC

Mate, at the end of the day you are providing a free service, if the time commitment starts to outweigh your torrence for generosity , then it time for drastic measures.

Not sure if it possible, but instead of banning an entire IP range, I think maybe a cool down period for a particular ranges may work, say for instances, after a two hour block from known offenders IP address ranges, they are locked out for N minutes, allowing some other region access. N could then be changed from time to time to stop offenders guessing the cool down timer.

Failing that, turn it off permanently for offending regions.

On a side note, I'm not particularly fond of the idea of cutting of APNIC, as i'm from Australia :)



Jozef Janitor
February 24, 2011 at 11:33 a.m. UTC

Jeremy, the easiest way to uniquely identify the end user is using their credit card - you don't have to require any fee for entering the free virtual networking lab. On the other hand, you can rely on a $1 user account registration fee, which is more like a "symbolic" fee, but it will uniquely identify every user. No more multiple registrations for the same person with multiple different email addresses.

Just set up a paypal account for that - I believe that the $1 fee for registration is nothing for the ppl who are looking for real devices. For example, I will release one soft drink after my lunch and I have already earned $1 for you!

A guest
February 24, 2011 at 12:17 p.m. UTC

Since you are offering lab equipment for free then the burden should be placed on the users... Use whatever will work and if we dont like it then we can go somewhere else! My suggestion would be to have a big banner that says to only make the reservation from the location where it will be used. Or you could place a cookie on there computer to identify who is logging in! I know that no matter where I take my laptop and jump on there internet the advertisements are still relevant to the site's that I visit.

Good Luck!

February 24, 2011 at 1:47 p.m. UTC

I was going to suggest some kind of IP-registration method, be able to tie something like 5 IP addresses to your account. Would create a bit of a pain for people on cable (with basically forced IP changes), but it's definitely better than dealing with abuse. Not only that, you could make sure that someone logging in from a particular IP has the username on the reservation - if IP A is registered to User A, and IP B is registered to User B, and IP A logs in to a reservation for User B you can be almost positive that there is some kind of abuse going on.

Speaking of your criteria for a "suspicious alert" DONT TELL ANYONE. It's somewhat security through obscurity, but if the douchebags don't know your criteria for abuse, they can't easily stay under the radar.

I'd also give a +1 to being able to "donate" in order to get less restricted lab access - ie, donate $10 and you get no IP restrictions for a year or something.

In the end, damn fine job stretch, keeping such an amazing lab running for free. I don't use it often, but if I were working for my CCNP or CCIE I'd definitely be using it as much as I could.

February 24, 2011 at 1:54 p.m. UTC

While I am sure everyone appreciates you thinking of us, you really need to think about yourself. Which methods is the easiest and will reap the most rewards (e.g. time to yourself)? Which ever method you choose some of us will complain and other will praise.


February 24, 2011 at 2:21 p.m. UTC

Naivety is never an excuse - you agreed upon something, you must abide, whether you actually understood it. Just ask any lawyer. So just ignore email responses like that: I don't have time for idiots and neither should you.

I also have no problem blocking subnets at whatever level you deem appropriate. If someone messes it up for a whole bunch of others, so be it. It's like recess: you're not required to get it, it's sure nice, but one bad egg can keep the whole class in. Been there, done that, it sucks, that's life.

Please continue to be as diligent and as much of an ass as you need to be. I use this lab to supplement the other lab that I am paying for, and I abide by the rules. If that means blocking people, block them. If it means having to pay for an RSA token that can then be tracked back to individuals, do it. This is a great service, a great blog, with some great knowledge, and I don't want to see it go away.


February 24, 2011 at 2:41 p.m. UTC

I don't agree IP binding would solve the problem. Many users (including me) have dynamic IP addresses assigned by their ISP's. Utilizing this approach would only cut a portion of users, even those who are legit users. On the other hand those who are making 2 and more accounts for purpose of having several time slots for either personal use or resell attempt, could simply erect 1 or more proxy servers with static IP addresses, bind those addresses with their accounts and allow access to themselves or to the people they have sold those seats.

February 24, 2011 at 2:41 p.m. UTC

Banning APAC users - Since you noticed most of the "abusers" are from APAC region, i believe the reasion behind is that the majority of ISP (atleast in india) usually assigns the IP via DHCP, rather than a static one.

Mapping IP to user account - @ home - You should have a static IP - @ workplace - In that case you should be the only one attempting the lab from workplace, what if a co-worker registers for a slot? Is that an abuse. This is the case when all are connected to internet via a corporate proxy server.I believe the scenario is same at most workplace.

Thought - Is there any way to limit one user account per user, tying the account to something unique (other than ip address). For example, when someone creates a new account, he should validate the registeration with a randon # / key generated by the system, which he receives on his mobile which is a unique identity.

February 24, 2011 at 2:52 p.m. UTC

as you can see from my profile, i'm from Iran, from one of those developing states who cant access U.S. credit cards. it is common here ISPes service with NAT technology, which means not only i do not have unique IP address, but it is also likely that my reservations become suspended because if anyone in anytime reserves your lab in my Area,we would convicted as abusers because our OUTSIDE LOCAL (did i mention that correct?!!) would be same.

so what do you say jeremy?

February 24, 2011 at 2:54 p.m. UTC

I think, you need something like sms-confirm (not so many people have >1 phone-number). Like new google 2 step auth. But i don't actually know, how implement this thing.

February 24, 2011 at 4:11 p.m. UTC

Wow, lot's of feedback already! Let me try to answer some questions...

@mike: Blocks A and B are usually booked fairly solid at least ten days in advance. Unfortunately I don't yet have visibility into exactly how much lab time is actually used, but the lab is online 24x7.

@alvarezp: I'd rather not aid offenders by getting into the details. ;)

@throne: Not useless; people will just have to think ahead about creating their reservation (which they should be doing already).

@Sergey: When a donation must be made in order to receive a service, it's not a donation, it's a payment. And like I said, a paid model is not something I'm going to pursue. Also, while Dynamips is a great study tool, it is only useful for emulating IOS routers; for switches and non-Cisco gear, actual hardware is a must.

@jocke: That's a very interesting idea! I've added it to my to-do list for further consideration.

@broc: Allowing for multiple IP addresses seemsa bit complex, but perhaps allowing a user to specify the IP address for which the reservation is valid is doable. So long as there is never more than one reservation per IP it should work. This would solve the issue of people wanting to make hom reservations from work and vice versa.

@FKP: I appreciate the sentiment but that just punishes everyone. And it won't stop the abusers.

@Avi: Interesting idea, but it seems prohibitively complex and ultimately pretty easy to defeat.

@Hakna: Most credit card processors have minimum charges and service fees (which I have to pay) per transaction. And not everyone has a credit card.

You guys have given me some good ideas to consider, thanks! I'm curious: for those of you with dynamic IP addresses (mobile connections excluded), how often do they really change? IMO if your IP address is really changing regularly even without a line disruption you should be looking for a new service provider.

February 24, 2011 at 5:13 p.m. UTC

When I use the lab, I usually sign up for the reservation at work or on my phone. Sometimes I'll access the lab at work on my lunch, or at home. A few times I've even accessed the lab from my phone.

For work, they actually push all of their internet traffic out to their main HQ, located on the west coast (while I'm located on the East Coast).

Some suggestions (forgive me if they are covered above I didn't have a chance to read through all the comments):

Using things with unique (or harder to mask / obtain another): -Authenticators (YubiKey) -Phone numbers (maybe have an automated system that calls the user with a passcode they have to give) -Maybe a phone app can be used (Like they use for WoW)

What if you have an automated system that sends E-mails out, maybe like once every three months( a random interval would be better) to the registered accounts. And just click a reactivation link within a certain time frame.

I understand that most of this requires money be spent, but maybe have different account levels. Each account level has different requirements(YubiKey, reactivation, etc), and each account level has different privileges (Hours a month that can be used, time frame that has to wait to make a reservation)

February 24, 2011 at 5:24 p.m. UTC

Just thinking out loud, what about certificates? Set up your own certificate server and assign certificates when people register with you. They have to have that certificate to book time, and when their reserved time comes up, they have to have the certificate on their system to gain access to the system - maybe by going to a webpage that verifies the cert and gives them the current password or something?

Potentially you could allow a person to have 2 or 3 certs associated with their ID, one for their home computer and one for work, etc. etc...

February 24, 2011 at 5:33 p.m. UTC

What about OpenID? When I authenticate with my openid provider (, it calls my phone asking for the digit 1 to allow login. This would tie login to infrastructure that requires a bit more authentication (voice provider, billing address, credit card).

Though, maybe SIP DIDs are a dime/dozen, but the purpose of locks is to slow not prevent. This might not work internationally.

February 24, 2011 at 8:52 p.m. UTC

How about:

Providing a check box on the reservation form where a user can signal that they will be logging in from a different IP and which point one of the following activities can occur:

// Case where Reservation IP and Login IP are behind different networks

  • Give the user some time period (12 hours?) to login from behind the IP that they will use for lab time, at which point they will receive their lab credentials. You now have a Reservation IP/Login IP to key off of.

// Case where Reservation IP and Login IP are behind the same network or POP

  • Run the reservation IP through Whois, run the origin AS through RTConfig (IRRToolset), and place their ISP's prefixes into an allow ACL, then require the user to login within some (short) time period from a different IP on that same network, at which point they will receive their lab credentials. You now have a userid/AS association pair to key off of.

  • Run traceroutes to Reservation IP/Login IP's to verify that they go through the same POP (i.e. a reservation made in Hoboken, NJ would not line up with a lab login from Fresno, CA.) You now have a userid/POP association pair to key off of.

Whitelist successful pairings (reservation (IP|AS|POP)/Login (IP|AS|POP)) for some period 'x'.

February 25, 2011 at 1:07 a.m. UTC

I run a free web hosting company, as such I see the exact same issues every day, and I experienced the same issue with it just being way too time consuming to verify every order(we get about 5000 orders a day now).

I would suggest a mixed implementation:

  • A donation from a verified paypal. I like that idea, definitely a good one. Not impenetrable but certainly would slow the rate of bad signups.

  • Don't block /8's but do block /12's and /16's. I have a good list of abusive nations and IP ranges, I think you can download a list off a geoip. A lot of these IP's have people that are just like you described. People who agree to a Terms of Service but then say "oh hi! I not know hacking and cracking site against terms of service, i not know I cannot set up spamming server, please re-enable account!!!!! PLEASE! I promise not do again!!!" and yes, I completely agree with deleting those emails and banning their /24 at a minimum.

  • You suggested limiting the lab to the IP that logged the booking... How about limiting it to the /24? Or if you want to be really clever you could at least do a reverse lookup on their IP and confirm they are coming from the same ISP - that would be pretty simple to script up in PHP or Python.

  • Other than that, basic profiling. eg. require name + address. Most fraudulent users will use "123 High St" or "123 Not Telling" or "asdfg asdfgh" etc. Any user detected putting in bad details like that incurs a temp ban(3 days) with more than two blocks on a that IP incurring a perm ban. If more than 3 IP's within a /24 cause a ban, then ban that entire /24.

  • I think the thing to remember is that you run a free service. Sometime they will try make you out to look like a loser/tool/fraud/douchebad/etc and ruin your credibility because you might not be acting fairly in their eyes. At the end of the day, it's your time, your gear, your money, you decide what you do and don't do and no one elses opinion really matters. Most people don't want to hear that but it's true. (that doesn't mean not being open to suggestions, but I know your smart enough to distinguish that difference)

  • I have plenty of other ideas but they are probably all rubbish. If your struggling though, let me know.


February 25, 2011 at 5:38 a.m. UTC

The problem with the IP address is that in some places (like here in Australia) static addresses for home is not common, so my home address will change every 12 hours. Maybe the authentication could be tied to something like OpenID or even a $5 donation, I would be more than happy to do that.

February 25, 2011 at 12:07 p.m. UTC


"You guys have given me some good ideas to consider, thanks! I'm curious: for those of you with dynamic IP addresses (mobile connections excluded), how often do they really change? IMO if your IP address is really changing regularly even without a line disruption you should be looking for a new service provider."

In Europe it's not like those service providers are bad, most of them use dynamic ip's. For me (and all others that I know, but it may be different from country to country) the lease is 36 hours. After that, short disconnect (yes, I do lose my irssi connections etc at that moment) and we're back. Not a problem for most regular users. That's why Europeans are fond of services like dyndns + automatically update the ip. There are service providers that use fixed ip's. But that doesn't mean they deliver better quality, or are way more expensive. Just changing to get a fixed ip is not a reason to change service providers. In my country, as far as I know there's only 1 service provider that uses fixed ip's.

Mmmm ... that gives me an idea.

  • Give the option for fixed ip or dynamic ip (with a dyndns/no-ip/... account) Good. But people with a fixed ip can cheat because they can reserve the lab with their fixed ip and create a Dyndns account to double book

  • Make everybody create a Dyndns/no-ip/... account
    Solves the problem partially. Because even people with a fixed ip can't double book on an account. But people can create multiple Dyndns accounts.

  • Make everybody create a Dyndns + give them something of yours!
    Here is an idea. Everybody creates a free Dyndns/no-ip/... account. And when registering (existing users will have to update) you give them something unique to tie the Dyndns/no-ip/... account to a person. They need to register with an email address + dyndns account name + you give them a public key. Those three together form a good combination.

Granted, it doesn't solve hardcore abusers who have multiple emails + register multiple Dyndns/no-ip/... accounts and get more than 1 key. But it is a deterrent.

Maybe this isn't a super great idea. But maybe this gives other people an idea to build on. The Dyndns account at least solves the dynamic ip issue.

February 25, 2011 at 4:06 p.m. UTC


I'm in favor of the non-refundable donation/fee solution. If possible, you could look through the list of IPs used to make reservations and the IPs where the abuse comes from and see how many are from 3rd world countries[1] which would be impacted by this (because their credit card would not be accepted).

My IP changes every two days. Looking at last week's logs, I see that the IP always comes from the same /18, so, if you choose to go that way, you may want to implement more loose checking rules (i.e. check if the IP trying to connect is "close"[2] to the one the reservation was made from), although this could be more difficult to implement than in sounds. Changing the provider would be useless because the others are doing the same thing.

[1] 3rd world countries is a very vague term and it includes some Eastern Europe countries (I live there), but NOT the EU members
[2] close could be the same pool (obtained via whois) or, if you want to go bold, the same country

February 25, 2011 at 5:32 p.m. UTC

Hi again, Strech.

What about this: a two-step e-mail confirmation (one right after reservation and one 20 minutes before lab time). You can send a "if you've been charged, you've been ripped off" messages here.

February 25, 2011 at 5:53 p.m. UTC


It seems many people are describing two-factor authentication. Have you considered the free mobile-otp application. It provides two factor authentication for java capable mobile phones. Might be worth looking into. As usual with two factor solutions, users sign up and create a pin and the app itself sends a password to be added to the pin for authentication. Obviously more complex than blocking a /8 of IPs but may provide a long term solution.

Thanks for all your efforts! Brian

February 25, 2011 at 10:32 p.m. UTC


My two cents - OpenID and or ip registration when you sign up for the lab. But what ever you do - it is your lab your time and make sure you KISS. It is not your issue to spend all your time on this as you need to study and live too. I know I have five people working on my lab that I have at my home. Thanks for your time and being the man you are to have it free for all. Your a better man than I for doing that. Maybe I will open mine up after my CCIE.


February 25, 2011 at 11:42 p.m. UTC

Maybe there is a way to further automate the banning. Not sure what your alerts look like, but maybe you could use a simple script and something like fail2ban to turn certain alerts into IP bans.

February 26, 2011 at 6:19 p.m. UTC

@ strech

I'm curious: for those of you with dynamic IP addresses (mobile connections excluded), how often do they really change?

Here in Germany you'll usually get a new dynamic IP address after your (PPP) session is disconnected and it's a usual behavior by a lot of ISP's to force a disconnect every 24h. Don't know how other European ISP's handle that, but I think it's not very different...

February 27, 2011 at 3:02 a.m. UTC

As you quoted:

"I considered limiting reservations to one per global IPv4 address as a way to prevent people from making multiple reservations"

First try implmenting this solution for a month or two and I am sure 80% of the abusing will be solved. The stupid guys who do the abusing aren't intelligent enough to use a http proxy.

February 28, 2011 at 1:22 a.m. UTC

wanman77 has it right: Keep it simple! As I understand it, the problem you have is accountability. You need a way to identify a unique individual, and tie them to a user account. If payment options (credit card, PayPal, etc) are off the table, and you consider telephone or SMS based authentication to be prohibitive for the users (or indeed yourself), then I think what we're left with is RSA tokens, certificates of some sort. How do you ensure that a given token is traceable back to an individual? Traditional methods fall back on multiple forms of verification, payment information, cell phone number, etc. It's a vicious circle.

All the other proposed solutions involving IP addressing are still open to abuse. Fact is, without obtaining someone's PayPal, credit card or cell phone information, you don't have much on them. Now, would you compromise and charge for an RSA token via PayPal, but refund the amount, minus the transaction fees which you would incur?

If I lived in a country where I hadn't got access to PayPal (is there such a place?) - be it my own account, a family member's or a friends, I'd look to an American friend who could purchase the token for me.

This is a one-time setup. Whomever buys the token is responsible for it. The actual user of the token need not be the PayPal account holder, though you could set it up that way if you want, by monitoring their IP addresses and ensuring they're 'geographically close' to their PayPal registered address. I'd say don't bother with that. Enforce a policy of no sign-up fee $x (to be held for 4 weeks and then refunded), no token.

The token allows you to control all. You cannot connect without a token, and a token can only be accepted according to the booking schedule, which has a lockout policy. No reservations can be less than x days apart, etc.

Detect any abuse with that unique token, and ban it forever. Failed connection attempts should count as abuse. Would you be willing to compromise on this one issue, the use of PayPal, given that it allows you to tie logins to a unique user and thereby control their access? Now you're going from free to a one-off payment (essentially, your PayPal overhead of transaction fees) of, for talk's sake, $0.30, and the unfortunate necessity of holding their fee for a period of x days before refund. What do you set the fee at? $5? $1 even?

The details aren't important but what is important is that your system is protected from abuse by the use of an RSA token (or similar) which you can monitor and control. If it ends up that someone wants to share their credentials with another.. it still won't avoid the lock-out policy. To make users value something, they have to invest something valuable of their own. As you cannot screen users for 'common decency' and 'respect' as traits, I see no other way.

There are probably 50 holes in my argument, but I'm sure there's a way of making this work. Just to take the idea a little further, there's nothing stopping you from issuing one token for booking and one token for the session - sent to the registered email address. Make the tokens expire after x minutes. There's that, and then there's RSA fingerprinting the user's client machine. Or both :)

If what you're trying to do is make this service free for all to help them educate themselves, then a few technical hurdles (educational) and 30 cents isn't asking much.

February 28, 2011 at 1:52 a.m. UTC


there are a lot of interesting ideas being circulated but here is the dilemma....
for regions like mine dynamic ip addresses are predominant and are refreshed within 24 hrs or less. Most individuals do not have a static ip at least not here in jamaica. Th APNIC region for the most part unforutnately for the many have ALWAYS had a lot of violators in every area conceivable.

I dont however believe it is fair to bundle all in one basket so to speak. But is it fair to you, how many unnecessary hours are you spending weeding out unscrupulous persons which could be spent with your family our other interests.

The concept of the site is to provide us with access that some of us like myself would never be able to afford otherwise. Truly an open handed gesture of kindness and faith. If it being violated, if it is becoming that much a burden. Then Jeremy its time to act.

The only way to create balance is not to raise the bar in terms of security so as to defeat the openess of the initiative. It is to take away the one thing which is making it a "favourable" target. Charge. whether its a dollar or a yearly fee to maintain the resources. Its the mental perception and its ripple effects which is important.

The struggle may be balancing your desire to give something free with the consequences of human nature. They will continue to abuse ANY loophole until you have had enough. The consideration is not in appreciating what you are giving. It just to see how much can they possibly take.

The only sad thing is those who may suffer. I didnt use this site. I used packettracer and walked to a local cisco academy when i couldnt afford the bus fare (you dont want to know how far) but your passion was contagious and your love became my love. Cisco really needs to appreciate its advocates more.

I have no degree. I HAD no direction or purpose. I HAD very little hope. I HAD no money. Your passion fueled me to become CCNA certified and currently to be doing CCDA & CXFF. I will be starting CCNP by May. And oh by the way I am one of the few in jamaica that can say they are employed as a Network Engineer at a major IT solutions company. Thank you

It is not in vain that you wrestle but all things are for a time and have a price.

Mapping dynamic ip to a dns2go like service (dyndns, etc) is a good solution.
Not sure what authentication could be put in place that would be unique enough to be feasible.

There are many great minds here im sure the right answer will be derived in time.

Just wanted to say thanks. Wont stop until i am CCIE multiple times over.

February 28, 2011 at 11:32 a.m. UTC


I don't see any perfect solution. The problem seems to be that there is no such a thing as an international-unique-id, provided for some "external" authority which can't be provided twice.

Digital certificates would make things difficult although they would not prevent from create several pairs of account/cretificate.

From the no-perfect solutions: What about using Cisco certication ID's as some form of authentication? I don't know exactly how, but I think it can be easily checked... This way would lead to rely on Cisco and would leave out people who are not certified which may be far from ideal, but may be easy and handy if:

  • statistically most of the people accessing the lab are at least CCNA (and <CCIE)

  • It is considered that CCNA candidates have enough to practice with Dynamips or even Packet Tracer.

In any case if the amount of people leaved out is small enough, there could be some other possibilities to be granted with access, after actively participate in the forum or something similar...

I am not currently a user of the lab (I read the articles and use some of the materials/links... provided which I thank to Jeremy and all of you), but I'm concern about the future of such a nice initiative.


February 28, 2011 at 2:55 p.m. UTC


Not sure how hard this would be to implement. But how about having a similar system as some forums out there, that you can only use the lab after more than 5x posts in the forum or comments section?

That would show that the person is at least contributing to the site.

(This is my first post btw :)

A guest
March 1, 2011 at 5:20 a.m. UTC

You should restrict lab use for users who leave comments on the blog posts and/or forums. That way only people who contribute to the website are able to benefit from the lab.

March 4, 2011 at 2:25 a.m. UTC

I don't have the expertise to suggest any type of authentication, but I can say that if Jeremy's idea is to help people who can't afford access to real gears, any type of payments would be against his approach: if I were still living in my country in Africa, there would be no way for me to pay a dime. No credit cards, no Paypal registered accounts at all. Another reality I wanna share: I like to encourage friends, classmates and coworkers to get certified, but all those whom I offered free materials and training too, I can tell none has even ever sit for half a test. It was true back home, it is true here in the US. Now even my best friend has to pay me, or he's going to buy all the books, videos and hardware himself. Period! There's a saying: I don't know the right way toward Success, but I can tell you the "best route" toward Failure: TRY TO PLEASE EVERYBODY. Jeremy: do what you've got to do! This is a free service, this is a generous idea, this is your valuable time. Make it easy for yourself, and people will follow. By the way, the unique IP address will affect me tonight: I set a reservation from home last week, but will be accessing the lab from my cousin's place; he's studying for CCNA and I wanna show him this lab. So ban me if I deserve it ;-)

Just an idea
March 4, 2011 at 3:54 a.m. UTC

I have a sorta different idea. Why not require the person publish their credentials from the Cisco certification tracker in order to get their account active for scheduling rack time?

You could verify the email did indeed come from Cisco. It's less likely they have multiple real ID's that way and abuse would be easier to permaban.

I don't know if this also could be used through other vendors or not.

Ultimately, though... GNS3 is enough to pass CCNA easily. If you haven't passed a single written exam, rack time is probably not the place to start anyway.

March 9, 2011 at 2:32 p.m. UTC

Could you make it so they have to be reachable on freenet/#cisco while using the lab? That should get rid of people trying to sell lab time, and a lot easier for you to monitor if the lab user & the IP they have on freenet is the same.

Comments have closed for this article due to its age.