Configuring Radware DefensePro To Mitigate HTTPS Floods

HTTPS floods can consume application resources even when network bandwidth remains available. Attackers generate large volumes of TLS connections or realistic web requests, forcing servers, load balancers, and security appliances to spend CPU cycles on handshakes, encryption, session tracking, and application processing.

Radware DefensePro can reduce this pressure when it is deployed with clear traffic baselines, carefully staged thresholds, and a mitigation policy matched to the protected service. The appliance should be configured to distinguish normal encrypted traffic from abnormal connection behavior without blocking legitimate users during traffic spikes.

The most important design decision is determining where TLS is terminated. If DefensePro sees only encrypted payloads, it can still identify volumetric, transport, and connection-rate anomalies, but deeper HTTP inspection requires decryption at an ADC, reverse proxy, or another inspection point.

Map The HTTPS Traffic Path

Begin by documenting the complete request path: Internet edge, router or firewall, DefensePro, load balancer, web tier, API services, and any upstream DDoS provider. Record whether HTTPS terminates on Radware Alteon, a cloud load balancer, a web application firewall, or the origin servers.

This path determines which DefensePro protections are practical. When TLS terminates behind the appliance, DefensePro can analyze source behavior, destination services, packet rates, connection rates, TCP flags, and session patterns. When decrypted traffic is forwarded through an inspection point, HTTP methods, URLs, headers, and response behavior may also support more precise mitigation.

Create separate service objects for important applications rather than combining every HTTPS endpoint into one policy. A public website, API gateway, authentication portal, and administrative interface usually have different traffic profiles and should have different thresholds.

Establish A Normal Traffic Baseline

Collect at least several business cycles of traffic before enabling aggressive enforcement. Useful measurements include new TCP connections per second, completed TLS handshakes, concurrent sessions, requests per second after TLS termination, average response time, and the percentage of rejected or reset connections.

A baseline should include expected peaks such as marketing campaigns, release events, payroll processing, and scheduled API jobs. A fixed threshold that works during quiet overnight traffic may cause false positives during a legitimate product launch.

DefensePro’s behavioral protection is most effective when it has representative traffic to evaluate. Start in a monitoring or learning mode where possible, review generated events, and identify trusted monitoring systems, health checks, CDN nodes, and partner networks before applying restrictive actions.

Build A Layered DefensePro Policy

Use multiple controls rather than relying on a single request-rate value. Transport-level protections can address SYN abuse, connection exhaustion, malformed packets, and unusual TCP behavior. Connection-rate controls can limit rapid session creation from individual sources or aggregate networks. Behavioral filters can identify deviations in packet size, protocol sequence, and access patterns.

For encrypted services, pay particular attention to TLS handshake pressure. A flood of short-lived HTTPS sessions can exhaust CPU and memory before the application receives a meaningful request. Set thresholds for new connections and concurrent sessions, then tune them against the normal ratio of handshakes to completed sessions.

If TLS is terminated on an upstream ADC or reverse proxy, apply application-aware controls there and use DefensePro to protect the transport path. If DefensePro participates in an architecture that supports SSL inspection, validate certificate handling, cipher compatibility, privacy requirements, and the performance cost before enabling decryption in production.

Control Area	What It Detects	Practical Response	Tuning Consideration
SYN and TCP behavior	Half-open sessions, malformed flags, abnormal handshakes	Challenge, rate-limit, or drop	Preserve legitimate mobile and high-latency clients
New connection rate	Bursts of TLS sessions	Per-source or aggregate throttling	Compare with normal peak connection rates
Concurrent sessions	Connection table exhaustion	Cap or slow excessive sessions	Account for long-lived browser and API sessions
TLS handshake behavior	Repeated or incomplete negotiations	Rate-limit suspicious handshakes	Monitor cipher, protocol, and client diversity
HTTP request behavior	High request rates or abusive paths after decryption	Block, challenge, or shape requests	Exclude health checks and trusted integrations
Source reputation	Known malicious or unstable origins	Drop or quarantine traffic	Avoid broad geographic blocks without evidence

Configure Detection Before Blocking

Create a policy in stages. First, attach the protected HTTPS virtual service or destination object and confirm that DefensePro is receiving the expected traffic. Then enable detection for anomalous rates and protocol behavior while keeping the response in alert, report, or simulation mode.

Review events for source distribution, destination ports, packet rates, action status, and time correlation. A genuine flood often produces a sharp change in several dimensions at once: connection rates rise, session completion falls, source diversity changes, and the service begins returning errors or timing out.

After validating the event pattern, enable graduated actions. Rate limiting is often safer than immediate blocking for borderline traffic. Stronger actions can be reserved for sources that repeatedly violate thresholds, exhibit malformed protocol behavior, or match verified attack signatures.

Coordinate DefensePro With The ADC

DefensePro and the application delivery controller should have clearly separated responsibilities. DefensePro can absorb or suppress hostile network and session behavior, while the ADC can manage TLS termination, HTTP persistence, URL routing, bot controls, and backend connection reuse.

Forward meaningful telemetry between these layers. Compare DefensePro alerts with ADC metrics such as SSL CPU utilization, handshake failures, pool saturation, backend queue depth, and HTTP 5xx responses. This correlation helps determine whether an incident is a volumetric HTTPS flood, an application-layer request attack, or a capacity issue unrelated to malicious traffic.

Use consistent source-IP handling throughout the path. Proxy Protocol, X-Forwarded-For, NAT, and CDN behavior can change how the origin sees clients. An incorrect configuration may cause DefensePro or the ADC to treat an entire proxy fleet as one attacker or may hide the true distribution of abusive sources.

Validate Failover And Logging

Test the policy during a controlled window before an incident occurs. Confirm that legitimate browsers, mobile clients, API consumers, synthetic monitors, and IPv6 users can establish sessions. Test both active and standby appliances, routing changes, asymmetric paths, and any bypass or fail-open behavior.

Centralize DefensePro events with firewall, ADC, web server, and monitoring logs. Record the policy name, action, threshold, protected object, source characteristics, and timestamps. These details make it easier to distinguish a false positive from a real attack and provide evidence for later threshold changes.

Retention and clock synchronization matter during investigations. Use reliable NTP, forward security events to a SIEM when available, and create alerts for sudden increases in mitigation actions, appliance resource utilization, dropped sessions, or protected-service latency.

Operational Recommendations

Keep the mitigation policy maintainable with these practices:

• Define separate thresholds for websites, APIs, login services, and administrative endpoints.
• Use alert-only mode during baseline collection and document every threshold change.
• Exempt verified health checks, monitoring agents, and trusted integrations by narrow criteria.
• Test TLS termination, routing, and failover after firmware or certificate changes.
• Review attack events alongside application metrics instead of judging success by dropped packets alone.

A DefensePro deployment should also fit the wider infrastructure strategy. Teams operating hybrid environments may place public services across data centers and AWS, making routing, certificate ownership, and cloud-side controls part of the same response plan. Engineers developing broader cloud skills can use this AWS certification path as a reference while mapping on-premises DDoS controls to cloud networking and security services.

Move From Baseline To Enforcement

Begin with one representative HTTPS service, capture normal behavior, and enable detection without disruptive actions. Once the event data matches application and ADC telemetry, introduce rate limits and targeted blocking in small steps.

Document the final policy, expected thresholds, rollback procedure, and escalation contacts. Then schedule recurring reviews after traffic growth, architecture changes, certificate updates, and major application releases. A tuned DefensePro configuration is a living control: measure it, test it, and adjust it before the next encrypted traffic flood reaches production.