WordPress est un système de gestion de contenu (CMS) qui permet de créer et gérer différents types de sites Internet : blog, site e-commerce, site vitrine ou encore portfolio.
Gratuit et libre, WordPress possède de nombreux avantages tels que sa simplicité d'utilisation et d'administration, sa facilité d’indexation dans les moteurs de recherche, une personnalisation importante grâce à de nombreux plugins disponibles et une communauté WordPress très active.
WordPress a besoin d'un serveur web (Nginx), de PHP, d'une interface permettant la communication entre le serveur web et PHP (PHP-FPM) et d'une base de données (MariaDB). Nous améliorerons les performances de WordPress grâce à OPCache et sécuriserons les échanges grâce à un certificat SSL/TLS délivré par Let's Encrypt.
1 - Prérequis
- Vous devez disposer d'Ubuntu 22.04. Si vous disposez d'une version antérieure, vous pouvez mettre à jour votre système en suivant cette procédure.
- Votre utilisateur doit avoir accès à sudo.
2 - WordPress avec Nginx
Notre choix se portera sur le serveur HTTP Nginx pour une question de performances. Nginx est reconnu pour ses hautes performances, sa stabilité, son ensemble de fonctionnalités, sa configuration simple ainsi que sa faible consommation en ressources.
2.1 - Installation de Nginx
Installez le paquet nginx :sudo apt-get -y install nginx2.2 - Configuration de Nginx
Modifiez les directives suivantes du fichier de configuration Nginx /etc/nginx/nginx.conf :user www-data;
worker_processes 8;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
...
-
worker_processes : afin de profiter pleinement de la puissance de votre serveur, il est recommandé de mettre autant de worker_processes que de cœurs disponibles sur votre serveur. Pour connaître le nombre de cœurs sur votre serveur, il suffit de lancer la commande :
grep processor /proc/cpuinfo | wc -l 8 - server_tokens : pour des raisons de sécurité, il est recommandé de désactiver l'envoi d'informations telles que le numéro de version de votre Nginx. Pour cela, décommentez cette directive dans le bloc http.
3 - Installation et téléchargement de WordPress
-
Déplacez-vous dans le répertoire /var/www et téléchargez la dernière version française de WordPress :
cd /var/www sudo wget http://fr.wordpress.org/latest-fr_FR.tar.gz -
Décompressez l'archive :
sudo tar -xzvf latest-fr_FR.tar.gz -
Dans la suite du tutoriel, le site WordPress sera nommé blog. Libre à vous de le modifier par un nom court et explicite. Renommez le dossier wordpress :
sudo mv wordpress blog -
Supprimez l'archive téléchargée :
sudo rm latest-fr_FR.tar.gz
4 - Droits Unix : un utilisateur dédié WordPress
Lors du déploiement basique d’un serveur HTTP, l’utilisateur sous lequel fonctionne ce serveur (Apache, Nginx...) est la plupart du temps www-data, nobody ou apache. Cela signifie que si plusieurs sites existent sous la même instance de Nginx, tous utilisent le même utilisateur. Or si l’un des sites s’avère corrompu par un utilisateur malveillant alors l’assaillant peut profiter pleinement de tous les droits de l’utilisateur sous lequel tourne le serveur web. Tous les sites s'avèrent donc vulnérables.
Pour des raisons évidentes de sécurité, il est donc recommandé de cloisonner ces utilisateurs et d'avoir un utilisateur dédié à la gestion du dossier blog. Cet utilisateur aura des droits aussi restreints que possible à ce répertoire.
Nous allons donc modifier le propriétaire du répertoire /var/www/blog et l'attribuer à un nouvel utilisateur dédié : blog.
Par ailleurs, Nginx est lancé sous l'utilisateur www-data et doit avoir accès en lecture au répertoire /var/www/blog pour lire les ressources statiques (HTML, CSS, JS, etc.). Nous allons donc attribuer le répertoire /var/www/blog au groupe www-data.
Enfin nous retirerons toutes les permissions de ce répertoire aux autres utilisateurs.
-
Créez un utilisateur blog :
sudo adduser blog -
Modifiez le propriétaire et le groupe du répertoire /var/www/blog :
sudo chown -R blog:www-data /var/www/blog -
Retirez toutes les permissions aux autres utilisateurs :
sudo chmod -R o-rwx /var/www/blog
5 - PHP et ses modules
WordPress nécessite certains modules PHP pour fonctionner :- PHP PDO : connecteur pour MariaDB
- PHP CURL : nécessaire pour certains plugins
- PHP GD : opérations sur les images
- PHP INTL : support de l'internationalisation.
sudo apt-get -y install php-cli php-mysql php-curl php-gd php-intl6 - PHP-FPM
Le module PHP-FPM permet la communication entre le serveur Nginx et PHP, basée sur le protocole FastCGI. Ce module, écoutant sur le port 9000 par défaut ou sur un socket UNIX, permet notamment l'exécution de scripts PHP dans un processus indépendant de Nginx avec des UID et GID différents. Il sera alors possible, dans le cas de la gestion de plusieurs applications sur un même serveur, de créer et configurer un groupe (appelé aussi pool) par application. Un pool définit notamment le UID/GID des processus PHP et le nombre de processus minimum, maximum ou encore le nombre de processus en attente à lancer.
6.1 - Installation
Installez le paquet php-fpm :sudo apt-get install -y php-fpm6.2 - Création du pool blog
Créez le pool dédié à WordPress en créant le fichier de configuration suivant : /etc/php/7.4/fpm/pool.d/blog.conf[blog]
listen = /var/run/blog.sock
listen.owner = blog
listen.group = www-data
user = blog
group = www-data
pm = ondemand
pm.max_children = 10
pm.process_idle_timeout = 60s
pm.max_requests = 500Certaines valeurs sont très arbitraires et seront, en fonction des ressources disponibles sur votre serveur et celles que vous souhaiterez dédier à votre WordPress, différentes d'une configuration à l'autre. Cependant ces différentes directives respectent certaines conditions :
- [blog] : nom du pool. Il est possible de créer plusieurs pools par fichier. Chaque pool doit commencer par cette directive.
- listen : interface d'écoute des requêtes. Les syntaxes acceptées sont ADRESSE_IP:PORT (exemple :
listen = 127.0.0.1:9000) et /path/to/unix/socket (exemple :listen = /var/run/blog.sock). Le socket est représenté comme un simple fichier sur le système et permet d’interfacer des processus entre eux sans passer par la couche réseau du système, ce qui est inutile lorsque Nginx et PHP-FPM sont hébergés sur le même serveur. Je vous conseille donc d'utiliser un socket. - listen.owner & listen.group : affecte l'utilisateur et le groupe au socket Unix si utilisé. Ces deux paramètres peuvent être associés au paramètre listen.mode qui définit les permissions du socket (660 par défaut). Il est important que Nginx ait les droits de lecture sur le socket Unix.
- user & group : utilisateur et groupe sous lesquels le pool de processus sera exécuté. Cet utilisateur et ce groupe doivent bien sûr exister sur votre système et surtout accéder aux fichiers PHP de votre WordPress. Cela veut dire aussi que chaque fichier et répertoire créé dans WordPress appartiendra à cet utilisateur et à ce groupe. Comme nous l'avons vu dans le chapitre dédié aux droits Unix, chaque fichier devra appartenir à l'utilisateur blog et au groupe www-data.
- pm : directive acceptant les 3 valeurs suivantes : static, dynamic et ondemand.
- static : les processus, au nombre de pm.max_children, sont continuellement actifs (quelle que soit la charge et l'affluence de votre WordPress) et sont susceptibles de consommer de la mémoire inutilement. Cette directive est recommandée si WordPress est l'unique application de votre serveur.
- dynamic : le nombre de processus fils pourra varier suivant la charge. Cependant, nous gardons le contrôle sur le nombre de processus fils à créer au démarrage du serveur, le nombre de processus maximum, en attente de requêtes, etc. Les directives suivantes deviennent obligatoires : pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers. Cette directive est recommandée si vous avez plusieurs pools avec un fort trafic (plus de 10 000 requêtes/jour).
- ondemand : aucun processus fils n'est lancé au démarrage du serveur, les processus s'activent à la demande et auront une durée de vie définie par la directive pm.process_idle_timeout. L'intérêt de cette directive est de libérer de la mémoire en cas de faible charge mais celle-ci peut légèrement augmenter le temps de réponse de votre WordPress. Cette directive est recommandée si vous avez plusieurs pools avec potentiellement une faible affluence.
Nous choisirons et détaillerons ici la directive ondemand qui présente l'avantage de créer des processus en fonction de la demande et de libérer des ressources sur le serveur lors de période de faible affluence.
- pm.max_children : nombre maximum de processus fils. La valeur du paramètre pm.max_children varie d'un système à l'autre. Voici la procédure à réaliser pour déterminer la valeur de ce paramètre :
-
Arrêtez le service php-fpm :
sudo systemctl stop php7.4-fpm.service -
Affichez la mémoire disponible (colonne available) sur votre système :
free -m total used free shared buff/cache available Mem: 3913 58 2532 39 1322 3539 Swap: 1048 0 1048Sur cet exemple, le système dispose de 3539Mo de RAM disponible. La quantité de RAM que vous souhaitez allouer au maximum à WordPress dépend de vous et des autres services actifs que vous disposez sur ce même système. Dans notre exemple, nous partirons du principe que nous souhaitons allouer au maximum 1Go (1000Mo) de RAM à WordPress.
-
Affichez la mémoire utilisée par un processus fils php-fpm :
sudo systemctl start php7.4-fpm.service && ps --no-headers -o "rss,cmd" -C php-fpm7.4 | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }' 18M -
Déterminez le nombre de pm.max_children en appliquant la méthode de calcul suivante :
pm.max_children = mémoire allouée (en Mo) / mémoire utilisée par un processus fils
Dans notre exemple : 1000 / 18 = 55 -
Éditez à nouveau le fichier /etc/php/7.4/fpm/pool.d/blog.conf et ajustez la valeur du paramètre pm.max_children :
[blog] listen = /var/run/blog.sock listen.owner = blog listen.group = www-data user = blog group = www-data pm = ondemand pm.max_children = 55 pm.process_idle_timeout = 60s pm.max_requests = 500
-
Arrêtez le service php-fpm :
- pm.process_idle_timeout : durée en secondes avant qu'un processus fils inactif soit détruit.
- pm.max_requests : nombre de requêtes que chaque processus fils devra exécuter avant d'être détruit. Cette valeur ne doit pas être trop élevée afin de contourner d'éventuelles fuites mémoires, ni trop faible pour ne pas solliciter régulièrement le CPU à chaque création de processus fils. 500 reste une valeur recommandée.
sudo systemctl restart php7.4-fpm.service7 - Création de la base de données WordPress sous MariaDB
7.1 - Installation de MariaDB
Installez les paquets suivants :sudo apt-get install -y mariadb-server mariadb-client7.2 - Configuration de MariaDB
Lancez le script de configuration (recommandé) :sudo 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): [Touche Entrée]
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:
Re-enter new password:
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!7.3 - Création de la base de données blog
-
Tout d'abord, connectez-vous sur l'interface MySQL avec l'utilisateur root et grâce au mot de passe saisi lors de la configuration de MariaDB :
sudo mysql -u root -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 49 Server version: 10.3.22-MariaDB-1ubuntu1 Ubuntu 20.04 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. -
Créez la base de données blog :
Tout comme pour la gestion du répertoire blog et pour plus de sécurité, vous allez tout d'abord créer un utilisateur MySQL blog dédié à la base de données blog, renseigner un mot de passe et ensuite lui donner les droits sur cette base de données :CREATE DATABASE blog; Query OK, 1 row affected (0.00 sec)CREATE USER "blog"@"localhost"; Query OK, 0 rows affected (0.00 sec) SET password FOR "blog"@"localhost" = password('mon_password'); Query OK, 0 rows affected (0.00 sec) GRANT ALL PRIVILEGES ON blog.* TO "blog"@"localhost" IDENTIFIED BY "mon_password"; Query OK, 0 rows affected (0.00 sec) FLUSH PRIVILEGES; Query OK, 0 rows affected (0.00 sec) EXIT; Bye
8 - Nom de domaine & virtual host
ⓘ Si vous souhaitez accéder à votre WordPress de l'extérieur (et non seulement via localhost), il est nécessaire de faire pointer votre domaine ou sous-domaine vers l'IP de votre serveur. Pour cela, commencez par modifier les règles DNS dans l'interface administrateur du fournisseur de votre nom de domaine.
-
Créez le fichier suivant /etc/nginx/sites-available/blog et modifiez les lignes en surbrillance en fonction de votre configuration :
upstream php-wp { server unix:/var/run/blog.sock; } server { listen 80; listen [::]:80; server_name blog.mondomaine.com; root /var/www/blog; index index.php; location / { try_files $uri $uri/ /index.php?$args; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location ~ .php$ { include fastcgi.conf; fastcgi_pass php-wp; } location ~* .(js|css|png|jpg|jpeg|gif|ico)$ { expires max; log_not_found off; } } -
Activez le virtual host :
sudo ln -s /etc/nginx/sites-available/blog /etc/nginx/sites-enabled/blog -
La nouvelle configuration sera prise en compte après redémarrage du service Nginx :
sudo systemctl restart nginx.service
9 - SSL/TLS avec Let's Encrypt
Let's Encrypt est une autorité de certification libre, automatisée et ouverte. Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique SSL/TLS au moyen d'un processus automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l'installation et le renouvellement des certificats pour la sécurisation des sites internet. Depuis sa création, Let's Encrypt a livré plus d'un milliard de certificats.
9.1 - Installation
Installez les paquets software-properties-common et certbot :sudo apt-get install -y software-properties-common
sudo apt-get install -y certbot9.2 - Génération des certificats
Let's Encrypt permet de générer de différentes façons plus ou moins automatisées un certificat. La méthode standalone permet de générer simplement un certificat. En revanche, celle-ci demande d'arrêter le serveur Nginx et ceci est valable à chaque renouvellement dudit certificat. Il existe aussi des plugins Apache et Nginx entièrement automatisés. Ces plugins mettent à jour automatiquement la configuration des virtual hosts. Dans cet article, nous recommandons d'utiliser le plugin webroot pour Nginx qui permet de générer et renouveler son certificat sans interrompre le serveur Nginx.
Le plugin webroot crée un fichier temporaire /var/www/blog/.well-known/acme-challenge dans le dossier racine de votre WordPress, celui-ci permettra aux serveurs de Let's Encrypt de valider votre certificat en appelant ce fichier temporaire.
- Générez votre certificat en remplaçant [email protected] et mondomaine.com par vos informations personnelles :
Vous obtiendrez 4 fichiers dans le répertoire /etc/letsencrypt/live/blog.mondomaine.com :sudo certbot certonly --webroot -w /var/www/blog --agree-tos --no-eff-email --email [email protected] -d blog.mondomaine.com --rsa-key-size 4096 Saving debug log to /var/log/letsencrypt/letsencrypt.log Obtaining a new certificate Performing the following challenges: http-01 challenge for blog.mondomaine.com Using the webroot path /var/www/blog for all unmatched domains. Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/blog.mondomaine.com/fullchain.pem. Your cert will expire on 20XX-XX-XX. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le- cert.pem : le certificat de votre domaine blog.mondomaine.com
- chain.pem : le certificat Let's Encrypt
- fullchain.pem : les certificats cert.pem et chain.pem combinés
- privkey.pem : la clé privée du certificat.
-
SSL/TLS utilise un système de chiffrement asymétrique (comme RSA ou Diffie-Hellman) afin de sécuriser les échanges de vos flux. Par défaut, Nginx utilise une clé de 1048 bits. En augmentant la longueur de la clé à 4096 bits, vous augmenterez ainsi la sécurité de votre protocole SSL/TLS.
Générez une nouvelle clé Diffie-Hellman (DH) de 4096 bits et attribuez-lui un minimum de permissions :
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096 sudo chmod 600 /etc/ssl/certs/dhparam.pem -
Ajoutez les lignes en surbrillance dans votre virtual host (/etc/nginx/sites-available/blog) en remplaçant les chemins des directives ssl_certificate, ssl_certificate_key, ssl_trusted_certificate et ssl_dhparam par l'emplacement de vos certificats :
upstream php-wp { server unix:/var/run/blog.sock; } server { listen 80; listen [::]:80; server_name blog.mondomaine.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name blog.mondomaine.com; root /var/www/blog; index index.php; ssl_certificate /etc/letsencrypt/live/blog.mondomaine.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/blog.mondomaine.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/blog.mondomaine.com/chain.pem; ssl_dhparam /etc/ssl/certs/dhparam.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers 'kEECDH+ECDSA+AES128 kEECDH+ECDSA+AES256 kEECDH+AES128 kEECDH+AES256 kEDH+AES128 kEDH+AES256 DES-CBC3-SHA +SHA !aNULL !eNULL !LOW !kECDH !DSS !MD5 !EXP !PSK !SRP !CAMELLIA !SEED'; ssl_ecdh_curve secp384r1; ssl_session_cache shared:SSL:1m; ssl_session_timeout 1440m; ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 8.8.4.4; add_header Strict-Transport-Security max-age=31536000; location / { try_files $uri $uri/ /index.php?$args; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location ~ .php$ { include fastcgi.conf; fastcgi_pass php-wp; } location ~* .(js|css|png|jpg|jpeg|gif|ico)$ { expires max; log_not_found off; } } -
Rechargez votre configuration Nginx :
sudo systemctl reload nginx.service
9.3 - Renouvellement automatique du certificat
Les certificats délivrés par Let's Encrypt sont valides 90 jours. Une tâche planifiée permettant de renouveler l'ensemble des certificats présents sur votre serveur est fournie avec le paquet certbot. Celle-ci est exécutée deux fois par jour et les renouvelle si et seulement si vos certificats expirent dans un délai inférieur à 30 jours.
-
Testez si le renouvellement automatique est fonctionnel avec la commande suivante :
sudo certbot renew --dry-run
10 - Configuration de WordPress
Lancez votre navigateur et rendez-vous à l'adresse suivante : https://blog.mondomaine.com/.
-
Lancez la configuration :
- Cliquez sur C'est parti !
-
Renseignez les informations de votre base de données :
- Renseignez le nom de votre base de données blog
- Rensseignez l'utilisateur de votre base de données blog
- Renseignez le mot de passe de votre base de données
- La base de données étant sur la même machine, renseignez localhost
- Cliquez sur Envoyer
-
Lancez l'installation :
- Cliquez sur Lancer l'installation
-
Renseignez les informations générales de votre blog :
- Renseignez un titre pour votre site WordPress
- Choisissez un identifiant pour le compte administrateur
- Choisissez un mot de passe pour le compte administrateur
- Renseignez votre email
- Cliquez sur Installer WordPress
11 - Améliorer les performances de votre WordPress côté serveur
OPcache (qui signifie Optimizer Plus Cache) est introduit depuis la version 5.5.0 de PHP. Il sert à cacher l'opcode de PHP, c’est-à-dire les instructions de bas niveau générées par la machine virtuelle PHP lors de l’exécution d’un script. Autrement dit, le code pré-compilé est stocké en mémoire. Cela évite ainsi l'étape de compilation à chaque requête PHP. De plus, OPcache va optimiser l'exécution du code afin d'en améliorer les performances.
-
Éditez le fichier /etc/php/7.4/fpm/php.ini, décommentez et modifiez les lignes suivantes dans la section [opcache] :
[opcache] opcache.enable=1 opcache.enable_cli=1 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=10000 opcache.revalidate_freq=1 opcache.save_comments=1 -
La nouvelle configuration sera prise en compte après redémarrage du service PHP-FPM :
sudo systemctl restart php7.4-fpm.service
12 - Améliorer la sécurité de votre WordPress
Les tentatives de piratages sur les sites WordPress sont nombreuses. Le plus souvent, ces attaques sont de type brute force sur votre page de connexion WordPress. Développé en langage Python, Fail2Ban est un outil permettant d'analyser des fichiers de logs et de déclencher des actions si certaines choses suspectes sont détectées. Fail2ban est capable de détecter des connexions non autorisées et de bannir (via iptables) l'adresse IP de l'attaquant. Les attaques de type brute force (tests de différentes combinaisons nom d'utilisateur / mot de passe) seront ainsi bloquées.
Fail2Ban se base sur un système de prisons (jails) que l'on peut définir, activer ou désactiver dans un simple fichier de configuration.
Fail2ban écoutera les logs générés par WordPress. Si Fail2ban détecte plus de 3 tentatives d'accès frauduleuses provenant d'une même IP sur la page de login, celui-ci bloquera automatiquement cette IP pour une durée que nous préciserons dans le fichier de configuration.
-
Installez le paquet fail2ban :
sudo apt-get -y install fail2ban -
Créez le filtre /etc/fail2ban/filter.d/wordpress.conf et ajoutez les lignes suivantes :
[Definition] failregex = ^<HOST> .* "(GET|POST) /wp-login.php ^<HOST> .* "(GET|POST) /xmlrpc.php -
Créez le jail /etc/fail2ban/jail.local dédié à votre site WordPress et ajoutez les lignes suivantes :
Avec cette configuration, une machine sera bloquée pendant 60min (3600 secondes) au bout de 3 tentatives de connexion échouées.[wordpress] enabled = true port = 80,443 protocol = tcp filter = wordpress maxretry = 3 bantime = 3600 logpath = /var/log/nginx/access.log -
Redémarrez le service fail2ban :
sudo systemctl restart fail2ban.service
Vous pourrez vérifier périodiquement les IP bloquées dans le fichier de log de Fail2ban : /var/log/fail2ban.log.
WordPress sur Android...
Découvrez l'excellente application WordPress qui vous permettra de créer et de découvrir du contenu sur votre mobile. Rédigez, éditez, et publiez des articles sur votre site, accédez à vos stats et inspirez vous d'articles à partir de vos blogs favoris.
Ubuntu Server 20.04 LTS
Edouard WATTECAMPS