Note: don't try this at home... you may get into uber-trouble with a less friendly university, suffering anything from revoked computer privileges to disciplinary action. Now, having said that...

How to DDoS your University's Engineering School
The relatively quick and relatively legal way

Ingredients:
    1 File-sharing service
    1 Occasionally clueless programmer
    600+ anime-ravenous users

Preparation

This story begins (as all good stories do) with three friends and a file-sharing service. During my freshman year two friends and I decided to create a file-sharing service that would rival Napster. We did it for the fun, we did it for the money* and we did it for the women. At the time, it was as good, if not better (TIDSSM) than anything else out there (this was before Morpheus and the like). Users could share any kind of file they wanted, they could IM each other, password protect directories, search the entire network, and browse each other's computers, much like a virtual network neighborhood. We had plans to develop an encrypted system and eventually make it super distributed. Oh the plans!

The real reason we did it was that it was supremely fun. We didn't really know what we were doing, but taught ourselves what we needed to know to as we went along. I was in charge of the website and learned PHP in order to create user accounts and manage the database. Our system was hosted out of our dorm room on two servers -- one we purchased and the other was donated by a friend. We were grass roots and we loved it.

Fast forward a year and our system had grown to a userbase of 10,000 through word of mouth alone. We had 600 people sharing at any one time; a far cry from Napster, but then again, we didn't have any advertising. Our main programmer decided to make it his senior project, and so we were able to move our servers to a computer lab in the school of engineering. The bandwidth was better there, we were given UPSs, and we were able to use a few of the spare computers if we ever needed to expand. Good deal.

Instructions

Now here's a piece of advice to all you young and upcoming Shawn Fanning's out there: make sure you team up with a programmer who knows what he's doing. One day, Jackson (for that was his name) began to work on a technique that would allow users to share files from behind a firewall. In order to this, he needed to modify the ping and auto-reconnect method that he was currently using to keep the clients online and listed in the main directory. A tweak here, a tweak there, and the first step to supporting proxy servers was ready to be tested out. Every so often the client would ping the server and the server would send a response, keeping each other informed of the other's presence. Jackson uploaded the new version and waited.

As the clients auto-updated to the new version, everything seemed fine. The system worked, people were trading files, and the website was functioning properly. Typically it took up to a week for most of the users to sign on and update to the new client. Then suddenly late one night, the system vanished without a trace. The website was down, our clients wouldn't connect, and SSH was getting nowhere. Network outage, we figured. Ha! As we were to soon learn, Jackson's senior project had turned into the senior project from the school of Burn-Baby-Burn!

It wasn't that Jackson's idea wasn't good, in fact it worked too well. It was just that he implemented it in the worst way imaginable. While setting up the send and receive system of pings, he accidentally coded it so that the client would send out a response ping as soon as it received one from the server, and the server would do the same as soon as it received one from the client. As more and more people updated to the new client, the server was doing nothing but sending and receiving packets. As fast as it possibly could. To over six-hundred clients.

Oops.

Somewhere between 700 and 800 clients the router died, and with it came the internet connection to all of the computers in all of the engineering labs. The situation was worse in the Robotics and Remote Sensing laboratory. Its server crashed when it could no longer contact its remote fileservers, a problem that kept it shut down for several days. Unwittingly, Jackson had launched a 700-computer Distributed Denial of Service attack against our own university. Out of all the CS majors, this is the one we chose to work with?

Remarkably, the university was very cool with the problem. No action was taken against us, and we were even allowed to continue our file-sharing system once Jackson had taken back the beast made the appropriate changes the code. The Robotics lab ended up suffering no damage, thankfully, and in the end they were actually quite pleased that the outage had occurred for it revealed a bug in the way their server contacted its remote fileservers.

Presentation

We could find many morals to this story: Don't pick nitwits to be your lead programmer. Make sure you trust the company you downloaded your software from. And last but not least, now we know that the next time you're feeling mad at a CS professor, start up your own file-sharing system and show him who's boss.


*Back then, we too had dreams of turning our .com into a business, eventually selling our software as an alternative to VPN solutions. Microsoft would buy us out for sure! *sigh*

Log in or registerto write something here or to contact authors.