Synology Threat Prevention: Cosa rileva e cosa non vede

Threat Prevention è il pacchetto a cui la maggior parte delle persone si rivolge nel momento in cui decide di ospitare un sito web su un NAS Synology. Risiede sul router, ha un'icona a forma di scudo e la sua dashboard conta gli attacchi a centinaia, quindi sembra proprio ciò che mantiene al sicuro un sito pubblico. Lo eseguiamo su un RT6600ax davanti a ogni macchina in nostro possesso, ed è valsa la pena averlo. È anche, per un sito web in self-hosting, quasi del tutto irrilevante.

Questo articolo della guida NAS Hosting 101 apre il nostro router, legge una settimana reale di eventi e mostra esattamente dove Threat Prevention smette di essere d'aiuto, utilizzando PHP2Shell come esempio di un attacco che Threat Prevention non avrebbe mai potuto rilevare.

Punto SynoPower Club: Ho trascorso molto tempo nel supporto Synology e la domanda arrivava continuamente: quale opzione devo attivare per fermare questo attacco. È l'istinto giusto rivolto allo strumento sbagliato. Ciò che mi ha finalmente fatto aprire gli occhi è stato leggere la nostra lista degli eventi anziché la pagina delle funzionalità. Ogni avviso registrato dal nostro router questo mese riguardava un indirizzo con una cattiva reputazione, non una richiesta con un payload malevolo. Una volta compreso questo, smetti di chiedere a Threat Prevention di ispezionare il traffico che sta tenendo in una busta sigillata.

Cosa fa effettivamente Threat Prevention su un router Synology #

Threat Prevention è un sistema di rilevamento e prevenzione delle intrusioni basato sulla linea di sviluppo di Snort e Suricata. Legge i pacchetti mentre il router li inoltra, li confronta con un set di firme e registra un avviso o scarta il pacchetto. Sul nostro RT6600ax il feed delle firme è ET Open, il livello gratuito del set di regole Emerging Threats, aggiornato quotidianamente alle 09:00.

Tre proprietà derivano da questa architettura, e tutte e tre contano più di qualsiasi casella di controllo nell'interfaccia:

• 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 readNon c'è alcuna intercettazione TLS in Threat Prevention, quindi un payload crittografato rimane opaco.
• 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.

Niente di tutto ciò è un difetto. Un IPS sul perimetro della rete è una cosa ragionevole e utile da avere. L'errore sta nel presumere che il perimetro sia il punto in cui un sito web viene attaccato.

Threat Prevention vs Web Application Firewall #

Il modo più chiaro per vedere la differenza è mettere Threat Prevention accanto a un Web Application Firewall e chiedersi cosa stia analizzando ciascuno di essi quando prende una decisione. Threat Prevention analizza un pacchetto. Un WAF analizza una richiesta HTTP decifrata.

Question	Router IPS	Reverse-proxy WAF
Dove corre	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

Non si tratta di prodotti in concorrenza tra loro. Coprono segmenti diversi dello stesso percorso e un sito in self-hosting ha un bisogno molto maggiore del secondo che del primo. Li manteniamo entrambi e ci aspettiamo cose completamente diverse da ciascuno.

Lettura di 595 eventi in una settimana sul nostro router #

Ecco la schermata panoramica di Threat Prevention del nostro router di produzione il 25 ottobre 2026. Cinquecentonovantacinque eventi malevoli nell'arco di sette giorni, di cui 75 ad alta gravità. Sembra un muro che trattiene un'inondazione.

Due dettagli in quella schermata valgono più del numero principale. Il primo è che un solo dispositivo appare tra le potenziali minacce, ed è REVERSE_MAIL, la macchina che termina TLS ed esegue MailPlus. Il secondo è la data della firma accanto alla spunta verde. Ora apri un singolo evento e leggi cosa è scattato effettivamente.

Classificazione Misc Attack, gravità Media, stato Alert, nome della firma ET CINS Active Threat Intelligence Poor Reputation IP group 24. Apri il corpo della regola e inizia con alert ip seguito da un lungo elenco di indirizzi. Questa è una consultazione di una blocklist. Nessuna parte della richiesta HTTP è stata letta, perché nessuna parte poteva esserlo. Abbiamo analizzato gli eventi rispetto a una seconda destinazione, il nostro host Virtual DSM, e abbiamo trovato la stessa classe di regola con un numero di gruppo diverso.

Quindi l'onesto riassunto di una settimana è questo: il router ha riconosciuto alcune centinaia di connessioni da indirizzi che avevano già una cattiva reputazione. Questo è davvero utile. Ma non si tratta di rilevamento di attacchi web, e nessuno dovrebbe interpretare il numero 595 come se lo fosse.

Come controllare Threat Prevention in 4 passaggi #

