Apache HTTPD Security Configurations v8.0

Edit this page

On a Windows system, Apache HTTPD is named PEM HTTPD, and the Apache httpd configuration file (pme.conf) is located in the <Apache_Installation_Path>/conf/addons directory. The ssl configuration file (httpd-ssl-pem.conf) is located in the <Apache_Installation_Path>/conf/addons directory.

On a Linux system, the apache httpd configuration file (edb-pem.conf) is located in the <Apache_Installation_Path>/conf.d directory and the SSL configuration file (edb-ssl-pem.conf) is located in the <Apache_Installation_Path>/conf.d directory.

Disable SSLv2 and SSLv3

You should disable SSL versions SSLv2, SSLv3, TLS 1, and TLS 1.1 as these versions are the most vulnerable and are affected by cryptographic concerns.

To disable the versions, please add the following command to apache httpd configuration file:

SSLProtocol -ALL +TLSv1.2

You need to restart the Web Server to apply the changes to the configuration file.

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

SSLProtocol -All TLSv1.2

SSLProxyProtocol -All TLSv1.2

Secure httpd with SSL Certificates

EDB recommends having an additional layer of SSL security for the web application.

By default, during PEM installation, PEM will generate and use self-signed certificates for Apache/HTTPD server. If you want to use your own SSL certificate for PEM, you must update the Apache configuration file.

On a Linux system, you need to open the Apache httpd configuration file (edb-ssl-pem.conf) in a text editor as 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.

There are two SSL Directives within the PEM VirtualHost section which you need to update:

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

For example, update:

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 Postgres Enterprise Manager. Follow the link shown below for the steps:

https://www.enterprisedb.com/postgres-tutorials/how-replacing-httpd-self-signed-ssl-certificates-trusted-ca-signed-certificates

Disable Web Server Information Exposure

EDB recommends disabling all web server signatures as part of web server security. The web server will expose a software signature; to disable the signature, add the following parameters to the Apache httpd configuration file. By default, PEM disables exposure of the information by adding the below parameters to the Apache httpd configuration file:

ServerTokens Prod

ServerSignature Off

The ServerTokens directive controls the server response header field, which is returned to the client. We recommend hiding 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 display of such information, we recommend disabling this directive in the Apache httpd configuration file.

You need to restart the web server to apply any changes to the Apache httpd configuration file.

Disable Directory Listing

The directory listing can allow an attacker to view complete directory contents. By default, the web server enables this option, and an attacker can discover and view any file. This listing could 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, you should disable the directory listing by setting the Options directive in the Apache httpd configuration file. By default, PEM disables the directory listing by setting the option below in the web server configuration file:

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

You need to restart the web server to apply the changes made to the configuration file.

Restrict the Access to a Network or IP Address

Apache provides access control based on the client hostname or IP address. To view the application by specific IP address or network, a user can modify the Apache configuration file as shown below to provide your network address within the Allow directive:

<Directory /application/hostname>

Options None

AllowOverride None

Order deny,allow

Deny from all

Allow from 192.168.0.0/24

</Directory>

PEM uses the ALLOWED_HOSTS configuration parameter in the application configuration file to provide the allowed hosts’ list of IP addresses. The application configuration config_local.py file is located in <PEM_INSTALLATION_PATH>/web.

By default, PEM allows all the hosts to connect with the application.

For example:

You can set the range of IP addresses in the configuration file as below:

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 as below:

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 as below:

ALLOWED_HOSTS = ['127.0.0.1', '192.168.0.1']

You need to restart the web server to apply the changes to the application configuration file.

Cross-site Tracing

There are two HTTP methods to debug the web server connections - TRACE and TRACK. When an HTTP TRACE request is sent to a web server that supports it, that server will respond, echoing the data passed to it, including any HTTP headers. We recommend disabling these methods within 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 does add the following lines to the Apache httpd configuration file:

RewriteEngine on

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)

RewriteRule .\* - [F]

Run Web Server from a Non-privileged User Account

Running the Apache web server as a root user creates a security issue. We always recommend running the web server as a unique non-privileged user. This helps to secure other services running in the event of any security breaches.

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

