Que signifient les requêtes lentes SELECT GET_LOCK() sur ci_sessions ?

La table ci_sessions est destiné à stocker les sessions des visiteurs d’un site CodeIgniter. Celle-ci est notamment utilisée quand la session driver est configuré sur database.

Elle permet à CodeIgniter de stocker les informations de sessions de chaque visiteur dans la base de données. Selon les cas, cela peut présenter un avantage ou un désavantage.

Pourquoi la requête SELECT GET_LOCK() est lente ?

En vérité, la requête en elle-même n’est pas lente. Elle est juste suspendue pendant la période de verrouillage. En effet, cette requête fait justement ce qu’il est censé faire : verrouiller la session durant le chargement d’une page.

La constatation de lenteur survient lorsque la requête a été initiée alors qu’un autre chargement de page est en cours : il attend alors que l’autre page ait fini de charger pour obtenir à son tour le verrou sur la table de session.

Vous constaterez alors une entrée de ce type dans votre fichier log slow queries dans MySQL :

# User@Host: codeigniter[codeigniter] @ localhost [127.0.0.1]
# Thread_id: 12345  Schema: codeigniter  QC_hit: No
# Query_time: 22.040801  Lock_time: 0.000000  Rows_sent: 1  Rows_examined: 0
# Rows_affected: 0  Bytes_sent: 70
SET timestamp=xxxxxxxxxx;
SELECT GET_LOCK('653407ce5dddb2b0745d76a5f6dc73c0', 300) AS ci_session_lock;

Comment éviter que la requête SELECT GET_LOCK() empêche le chargement simultané des pages ?

Si vous souhaitez permettre à un utilisateur de charger simultanément plusieurs pages, vous devriez songer à utiliser un autre système de stockage de session qui vous permet un accès simultané à celui-ci.

Le plus simple est de basculer sur un stockage de session par fichiers. Pour cela, ajustez les paramètres suivants dans votre fichier de configuration CodeIgniter :

$config['sess_driver'] = 'files'; // was previously 'database'
$config['sess_save_path'] = sys_get_temp_dir();

Vous pouvez également envisager d’utiliser d’autres systèmes de stockage de sessions telles que Memcached ou Redis, notamment si votre application requiert un système de session centralisée.

Pourquoi les plugins WordPress désactivent le cache navigateur des pages HTML ?

WP Fastest Cache n’est pas le seul à le faire. Selon les plugins, la manipulation des headers Expires, Cache-Control et autres leur permettent de forcer le navigateur à faire une requête HTTP au serveur, et ainsi éviter que le navigateur ait des données obsolètes.

Cependant, puisque Varnish utilise aussi ces en-têtes HTTP pour prendre des décisions de mise en cache, cela désactive systématiquement le cache Varnish en marquant ces requêtes comme « uncacheable ».

En plus, les plugins comme WP Fastest Cache intègrent un mécanisme de purge de Varnish, ce qui permet donc de supprimer immédiatement les données de cache obsolètes sur Varnish, sans attendre que le cache expire.

Comment forcer la mise en cache ?

Il faut décomposer le problème en deux. D’abord, il faut marquer les réponses HTTP concernées pour éviter qu’on puisse forcer la mise en cache partout. Cela se fera au niveau d’Apache. Ensuite, il faudra détecter ce marquage au niveau de Varnish pour forcer la mise en cache.

Marquer les réponses HTTP servis depuis le cache WP Fastest Cache

WP Fastest Cache utilise mod_rewrite pour réécrire les URL vers les fichiers HTML préenregistrés dans le cache. Cela tombe bien, Apache sait ajouter des en-têtes HTTP selon la correspondance de dossier.

Dans votre VirtualHost (typiquement dans /etc/apache2/sites-available/domaine.com), ajoutez la directive suivante pour ajouter un header aux réponses servies depuis le dossier de cache de WP Fastest Cache :

<Directory ~ "wp\-content\/cache\/all(\/.*)*\/index\.html$">
    Header set Edge-Cache-Platform "wpfastestcache"
</Directory>

Redémarrez Apache ensuite :

systemctl restart apache2

À partir de ce moment, si vous faites une requête HTTP sur votre site et que la réponse est en cache par WP Fastest Cache, vous pourriez voir l’en-tête « Edge-Cache-Platform » (que vous pouvez d’ailleurs ajuster avec un autre nom, si vous souhaitez) :

$ curl -I http://www.exemple.com
HTTP/2 200
date: Sat, 01 Jun 2024 08:21:04 GMT
content-type: text/html; charset=UTF-8
server: nginx
vary: User-Agent,Accept-Encoding
last-modified: Fri, 31 May 2024 09:16:26 GMT
edge-cache-platform: wpfastestcache
cache-control: max-age=0, no-cache, no-store, must-revalidate
pragma: no-cache
expires: Mon, 29 Oct 1923 20:30:00 GMT
age: 0
accept-ranges: bytes
edge-cache-status: MISS

Détecter le marquage et appliquer les caches

Maintenant, dans votre VCL, ajoutez ceci dans la subroutine vcl_backend_response :

sub vcl_backend_response {
    if (beresp.ttl < 86400s && beresp.http.Content-Type ~ "text/html" && beresp.http.Edge-Cache-Platform ~ "wpfastestcache") {
        set beresp.ttl = 86400s;
        set beresp.grace = 86400s;
        return(deliver);
    }
}

Ceci détecte le header et le TTL (durée de validité du cache), et force celui-ci à 86 400 secondes (une journée) si elle est inférieure.

Notez également la présence de return(deliver), celui-ci est en place afin que le built-in VCL de Varnish n’entre pas en action si la requête correspond aux conditions du if. En effet, le built-in VCL va réajuster le TTL à 120s et le beresp.uncacheable = true si elle est exécutée, à cause des headers Cache-Control et autres.

Maintenant, la requête est bien mis en cache :

