LEMP : guide ultime pour un serveur web sécurisé et performant

Publié le , par Jacky Thierry, dans la catégorie #Sécurité & adminsys

LAMP & LEMP installation serveur

A propos de l'auteur

Jacky THIERRY

CTO, Project Manager, Startup owner

Travaillant depuis plus de 15 ans dans le digital, j'ai dirigé de nombreux projets pour des grosses companies mondiales, des agences web, et des associations locales. Je suis spécialisé dans le développement agile avec des équipes outsourcées.

  • Jacky Thierry linkedin
  • Jacky Thierry twitter
  • Jacky Thierry instagram
  • Jacky Thierry RSS feed
Jacky Thierry

Découvrir la stack LEMP

1 – Qu’est ce que LEMP ?

LEMP est l’une des stacks les plus populaires pour faire fonctionner un site internet, possédant de très bonnes performances et des fonctionnalités récentes. C’est un pack d’outils incluant un serveur web, une base de données, et un langage de programmation, le tout fonctionnant nativement avec chaque distribution Linux. Cette stack logicielle peut également fonctionner sous Windows ou Mac.

LEMP est un acronyme signifiant :

  • L : Linux – les serveurs fonctionnent nativement sous une distribution Linux
  • E : EngineX, souvent appelé Nginx – serveur web qui recevra les requêtes de vos visiteurs et les redirigera vers le dossier hébergeant votre site
  • M : MariaDB or Mysql – base de données qui stockera toutes les données (contenus, utilisateurs, configuration, médias..) dont vous aurez besoin sur votre site
  • P : PHP – langage de programmation que vous utiliserez pour développer votre site

2 – Pourquoi auto-héberger votre serveur web ?

Héberger son propre serveur web est généralement une bonne idée pour les sociétés, les administrateurs systèmes, et les développeurs web. Cela apporte certains avantages par rapport à une solution d’hébergement mutualisée qui possède certaines limites :

  1. Vous pouvez installer n’importe quel composant, sans être restreint par une liste autorisée
  2. Vous pouvez totalement optimiser votre service et changer les configurations systèmes selon vos besoins
  3. Vous pouvez contrôler les versions et mises à jour de vos logiciels et composants
  4. Vous ne partagez pas les performances et la bande passante avec d’autres clients

Bien sur, cela requiert quelques compétences techniques. Il vous faudra installer, configurer, et maintenir vos serveurs, cela demande plus de travail et de temps qu’une solution d’hébergement mutualisée. Néanmoins, cela est fortement recommandé pour les personnes qui sont prêtes à investir un peu de temps et qui ont (ou souhaitent acquérir) des compétence en administration système.

3 – Alternatives à LEMP

LEMP n’est pas la seule solution possible pour héberger un site web. Il existe de nombreuses stacks, selon votre système d’exploitation et vos composants. Comme LEMP, ils incluent pour la plupart un serveur web, une base de données et un langage de programmation. Voici une liste non exhaustive de solutions existantes :

  • LEMP / WEMP / MEMP : Nginx, Mysql/MariaDB, PHP pour systèmes Linux, Windows ou Mac
  • LAMP / WAMP / MAMP : Apache, Mysql/MariaDB, PHP pour systèmes Linux, Windows ou Mac
  • MEAN : MongoDB, ExpressJs, Angular, NodeJS
  • RAMP : Ruby on rails, Apache, Mysql, Passenger

Afin de choisir celui qui vous correspond le plus, le système d’exploitation et le langage de programmation sont souvent les 2 prérequis à considérer en priorité.

4 – LEMP vs LAMP

LEMP est une déclinaison de LAMP, ce qui signifie que choisir LEMP plutôt que LAMP revient à choisir Nginx à qu’Apache. Les 2 sont fonctionnels, performants et massivement utilisés en tant que serveurs web, il n’y a donc pas de meilleur choix dans l’absolu. Pour un usage classique, cela dépend principalement de vos préférences personnelles.

4.1 – Nginx vs Apache

Comme Lighthttpd avant lui, Nginx est un serveur léger et moderne, offrant de très bonnes performances et implémentant généralement de nouvelles fonctionnalités plus rapidement qu’Apache (comme TLS 1.3).

Il a été conçu dans le but de palier aux principaux défauts d’apache. Il possède une approche asynchrone et non bloquante, au lieu d’un concept basé sur des process et des threads. Cela signifie que Nginx ne créé pas de nouveau process pour chaque requête et obtient donc de meilleures performances (spécialement sous une charge conséquente). Il inclut également les modules lors de sa compilation, et possède un module PHP dans son cœur.

