Avoiding Distributed Denial of Service (DDOS) Attacks | .NET Development Security Solutions

The DDOS attack is one of the most devastating attacks that a Web server can experience. Zombie computers (those infected with a special virus that gives the cracker full control of the system) attack from all over the world. The essence of a DDOS attack is to send high priority messages to the affected servers that don’t require processing. Such an attack wastes processing cycles. What the user sees is an inability to contact the server. In short, your server becomes just another hunk of humming metal that doesn’t serve a particular useful function other than generate heat.

Many developers have the misconception that they can’t do anything about DDOS attacks. The attack comes from other machines where the administrator failed to exercise proper control and the thought is that the local administrator can change server settings and set up firewalls for protection. Turning off features such as Telnet can help, but it’s not a complete solution. The following sections discuss coding practices you can enforce to help in the fight against DDOS.

Don’t Process Out-of-Band (OOB) Messages

The “Working with Sockets” section of Chapter 8 discussed how sockets work. In fact, Listing 8.1 shows how to use the SocketPermission class to restrict access to this important feature. That section also discusses the OOB message—essentially an error message for sockets. Because the OOB message is higher priority than the standard socket message, crackers can use it to start a DDOS attack on your system. In short, your application could become the focus of a DDOS attack, even if it works as intended and has the proper security features in place.

The standard practice for applications is to check for errors and react to them as needed. Consequently, you might think that processing OOB messages is a prerequisite for good computing. However, look at the example in Listing 8.1 and you’ll notice there isn’t a single line of code that checks for the OOB message because this application doesn’t have a need for this level of error checking. In fact, most applications don’t have a need to process OOB messages. Leaving OOB message processing out of your application may not seem like a good idea, but consider first what you’ll do with the information. If, like many applications, you aren’t going to do anything with it, then don’t process the OOB messages and leave yourself open to attack.

However, what happens when you do need to check for OOB messages for some reason? In this case, setting a performance counter can be helpful. If you reach a specific threshold, turn off OOB message processing. The goal, in this case, is to react to normal levels of error reporting without allowing avalanches of error messages to bring processing on the server to a halt.

Using the Performance Counter Approach

The important thing to remember about DDOS is that the attack is on the server’s ability to process requests. As long as the cracker is successful in shutting the server down, causing it to crash, or at least reducing its ability to process legitimate messages, the attacker has won the DDOS battle. It’s important to concentrate on the concept of overloading the server in some way. This means the attack could take a form as simple as passing bad requests to your application. After all, the cracker doesn’t need to know anything about the application to pass it a bad request—the simple act of passing bad data is enough.

Creating a performance counter in the Win32 API environment is nothing short of a nightmare, so many developers avoid performing this task. However, the .NET environment makes the task of creating a custom performance counter relatively easy. All you need to do is create a custom performance counter that tracks the number of bad requests to your application. When the number reaches a specific threshold, you know that something is wrong—it could be a DDOS.

Listing 9.3 shows an example of a performance counter approach for detecting DDOS or other error overflow conditions on a server. You’ll find this example in the \Chapter 09\C#\ PerfCounter and \Chapter 09\VB\PerfCounter folders of the source code located on the Sybex Web site.

Listing 9.3 Using a Performance Counter Approach for Detecting DDOS

// A collection of counters. CounterCreationDataCollection CounterCollect; // The error counter. CounterCreationData           ErrorCount; // Determines random error. Random                        EventVal; // Error performance counter. PerformanceCounter            PerfCount; public frmMain() {    // Required for Windows Form Designer support    InitializeComponent();    // Create the collection and error counter.    CounterCollect = new CounterCreationDataCollection();    ErrorCount =       new CounterCreationData(          "Error_Count",          "Contains the application error count.",          PerformanceCounterType.RateOfCountsPerSecond32);    // Add the counter to the collection.    CounterCollect.Add(ErrorCount);    // Create a custom counter category.    PerformanceCounterCategory.Create(Application.ProductName,                                      "Error checking counter.",                                      CounterCollect);    // Create the performance counter.    PerfCount = new PerformanceCounter(Application.ProductName,                                       "Error_Count",                                       false);    // Create the random number generator.    EventVal = new Random(DateTime.Now.Second); } private void btnTest_Click(object sender, System.EventArgs e) {    // Set the number of events per second.    EventGen.Interval = Convert.ToInt32(1000 / txtTimerVal.Value);    // Start the timer.    EventGen.Start(); } private void EventGen_Tick(object sender, System.EventArgs e) {    // Generate a random error event.    if (EventVal.Next(5) <= 1)       PerfCount.Increment(); } private void frmMain_Closing(object sender,                              System.ComponentModel.CancelEventArgs e) {    // Destroy the counter.    PerformanceCounterCategory.Delete(Application.ProductName); }

I used a standard Windows application for the example, but the same technique works fine in a component or any other kind of application you want to create. The constructor begins by initializing the counter. This example shows a very simple counter. The code begins by creating a counter and a counter collection to hold it. It then uses the PerformanceCounterCategory .Create() method to add the collection to Windows. The collection can contain any number of counters and you can create counters of various types. You can read more about the various performance counter types at http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemDiagnosticsPerformanceCounterTypeClassTopic.asp.

Creating a performance counter for Windows doesn’t provide access to it. The code creates a new PerformanceCounter object using the name of the counter category and the individual counter. Notice that you must set the ReadOnly argument to false or you won’t be able to generate new data for the counter.

The one element in the constructor that you don’t need to create, in most cases, is the Random object, EventVal object. This object generates random errors in this example. In a production environment, you’d only want to know about the real errors.

The btnTest_Click() method sets the timer interval and starts the timer. Once the timer starts, it generates ticks at the rate specified by the Interval property. Each call to the EventGen_Tick() event handler is the result of a tick. The code checks the current random number value. If it’s less than or equal to 1, the code increments the performance counter using the PerfCount.Increment() method.

Because this is a temporary counter, you should destroy it before you exit the application. The frmMain_Closing() method accomplishes this task. All you need to supply is the name of the counter category.

Start the program at this point, so you can test it. Use the following procedure to view the output of this application:

Open the Performance console located in the Administrative Tools folder of the Control Panel. You’ll see the Performance console consisting of the System Monitor and Performance Logs and Alerts snap-ins.
Select the System Monitor snap-in. The right pane now contains a graphic display of some type.
Add a new counter to the display by clicking the Add button (looks like a plus sign). Select the application name, PerfCounter, Performance Object field, and Error_Count from the Select Counters from List field.
Click Add, and then Close.
Click Test. The program will begin generating random error events. Figure 9.9 shows typical output.

Figure 9.9: Use a performance counter to help detect DDOS attacks.

Detection is a good first step in dealing with a DDOS attack. Obviously, you need to remedy the problem once you detect it, which could be the topic of another book (or at least a very long article). Most companies find ways to increase Web server capacity during a DDOS and then filter packets coming from the zombies attacking the server. Generally, you’ll find that you need to work with a network administrator during the remedy phase to ensure that the DDOS attack doesn’t bring your system down. Because there are so many possible solutions, I won’t discuss the remedy phase in detail in this book.