Apache HTTPD security configurations v10

Suggest edits

On Windows, Apache HTTPD is named PEM HTTPD. The Apache HTTPD configuration file is pem.conf and the SSL configuration file is httpd-ssl-pem.conf. Both configuration files are in the <Apache_Installation_Path>/conf/addons directory.

On Linux, the Apache HTTPD configuration file is edb-pem.conf and the SSL configuration file is edb-ssl-pem.conf. Both configurations files are in the <Apache_Installation_Path>/conf.d directory.

Disable SSLv2 and SSLv3

Disable SSL versions SSLv2, SSLv3, TLS 1, and TLS 1.1. These versions are the most vulnerable and have cryptographic concerns.

To disable the versions, add the following command to the Apache HTTPD configuration file:

SSLProtocol -ALL +TLSv1.2

Restart the web server to apply the changes to the configuration file.

PEM adds the following lines to the SSL configuration file to allow for the use of TLS 1.2 as security:

SSLProtocol -All TLSv1.2
SSLProxyProtocol -All TLSv1.2

Secure HTTPD with SSL certificates

We recommend an additional layer of SSL security for the web application.

During PEM installation, PEM generates and uses self-signed certificates for the Apache/HTTPD server. If you want to use your own SSL certificate for PEM, you must update the Apache configuration file.

On Linux, you need to open the Apache HTTPD configuration file (edb-ssl-pem.conf) in a text editor and be a user with write permission on the file. You must also change the server name and file names in the configuration file to match your certificate files.

Update these two SSL directives in the PEM VirtualHost section:

  • SSLCertificateFile is your DigiCert certificate file (for example, your_domain_name.crt).
  • SSLCertificateKeyFile is the .key file generated when you created the CSR (for example, your_private.key).

For example, make the following updates:

SSLEngine on
SSLCertificateFile /path/to/your_domain_name.crt
SSLCertificateKeyFile /path/to/your_private.key

You can also replace the HTTPD self-signed SSL certificates with trusted CA-signed certificates in PEM. For instructions, see this Postgres tutorial.

Disable web server information exposure

We recommend that you disable all web server signatures as part of web server security. To disable the web server signature, add the following parameters to the Apache HTTPD configuration file. PEM disables exposure of the information by adding the parameters to the Apache HTTPD configuration file.

ServerTokens Prod
ServerSignature Off

The ServerTokens directive controls the server response header field, which returns to the client. We recommend that you hide the Apache server version by adding this parameter in the Apache HTTPD configuration file.

The ServerSignature directive includes a footer for server-produced documents. The footer contains information regarding the Apache configuration, like the Apache and operating system version. To limit the exposure of this information, we recommend that you disable the directive in the Apache HTTPD configuration file.

Restart the web server to apply any changes to the Apache HTTPD configuration file.

Disable directory listing

The directory listing allows an attacker to view the complete contents of the directory. By default, the web server enables this listing, allowing an attacker to discover and view any file. This listing might lead to the attacker reverse engineering an application to obtain the source code, analyze it for possible security flaws, and discover more information about an application.

To avoid this risk, disable the directory listing by setting the Options directive in the Apache HTTPD configuration file. PEM disables the directory listing by setting the following option in the web server configuration file:

<Directory /application/directory> Options -Indexes </Directory>

Restart the web server to apply the changes made to the configuration file.

Restrict the access to a network or IP address

Apache allows you to provide the client hostnames or IP addresses that can access the application. To give access to an IP address or network, enter the network address in the Allow directive.

<Directory /application/hostname>
Options None
AllowOverride None
Order deny,allow
Deny from all
Allow from 192.168.0.0/24
</Directory>

The ALLOWED_HOSTS configuration parameter in the application configuration file sets the allowed hosts by IP address. The application configuration file (config_local.py) is located in <PEM_INSTALLATION_PATH>/web.

PEM allows all the hosts to connect with the application.

For example:

# You can set the range of IP addresses in the configuration file:
ALLOWED_HOSTS = ['225.0.0.0/8', '226.0.0.0/7', '228.0.0.0/6']

#You can set the IP adresses to allow a host on a subnet level in the configuration file:
ALLOWED_HOSTS = ['192.0.2.0/28', '::192.0.2.0/124']

#You can set a specific individual host address (based on the IP address) in the configuration file:
ALLOWED_HOSTS = ['127.0.0.1', '192.168.0.1']

To apply the application configuration file changes, restart the web server.

Cross-site tracing

You can use two HTTP methods to debug the web server connections: TRACE and TRACK. When an HTTP TRACE request is sent to a supported web server, the server responds and echoes the data passed to it, including any HTTP headers. We recommend that you disable these methods in the Apache configuration.

To disable the TRACE method for all virtual hosts, add the following line to the Apache HTTPD configuration file:

TraceEnable off

To disable these methods for a specific virtual host, add the following lines for each virtual host in the Apache configuration file. PEM also adds the following lines to the Apache HTTPD configuration file:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)
RewriteRule .\* - [F]

Run web server from a nonprivileged user account

Running the Apache web service as a root user can create a security issue. We recommend that you run the web server as a unique nonprivileged user. Doing so helps to secure any other services running during a security breach.

PEM runs as a WSGI application. To delegate the WSGI applications that are running, create distinct daemon processes using the WSGIDaemonProcess directive.

On Linux, the Apache web server starts as the root user. Meanwhile, PEM runs the daemon processes as the pem user. On Windows, the WSGIDaemonProcess directive and features aren't available. During the installation, PEM HTTPD installs as a service. For this service installation to succeed, you must be a member of the Administrators group.

