Validating Cisco's Threat-Centric Security Solutions
Test case 2b: Radware DefensePro on Firepower 9300
SUMMARY: We reviewed the Radware DefensePro DDoS protection technology running on the Firepower 9300 platform, verifying the solution's ability to quickly detect and mitigate DDoS attacks on services and infrastructure through behavioral traffic analysis.
Radware DefensePro is a third-party solution for DDoS protection that is capable of running on the Cisco Firepower 9300 platform as a decorator application.
In this test case, we reviewed the functionality and management of DefensePro, as well as use cases for its utilization on the Firepower platform. Subsequently, we verified the DDoS protection function by simulating three widespread types of attacks -- SYN Flood, NTP Amplification Attack (i.e. UDP Flood) and the DNS Flood. As the source of attacks, we used a Linux PC running Kali Linux, which is equipped with various tools for network security testing.
The Radware Defense Pro is designed to mitigate DDoS attacks and provide an additional line of defense for the protected networks and services. It is available as a standalone appliance, a KVM image for generic virtualization, or as a Firepower 9300 application, which we evaluated in this test series.
The recommended location for the DDoS protection is in front of the firewall. This way, DefensePro is able to detect the attacks and analyze their behavior before they can be affected by other security infrastructure and at the same time protect the security infrastructure from the attacks.
When integrated to the Firepower 9300 platform, the DDoS protection function is placed in the similar way and inserted as a decorator application on top of the main application of the security module, e.g. the ASAv firewall.
DDoS protection can be utilized in various ways and locations. On one hand, it can be used as a part of the security service provided to the end customers in order to protect their cloud-based server infrastructure against attacks originating from the Internet. The security policies, DDoS mitigation techniques and other parameters can be defined and applied on a per-tenant basis.
Alternatively, it can provide protection for the security infrastructure itself, improving performance and reliability of other security products by deflecting some of the malicious traffic before it reaches them.
Finally, it can be used to detect and mitigate attacks originating from the local, protected networks, for example, from a protected office environment where a host may have become infected.
With the three attacks used in our test, we verified the functionality of the three main DDoS mitigation engines available in DefensePro.
The attacks based on traffic volume, but based on valid communication processes, can be detected and mitigated by statistical analysis of the traffic over time, a technology called Behavioral DoS by Radware. When such DDoS protection policy is applied, the BDoS engine will monitor traffic and learn the typical load profile of the service over a period of time. Strong deviations from the expected behavior can be then identified as ongoing attacks on the protected network.
The analysis of the traffic goes beyond layer 4/7 analysis. DefensePro collects a large number of parameters known about the flow, such as packet interval distribution, packet sizes, TCP Window size and so on. Abnormalities and difference from the values observed in the legitimate traffic may indicate an attack and trigger countermeasures.
The DNS Flood protection works on similar principles and can detect non-typical DNS query type distribution, a common characteristic for attack traffic. In case of a SYN Flood, DefensePro can apply a series of challenges to the incoming connections, in order to recognize legitimate and malicious clients. Unlike the BDoS engine, SYN challenge does not lead to packet drop or rate limiting. Instead, the engine answers the connection itself and runs a series of tests to distinguish the legitimate clients from malicious attack tools.
On the TCP layer, the protection against SYN Flood is achieved through SYN cookies, but even a legitimate connection can be additionally verified on ´the higher layers. For example, DefensePro can intercept the connection attempt to a web server and serve the untrusted client a HTTP redirect or a login/captcha page. Malicious tools designed for attacks and unable to process returned content will not be able to gain access to the protected web server.
The SYN Flood protection can be triggered when a certain threshold of unanswered SYN packet rate is reached, with rules defined individually for each network address and port. The threshold is not based on the total packet rate, but rather on the difference in observed SYN and ACK packets. Therefore, occasional spikes in the legitimate traffic will not trigger the protection.
Once the protection was triggered for an engine, it can apply dynamically generated rules (based on signatures) to drop or limit traffic classified as malicious. Once the attack traffic returns below the threshold, the rule will be removed.
We reviewed the configuration process of DefensePro using Radware's configuration and monitoring tool APSolute Vision.
Configuration of the protection involves creation of a network protection policy that defines which of the DefensePro's detection engines will be applied, and with which parameters. Then, the policy and the required action are applied to a specific traffic direction. Each instance of a learning engine works independently and is able to learn the unique traffic profile specific to a network or customer.
1. Attack mitigation – SYN Flood
We verified the attack detection and mitigation functionality of DefensePro by transmitting three types of attacks from the Kali Linux VM. We initiated a SYN Flood attack by issuing the following command on the attacker machine:
hping3 –S –p 80 –rand-source –flood 220.127.116.11
In the APSolute Vision GUI, we observed that the SYN Flood protection engine recognized an ongoing SYN Flood and applied a new rule to challenge incoming connections.
At the same time, the BDoS engine detected the same ongoing attack, although it was less specifically recognized as network flood IP.
Within the attack details, we could also display the dynamically generated classification rule to identify the attack flow. In case of an ongoing attack, this rule can be examined in order to better understand the source of the attack and identify the traffic being dropped.
After stopping the attack on the attacker machine, we verified that the attack status has been cleared and the classification rule was removed.
We could observe the behavior of the traffic after the BDoS mitigation was triggered. We see only a brief increase in the rate of SYN packets, which is then quickly blocked.
2. Attack Mitigation – NTP Amplification attack (UDP Flood) In this test we simulated the flood of NTP response packets generated by a NTP Amplification attack. From the perspective of the attacked network, this attack can be seen as a UDP Flood. The attack traffic was generated by hping tool.
We observed that BDoS engine reported a new attack and generated a new dynamic rule to classify the attack traffic flow. Under BDoS Traffic Monitoring Reports, we observed that the attack traffic was quickly mitigated after detection.
While the attack was ongoing, we accessed the web server located in the protected network and verified that there was no observable impact on the legitimate traffic.
3. Attack Mitigation – DNS Flood
In this case, we simulated a flood of DNS packets directed against a DNS server located within the protected network. The attack traffic was generated by the dnsflood tool.
We observed that both BDoS and DNS engines were triggered by the attack. A new dynamic rule was generated to classify the attack flows.
Similarly to the other test steps, the attack traffic was blocked within seconds after detection.
Table 3: Hardware and Software Versions
|Firewall||Firepower 9300||APSolute Vision v. 3.30.00|