Dans le cadre de nos activités d’infogérance et de serveurs virtuels / dédiés loués utilisant une interface de gestion Plesk, nous avons recours à plusieurs bonnes pratiques visant à héberger les sites PHP de façon sécurisée, quelles sont les recommandations que nous appliquons ?
Quels vecteurs d’attaques existent ?
Pour protéger votre ou vos sites internet, il y a plusieurs « portes d’entrée » à sécuriser. En effet, si vous sécurisez votre porte d’entrée à la maison mais que vous laissez la fenêtre ouverte, cela ne sert strictement à rien
Sécurisation de l’accès à Plesk
Si vous êtes une agence Web et que vous développez et hébergez des sites internet pour des clients, mais qu’ils n’ont pas besoin de se connecter à l’interface de gestion (exemple, vous réalisez également le Webmastering pour eux), le mieux est de bloquer le port 8880 et le port 8443 à tout le monde et autoriser uniquement des connexions depuis quelques adresses IP. La bonne pratique est de faire en sorte que tout le monde partage la même adresse IP et donc pour cela, un petit VPN peut être bien utile.
En effet, au lieu de mettre des IPs de box internet, vous mettez l’IP de confiance de votre ou de vos VPNs et tout le monde peut se connecter ainsi. Il vous faudra alors sécuriser votre accès VPN et non plus votre accès Plesk, qui ne changera pas, tant que vous ne changez rien au niveau de votre VPN
Si vous devez donner des accès à des clients, le mieux est de laisser Fail2ban (installé par défaut), activé et de laisser Plesk faire. Il est également possible de mettre un filtrage géographique pour autoriser uniquement par exemple les adresses IPs renseignées comme Française de se connecter.
Sécurisation du système d’exploitation
Si vous disposez d’une distribution comme CloudLinux, celle-ci propose nativement un système de mini-container. Grosso modo, chaque client dispose de ressources qui lui sont propres (cela s’active ou non) et surtout, on peut isoler son système de fichiers pour qu’il ne voit et n’accède uniquement à ce qu’il a le droit.
CloudLinux ne sécurise pas tout … si vous donnez l’accès au shell en précisant, /bin/bash ou /bin/sh ou autre et qu’une personne arrive à se connecter à ce shell, il pourra par exemple modifier la crontab et ajouter n’importe quoi. Certes, ce n’est pas l’ensemble du serveur qui est concerné, mais bien uniquement le site en question, ou tout le moins, l’ensemble des sites hébergés sous le même utilisateur (un utilisateur CloudLinux donne accès au même LVE et donc à un groupe de ressources qui sont partagées entre tous les sites gérés par ce même utilisateur)
Donc CloudLinux ou pas, faites très attention à ne pas donner l’accès au shell dès lors que cela n’est pas nécessaire, de plus, avec l’avènement des usines logicielles. Le besoin d’exécuter des commandes pour Symfony ou d’autres frameworks sont de moins en moins justifiées (La compilation des CSS doit être faite sur l’environnement de build et non de production …)
Sécurisation de SSH / SFTP / FTP
Plesk offre la possibilité de se connecter en SSH sur le serveur, récupérant ainsi un shell et permettant l’exécution de commandes. Si par bruteforce, fuite de mot de passe ou tout autre système permettant de connaitre le mot de passe de votre utilisateur, quelqu’un arrive à se connecter et à disposer d’un shell, il peut faire ce que bon lui semble.
La bonne pratique en SSH est d’utiliser une clé pour se connecter. Vous mettez un mot de passe improbable (par exemple une phrase ou un mot de passe de plus de 50 caractères) sur votre utilisateur Plesk, que vous oubliez et que vous changez de temps à autre (exemple tous les mois). Avez votre clé, vous vous connectez en SSH pour réaliser vos opérations. Afin d’encore plus sécuriser les choses, il est nécessaire de dédier un compte par usage. Si vous avez un outil de CI/CD qui doit se connecter, il doit avoir son accès propre et vous le votre (On ne mélange pas les torchons et les serviettes …)
Pour la partie FTP, il est recommandé de changer très régulièrement de mot de passe et si vous ne vous servez pas de ce protocole, alors fermez tout simplement le port 21 dans le système de gestion du Firewall de Plesk. Aussi, on applique les mêmes sécurisations que pour Plesk, on peut lui demander d’autoriser uniquement les connexions depuis des IPs françaises. Cela n’est pas une sécurité absolue mais cela permet de réduire la surface d’attaque. Et toujours, on laisse Fail2ban activé
Sécurisation de PHP
Pour sécuriser PHP, il est de bonne guerre de désactiver la possibilité d’exécuter des commandes système ou bien même de lancer un shell. Ceci évite que quelqu’un puisse, à travers une faille applicative, de prendre la main sur des commandes système et de modifier par exemple la crontab.
Il est de bon usage de désactiver ces commandes :
disable_functions=exec,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
En effet, il est privilégié de passer par des fonctionnalités native de PHP (exemple pour imagemagick)
Quand les applications sont bien faites, celles-ci ne doivent rencontrer aucun impact. En effet, WordPress, Prestashop, Magento, Drupal, Joomla doivent fonctionner sans le moindre mal.
Quant aux crons, ils sont exécutés par une autre instance de PHP (qui n’est pas le serveur Web) donc aucun souci sur ce sujet
Sécurisation de l’application
Une des bonnes pratiques avant tout est de garder le framework ou le moteur à jour (Votre WordPress doit être le plus à jour possible, votre Magento également …). Chaque version corrige des potentielles failles ou bien des failles tout court, et apporte son lot de nouveautés et de performance. C’est complètement bénéfique d’avoir les dernières versions
Devant chaque application, il devrait y avoir un WAF. Celui-ci est là pour se prémunir des attaques identifiées grâce à des signatures d’attaques. Si votre application / site internet / boutique en ligne n’a nullement besoin d’être présente en Inde, il est alors utile de fermer les accès à l’Inde par exemple. Plus vous limitez la surface d’attaques et moins de risque vous avez.
Tout autant, certains serveurs Web comme LiteSpeed ont développé des technologies analysant le flux HTTP(s) et si votre internaute réalise beaucoup d’erreurs sur le site, il peut être mis en quarantaine, protégeant ainsi vos ressources et votre contenu.
Pour finir
Avec 25 années d’expérience dans ce domaine, nous n’avons jamais fini d’en apprendre et d’en voir … l’internet est de base libre, voir trop libre peut-être, à vous de limiter la liberté que vous donnez aux autres pour que la vôtre ne soit pas compromise. Rappelons que vous êtes responsable des données que vous manipulez / stockez à travers votre site internet / application / boutique en ligne et qu’une faille peut vite couter très cher, tant par les amendes que la CNIL peut infliger mais également par une baisse de crédibilité de votre image de marque.
Si vous avez des questions / doutes ou que vous souhaitez être accompagnés, nous nous ferons un plaisir de vous apporter notre aide, et si vous n’avez pas envie de gérer ces problématiques, alors faites appel à nos services et nous nous occuperons de cela en toute connaissance de cause.
Rappelez-vous que la sécurité est un ensemble de couches que l’on ajoute et qui font la force du système, les solutions All-In-One qui font tout, peuvent connaître des défaillances et ce jour là, vous vous retrouvez sans le sous … encore une fois, rien ne sert de blinder la porte d’entrée, si la fenêtre reste ouverte à côté.
