Web Server Configuration

Overview

This document serves as a guideline to harden the web server configuration with regard to running SugarCRM. Note that this is a guideline and certain settings will depend on your specific environment and setup. This guideline focuses on Apache web server as this is SugarCRM's primary supported web server. However, the recommendations in this document apply to all web servers in general.

Advisory ID: sugarcrm-sr-2015-003
Revision: 1.1
Last updated: 2015-10-01 

SugarCRM .htaccess file

During installation, SugarCRM deploys an .htaccess file in SugarCRM's root folder. The content of this file may change during upgrades as well. The primary configuration directives managed by SugarCRM are focused around disabling direct access to certain directories and files. Secondly, the configuration contains specific URL rewrite rules which are required for SugarCRM.

Although this file can be used to ship most of the settings which are explained in this document to harden the web server, SugarCRM has chosen not to do so as most of them depend on the customer's setup which cannot be fully controlled by the SugarCRM application itself.

All directives which are managed by SugarCRM are placed between the following markers inside the .htaccess file:

    # BEGIN SUGARCRM RESTRICTIONS
RedirectMatch 403 .*\.log$
...
# END SUGARCRM RESTRICTIONS

Customers can add additional directives if need. Make sure to put those directives outside of the above-mentioned markers. SugarCRM can rebuild during upgrades all directives enclosed in the above markers.

Securing .htaccess

Apache allows admins to drop in .htaccess files in any given directory. When a request comes in, Apache will scan the directory recursively for any .htaccess file and apply its configuration directives. This ability is orchestrated by the AllowOverride directive which is enabled by default on most Apache configurations.

To disable this dynamic Apache configuration behavior, disable AllowOverride and make sure to copy paste the .htaccess file content as well.

    <Directory "/var/www/html">
    AllowOverride None
    # BEGIN SUGARCRM RESTRICTIONS
    RedirectMatch 403 .*\.log$
    ...
    # END SUGARCRM RESTRICTIONS
</Directory>

When choosing for this security measure, make sure to verify if any changes have happened in the .htaccess after an upgrade. Those changes need to be applied manually back in the Apache configuration to ensure SugarCRM functions properly. Disabling the .htaccess file support also has a positive impact on the performance as Apache will no longer need to scan for the presence of .htaccess files.

Although Apache does not allow to download .htaccess files, to tighten the security around .htaccess, even more, the following directives can be added:

    <Files ".ht*">
    Order deny,allow
    Deny from all
</Files>

Prevent version exposure

By default Apache web server exposes its version and OS details in most *nix distributions in both the HTTP response headers as well as on the default error pages. To prevent this behavior use the following configuration directives:

    ServerSignature Off
ServerTokens Prod

 The exposure of the PHP version can be disabled in your php.ini file. When exposed an X-Powered-By response header will be added containing the PHP version information.

    expose_php = Off

Another option is to unset the header explicitly in the Apache configuration:

    <IfModule mod_headers.c>
    Header unset X-Powered-By 
</IfModule>

Note that unsetting the Server header is not possible using this way. The web server will always respond with a Server header containing the string "Apache". If it is desired to remove this header as well, additional modules need to be used for this (i.e. mod_security can do this).

Directory listing and index page

Make sure to configure a default index page which should only be index.php for SugarCRM. This is mostly configured but worth checking. Additional SugarCRM does not require the directory browsing support and this is recommended to be disabled. This can be accomplished by removing Options Indexes and/or completely disable the mod_autoindex module.

Optionally additional Allow/Deny directives can be used to apply access lists to certain directories. It is not recommended to add additional authentication through Apache as SugarCRM already fully manages user authentication. The Allow/Deny directives can still be used to apply any IP access list if required by the customer.

The following example secures the root directory (default configuration), disable directory browsing and an additional IP access list is applied.

    DocumentRoot "/var/www/html"

<Directory />
    AllowOverride none
    Order allow,deny
    Deny from all
</Directory>

<Directory "/var/www/html">
    DirectoryIndex index.php
    Options -Indexes
    Order deny,allow
    Allow from 10.0.0.0/8
    Deny from all
</Directory>

Additional Options directives

SugarCRM does not rely on both CGI and SSI and it is recommended to disable this functionality explicitly. Optionally the FollowSymLinks options can also be disabled depending on your directory setup.

    <Directory "/var/www/html">
    Options -ExecCGI -Includes -FollowSymLinks
</Directory>

Web server permissions

Ensure your web server is configured to run as a dedicated non-privileged user. Certain *nix distributions use out of the box the user/group nobody. It is recommended to use a dedicated user/group instead.

    User wwwrun
