Aller au contenu principal

Détection des menaces

Fonctionnalité Pro

La détection de menaces et le blocage automatique sont disponibles avec la licence Pro. Obtenez votre licence Pro pour accéder à cette fonctionnalité.

Sentinel détecte et bloque automatiquement les requêtes malveillantes en utilisant une correspondance de motifs basée sur des signatures.

Comment ça fonctionne​

  1. Analyse des requêtes : Chaque requête HTTP est analysée avant d'atteindre PrestaShop — chaîne de requête, corps brut, champs de formulaire (y compris les envois multipart/form-data) et noms des fichiers téléversés. Le percent-encoding est d'abord défait, de sorte qu'encoder un caractère ne permet pas de dissimuler une charge. Les jetons de sécurité que PrestaShop ajoute à ses liens et à ses formulaires ne sont pas comparés aux signatures lorsqu'ils ont exactement la forme que PrestaShop leur donne, afin qu'un jeton tiré au hasard ne fasse plus refuser une page ou un formulaire ; toute autre valeur de ces paramètres est analysée comme d'habitude, et les signatures qui les visent s'appliquent toujours.
  2. Correspondance de motifs : La requête est comparée aux signatures de menaces connues téléchargées depuis l'API Sentinel
  3. Blocage instantané : Si un motif malveillant est détecté, la requête est bloquée avec HTTP 403, sauf si elle vient d'une IP de confiance ou vise une URL jamais bloquée (voir Ce qui n'est jamais bloqué)
  4. Journalisation : Toutes les attaques détectées sont enregistrées avec les détails (IP, URI, motif correspondant)
Requêtes surdimensionnées ou malformées

La comparaison aux signatures s'exécute avec un budget de backtracking fixé par Sentinel, de sorte que le comportement ne dépend pas de la configuration PHP de votre hébergeur. Si une requête est construite pour que le moteur abandonne avant d'avoir terminé — une technique connue pour faire passer une charge à travers un filtrage par signatures — elle est traitée comme une menace et bloquée, jamais comme du trafic sain. Une signature qui ne compile pas est en revanche ignorée, afin qu'un motif défectueux ne puisse pas bloquer vos visiteurs.

Une exception : lorsque le moteur abandonne sur une requête provenant du back-office avec une session employé connectée, la requête n'est pas bloquée. Un formulaire d'administration volumineux peut épuiser le budget d'une signature gourmande sans rien transporter d'hostile, et bloquer coûterait une page à votre équipe pour un contrôle qui n'a jamais abouti. L'événement est enregistré dans les journaux de sécurité sous le type Contrôle non effectué, avec la signature concernée et la raison pour laquelle le contrôle n'a pas pu être mené à terme. Une signature qui correspond réellement bloque la requête, session employé ou non ; depuis une IP de confiance ou vers une URL jamais bloquée, ni une correspondance ni un contrôle abandonné ne la bloquent.

Activer ou désactiver la détection​

La détection des menaces se règle dans la carte Détection des menaces en temps réel de l'onglet Détection des menaces de Sentinel > Configuration. Basculez l'interrupteur, puis cliquez sur Appliquer : rien ne change tant que vous n'avez pas cliqué.

Activer la détection télécharge aussi les dernières signatures. Si elles ne peuvent pas être téléchargées, la détection est quand même activée et la page affiche Détection des menaces activée, mais les signatures n'ont pas pu être téléchargées : suivi de la raison.

Le badge de la carte indique l'état de la détection :

  • Activé : chaque requête est comparée aux signatures, et une attaque est bloquée, sauf si elle vient d'une IP de confiance ou vise une URL jamais bloquée (voir Ce qui n'est jamais bloqué).
  • En attente des signatures : la détection est activée, mais aucune signature n'a encore été téléchargée, donc rien n'est bloqué.
  • Désactivé : la détection est désactivée, y compris sur les fichiers PHP atteints directement (voir Détection par signatures sur les accès directs).

Tant que les signatures n'ont pas été téléchargées, l'onglet affiche l'avis Signatures de détection des menaces manquantes au-dessus de la carte, avec un bouton Télécharger les signatures. La détection reste inactive jusqu'à leur téléchargement.

En plan gratuit, la carte affiche à la place de l'interrupteur et du badge l'invitation au Pro décrite sous Détection des menaces.

Seul un employé qui peut configurer le module Sentinel modifie ces réglages ; les autres voient l'onglet en lecture seule. Voir Qui peut modifier les réglages.

Mise à jour des signatures​

Les signatures de détection sont gérées à distance sur l'API Sentinel et synchronisées automatiquement :

  • À l'installation : Les signatures sont téléchargées lors de l'installation du module
  • Synchronisation quotidienne : Le back-office vérifie automatiquement les signatures mises à jour toutes les 24 heures
  • Téléchargement manuel : Si les signatures sont absentes, l'onglet Détection des menaces de Sentinel > Configuration affiche l'avis Signatures de détection des menaces manquantes avec un bouton Télécharger les signatures

Une boutique dont le plan n'inclut plus la détection des menaces reçoit un jeu de signatures vide à la synchronisation suivante : elle n'a alors plus rien à comparer aux requêtes.

Une erreur passagère garde en place les signatures déjà présentes jusqu'à la synchronisation suivante : service Sentinel injoignable, réponse trop tardive, erreur du serveur ou clé de licence refusée.

Tant que la boutique garde la détection des menaces, ses signatures suivent celles du service Sentinel sans nécessiter de mise à jour du module.

Ce qui n'est jamais bloqué​

Les adresses de la carte IP de confiance de l'onglet Général de Sentinel > Configuration ne sont jamais bloquées par la détection des menaces : sur le front-office, sur le back-office et sur les fichiers PHP atteints directement (voir Détection par signatures sur les accès directs). C'est la liste à laquelle les protections brute-force et DDoS font déjà confiance, et les plages CIDR sont acceptées.

Une exemption laisse passer toute attaque

Une requête venue d'une IP de confiance, ou vers une URL jamais bloquée, n'est pas bloquée, même quand elle porte une attaque. Ne faites confiance qu'à des adresses que vous maîtrisez, et vérifiez les points ci-dessous.

  • IP de maintenance : les IP de maintenance réglées dans PrestaShop sont aussi de confiance tant que l'interrupteur Faire aussi confiance aux IP de maintenance PrestaShop de la carte est activé, et il l'est dès l'installation du module. Relisez-les, et désactivez l'interrupteur si l'une d'elles est une adresse que vous ne maîtrisez pas. Sur les fichiers PHP atteints directement, un changement des IP de maintenance fait dans PrestaShop s'applique une fois la carte IP de confiance enregistrée de nouveau.
  • Derrière un proxy ou un CDN : seule compte l'adresse transmise par un proxy déclaré dans la carte Derrière un proxy ou un CDN ?, jamais le réglage hérité Faire confiance à X-Forwarded-For. Tant que le proxy n'est pas déclaré, Sentinel voit l'adresse du proxy au lieu de la vôtre, et votre IP de confiance n'est pas reconnue. Si l'adresse d'un proxy non déclaré figure parmi les IP de confiance ou les IP de maintenance, tous les visiteurs qui passent par ce proxy sont exemptés.
  • Plages trop larges : une plage comme 0.0.0.0/0 exempte toutes les adresses qu'elle contient, attaquants compris, et Sentinel ne la refuse pas. Limitez chaque plage aux adresses que vous maîtrisez.
  • Journalisée, pas bloquée : une requête venue d'une IP de confiance qui correspond à une signature atteint sa page normalement, et les journaux de sécurité l'enregistrent comme non bloquée, avec la signature reconnue : sous Contrôle non effectué pour une requête qui passe par PrestaShop, et comme Non bloquée — IP de confiance dans l'onglet des logs fichiers pour un fichier PHP atteint directement.
  • Détection désactivée : tant que l'interrupteur Détection des menaces en temps réel est désactivé, rien n'est comparé, donc rien n'est bloqué et aucune exemption n'est enregistrée : ni événement Contrôle non effectué, ni marque Non bloquée — IP de confiance ou Non bloquée — URL de confiance. Les accès directs que la protection Auto Prepend File enregistre, et les requêtes POST, PUT, PATCH et DELETE, restent journalisés.

URL jamais bloquées​

La carte URL jamais bloquées de l'onglet Détection des menaces de Sentinel > Configuration liste les URL que la détection des menaces ne bloque jamais, comme l'adresse où un prestataire de paiement confirme une commande. Cette liste n'est pas la liste URLs exclues de la protection DDoS : une URL exclue là-bas reste contrôlée par la détection des menaces.

Écrivez un chemin par ligne, qui commence par /, sans le domaine ni les paramètres de requête. Chaque entrée désigne l'une de deux choses :

  • Une page de module : un chemin qui commence par /module/, par exemple /module/ps_wirepayment/validation, est la page validation du module ps_wirepayment, affichée par PrestaShop. Sentinel compare l'entrée à la page que PrestaShop s'apprête à exécuter, pas à l'adresse demandée : la page est couverte avec ou sans URL simplifiées, avec un préfixe de langue et dans une boutique installée dans un sous-dossier, alors qu'une adresse dont les paramètres de requête mènent à une autre page ne l'est pas. La casse ne compte pas. Seules les pages front d'un module activé sont couvertes, jamais le back-office ni les pages de PrestaShop lui-même.
  • Un fichier PHP appelé en direct : tout autre chemin, par exemple /modules/mymodule/ipn.php, est un fichier atteint sans passer par PrestaShop (voir Détection par signatures sur les accès directs). Écrivez-le depuis la racine de la boutique, sans le dossier d'une boutique installée dans un sous-dossier. Seule une requête qui atteint le fichier listé par son chemin simple est couverte : rien après le nom du fichier, aucun segment vide, . ou .., rien qui reste encodé une fois décodé, et la même casse que l'entrée.

Un * remplace un segment entier fait uniquement de lettres sans accent, de chiffres, de _, . ou -, jamais un /, et il est refusé en premier comme en dernier segment : /modules/*/ipn.php couvre /modules/mymodule/ipn.php, pas /modules/mymodule/sub/ipn.php ni /modules/my+module/ipn.php.

Enregistrer refuse toute la liste, n'enregistre rien et garde ce que vous avez saisi dans le champ quand une entrée ne commence pas par /, contient .., ?, #, %, \, une espace, un segment vide comme dans //, un segment ., un / final ou un * qui n'est pas un segment entier, ou dépasse 255 caractères. La page nomme alors la première entrée refusée : %entry% n'est pas un chemin d'URL valide. Commencez-le par /, sans paramètres de requête, et n'utilisez * que pour un segment entier qui n'est ni le premier ni le dernier. Rien n'a été enregistré : corrigez-le et enregistrez de nouveau., où %entry% est cette entrée. Une liste de plus de 50 URL est refusée de la même façon, avec Vous pouvez lister au plus 50 URL. Rien n'a été enregistré : raccourcissez la liste et enregistrez de nouveau. Sinon, les lignes vides et les entrées répétées sont retirées, et la page affiche Les URL jamais bloquées ont été enregistrées.

  • Seulement ce qui en a besoin : une attaque envoyée vers une URL listée passe, comme le dit la mise en garde plus haut. Ne listez que les URL de paiement ou de webhook que la détection des menaces bloque à tort, et utilisez * avec parcimonie.
  • Journalisée, pas bloquée : une requête vers une URL listée qui correspond à une signature atteint sa page normalement, et les journaux de sécurité l'enregistrent comme non bloquée, avec la signature reconnue : sous Contrôle non effectué pour une page de module, et comme Non bloquée — URL de confiance dans l'onglet des logs fichiers pour un fichier PHP appelé en direct. Une requête venue d'une IP de confiance est enregistrée comme venue d'une IP de confiance, même vers une URL listée.

Menaces protégées​

Injection SQL​

Détecte les tentatives de manipulation de votre base de données :

Exemple : /index.php?id=1' AND SELECT SLEEP(5)--

Sentinel bloque les motifs comme :

  • SELECT ... SLEEP ...
  • UNION SELECT ...
  • Mots-clés SQL dans des contextes suspects

Opérations sur les fichiers​

Détecte les tentatives d'écriture de fichiers malveillants :

Exemple : file_put_contents('shell.php', '<?php ...')

Bloque les tentatives de :

  • Écrire des fichiers avec file_put_contents
  • Télécharger du code distant avec wget
  • Modifier la configuration PHP avec ini_set

Exécution de commandes​

Empêche l'exécution de commandes système :

Exemple : system('rm -rf /')

Exploits de modules​

Détecte les vulnérabilités connues dans les modules PrestaShop populaires :

  • Module Product Search
  • Modules de blog (CSBlog, SmartBlog, etc.)
  • Modules de paiement

En-têtes HTTP suspects​

Détecte les en-têtes HTTP malveillants ou suspects :

  • Scanners de sécurité : Bloque les requêtes provenant d'outils de scan connus (sqlmap, nikto, nmap, dirbuster, etc.)
  • User-Agent vide : Bloque les requêtes sans en-tête User-Agent (fréquent dans les attaques automatisées)
  • Log4Shell : Détecte les tentatives d'injection JNDI dans les en-têtes HTTP

Quand une attaque est détectée​

  1. La requête est bloquée avec HTTP 403 Forbidden
  2. Une page personnalisée est affichée à l'attaquant
  3. L'attaque est enregistrée dans /var/logs/sentinel-AAAA-MM-JJ.log
  4. Le contexte est enregistré : adresse IP, URI, motif correspondant, données de la requête

Depuis une IP de confiance ou vers une URL jamais bloquée, la requête n'est pas bloquée : elle atteint sa page normalement, sans la page de blocage, et l'attaque est seulement journalisée, comme non bloquée.

Exemple de requête bloquée​

Quand quelqu'un essaie :

https://votreboutique.com/index.php?search=SELECT SLEEP(10)

Il voit :

HTTP 403 Forbidden
Accès refusé
Votre requête a été bloquée pour des raisons de sécurité.

Et Sentinel enregistre :

{
  "ip": "192.168.1.100",
  "uri": "/index.php?search=SELECT SLEEP(10)",
  "pattern": "(.*)select(.*)sleep(.*)",
  "method": "GET"
}

Suivant : Journaux de sécurité