Difference between revisions of "Apache Hardening"

From EPrints Documentation
Jump to: navigation, search
(Content Security Policy)
m
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
There are various ways that Apache configuration can be hardened to make it more secure.  The suggested configuration changes below are informed by https://securityheaders.com/ Much of this is quite generic and could be applied to an web host not just an EPrints repository but some needs be be specifically configured for an EPrints repository.   
+
There are various ways that Apache configuration can be hardened to make it more secure.  The suggested configuration changes below are informed by https://securityheaders.com/ Much of this is quite generic and could be applied to any web host not just an EPrints repository but some needs be be specifically configured for an EPrints repository.   
  
 
== HTTP Strict Transport Security (HSTS) ==
 
== HTTP Strict Transport Security (HSTS) ==
Line 26: Line 26:
  
 
== Content Security Policy ==
 
== Content Security Policy ==
Content Security Policies are one of the more complex aspects to configure in Apache.  There purpose is to cover where aspects of the page (e.g. JavaScript, CSS, images, fonts, etc.) can be provided.  Also it covers how they can be provided, mainly in the case of JavaScript whether they can be inline or evaluated scripts.  EPrints repository software currently uses some inline scripts, so the benefits of the Content Security Policy are limited due to this.  However, EPrints repository software development is working towards eliminating use of inline JavaScript, so that a more secure Content Security Policy can be used.  At present the following policy is recommended.  It should work for vanilla EPrints repositories that only use common Bazaar plugins (e.g. IRStats2, etc.):
+
Content Security Policies are one of the more complex aspects to configure in Apache.  There purpose is to cover from where aspects of the page (e.g. JavaScript, CSS, images, fonts, etc.) can be provided.  Also, it covers how they can be provided, mainly in the case of JavaScript whether they can be inline or evaluated scripts.  EPrints repository software currently uses some inline scripts, so the benefits of the Content Security Policy are limited due to this.  However, EPrints repository software development is working towards eliminating use of inline JavaScript, so that a more secure Content Security Policy can be used.  At present the following policy is recommended.  It should work for vanilla EPrints repositories that only use common Bazaar plugins (e.g. IRStats2, etc.):
 
  Header set Content-Security-Policy "default-src 'none'; script-src 'self' 'unsafe-inline' www.google.com www.gstatic.com; connect-src 'self'; img-src 'self'; style-src 'self' 'unsafe-inline' www.gstatic.com; base-uri 'self'; form-action 'self'; font-src 'self'
 
  Header set Content-Security-Policy "default-src 'none'; script-src 'self' 'unsafe-inline' www.google.com www.gstatic.com; connect-src 'self'; img-src 'self'; style-src 'self' 'unsafe-inline' www.gstatic.com; base-uri 'self'; form-action 'self'; font-src 'self'
Like other Apache hardening configuration, this is best added to a file under Apache configuration directory so it is applied to all virtualhosts.  However, if you are running other websites that do no have inline or evaluated JavaScript, it may be better to add this line inside the HTTP and HTTPS virtualhosts for the EPrints repository in their archive's ''cfg/apachevhost.conf'' and ''ssl/securevhost.conf'' configurations.
+
Like other Apache hardening configuration, this is best added to a file under Apache configuration directory so it is applied to all virtualhosts.  However, if you are running other websites that do no have inline JavaScript, it may be better to add this line inside the HTTP and HTTPS virtualhosts for the EPrints repository in their archive's ''cfg/apachevhost.conf'' and ''ssl/securevhost.conf'' configurations.
  
The policy above currently only included '' 'unsafe-inline' '' needed for inline JavaScript.  It has been reported that sometimes EPrints repositories will use evaluated JavaScript, so it may be necessary to add '' 'unsafe-eval' '' to the ''script-src'' section.
+
The policy above currently only includes '' 'unsafe-inline' '' needed for inline JavaScript.  It has been reported that sometimes EPrints repositories will use evaluated JavaScript, so it may be necessary to add '' 'unsafe-eval' '' to the ''script-src'' section.
  
It is to be expected that many bespoke modifications or addition of Bazaar plugins will lead to you needing to update your Content Security Policy.  In particular if you rebenading your repository, as this will commonly use CSS, JavaScript, images and fonts from remote hosts.
+
It is to be expected that many bespoke modifications or addition of Bazaar plugins will lead to you needing to update your Content Security Policy.  In particular if your rebranding your repository, as this will commonly use CSS, JavaScript, images and fonts from remote hosts.
  
 
== SSL Protocols and Ciphers ==
 
== SSL Protocols and Ciphers ==
 +
Recommended SSL protocols and ciphers will change over time as new protocols/ciphers become available and older ones become considered as weak.  You want to make sure that you are using the strongest protocols and ciphers but if you only use these then some browsers may not be able to access you EPrints repositories.  Ensuring the correct balance is important.  The following lines should be added to your archive's HTTPS virtualhost (i.e. in the archive's ''ssl/securevhost.conf''):
 +
