Synology Prévention des menaces : ce qu'il détecte et ce qu'il ne peut pas voir

Threat Prevention est le paquet vers lequel la plupart des gens se tournent dès qu'ils décident d'héberger un site Web sur un NAS Synology. Il se situe sur le routeur, possède une icône de bouclier, et son tableau de bord compte les attaques par centaines, donnant l'impression d'être l'élément qui sécurise un site public. Nous l'exécutons sur un RT6600ax devant chaque machine que nous possédons, et il a valu la peine d'être installé. Il est également, pour un site Web auto-hébergé, presque totalement hors sujet.

Cet article de NAS Hosting 101 ouvre notre propre routeur, en extrait une semaine réelle d'événements et montre exactement là où Threat Prevention cesse de pouvoir aider, en utilisant PHP2Shell comme exemple d'attaque que Threat Prevention n'allait jamais voir.

Point SynoPower Club : J'ai passé beaucoup de temps au support Synology, et la question revenait sans cesse : quelle option dois-je activer pour stopper cette attaque. C'est le bon instinct ciblant le mauvais équipement. Ce qui m'a enfin fait déclic, c'est de lire notre propre liste d'événements au lieu de la page des fonctionnalités. Chaque alerte enregistrée par notre routeur ce mois-ci concernait une adresse ayant une mauvaise réputation, et non une requête avec une mauvaise charge utile. Une fois qu'on a vu cela, on arrête de demander à Threat Prevention d'inspecter un trafic qu'il détient dans une enveloppe scellée.

Ce que fait réellement Threat Prevention sur un routeur Synology #

Threat Prevention est un système de détection et de prévention des intrusions basé sur la lignée de Snort et Suricata. Il lit les paquets au fur et à mesure que le routeur les réachemine, les compare à un jeu de signatures et enregistre une alerte ou rejette le paquet. Sur notre RT6600ax, le flux de signatures est ET Open, le niveau gratuit du jeu de règles Emerging Threats, actualisé quotidiennement à 09:00.

Trois propriétés découlent de cette conception, et toutes trois comptent plus que n'importe quelle case à cocher dans l'interface :

• It can only examine packets the router forwards. Traffic that never crosses the routing engine is not slow to inspect, it is invisible.
• It can only match on bytes it can read. Il n'y a aucune interception TLS dans Threat Prevention, donc une charge utile chiffrée reste opaque.
• It can only match signatures somebody else wrote. The interface exposes vendor classes to switch on and off, and nothing that accepts a rule you author yourself.

Rien de tout cela n'est un défaut. Un IPS au périmètre du réseau est une chose raisonnable et utile à posséder. L'erreur consiste à supposer que le périmètre est l'endroit où un site Web est attaqué.

Threat Prevention vs un pare-feu d'application Web #

Le moyen le plus clair de voir l'écart est de placer Threat Prevention à côté d'un pare-feu d'application Web et de se demander ce que chacun détient lorsqu'il prend sa décision. Threat Prevention détient un paquet. Un WAF détient une requête HTTP déchiffrée.

Question	Router IPS	Reverse-proxy WAF
Là où ça court	On the routing path, before TLS ends	At the edge, after TLS ends
What it inspects	Packet headers and any cleartext bytes	Method, path, headers, cookies, body
HTTPS traffic	Opaque	Fully readable
Rules you can add	Vendor classes on or off	Your own expressions, plus managed rulesets
Same-subnet traffic	Never seen	Not applicable, it is upstream of everything
Typical catch	Reputation hits, scans, cleartext exploits, outbound command and control	Injection, traversal, known CVE request shapes, credential stuffing, bots

Ce ne sont pas des produits concurrents. Ils couvrent différents segments d'un même parcours, et un site auto-hébergé a bien plus besoin du second que du premier. Nous conservons les deux et nous attendons des choses totalement différentes de chacun.

Lecture de 595 événements d'une semaine sur notre propre routeur #

Voici l'écran d'aperçu de Threat Prevention de notre routeur de production le 25 octobre 2026. Cinq cent quatre-vingt-quinze événements malveillants sur sept jours, dont 75 de sévérité élevée. Cela ressemble à un mur retenant une inondation.