Si vous souhaitez en savoir plus sur les différences techniques, vous pouvez consulter cette excellente comparaison entre Nginx et Apache. Nous pouvons en conclure :

  1. Nginx est plus récent et rapide qu’Apache dans leurs versions standards. Il fonctionne plus efficacement sous une charge importante, sans installation de module de cache ou d’optimisations spécifiques
  2. Nginx possède moins d’options qu’Apache, mais suffit dans la plupart des cas. Il a été construit avec le philosophie « Faire moins mais mieux »
  3. Grace à son design léger, Nginx est plus simple à configurer en tant que serveur statique, mais plus difficile dans un environnement complexe

De mon avis, Nginx est généralement un meilleur choix du à son design et ses performances, sauf si vous possédez de solides connaissances d’Apache, ou avez des besoins très spécifiques.

4.2 – MariaDB vs Mysql

MariaDB et Mysql sont tous deux utilisés dans les stacks LEMP et LAMP. MariaDB est un fork de Mysql, créé par Michal Widenius (également créateur de Mysql), au moment du rachat de Mysql (possédé par Sun) par Oracle. La communauté libre était à l’époque inquiète qu’Oracle puisse changer la licence de Mysql, et a donc créé un fork pour s’assurer que celui ci reste libre et ouvert. MariaDB est sous licence GPLv2 (GNU General Public Licence 2).

MariaDB est entièrement compatible avec Mysql, ce qui signifie qu’il fonctionne exactement de la même manière. Toutes les commandes et options sont identiques (à l’exception des nouvelles fonctionnalités développées par Oracle et réservées à la version commerciale), à la différence qu’elles sont nommées mariadb au lieu de mysql.

5 – Parts de marché de LEMP

Voici quelques données pour illustrer l’utilisation et la progression de LEMP ces dernières années :

  1. Nginx est, début 2018, utilisé par plus de 35% des serveurs web dans le monde.
  2. Apache est maintenant utilisé par moins de 50% des serveurs.
  3. Durant les 5 dernières années, le nombre de serveurs en production utilisant Nginx a augmenté de plus de 20%. Apache lui, est utilisé sur 20% de serveurs en moins.
  4. PHP est utilisé par 83% des sites internet dans le monde, augmentant de 6% en 5 ans.
  5. PHP7 est sorti en décembre 2015, et est maintenant, début 2018, utilisé par 10% des serveurs sous PHP

Sources (en anglais) : Nginx market share evolution, usage of PHP as backend language, usage of PHP7 vs PHP5.

Installer LEMP

Pour installer la stack LEMP, nous allons installer séparément plusieurs serveurs, puis les configurer :

  1. Nginx
  2. PHP7
  3. MariaDB

Avant de commencer, assurez vous que votre serveur est à jour :
apt update && apt dist-upgrade

1 – Installer Nginx

Nous utiliserons la version de Nginx provenant des dépôts officiels de votre distribution, puis optimiserons certaines valeurs par défaut dans le fichier principal de configuration :

apt install nginx

vi /etc/nginx/nginx.conf

client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 4 16k;
fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;

Redémarrez maintenant le service pour appliquer les changements :

service nginx restart

2 – Installer PHP7

PHP 7.0 est la version fournie par défaut sous Debian. Si vous souhaitez une version plus à jour de PHP (PHP 7.2 au moment de la rédaction de cet article), vous pouvez utiliser le dépôt d’Ondrej Sury, contenant la dernière version de PHP pour debian et ubuntu.

apt install php7.0-fpm php7.0-mysql php7.0-common php7.0-gd php7.0-json php7.0-cli php7.0-curl php7.0-xml php7.0-zip php7.0-mbstring

Une fois installé, changez ces valeurs :

vi /etc/php/7.0/fpm/pool.d/www.conf

pm.max_children = 10
pm.max_requests = 200

vi /etc/php/7.0/fpm/php.ini

date.timezone = America/Cayenne //Indiquez votre timezone
upload_max_filesize = 8M
max_execution_time = 60
max_input_vars = 5000

Redémarrez maintenant le service pour appliquer les changements :

service php7.0-fpm restart

3 – Installer MariaDB