SSLHonorCipherOrder on
 +
SSLProtocol  all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
 +
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
 +
However, over time some of these protocols or ciphers may come to be considered weak.  You should periodically check you EPrints repository on https://www.ssllabs.com/ssltest/.  If you get an A grade or above then your protocol/cipher choice is still OK. (To get an A+ grade you need [[#HTTP Strict Transfer Protocol (HSTS)|HSTS]] enabled).  If you get less than an A grade, the report produced should tell you which protcols and ciphers you need to disable and possibly which newer one you should enable.
  
== SSL Session Tickets and Compression ==
+
== Disabling SSL Session Tickets and Compression ==
 +
On top of using strong SSL protocols and ciphers, disabling SSL session tickets and compression can further improve security.  As SSL session tickets can last a long time, this makes then vulnerable to being cracked.  Apache recommends if you use session tickets that your restart the webserver regularly (i.e. daily).  This is not ideal and far outweighs the small efficiency benefit over using SSL session IDs, so the simplest solution is to disable.  Using SSL compression may give a small performance improvement but has various security issues TLS (SSL) compression is not used by most modern browsers due to potential information leakage, so it is easiest just to turn this off as well.
 +
 
 +
To disable both SSL session tickets and compression you need to add the following two lines to your EPrints repository archive's ''ssl/securevhost.conf'':
 +
SSLSessionTickets off
 +
SSLCompression off
  
 
== X-Content-Type-Options (MIME Sniffing) ==
 
== X-Content-Type-Options (MIME Sniffing) ==
 +
EPrints repository software allows a wide range of different types of file to be uploaded but this can be restricted.  However, MIME sniffing can be used to assist getting round this restriction, allowing files to be presented under a different MIME type so they can uploaded when otherwise would not be permitted. Such uploaded files may then be used to facilitate cross-site scripting (XSS) attacks. To prevent MIME sniffing the following line should be used:
 +
Header set X-Content-Type-Options "nosniff"
 +
Like with other Apache hardening configuration, this should be added to a file under the Apache configuration directory, so it is applied to all virtualhosts.
  
 
[[Category:Howto]]
 
[[Category:Howto]]

Latest revision as of 12:11, 23 August 2022

There are various ways that Apache configuration can be hardened to make it more secure. The suggested configuration changes below are informed by https://securityheaders.com/ Much of this is quite generic and could be applied to any web host not just an EPrints repository but some needs be be specifically configured for an EPrints repository.

HTTP Strict Transport Security (HSTS)

HSTS ensures that a visitor's (to your EPrints repository) web browser only uses HTTPS, once they are aware HTTPS is available. It is now quite common to setup an Eprinst repository to be only HTTPS with HTTP redirects. If this is the case only your visitor's first request will be HTTP and then their web browser will know to use HTTPS from there on.

