Protection against DOS and DDOS

I previously discussed the concept of DOS and DDOS. This post describes the procedures to configure HTTP DoS protection on the Citrix Next Generation Firewall.

  • Enable HTTP DoS
  • Add an HTTP DoS policy
  • Add a service
  • Bind the monitor
  • Bind the service to the policy
    Note: For information about using the CLI to configure this feature, see the Command Reference Guide.

To enable HTTP DoS in the GUI Configuration Utility:

  1. In the left pane, expand System, and click Settings. The System Settings Overview page appears in the right pane.
  2. Click advanced features. The Configure Advanced Features dialog box appears.
  3. Select HTTP DoS Protection check box, click OK, and click Yes on the Enable/Disable Feature(s) dialog box.
  4. The status bar displays a message indicating that the selected feature is enabled.

To add an HTTP DoS policy

  1. In the left pane, expand Protection Features, and click HTTP DoS. The HTTP DoS page appears in the right pane.
  2. Click Add. The Create HTTP DoS Policy dialog box appears.
  3. Type a name for the policy in the Name text box, for example, dospol_1.
  4. Type a numeric value in the QDepth text box that denotes the queue size, for example, 200.
  5. Type a numeric value in the Client Detect Rate text box, for example, 1, and click OK.
    Note: The client detect rate value denotes the percentage of traffic to which the HTTP DoS policy is applied.
    The policy that you created appears in the right pane and the status bar displays a message indicating that the DoS policy is successfully configured.

To add a service

  1. In the left pane, expand Load Balancing, and click Services. The Services page appears in the right pane.
  2. Click Add. The Create Service dialog box appears.
  3. In the Service Name text box type a name, for example, HTTP_DoS_service1.
  4. In the Server text box type the IP address of the server that the service represents, for example,
  5. In the Protocol drop-down list box, select the protocol type, for example, HTTP.
  6. Type the port number in the Port text box, for example, 80. Ensure that Enable Service check box is selected.
  7. Select the Advanced tab, and select the Override Global check box.
  8. Type numeric values in the Max Clients text box and Client text box respectively, for example, 200 and 60.
  9. Click Create and click Close. The service you create appears in the list of services.

To bind a monitor and a policy to the service

  1. In the left pane, expand Load Balancing, and click Services. The Services page displays the list of services in the right pane.
  2. Select the service that you want to bind and click Open. The Configure Service dialog box appears.
  3. Select the Monitor tab, click tcp in the Monitors list, and click Add. The selected monitor tcp is added to the Configured frame.
  4. Select the Policies tab, click a policy from the Available Policies list, for example, dospol_1 that you created in the previous section, and click Add.
  5. The policy appears in the Configured Policies list.
  6. Click OK and click Close. A message in the status bar indicates that the service is configured.

In the previous procedure, if more than 200 clients are waiting in the system surge queue for the service HTTP_DoS_service1, the HTTP DoS protection function is triggered. The default rate of challenged JavaScript responses sent to the client is one percent of the server response rate. For example, if the server generates 100 responses per second, and there are 200 clients in the surge queue, the HTTP DoS protection feature picks one pending client request per second from the surge queue (1% of 100) and sends a challenge JavaScript response to the suspect client at the rate of one JavaScript per second.

If the client executes the received challenge JavaScript, generates the cookie, and re-sends the original HTTP request with the JavaScript-generated cookie, it proves that it is a legitimate browser-based client. The HTTP DoS Protection feature queues the HTTP requests of the client in its higher-priority legitimate client queue, so that it is served faster.

Tuning the Client Detection/JavaScript Challenge Response Rate

The default client detection/JavaScript challenge response rate of one percent is inadequate in many real attack scenarios, therefore, it needs to be tuned. For example, there are 500 responses/sec from the server, and the server is under attack with 10000 Gets/sec. If 1% of the server responses are sent as JavaScript challenges, responses are reduced to almost none: 5 client (500 *0.01) Javascript responses, for 10000 waiting client requests, approximately 0.05% of the real clients receive JavaScript challenge responses.

If the client detection/Javascript challenge response rate is very high (for example, 10%, generating 1000 challenge Javascript responses per second), it may saturate the upstream links or harm the upstream network devices. Citrix recommends that an administrator exercise care when choosing Client Detect Rate values.

If the configured triggering surge queue depth is, for example, 200, and the surge queue size is toggling between 199 and 200, the system toggles between the “attack” and “no-attack” scenario, which is not desirable.

To prevent the “attack” and “no attack” scenario from occurring, a window mechanism is provided. When the surge queue size reaches 200, and the “attack” scenario is detected, the surge queue size must fall for the system to enter

“noattack” mode. If the value of WINDOW_SIZE is set to 20, the surge queue size must fall under 180 before the system enters “no-attack” mode. During configuration, you must specify a value more than the WINDOW_SIZE for the QDepth parameter when adding a DoS policy or setting a DoS policy.

The triggering surge queue depth should be configured based on prior knowledge of the traffic characteristics.

Guidelines for HTTP DoS Protection Deployment

Citrix recommends you deploy the HTTP DoS protection feature in a tested and planned manner, and closely monitor after the initial deployment. Use the following information to fine-tune the deployment of HTTP DoS Protection:

  • The maximum number of concurrent connections supported by your
  • The average and normal values of the concurrent connections supported by
    your servers
  • The maximum output rate (responses/sec) that your server can generate.
  • The average traffic that your server handles.
  • The typical bandwidth of your network.
  • The maximum bandwidth available upstream.
  • The limits faced by the bandwidth, for example, external link, router and so on. The critical devices on the path that may suffer from a traffic surge.
  • Whether allowing a greater number of clients to connect is more important than protecting upstream network devices.
    Attack Characteristics
  • What is the rate of incoming fake requests that you have experienced in the past?
  • What types of requests have you received (complete posts, incomplete gets)?
  • Did previous attacks saturate your downstream links? If not, what was the bandwidth?
  • What types of source IP addresses and source ports did the HTTP requests have (e.g., IP addresses from one subnet, constant IP, ports increasing by one).
  • What types of attacks do you expect in future? What type have you seen in the past?
  • Any or all information that can help you tune DoS attack protection.

    Get the most powerful DDOS Protection here.

    It’s powerful!