Maintenant, nous allons installer MariaDB. J’ai choisi dans ce tuto d’utiliser MariaDB plutôt que Mysql pour la pérennité de sa licence, mais celle ci étant un fork de la 2ème, les 2 fonctionnent de la même manière, vous devrez juste changer « mariadb-server » par « mysql-server » si vous souhaitez installer Mysql.

apt install mariadb-server

Par défaut, MariaDB n’est pas sécurisé et contient une base de données de test. Le paquet nous fournit un script à exécuter pour y remédier, donc n’oubliez surtout pas de lancer celui-ci après l’installation :

mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
Enter current password for root (enter for none): Type enter
OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.
Set root password? [Y/n] y
New password: Your password (at least 12 caracteres with letters and special caracteres)
Re-enter new password: Your password (at least 12 caracteres with letters and special caracteres)
Password updated successfully!
Reloading privilege tables..
... Success!
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] Y
... Success!
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] Y
... Success!
By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n] Y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n] Y
... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!

Augmentez la taille du cache et des tampons InnoDB en modifiant ces valeurs :

vi /etc/mysql/mariadb.conf.d/50-server.cnf

[mysqld]
query_cache_limit       = 2M
query_cache_size        = 32M
innodb_buffer_pool_instances = 1
innodb_buffer_pool_size = 79M
[mariadb]
aria_pagecache_buffer_size = 2M

Enfin, redémarrez le service :

service mariadb restart

Configurer un site web sous LEMP

Maintenant que vous avons installé notre stack LEMP, nous allons pouvoir configurer notre premier site web en suivant ces étapes :

  1. Créer ou copier un site web
  2. Créer un dossier de logs
  3. Créer un hôte virtuel dans Nginx
  4. Activer cet hôte virtuel

1 – Créer ou copier un site web

Commençons par créer notre site. A des fins de simplification, nous utiliserons ici juste un fichier nommé index contenant tous les paramètres de notre configuration. Une fois celui créé, il faudra lui donner les droits d’accès et de modification à l’utilisateur www-data (utilisateur par défaut dans Nginx). Le plus simple est d’attribuer la propriété du dossier à cet utilisateur (nous sécuriserons d’avantage ces permissions dans la suite de cet article) :

mkdir /var/www/website

vi /var/www/website/index.php

<?php phpinfo(); ?>

chown www-data -R /var/www/website/

Ce fichier est un fichier sensible comprenant des informations interne à votre serveur. Ne laissez pas celui ci accessible après cette installation, et pensez bien à le supprimer une fois testé.

Si vous avez déjà un site que vous voulez copier, tapez la commande suivante :

cp -R website/ /var/www/

2 – Créer un dossier de logs

Ensuite, créons un dossier dans lequel tous les logs applicatifs (journaux d’accès et d’erreurs) seront stockés. De même que précédemment, attribuons sa propriété à l’utilisateur www-data :

mkdir /var/log/nginx/website/

chown -R www-data /var/log/nginx/website/

3 – Créer un hôte virtuel dans Nginx

Dans le cas où vous souhaitez utiliser un CMS, je vous recommande de suivre la procédure décrite dans mon article sur l’installation facile de WordPress en 3 étapes et de sauter ce paragraphe.

Tout d’abord, désactivons le site configuré par défaut dans Nginx :

unlink /etc/nginx/sites-enabled/default

Puis créons un hote virtuel minimal (nous l’améliorerons par la suite) pour simplement afficher notre site :

vi /etc/nginx/sites-available/www.website.com.conf

server {
 server_name www.website.com;
 listen 80;
 port_in_redirect off;
 access_log /var/log/nginx/website/access.log;
 error_log /var/log/nginx/website/error.log error;

 root /var/www/website/;
 index index.php;

 location ~ \.php$ {
  try_files $uri =404;
  include fastcgi_params;
  fastcgi_pass unix:/run/php/php7.0-fpm.sock;
  fastcgi_split_path_info ^(.+\.php)(.*)$;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 }
}

4 – Activer un hôte virtuel dans Nginx

Enfin, activons notre hôte et redémarrons Nginx :

ln -s /etc/nginx/sites-available/www.website.com.conf /etc/nginx/sites-enabled/www.website.com.conf

service nginx restart

Ajouter SSL à Nginx

1 – Présentation de SSL

SSL (et maintenant TLS) est un protocole destiné à sécuriser les connexions de vos visiteurs vers votre site web à l’aide de clefs privée et publique.

