Synology Threat Prevention: Wat het onderschept en wat het niet kan zien
Bijgewerkt op 25 oktober 2026
Threat Prevention is het pakket waar de meeste mensen naar grijpen op het moment dat ze besluiten een website te hosten op een Synology NAS. Het bevindt zich op de router, het heeft een schildpictogram en het dashboard telt honderden aanvallen, dus het lijkt hetgeen dat een openbare site veilig houdt. We draaien het op een RT6600ax voor elke machine die we bezitten, en het is de moeite waard geweest om te hebben. Voor een zelfgehoste website is het echter ook vrijwel geheel naast de kwestie.
Dit NAS Hosting 101-artikel opent onze eigen router, leest er een echte week aan gebeurtenissen uit af en laat precies zien waar Threat Prevention niet meer kan helpen, met PHP2Shell als voorbeeld van een aanval die Threat Prevention nooit zou zien.
SynoPower Club-punt: Ik heb een lange tijd bij Synology support gewerkt en de vraag kwam voortdurend binnen: welke optie moet ik inschakelen om deze aanval te stoppen. Het is het juiste instinct, gericht op het verkeerde apparaat. Wat het voor mij uiteindelijk duidelijk maakte, was het lezen van onze eigen gebeurtenissenlijst in plaats van de functiepagina. Elke waarschuwing die onze router deze maand heeft geregistreerd, was een adres met een slechte reputatie, niet een verzoek met een slechte payload. Zodra u dat hebt gezien, stopt u met het vragen aan Threat Prevention om verkeer te inspecteren dat in een verzegelde envelop zit.
Wat Threat Prevention daadwerkelijk doet op een Synology-router #
Threat Prevention is een inbraakdetectie- en preventiesysteem dat is gebouwd op de Snort- en Suricata-reeks. Het leest pakketten terwijl de router ze doorstuurt, vergelijkt ze met een regelset (signatures) en registreert een melding of blokkeert het pakket. Op onze RT6600ax is de signature-feed ET Open, de gratis versie van de Emerging Threats-regelset, dagelijks bijgewerkt om 09:00 uur.
Uit dat ontwerp volgen drie eigenschappen, en alle drie zijn ze belangrijker dan welk selectievakje in de interface dan ook:
- 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 readEr is nergens TLS-interceptie in Threat Prevention, dus een versleutelde payload is ondoorzichtig.
- 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.
Niets daarvan is een defect. Een IPS aan de netwerkperimeter is een verstandige en nuttige voorziening. De fout is aan te nemen dat de perimeter de plek is waar een website wordt aangevallen.
Threat Prevention versus een Web Application Firewall #
De duidelijkste manier om het verschil te zien, is door Threat Prevention naast een web application firewall te plaatsen en te vragen wat elk van beide vasthoudt wanneer het een beslissing neemt. Threat Prevention houdt een pakket vast. Een WAF houdt een ontsleuteld HTTP-verzoek vast.
| Question | Router IPS | Reverse-proxy WAF |
|---|---|---|
| Waar het loopt | 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 |
Dat zijn geen concurrerende producten. Ze dekken verschillende segmenten van hetzelfde traject af, en een zelfgehoste site heeft de tweede veel meer nodig dan de eerste. We behouden ze allebei en verwachten van elk totaal andere dingen.
595 gebeurtenissen in één week aflezen op onze eigen router #
Hier is het overzichtsscherm van Threat Prevention op onze productierouter op 25 oktober 2026. Vijfhonderdvijfennegentig kwaadaardige gebeurtenissen over zeven dagen, waarvan 75 met hoge ernst. Het leest als een muur die een vloedgolf tegenhoudt.
Twee details in dat scherm zijn meer waard dan het hoofdgetal. Het eerste is dat er slechts één apparaat verschijnt onder potentiële bedreigingen, en dat is REVERSE_MAIL, de machine die TLS beëindigt en MailPlus uitvoert. Het tweede is de signature-datum naast het groene vinkje. Open nu één enkele gebeurtenis en lees wat er werkelijk is geactiveerd.
Classification Misc Attack, severity Medium, status Alert, signature name ET CINS Active Threat Intelligence Poor Reputation IP group 24. Open de regelinhoud en het begint met alert ip en daarna een lange lijst met adressen. Dat is een opzoeking in een blokkeerlijst. Geen enkel onderdeel van het HTTP-verzoek werd gelezen, omdat geen enkel onderdeel gelezen kon worden. We hebben gebeurtenissen gestreekproefd tegen een tweede bestemming, onze Virtual DSM-host, en vonden dezelfde regelklasse met een ander groepsnummer.
Dus de eerlijke samenvatting van één week is dit: de router herkende een paar honderd verbindingen van adressen die al een slechte naam hadden. Dat is oprecht nuttig. Het is geen detectie van webaanvallen, en niemand zou het getal 595 moeten interpreteren alsof dat wel zo was.
Threat Prevention controleren in 4 stappen #
Voordat u Threat Prevention met wat dan ook vertrouwt, neemt u tien minuten de tijd om uit te zoeken wat het daadwerkelijk doet op uw eigen netwerk. Elke onderstaande stap is alleen-lezen en verandert niets.
Open één gebeurtenis en lees de handtekeningtekst #
Ga naar Threat Prevention, vervolgens Gebeurtenissen en klik op een willekeurige vermelding. Kijk voorbij de gekleurde ernstbadge naar het vak Handtekeningregels. Een regel die begint met alert ip vergelijkt alleen op adresreputatie. Een regel die content of pcre bevat, vergelijkt op payload. Tel hoeveel u er van elk kunt vinden in uw eigen lijst voordat u beslist wat Threat Prevention beschermt.
Controleer welke interfaces worden gemonitord #
Open Instellingen en lees de tabel Gemonitorde interfaces. Alleen de interfaces die daar zijn aangevinkt worden geïnspecteerd, en bij een normale implementatie zijn dat de interfaces die op het internet zijn gericht. Verkeer tussen twee apparaten op hetzelfde LAN-subnet wordt geswitcht in plaats van gerouteerd, dus het bereikt nooit de inspectie-engine en geen enkele instelling op deze pagina kan dat veranderen.
Ontdek wat er gebeurt als de router het druk heeft #
Kijk in hetzelfde paneel naar de standaardmodus. Prioriteit voor netwerkstabiliteit betekent dat wanneer het verkeer de verwerkingscapaciteit van de engine overschrijdt, het overschot ongefilterd wordt doorgelaten. Beveiligingsprioriteit betekent dat het overschot in plaats daarvan wordt gedropt. De ene keuze faalt open en houdt uw verbinding in de lucht, de andere faalt gesloten en haalt uw verbinding onderuit. Bepaal welke u daadwerkelijk wilt.
Try to add a rule of your own #
Open Self-Defined Policy. You can change the action for a signature the vendor already ships, and you can scope it by source or destination address. There is no field anywhere that accepts a signature you wrote. If your threat is newer than your signature feed, this screen is where you discover you have no way to respond.
Waar het werkelijk zijn plaats verdient #
We houden Threat Prevention ingeschakeld, en niet uit bijgeloof. Er zijn vier taken die het uitvoert en die niets anders in onze stack doet.
- 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.
Wat die vier gemeen hebben, is dat geen van alle een aanval op een website is.
Waarom een site-eigenaar Threat Prevention om het verkeerde vraagt #
Wanneer u een site op een NAS host, bevat het verzoekpad meestal een reverse proxy. Het onze ziet er zo uit, en die vorm bepaalt alles:
- The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
- What is left crosses the router, waar Threat Prevention een versleutelde TLS-stream ziet en niets meer.
- De 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.
Lees die vier regels samen en de valkuil is duidelijk. Het enige segment waar het verzoek in leesbare vorm bestaat, is de laatste hop, en dat is precies het ene segment dat de router niet kan observeren. Overal waar de router kan observeren, is het verzoek versleuteld. Er is geen selectievakje dat een dergelijke tegenstrijdigheid oplost, en Threat Prevention faalt niet wanneer het stil blijft. Het rapporteert nauwkeurig over verkeer dat het structureel niet kan lezen.
Dit is ook waarom het richten van Threat Prevention op een specifieke site niet werkt. Het pakket is gebonden aan routerinterfaces, niet aan hostnamen. Het heeft geen idee bij welke van uw sites een verbinding hoort, omdat het de Host-header nooit ziet.
Drie redenen waarom PHP2Shell onzichtbaar was bij de router #
PHP2Shell, het paar kwetsbaarheden voor remote code execution zonder authenticatie bijgehouden als CVE-2026-109618 en CVE-2026-109619, lekte uit op 20 oktober 2026 en werd de volgende dag upstream gepatcht. Het is precies het soort ding waarvan mensen hopen dat een router-IPS het zal opvangen, en het is de moeite waard om specifiek te zijn over waarom het dat niet kon.
Ten eerste was het verkeer versleuteld op elk segment dat de router in de gaten houdt. 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.
Ten tweede bestaat er geen Threat Prevention-handtekening om in te schakelen. 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.
Ten derde, en het meest fundamenteel, heeft deze aanval geen payload-vorm om op te matchen. 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.
Het eerste verzoek wordt gedefinieerd door hoeveel geheugen het verbruikt, niet door een reeks bytes, en een grote upload, een enorme JSON-body, een diepe array en een lange string in een reguliere expressie komen allemaal in aanmerking. Het tweede bevat helemaal geen kwaadaardige bytes. Een IPS beslist per pakket en per stroom. Het heeft geen model van een worker-proces dat gecontamineerde status overdraagt van het ene verzoek naar het volgende, wat precies is waar deze bug zich bevindt.
Dat stelt ook de grenzen aan de mitigatie die destijds de ronde deed, namelijk het uitschakelen van session.upload_progress in de PHP-configuratie. Het verwijdert weliswaar één goed gedocumenteerde manier om de tweede CVE te bereiken, en op een machine die u echt niet kunt patchen is het beter dan niets. Het is geen definitieve oplossing: geheugenuitputtingsgevaren zijn niet alleen via die ene functie bereikbaar, en de instelling heeft helemaal geen invloed op CVE-2026-109618. We hebben het als tussenoplossing op precies één host gebruikt en het beschouwd als geleende tijd, niet als een definitieve oplossing. Het volledige verslag van hoe we hebben gepatcht staat in onze PHP2Shell write-up.
Fail Open by Design, en de dag dat het ons onze e-mail kostte #
Er is nog een eigenschap die het waard is om te weten voordat u Threat Prevention beschouwt als een beveiligingsmaatregel waarop u kunt vertrouwen. De aanbevolen standaardmodus is de netwerkstabiliteit-prioriteitsmodus, en de interface vermeldt zonder enig euphemisme wat dat betekent: wanneer het verkeer de verwerkingscapaciteit overschrijdt, worden in behandeling zijnde pakketten omgeleid zonder te worden gefilterd. Het alternatief, de beveiligingsprioriteitsmodus, verwijdert ze in plaats daarvan en waarschuwt dat de verbinding onstabiel zal zijn totdat het probleem is opgelost.
Dat is een verstandige standaardinstelling voor een thuisrouter. Het betekent wel dat Threat Prevention op z'n zwakst is op precies het moment dat u het op z'n sterkst zou willen hebben, omdat een overspoeling (flood) zowel het ding is dat u wilt laten filteren als het ding dat de capaciteit overschrijdt.
We hebben ook de andere foutmodus geregistreerd. Op 2 augustus 2026 bestookte iemand onze reverse proxy 116 keer met een exploit voor een Windows PHP-CGI-bug die helemaal niet kan werken tegen Linux. Threat Prevention liet genoeg pakketten vallen om de eigen status vast te laten lopen, en begon vervolgens het uitgaande verkeer te weigeren van exact de machine die het verdedigde. Onze e-mailwachtrij liep vast en het symptoom zag er precies uit als een DNS-storing. Het herstarten van de router loste het op. Er verscheen niets in het access log van de proxy, omdat niets de proxy ooit bereikte. Een aanval die structureel niet in staat was om te slagen, kostte ons toch een storing, via hetgeen dat verondersteld werd het te stoppen.
Kijk naar de aantallen ingeschakelde regels in die lijst terwijl u daar bent. Web Application Attack toont 5.928 van de 6.010 regels actief, en de verhouding is vergelijkbaar in de klassen die voor ons van belang zijn. Het inschakelen van een klasse schakelt niet elke regel daarin in, en de interface biedt geen mogelijkheid om te zien welke van de overige regels u mist.
Plaats een proxy aan de voorkant en vergrendel de origin hierop #
Als u een website host vanaf een NAS, is de maatregel die het werk doet dat de router niet kan, een reverse-proxy WAF. We gebruiken Cloudflare, en de reden is positie in plaats van merk: TLS eindigt op de edge, dus het volledige verzoek is leesbaar op het moment dat de beslissing wordt genomen. Methode, pad, query, headers, cookies en body zijn allemaal beschikbaar voor een regel.
Dat is waarom de PHP2Shell-beveiligingen daar arriveerden en niet op de router. Toen de CVE's bekend werden, kreeg de beheerde regelset binnen twee dagen zeven regels voor het paar, en ze waren live op alle vier de zones die we beheren voordat we klaar waren met het herbouwen van onze eigen containers. Er is nooit een equivalent verschenen in de Threat Prevention-feed, en vijf dagen later is er nog steeds geen openbare Snort- of Emerging Threats-regel om te installeren.
Eén waarschuwing die belangrijker is dan de keuze van de provider. Een proxy aan de voorkant helpt alleen zolang deze niet kan worden omzeild. Als uw origin-adres rechtstreeks antwoordt op het openbare internet, slaat iedereen die het ontdekt elke edge-regel over die u hebt geschreven. Beperk poort 443 op de origin tot de netwerkreeksen van de proxy, haal die reeksen op via het provider-eindpunt in plaats van ze hard te coderen, en verifieer de vergrendeling door de site rechtstreeks vanaf het adres op te vragen. Onze bredere opzet en de vier lagen achter deze worden beschreven in the five layers we run.
Threat Prevention-beperkingen en veiligheidsopmerkingen #
Threat Prevention vereist externe opslag op de router en is niet op elk model beschikbaar, dus controleer de ondersteuning voor uw hardware voordat u hierop plant. De engine is ook het drukste onderdeel van uw router en op een consumentenapparaat is dit de component die het meest waarschijnlijk de limiet voor de doorvoer wordt. Meet voor en na in plaats van te vertrouwen op het marketingcijfer.
Beschouw elk getal op het overzichtsscherm als het aantal handtekeningovereenkomsten, niet als het aantal gestopte aanvallen. De twee verschillen in beide richtingen. Een reputatiehit tegen een scanner die toch nooit iets zou bereiken, blaast het totaal op, en een rustige week bewijst niets over het HTTPS-verkeer dat de engine niet kan lezen.
In Threat Prevention is status net zo belangrijk als ernst. 'Pakketten met een hoog risico automatisch negeren' werkt alleen op de hoge categorie, dus vermeldingen met een gemiddelde ernst worden geregistreerd en doorgestuurd. Een interface die 'Alert' aangeeft, vertelt u dat het pakket is afgeleverd.
De handtekeningfeed is een toeleveringsketen. ET Open vernieuwt volgens een schema, loopt achter op de commerciële regelset en levert mogelijk helemaal niets voor een kwetsbaarheid die al dagen oud is. Een dashboard dat meldt dat de database up-to-date is, meldt dat deze overeenkomt met de feed, niet dat de feed dekt wat momenteel wordt misbruikt.
Niets van dit alles vervangt het patchen. Elke laag die hier wordt besproken, koopt tijd voor datgene wat een kwetsbaarheid daadwerkelijk dicht, namelijk het bijwerken van de getroffen software. Voor PHP2Shell betekende dat nieuwe PHP-pakketten en opnieuw gebouwde containers, en geen enkele netwerkbeveiliging kon dat vervangen.
Weersta ten slotte de neiging om elke klasse in te schakelen na het lezen van een beveiligingsadvies. Klassen zoals Misc activity bevatten duizenden regels met lage waarde die voornamelijk ruis genereren en dezelfde capaciteit verbruiken die de nuttige klassen nodig hebben. Een rustige, goed afgestelde gebeurtenissenlijst die u daadwerkelijk leest, is beter dan een drukke lijst die u leert te negeren.
Veelgestelde vragen #
Beschermt Threat Prevention een website die op mijn NAS wordt gehost? #
Nauwelijks, en niet op de manier die de naam doet vermoeden. Een website wordt geserveerd via HTTPS en Threat Prevention voert geen TLS-interceptie uit, dus het verzoek is ondoorzichtig waar de router het kan zien. Bij een typische configuratie wordt het verzoek pas leesbaar nadat een reverse proxy TLS beëindigt, en die stap bevindt zich meestal op hetzelfde subnet, zodat het wordt geswitcht in plaats van gerouteerd en de router het nooit verwerkt. Gebruik een reverse-proxy WAF voor de website en bewaar Threat Prevention voor waar het goed in is.
Which option should I switch on to stop a specific CVE? #
Usually none, because the answer depends on whether the vendor shipped a signature for it at all. Open Self-Defined Policy and you will find you can change the action on an existing signature but cannot add one of your own. If no rule exists in the feed, there is nothing to enable, and for a vulnerability a few days old that is the normal case.
Why does my event list only name one or two devices? #
Because those are the devices receiving traffic the engine can actually read. On our network it is consistently the mail server, which answers cleartext SMTP on port 25. A web host behind a reverse proxy produces few entries not because it is attacked less, but because its traffic is encrypted at every point the router inspects.
Inspecteert Threat Prevention het verkeer tussen apparaten op mijn LAN? #
No. Two devices in the same subnet reach each other through a switch, and the router is not in that path, so the packets are never offered to the inspection engine. The Monitored Interfaces table in Settings shows the real scope, and no option there extends it to same-subnet traffic.
Is het veilig om Threat Prevention ingeschakeld te laten? #
Yes, with one caveat worth knowing. The recommended default passes traffic through unfiltered when the engine is saturated, which keeps your line up at the cost of inspection. The opposite mode drops that traffic instead. We have also had the engine wedge under a flood of harmless exploit attempts and start refusing a server’s outbound traffic, which cost us a mail outage, so include the router in your list of suspects when a machine goes quiet.
Heeft Threat Prevention überhaupt geholpen bij PHP2Shell? #
No, and three separate reasons each would have been enough on their own. The traffic was encrypted everywhere the router looks, no Snort or Emerging Threats signature was published for either CVE, and the exploit has no payload shape to match because the first request is defined by the memory it consumes and the second looks completely ordinary. The fix was new PHP packages, with a reverse-proxy WAF covering the gap in the meantime.
Is disabling session.upload_progress enough on an unpatchable host? #
It helps and it is not enough. Switching it off removes one documented route to CVE-2026-109619, which is worth doing on a host you truly cannot update, but memory exhaustion is reachable by other means and the setting does nothing for CVE-2026-109618. Treat it as borrowed time and plan the package update.
What should I buy or configure first for a NAS-hosted site? #
Plaats een reverse proxy met een beheerde regelset voor de site en beperk vervolgens de oorsprong zodat poort 443 alleen reageert op dat proxy-netwerk. Die twee stappen samen verplaatsen het inspectiepunt naar een plek waar het verzoek leesbaar is en verwijderen de omleiding die dit ongedaan zou maken. Houd Threat Prevention daarna ingeschakeld voor uitgaande command-and-control en voor cleartext-services, want dat is waar het echt werk verricht.
Referenties en video-rondleidingen #
Primaire bronnen voor alles wat hierboven is vermeld, plus drie handleidingen die de moeite waard zijn.
- Synology Kenniscentrum: 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.
- Cloudflare IP-bereiken is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.