Protecting Oracle HTTP Server Against Known Web Server Attacks

Securing Oracle HTTP Server Against DoS Attacks

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.

Table 4-1 Tuning Directives for Oracle HTTP Server

Directive	Default Value	Description
`TimeOut`	`60 seconds`	Server wait time before failing a request.
`RequestReadTimeout`	`header=5-40 seconds, MinRate=500 seconds` `body=10 seconds, MinRate=500 seconds`	Timeout for receiving request headers and request body from the client. See Protecting Oracle HTTP Server Against Slow HTTP Attacks.
`KeepAliveTimeout`	`5 milliseconds`	Amount of time the server waits for subsequent requests on a persistent connection. Setting this directive to a higher value may cause performance issues in servers that are heavily loaded. A higher timeout value may result in several server processes being occupied, waiting on connections with idle clients.
`LimitRequestBody`	`0`	Restricts the total size of the HTTP request body sent from the client. Configure this directive to limit resource consumption triggered by client input.
`LimitRequestFieldSize`	`8190 bytes`	Restricts the size of the HTTP request header allowed from the client. Configure this directive to limit resource consumption triggered by client input.
`LimitXMLRequestBody`	`1000000 bytes`	Limits the size of an XML-based request body. Configure this directive to limit the maximum size of an XML-based request body.
`AcceptFilter`	NA	Enables operating system specific optimizations for a listening socket. Using none as an argument will disable any accept filters for that protocol.
`MaxRequestWorkers`	`250`	Sets the limit on the number of simultaneous requests served. To increase the default value, you must also raise the `ServerLimit` directive.
`CGIDScriptTimeout`	NA	Limits the wait time for more output from the CGI program. By default, the value of `Timeout` directive is used. Configure the `CGIDScriptTimeout` directive to overwrite the default value. If you are using CGI applications, see CGIDScriptTimeout Directive in Administering Oracle HTTP Server.

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.

Protecting Oracle HTTP Server Against Slow HTTP Attacks

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:

Open the httpd.conf file using the Advanced Server Configuration page of the Fusion Middleware Control application, or a text editor.
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"

Edit the following directive in the configuration:

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

Note:

Tuning this directive can affect some of the applications' performance. Appropriate testing needs to be done to ensure proper working. See "Required Testing" in My Oracle Support document ID 2350321.1.

Protecting Oracle HTTP Server Against Host Header Attacks

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.

Note:

The RewriteCond and RewriteRules are not inherited. They have to be specified for each VirtualHost separately. If you don’t want to specify RewriteRule for every VirtualHost and want to keep the rules same throughout the configuration, you can make the scope of the above configuration global by adding the following lines in each of the VirtualHosts:

RewriteEngine On
RewriteOptions Inherit #this will inherit global configuration

Another way to achieve this is by specifying RewriteOptions in global context with the value InheritDown or InheritDownBefore. However, you must still add RewriteEngine On in the VirtualHosts.

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