Guide de durcissement et de sécurité¶
ownCloud est livré avec des paramètres de sécurité par défaut qui n’ont pas besoin d’être modifiés par les administrateurs. Cependant, dans certains cas, un durcissement de la sécurité peut être appliqué dans des scénarios où les administrateurs ont le contrôle total sur leur instance ownCloud. Cette page suppose que vous exécutiez un serveur ownCloud sur Apache2 dans un environnement Linux.
Note
ownCloud vous avertira sur la page d’administration si des options de sécurité critiques sont manquantes. Cependant, il appartient toujours à l’administrateur du serveur de revoir et de maintenir la sécurité du système.
Limite de la longueur du mot de passe¶
ownCloud utilise l’algorithme bcrypt, et par conséquent, pour des raisons de sécurité et de performances, par exemple un déni de service, car la demande en CPU augmente exponentiellement, il ne vérifie que les 72 premiers caractères des mots de passe. Ceci s’applique à tous les mots de passe utilisés dans ownCloud : les mots de passe utilisateur, ceux des partages de liens et ceux des partages externes.
Système d’exploitation¶
Accès en lecture de PHP à /dev/urandom¶
ownCloud utilise un mixeur conforme à la RFC 4086 (“Randomness Requirements for Security”) pour générer des nombres pseudo-aléatoires sécurisés cryptographiquement. Ceci signifie que lors de la génération d’un nombre aléatoire, ownCloud demandera de multiples nombres aléatoires à différentes sources et en dérivera le nombre aléatoire final.
La génération de nombres aléatoires essaiera aussi d’obtenir des nombres aléatoires de /dev/urandom. Par conséquent, il est vivement recommandé de configurer PHP pour qu’il puisse lire des données aléatoires sur celui-ci.
Note
Quand open_basedir est configuré dans le fichier php.ini, assurez-vous d’inclure /dev/urandom.
Activation des modules de durcissement tel que SELinux¶
Il est vivement recommandé d’activer les modules de durcissement tel que SELinux quand c’est possible. Consulter Configuration SELinux pour en apprendre plus sur SELinux.
Déploiement¶
Placement du répertoire data en dehors de la racine Web¶
Il est vivement recommandé de placer le répertoire data en dehors de la racine Web (c-à-d. en dehors de /var/www). Il est plus facile de le faire sur une nouvelle installation.
Désactivation de la génération d’aperçus¶
ownCloud peut générer des aperçus de type de fichiers courants tels que les images ou les fichiers texte. Par défaut, la génération d’aperçus pour quelques types de fichiers que nous considérons comme suffisamment sûrs pour le déploiement est activée par défaut. Cependant, les administrateurs doivent garder à l’esprit que ces aperçus sont générés en utilisant des bibliothèques PHP écrites en C et qui peuvent être vulnérables aux attaques par vecteurs.
Pour des déploiements très sécurisés, nous recommandons de désactiver la génération d’aperçus en définissant enable_previews à false dans le fichier config.php. En tant qu’administrateur, vous pouvez aussi gérer quels fournisseurs d’aperçus sont activés en utilisant l’option enabledPreviewProviders.
Utilisation de HTTPS¶
L’utilisation d’ownCloud sans connexion chiffrée HTTPS rend votre serveur vulnérable aux attaques de type man-in-the-middle (MITM), et permet potentiellement l’interception de données utilisateur et de mots de passe. La bonne pratique, que nous recommandons vivement, est de toujorus utilsier HTTPS pour les serveurs de production et de ne jamais autoriser les connexions non chiffrées HTTP.
La configuration HTTPS de votre serveur Web est fonction du serveur utilisé. Veuillez consulter la documentation de votre serveur HTTP. Les exemples suivants s’appliquent à un serveur Apache.
Redirection de tout trafic non chiffré en HTTPS¶
Pour rediriger tout le trafic HTTP en HTTPS, les administrateurs sont encouragés à définir une redirection permanente en utilisant le code d’état 301. Avec Apache, ceci peut être accompli comme suit dans la configuration des hôtes virtuels d’Apache contenant l’entrée <VirtualHost *:80> :
Redirect permanent / https://exemple.com/
Activation de HTTP Strict Transport Security¶
Rediriger tout le trafic vers HTTPS est bien mais ne protège pas complètement des attaques man-in-the-middle. Par conséquent, les administrateurs sont encouragés à définir l’en-tête HTTP Strict Transport Security, qui indique aux navigateurs de ne pas autoriser de connexion à l’instance ownCloud en utilisant HTTP, et essaient d’empêcher les visiteurs du site de passer outre les avertissements de certificats invalides.
Ceci peut être accompli en définissant les paramètres suivants dans la configuration de l’hôte virtuel d’Apache contenant l”entrée <VirtualHost *:443>
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains"
</IfModule>
Si vous n’avez pas accès à votre fichier de configuration Apache, il est aussi possible d’ajouter ceci dans le fichier .htaccess principal livré avec ownCloud. Assurez-vous de l’ajouter sous la ligne suivante
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####
Cet exemple de configuration rendra également les sous-domaines uniquement accessibles par HTTPS. Si vous avez des sous-domaines non accessibles par HTTPS, supprimez includeSubdomains;.
Note
Ceci nécessite l’activation du module Apache mod_headers.
Si vous utilisez nginx comme serveur Web, un exemple est déjà inclus dans Exemples de configurations pour Nginx
#add_header Strict-Transport-Security "max-age=15768000; includeSubDomains";
Vous devez retirer le caractère # et recharger nginx pour activer cette modification.
Configuration SSL correcte¶
Les configurations SSL par défaut des serveurs Web ne sont souvent pas optimales et nécessitent d’être ajustée pour des performances et une sécurité optimales. Les chiffrements SSL et les options dépendent compmlètement de votre environnement et par conséquent, une recommandation générique n’est pas possible.
Nous recommandons l’utilisation de Mozilla SSL Configuration Generator pour générer une configuration sécurisée adaptée à vos besoins et votre environnement, et l’outil gratuit Qualys SSL Labs Tests qui donne de bonnes indications sur la configuration de votre serveur SSL.
Assurez-vous également que la compression HTTP soint désactivée pour réduire le risque d’attaque BREACH.
Utilisation d’un domaine dédié pour ownCloud¶
Les administrateurs sont encouragés à installer ownCloud sur un domaine dédié comme par exemple « cloud.domaine.tld » au lieu de « domaine.tld » pour obtenir tous les bénéfices offerts par la Same-Origin-Policy (politique de même origine).
Installation de l’instance ownCloud dans une DMZ¶
Comme ownCloud gère des fonctionnalités tel que le partage de fichiers fédéré, nous ne considérons pas que Server Side Request Forgery (SSRF) fasse partie de notre modèle de menace. En fait, étant donné tous les connecteurs de stockage externes, cela peut être considéré comme une fonctionnalité et non une vulnérabilité.
Cela signifie qu’un utilisateur de votre instance ownCloud pourrait explorer si d’autres hôtes sont accessibles depuis le réseau ownCloud. Si vous ne voulez pas ceci, vous devez vous assurer que votre ownCloud est correctement installé dans un réseau distinct et avec des règles de pare-feu correctes.
Service d’en-têtes relatifs à la sécurité par le serveur Web¶
Les en-têtes de sécurité de base sont déjà servis par ownCloud dans un environnement par défaut. Ce qui inclut :
- X-Content-Type-Options: nosniff
- Indique à certains navigateurs de ne pas renifler le type MIME des fichiers. Ceci est utilisé pour empêcher les navigateurs d’interprêter des fichiers texte comme du JavaScript.
- X-XSS-Protection: 1; mode=block
- Indique aux navigateurs d’activer leurs propres filtres de Cross-Site-Scripting.
- X-Robots-Tag: none
- Indique aux robots de recherche de ne pas indexer ces pages.
- X-Frame-Options: SAMEORIGIN
- Empêche l’intégration de l’instance ownCloud dans un iframe d’un autre domaine pour empêcher le Clickjacking ou d’autres attaques similaires.
Ces en-têtes sont codés en dur dans le serveur ownCloud et ne nécessitent aucune intervention de la part des administrateurs.
Pour une sécurité optimale, les administrateurs sont encouragés à faire servir ces en-têtes de sécurité de base par leur serveur Web. Pour faire cela, Apache doit être configuré pour utiliser le fichier .htaccess et les modules Apache suivantes doivent être activés :
- mod_headers
- mod_env
Les administrateurs peuvent vérifier si ce changement de sécurité est actif en accédant à une ressource statique servie par le serveur Web et en vérifiant que les en-têtes de sécurité mentionnés plus haut soient bien présents.