$ curl -I http://www.exemple.com
HTTP/2 200
date: Sat, 01 Jun 2024 08:26:04 GMT
content-type: text/html; charset=UTF-8
content-length: 85497
server: nginx
vary: User-Agent,Accept-Encoding
last-modified: Fri, 31 May 2024 09:16:26 GMT
edge-cache-platform: wpfastestcache
cache-control: max-age=0, no-cache, no-store, must-revalidate
pragma: no-cache
expires: Mon, 29 Oct 1923 20:30:00 GMT
age: 300
accept-ranges: bytes
edge-cache-status: HIT

Vous pouvez éventuellement décider de supprimer l’en-tête de réponse HTTP Edge-Cache-Platform au niveau de Varnish dans le if précédemment proposé, si vous souhaitez que cette information ne soit pas publique.

Dans les prémices des certificats SSL gratuits, cPanel n’avait pas proposé une intégration avec le service Let’s Encrypt qui est, jusqu’à maintenant, le service le plus populaire pour ce type de besoin. Pour palier à ce manque, FleetSSL a été créé. Ce plugin cPanel gère le processus complet de la création et de l’installation des certificats SSL avec le service Let’s Encrypt.

Aujourd’hui, cPanel a (enfin) intégré nativement Let’s Encrypt dans son outil nommé AutoSSL. Et comme FleetSSL est désormais un outil abandonné, il est intéressant de rebasculer sur AutoSSL.

Désinstallation de FleetSSL

Pour désinstaller FleetSSL, rien de plus simple. Dans le terminal root de votre serveur cPanel, désinstallez tout simplement le package :

yum -y remove letsencrypt-cpanel

À noter que sur la version 0.6.1 spécifiquement, la désinstallation peut échouer en raison d’un bug dans le script de désinstallation intégré. Dans ce cas précis, il va falloir le désinstaller manuellement :

rpm -e --justdb letsencrypt-cpanel-0.6.1-1

Remarque : la désinstallation de FleetSSL ne supprime pas les certificats SSL créés avec celui-ci. Les paramètres utilisateurs et paramètres systèmes sont également préservés, chose que vous pouvez supprimer manuellement :