Group www

Ensure the configured user/group have the proper file and directory permissions for SugarCRM. See the installation/upgrade guide for more detailed instructions regarding the required permissions.

Disable unnecessary loadable modules

Apache is pluggable by means of loadable modules. To minimize the chances of becoming a victim of an attack it is recommended to disable all loadable modules which are not needed. SugarCRM recommends the following base Apache modules:

• mod_authz_host
• mod_dir
• mod_expires
• mod_rewrite
• mod_headers
• mod_mime
• mod_alias

From an Apache perspective to disable a loadable module, it is sufficient to comment out the LoadModule directives. However certain *nix distribution has additional configuration scripts to manage the loaded Apache modules. Please refer to your *nix distribution for this.

Based on your setup additional Apache modules can be used. When using MPM prefork you will also need mod_php5 and when terminating secure HTTP connection on the web server directly also mod_ssl (see below).

HTTP methods

HTTP uses different methods (verbs) in requests. As per RFC-7231 for HTTP/1.1 different request methods are defined which serve the primary source of the request semantics. The following methods are used by SugarCRM:

For new REST API:

• GET
• POST
• PUT
• DELETE
• HEAD (*)
• OPTIONS (*)

Bootstrap, BWC access, old SOAP/REST API:

• GET
• POST

(*) Currently not in use, but may be implemented in the future.

The new REST API is accessed using the URL "/rest/vxx/…" where xxx represents the API version number. To harden the usage of the additional HTTP methods the following directives can be used for the new REST API endpoint while only allowing GET and POST on the legacy access.

    <Directory "/var/www/html">
    <LimitExcept GET POST>
        Order deny,allow
        Deny from all
    </LimitExcept>
</Directory>

<Location "/rest">
    <LimitExcept GET POST PUT DELETE>
        Order deny,allow
        Deny from all
    </LimitExcept>
</Location>

<Location "/api/rest.php">
    <LimitExcept GET POST PUT DELETE>
        Order deny,allow
        Deny from all
    </LimitExcept>
</Location>

Instead of using the Limit directive, an alternative is using mod_allowmethods which is available since Apache 2.4. However this module is flagged as experimental.

Secure HTTP traffic

SugarCRM requires the usage of HTTPS transport without any exception. Depending on your setup you can terminate the secure connection on a separate endpoint (load balancer, dedicated HTTPS termination point) or directly on the web server(s). You will also need a valid private key and X.509 certificate. In most cases, the customer needs to acquire an X.509 certificate through a public certification authority of their choice. For internal deployments, this may not be necessary when a local PKI environment is available.

When terminating the secure connection directly on the Apache web server, mod_ssl is required. A dedicated VirtualHost needs to be configured on port 443 (standard HTTPS port). The following is a basic SSL/TLS configuration as a reference. More details are covered in the next paragraphs.

    <VirtualHost 1.2.3.4:443>
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/example.com.crt
    SSLCertificateKeyFile /etc/pki/tls/certs/example.com.key
    SSLCertificateChainFile /etc/pki/tls/certs/example_bundle.crt
    ServerName crm.example.com
</VirtualHost>

Make sure to have your server name properly configured as it should match the X.509 certificate's CommonName (or one of the SNA's, subject alternative names). More information regarding the certificate requests including the certificate chain can be obtained from your certification authority.

Ensure to redirect all non-secure HTTP (port 80) traffic to the secure virtual host.

    <VirtualHost *:80>
    Redirect "/" "https://crm.example.com/"
</VirtualHost >

Cipher suite hardening

As per the publish date of this document, the usage of any version of SSL protocol, as well as TLSv1.0 and TLSv1.1 are recommended to be disabled. The current safe secure transport protocols are TLSv1.2 and TLSv1.3 with properly configured cipher suites.

For proper deployment of Diffie-Hellman (DH) key exchange algorithms the following guidelines apply:

• No longer use out-dated export cipher suites
• Ensure the usage of Elliptic Curve Diffie-Hellman (ECDHE) based algorithms
• Use of non-common Diffie-Hellman groups 

More detail around the DH configuration and a detailed list of recommended cipher suites including web server configuration examples can be found at https://weakdh.org/sysadmin.html. Additionally, an online SSL/TLS checker can be used to generate a full report of your current configuration in case your web server is publically reachable. A recommended tool is https://www.ssllabs.com/ssltest/analyze.html. The output of this SSL/TLS test suite will guide you into further (optional) details which can be tweaked regarding your configuration (i.e. OCSP stapling, certificate pinning, …).