Prima di affidare qualsiasi cosa a Threat Prevention, dedica dieci minuti a scoprire cosa sta effettivamente facendo sulla tua rete. Ogni passaggio seguente è in sola lettura e non modifica nulla.

Dove si guadagna davvero il suo posto #

Manteniamo Threat Prevention attivo, e non per superstizione. Ci sono quattro compiti che svolge e che nessun altro elemento del nostro stack fa.

• 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.

Ciò che questi quattro compiti hanno in comune è che nessuno di essi è un attacco a un sito web.

Perché il proprietario di un sito chiede a Threat Prevention la cosa sbagliata #

Quando si ospita un sito su un NAS, il percorso della richiesta include solitamente un reverse proxy. Il nostro si presenta così, ed è la sua struttura a determinare tutto:

• The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
• What is left crosses the router, dove Threat Prevention vede un flusso TLS crittografato e niente di più.
• IL 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.

Leggendo queste quattro righe insieme, la trappola è ovvia. L'unico segmento in cui la richiesta esiste in forma leggibile è l'ultimo hop, ed è proprio l'unico segmento che il router non può osservare. In ogni punto che il router può osservare, la richiesta è crittografata. Non esiste alcuna casella di controllo in grado di risolvere una contraddizione del genere e Threat Prevention non sta sbagliando quando rimane in silenzio. Sta semplicemente riportando con precisione il traffico che è strutturalmente impossibilitato a leggere.

Questo è anche il motivo per cui puntare Threat Prevention su un sito specifico non funziona. Il pacchetto è vincolato alle interfacce del router, non agli hostname. Non ha alcuna nozione di quale dei tuoi siti appartenga a una connessione, perché non vede mai l'intestazione Host.

Tre motivi per cui PHP2Shell era invisibile al router #

PHP2Shell, la coppia di falle di esecuzione di codice remoto pre-autenticazione tracciate come CVE-2026-109618 e CVE-2026-109619, è stata divulgata il 20 ottobre 2026 ed è stata corretta a monte il giorno successivo. È esattamente il tipo di problema che le persone sperano che un IPS per router sia in grado di assorbire, e vale la pena essere specifici sul perché non abbia potuto farlo.

In primo luogo, il traffico era crittografato su ogni segmento monitorato dal router. 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.

In secondo luogo, non esiste alcuna firma di Threat Prevention da attivare. 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.

Terzo, e ancor più fondamentale, questo attacco non ha una struttura di payload da confrontare. 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 prima richiesta è definita dalla quantità di memoria che consuma, non da una sequenza di byte, e un caricamento di grandi dimensioni, un corpo JSON enorme, un array profondo e una stringa lunga in un'espressione regolare ne sono tutti un esempio. La seconda non trasporta alcun byte malevolo. Un IPS decide per pacchetto e per flusso. Non ha alcun modello di processo worker che trasporta uno stato contaminato da una richiesta a quella successiva, che è esattamente dove risiede questo bug.

Questo fissa anche i limiti della mitigazione che circolava all'epoca, che consisteva nel disattivare session.upload_progress nella configurazione di PHP. Rimuove effettivamente un modo ben documentato per raggiungere il secondo CVE e, su una macchina che non puoi davvero aggiornare, è meglio di niente. Non è una soluzione definitiva: l'esaurimento della memoria non è raggiungibile solo tramite quella singola funzionalità e l'impostazione non ha alcun impatto su CVE-2026-109618. L'abbiamo usata come soluzione temporanea su un solo host e l'abbiamo considerata come tempo guadagnato, non come una risoluzione. Il resoconto completo di come abbiamo applicato le patch è nel nostro PHP2Shell write-up.

Fail-open per progettazione, e il giorno in cui ci è costato le nostre e-mail #

C'è un'altra proprietà che vale la pena conoscere prima di considerare Threat Prevention come un controllo su cui fare affidamento. La sua modalità predefinita consigliata è la modalità di priorità alla stabilità della rete, e l'interfaccia spiega cosa significa senza alcun eufemismo: quando il traffico supera la capacità di elaborazione, i pacchetti in sospeso vengono lasciati passare senza filtraggio. L'alternativa, la modalità di priorità alla sicurezza, li scarta e avverte che la connessione sarà instabile fino alla risoluzione del problema.

Si tratta di un'impostazione predefinita ragionevole per un router domestico. Significa però che Threat Prevention è nel suo punto più debole proprio nel momento in cui vorresti che fosse più forte, perché un traffico anomalo di tipo flood è sia ciò che desideri filtrare sia ciò che supera la capacità del sistema.

