Web Server Security Recommendations

IIS Web Server

See the IIS documentation for information on enabling SSL for all interactions with the web server.

Note: SSL should be enabled for the entire IIS Web server under which you installed the PPM applications.

To disable weak ciphers on IIS, refer to Microsoft support documentation.

Apache web server

See the Apache HTTP Server documentation for information on enabling SSL for all interactions with the web server and on enforcing strong security.

Recommendations to protect against slow HTTP attacks

Slow HTTP attacks are denial-of-service (DoS) attacks in which the attacker sends HTTP requests in pieces slowly, one at a time to a web server. Here are the recommendations for the Apache web server to protect it against slow HTTP attacks.

Use the <Limit> and <LimitExcept> directives to drop requests with methods not supported by the URL alone won�t help, because Apache waits for the entire request to complete before applying these directives. Therefore, use these parameters in conjunction with the LimitRequestFields, LimitRequestFieldSize, LimitRequestBody, LimitRequestLine, LimitXMLRequestBody directives as appropriate. For example, it is unlikely that your web app requires an 8190 byte header, or an unlimited body size, or 100 headers per request, as most default configurations have.
Set reasonable TimeOut and KeepAliveTimeOut directive values. The default value of 300 seconds for TimeOut is overkill for most situations.
Increase the default value of ListenBackLog, which is helpful when the server can�t accept connections fast enough.
Increase the MaxRequestWorkers directive to allow the server to handle the maximum number of simultaneous connections.
Adjust the AcceptFilter directive, which is supported on FreeBSD and Linux, and enables operating system specific optimizations for a listening socket by protocol type. For example, the httpready Accept Filter buffers entire HTTP requests at the kernel level.

NGINX web server

If your PPM sever is integrated with the NGINX web server, configure the following in NGINX to enable NGINX to accept headers with underscores:

In the server block of the NGINX configuration, add the following parameter:
Copy code
```
underscores_in_headers on
```
Validate and reload the configuration by running the following command:
Copy code
```
1
2
3
nginx -t
 
service nginx reload
```

Enable CORS filter

Cross-Origin Resource Sharing (CROS) filter is an implementation of W3C's CORS specification, which is a mechanism that enables cross-origin requests.

The filter works by adding required Access-Control-* headers to HttpServletResponse object. The filter also protects against HTTP response splitting. If request is invalid, or is not permitted, then request is rejected with HTTP status code 403 (Forbidden). A flowchart that demonstrates request processing by this filter is available.

Use the following parameters to enable CORS filter:

ENABLE_CORS_FILTER: enable CORS filter.
ACCESS_CONTROL_ALLOW_ORIGIN: specify the permitted domains for making requests from the webpage. Separate multiple values with commas.Do not use * due to Tomcat's parameter restrictions.