/home/*/.cpanel/nvdata/letsencrypt-cpanel
/etc/letsencrypt-cpanel.conf
/etc/letsencrypt-cpanel.licence

Activation de Let’s Encrypt dans AutoSSL

Vous pouvez configurer Let’s Encrypt comme fournisseur de certificat SSL dans WHM > SSL/TLS > Manage AutoSSL si ce n’est pas déjà le cas.

Si Let’s Encrypt ne figure pas sur la liste, il sera nécessaire de l’installer manuellement avec la commande suivante :

/usr/local/cpanel/scripts/install_lets_encrypt_autossl_provider

Mettre à jour les certificats SSL

Une fois AutoSSL configuré, vous pouvez cliquer sur « Run AutoSSL for all users » pour exécuter AutoSSL. Ceci permettra d’anticiper le remplacement des certificats SSL Let’s Encrypt créé par FleetSSL qui sont proches de la date d’expiration.

1. Créer des index sur les tables. Sélectionner les colonnes plus utilisées avec WHERE et les indexer.
2. Utiliser la fonction EXIST() au lieu de COUNT() pour vérifier l’existence d’un enregistrement dans la table.
3. Ne sélectionner que les champs utiles (éviter SELECT *)
4. Eviter les sous-requêtes dans WHERE
5. Eviter SELECT DISTINCT autant que possible
6. Utiliser WHERE au lieu de HAVING
7. Créer des jointures uniquement avec INNER JOIN (éviter des jointures avec WHERE)
8. Utiliser LIMIT pour limiter le volume de résultat
9. Utiliser UNION ALL au lieu de UNION autant que possible
10. Utiliser UNION WHERE au lieu d’un long WHERE … or … or …
11. Exécuter les requêtes de maintenances pendant les périodes calmes en trafic (par exemple les requêtes de nettoyage de la base de données)
12. Eviter l’utilisation de OR avec les jointures
13. Utiliser des tables temporaires
14. Supprimer les index avant d’importer une large set de données et remettre après cela
15. Eviter les opérateurs de négation (!= ou <>)
16. Réduire la quantité de sous-requêtes

Que contient _wp_attachment_metadata ?

_wp_attachment_metadata contient les métadonnées associées à votre image dans un format sérialisé pour se permettre d’être stocké dans un champ « string » (texte).

Pour constater la taille utilisée par ce dernier, vous pouvez exécuter la requête SQL suivante sur votre base de données (depuis phpMyAdmin par exemple) :

SELECT SUM(LENGTH(meta_value)) as meta_size FROM wp_postmeta WHERE meta_key = '_wp_attachment_metadata';

À noter que la valeur indiquée est en octets. Ce type de métadonnées ne devrait être disponible que pour les posts de type « attachment », autrement dit que les médias. Cela se vérifie assez facilement avec la requête SQL suivante :

SELECT wp_posts.post_type, meta_key FROM wp_postmeta INNER JOIN wp_posts ON wp_posts.ID = wp_postmeta.post_id WHERE meta_key = '_wp_attachment_metadata' GROUP BY wp_posts.post_type;

Vous ne devriez alors voir qu’un seul post_type qui est attachment.

Prenons maintenant une ligne au hasard :

SELECT meta_key, meta_value FROM wp_postmeta WHERE meta_key = '_wp_attachment_metadata' ORDER BY RAND() LIMIT 0,1;

Si nous regardons son contenu, nous verrons que celui-ci contient entre autres :

• Les métadonnées EXIF de l’image (modèle de caméra, paramètres de la prise …)
• Les miniatures existantes et leurs tailles

Comment réduire la taille de _wp_attachment_metadata ?

Réduire la quantité d’images sur le site

Cela ne vient pas forcément à l’esprit, mais plus il y a d’images, plus il y aura de métadonnées d’images. L’action le plus simple et de supprimer les médias inutilisés sur votre site web. Le plugin Media Cleaner est justement là pour effectuer cette tâche.

Réduire la quantité de miniatures sur votre site

Étant donné que chaque format de miniature rajoute des données pour chaque image sur _wp_attachment_metadata, réduire la quantité de miniatures vous aidera également à réduire les données.

Pour commencer, vous pouvez lister les formats de miniatures existantes sur votre site grâce à WP-CLI (disponible en ligne de commande) :

wp media image-size

Commencez alors par identifier les formats et leur origine : thème ou plugin. En effet, vous allez devoir faire un peu de recherche pour savoir quel plugin ou quel thème a introduit ce format de miniature.

Le plugin ou le thème aura à utiliser la fonction WordPress add_image_size() pour effectuer cette action, vous pourrez alors rechercher les fichiers PHP utilisant cette commande pour constater les plugins et thèmes impliqués. Vous pouvez donc utiliser la commande « grep » pour rechercher rapidement ces fichiers :

cd /home/monsite/public_html/wp-content
grep -r -H 'add_image_size'

(assurez-vous de remplacer « /home/monsite/public_html » par la racine de votre site web)

Désactivez et supprimez ensuite le plugin et/ou le thème de votre site web pour supprimer ce format de miniature, et regénérez vos miniatures avec WP-CLI :

wp media regenerate --yes

IMPORTANT !!! Cette commande prendra plusieurs minutes, voire plusieurs heures pour s’exécuter, et sera gourmand en ressources CPU.

Supprimer les données EXIF de vos images

Vous pouvez aussi supprimer vos données EXIF de vos images pour réduire la taille de la métadonnée _wp_attachment_metadata.

Malheureusement, je n’ai aujourd’hui retrouvé aucun outil pour appliquer cela sur les images déjà existantes sur votre site. Je ne pourrais que vous conseiller de supprimer ces informations en amont, avant d’ajouter l’image sur le site. Vous pouvez faire cela avec votre éditeur de photo (Photoshop, Paint.NET, …) ou avec ce genre d’outil en ligne : verexif.com.

Conclusion

Si vous avez un problème avec _wp_attachment_metadata, c’est sûrement que votre site web contient beaucoup d’images et/ou votre thème et vos plugins demandent à ce que WordPress génère beaucoup de miniatures.

Un nettoyage de cette métadonnée allègera votre table wp_postmeta et améliorera vos performances, toutefois si vous n’avez pas la possibilité de réduire cela et que cela vous pose un problème, il sera nécessaire d’envisager un serveur MySQL (et donc probablement une formule d’hébergement web) avec plus de ressources.

La sécurité par l’obscurité

Cette pratique de sécurité consiste à déplacer l’URL effective pour se connecter à WordPress. Dans les dessous des plugins comme WPS Hide Login se trouve des directives pour déporter l’URL wp-login.php vers un autre URL, en passant par la réécriture d’URL. Quant à l’accès à l’URL wp-admin, ce type de plugin remplace la redirection vers la page de connexion en une erreur 404 ou en une redirection vers la page d’accueil.

Certes, cette pratique peut rebuter pas mal de robots qui sont programmés à n’utiliser que les URLs par défaut, mais ce n’est pas pour autant que votre site web soit sécurisé. Déjà, il est assez rare que les hébergeurs limitent les erreurs 404 ni par adresse IP, ni par nom de domaine. Donc, votre site web n’est probablement pas immunisé de robots qui tenteraient d’accéder à l’URL en testant différentes combinaisons possibles (une attaque par bruteforce).

Les accès machines (API)

Mais le pire, c’est que wp-login.php n’est pas le seul moyen de se connecter à WordPress. Aujourd’hui, nous avons le REST API et le vieux XML-RPC qui permet également de se connecter au site. Vous ne pouvez donc tout simplement pas vous reposer sur vos lauriers après avoir déplacé wp-login.php. Et, vous ne pouvez malheureusement pas déplacer le REST API. Déjà, déplacer wp-login.php présente des risques d’incompatibilités avec certains plugins (notamment ceux qui pourraient proposer des mécanismes de connexions comme les plugins d’espace membre, de forum ou d’espace client) ; désactiver le XML-RPC se fait, mais quelques vieux plugins risquent d’en avoir toujours besoin ; et REST API, malheureusement, vous ne pouvez pas le déplacer sans casser WordPress.

Vous pouvez remarquer rapidement en ayant un plugin qui comptabilise le nombre de connexions échoué que même si vous déplacez wp-login.php, vous continuez à avoir des robots qui tentent de se connecter.

Alors, qu’est-ce qu’il faut faire pour sécuriser WordPress ?

Au lieu de dépenser vos efforts pour cacher les pages de connexion, vous devriez miser plus sur la sécurisation de la page de connexion lui-même.

Limiter les adresses IP

Autant que possible, limitez l’accès aux pages de connexion et au REST API / XMLRPC par une liste d’adresse IP / géolocalisation. Si vous vivez en France, par exemple, vous pouvez restreindre l’accès uniquement à ce pays.

Il y a plusieurs techniques possibles, que ce soit avec un plugin, avec un .htaccess, dans les configurations serveurs voire même au niveau du proxy CDN (comme Cloudflare). A titre personnel, je recommande toujours de régler ce problème le plus tôt possible : donc au niveau du CDN, ou au niveau de la configuration serveur.

Limiter les accès robots

Si vous êtes dans l’obligation d’exposer votre page de connexion (site ayant un accès membre, par exemple), assurez-vous de bloquer les robots sur ces pages.

La méthode la plus classique est d’y activer un système captcha. Malheureusement, le captcha peut être relou pour l’expérience utilisateur et en plus, il est aujourd’hui facilement outrepassé par les robots grâce à de l’IA et aux fermes de clics.

La solution que je recommande est de se baser sur une solution de réputation. Beaucoup de services proposent aujourd’hui (gratuit ou payant) une certaine liste d’adresse IP qui ont déjà attaqué d’autres sites WordPress. Il suffira d’ajouter cette liste dans vos listes de blocages.

C’est d’ailleurs pour cette raison que les solutions de pare-feu en proxy comme Cloudflare et Sucuri sont puissants. En effet, ils peuvent détecter, sur une très large échelle, le comportement d’une adresse IP sur des millions de sites et repérer ainsi les robots d’attaques pour pouvoir ensuite les bloquer à échelle globale.

Vous pouvez aussi bloquer les adresses IP non résidentielles (adresses IP qui sont dans des datacenters), qui représente une masse non négligeable des attaquants. Malheureusement, je n’ai trouvé à ce jour aucune liste assez fiable.

Limitez les tentatives infructueuses

On ne dirait pas comme ça, mais WordPress n’en est pas immunisé, de nature. Il faut implémenter vous-même une solution pour limiter les tentatives infructueuses. Personnellement, j’ai implémenté cela par le biais de scripts LUA sur mon serveur NGINX, mais c’est une solution qui peut aussi être implémenté avec un simple plugin.

Certains hébergeurs proposent également cette solution sous forme de règles ModSecurity ou de limitation de trafic L7 sur son serveur web, ou encore les CDN proxy orienté sécurité comme Sucuri.

Utiliser un mot de passe fort et l’authentification à deux facteurs

Évidemment, si votre ensemble nom d’utilisateur / mot de passe est facilement identifiable, alors c’est nécessaire d’améliorer cela en mettant un mot de passe fort (long et complexe) et surtout de mettre l’authentification à deux facteurs afin que, même si les robots passent la page de connexion, l’authentification à deux facteurs vont les garder derrière une autre porte.

Qu’est-ce que le brute force ?

Rien de tel qu’une article Wikipédia pour nous l’expliquer :

L’attaque par force brute est une méthode utilisée en cryptanalyse pour trouver un mot de passe ou une clé. Il s’agit de tester, une à une, toutes les combinaisons possibles.

Attaque par force brute – Wikipédia

C’est assez simpliste comme attaque, il suffit de tester un à un la liste de mot de passe compatible. Bien évidemment, des logiciels sont en place pour que l’opération soit automatisée.

Et aujourd’hui, elle est, la plupart du temps, opéré depuis des serveurs piratés/vérolés (ce qui permet de faire beaucoup de requêtes en parallèle et cibler ainsi plus de sites et/ou tester beaucoup plus de mot de passe par seconde) ou depuis des PC ou autres appareils du quotidiens qui sont piratés ou également vérolés.

La deuxième technique est fortement répandue du fait qu’aujourd’hui, la plupart des pages de connexion ne sont pas accessibles depuis des adresses IPs de datacenter : pour se préserver de ce type d’attaque, certains administrateurs systèmes bloquent systématiquement l’accès aux pages de connexion dès que l’adresse IP est détectée comme provenant d’un datacenter.

Et pour finir le tour de ce type d’attaque, sachez qu’aujourd’hui les hackers ne testent pas toutes les combinaisons, mais « juste » les combinaisons les plus probables : les mots de passes les plus utilisés, les mots de passes possible en exploitant des informations depuis le site lui-même (url du site, nom du compte administrateur, …) ou depuis vos données personnelles visible en ligne (votre date de naissance, retrouvé depuis un réseau social, par exemple).

Ne pas se protéger, la meilleure solution

C’est interloquant comme titre, non ? Oui, ne pas se protéger est la meilleure solution. Ceci consiste tout simplement à fermer la porte pour tout le monde et sans exception. De cette façon, vous ne dépensez pas inutilement de ressources pour identifier si tel ou tel requête fait partie d’une attaque ou non.

Ainsi, restreindre l’accès à wp-login.php et wp-admin à seulement votre adresse IP reste la meilleure solution. Mais ce n’est malheureusement toujours pas possible. C’est notamment le cas quand vous avez des adresses IPs dynamiques, quand vous êtes plusieurs à travailler sur le site, … Bref, faire disparaître la porte peut causer des tas d’inconforts du côté des administrateurs du site.

Pourquoi ne pas utiliser un plugin ?

Là, vite fait, j’ai trois arguments à vous proposer :

• Moins de plugin = moins d’emmerdes sur WordPress. Je ne sais pas si vous avez déjà fait le test mais l’ajout d’un plugin (n’importe lequel) augmente le temps de réponse de WordPress et diminue donc sa vitesse de chargement. Et installer un plugin WordPress c’est aussi un peu plus de risque de bugs et d’instabilité, même si franchement les développeurs de plugins de sécurité WordPress font actuellement un travail très propre. J’estime que le jeu n’en vaut pas la chandelle.
• Faire des actions sur WordPress n’est pas toujours possible. Notamment si on est dans la position d’hébergeur web. Modifier le site d’un client serait très mal vu, même si c’est pour mieux lui protéger, car vous risquez fortement d’induire des problèmes dans le site lui-même (incompatibilité avec votre plugin de sécurité, modifications particulières faites sur WordPress par le développeur, …).
• Un plugin WordPress n’a pas les outils nécessaires pour agir en amont. Le plugin WordPress ne peut rien exécuter tant que WordPress n’est pas démarré. Donc, à chaque requête, WordPress démarre d’abord, avant qu’un plugin de sécurité ne puisse finalement annuler la requête d’un attaquant. Agir à un niveau plus haut permet d’empêcher WordPress de gaspiller un temps de chargement et des ressources pour les attaquants.
• Bonus ou argument numéro 3 bis (à vous de voir), je vois beaucoup de plugin de sécurité de faire l’erreur de stocker les adresses IPs bloqués dans MySQL. Le souci se manifeste quand vous commencez à avoir 40 000 ou 70 000 IPs bloqués. C’est un nombre tout à fait raisonnable vu le fléau d’attaque sur internet, mais c’est très « amateur » de vouloir rechercher des données sur 70 000 lignes sur MySQL à chaque ouverture de page. Et encore pire quand on sait que l’adresse IP est stocké dans un champ non indexé ou un champ VARCHAR ou TEXT. Et loguer tout cela, en prime, c’est l’enfer. Or, avec des outils comme fail2ban, il y a des moyens de loguer cela en asynchrone.

Et de l’autre côté, j’ai quelques 3 avantages à mettre en avant :

• La mise en place peut se faire sans accès au tableau de bord du site. Ceci permet notamment de protéger en une opération tous les sites d’un même serveur.
• Les logs ne sont pas dans MySQL. C’est un avantage non négligeable pour garder la base de données WordPress léger et rapide à accéder. wp_postmeta chauffe déjà assez.
• Le blocage se fait au niveau du service web voire même au niveau du kernel (iptables) ce qui permet d’économiser les ressources.

Mise en place de la protection bruteforce sur NGINX

Dans un premier temps, j’ai ajouté une zone de limite de requête dans NGINX :

echo "limit_req_zone $server_name$binary_remote_addr zone=wpratelimit:10m rate=10r/m;" > /etc/nginx/conf.d/wp-rate-limit.conf

Vous pouvez notamment constater :

• limit_req_zone : la directive NGINX utilisée
• $server_name$binary_remote_addr : la clé d’identification du client. Dans mon cas, j’ai mis à la fois $server_name (nom du site) et $binary_remote_addr (adresse IP du client en binaire) pour pouvoir identifier les clients différemment par site. Ceci me permet de ne pas bloquer un client parce qu’il accède à 10 sites WordPress sur le même serveur.
• zone=wpratelimit:10m : création de la zone « wpratelimit » et qui a 10 Mo de taille
• rate=10r/m : la limite est de 10 requêtes par minute.

Ensuite, il faut appliquer cette zone de limite aux fichiers wp-login.php et xmlrpc.php. Pour ma part, j’ai imbriqué les directives location étant donné que j’utilise fastcgi directement pour servir les fichiers PHP :

location ~ \.php$ {
    [...]

    location ~* (wp-login|xmlrpc)\.php$ {
      limit_req zone=wpratelimit;
      add_header RateLimit "yes";
    }
  }

Si vous utilisez NGINX comme reverse proxy, il faudra implémenter différemment, mais le principe reste le même. Il faudra également avoir un log d’erreur que fail2ban analysera régulièrement :

error_log /home/monsite/logs/error.log

N’oubliez pas de recharger NGINX après les modifications :

systemctl reload nginx

Bloquer les attaques répétés avec fail2ban

Une fois les attaques par bruteforce bloqués sur NGINX, il faudra bloquer les attaques répétés depuis iptables pour réduire le risque de sécurité (un attaquant pourrait potentiellement essayer autre chose que WordPress) et les ressources consommés.

Pour cela, il faut créer un nouveau filtre fail2ban dans /etc/fail2ban/filter.d/wp-rate-limit.conf :

[Definition]
ngx_limit_req_zones = wpratelimit
failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting requests, excess: [\d\.]+ by zone "(?:%(ngx_limit_req_zones)s)", client: <HOST>,
ignoreregex =
datepattern = {^LN-BEG}

Notez que c’est basé sur le fichier etc/fail2ban/filter.d/nginx-limit-req.conf disponible sur fail2ban par défaut.

Ensuite, dans /etc/fail2ban/jail.local, j’ajoute un nouveau prison :

[wp-rate-limit]
enabled = true
bantime = 86400
maxretry = 3
logpath = /home/*/logs/error.log tail

