Detecting DDOS and Other Security Problems
- Overcoming the Paucity of Tools
- Defining Custom Performance Counters
- Testing Your Custom Counter
- Real-World Counter Generators
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
To ensure that an application can enforce security, many software security techniques focus on building walls between the user and the application or its data. However, walls alone won't protect your system. A necessary step in building solid software is to assume that a cracker can breach any security measure you provide. Making this assumption means that you must monitor the system and detect breaches as they occur. If you can detect a breach in your application before it becomes a major problem, at least you can close the door on intruders.
Overcoming the Paucity of Tools
Most vendors are still at the first step of building secure software: they build high walls. For example, if you search through the Microsoft Developer Network (MSDN) documentation, you'll find few topics on detecting security breaches. Most MSDN security topics focus on enforcing security, rather than assuming that security measures will fail at some point and taking proactive measures. In fact, after several searches, I finally gave up finding any detection topics at all. Worse, the detection problem isn't just limited to Microsoft and the people who build the MSDN documentation.
However, you don't have to live with the fact that the sources of information for detecting security breaches is somewhat lacking, because you already have many of the tools you need.
When developing code with an eye toward security, you must consider the needs of the cracker. I've seen many articles espouse the view that the developer thinks like a cracker, but that perspective doesn't really help; you need to consider what the cracker needs to invade your system. Most crackers won't succeed on their first try or on their second. Crackers often spend hours taking your code apart, looking for flaws. Once one or more crackers find a flaw, they require additional time to develop an exploit that makes use of the flaw. (The exploit time is becoming progressively smaller, hence the need to find other methods of dealing with the problem.)
Consequently, you can monitor your system for odd usage patterns in an attempt to detect cracker activity. Monitoring the heartbeat of your applications lets you detect events as obvious as a Distributed Denial of Service (DDOS) attack or as subtle as a cracker searching for easy passwords.
You should determine what tool you can use to perform security monitoring because there's nothing documented and no obvious controls you can use. Many developers view performance counters as something to monitor application behavior in an effort to improve performance. However, performance counters are just tools, like any other tool in your kit. You can also use them to watch other activities and use the data to create non-standard pictures of your application. For example, you could create a counter that detects the number of non-secure access attempts to your application. Because an authorized user would know to use a secure connection, a high number of non-secure accesses could point to cracker activity.
Likewise, you can monitor application activity using a custom performance counter. If you suddenly notice that the system is handling more requests than usual, it could point to a DDOS attack or at least an activity that you should check out. You don't necessarily have to monitor errors; you can monitor any activity that could point to a cracker activity. The monitoring doesn't have to remain in place at all times, either. You can use configuration settings to modify the monitoring activities of your application as needed. The point is to create a flexible application that assumes someone is going to take the code apart looking for flaws to exploit.