Sécuriser son site web
======================
Principes de base
^^^^^^^^^^^^^^^^^
Voici quelques précautions à prendre pour réduire les risques d’infection de votre CMS :
* vérifier que le CMS est à jour en dernière version
* s’assurer que les plugins et modules soient eux aussi à jour
* s’inscrire aux bulletins de sécurité du CMS et des plugins
* filtrer les accès aux admins par des IP autorisées (fichier .htaccess)
* limiter l’impact des attaques par brute force sur les admin via une authentification par le serveur web
* supprimer les dossiers/fichiers d’installation
* complexifier les identifiants (login utilisateur et mot de passe) des accès administration, FTP et BDD
* interdire l’exécution de code php dans les dossiers où des fichiers .php n’ont pas à se trouver (img/ par exemple) via le fichier .htaccess
* Attribuer les bonnes permissions sur les fichiers et dossiers. Se référer aux préconisations de l’éditeur du CMS.
Séparation des privilèges
^^^^^^^^^^^^^^^^^^^^^^^^^
DRI respecte l’état de l’art et les bonnes pratiques en matière de sécurité et de défense des environnements web. Aussi, les plates-formes mises à disposition de nos clients sont organisées sous le principe de la séparation des privilèges, c’est à dire que chaque fonctionnalité ne doit posséder que les privilèges et ressources nécessaires à son exécution.
Cette contrainte peut affecter certains développeurs dans l’administration des environnements mais assurément, cette bonne pratique est nécessaire et est un minimum pour éviter toutes intrusions au sein de vos espaces. Ce principe est d’autant plus indispensable sur les environnements mutualisés car pouvant impacter les autres clients. L’intrusion devient alors une porte ouverte avec des rebonds possibles entre différents sites web.
Dans ce contexte, nous imposons la création et la définition de :
* un compte dédié à l’utilisateur web Apache en lecture uniquement. Les applications nécessitant des droits en écriture sur certains dossiers (cache, upload,modules...) pourront être traitées en exception et au cas par cas. Dans ce cas de figure, une protection par .htaccess doit alors être appliquée. Ce filtrage par extensions de fichiers sera adapté au besoin et au type de contenu que le dossier doit héberger pour l’application.
* un compte dédié à l’utilisateur ftp en écriture permettant de manipuler les dossiers et fichiers depuis cet accès.
Quelques exemples
-----------------
Voici quelques exemples de directives à placer dans un fichier .htaccess
Prestashop : Désactivation de PHP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Placer un fichier .htaccess dans les dossiers cache, download, img, log, mails, upload
.. code-block:: php
# On désactive l'interprétation des fichiers PHP
RemoveHandler .php
# On interdit l'accès aux fichiers PHP
Deny from all
Prestashop : protection du backoffice
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: php
# Authentification par mot de passe
AuthName "Authorized Only"
AuthType Basic
AuthUserFile /var/www/html/virtualdomains/12345/domain.com/projects/htpasswd-require valid-user
# Filtrage IP
Order deny,allow
Deny from all
Allow from 192.0.2.142
Allow from 198.51.100.2
Satisfy Any
Wordpress : configuration de wp-config.php
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: php
# Définit les droits sur les fichiers crées
define('FS_CHMOD_DIR', 0770 );
define('FS_CHMOD_FILE', 0660 );
# Utilise le FTP pour la mise à jour du code
# depuis le backoffice
define('FS_METHOD', 'ftpsockets');
# Désactive l'édition en ligne
define('DISALLOW_FILE_EDIT', true);
Wordpress : protection du backoffice
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: php
# Authentification par mot de passe
AuthName "Authorized Only"
AuthType Basic
AuthUserFile /var/www/html/virtualdomains/12345/domain.com/projects/htpasswd-require valid-user
# Filtrage IP
Order deny,allow
Deny from all
Allow from 192.0.2.142
Allow from 198.51.100.2
Satisfy Any