Abbiamo anche documentato l'altra modalità di guasto. Il 2 agosto 2026 qualcuno ha colpito ripetutamente il nostro reverse proxy 116 volte con un exploit per un bug PHP-CGI per Windows che non può funzionare su Linux. Threat Prevention ha scartato abbastanza pacchetti da bloccare il proprio stato, per poi iniziare a rifiutare il traffico in uscita della macchina stessa che stava difendendo. La nostra coda di posta si è bloccata e il sintomo sembrava esattamente un guasto del DNS. Il riavvio del router ha risolto il problema. Nulla è apparso nel registro degli accessi del proxy, perché nulla ha mai raggiunto il proxy. Un attacco strutturalmente incapace di avere successo ci è comunque costato un'interruzione di servizio, a causa dello strumento che avrebbe dovuto fermarlo.

Dai un'occhiata ai conteggi di abilitazione in quell'elenco mentre sei lì. Web Application Attack mostra 5.928 su 6.010 regole attive e il rapporto è simile nelle classi che ci interessano. Attivare una classe non attiva tutte le regole al suo interno e l'interfaccia non offre alcun modo per vedere quali tra le rimanenti ti mancano.

Metti un proxy davanti, poi blocca l'origine su di esso #

Se gestisci un sito web da un NAS, il controllo che svolge il lavoro che il router non può fare è un WAF reverse-proxy. Utilizziamo Cloudflare, e il motivo risiede nella posizione piuttosto che nel marchio: TLS termina all'edge, quindi l'intera richiesta è leggibile nel momento in cui viene presa la decisione. Metodo, percorso, query, header, cookie e corpo sono tutti disponibili per una regola.

Ecco perché le protezioni PHP2Shell sono arrivate lì e non sul router. Quando sono emersi i CVE, il set di regole gestito ha ottenuto sette regole per la coppia nel giro di due giorni, ed erano attive su tutte e quattro le zone che gestiamo prima ancora che avessimo finito di ricompilare i nostri container. Nessun equivalente è mai apparso nel feed di Threat Prevention e, cinque giorni dopo, non esiste ancora alcuna regola pubblica Snort o Emerging Threats da installare.

Un avvertimento che conta più della scelta del provider. Un proxy posizionato davanti aiuta solo fino a quando non lo si può aggirare. Se l'indirizzo di origine risponde direttamente a Internet pubblico, chiunque lo scopra salta ogni regola edge che hai scritto. Limita la porta 443 sull'origine agli intervalli di rete del proxy, ricava tali intervalli dall'endpoint del provider anziché digitarli a riga di codice, e verifica il blocco richiedendo il sito direttamente dal suo indirizzo. La nostra configurazione più ampia, e i quattro livelli dietro a questo, sono descritti in the five layers we run.

Limiti di Threat Prevention e note di sicurezza #

Threat Prevention richiede una memoria esterna sul router e non è disponibile su tutti i modelli, quindi conferma il supporto per il tuo hardware prima di pianificarne l'uso. Il motore è anche l'elemento che lavora di più nel router e, su un'unità consumer, è il componente che più facilmente diventa il limite per il throughput. Misura le prestazioni prima e dopo anziché fidarti della cifra di marketing.

Considera ogni numero nella schermata panoramica come un conteggio di corrispondenze di firme, non come un conteggio di attacchi bloccati. I due differiscono in entrambe le direzioni. Un riscontro di reputazione contro uno scanner che non avrebbe mai ottenuto nulla gonfia il totale, e una settimana tranquilla non prova nulla sul traffico HTTPS che il motore non può leggere.

In Threat Prevention, lo stato conta quanto la gravità. "Drop high-risk packets automatically" agisce solo sulla fascia alta, quindi le voci a gravità media vengono registrate e inoltrate. Un'interfaccia che mostra Alert ti sta dicendo che il pacchetto è stato consegnato.

Il feed delle firme è una catena di fornitura. ET Open si aggiorna a intervalli programmati, è in ritardo rispetto al set di regole commerciale e potrebbe non rilasciare nulla per una vulnerabilità risalente a diversi giorni prima. Una dashboard che segnala che il database è aggiornato indica che corrisponde al feed, non che il feed copra ciò che viene attualmente sfruttato.

Niente di tutto ciò sostituisce l'applicazione delle patch. Ogni livello qui discusso fa guadagnare tempo per ciò che chiude effettivamente una vulnerabilità, ovvero l'aggiornamento del software interessato. Per PHP2Shell ciò ha significato nuovi pacchetti PHP e container ricreati, e nessun controllo di rete è stato in grado di sostituirlo.

Infine, resisti alla tentazione di attivare ogni classe dopo aver letto un avviso di sicurezza. Classi come Misc activity contengono migliaia di regole di poco valore che generano principalmente rumore e consumano la stessa capacità necessaria alle classi utili. Un elenco di eventi silenzioso e ben ottimizzato che leggi davvero è meglio di uno rumoroso che impari a ignorare.

Domande frequenti #

Riferimenti e video dimostrativi #

Fonti primarie per tutto ciò che è stato affermato sopra, più tre guide dettagliate che valgono il tempo impiegato.

• Centro conoscenze 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.
• Intervalli IP di Cloudflare is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.