CC Attack Protection

A CC (Challenge Collapsar) attack continuously sends large numbers of HTTP or HTTPS requests to consume application connections, computing resources, or upstream service capacity, causing legitimate requests to slow down or fail. Unlike volumetric attacks that primarily consume network bandwidth, CC attacks often target resource-intensive endpoints such as login, search, and dynamic query APIs. Each request can appear legitimate, so effective protection needs to consider both request characteristics and access frequency.

OpenResty Edge provides multiple layers of protection, from request controls to network-layer IP blocking. Page rules define where a policy applies, group requests by keys such as client IP address, URI, and Cookie, and delay, challenge, reject, or block abnormal traffic when a threshold is reached.

# Protection capabilities

# Request-layer protection

Request-layer actions protect HTTP and HTTPS endpoints and are the primary controls for mitigating CC attacks.

• Limit request rate: Smooth request traffic with a leaky-bucket algorithm, delaying requests before rejecting them at the configured threshold.
• Limit request count: Count requests in a fixed time window and execute a rejection action after the threshold is exceeded.
• Delay requests: Add a fixed delay to requests that match a page rule, reducing the efficiency of automated clients.
• Block requests: Observe the request rate over consecutive time windows and block requests for a configured period after the conditions are met.

# Network-layer blocking

Network-layer actions drop packets from the source IP at the operating system level and therefore have a broader impact than rejecting an individual HTTP request. Verify that the source IP is reliable before using these actions to avoid blocking legitimate users behind a shared egress, proxy, or NAT gateway.

• Block source IP: Block the source IP of the current request for a configured period.
• Block an IP list: Block the source IP at the operating system level when it matches a predefined IP list.

# Additional traffic protection

The following capabilities do not identify typical HTTP CC requests, but they can protect TLS handshake resources or control response bandwidth.

• Limit SSL handshake rate: Limit the TLS handshake rate by client IP address.
• Limit response data rate: Limit the response transmission rate for matching requests so large responses do not continuously consume outbound bandwidth.

# Choose a protection action

# Core configuration concepts

# Conditions

Page rule conditions determine which requests enter a protection policy. Start with resource-intensive or automation-prone endpoints such as login, search, checkout, and dynamic APIs instead of applying the same threshold to the entire application.

# Keys

Keys determine how requests are grouped and counted. Common options include client IP address, URI, URI argument, Cookie, a specified request header, and the first or last IP address in X-Forwarded-For. Combining keys creates a more granular counting dimension. For example, the combination of client IP address and URI limits each client’s access to each endpoint independently.

Before using X-Forwarded-For as a key, ensure that requests can arrive only through trusted proxies and that those proxies overwrite or sanitize any client-supplied header with the same name. Otherwise, an attacker can forge the header to bypass rate limits or cause an incorrect block.

# Thresholds and time windows

Rate-based actions delay or reject requests based on the number of requests per unit of time. Count-based actions total requests in a fixed time window. Set thresholds from normal traffic peaks, endpoint cost, and the acceptable burst size, then adjust them gradually after observing production behavior.

# Rejection actions

After a rejection condition is met, OpenResty Edge can close the connection, return an error page, require a CAPTCHA or JavaScript challenge, mark the request as rejected, or block an IP when supported by the selected action. For traffic that can include legitimate users, prefer a recoverable action such as a CAPTCHA. Use connection closing or IP blocking after confirming a malicious source.

# Configuration workflow

1. In Edge Admin, open Page Rules for the target application.
2. Create a rule and define its conditions from the URI, client information, or request characteristics.
3. Under Actions, select the appropriate CC attack protection action.
4. Configure its keys, thresholds, time windows, and rejection action.
5. Create the rule and release the application configuration.
6. Use controlled test traffic to verify normal requests, threshold handling, and behavior after the limit expires.

The SSL handshake rate limit is enabled from the application’s SSL configuration page. For details, see Limit SSL handshake rate.

# Configure CC attack logs

After enabling a protection rule, also enable CC attack logs to create a feedback loop of detection, handling, observation, and tuning.

In Edge Admin, open Global Config > Logs, enable CC Logs, and configure the log rate limit, protection statistics expiration time, shared memory size, buffer, and flush interval for the expected attack volume. Log rate limiting avoids writing an entry for every request during a high-rate attack and reduces load on the logging system.

After releasing the configuration, open Application > CC Logs to review triggered records. Use the client identifier, URI, handling result, and trigger frequency to determine whether the thresholds are appropriate. For configuration and testing steps, see CC Attack Logs.

# Scope

Rate-limiting state is isolated by application by default and is not shared across applications. For example, after a client triggers a request rate limit in application A, it can still access application B if no limit is triggered there. This differs from using a global shared rate-limiting zone directly in NGINX.

Operating system-level IP blocking drops all packets from the source IP. Evaluate its impact against the actual network topology before enabling it.

# Tuning recommendations

• Establish a baseline first: Use monitoring and access logs to understand request rates during normal periods and business peaks before setting the initial thresholds.
• Narrow the rule scope: Start with high-cost URIs, abnormal regions, or explicit automation characteristics to reduce impact on legitimate traffic.
• Choose stable keys: When many users share an egress IP, do not rely on the client IP alone. Combine it with the URI, Cookie, or another trusted identifier.
• Escalate handling gradually: Start with observation, delays, or challenges, then move to rejection or blocking based on attack duration and false-positive results.
• Combine multiple layers: Absorb short bursts with request rate limiting, handle sustained abnormal traffic with request blocking, and apply network-layer blocking only to confirmed attack sources.
• Tune from CC logs: Regularly review trigger sources, affected URIs, and handling results to identify thresholds that are too strict, rules that are too broad, or changing attack characteristics.
• Verify recovery behavior: In addition to testing the trigger behavior, confirm that legitimate requests recover after a time window or block expires.