Denial of Service (DoS) is the act of performing an attack, which prevents the system from providing services to legitimate users.

All network servers can be subject to DoS attacks that attempt to prevent responses to clients by tying up the resources of the server. It is not possible to prevent such attacks entirely, but you can mitigate the problems that they create.

Often the best anti-DoS tool can be a firewall or other operating-system configurations. For instance, you can configure almost all firewalls to limit the number of simultaneous connections from a single IP address or network, thereby preventing more than a few simple attacks.

Table 4-1 provides the list of directives that help tune Oracle HTTP Server to improve its performance. In addition, these directives enable server administrators to exercise greater control over abnormal client requests and thereby protect against potential DoS attacks. Tuning these directives can affect some of the applications' performance. Appropriate testing needs to be done to ensure proper working. The default value provided for each directive is acceptable in most cases.

For more information about performance tuning, see Tuning Oracle HTTP Server in Tuning Performance.

For more information about the directives, see Apache HTTP Server documentation.

Slow HTTP POST Denial of Service (DoS) attack is an application-level DoS attack that sends slow traffic to the server and consumes server resources by maintaining open connections for an extended period of time.

The slow HTTP POST DoS attacks, unlike bandwidth-consumption DoS attacks, does not require large amount of traffic to be sent to the server. It only requires that the client is able to maintain open connections for several minutes. If the server maintains too many open connections, then it may not be able to respond to new, legitimate connections.

The attack holds server connections open by sending crafted HTTP POST headers that contain content-length headers with large values, to inform the web server how much of data to expect. After the HTTP POST headers are fully sent, the HTTP POST message body is sent at slow speeds to prolong the completion of the connection and lock up server resources.

By waiting for the complete request body, the server helps the clients with slow or intermittent connections to complete requests, but exposes itself to abuse.

To address the slow HTTP attacks, Oracle recommends that you tune the RequestReadTimeout directive provided by mod_reqtimeout module. This directive specifies various timeouts for receiving the request headers and the request body from the client. If the client fails to send headers or body within the configured time, a 408 Request Timeout error is sent, thus preventing a denial of service attack.

To modify the RequestReadTimeout directive:

1. Open the httpd.conf file using the Advanced Server Configuration page of the Fusion Middleware Control application, or a text editor.

2. In the LoadModule section of the file, if mod_reqtimeout is not already configured, add the following line to load the mod_reqtimeout module:

   LoadModule reqtimeout_module "${PRODUCT_HOME}/modules/mod_reqtimeout.so"

3. Edit the following directive in the configuration:

   <IfModule reqtimeout_module>
     RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
    </IfModule>

The HTTP Host header attacks exploit vulnerable websites that handle the value of the Host header in an unsafe way. If the server implicitly trusts the Host header, and fails to validate or escape it properly, an attacker may be able to use this input to inject harmful payloads that manipulate the server-side behavior.

One such way an attack can occur is when an application uses the input coming from the Host or X-Forwarded-Host request headers as part of the response without proper validation. Information from these headers should not be trusted as it is just another client side value an attacker can tamper with, which can result in unintended behavior. This can be mitigated by adding the following directives in your httpd.conf file:

• RewriteCond %{HTTP_HOST} !^<your website>
• RewriteRule ^(.*)$ - [F,L]

The RewriteCond directive checks the Host header which is sent with the request and matches it to the second argument <your website> provided in the directive. The RewriteRule directive will be executed only if the RewriteCond directive is set. The RewriteRule directive takes three arguments:

• The first argument specifies the URL that you want to replace. The value ^(.*)$ replaces any URL that is present.
• The second argument specifies the URL that you want to replace the first URL with. The value - specifies that you do not want to replace the first URL with any other value.
• The third argument is for flags. The first flag F signifies Forbidden, where the user receives a 403 Forbidden status code on the request. The second flag L signifies Last, which means that this will be the last RewriteRule considered in the configuration. If you have specified many RewriteRules after the L flag, they will not be considered.

See the My Oracle Support (Doc ID 2356329.1) and Apache Module mod_rewrite.