Deux détails sur cet écran valent plus que le chiffre principal. Le premier est qu'un seul appareil apparaît sous la liste des menaces potentielles, et il s'agit de REVERSE_MAIL, la machine qui termine le TLS et exécute MailPlus. Le second est la date de signature à côté de la coche verte. Ouvrez maintenant un seul événement et lisez ce qui s'est réellement déclenché.

Classification Misc Attack, sévérité Moyenne, statut Alerte, nom de signature ET CINS Active Threat Intelligence Poor Reputation IP group 24. Ouvrez le corps de la règle et il commence par alert ip puis une longue liste d'adresses. Il s'agit d'une recherche dans une liste de blocage. Aucune partie de la requête HTTP n'a été lue, car aucune partie ne pouvait l'être. Nous avons échantillonné des événements vers une deuxième destination, notre hôte Virtual DSM, et nous avons trouvé la même classe de règle avec un numéro de groupe différent.

Le résumé honnête d'une semaine est donc le suivant : le routeur a reconnu quelques centaines de connexions provenant d'adresses qui avaient déjà une mauvaise réputation. C'est véritablement utile. Ce n'est pas de la détection d'attaques Web, et personne ne devrait lire le nombre 595 comme si c'en était.

Comment auditer Threat Prevention en 4 étapes #

Avant de faire confiance à Threat Prevention pour quoi que ce soit, passez dix minutes à découvrir ce qu'il fait réellement sur votre propre réseau. Chaque étape ci-dessous est en lecture seule et ne modifie rien.

Là où il mérite vraiment sa place #

Nous gardons Threat Prevention activé, et non par superstition. Il accomplit quatre tâches que rien d'autre dans notre infrastructure ne fait.

• Outbound command and control. This is the strongest case by far. A compromised device has to call home, that call has to leave through the router, and a good share of it is still either cleartext or aimed at a known address. Our router ships the Malware Command and Control Activity class with 3,450 of 3,498 rules enabled, and the Domain Observed Used for C2 class with 7,157 of 7,202.
• Cleartext protocols from the internet. Our mail server answers on port 25, and SMTP is cleartext until STARTTLS. That is real inspectable traffic, and it is no accident that the mail host is the one device our events list keeps naming.
• Scanning and reconnaissance. Port sweeps and fingerprinting are recognised by connection behaviour rather than by payload, so encryption does not hide them.
• Visibility. A searchable log of who knocked and with what reputation is worth having, even when every entry is only a reputation hit. It is monitoring value, and it should be counted as monitoring value rather than as protection.

Ce que ces quatre points ont en commun, c'est qu'aucun d'entre eux n'est une attaque sur un site Web.

Pourquoi le propriétaire d'un site demande la mauvaise chose à Threat Prevention #

Lorsque vous hébergez un site sur un NAS, le chemin de la requête comporte généralement un proxy inverse. Le nôtre ressemble à ceci, et c'est sa structure qui détermine tout :

• The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
• What is left crosses the router, où Threat Prevention ne voit qu'un flux TLS chiffré et rien de plus.
• Le reverse proxy NAS terminates TLS and forwards plain HTTP to the machine that runs the site.
• That last hop is on the same subnet, so the frame goes through a switch and the router is not in the path.

Lisez ces quatre lignes ensemble et le piège est évident. Le seul segment où la requête existe sous une forme lisible est le dernier saut, et c'est le seul segment que le routeur ne peut pas observer. Partout où le routeur peut observer, la requête est chiffrée. Il n'y a aucune case à cocher qui résolve une telle contradiction, et Threat Prevention n'échoue pas lorsqu'il reste silencieux. Il rend compte avec précision d'un trafic qu'il est structurellement incapable de lire.

C'est également la raison pour laquelle orienter Threat Prevention vers un site spécifique ne fonctionne pas. Le paquet est lié aux interfaces du routeur, et non aux noms d'hôte. Il n'a aucune notion du site auquel appartient une connexion, car il ne voit jamais l'en-tête Host.

Trois raisons pour lesquelles PHP2Shell était invisible au niveau du routeur #

PHP2Shell, la paire de failles d'exécution de code à distance avant authentification répertoriées sous les références CVE-2026-109618 et CVE-2026-109619, a fuité le 20 octobre 2026 et a été corrigée en amont le lendemain. C'est exactement le genre de chose que les gens espèrent qu'un IPS de routeur va absorber, et il convient de détailler pourquoi il n'a pas pu le faire.

Premièrement, le trafic était chiffré sur tous les segments surveillés par le routeur. The exploit lives in the HTTP request, and the HTTP request only exists in the clear after TLS has been terminated, which happens downstream of the router on a hop the router never carries.

Deuxièmement, aucune signature Threat Prevention n'existe à activer. We checked again on 25 October 2026 and found no published Snort or Emerging Threats rule for either CVE. Our feed is ET Open, the free tier, which lags the commercial set, and the Self-Defined Policy screen accepts no rule of your own. So even an operator who knew precisely what to match for had nowhere to put it.

Troisièmement, et de manière plus fondamentale, cette attaque n'a aucune forme de charge utile à faire correspondre. The chain takes two requests. The first has to push PHP into exhausting its memory limit, which makes the engine abandon a request through a path that skips cleanup and leaves some global state behind. The second request is ordinary, and it is the one that reaches a stale pointer and turns into code execution.

La première requête est définie par la quantité de mémoire qu'elle consomme, et non par une séquence d'octets, et un téléversement volumineux, un corps JSON énorme, un tableau profond et une longue chaîne dans une expression régulière conviennent tous. La seconde ne transporte aucun octet malveillant. Un IPS prend ses décisions par paquet et par flux. Il ne dispose d'aucun modèle de processus worker portant un état contaminé d'une requête à la suivante, ce qui est précisément là où réside ce bogue.

Cela fixe également les limites de la mesure d'atténuation circulant à l'époque, qui consistait à désactiver session.upload_progress dans la configuration PHP. Cela supprime en effet un moyen bien documenté d'atteindre la seconde CVE, et sur une machine que vous ne pouvez vraiment pas corriger, c'est mieux que rien. Ce n'est pas un correctif : l'épuisement de la mémoire n'est pas accessible uniquement via cette seule fonctionnalité, et le paramètre n'a aucun impact sur la CVE-2026-109618. Nous l'avons utilisé comme solution temporaire sur un seul hôte et l'avons considéré comme un répit provisoire, et non comme une résolution. Le compte rendu complet de la manière dont nous avons appliqué le correctif se trouve dans notre PHP2Shell write-up.

« Fail Open » par conception, et le jour où cela nous a coûté notre courrier électronique #

Il y a une autre propriété qui mérite d'être connue avant de considérer Threat Prevention comme une mesure de contrôle fiable. Son mode par défaut recommandé est le mode de priorité à la stabilité du réseau, et l'interface indique clairement ce que cela signifie : lorsque le trafic dépasse la capacité de traitement, les paquets en attente sont ignorés sans être filtrés. L'alternative, le mode de priorité à la sécurité, les rejette plutôt et avertit que la connexion sera instable jusqu'à ce que le problème soit résolu.

C'est un choix par défaut raisonnable pour un routeur domestique. Cela signifie toutefois que Threat Prevention est au plus faible au moment exact où vous le souhaiteriez le plus fort, car une saturation est à la fois ce que vous voulez filtrer et ce qui dépasse la capacité.

Nous avons également enregistré l'autre mode de défaillance. Le 2 août 2026, quelqu'un a pilonné notre proxy inverse à 116 reprises avec un exploit ciblant un bogue PHP-CGI sous Windows qui ne peut absolument pas fonctionner sur Linux. Threat Prevention a rejeté suffisamment de paquets pour bloquer son propre état, puis a commencé à refuser le trafic sortant de la machine même qu'il défendait. Notre file d'attente de courrier s'est bloquée et le symptôme ressemblait exactement à une panne DNS. Le redémarrage du routeur a résolu le problème. Rien n'est apparu dans le journal d'accès du proxy, car rien n'a jamais atteint le proxy. Une attaque qui était structurellement incapable de réussir nous a tout de même coûté une interruption de service, par l'intermédiaire du composant censé l'arrêter.

Regardez le nombre de règles activées dans cette liste pendant que vous y êtes. Web Application Attack affiche 5 928 règles actives sur 6 010, et le ratio est similaire dans les classes qui nous intéressent. Activer une classe n'active pas toutes les règles qu'elle contient, et l'interface ne vous permet aucunement de voir quelles sont les règles restantes qui vous manquent.

Placez un proxy en amont, puis verrouillez l'origine dessus #

Si vous hébergez un site web depuis un NAS, le contrôle qui accomplit la tâche que le routeur ne peut pas faire est un WAF à reverse proxy. Nous utilisons Cloudflare, et la raison tient à sa position plutôt qu'à la marque : la terminaison TLS se fait à l'edge, de sorte que l'intégralité de la requête est lisible au moment où la décision est prise. Méthode, chemin, requête, en-têtes, cookies et corps de la requête sont tous accessibles pour une règle.

C'est pourquoi les protections PHP2Shell sont arrivées là et non sur le routeur. Lorsque les CVE ont été divulguées, le jeu de règles gérées a obtenu sept règles pour cette paire en deux jours, et elles étaient actives sur l'ensemble des quatre zones que nous exploitons avant même que nous n'ayons fini de reconstruire nos propres conteneurs. Aucun équivalent n'est jamais apparu dans le flux Threat Prevention, et cinq jours plus tard, il n'y a toujours aucune règle Snort ou Emerging Threats publique à installer.

Un avertissement qui importe plus que le choix du fournisseur. Un proxy en amont ne sert à rien s'il peut être contourné. Si votre adresse d'origine répond directement à l'internet public, quiconque la découvre outrepassera toutes les règles edge que vous avez écrites. Restreignez le port 443 sur l'origine aux plages réseau du proxy, récupérez ces plages depuis l'endpoint du fournisseur plutôt que de les coder en dur, et vérifiez le verrouillage en interrogeant le site directement depuis son adresse. Notre configuration plus vaste, ainsi que les quatre couches derrière celle-ci, sont décrites dans the five layers we run.

Limites et notes de sécurité de Threat Prevention #

Threat Prevention nécessite un stockage externe sur le routeur et n'est pas disponible sur tous les modèles, vérifiez donc la prise en charge de votre matériel avant de planifier son utilisation. Le moteur est également le composant le plus sollicité de votre routeur, et sur un modèle grand public, c'est le composant le plus susceptible de devenir le plafond de débit. Mesurez avant et après plutôt que de vous fier aux chiffres du marketing.

Considérez chaque nombre affiché sur l'écran d'aperçu comme un nombre de correspondances de signatures, et non comme un nombre d'attaques bloquées. Les deux diffèrent dans les deux sens. Un impact de réputation contre un scanner qui n'allait de toute façon rien obtenir gonfle le total, et une semaine calme ne prouve rien concernant le trafic HTTPS que le moteur ne peut pas lire.

Dans Threat Prevention, le statut importe tout autant que la sévérité. L'option « Ignorer automatiquement les paquets à haut risque » n'agit que sur le niveau élevé, de sorte que les entrées de sévérité moyenne sont enregistrées et transmises. Une interface qui affiche Alerte vous indique que le paquet a été délivré.

Le flux de signatures est une chaîne d'approvisionnement. ET Open se rafraîchit selon un calendrier, accuse un retard par rapport au jeu de règles commercial, et peut ne rien fournir du tout pour une vulnérabilité datant de plusieurs jours. Un tableau de bord qui indique que la base de données est à jour indique qu'elle correspond au flux, et non que le flux couvre ce qui est actuellement exploité.

Rien de tout cela ne remplace l'application des correctifs. Chaque couche abordée ici permet de gagner du temps pour ce qui corrige réellement une vulnérabilité : la mise à jour du logiciel concerné. Pour PHP2Shell, cela signifiait de nouveaux paquets PHP et des conteneurs reconstruits, et aucun contrôle réseau ne s'y substituait.

Enfin, résistez à la tentation d'activer chaque classe après avoir lu un avis de sécurité. Les classes comme Misc activity contiennent des milliers de règles à faible valeur qui génèrent principalement du bruit et consomment la même capacité dont les classes utiles ont besoin. Une liste d'événements calme et bien réglée que vous lisez réellement vaut mieux qu'une liste bruyante que vous apprenez à ignorer.

Questions fréquemment posées #

Références et visites guidées vidéo #

Sources principales pour tout ce qui est énoncé ci-dessus, ainsi que trois guides détaillés qui valent le détour.

• Centre de connaissances Synology : Threat Prevention covers requirements, modes and model support.
• Synology-SA-26:14 lists the fixed PHP package versions for DSM, including the 7.4 build.
• Synology Statement on PHP2Shell names the affected packages and the one that needs a manual update.
• Cloudflare WAF managed rules explains how managed rulesets are versioned and deployed.
• Plages d'adresses IP de Cloudflare is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.