Adding a Service Protection Class
To add a service protection class, click Catalogs > Service Protection.
The Virtual Traffic Manager displays a list of existing service protection classes, and allows you to add a new service protection class by entering a name and clicking Create Class.
When you add a new service protection class, there are five main configuration groups.
Basic Settings
These settings enable and disable service protection and dictate in which mode the service protection class operates.
If you wish to bypass this service protection class temporarily, you can enable or disable service protection for the class. This is particularly useful if many virtual servers are configured to use the service protection class.
You can configure the log buffer time, which is the amount of time the Virtual Traffic Manager buffers logging in order to reduce disk writes (and reduce any knock-on problems if heavy logging results during a DoS attack). The Virtual Traffic Manager also includes a debug option, which causes verbose output to be logged.
ATTENTION The debug option can create heavy loads on your Virtual Traffic Managers, and should not be used in production systems.
The Virtual Traffic Manager also offers a test mode, whereby the decisions made by the Virtual Traffic Manager with this service protection class are logged, but not acted upon. This option is designed to help tune the parameters of the service protection class to suit your services, and should be used for a period of testing before switching on protection.
Simultaneous Connections
These settings specify limits on the number of connections that the Virtual Traffic Manager allows from individual IP addresses:
Setting | Description |
|---|---|
max_1_connections | The maximum number of simultaneous connections the Virtual Traffic Manager allows from each connecting IP address. Set to 0 to disable this limit. |
per_process_connection_count | Determine whether the Virtual Traffic Manager uses a per-process simultaneous connection count model (each Virtual Traffic Manager typically has several processes, one process per available CPU core). Click "Yes" to allow the connecting IP address to make up to max_1_connections connections to each process within the Virtual Traffic Manager. Click "No" to allow the connection IP address to make up to max_1_connections connections to the Virtual Traffic Manager as a whole. If per_process_connection_count is set to "Yes", the following additional limits apply: max_10_connections: The maximum number of simultaneous connections from the top 10 busiest connecting IP addresses combined. The top 10 clients typically represent the majority of the load on a particular virtual server if any form of DoS attack is in progress or other abusive connections are being made to the Virtual Traffic Manager. It is therefore desirable to limit this particular group of users while leaving other requests untouched. For normal use, Ivanti suggests a value between 1 and 10 times the max_1_connections limit. To remove the effect of this limit, set it to at least 10 times the max_1_connections limit. The Virtual Traffic Manager ignores this setting if per_process_connection_count is set to "No", or max_1_connections is 0, or min_connections is 0. min_connections: The entry threshold for the max_10_connections limit. The max_10_connections limit is not applied to connecting IP addresses with this many or fewer simultaneous connections. Set to 0 to disable both the max_1_connections and max_10_connections limits. The Virtual Traffic Manager ignores this setting if per_process_connection_count is set to "No". |
Connection Rate
ATTENTION Connection rate limiting is per process, and each process independently imposes the rate on the connections it is handling.
These settings allow you to limit the rate at which each connecting IP address might make new connections or requests:
Setting | Description |
|---|---|
max_connection_rate | The maximum number of connections that any individual IP address can make to the Virtual Traffic Manager during the interval specified in rate_timer. Set to 0 to disable the limit. In the case of HTTP, each individual request is counted as a connection, even if they are tunneled within a single Keepalive connection. |
rate_timer | The interval (in seconds) the Virtual Traffic Manager uses to determine how frequently max_connection_rate is assessed. For example, a value of 60 imposes a limit of max_connection_rate connections per minute. All connection attempts above this limit are rejected for the remainder of the rate_timer interval. |
For more fine grained connection rate control, use the Request Rate Shaping feature described in Request Rate Shaping.
Access Restrictions
The Allowed list allows you to specify allowed IP addresses or networks that are exempt from the normal service protection checks in this service protection class. In other words, IP addresses in this list are not subject to any of the limits set in the Simultaneous Connections and Connection Rate sections.
Use the Banned list to declare IP addresses or networks from which the Virtual Traffic Manager must always drop connections.
When checking a source IP, the subnets in both lists are evaluated using a longest-match first algorithm. In other words, the more specific subnet takes precedence. It is therefore possible to ban a more specific subnet contained within a less specific allowed one and vice versa. For example, allowing 192.168.0.0/16 and banning 192.168.128.0/24 allows requests from IP 192.168.0.137, but not from 192.168.128.137. If the same subnet is present in both the Allowed and the Banned list, requests from that subnet are allowed.
To add to either list, input the IP or network address in the appropriate box. Use one of the following formats:
- 192.0.2.0/255.255.255.0
- 192.0.2.0/24
- 192.0.2.1
- 192.0.2.
HTTP-Specific Settings
These settings provide extra checks which can be performed on HTTP traffic.
The Virtual Traffic Manager allows you to enforce compliance with RFC2396; this checks that the URL is properly formed according to accepted guidelines. Since standard Web browsers comply with RFC2396, this test will reject requests that include unusual or malicious data or formatting, while allowing legitimate requests to pass through.
The length of the HTTP body and any HTTP header can be restricted. This prevents a malicious attacker sending a very large or endless body or header. Web servers normally buffer incoming requests in progress in memory, and can therefore be vulnerable to a memory depletion attack. You can guard against this by preventing clients from sending large amounts of request data.
You can also specify a limit to the total size of all the HTTP headers. This prevents an attacker from constructing a very large request using a large number of HTTP headers.
You can limit the size of the URL requested, to prevent buffer overflow attacks and other attempts to use the URL as a vector for large amounts of data or worms.
After decoding, the Virtual Traffic Manager can reject HTTP headers that contain binary data. This is often an indicator of an attempted buffer-overrun attack, although some poorly written applications use binary data. If you suspect that your applications could be affected, you should first prove this feature using the test mode.
Finally, the Virtual Traffic Manager allows you to specify whether to reject requests silently if they fail one of the above tests, or to send HTTP error messages to the client that makes the request. Sending error messages incurs slightly higher overheads, which can be significant if a DoS attack is in progress.
If you associate this service protection class with a virtual server that does not handle HTTP traffic, then these settings will be ignored.
Service Protection Rule
This section displays the current rule, if any, which the service protection class is using. If you wish to change the rule, select the rule you wish to use from the drop-down menu. For more information on TrafficScript, please see TrafficScript Rules.
To commit your settings and create the service protection class, click Update.