On Linux, the Apache web server starts as the root user, but the daemon processes which PEM application runs as pem user. On Windows, the WSGIDaemonProcess directive and its features are not available. PEM HTTPD is installed as a service during the installation, and the user needs to be a member of the Administrators group for the service installation to succeed.

By default the Apache services are registered to run as the system user (the LocalSystem account).

Customize Security HTTP Headers in PEM WebServer

PEM contains its own configuration file to fix the following security issues. We recommend overriding the configuration only of config_local.py and not of config.py. The config_local.py is not present on the systems in most of the cases; hence users need to create it to override the application-level configurations. Please note that during a PEM upgrade, config_local.py will not be overwritten, but changes in config.py and config_distro.py will be overridden. Users need to remove config_local.py after uninstalling the PEM.

By default, config_local.py is located 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 may be able to use this input to inject harmful payloads that manipulate server-side behavior. The web applications typically don't know what domain they are deployed on unless specified in a configuration file during setup. When they need to know the current domain, for example, they may 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 & SQL injections.

X-Frame-Options

X-Frame-Options can be used to indicate if a browser should be allowed to render a page in an <iframe> tag. It was designed specifically to protect against clickjacking. PEM has a host validation X_FRAME_OPTIONS option to prevent such kind of 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 and provides a broader range of protection than the X-Frame-Options header (which it replaces). It is designed in such a way that website authors can whitelist individual domains from which resources (like scripts, stylesheets, and fonts) can be loaded, and also domains that are permitted to embed a page.

PEM has a host validation CONTENT_SECURITY_POLICY option to prevent such kinds of 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 response header (often abbreviated as HSTS) allows a web site or web application to tell browsers that it should only be accessed using HTTPS instead of HTTP. This option allows you to prevent a man-in-the-middle attack. The default is:

STRICT_TRANSPORT_SECURITY = "max-age=31536000;includeSubDomains"

Note

Adding this parameter may cause problems if config is changed. Hence it is recommended to add this only after PEM installation is complete and tested.

X-Content-Type-Options

The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in Content-Type headers should not be changed and followed. This is a way to opt out of MIME type sniffing, or, in other words, 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 script into web pages viewed by other users. The HTTP X-XSS-Protection response to the header is a feature of Internet Explorer, Chrome, and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline') 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, you need to add the following options to the Apache configuration file:

<IfModule mod_headers.c>

Header set X-XSS-Protection "1; mode=block"

</IfModule>

A web server restart is required for configuration file changes to be applied.

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.

This changes requires an Apache service restart in order to take effect

For more detailed information on config.py file you can see PEM Online Help.

Cookies are small packets of data that a server can send to your browser to store configuration data. The browser automatically sends them along with all requests to the same server, so it’s important to know how to secure cookies. There are multiple configuration options provided by PEM to make cookies secure which you can refer to in config.py but the three that follow are most important.

  1. SESSION_COOKIE_SECURE - Setting the secure flag prevents the cookie from ever being sent over an unencrypted connection. It basically tells the browser to never add the cookie to any request to the server that does not use an encrypted channel. The browser will only add cookies to connections such as HTTPS. The default is:

    SESSION_COOKIE_SECURE = True

  2. SESSION_COOKIE_HTTPONLY - By default the content of cookies can be read via JavaScript. The HTTPOnly flag prevents scripts from reading the cookie. As the name HTTPOnly implies, the browser will only use the cookie in HTTP(S) requests. This prevents hackers from using XSS vulnerabilities to learn the contents of the cookie. For example, for the sessionId cookie it is never necessary to read the cookie with a client-side script, so for sessionId cookies, you can always set the HTTPOnly flag. The default is:

    SESSION_COOKIE_HTTPONLY = True

  3. ENHANCED_COOKIE_PROTECTION - When you set this option to True then a token will be generated according to the IP address and user agent. In all subsequent requests, the token will be recalculated and checked against the one computed for the first request. If the session cookie is stolen and the attacker tries to use it from another location, the generated token will be different, and in that case, the extension will clear the session and block the request. The default is:

    ENHANCED_COOKIE_PROTECTION = True

    Note

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

    This changes requires an Apache service restart in order to take effect.

    For more detailed information on config.py file you can see PEM Online Help.