Comme vous voyez, je bloque pour 86 400 secondes (24h si vous voulez) au bout de 3 blocages détectés sur NGINX. Et j’analyse les fichiers d’erreurs sur /home/*/logs/error.log. Le tail à la fin de logpath me permet de ne pas recharger les fichiers en entier au démarrage de fail2ban, ce qui diminue fortement la charge I/O engendrée (ça se voit beaucoup sur un serveur à 1000 sites).

N’oubliez pas de redémarrer fail2ban par la suite :

systemctl restart fail2ban

Place aux tests

Pour tester, j’ai utilisé Apache Benchmark (ab) pour effectuer « beaucoup » de requêtes sur wp-login.php :

ab -n 20 https://www.monsite.com/

Au bout de 10 requêtes, l’IP est bloquée. On peut constater cela depuis le fail2ban-client :

fail2ban-client status wp-rate-limit

Et les blocages faites par NGINX sont logués :

[root@serveur ~] tail /home/monsite/logs/error.log
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"

Désactiver l’accès SSH avec mot de passe

Un mot de passe ne signifie quasiment plus rien en 2022. Si auparavant, celui-ci permettait de sécuriser l’accès à un service, aujourd’hui, nous avons atteint un capacité de calcul et un capacité de trafic réseau suffisamment énorme pour envisager d’essayer toutes les caractères possibles.

Cette technique s’appelle le bruteforce et consiste tout simplement à demander à un ou plusieurs PC, Mac, serveurs Linux, votre frigo connecté ou votre smartphone, d’essayer un à un une liste de mot de passe sur un service. Grâce à internet et une petite armée d’appareils infectés, les hackers arrivent à essayer des milliers si ce n’est des millions de combinaisons de mots de passe en quelques minutes. Il est aussi courant de voir des pirates louer des serveurs ou pirater des sites justement pour cet usage.

Le meilleur moyen de leur couper l’herbe sous le pied et tout simplement de ne pas disposer de mot de passe. S’il n’y a pas de mot de passe à pirater, alors leur bruteforce ne vont pas du tout aboutir.

En remplacement du mot de passe, nous pouvons utiliser la cryptographie à notre avantage et utiliser donc une paire de clé privée/publique pour s’authentifier sur notre serveur SSH.

Création d’une paire de clé SSH

Vous pouvez créer une paire de clé SSH depuis votre PC ou depuis le serveur lui-même. D’ailleurs vous pouvez le créer sur n’importe quel appareil. Sous Windows, l’outil PuTTY vous permet de le faire. Sous Linux et Mac, vous pouvez utiliser la commande suivante :

ssh-keygen -t rsa

L’option -t rsa permet d’indiquer l’algorithme à utiliser. Une fois vos clés créés, vous devez être en possession d’une clé privée et d’une clé publique.

Autoriser la clé SSH à se connecter à un utilisateur sur le serveur SSH

Ensuite, il s’agit d’ajouter votre clé SSH à un utilisateur du serveur. Pour cela, ouvrez le fichier de clé publique qui devrait contenir la clé publique de la forme ssh-rsa XXXXXXXXXXXX(…) user@hostname. Copiez tout cela et ajoutez-le au fichier /root/.ssh/authorized_keys du serveur (créez le fichier et le dossier si nécessaire).

Une fois ajouté au fichier, essayez de vous connecter au SSH. Le serveur ne devrait plus vous demander de mot de passe lors de la connexion.

Désactiver la connexion par mot de passe

Enfin, nous pouvons désactiver la connexion par mot de passe pour l’utilisateur root. Dans le fichier de configuration de votre serveur SSH (/etc/ssh/sshd_config), remplacez :

PermitRootLogin yes

par :

PermitRootLogin without-password

et redémarrez le service SSH :

systemctl restart sshd

Bannir les tentatives de connexion avec mauvais mot de passe avec fail2ban

Une autre chose qui peut être faite est de bannir une adresse IP s’il a obtenu trop d’échec de connexion pour mauvais mot de passe. L’outil fail2ban est justement destiné à cet usage. Pour l’installer :

apt-get install -y fail2ban

Ensuite, pour la configuration, il nous faudra créer le fichier /etc/fail2ban/jail.local avec comme contenu :

[DEFAULT]
bantime = 3600

[sshd]
maxretry = 3
action = iptables-multiport

Dans la section DEFAULT, je définis le temps de blocage sur 3600 secondes (1 heure). Ceci s’appliquera alors à tous les services surveillé par fail2ban. Rien ne vous empêche de spécifier un bantime différent par service en utilisant la même directive dans les sections des services.

La section sshd s’applique du coup pour le service SSH uniquement. J’ai mis maxretry sur 3 pour limiter la connexion à 3 tentatives. L’action iptables-multiport est une action prédéfinie dans fail2ban qui permet de bloquer l’adresse IP détectée sur tous les ports du serveurs et ce en utilisant IPTables.

Maintenant, il s’agit de démarrer fail2ban :

systemctl restart fail2ban

N’oublions pas de l’activer au démarrage :

systemctl enable fail2ban

Vous pouvez ensuite visualiser l’état global de fail2ban avec la commande suivante :

fail2ban-client status

Et vous pouvez voir l’état du monitoring du SSH avec la commande suivante :

fail2ban-client status sshd

Je ne serais pas du tout surpris que vous aillez déjà quelques adresses IP bloqués. Vive internet.

Limiter l’accès SSH à quelques adresses IP de confiance

C’est la solution que je préconise au maximum. Si un voleur ne peut pas toucher votre porte, alors il ne pourra pas faire sauter votre serrure. Malheureusement, je suis dans un cas où mon adresse IP n’est pas fixe, et par conséquent, je peux risquer de me bloquer moi-même si je mets une adresse IP aujourd’hui et que demain je ne peux plus m’y connecter en utilisant cette même adresse IP.

Ainsi, j’utilise l’approche suivante. J’ai listé tous les adresses IPs que mes fournisseurs d’accès Internet pourraient me fournir. Ceci se liste facilement grâce aux informations liés au ASN et aux routes BGP ainsi associés. Pour faire simple, un fournisseur d’accès Internet dispose généralement sa propre numéro AS (le ASN du coup) et chaque adresse IP est associé à un ASN. Une fois l’ASN de votre fournisseur identifié sur peeringdb.com, vous pouvez rechercher les blocs d’IPs associés sur hackertarget.

J’ajoute dans la liste également quelques adresses IPs de confiance, notamment l’adresse IP de quelques un de mes autres serveurs, au cas où je suis vraiment bloqué et que je dois utiliser un autre de mes serveurs pour se frayer un chemin dans ce serveur en particulier. C’est toujours mieux que se connecter sur une console KVM over IP.

C’est une sacré liste, mais pas aussi grande qu’Internet tout entier. Ca coupe déjà l’herbe sous le pied de pas mal de machines infectés et de hackers malintentionnés. C’est mieux que rien.

Maintenant qu’on a la liste à autoriser, configurons le pare-feu. Pour ma part, j’utilise IPSet avec IPTables qui me permet de lister un grand nombre de plage IP sans perdre trop de performances. Commençons par créer le set d’IP autorisé à se connecter en SSH :

ipset -N admin hash:net

Ensuite, ajoutons-y des adresses IP :

ipset -A admin 1.2.3.4

Evidement, 1.2.3.4 a vocation à être remplacé par une adresse IP ou un CIDR. Enfin, autorisons ce set d’IP sur le port 22 :

iptables -A INPUT -p tcp --dport 22 -m set --match-set admin src -j ACCEPT

Et enregistrons les modifications :

ipset save > /etc/ipset.conf
iptables-save > /etc/iptables/rules.v4

Si vous n’avez pas iptables-save, alors il faut installer iptables-persistent :

apt-get install iptables-persistent

Et voilà, votre service SSH est désormais limité aux adresses IPs que vous avez fournis.

Installation du dépôt Sury.org

L’ajout du dépôt Sury.org requiert quelques dépendances :

apt-get -y install apt-transport-https lsb-release ca-certificates

Ensuite, il faut importer la clé GPG du dépôt :

wget -q -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

Enfin, nous pouvons ajouter le dépôt dans les configurations de apt :

echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list

Installation de PHP 5.6 depuis les dépôts Sury.org

Commençons par rafraîchir la liste des paquets dans apt, suite à l’ajout du dépôt :

apt-get update

Ensuite, entamons le vif du sujet :

apt-get -y install php5.6 php5.6-common php5.6-gd php5.6-mysql php5.6-imap php5.6-cli php5.6-cgi php-pear php5.6-curl php5.6-intl php5.6-pspell php5.6-sqlite3 php5.6-tidy php5.6-xmlrpc php5.6-xsl php-memcache php-imagick php-gettext php5.6-zip php5.6-mbstring php5.6-soap php5.6-memcached php5.6-redis php5.6-fpm

Configuration de PHP 5.6

Si vous souhaitez ensuite modifier la version PHP par défaut du CLI, utilisez la commande suivante :

update-alternatives --config php

Vous pouvez faire la même chose pour PHP-CGI :

update-alternatives --config php-cgi

Remarque : Changer la version PHP par défaut du CLI peut engendrer des comportements inattendu chez certains outils utilisant /usr/bin/php pour accéder à PHP, sans vérifier sa version. C’est notamment le cas d’ISPConfig dans ses crons, ainsi que de Roundcube lors de l’exécution de certains scripts durant l’installation/mise à jour.

Je vous recommanderai plutôt de modifier la version PHP par défaut du CLI uniquement sur un seul utilisateur shell qui est celui du site qui en a besoin. J’écrirai bientôt un tutoriel à ce sujet.

Ajout dans ISPConfig

Si vous utilisez ISPConfig, vous pouvez ajouter cette nouvelle installation dans ISPConfig > Système > Version PHP additionnelles. Vous mettez les valeurs suivantes :

• PHP Name : le nom dont vous souhaitez afficher sur la liste à dérouler. J’ai mis « PHP 5.6 » pour ma part.
• FastCGI Settings > Path to the PHP FastCGI binary : php-cgi5.6
• FastCGI Settings > Path to the php.ini directory : /etc/php/5.6/cgi/php.ini
• PHP-FPM Settings > Path to the PHP-FPM init script : php5.6-fpm
• PHP-FPM Settings > Path to the php.ini directory : /etc/php/5.6/cgi/php.ini
• PHP-FPM Settings > Path to the PHP-FPM pool directory : /etc/php/5.6/fpm/pool.d

Bonus : script d’installation

Voici en bonus un script d’installation/mise à jour complet que j’ai créé pour vous. Elle permet d’installer PHP 5.6 depuis les dépôts sury.org, garde la version de PHP par défaut inchangée, et ajoute PHP 5.6 dans ISPConfig. Elle empêche également le démarrage du service PHP-FPM associé si aucun site n’est configuré sur cette version de PHP dans ISPConfig, empêchant ainsi de perdre inutilement des ressources (CPU, RAM, disque …).

L’utilisation se fait en une seule ligne et est totalement automatisée :

curl -s https://scripts.ratefiarison.com/raw/debian-install-php5.6-sury | bash

Après avoir sorti le tutoriel pour installer PHP 5.4 sous Debian 11, j’ai décidé de pousser le concept plus loin lorsque j’étais confronté à une situation où je dois migrer un très vieux site OsCommerce sur un système d’exploitation récent. Fort heureusement, j’ai pu reprendre une grande partie des résolutions de problème faites sur ce précédent article.

1. Installer OpenSSL 1.0.2u

Comme PHP 5.4, PHP 5.3 requiert une vieille version d’OpenSSL que nous allons compiler et installer de côté :

mkdir -p /usr/local/openssl-1.0.2u
wget -O /usr/local/src/openssl-1.0.2u.tar.gz https://www.openssl.org/source/openssl-1.0.2u.tar.gz
cd /usr/local/src/
tar -xf openssl-1.0.2u.tar.gz
rm -f openssl-1.0.2u.tar.gz
cd openssl-1.0.2u
./config shared --prefix=/usr/local/openssl-1.0.2u
make -j $(nproc)
make install
ln -s /usr/local/openssl-1.0.2u/lib /usr/local/openssl-1.0.2u/lib/x86_64-linux-gnu
wget -O /usr/local/openssl-1.0.2u/ssl/cert.pem "http://curl.haxx.se/ca/cacert.pem"
ln -s /usr/local/openssl-1.0.2u/lib/libcrypto.so.1.0.0 /usr/lib/x86_64-linux-gnu/
ln -s /usr/local/openssl-1.0.2u/lib/libssl.so.1.0.0 /usr/lib/x86_64-linux-gnu/

2. Installer cURL 7.82.0

Même chose pour cURL avec qui on a besoin d’une vieille version :

mkdir -p /usr/local/curl-7.82.0
wget -O /usr/local/src/curl-7.82.0.tar.gz https://curl.se/download/curl-7.82.0.tar.gz
cd /usr/local/src/
tar -xf curl-7.82.0.tar.gz
rm -f curl-7.82.0.tar.gz
cd curl-7.82.0
./configure --with-openssl=/usr/local/openssl-1.0.2u --prefix=/usr/local/curl-7.82.0
make -j $(nproc)
make install

Remarquez l’utilisation d’OpenSSL 1.0.2u lors de la compilation de cURL.

3. Compiler PHP 5.3 sur Debian 11

Déjà, il faut disposer des bonnes dépendances pour compiler PHP 5.3 :

apt-get install -y libfcgi-dev libfcgi0ldbl libmcrypt-dev libssl-dev libc-client2007e libc-client2007e-dev libpq-dev libxslt-dev libltdl-dev libmariadb-dev-compat libmariadb-dev

J’ignore si les paquetages libmariadb-dev-compat et libmariadb-dev peuvent être omis ou non, vu que, plus tard dans mes tests, j’ai décidé d’utiliser mysqlnd, le client natif de PHP pour MySQL. Techniquement, en utilisant mysqlnd, ces librairies sont inutiles. A tester.

Maintenant, il s’agit de télécharger et décompresser la dernière version de PHP 5.3 :

wget -O /usr/local/src/php-5.3.29.tar.gz https://www.php.net/distributions/php-5.3.29.tar.gz
cd /usr/local/src/
tar -xf php-5.3.29.tar.gz
rm -f php-5.3.29.tar.gz
cd php-5.3.29

A présent, il faut configurer la compilation :

./configure --prefix=/usr/local/php-5.3 --with-pdo-pgsql --with-zlib-dir --with-freetype-dir --enable-mbstring --with-libxml-dir=/usr --enable-soap --enable-calendar --with-curl=/usr/local/curl-7.82.0 --with-mcrypt --with-zlib --with-pgsql --disable-rpath --enable-inline-optimization --with-bz2 --with-zlib --enable-sockets --enable-sysvsem --enable-sysvshm --enable-pcntl --enable-mbregex --enable-exif --enable-bcmath --with-mhash --enable-zip --with-pcre-regex --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-mysql-sock=/var/run/mysqld/mysqld.sock --with-jpeg-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --with-openssl=/usr/local/openssl-1.0.2u --with-fpm-user=www-data --with-fpm-group=www-data --with-libdir=/lib/x86_64-linux-gnu --enable-ftp --with-kerberos --with-gettext --with-xmlrpc --with-xsl --enable-fpm

–prefix me permet de définir le dossier sur lequel je vais installer PHP 5.3, –with-curl pour indiquer le chemin du cURL que je souhaite utiliser (celui qu’on a précédemment compilé), –with-openssl pour indiquer le chemin du OpenSSL que je souhaite utiliser (également celui précédemment compilé).

J’ai essayé de compiler avec les librairies MySQL fournis par MariaDB 10.5 sur le dépôt officiel de Debian mais je n’ai pas réussi, à cause de l’absence de certains fichiers headers, qui ont été présent auparavant sur les vieilles version de MySQL. Je ne me suis pas cassé la tête, j’ai activé l’utilisation du mysqlnd (MySQL Native Driver) de PHP en utilisant les options –with-mysql=mysqlnd –with-mysqli=mysqlnd –with-pdo-mysql=mysqlnd.

Enfin, on compile et installe :

make -j $(nproc)
make install

4. Configurer PHP 5.3

Déjà, initialisons les fichiers de configuration par les fichiers de configuration par défaut proposés :

cp /usr/local/src/php-5.3.29/php.ini-production /usr/local/php-5.3/lib/php.ini
cp /usr/local/php-5.3/etc/php-fpm.conf.default /usr/local/php-5.3/etc/php-fpm.conf

Ensuite, préparer le dossier qui va accueillir les pool PHP-FPM :

mkdir -p /usr/local/php-5.3/etc/php-fpm.d

Configurer le fichier PID du PHP-FPM :

sed -i "s|;pid\s=\srun/php-fpm.pid|pid = run/php-fpm.pid|g" /usr/local/php-5.3/etc/php-fpm.conf

Configurer le socket d’écoute et son utilisateur/groupe propriétaire :

sed -i "s|;listen\s=.|listen = /run/php/php5.4-fpm.sock|g" /usr/local/php-5.3/etc/php-fpm.conf
sed -i "s|;listen.owner\s=.|listen.owner = www-data|g" /usr/local/php-5.3/etc/php-fpm.conf
sed -i "s|;listen.group\s=.|listen.group = www-data|g" /usr/local/php-5.3/etc/php-fpm.conf

Enfin, il faut inclure les fichiers de configuration dans le dossier que nous avons créé prédécemment :

sed -i "s|;include\s=.|include=/usr/local/php-5.3/etc/php-fpm.d/.conf|g" /usr/local/php-5.3/etc/php-fpm.conf

Maintenant, il faut créer le service systemd correspondant à PHP-FPM :

cat < /lib/systemd/system/php5.3-fpm.service
[Unit]
Description=The PHP 5.3 FastCGI Process Manager
After=network.target

[Service]
Type=simple
PIDFile=/usr/local/php-5.3/var/run/php-fpm.pid
ExecStartPre=/bin/mkdir -p /run/php
ExecStart=/usr/local/php-5.3/sbin/php-fpm --nodaemonize --fpm-config /usr/local/php-5.3/etc/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID
PermissionsStartOnly=true

[Install]
WantedBy=multi-user.target
EOF

Maintenant, il faut l’activer au démarrage et le lancer :

systemctl daemon-reload
systemctl enable --now php5.3-fpm.service
systemctl restart php5.3-fpm.service

Par pure caprice, je mets un lien symbolique dans /usr/bin afin de faciliter l’utilisation de PHP 5.3 en ligne de commande :

ln -s /usr/local/php-5.3/bin/php /usr/bin/php5.3
ln -s /usr/local/php-5.3/bin/php-cgi /usr/bin/php-cgi5.3

5. Ajouter PHP 5.3 sur ISPConfig

Si vous utilisez ISPConfig comme panneau de contrôle, alors vous pouvez ajouter cette installation dans ISPConfig grâce à la requête SQL suivante :

mysql --defaults-file=/etc/mysql/debian.cnf dbispconfig -e "INSERT INTO server_php (sys_userid, sys_groupid, sys_perm_user, sys_perm_group, sys_perm_other, server_id, client_id, name, php_fastcgi_binary, php_fastcgi_ini_dir, php_fpm_init_script, php_fpm_ini_dir, php_fpm_pool_dir, active) VALUES (1, 1, 'ruid', 'ruid', '', 1, 0, 'PHP 5.3', 'php-cgi5.3', '/usr/local/php-5.3/lib/php.ini', 'php5.3-fpm', '/usr/local/php-5.3/lib/php.ini', '/usr/local/php-5.3/etc/php-fpm.d', 'y')"

Conclusion

Faire fonctionner PHP 5.3 sur un système d’exploitation aussi récent que Debian 11 n’est finalement pas si difficile qu’on pourrait le croire. Il faut juste mettre à disposition les bonnes versions des dépendances au compilateur. Mais planifiez quand même votre migration vers un PHP plus récent, avant que quelqu’un ne trouve une brèche sur votre site.