Pour plus d’informations sur SSL et TLS, consultez mon guide du débutant sur les certifcats SSL

2 – Créer des certificats

Nous utiliserons Let’s Encrypt pour nos certificats SSL. Si vous ne connaissez pas déjà cet outil, je vous conseille de lire mon guide ultime sur Let’s Encrypt.

apt install git

git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt --depth=1

cd /opt/letsencrypt/

service nginx stop

/opt/letsencrypt/letsencrypt-auto certonly --rsa-key-size 4096 --standalone -d www.website.com

service nginx start

3 – Renforcer la sécurité des certificats avec Diffie-Hellman

Diffie-Hellman est un outil permettant de renforcer la sécuritée de votre certificqt SSL. Il va compliquer le déchiffrement de vos transactions dans le cas où une personne tierce volera votre clef privée.

Nous ajouterons à la clef privée un chiffrement de 4096 bits contenu dqns un fichier tiers. Soyez patient, l’opération peut prendre plusieurs minutes, selon la puissance de votre serveur.

openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096

4 – Mettre à jour l’hôte virtuel

Maintenant que les certificats SSL sont générés, on peut les ajouter à notre configuration Nginx.

4.1 Ajouter les certificats SSL

vi /etc/nginx/sites-available/www.website.com.conf

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/www.website.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.website.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/www.website.com/chain.pem;

4.2 Ajouter la clef Diffie-Hellman

vi /etc/nginx/sites-available/www.website.com.conf

ssl_dhparam /etc/ssl/certs/dhparam.pem;

4.3 Indiquer les protocoles et chiffrements à utiliser

Il es fortement recommandés de n’utiliser que les dernières version de TLS et des chiffrements forts.

vi /etc/nginx/sites-available/www.website.com.conf

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers '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';
ssl_prefer_server_ciphers On;

4.4 OCSP Stapling

L’agraffage OCSP ets un mécanisme permettant de valider un certificat SSL, et de mettre en cache les informations de celui ci (notamment la date de fin de validité).

Pour chaque requête, une demande est faite auprès d’une authorité de certification pour valider le certificat fournit par le serveur. Ce mécanisme a deux principaux défauts, il surcharge les authorités de certification, mais surtout, cela créée une requête supplémentaire (et doit attendre de la réponse de celle ci), mais il informe également l’authorité de toutes les pages que vous visitez. L’aggraffage OCSP permet de mettre en cache la date de fin de validité du certificat durant la première transaction, donc plus besoin de valider les visites suivantes auprès d’une authorité de certification.

vi /etc/nginx/sites-available/www.website.com.conf

ssl_stapling on;
ssl_stapling_verify on;

4.5 Rediriger le traffic http vers https à l’aide de redirections 301

Maintenant que vous avez un site fonctionnel sous HTTPS, il vous faut rediriger les utilisateurs utilisant la version non sécurisée vers celle ci.

vi /etc/nginx/sites-available/www.website.com.conf

server {
 listen 80;
 server_name www.website.com;
 return 301 https://www.website.com$request_uri;
}

4.6 Configuration SSL complète

Voici la configuration complète de votre hôte virtuel après l’ajout de SSL :

vi /etc/nginx/sites-available/www.website.com.conf

