Protect your apps with rate limiting in Citrix ADC

Your application server handles various streams of requests every day. But what if it gets overwhelmed with a huge influx of malicious requests? That can lead to your apps being compromised or can affect app performance.

The rate limiting capability in Citrix Application Delivery Controller (ADC) can help you to solve this problem. It gives you the power to block malign requests from these attackers so you can protect your system and limit/meter your resource usage.

In this blog post, I’ll look at five use cases where Citrix ADC’s rate limiting capability can help you to protect your apps and ensure a great user experience.

Rate Limit for the Overall Application

Assume the threshold for incoming requests for your application is 1,000 and the time slice is 10 seconds. In this case, 1,000 requests/10 seconds from any client to any URL is allowed. Any request coming in after that time frame (for example, request No. 1,001) will be dropped and the counter will be reset, rate limiting all your incoming requests.

So, to configure rate limiting feature on overall application, follow these CLI commands and fill in the appropriate values where required:

• add ns limitIdentifier <limit_identifier_for_application> -threshold 1000 -timeSlice 10
• add responder policy <responder_policy_name> sys.check_limit(“<limit_identifier_for_application>”) RESET
• add responder policylabel <responder_policy_label_name>
• bind responder policylabel <responder_policy_label_name> <responder_policy_name><priority> END

* Replace RESET action to DROP/create an action you want to perform once the requests go beyond the threshold.

Rate Limit Per Client

For a typical e-commerce website, assume there are various clients such as C1, C2, C3, etc., and the requests per second (RPS) from a single client is 300. Here, a rate limit policy makes sense if it is configured per client IP.

In scenarios where all the client requests pass through a NAT device before entering your Citrix ADC, all the clients will have the same IP and the policy won’t hold true just for a specific client. Instead it will be based on all the client IPs.

So if the threshold is 1,000 and the time slice is 10 seconds, 1,000 requests/10 seconds to any URL from a single client are allowed. Request No. 1,001 from the same client would be reset or dropped. This holds true for all the client IPs if a NAT device sits in front of the Citrix ADC.

So, to configure rate limiting feature based on client IPs, follow the CLI commands below and fill in the appropriate values where required:

• add stream selector <perclient_stream_selector_name> client.ip.src
• add ns limitIdentifier <perclient_limit_identifier> -threshold 1000 -timeSlice 10 -selectorName <perclient_stream_selector_name>
• add responder policy <responder_policy_name> sys.check_limit(“<perclient_limit_identifier>”) RESET
• add responder policylabel <policy_label_name>
• bind responder policylabel <policy_label_name><responder_policy_name> <priority> END

* Replace RESET action to DROP/create an action you want to perform once the requests go beyond the threshold.

Rate Limit Based on Header

Rate limiting based on header serves to monitor the rate of traffic associated with the header values. Sites that use HTTP form authentication methods (specifically crafted HTTP post that has username and password field names with variables) or data presented in custom HTTP headers (e.g. actual source IP of the client) are highly vulnerable.

So, rate limiting based on the data presented in the request headers helps you to uniquely identify a client, ensuring only a very specific set of HTTP requests are allowed by the client. Reliability of the network and the resources that the appliance manages are ensured.

For each incoming connection/entity on which rate limiting is to be enacted you can use a specific header or a combination of unique identifiers.

For example, if the threshold of incoming packets is 1,000 and the time slice is 10 seconds, 1,000 requests in 10 seconds to any URL from any client that has a certain header value for a given header name are allowed. Request No. 1,001 from any client to any URL with the same header value for the given header name would be reset/dropped.

Header name-value patterns other than the one where the rate limiting policy is applicable will go through without any hiccups.

So, to configure rate limiting feature based on header, follow the below CLI commands and fill in the appropriate values wherever required:

• add stream selector <stream_selector_based_header> HTTP.REQ.HEADER(“<header_name>”)

For e.g add stream selector new_stream_selector “HTTP.REQ.HEADER(\”True-Client-IP\”).AFTER_REGEX(re/(^)/)”

