Of course, it also protects my server from much more powerful and dangerous attacks, such as high-bandwidth DDoS, but I don't know any legal and ethical way to test that sort of attack.
Open a second Web browser window and go to the same page:
In one of the browse windows, fill in the CAPTCHA, as shown below, and then press Enter.
After submitting the form, while the next page is loading, switch to the other browser window showing the attack.samsclass.info page and refresh the page several times.
After 30 seconds or so, your other browser window should show the captured HTTP requests and responses, as shown below:
Notice the IP addresses in the GET requests: the requests go to my server at 67.202.107.49, and come from your computer's public IP address. If you are working from CCSF, it will begin with 147.144.
Open a Web browser and go to
Open a second Web browser window and go to the same page:
In one of the browser windows, fill in the CAPTCHA, and then press Enter.
After submitting the form, while the next page is loading, switch to the other browser window showing the games.samsclass.info page and refresh the page several times.
After 30 seconds or so, your other browser window should show the captured HTTP requests and responses, as shown below:
The requests no longer come from your IP address. They come from a different address, somewhere on the CloudFlare network. When I did it, the source of the GET requests was 173.245.48.160.
Copy the source IP address of the requests. Paste it into a browser address field and press Enter to see who is using that server.
You should see a CloudFlare message, as shown below:
This proves that the requests are indeed coming from CloudFlare. Normal GET requests are proxied through.
Open a browser and go to http://code.google.com/p/owasp-dos-http-post
Click Downloads. Click HttpDosTool3.6.zip. Download the file and unzip it.
In the "HTTP Attack" window, in the URL box, enter http://attack.samsclass.info as shown below, but do NOT start the attack yet:
This attack will freeze my Web server, so if you start it too soon, you won't be able to start the packet sniffer.
Open a Web browser and go to
Fill in the CAPTCHA, and then press Enter.
While the page is loading, in the "HTTP Attack" window, click the "Run attack" button.
After a few seconds, click the "Cancel attack" button. If you don't stop the attack, the Web server will freeze and you won't be able to see the captured packets.
After 30 seconds or so, the Web page will display the captured packets, as shown below:
These mangled requests confuse the server-- if you scroll down you can see the many server responses saying "Bad Request".
(If you scrolled down, you may see "HTTP/1.1 400 Bad Request" messages instead--those are also acceptable as proof that you have the attack working.)
Save a screen capture with a filename of "Proj 17a from YOUR NAME".
Open a Web browser and go to
Fill in the CAPTCHA, and then press Enter.
While the page is loading, in the "HTTP Attack" window, click the "Run attack" button.
After a few seconds, click the "Cancel attack" button.
After 30 seconds or so, the Web page will display the captured packets, as shown below:
The "Start:" line is followed immediately by the "Finish" line--there were no HTTP requests sent to my server during the attack. CloudFlare stopped them. So even though I have a weak, vulnerable server, it will stay up as long as my visitors come through the CloudFlare-protected URL.
If some normal requests and resonses are shown, that's OK.
Save a screen capture with a filename of "Proj 17b from YOUR NAME".
Email the images to cnit.122sam@gmail.com with a subject of "Project 17 from YOUR NAME".