A denial-of-service (DoS) attack is an attempt by a single person or a group of people to disrupt an online service. It is designed to bring the server and network to its knees by flooding it with useless traffic. A DoS attack is the most common type of Internet attack and can be launched against your site at any time with relative ease. This can affect you by eating up your bandwidth and server resources to service these bogus requests while leaving no resources to fill legitimate requests.

So how do you know if you're being attacked? There are many variations of DoS attacks, and some are more difficult to catch than others. Some programs, such as the Apache Web server, have rearchitected their software to protect against this sort of attack. The method described here will allow you to catch and automatically defeat DoS attacks against your applications, regardless of the Web server used.

All you'll need to add to your database is a single table to keep track of active sessions (see Listing 1). You can decide whether to implement this on an application level or across the entire server, and decide which database makes sense for doing this tracking. Although there is a slight performance hit to enable this feature, you'll gain other relevant information on current site usage such as how many users are online, what page they're currently viewing, and how many total pages they've retrieved during the session.

Some may feel that we're creating a set of data for tracking sessions in a database that could just as well be created using ColdFusion's client variables. We'll discuss that alternative briefly in the conclusion.

We only need to make a couple of changes to our application to enable our DoS checking. First, in your application.cfm, we'll add code to check if a session already exists in our database. If it does, we'll update the lasthit timestamp as well as the last page and total pages viewed; otherwise we'll add a new record for this session (see Listing 2). We use a combination of CFID and CFTOKEN instead of URLTOKEN to keep things compatible with earlier versions of ColdFusion.

Now we have all of the current sessions for our site within a database. We'll take advantage of ColdFusion's built-in session management to help us detect attacks. Normally, ColdFusion will generate a new CFID and CFTOKEN for each individual browser that it encounters. Since many DoS attacks use an automated program and not a browser, ColdFusion ends up generating a new CFID and CFTOKEN for each request. Now we need a way to check for this.

We set up a scheduled script to run every 5 minutes and monitor our session table (you can modify the interval if necessary). Our check script (see Listing 3) first deletes any sessions from our database that are older than our specified session length (as defined in a CFAPPLICATION tag, which though not shown here, is 60 minutes in this case). We then count how many distinct URLTOKENs we have for each IP address. You should note that it is perfectly valid to have multiple sessions for a single IP if your users are sharing an Internet connection or going through a proxy server. Therefore, we'll set our threshold high enough (50) so that regular usage of the site will not be affected. You can modify this threshold as you see fit to make the check more or less sensitive. Finally, we create a list of any offending IP addresses and save this to an application variable.

You may wonder about locking the last line, assigning the application.DoS variable. While in CF5 it's always best to lock any reference to persisted variables, and in CFMX it's wise to do so to avoid "race conditions" when multiple users or sessions run code at the same time. In this case, however, this is a task that will be run only by the CF scheduler and then only once at a time.

The last thing you'll need to do in order to protect your site is to add some code at the top of your application.cfm to stop offending requests dead in their tracks (see Listing 4). Although we can't ignore these requests completely (as they've already made it through to our application), we can halt them right away so that we do not waste processing power or bandwidth.

We mentioned earlier that this process of tracking and analyzing sessions, while it has value beyond just this task, is partly already done for us if we enable CLIENTMANAGEMENT="yes" in our CFAPPLICATION tag. ColdFusion will then automatically write to a repository a set of fixed client variables similar to those we've set up (CFID, CFTOKEN, HitCount, LastVisit, TimeCreated, and URLToken). It will then update these values for each client that visits your application.

There are a couple of problems with using this data. First, CF doesn't automatically write the IP address for the visitor. You could easily add that one value by adding to your application.cfm the single line:

<CFSET client.ipaddress=cgi.remote_addr>

But even then, in order to process the data, you need to manage it in the location and format in which CF creates it. It writes these data either to a database or the registry, depending on the setting of the associated CLIENTSTORAGE attri-bute. If CLIENTSTORAGE="registry", or if it's not specified at all, CF will write these variables to the registry. CLIENTSTORAGE can also point to a database.

The problem is that the database approach creates tables (Cdata and CGLobal) and columns that are not easily parsed for our purposes. And while we could write CFREGISTRY tags to extract the data from the registry, it is challenging to then convert that to query-like data to be analyzed as we have. (If you want to explore it, the client data is written to the registry in HKEY_LOCAL_MACHINE\SOFTWARE\ Macromedia\ColdFusion\CurrentVersion\Clients).

DoS attacks are on the rise and growing exponentially each year. You need to protect yourself, or at least be aware of the damage that a DoS attack can do. If you have a Web page with 200K of graphics and data, calling that six or seven times a second will consume a full T1 of bandwidth. Hopefully most of you will only need this tag to keep track of users currently on your site, but for those having attack problems, this method will provide a self-correcting way to insulate your site from trouble.