• add ns limitIdentifier<limitIdentifier_header> -threshold 1000 -timeSlice 10 -mode <mode> – selectorName <stream_selector_based_header>
• add responder policy <responder_policy_name> HTTP.REQ.HEADER(“<header_name>”).exists&&sys.check_limit(“<limitidentifier_header>”) RESET
• add responder policylabel <policy_label_name>
• bind responder policylabel <policy_label_name><responder_policy_name> <priority> END

Please note, the header name should match.

* Replace RESET action to DROP/create an action you want to perform once the requests go beyond the threshold.

Rate Limit Based on Cookies

Rate limiting based on cookies mean ADC will drop the connection if the threshold of connections coming from a unique cookie ID is breached. Here, we rate limit the request based on a specific cookie value for a given cookie name.

In this example, if the threshold is 1,000 and the time slice is 10 seconds, 1,000 requests per 10 seconds to any URL from any client with a certain cookie value for the given cookie are allowed. Packet No. 1,001 from any client to any URL with the same cookie value for the given cookie name would be reset/blocked. For all requests with the given cookie name, the rate limit is applied. Any number of requests from any client to any URL without this cookie name would be allowed.

So, to configure rate limiting feature based on cookies, follow the CLI commands below and fill in the appropriate values where required:

• add stream selector <cookie_stream_selector> HTTP.REQ.COOKIE.VALUE(“<cookie_name>”)
• add ns limitIdentifier<cookie_limitIdentifier> -threshold 1000 -timeSlice 10 -mode <mode> – selectorName <cookie_stream_selector>
• add responder policy <responder_policy_name> HTTP.REQ.COOKIE.contains(“<cookie_name>”)&&sys.check_limit(“<cookie_limitidentifier>”) RESET
• add responder policylabel <policy_label_name>
• bind responder policylabel <policy_label_name><responder-policy-name> <priority> END

Please note, the cookie name should match.

* Replace RESET action to DROP/create an action you want to perform once the requests go beyond the threshold. 

Rate Limit Based on Heavy URLs

Some URLs may consume considerable server resources per request or because of complex back-end server processing, causing high latency in responses. These URLs might not be heavy all the time, but this slowness typically happens when malicious users query a database or submit complex queries, resulting in high latency that eats up resources.

Citrix ADC’s rate limiting based on heavy URLs puts thresholds on URLs in terms of latency, protecting web apps and differentiating DoS attackers from legitimate app users.

For example, if the threshold is 1,000 and time slice is 10 seconds, 1,000 requests per 10 seconds to a single URL from any client are allowed. Request No. 1,001 to the same URL would be reset/dropped. The rate limit is applicable for all the URLs in the app and blocks attacks causing high latency.

So, to configure rate limiting feature based on Heavy URL, follow the CLI commands below and fill in the appropriate values where required.

• add stream selector <heavyurl_stream_selector_name> HTTP.REQ.URL.PATH
• add ns limitIdentifier <heavyurl_limitidentifier_name> -threshold 1000 -timeSlice 10 -selectorName <stream_selector_name>
• add responder policy <responder_policy_name> sys.check_limit(“<heavyurl_limitidentifier_name>”) RESET
• add responder policylabel <policy_label_name>
• bind responder policylabel <policy_label_name><responder_policy_name> <priority> END

* Replace RESET action to DROP/create an action you want to perform once the requests go beyond the threshold.

Conclusion

Citrix ADC provides powerful capabilities that protect your apps by limiting the number of requests that come into your server. With Citrix ADC’s rate limiting functionalities, you can quickly configure thresholds, define responses, and gain valuable insights into specific URLs of websites, apps, or API endpoints. This will help to ensure high availability of resources to your clients and improve the reliability of your network and resources.

For more information, check out our rate limiting resources in Citrix Docs. If you want to track whether your application’s peak usage is trending above the configured rate limits, learn how in our Citrix ADM service peak and lean usage analytics documentation. And you can also get more information in our technical documentation on configuring the responder feature to display user-specific messages, implementing rate limiting using the responder feature, and limiting bandwidth using rate limiting.