Please note that using the above instruction "perfect forward secrecy" will be enabled. This basically means that captured TLS traffic can only be decoded using the session key between a specific client and server. Nonperfect forwarding secrecy connections can always be decrypted by having access to only the server's private key. If the customer's setup has intermediate IDS/WAF systems to inspect traffic looking inside the secure traffic, having perfect forwarding secrecy configured may not be desirable.

Public trusted root CA's

It is recommended that the *nix system where Apache is running always has the latest public root CA (certification authority) files available to authenticate server certificates during the SSL/TLS handshake. Most *nix distributions take care of this through their online update process. If this is not the case, the system administrator is responsible to ensure the latest trusted root CA's are up-to-date. Out of the box, the SugarCRM application contacts the SugarCRM heartbeat and licensing server using a secure connection.

HSTS header

As all traffic requires HTTPS for SugarCRM, it is recommended to configure a global HSTS (HTTP Strict Transport Security) header. This is an additional opt-in security enhancement supported by most modern browsers. The HSTS will instruct the browser to always use HTTPS in the future for the given FQDN. More details regarding HSTS can be found here: https://www.owasp.org/index.php/HTTP_Strict_Transport_Security.

Before enabling the HSTS header, ensure that no other non-HTTPS website is running for the given FQDN and any subdomains.

    Header always set Strict-Transport-Security \
"max-age=10886400; includeSubdomains; preload"

Optionally when your SugarCRM application is publically reachable, you can submit your FQDN on the preload which is maintained by Chrome and included by Firefox, Safari, Internet Explorer 11 and Edge browser. Understand the consequences and requirements to end up on the preload list. Once registered, this cannot be undone easily. Submissions for the HSTS preload list can be found at https://hstspreload.appspot.com.

CSP header

A Content Security Policy header can be added to offer additional protection against XSS (cross-site scripting). Most modern browsers support CSP and will apply the limitation as directed by the CSP header. The CSP header defines the allowed sources through different directives which are allowed regarding JScript, CSS, images, fonts, form actions, plugins, … More information can be found at https://www.owasp.org/index.php/Content_Security_Policy.

The management of CSP headers can become complex and may depend on different types of customizations which can be deployed on the SugarCRM platform. 

For now, CSP headers can be configured directly on the web server. A basic configuration looks like this: 

    Header always set Content-Security-Policy \
"default-src 'self'; script-src 'self'"

Note: This is a syntax example of a CSP header and not a recommended value.

Older browsers use the header X-Content-Security-Policy or X-WebKit-CSP instead of the standardized one. The CSP header can also safely be added first in "report only" mode before deploying it in production using Content-Security-Policy-Report-Only.

Additional security headers

To prevent clickjacking an X-Frame-Options header can be added. This header can also be used to iframe the SugarCRM application inside another web site if required. This can be better controlled with the above mentioned CSP header. Both can coexist together but it is encouraged to used the CSP approach.

    Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Frame-Options "ALLOW-FROM https://someothersite.com"

To protect against "drive-by download" attacks, it is encouraged to disable Content-Type sniffing. This is particularly targeted at Chrome and IE.

    Header always set X-Content-Type-Options "nosniff"

Ensure XSS browser protection is enabled by adding the following header. By default, this feature should be enabled in every browser. In case it has been disabled, sending this header will re-enable it.

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

Secure cookie settings

Ensure the following settings are applied in php.ini to ensure legacy cookies are properly protected against XSS attacks and are only transmitted over a secure HTTPS connection.

    session.cookie_httponly = 1
session.cookie_secure = 1

Additionally, the session.cookie_path can be tweaked if other applications are running on the same web server.

Security modules

Additional Apache loadable security modules exist which can optionally be installed to better protect your system from malicious requests and/or DDOS attacks. The following modules are available for Apache 2.4:

• mod_security - This module adds WAF (web application firewall) capabilities to your Apache setup. In combination with the OWASP CRS (core rule set) gives you a solid starting point for a WAF implementation.
• mod_evasive - This module helps to prevent (D)DOS attacks

Covering both modules in details is out of the scope of this Security Response. Refer to the module documentation for additional details. In the future, SugarCRM may publish specific settings and fine-tuning for both modules. 

Additional resources

Generic Apache security tips
http://httpd.apache.org/docs/2.4/misc/security_tips.html

Online SSL/TLS tester
https://www.ssllabs.com/ssltest/analyze.html

Useful HTTP headers
https://www.owasp.org/index.php/List_of_useful_HTTP_headers

Publication History

A stand-alone copy of this document that omits the distribution URL is an uncontrolled copy and may lack important information or contain factual errors. SugarCRM reserves the right to change or update this document at any time.