server {
  server_name www.website.com;
  listen 443 ssl;
  ssl_protocols TLSv1.3 TLSv1.2;
  ssl_ciphers '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';
  ssl_prefer_server_ciphers On;
  ssl_certificate /etc/letsencrypt/live/www.website.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/www.website.com/privkey.pem;
  ssl_trusted_certificate /etc/letsencrypt/live/www.website.com/chain.pem;
  ssl_session_cache shared:SSL:128m;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;
  ssl_stapling on;
  ssl_stapling_verify on;
  port_in_redirect off;

  access_log /var/log/nginx/website/access.log;
  error_log /var/log/nginx/website/error.log error;

  root /var/www/website/;
  index index.php;

  location ~ \.php$ {
    try_files $uri =404;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    fastcgi_split_path_info ^(.+\.php)(.*)$;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
 }

server {
 listen 80;
 server_name www.website.com;
 return 301 https://www.website.com$request_uri;
}

Améliorer la sécurité de votre serveur LEMP

A ce stade, nous avons un serveur fonctionnel utilisant HTTPS. Avant de l’utiliser en production, nous devons augmenter la sécurité de celui ci et de notre système.

1 – Créer de nouveaux utilisateurs MariaDB

Une bonne pratique lors de l’utilisation de bases de données est de créer un nouvel utilisateur pour chaque application, avec des permissions se limitant à la base concernée.

N’utilisez jamais de compte administrateur dans vos applications, pour des raisons de sécurité évidentes. Si une de vos applications étaient compromises, toutes vos bases le seraient également.

Voici la procédure à suivre pour chaque nouvelle application web utilisant une base de données :

  1. Créer un nouvel utilisateur
  2. Créer une nouvelle base
  3. Accorder au nouvel utilisateur des permissions à la nouvelle base
  4. Recharger les privilèges

mysql -u root -p

CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'password';
CREATE DATABASE newbase;
GRANT ALL PRIVILEGES ON newbase.* TO 'newuser'@'localhost';
FLUSH PRIVILEGES;
QUIT;

2 – Définir les permissions des fichiers et dossiers

Le mieux pour gérer ses autorisations de fichiers et de créer un nouvel utilisateur système pour chaque application et attribuer les droits du dossier publique du site web à celui ci.

Cela limite la portée de l’accès en cas d’intrusion frauduleuse.

Cet utilisateur aura un accès complet au site, et l’utilisateur www-data de Nginx n’aura que des droits d’exécution :

adduser sysuser

chown sysuser:www-data -R /var/www/website/

chmod -R 710 -R /var/www/website/

3 – Changer la signature serveur de Nginx

La signature serveur de Nginx est un header ajouté par le serveur web indiquant le type et la version de Nginx utilisée. Celui ci est ajouté par défaut, ce qui permet à tous vos utilsateurs de savoir que vous utilisez Nginx, et quelle version de celui ci est installée.

Ceci est bien évidemment une information que nous voulons cacher.

Afin de la masquer, nous aurons besoin d’installer la version nginx-extras, à la place de la version nginx-full installée précédemment.

apt install -y nginx-extras

vi /etc/nginx/nginx.conf

http {
  more_set_headers "Server: Webserver";
  server_tokens off;
}

4 – Ajouter des headers de sécurité dans Nginx

4.1 Strict-Transport-Security

HSTS (HTTP Strict Transport Security) est un mécanisme indiquant aux navigateurs d’utiliser HTTPS dans leurs connexions au server. Il indique également un laps de temps dans lequel les navigateurs refuseront toute connexion non HTTPS vers votre site web.

HSTS limite les attaques protocol downgrade et cookie hijacking.

vi /etc/nginx/sites-available/www.website.com.conf

add_header Strict-Transport-Security "max-age=31557600; includeSubDomains";

4.2 Content-Security-Policy

CSP (Content Security Policy) permet de définir les origines des ressources chargées sur votre site web.

CSP limite les attaques cross-site-scripting (XSS), clickjacking et code injections.

vi /etc/nginx/sites-available/www.website.com.conf

add_header Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline';";

4.3 X-XSS-Protection

XSS Protection est un filtre utilisé uniquement sous IE8. Il force la fonctionnalitée de protection XSS du navigateur.

XSS Protection empêche les attaques cross-site-scripting.

vi /etc/nginx/sites-available/www.website.com.conf

add_header X-Xss-Protection "1";

4.4 X-Frame-Options

Frame options permet de préciser si vous autorisez ou non les navigateurs à afficher le contenu de votre page dans un frame, un iframe ou un object html.

Frame Options empêche les attaques clickjacking et protège l’utilisation de votre contenu.

vi /etc/nginx/sites-available/www.website.com.conf

add_header X-Frame-Options "SAMEORIGIN" always;

4.5 X-Content-Type-Options

Content type options force les navigateurs à utiliser le type mime fournit dans vos réponses, sans chercher à le deviner eux même selon le contenu renvoyé.

Content type options empêche les attaques mime type sniffing.

vi /etc/nginx/sites-available/www.website.com.conf

add_header X-Content-Type-Options "nosniff" always;

4.6 Referrer-Policy

Referrer policy vous permet d’indiquer ou non aux sites tiers l’origine de votre site en cas de clics sur des liens externes.

vi /etc/nginx/sites-available/www.website.com.conf

add_header Referrer-Policy strict-origin-when-cross-origin;

5 – Interfaces web d’administration de bases de données

Je vous recommende fortement de ne jamais installer Phpmyadmin sur votre serveur. Il permet un accès direct à votre base de données, qui pourraient être utilisé à des fins malicieuses.

Cependant si vous voulez une interface web d’aministration, lisez ces conseils :

  1. Préférez un outil sans installation, comme adminer. Vous aurez plus de fonctionnalités disponibles, et vous pourrez l’utiliser depuis un poste client.
  2. Dans le cas ou vous avez besoin de Phpmyadmin, installez le sur un serveur différent, avec un autre nom de domaine.
  3. Changez l’url d’accès, comme /pma/ au lieu de /phpmyadmin/

Améliorer les performances de votre serveur LEMP

1 – Activer HTTP2

1.1 Qu’est ce que HTTP2

HTTP2 est l’évolution du fameux protocole HTTP (HyperText Transfert Protocole). Il est sorti en 2015, soit 18 ans après la dernière mise à jour (HTTP 1.1 datant de 1997) par l’IETF (Internet Engineering Task Force). Il est basé sur le protocole SPDY, développé par Goole quelques années plus tôt, et depuis abandonné.

HTTP2 apporte de nouvelles fonctionnalités autour de la sécurité et des performances :

  1. Compression des headers HTTP
  2. Cumul des requêtes dans une seule connexion
  3. Push server et notifications
  4. Requiert TLS à partir de la version 1.2

Les gains de performaces sont assez significatifs, pouvant aller jusqu’à 50 de temps de chargement plus rapide (mesuré sur un site utilisant WordPress).

1.2 Installer HTTP2 dans Nginx

  1. Tout d’abord, vous devez vous assurer que SSL est activé avec le protocole TLS 1.2 ou 1.3 (voir les chapitres précédents)
  2. Ensuite, éditez votre hôte virtuel et changez le numéro du port d’écoute, en précisant http2
  3. Finalement, redémarrez Nginx

vi /etc/nginx/sites-available/www.website.com.conf

listen 443 ssl http2;

service nginx restart

2 – Activer la compression GZIP

2.1 Qu’est ce que la compression GZIP

GZIP est un module qui compresse les données envoyées par le serveur au client. Au lieu d’envoyer un text brut, qui serait volumineux, il compresse les données pour en réduire la taille et le temps de transfert. Le navigateur web recevra le fichier et le décompressera, afin de rendre l’opération plus rapide.

2.2 Configurer Nginx avec la compression GZIP

vi /etc/nginx/sites-available/www.website.com.conf

gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 265;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

3 – Mettez vos ressources en cache

3.1 Qu’est ce que le cache de ressources

Cacher les ressources permet aux navigateurs web mettre en cache certains éléments et de ne plus envoyer de requêtes pour ceux ci. Tous les pages de votre site ont certaines ressources en commun (comme votre logo, vos polices de caractères, etc). Cette option permet donc de ne plus télécharger ces éléments pour chaque page, mais de les mettre en cache pour les réutiliser depuis un téléchargement précédent. Cela augmente considérablement la vitesse de chargement d’une page.

3.2 Activer le cache de ressources dans Nginx

vi /etc/nginx/sites-available/www.website.com.conf

location ~*.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|cur)$ {
  expires max;
  log_not_found off;
  access_log off;
}

