“Netflow collection.” This is what I kept hearing from DDoS providers when I asked how they monitored networks. But there are a couple problems with utilizing NetFlow.
Problem 1: Sampling Rates…
I’ve very rarely seen a sampling rate of 1 on routers. Cisco’s CRS shelves and ASR9ks as well as Juniper’s TX Matrix Plus and MX960s are certainly capable of sampling 100% of flows and packets through the box.
But because of performance worries, the majority of implementations I’ve seen monitor 50-80% of packets traversing core routers. This means that the majority of customers aren’t viewing 20-50% of the flows per second.
In fact, JUNOS is only capable of sampling 65,535 packets per second. Have more flows that than? Sorry.
Pulling Netflow from a firewall? These sampling rates are typically in the 20-60% range due to the processing done on packets.
Basically, your cloud provider is starting out behind the 8-ball and possibly missing out on a lot of the flows making it into your network.
Problem 2: Low and Slow attacks are COMPLETELY missed
Low and Slow DDoS attacks are getting more and more frequent. DNS and NTP amplification attacks, Slowloris, and SlowHTTPTest are all ways to creep through IPS, Netflow, and Firewalls.
NetFlow collection techniques won’t recognize this traffic as harmful. DNS/NTP amplification visibility may show up on the radar, but if you operate a public facing DNS, it may not.
These DDoS mechanisms are designed exploit protocol vulnerabilities. You can’t close those vulnerabilities without closing the functionality of HTTP/DNS/NTP.
Problem 3: Reputations aren’t as reliable anymore
But, you say that there are known Slowloris instances at certain IP addresses? Ok, fine, but does that mean it’s a hacker or could it be your grandma’s compromised machine legitimately trying to visit your website?
“Well what about China?” There are some companies who know they’ll NEVER see traffic from China. They can block and mitigate this traffic, but the globalization of today’s economy is increasingly making it difficult to black-list entire countries.
“What about a mass of users all of the sudden?” Go check with your marketing department, they may have just tweeted a 95% off coupon for the next hour. This type of thing happens all of the time and is typically a false alarm for NetFlow DDoS mechanisms.
Solution? On-premise 1st line of defense
On premise detection and/or mitigation is the way to go for your first line of defense.
Almost every company has a firewall. Most companies have an IPS/IDS solution in place. A lot have Malware detection/mitigation in place. Few have a dedicated DDoS appliance installed. When asked, most customers reply with “Well, my signatures and SCREENs should catch the traffic.”
Not so! As mentioned above, attacks are utilizing common transport protocol mechanisms for their attacks. And the traffic being let in isn’t matching any signatures or it is going too slow to hit your screens.
That said, you CAN put something on your network that inspects the traffic for behaviors instead of signatures. Much like a load balancer, these systems view resource loads and inspect packets to make decisions based on the likelihood of traffic being genuine or not.
Check out Juniper’s DDoS Secure, Radware’s DefensePro, and Vectra Networks for heuristic-based protection. These are really cool technologies!
- If your bandwidth can’t handle the flood, send the dirty traffic to the cloud laundry service, for everything else, keep it on premise.
- It’s a good idea to have more than one detection mechanism, so I’d still recommend using a NetFlow collector, but just not as a primary tool, and definitely not one tied into anything very “automatic”.
Have an opinion? Leave a comment!