By default, the Apache services run as the system user (the LocalSystem account).

Customize security HTTP headers in PEM web server

PEM contains a separate configuration file to fix the following security issues. We recommend that you override the configuration only of config_local.py and not of config.py. The config_local.py file is present only on some systems. You must create it to override the application-level configurations. During a PEM upgrade, you can't overwrite config_local.py, but you can overwrite changes in config.py and config_distro.py. Remove config_local.py after uninstalling PEM.

By default, config_local.py is in /usr/edb/pem/web on Linux and at C:\ProgramFiles\edb\pem\server\share\web on Windows.

Host header injection attacks

HTTP host header attacks exploit vulnerable websites that handle the host header value in an unsafe way. If the server implicitly trusts the host header and fails to validate or escape it properly, an attacker can use this input to inject harmful payloads that manipulate server-side behavior. The web applications typically don't know the domain they are deployed on unless specified in a configuration file during setup. When they need to know the current domain, for example, they can resort to retrieving the domain from the host header to generate an absolute URL. The host header is a potential vector for exploiting a range of other vulnerabilities, most notably web cache poisoning and SQL injections.

X-Frame-Options

X-Frame-Options indicate whether a browser is allowed to render a page in an <iframe> tag. It specifically protects against clickjacking. PEM has a host validation X_FRAME_OPTIONS option to prevent these attacks, which you can configure in the config_local.py file. The default is:

X_FRAME_OPTIONS = "SAMEORIGIN"

Content-Security-Policy

Content-Security-Policy is part of the HTML5 standard. It provides a broader range of protection than the X-Frame-Options header, which it replaces. It is designed so that website authors can whitelist domains. The authors can load resources (like scripts, stylesheets, and fonts) from the whitelisted domains and also from domains that can embed a page.

PEM has a host validation CONTENT_SECURITY_POLICY option to prevent attacks, which you can configure in the config_local.py file. The default is:

CONTENT_SECURITY_POLICY = "default-src https: data: blob: 'unsafe-inline' ‘'unsafe-eval';"

Strict-Transport-Security

The Strict-Transport-Security (HSTS) response header can prevent a man-in-the-middle attack. When you enable the option, websites or web applications tell browsers that they accept only HTTPS and not HTTP. The default is:

STRICT_TRANSPORT_SECURITY = "max-age=31536000;includeSubDomains"
Note

Adding this parameter can cause problems if config is changed. Therefore, we recommend that you add it only after PEM installation is complete and tested.

X-Content-Type-Options

The X-Content-Type-Options response HTTP header is a marker. The server uses the marker to indicate that the MIME types advertised in Content-Type headers can't be changed and followed. The following is a way to opt out of MIME type sniffing, that is, to say that the MIME types are deliberately configured. The default is:

X_CONTENT_TYPE_OPTIONS = "nosniff"

X-XSS-Protection

Cross-site scripting (XSS) is one of the most common application layer vulnerabilities in the web servers. XSS enables attackers to inject client-side scripts into web pages that other users view. The HTTP X-XSS-Protection response to the header is a feature of Internet Explorer, Chrome, and Safari. It stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. These protections are unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline'). However, these protections can still provide protections for users of older web browsers that don't yet support CSP. The default is:

X_XSS_PROTECTION = "1; mode=block"

To avoid this, add the following options to the Apache configuration file:

<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>

To apply the configuration file changes, restart the web server.

By default, PEM sets X-XSS-Protection to "1; mode=block" in the application configuration file, which is located at /usr/edb/pem/web/config.py.

To apply the changes, restart the Apache service.

For detailed information on the config.py file, see Managing configuration settings.

Cookie security

Cookies are small packets of data that a server sends to your browser to store configuration data. The browser sends them and all other requests to the same server, so it’s important to know how to secure cookies. Multiple configuration options in config.py can make cookies secure. These are the three most important options:

  • SESSION_COOKIE_SECURE — The flag prevents cookies from sending over an unencrypted connection. The browser can't add the cookie to any request to a server without an encrypted channel. The browser can add cookies only to connections such as HTTPS. The default is:

    SESSION_COOKIE_SECURE = True

  • SESSION_COOKIE_HTTPONLY — By default, JavaScript can read the content of cookies. The HTTPOnly flag prevents scripts from reading the cookie. Instead, the browser uses the cookie only with HTTP or HTTPS requests. Hackers can't exploit XSS vulnerabilities to learn the contents of the cookie. For example, the sessionId cookie never requires that it be read with a client-side script. So, you can set the HTTPOnly flag for sessionId cookies. The default is:

    SESSION_COOKIE_HTTPONLY = True

  • ENHANCED_COOKIE_PROTECTION — When you set this option to True, then a token is generated according to the IP address and user agent. In all subsequent requests, the token recalculates and compares to the one computed for the first request. If the session cookie is stolen and the attacker uses it from another location, the generated token is different. In that case, the extension clears the session and blocks the request. The default is:

    ENHANCED_COOKIE_PROTECTION = True

    !!! Note This option can cause problems when the server deploys in dynamic IP address hosting environments, such as Kubernetes or behind load balancers. In such cases, set this option to False.

    To apply the changes, restart the Apache service.

    For detailed information on config.py file, see Managing Configuration Settings.

← Prev

Securing your deployment

↑ Up

Securing your deployment

Next →

PEM application security configurations