Applies To:

Show Versions Show Versions

Manual Chapter: Mitigating Application-Layer Denial of Service and Brute Force Attacks
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

A denial-of-service attack (DoS attack) is an attempt to make a computer resource unavailable to its intended users. The DoS attack generally consists of the concerted, malevolent efforts of a person or persons to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely. Perpetrators of DoS attacks typically target sites or services, such as banks, credit card payment gateways, and even root name servers, that are hosted on high-profile web servers.
One common method of attack involves saturating the target (victim) machine with external communications requests, so that the target system cannot respond to legitimate traffic, or responds so slowly as to be rendered effectively unavailable. In general terms, DoS attacks are implemented by forcing the targeted computer to reset, or by consuming its resources so that it can no longer provide its intended service, or by obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.
Denial-of-service attacks are also known as HTTP-GET attacks or page flood attacks. The attacks can be initiated either from a single user (single IP address) or from thousands of computers (distributed DoS attack), which overwhelms the target system. A page flood attack (or HTTP flood attack) resembles the patterns of normal Web surfing, making it harder for automated tools to differentiate between legitimate Web traffic and an attempted attack.
To mitigate DoS attacks, Application Security Manager applies denial-of-service detection to all traffic.
You can configure the Application Security Manager to monitor latency of Layer 7 (application layer) traffic to detect the spikes and anomalies in the typical traffic pattern. The spikes and anomalies may indicate an attempted attack. The system rejects suspicious traffic based on your configuration, which includes detection criteria and suspicious behavior criteria.
Detection Criteria
These settings determine how your system determines an attack. The minimum latency threshold and either of the other two latency values must be reached before the system mitigates a potential attack.
Suspicious Criteria
These settings specify thresholds for transactions per second (TPS) for typical traffic. If current traffic through the system reaches or exceeds the specified thresholds, then the system starts mitigating what may be the start of a DoS attack. The system thwarts the probable attack by limiting the TPS to that of the history interval (which is based on typical traffic). The system does not return a blocking response page.
1.
On the Main tab of the Application Security navigation pane, click Anomaly Detection.
The DoS Attack Prevention screen opens.
3.
In the DoS Configuration area, for the Operation Mode setting, select the mode for DoS detection and mitigation.
Off
Select this mode when you do not want the system to check for DoS attacks. This is the default setting.
Transparent
Select this mode if you want the system to issue reporting data. In this mode, when the system detects an attack, the Security Enforcer logs the attack data, but does not prevent access to the application by the offending client.
Blocking
Select this mode if you want the system to drop the connection from the attacking IP address or the attacked URLs.
4.
In the DoS Configuration area, for the Detection Criteria settings, type values for latency and threshold.
Latency increased by
Specifies that the system considers traffic to be an attack if the ratio of the latency-detection-interval to the latency-history-interval for one URL is greater than this value.
Latency reached
Specifies that the system considers traffic to be an attack if the latency detection interval for a specific URL is greater than this value.
Minimum Latency Threshold for detection
Specifies that the system considers traffic to be an attack if the detection interval for a specific URL is equal to or greater than this value and at least one of the Latency values is reached. If the detection interval is lower than this value, the system does not consider this traffic to be an attack, even if one of the Latency values is reached.
5.
In the DoS Configuration area, for the Suspicious Criteria setting, type values for latency and request rates.
TPS increased by
Specifies that the system considers an IP address to be either an attacker or a URL under attack (suspicious), if the ratio between the transaction-rate-detection interval and the transaction-rate-history interval for one IP address or URL is greater than this value.
TPS (per IP address) reached
Specifies that the system considers an IP address to be suspicious if the number of transactions (requests) sent per second from an IP address is equal to or greater than this value.
TPS (per URL) reached
Specifies that the system suspects a URL to be under attack if the number of transactions (requests) sent per second for the URL is equal to or greater than this number. The default setting is 1000 transactions per second.
6.
For the Prevention Policy setting, select how the system mitigates an attack. The system applies the enabled mitigation techniques in the order listed.
Client-Side Integrity Defense
Specifies, when checked, that the system determines whether the client is a legal browser or an illegal script by sending a JavaScript response to suspicious IP addresses, and waiting for a response. Legal browsers are able to respond, whereas illegal scripts cannot.
Source IP-Based Rate Limiting
Specifies, when checked, that when the system detects a suspicious IP address, the system drops requests from the suspicious IP address to the URL. The system stops dropping requests from the IP address when the IP addresss detection interval matches but does not exceed its history interval.
URL-Based Rate Limiting
Specifies, when checked, that when the system detects a URL under attack, the system limits the rate of all logon requests for the URL according to the URLs history interval.
7.
For the Prevention Duration setting, specify the length of time for which the system mitigates DoS attacks.
Unlimited
Specifies that after the system detects and stops a DoS attack, it performs attack prevention until it detects the end of the attack.
Maximum
Specifies that after the system detects and stops a DoS attack, it performs attack prevention either for the time configured here (even if the system detects that the attack continues), or until the system detects the end of the attack, whichever is earlier. Type a value, in seconds, in the box.
Note: You must configure the Prevention Duration setting before you save the DoS configuration.
8.
Click Save to save the detection and prevention criteria.
9.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Brute force attacks are attempts to break in to secured areas of a web application by trying exhaustive, systematic permutations of code or user name/password combinations to discover legitimate authentication credentials. Malicious users send high volumes of these combinations, often scripted, to get past security mechanisms.
In this automated scenario, it is possible for one malicious user to make thousands of logon attempts per minute. You can configure the Application Security Manager to detect, report on, and prevent Layer 7 brute force attack attempts, based on your criteria.
In Application Security Manager, brute force attack mitigation is a multifaceted configuration. You configure the logon URL to be protected, the mitigation methods, and the access validation criteria for logon responses. With this configuration, the system can monitor traffic to detect excessive failures to authenticate, monitor suspicious IP addresses (those that are generating a high volume of logon attempts), and detect other anomalies in the typical traffic pattern for the logon URL.
1.
On the Main tab of the Application Security navigation pane, click Anomaly Detection.
The DoS Attack Prevention screen opens.
2.
On the menu bar, click Brute Force Attacks Prevention.
The Login URLs screen opens.
4.
Click the Create button.
The New Brute Force Protection Configuration screen opens.
5.
In the Brute Force Protection Configuration area, select and define the parameters for the Login URL setting.
The system automatically adds to the security policys list of URLs any logon URL (explicit or wildcard) that you specify on this screen.
6.
In the Brute Force Protection Configuration area, for the Authentication Type setting, select the method by which the application server validates user logon credentials.
HTML Form
Specifies that the code of the logon URL is written in the format of an HTML form.
HTTP Basic Authentication
Specifies that the web server uses HTTP basic authentication to authenticate users.
HTTP Digest Authentication
Specifies that the web server uses HTTP digest authentication to authenticate users.
NTLM
Specifies that the web server uses NT LAN Manager (NTLM) authentication to authenticate users.
7.
For the Username Parameter Name setting, type the user name parameter written in the code of the HTML form. When the system detects this parameter with the password parameter, the system recognizes the request as a logon attempt. (This setting applies only to the HTML Form authentication type.)
8.
For the Password Parameter Name setting, type the password parameter written in the code of the HTML form. When the system detects this parameter with the user name parameter, the system recognizes the request as a logon attempt. (This setting applies only to the HTML Form authentication type.)
Once you have configured the logon URL to be protected, you can set up the mitigation methods. The Application Security Manager provides two types of mitigation methods for brute force attacks: session-based and dynamic.
Session-based mitigation
This mitigation method counts the number of failed logon attempts that occur during the same session for an IP address. For this mitigation method, you can configure a blocking policy. When the system detects a brute force attack, the attack triggers the Brute force attack detected violation, and the system applies the blocking policy, which may include sending blocking response page to the offending client. (For more information on the blocking policy, see Configuring the blocking policy.)
Dynamic mitigation
This mitigation method detects and mitigates brute force attacks based on statistical analysis of the traffic. Similar to DoS attack mitigation, the system initiates attack mitigation when the current traffic volume is significantly higher than the typical traffic volume. For this mitigation method, the system simply rejects the offending traffic, and does not send blocking response pages.
1.
Above the Session-based Brute Force Protection area, click the Blocking Settings link to open the Blocking Policy screen. On this screen, you can configure the blocking actions that the system takes when it detects excessive logon attempts from a client.
Note: See Configuring the blocking policy, for more information.
Login Attempts From The Same Client
Specifies how many times a user can attempt to log on before the system blocks the request. The system responds with the blocking response page.
Re-enable Login After
Specifies, in seconds, how long the user must wait after the system sends the blocking response page before successfully logging on.
1.
In the Dynamic Brute Force Protection area, for the Operation Mode setting, select how the system reacts when it detects an attack.
Off
Select this mode when you do not want the system monitor traffic to detect brute force attacks.
Transparent
Select this mode if you want the system to issue reporting data. In this mode, when the system detects an attack, the Security Enforcer logs the attack data, but does not drop offending requests. This is the default setting.
Blocking
Select this mode if you want the system to drop the offending requests when the system detects an attack, in addition to displaying the attack data on the Brute Force Attacks screen.
2.
For the Detection Criteria setting, specify the criteria under which the system considers logon attempts to be an attack. First, the Minimum Failed Login Attempts value must be reached, and then either the Failed Logins Attempts increased by percent or the Failed Login Attempts Rate reached number must be attained.
Failed Logins Attempts increased by
Specifies that the system considers logon attempts to be an attack if, for all IP addresses tracked, the ratio between the detection interval and the history interval is greater than this number.
Failed Login Attempts Rate reached
Specifies that the system considers logon attempts to be an attack if, for all IP addresses tracked, the logon rate reaches this number.
Minimum Failed Login Attempts
Specifies that the system considers logon attempts to be an attack if, for all IP addresses tracked, the number of logon attempts is equal to, or greater than, this number. This setting prevents attack mitigation on typical traffic volumes.
3.
For the Suspicious Criteria (per IP address) setting, specify how the system identifies traffic that may represent an attempted attack.
Failed Login Attempts increased by
Specifies that the system considers logon attempts from an individual IP address to be an attack if the ratio between the detection interval and the history interval is greater than this number.
Failed Login Attempts Rate reached
Specifies that the system considers an individual IP address to be suspicious if the number of logon attempts per second from an IP address is equal to or greater than this number.
4.
For the Prevention Policy setting, select how the system mitigates an attack. The system applies the enabled mitigation techniques in the order listed.
Client-Side Integrity Defense
Specifies, when checked, that the system determines whether the client is a legal browser or an illegal script, by sending a JavaScript response to suspicious IP addresses and waiting for a response. Legal browsers are able to respond, whereas illegal scripts cannot.
Source IP-Based Rate Limiting
Specifies, when checked, that when the system detects a suspicious IP address, the system drops requests from the suspicious IP address to the URL. The system stops dropping requests from the IP address when the IP addresss detection interval matches but does not exceed its history interval.
URL-Based Rate Limiting
Specifies, when checked, that when the system detects a URL under attack, the system limits the rate of all logon requests for the URL according to the URLs history interval.
5.
For the Prevention Duration setting, specify the length of time for which the system mitigates brute force attacks.
Unlimited
Specifies that after the system detects and mitigates a brute force attack, it performs attack prevention until it detects the end of the attack.
Maximum
Specifies that after the system detects and mitigates a brute force attack, it performs attack prevention either for the time configured here (even if the system detects that the attack continues), or until the system detects the end of the attack, whichever is earlier. Type a value, in seconds, in the box.
The last task in configuring brute force attack protection is to configure access validation criteria for the target logon URL.
1.
In the Access Validation area, define at least one validation criterion for responses to requests for the target logon URL. The validation criteria are:
A string that should appear in the response
A string that must appear in the response to allow the user to access the logon URL; for example, Successful Login.
A string that should NOT appear in the response
A string that, when it appears in the response, prohibits user access to the logon URL; for example, Authentication failed.
Expected HTTP response status code
An HTTP response code that the server must return to the user to allow access to the logon URL; for example, 200.
Expected validation header name and value (for example, Location header)
A header name and value that the response to the logon URL must match to permit access to it.
Expected validation domain cookie name
A defined domain cookie name that the response to the logon URL must include to permit user access to it.
Expected parameter name (added to URI links in the response)
A parameter that must exist in the logon URLs HTML body to allow access to it.
2.
Click the Save button.
The screen refreshes, and you see your protected logon URL in the list.
3.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)