This page covers information you should know if your site runs PHP and MySQL scripts on a dedicated or virtural dedicated server. It provides some basic PHP code that prevents continuous reloading of a single page. It also explains why you need to have FastCGI turned on if you do run these scripts. If your site runs only on HTML and JavaScript, you probably don't need to continue.
My website was recently hit by a denial of service attack. I should probably explain that MrKent.com is hosted on a dedicated server in Herndon, Virginia belonging to Peer 1 Hosting. Many years ago when the site was hosted on a shared server it was much easier to get things uploaded and on line than it has become since moving to a dedicated server over the past several years.
Much of what I have learned about managing a remote dedicated server has been learned through trial and error (a lot of error). Therefore this page and information contained therein is provided to try and make life bit easier for those like myself (The Little Guy) who have never had any formal training on the use of a Windows server. I believe I am currently on my fourth Windows server at the time of this writing.
I first noticed the recent attack on a Monday morning as I was attempting to make use of one of the free punch clocks provided on this site. There was no way to go beyond the welcome page. Any page containing PHP code was unavailable. I opened the remote desktop connection and brought up the "Reliability and Performance Monitor."
I have set it up to display CPU usage, the Disk Reads per Second and Anonymous Users per Second. As I suspected, the CPU usage was hanging at 100%. Next I right-clicked on the task bar and brought up the Task Manager. In viewing the Processes I found it to be totally filled with repetitive sessions of the php-cgi.exe file. This file is part of the FastCgi application associated with the PHP - Apache service (I will explain later how I fixed that issue).
By the way, this took place at a time of day when my site is receiving the most traffic. Nevertheless I decided to re-boot the server to stop the attack and start fresh. That worked for the moment but an hour or so later it happened again and again and again. I knew it was a Denial of Service attack so I began to Google how to avoid this kind of issue.
If you try Googling "avoiding denial of service" you will get several results. The first on the list is from msdn.microsoft.com/en-us/library/cc151077.aspx. But as I read it I could tell their advice was not targeted to The Little Guy. And the same was true with the other links displayed in the Google list of results. (You may already know this, which is why you are here today.) I then decided this battle was going to be all up to me if I expected to prevail.
From viewing the many repetitive sessions of the php-cgi.exe application I decided the attacker was simply reloading the same page over and over. I realized that you cannot prevent a page from being reloaded (or refreshed). But there are plenty of examples of PHP code provided on the Internet to prevent a form from being re-submitted. So I began using that code on all of my PHP pages. That took several days of work because I have just under 60 various online applications contained under the umbrella of mrkent.com. Not all of the pages use PHP code but many do and some also access the mysql database engine, which saps more CPU time.
In the mean time I began doing research on FastCgi which is the description given in the Task Manager's Processes column along with the php-cgi.exe file. I learned that it is a service that can be turned on or off. It will do a webmaster no good if he/she never uses any scripting (php, mysql, perl). I had never given it much attention and knew very little about it - until now. But, as I researched I discovered that it speeds up the delivery of scripted pages by leaving a copy in memory once it has been called upon. Then when it is called again the CPU doesn't need to dig it up and create the page from code all over again.
After nearly a week had passed nearly all of the PHP pages had been re-coded and I had learned much more about FastCGI. The attacks were still there but were becoming very short-lived and had little effect as a result of the new code.
I have worked with both Plesk and Cpanel but I am most familiar with Plesk as a control panel for the Windows server and is what I currently use. As I read more about FastCgi and that it could be turned on or off I decided to check and see if it could be found in my Plesk control panel. (Remember, I have already admitted that I learn by trial and error most of the time.)
As it turns out, when I was setting up MrKent.com on the current server which took place in September of 2011, I actually had seen "FastCgi" as one of the choices in the domain setup panel. But, not knowing much about it then, I simply chose "CGI" which is the first option on the list. The graphic shown below is part of the Plesk control panel's Domain - Web Hosting - Setup page.
On the following page I will share my feelings of surprise following the selection of FastCGI as opposed to simply CGI:
