Here is part 1 of this blog.
Detecting DDoS Attacks
A DDos attack is a tricky monster because it can look like legitimate traffic. We have come up with an algorithm for detecting DDoS attacks that from our tests seems to be accurate. We say this because it largely reduces the risk of false positives. It involves flow volumes, byte sizes and standard deviations. Although it is fairly complicated, it will still need modifications as DDoS behavior morphs over time.
Stopping DDoS Attacks
While I’m not offering a definitive solution to stop all DDoS attacks I am suggesting that implementing URPF (Unicast Reverse Path Forwarding) is something that you many want to consider.
There is one short coming with URPF that is glaringly obvious when using it for DDOS mitigation. It assumes that the source addresses are spoofed and invalid. The whole thing hinges on whether the attacker(s) are available to route back to. Today’s attacks tend to be more sophisticated, using botnets to attack. As far as the router is concerned, this is valid traffic and will be happily forwarded on when this technique is used. This is a bummer so, detection and reactive response is still a good solution to implement as part of your strategy against DDoS attacks. Reactive can mean detection, trigger event and scripting an automated action to contain the attack to a router or switch interface.
Conversation and Flow Behavior
While monitoring for network scans or hosts communicating with known Internet bad guys are good security practices, other less obvious enigmas are detected like DDoS over a series of events. For example, If an average user communicated with 100 or so hosts with only one flow each, would you consider this odd? Most security professionals would agree that this pattern or other Nefarious Activity is suspicious but, not necessarily a definitive threat. It might depend on the host involved. A flag could get raised but, not necessarily an alarm.
What if a host closed less than 10% of the 100 or so connections it opened? Again, this may not be a guaranteed problem however, suspicions and a flag could get raised. In Flow Analytics, these flags raise the Unique Index (UI) for the host. If the UI increases beyond acceptable levels, events and alarms can be triggered.
Alarming based on excessive flags is another way to help avoid false positives.
Alarming for Specific Patterns
What can you do if the NetFlow traffic or sFlow traffic you want to monitor for is not one of the pre canned algorithms? There are two ways:
- You can create your own using a saved report in Scrutinizer NetFlow and sFlow Analyzer. Once you have defined the report by including or excluding certain traffic, you can set a threshold either over or under a volume limit. See the example below which sets a threshold on an NBAR Application ‘Skype’:
- The second way to define a monitor is to contact Plixer and explain what you want to monitor for. They in turn can create an algorithm and use Flow Analytics to routinely check for the traffic pattern.
Your largest security threat is internal. Make sure you have setup Flow Analytics correctly or call us to review the configuration.
What type of traffic are you looking to monitor?