The joint Corero-Juniper Threat Defense Director (TDD) anti-DDoS solution protects network infrastructure from volumetric DDoS attacks that continue to grow in magnitude, frequency and sophistication. Today, the solution has already been deployed and proven in many sectors including service providers, OTTs, enterprises and research and education institutes. Customers are experiencing huge benefits from TDD’s effective detection and real-time mitigation of rapidly changing multi-vector attacks. This new experience often provokes questions, such as, “How can TDD detect attacks so quickly?”, “I used a mainstream DDoS protection solution for a for a long time and saw a lot of false-positives, but I see little in TDD, how is that?”, “Can TDD protect my network from zero-day attacks?”, “Are there attack databases that I need to update regularly?” and many more.
This blog provides answers to these questions and explains how TDD delivers its fast, automatic DDoS protection.
Legacy DDoS Database Maintenance
To start, let’s understand the legacy approach of maintaining an attack vector signature database.
An attack vector is defined by combinations of packet attributes. For example:
Attack Vector = (1) Destination IP + (2) Protocol Number + (3) Port + (4) Payload and more.
Traditional anti-DDoS tools can only inspect packet headers and use hard-coded entries to define attack vectors, which are then matched against packets on a per-destination IP basis. For example, DNS reflection and amplification attack is UDP-based with a fixed source port 53. These attacks also typically have the QUERY ANY flag set, but this requires packet payload inspection, which most DDoS solutions cannot achieve. When a new or zero-day attack is launched by attackers in the wild, the first batch of targeted victims must suffer and report the incident to the security vendors. Vendors then investigate the new DDoS vector and provide mitigation countermeasures, usually by using hard-coded signature database.
Dynamic Inspection Pipeline
However, using a hard-coded signature database is not an agile and smart solution to detect continuously evolving DDoS attacks as it requires a mechanism to learn and inspect traffic dynamically based on the traffic behavior in the network. TDD’s dynamic inspection pipeline, together with a powerful analytic engine, SecureWatch Analytics (vSWA), is designed for this purpose.
Figure 2 below shows the dynamic inspection pipeline adopted by TDD. Raw packets are deeply inspected. Attributes are intelligently tracked and the analytics engine creates traffic signatures that are applied to a Juniper router’s flexible-match filter. For example, when users visit a http server, the initial TCP 3-way handshake triggers at least 3 signatures:
- <http IP>, tcp, dst port 80, length=64, SYN
- <http IP>, tcp, dst port 80, length=64, SYN-ACK
- <http IP>, tcp, dst port 80, length=64, ACK
In the same way, when a Mac user enables ARMS on MacOS, the traffic examined by TDD creates a signature of <IP>, udp, src port 3283 and so on. The inspection and signature formation are fully dynamic and automated based on behavior and not static values. This is the reason why regular database updating is not required with TDD.
Traffic Pattern Analytics
In this section, we discuss TDD’s detection mechanism by leveraging granular traffic pattern analytics.
Analytics by (Victim) IP Volume
The least accurate DDoS analysis just uses IP traffic volume without any details. In the below example, the protected server normally receives 5Gbps of traffic, so the operator sets up a 10Gbps mitigation threshold. When incoming traffic suddenly surges to 15Gbps (3x higher), can we tell this is a real attack? No, we can’t. There is no information about whether the leap is caused by an increase in legitimate transactions or malicious flooding. We don’t know which service running in the server attracts that traffic or attack. If the operator blindly discards the traffic based on /32 prefix, e.g., RTBH, they basically complete the DDoS or, worse, block legitimate traffic when there was no DDoS attack.
Analytics by IP + Service (Port)
Now, if the operator analyzes server traffic more intelligently by service, namely FTP, DNS or SSH, the contribution of each service can be illustrated and mitigation threshold of each service can be set up individually. When traffic surges, we can identify that the suspicious traffic is caused by FTP and the mitigation countermeasure does not affect DNS and SSH services. The precision is equivalent to flowspec (5-tuple). Yet, we still cannot tell whether the traffic in the surge is legitimate or not. Could it be a legitimate event, e.g., marketing campaign or data migration, where FTP access is required?
Analytics by Signatures
The advantage of deep packet overflow inspection is that it’s not limited to 5-tuple. It may include a packet’s TTL, length, control flags, fields in the payload and more. Signatures are useful to analyze traffic patterns and network behavior. Let’s take another look at the server traffic in the above example.
Figure 4 below shows the signature chart. The traffic matches numerous signatures which are uniformly distributed and consistent. During the busy period, incoming traffic is triple due to frequent access by FTP users. The activities create more signatures of each transaction, and all of them behave normally with similar volume as those in the background. Based on that, we can conclude with a high level of confidence that they are legitimate transactions, and the server is unlikely to be under attack.
Elimination of False-Positive
Different threshold values can be set up to discriminate signature families such as UDP-based reflection, TCP SYN sent to a service port, ICMP request and reply, etc. Detections and mitigations triggered by specific signature thresholds are more precise than /32 prefix or flow-based (5-tuple) traffic thresholds. Surgical discrimination in this way avoids false positives and ensures protection accuracy is not affected by changes in legitimate traffic rates.
When a protected asset is under attack, TDD creates a distinct signature which matches common packet attributes. For example, an abrupt surge of UDP packets, which come from a fixed source 1121 port with large 1500B size and the same TTL, is likely a reflection and amplification attack. This is easy to illustrate the malicious behavior by fine-grained analytics.
“Corero has over a decade of experience focused on DDoS and has developed highly accurate ways of detecting attack traffic that are not dependent on fixed pattern signatures.” – Sean Newman, VP Product Management, Corero Network Security
Zero-Day Attack Handling
As we have seen, TDD leverages a dynamic inspection pipeline and fine-grained signature analytics to detect abnormality in the network. The solution is also capable of identifying malicious behavior and mitigating the attack vector. In 2018, cybercriminals took advantage of a Memecached server vulnerability to launch volumetric, zero-day DDoS attacks. Corero’s solution detected the high rate of large size UDP response packets. The solution successfully and accurately mitigated these attacks without any software or configuration updates. Corero SOC retrieved the attack vector afterward, discovered this was an abuse of the Memecache service and named the attack as Memecached Reflection and Amplification DDoS. Thus, a new rule name was created for dashboard and reporting purposes in a subsequent software release.
A Real Example
Seeing is believing. So, let’s look at real customer traffic analytics.
Figure 8 below shows a normal traffic pattern captured by TDD’s SecureWatch Analytics engine (vSWA). The pattern is uniform without any abrupt surge. Packet rate ranges 5kpps to 10kpps. Signature deviation is low.
When the network is under attack, the malicious signature is very distinct. Figure 9 below shows a few volumetric attack vectors. Their packet rates are ~100x more than the usual traffic rates. Attack vectors in high deviation can be differentiated effectively by setting up threshold values 5-7x above the usual signature rate. Malicious traffic can be mitigated precisely by filters which match the inspected signatures, i.e., the attack vectors.
TDD is designed to tackle volumetric DdoS attacks. Consider a 1kpps DdoS attack might harm an individual server, but this is trivial in a provider edge network, which runs Tera bits of traffic, whereas a millions pps attack would cause collateral damage of the infrastructure and critical services. When the network is targeted by volumetric DdoS attacks, organizations need an effective tool to block the tsunami outside the door and prevent it from crippling their infrastructure.
Fully Automated Mitigation
A sound anti-DdoS solution should detect and mitigate attacks accurately. We have discussed how TDD detects attacks. Now, let’s touch a little bit on the mitigation. TDD’s traffic analytics capability allows it to discriminate malicious signatures. These signatures may reside in an upper layer such as DNS QUERY flag and a few bits in NTP payload. In order to block malicious packets precisely, deep packet inspection is required in the mitigator. TDD leverages Juniper’s routers to achieve this at scale. By utilizing the solution’s deep packet inspection capability via Juniper’s Trio silicon, attack packets are blocked by flexible-match firewall filters. The filter formation and enforcement are fully automated and crafted by the analyzed signatures. Thus, operators do not need to panic to login and build the mitigation filter bit by bit manually.
Cybercriminals do not stand still. Their tricks to launch DdoS are evolving and becoming more sophisticated. A legacy solution that relies on a hard-coded signature database cannot catch the tide. With dynamic inspection and fine-grained traffic analytics, Corero TDD combined with Juniper solutions detects and precisely mitigates volumetric DDoS in any network empowering businesses and services.
Want to learn more? Join us for an upcoming webinar on November 9th for a technical deep dive and see the live demo in action.