The following line should be added to near the top of the HTTPS virtualhost, (i.e. in the archive's ssl/securevhost.conf):

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

The max-age=31536000 is the recommended length in seconds (365 days, i.e. approx. 1 year). includeSubDomains is not absolutely necessary unless the repository has alternative hostnames that are under the primary hostname (e.g. www.example.eprints.org is a secondary hostname for example.eprints.org). preload is only really useful if your repository is the root of a domain (e.g. eprints.org) is on browsers preload lists (e.g. [1]). This will make sure that even the first request for your repository is rewritten to HTTPS before being submitted by your visitor's web browser.

X-Frame-Options (Clickjacking)

Clickjacking is where someone embed your website (e.g. EPrints repository) within their website to trick you into clicking on something you would not normally click. Generally there is no good reaso to allow your repository to be embedded on another website, so the following line should be used.

Header always append X-Frame-Options SAMEORIGIN

This can be put in its own file under Apache's configuration directories, as it is best to make sure it is applied to all virtualhosts.

Permissions Policy

Permissions Policy (formerly known as Features Policy but using different syntax), is intended to set out what access your EPrints repository might need to certain peripherals / sensors / features your visitor's web browser might have access (e.g. webcam, microphone and geolocation). EPrints repositories do not generally need access to any of these but if your repository was compromised (e.g. someone uploaded some JavaScript that would be executed if a user requested a certain page), it is sensible to explicitly specify access is not required, so these peripherals/data could not be misused.

The following line states that your EPrints repository does not need access to a visitor's computer's camera, geolocation or microphone.

Header always set Permissions-Policy "camera=(), geolocation=(self 'HOST_URL'), microphone=()"

Make sure you update the HOST_URL with the primary hostname URL of your repository (e.g. https://example.eprints.org/). Like for Clickjacking protection line, this is best added to its own file under Apache's configuration directories, so it applies to all virtualhosts. New peripherals, sensors and features continue to be added to the Permissions Policy. The line above is only intended to cover the most significant. You can build your own permissions policy at https://www.permissionspolicy.com/ and update the above line as appropriate.

Referrer Policy

Referers is an important part of how the Web works but it also means private information can be leaked between one website and another, often in a way where it could be intercepted. Referer Policy can ensure the private part of this information (i.e. specificially what you were accessing on the referring website ) is not sent to the referred website. Also the information that is being sent can only be sent if this would be over HTTPS, so it cannot be intercepted. Therefore, the following Referer Policy line is recommended:

Header set Referrer-Policy "strict-origin-when-cross-origin"

Like for Clickjacking protection and Permissions Policy lines, this is best added to its own file under Apache's configuration directories, so it applies to all virtualhosts. strict-origin-when-cross-origin will only send referer information to the website click on if the link is HTTPS. If the website is not the same website (i.e. the origin), then it will only send the hostname of the refering website not the full URL, which could contain private information.

Content Security Policy

Content Security Policies are one of the more complex aspects to configure in Apache. There purpose is to cover from where aspects of the page (e.g. JavaScript, CSS, images, fonts, etc.) can be provided. Also, it covers how they can be provided, mainly in the case of JavaScript whether they can be inline or evaluated scripts. EPrints repository software currently uses some inline scripts, so the benefits of the Content Security Policy are limited due to this. However, EPrints repository software development is working towards eliminating use of inline JavaScript, so that a more secure Content Security Policy can be used. At present the following policy is recommended. It should work for vanilla EPrints repositories that only use common Bazaar plugins (e.g. IRStats2, etc.):

Header set Content-Security-Policy "default-src 'none'; script-src 'self' 'unsafe-inline' www.google.com www.gstatic.com; connect-src 'self'; img-src 'self'; style-src 'self' 'unsafe-inline' www.gstatic.com; base-uri 'self'; form-action 'self'; font-src 'self'

Like other Apache hardening configuration, this is best added to a file under Apache configuration directory so it is applied to all virtualhosts. However, if you are running other websites that do no have inline JavaScript, it may be better to add this line inside the HTTP and HTTPS virtualhosts for the EPrints repository in their archive's cfg/apachevhost.conf and ssl/securevhost.conf configurations.

The policy above currently only includes 'unsafe-inline' needed for inline JavaScript. It has been reported that sometimes EPrints repositories will use evaluated JavaScript, so it may be necessary to add 'unsafe-eval' to the script-src section.

It is to be expected that many bespoke modifications or addition of Bazaar plugins will lead to you needing to update your Content Security Policy. In particular if your rebranding your repository, as this will commonly use CSS, JavaScript, images and fonts from remote hosts.

SSL Protocols and Ciphers

Recommended SSL protocols and ciphers will change over time as new protocols/ciphers become available and older ones become considered as weak. You want to make sure that you are using the strongest protocols and ciphers but if you only use these then some browsers may not be able to access you EPrints repositories. Ensuring the correct balance is important. The following lines should be added to your archive's HTTPS virtualhost (i.e. in the archive's ssl/securevhost.conf):

SSLHonorCipherOrder on
SSLProtocol  all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

However, over time some of these protocols or ciphers may come to be considered weak. You should periodically check you EPrints repository on https://www.ssllabs.com/ssltest/. If you get an A grade or above then your protocol/cipher choice is still OK. (To get an A+ grade you need HSTS enabled). If you get less than an A grade, the report produced should tell you which protcols and ciphers you need to disable and possibly which newer one you should enable.

Disabling SSL Session Tickets and Compression

On top of using strong SSL protocols and ciphers, disabling SSL session tickets and compression can further improve security. As SSL session tickets can last a long time, this makes then vulnerable to being cracked. Apache recommends if you use session tickets that your restart the webserver regularly (i.e. daily). This is not ideal and far outweighs the small efficiency benefit over using SSL session IDs, so the simplest solution is to disable. Using SSL compression may give a small performance improvement but has various security issues TLS (SSL) compression is not used by most modern browsers due to potential information leakage, so it is easiest just to turn this off as well.

To disable both SSL session tickets and compression you need to add the following two lines to your EPrints repository archive's ssl/securevhost.conf:

SSLSessionTickets off
SSLCompression off

X-Content-Type-Options (MIME Sniffing)

EPrints repository software allows a wide range of different types of file to be uploaded but this can be restricted. However, MIME sniffing can be used to assist getting round this restriction, allowing files to be presented under a different MIME type so they can uploaded when otherwise would not be permitted. Such uploaded files may then be used to facilitate cross-site scripting (XSS) attacks. To prevent MIME sniffing the following line should be used:

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

Like with other Apache hardening configuration, this should be added to a file under the Apache configuration directory, so it is applied to all virtualhosts.