mirror of
https://github.com/nextcloud/documentation.git
synced 2026-03-27 13:38:39 +07:00
clarify server hardening doc
Conflicts: admin_manual/configuration_server/harden_server.rst
This commit is contained in:
@@ -4,76 +4,64 @@ Hardening and Security Guidance
|
||||
|
||||
ownCloud aims to ship with secure defaults that do not need to get modified by
|
||||
administrators. However, in some cases some additional security hardening can
|
||||
only be applied in scenarios were the administrator has complete control over
|
||||
the ownCloud instance.
|
||||
|
||||
This document lists some security hardenings which require manual interaction by
|
||||
administrators. The whole document content is based on the assumption that you
|
||||
run ownCloud Server on Apache2 in a Linux environment.
|
||||
be
|
||||
applied in scenarios were the administrator has complete control over
|
||||
the ownCloud instance. This page assumes that you run ownCloud Server on
|
||||
Apache2
|
||||
in a Linux environment.
|
||||
|
||||
.. note:: ownCloud will warn you in the administration interface if some
|
||||
critical security-relevant options are missing. However, it is still up to
|
||||
the server administrator to review and maintain system security.
|
||||
|
||||
|
||||
Limit on Password Length
|
||||
------------------------
|
||||
|
||||
ownCloud uses the bcrypt algorithm and thus for security and performance reasons,
|
||||
e.g. Denial of Service as CPU demand increases exponentially, it only verifies
|
||||
the first 72 characters of passwords. This applies to all passwords that you use
|
||||
in ownCloud: user passwords, passwords on link shares, and passwords on external
|
||||
shares.
|
||||
ownCloud uses the bcrypt algorithm, and thus for security and performance
|
||||
reasons, e.g. Denial of Service as CPU demand increases exponentially, it only
|
||||
verifies the first 72 characters of passwords. This applies to all passwords
|
||||
that you use in ownCloud: user passwords, passwords on link shares, and
|
||||
passwords on external shares.
|
||||
|
||||
Operating system
|
||||
----------------
|
||||
|
||||
.. _dev-urandom-label:
|
||||
|
||||
Give PHP read accesss to ``/dev/urandom``
|
||||
*****************************************
|
||||
|
||||
ownCloud uses a `RFC 4086 ("Randomness Requirements for Security")`_ compliant
|
||||
mixer to generate cryptographically secure pseudo-random numbers. This means
|
||||
that when generating a random number ownCloud will request multiple random
|
||||
numbers from different sources and derive from these the final random number.
|
||||
|
||||
The random number generation also tries to request random numbers from
|
||||
``/dev/urandom``, thus it is **highly recommended** to configure your setup in
|
||||
such a way that PHP is able to read random data from it. Not granting PHP access
|
||||
to ``/dev/urandom`` may make your random numbers predictable and may make your
|
||||
ownCloud instance insecure as attackers might predict password reset tokens or
|
||||
other sensitive data.
|
||||
|
||||
.. note:: When having an ``open_basedir`` configured within your ``php.ini``
|
||||
make sure to include the folder ``/dev``.
|
||||
``/dev/urandom``, thus it is highly recommended to configure your setup in such
|
||||
a way that PHP is able to read random data from it.
|
||||
|
||||
Enable hardening modules such as SELinux
|
||||
****************************************
|
||||
It is highly recommend to enable hardening modules such as SELinux where
|
||||
|
||||
It is highly recommended to enable hardening modules such as SELinux where
|
||||
possible. See :doc:`../installation/selinux_configuration` to learn more about
|
||||
SELinux.
|
||||
|
||||
Use newest PHP version
|
||||
**********************
|
||||
Some security features and hardenings in PHP are only available in the latest
|
||||
PHP release and thus it is recommended to run the latest PHP version. You can
|
||||
find the latest version on http://php.net/.
|
||||
|
||||
Some Linux distributions backport security patches, but this is not reliable as
|
||||
some get missed, or the backports are years late. It is always best to run the
|
||||
latest PHP version.
|
||||
|
||||
Deployment
|
||||
----------
|
||||
|
||||
Move data directory outside of the web root
|
||||
*******************************************
|
||||
It is highly recommended to move the data directory (where ownCloud stores its
|
||||
data) outside of the web root (i.e. outside of ``/var/www``) It is possible to
|
||||
do this by moving the folder manually, and then adjusting the
|
||||
``'datadirectory'`` parameter in ``config.php``.
|
||||
Place data directory outside of the web root
|
||||
********************************************
|
||||
|
||||
It is highly recommended to place your data directory outside of the Web root
|
||||
(i.e. outside of ``/var/www``). It is easiest to do this on a new
|
||||
installation.
|
||||
|
||||
.. Doc on moving data dir coming soon
|
||||
.. You may also move your data directory on an existing
|
||||
.. installation; see :doc:``
|
||||
|
||||
Disable preview image generation
|
||||
********************************
|
||||
|
||||
ownCloud is able to generate preview images of common filetypes such as images
|
||||
or text files. By default the preview generation for some file types that we
|
||||
consider secure enough for deployment is enabled by default. However,
|
||||
@@ -82,23 +70,24 @@ libraries written in C which might be vulnerable to attack vectors.
|
||||
|
||||
For high security deployments we recommend disabling the preview generation by
|
||||
setting the ``enable_previews`` switch to ``false`` in ``config.php``. As an
|
||||
administrator you are also able to manage which preview providers are enabled by
|
||||
administrator you are also able to manage which preview providers are enabled
|
||||
by
|
||||
modifying the ``enabledPreviewProviders`` option switch.
|
||||
|
||||
.. _use-https-label:
|
||||
|
||||
Use HTTPS
|
||||
---------
|
||||
Using ownCloud without using an encrypted HTTPS connection might allow attackers
|
||||
in a man-in-the-middle (MITM) situation to intercept your users data and
|
||||
passwords. Thus ownCloud always recommends to setup ownCloud behind HTTPS.
|
||||
|
||||
How to setup HTTPS on your web server depends on your setup, we recommend to
|
||||
check your distribution's vendor information on how to configure and setup
|
||||
HTTPS.
|
||||
Using ownCloud without using an encrypted HTTPS connection opens up your server
|
||||
to a man-in-the-middle (MITM) attack, and risks the interception of user data
|
||||
and passwords. It is a best practice, and highly recommended, to always use
|
||||
HTTPS on production servers, and to never allow unencrypted HTTP.
|
||||
|
||||
How to setup HTTPS on your Web server depends on your setup; please consult the
|
||||
documentation for your HTTP server. The following examples are for Apache.
|
||||
|
||||
Redirect all unencrypted traffic to HTTPS
|
||||
*****************************************
|
||||
|
||||
To redirect all HTTP traffic to HTTPS administrators are encouraged to issue a
|
||||
permanent redirect using the 301 status code. When using Apache this can be
|
||||
achieved by a setting such as the following in the Apache VirtualHosts config:
|
||||
@@ -110,16 +99,14 @@ achieved by a setting such as the following in the Apache VirtualHosts config:
|
||||
Redirect permanent / https://cloud.owncloud.com/
|
||||
</VirtualHost>
|
||||
|
||||
.. _enable-hsts-label:
|
||||
|
||||
Enable HTTP Strict Transport Security
|
||||
*************************************
|
||||
While redirecting all traffic to HTTPS is already a good start it will often not
|
||||
completely prevent man-in-the-middle attacks for a regular user. Thus
|
||||
administrators are encouraged to set the HTTP Strict Transport Security header
|
||||
which will instruct browsers to not allow any connection to the ownCloud
|
||||
instance anymore using HTTPS and an invalid certificate warning will often not be
|
||||
able to get bypassed.
|
||||
|
||||
While redirecting all traffic to HTTPS is good, it may not completely prevent
|
||||
man-in-the-middle attacks. Thus administrators are encouraged to set the HTTP
|
||||
Strict Transport Security header, which instructs browsers to not allow any
|
||||
connection to the ownCloud instance using HTTP, and it attempts to prevent site
|
||||
visitors from bypassing invalid certificate warnings.
|
||||
|
||||
This can be achieved by setting the following settings within the Apache
|
||||
VirtualHost file:
|
||||
@@ -128,66 +115,66 @@ VirtualHost file:
|
||||
|
||||
<VirtualHost *:443>
|
||||
ServerName cloud.owncloud.com
|
||||
Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
|
||||
Header always add Strict-Transport-Security "max-age=15768000"
|
||||
</VirtualHost>
|
||||
|
||||
Be aware that the above policy will also apply for all subdomains. If you don't
|
||||
have HTTPS properly configured on all subdomains you mut remove the ``includeSubdomains``
|
||||
part.
|
||||
|
||||
Furthermore it shall be noted that this requires that the ``mod_headers``
|
||||
extension is installed.
|
||||
This requires the ``mod_headers`` extension in Apache.
|
||||
|
||||
Proper SSL configuration
|
||||
************************
|
||||
Default SSL configurations by web servers are often not state of the art and
|
||||
|
||||
Default SSL configurations by Web servers are often not state-of-the-art, and
|
||||
require fine-tuning for an optimal performance and security experience. The
|
||||
available SSL ciphers and options depend completely on your environment and
|
||||
thus giving a generic recommendation is not really possible.
|
||||
|
||||
We recommend to use the `Mozilla SSL Configuration Generator`_ to generate a
|
||||
suitable configuration suited for your environment, furthermore the free `Qualys
|
||||
SSL Labs Tests`_ give good guidance about whether the SSL server was correctly
|
||||
We recommend using the `Mozilla SSL Configuration Generator`_ to generate a
|
||||
suitable configuration suited for your environment, and the free `Qualys
|
||||
SSL Labs Tests`_ gives good guidance on whether your SSL server is correctly
|
||||
configured.
|
||||
|
||||
Use a dedicated domain for ownCloud
|
||||
-----------------------------------
|
||||
|
||||
Administrators are encouraged to install ownCloud on a dedicated domain such as
|
||||
cloud.domain.tld instead of domain.tld to gain all the benefits offered by the
|
||||
Same-Origin-Policy.
|
||||
|
||||
Serve security related Headers by the web server
|
||||
------------------------------------------------
|
||||
Basic security headers are served by ownCloud already in a default environment. These include:
|
||||
|
||||
Basic security headers are served by ownCloud already in a default environment.
|
||||
These include:
|
||||
|
||||
- ``X-Content-Type-Options: nosniff``
|
||||
- Instructs some browsers to not sniff the mimetype of files. This is used for example to prevent browsers from interpreting text files as JavaScript.
|
||||
- Instructs some browsers to not sniff the mimetype of files. This is
|
||||
used for example to prevent browsers from interpreting text files as JavaScript.
|
||||
- ``X-XSS-Protection: 1; mode=block``
|
||||
- Instructs browsers to enable their browser side Cross-Site-Scripting filter.
|
||||
- Instructs browsers to enable their browser side Cross-Site-Scripting
|
||||
filter.
|
||||
- ``X-Robots-Tag: none``
|
||||
- Instructs search machines to not index these pages.
|
||||
- ``X-Frame-Options: SAMEORIGIN``
|
||||
- Prevents embedding of the ownCloud instance within an iframe from other domains to prevent Clickjacking and other similiar attacks.
|
||||
- Prevents embedding of the ownCloud instance within an iframe from
|
||||
other domains to prevent Clickjacking and other similiar attacks.
|
||||
|
||||
However, these headers are added by the applications code in PHP and thus not
|
||||
served on static resources and rely on the fact that there is no way to bypass
|
||||
the intended response code path.
|
||||
These headers are hard-coded into the ownCloud server, and need no intervention
|
||||
by the server administrator.
|
||||
|
||||
For optimal security, administrators are encouraged to serve these basic HTTP
|
||||
headers by the web server to enforce them on response.
|
||||
|
||||
Apache has to be configured to use the ``.htaccess`` file and the following Apache
|
||||
headers by the web server to enforce them on response. To do this Apache has to
|
||||
be configured to use the ``.htaccess`` file and the following Apache
|
||||
modules need to be enabled:
|
||||
|
||||
- mod_headers
|
||||
- mod_env
|
||||
|
||||
For nginx, please see the nginx configuration example :ref:`nginx_configuration_example`
|
||||
|
||||
Administrators can verify whether this security change is active by accessing a
|
||||
static resource served by the web server and verify that the above mentioned
|
||||
security headers are shipped.
|
||||
|
||||
.. _Mozilla SSL Configuration Generator: https://mozilla.github.io/server-side-tls/ssl-config-generator/
|
||||
.. _Mozilla SSL Configuration Generator:
|
||||
https://mozilla.github.io/server-side-tls/ssl-config-generator/
|
||||
.. _Qualys SSL Labs Tests: https://www.ssllabs.com/ssltest/
|
||||
.. _RFC 4086 ("Randomness Requirements for Security"): https://tools.ietf.org/html/rfc4086#section-5.2
|
||||
.. _RFC 4086 ("Randomness Requirements for Security"):
|
||||
https://tools.ietf.org/html/rfc4086#section-5.2
|
||||
Reference in New Issue
Block a user