What is our primary use case?
We have been using Radware DDoS extensively for the past two years in our production network within the utility sector. Primarily, we use it for application layer filtering and for direct termination with our Internet Service Providers (ISPs). Initially, we encountered several challenges during the configuration process, primarily due to the lack of ready-made templates. However, over the last two years, we have successfully implemented filtering measures, effectively mitigating our DDoS attacks by removing unwanted traffic directed at our public IP addresses.
This system has been crucial in securing our operations and meeting our specific needs for our data center. All public domain URLs in the utility sector are hosted behind an Internet firewall, ensuring that the traffic directed to these public domains is properly managed through DDoS protection. That sums up our experience with this system.
How has it helped my organization?
Radware DDoS has been effective at mitigating advanced DDoS attacks such as burst or DNS attacks and encrypted SSL floods because we blocked all public domain IPs through access lists at my DC router, where all the ILLs are delivered from the ISP. We are getting IOCs, which are Indicators of Compromise from CERT-In, NCIIPC, and CS K-Cyber Swachhata Kendra, from central agencies.
My experience with the behavior-based detection technology for real-time attack detection and minimizing false positives is quite positive. The behavioral framework we have consists of three layers. The first layer focuses on DDoS protection, as we are implementing two policies for two ISPs simultaneously. In our environment, we are not using an active-standby setup; instead, we utilize both links from each ISP. Therefore, we are deploying two identical boxes, one connected to each ISP. These ISP links are directed towards our management service, where all public domain sites are hosted in our data center. Regarding the behavioral aspect, let's consider a scenario where there is suddenly a spike in packet traffic from a public domain. We typically monitor the daily bandwidth usage on the ISP side. For example, if the average bandwidth usage is around 200 Mbps, but one day we notice a surge to 400 Mbps, this may indicate unknown traffic hits. This is particularly concerning because we operate in the utility sector, where we collect electricity bills each month. We use handheld devices to fetch these bills from our system, processing them at the beginning of each month. This increase in traffic could likely stem from these sources, as they may be generating numerous unknown visits to our data center servers in an attempt to log in.
To analyze this behavioral pattern, we first examine the trust levels associated with the bandwidth usage. We investigate the cause of the sudden increase in bandwidth and identify the unknown IP addresses responsible for the traffic. We then determine the locations of these IPs and formulate policies in our DDoS logon system to block any suspicious activity. Additionally, we address two other behavioral patterns: one through endpoint security for end-user services and another through anti-Advanced Persistent Threats (APT) measures. This comprehensive approach helps us safeguard our systems effectively.
Radware DDoS protects legitimate users during a DDoS attack. We have a behavioral filtering template that we enabled after subscription. Every month, we create a report analyzing the number of unknown hits generated from DDoS, identifying legitimate IPs from our customer base and unknown IPs from other countries. We conduct geo-fencing as the first level of protection, allowing only Indian region IPs to execute packets towards our management server. The second level involves using default templates to perform this activity efficiently.
What is most valuable?
The HTTP Layer 7 protection works effectively as the signatures are updated on a daily basis and automated from the Radware cloud. Zero-day protection happens automatically because the initial steps only require us to create the policy for filtering, but after that, it continuously does its job without any manual intervention.
The zero-day attack signatures for new types of attack threats and vulnerabilities are directly taken from the cloud and blocked. For DC network flow, the fast layer DDoS attack itself is removed from the entry point from the ISP side only. After that, the traffic lands with DDoS, coming from my perimeter firewall, providing another layer of filter and protection. After my perimeter firewall, the traffic goes to my anti-APT, where we perform another level of protection or filtering for DDoS.
What needs improvement?
There are areas where Radware DDoS could improve, specifically regarding centralized visibility. If someone is allowed access to one payment server but attempts to access the backend database and application servers from that source, we need to analyze the level of propagation. If they are performing suspicious activities such as random logins, it would be beneficial to have a centralized console that shows which IP is attempting which actions for greater visibility, enabling better analysis.
To sum it up, we suggest that clear visibility within a management console could significantly enhance Radware DDoS's usability. We use Radware DDoS and Check Point for our public site because understanding the origin and pattern of public hits is crucial. If the console could segregate packets by type—such as HTTPS, logger, database-related queries, or other behavioral data—and generate reports accordingly, it would better aid our analysis.
For how long have I used the solution?
We have been using Radware DDoS for two years.
What do I think about the scalability of the solution?
In terms of scalability, Radware DDoS excels. One device we procure is reliable and automates filtering by downloading signatures and providing behavioral analysis. It operates with predefined signature filtering without needing much from us other than receiving reports. I would rate its scalability as nine out of ten.
How are customer service and support?
I have contacted technical support for Radware DDoS many times, and their support quality is the best I have encountered in my entire career. Their responses are quick, and the support surpasses my experience with other OEMs such as Check Point, Sophos, Fortinet, and Cisco, who can often be slow with their solutions.
I have faced issues and approached TAC, and their ability to provide skilled and technically sound support is impressive. They accurately address the service requests and come up with effective solutions faster than many other manufacturers. Their support is significantly better than other OEMs who often resort to trial-and-error methods.
Which solution did I use previously and why did I switch?
Throughout my career, I have done DDoS filtering through ISPs, but currently, we have a dedicated appliance for DDoS, following recommendations from the DOT and Central Government of India for compliance with ISO 27001 certification.
How was the initial setup?
The initial deployment process can be quite challenging. The business analyst or and solution integrator often creates confusion, particularly in our location. The Solution Integrators are usually not able to explain everything clearly in one go, which means we often have to go through the information piece by piece. As a result, completing the initial setup and implementation can take nearly forty-five days. If there were a ready-made template available, it would greatly simplify the process. We need to identify the specific hardware requirements and develop a checklist for hardware compatibility and configuration that meets our cybersecurity policies. To comply with these policies, we are currently working on strategies to mitigate potential risks.
Getting a ready-made template for hardware considerations, including guidance on how to harden that hardware before moving to the production level, would be extremely helpful. Additionally, having recommended guidelines from Radware on enabling these policies could streamline our implementation process. In my opinion, this approach would allow us to complete the entire solution implementation within the recommended timeframe.
Maintenance involves ensuring that hardware is functioning properly, including checking subscriptions and enabling necessary blades. For example, last month, we had to enable geo-fencing to block all traffic except from India, which involved re-enabling a previously disabled geo-fencing blade. If there were a central management console that provided alerts about system health, such as fan RPMs and SMPS performance, it would help us maintain the Radware DDoS system proactively.
What about the implementation team?
Typically, two to three people are required for deployment. Initially, we communicate with the application team to ensure proper TLS and SSL levels. After confirming application legitimacy, we assess the delivery and operation level, followed by database and server reviews before concluding that the application is ready to integrate with the DDoS devices.
What's my experience with pricing, setup cost, and licensing?
We are going for seven-year support with a solution comprising two hardware boxes for redundancy and high availability, priced at around 2.4 crores. This pricing is manageable without any worry.
Which other solutions did I evaluate?
I have considered competing products in the market. We have raised a request for another solution besides Radware DDoS, as Cloudflare has been selected as L1 for another DR setup we are trying to establish. Management requests that we consider similar solutions, which is why Radware DDoS remains qualified as L1.
What other advice do I have?
I would rate Radware DDoS a nine out of ten.
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.