4 – Hôte virtuel au complet

vi /etc/nginx/sites-available/website

server {
  server_name www.website.com;
  listen 443 ssl http2;
  ssl_protocols TLSv1.3 TLSv1.2;
  ssl_ciphers '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-$
  ssl_prefer_server_ciphers On;
  ssl_certificate /etc/letsencrypt/live/www.website.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/www.website.com/privkey.pem;
  ssl_trusted_certificate /etc/letsencrypt/live/www.website.com/chain.pem;
  ssl_session_cache shared:SSL:128m;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;
  ssl_stapling on;
  ssl_stapling_verify on;
  port_in_redirect off;

  add_header Strict-Transport-Security "max-age=31557600; includeSubDomains";
  add_header Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline';";
  add_header X-Xss-Protection "1";
  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header Referrer-Policy strict-origin-when-cross-origin;

  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_min_length 265;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  access_log /var/log/nginx/website/access.log;
  error_log /var/log/nginx/website/error.log error;

  root /var/www/website/;
  index index.php;

  location ~ \.php$ {
    try_files $uri =404;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    fastcgi_split_path_info ^(.+\.php)(.*)$;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  }

  location ~*.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|cur)$ {
    expires max;
    log_not_found off;
    access_log off;
  }

}

server {
  listen 80;
  server_name www.website.com;
  return 301 https://www.website.com$request_uri;
}