Synology Threat Prevention: Hva den fanger opp og hva den ikke kan se

Threat Prevention er pakken de fleste griper etter i det øyeblikket de bestemmer seg for å hoste et nettsted på en Synology NAS. Den ligger på ruteren, den har et skjold-ikon, og dashbordet teller angrep i hundrevis, så den ser ut som tingen som beskytter et offentlig nettsted. Vi kjører den på en RT6600ax foran hver eneste maskin vi eier, og den har vært verdt å ha. Den er også, for et egenhostet nettsted, nesten helt ved siden av poenget.

Denne «NAS Hosting 101»-artikkelen åpner vår egen ruter, leser ut en reell uke med hendelser fra den, og viser nøyaktig hvor Threat Prevention slutter å kunne hjelpe, med PHP2Shell som eksempel på et angrep Threat Prevention aldri kom til å se.

SynoPower Club-punkt: Jeg brukte lang tid i Synology-supporten, og spørsmålet kom inn hele tiden: hvilket alternativ slår jeg på for å stoppe dette angrepet. Det er det riktige instinktet rettet mot feil boks. Det som til slutt fikk brikkene til å falle på plass for meg, var å lese vår egen hendelsesliste i stedet for funksjonssiden. Hver advarsel ruteren vår har registrert denne måneden var en adresse med dårlig rykte, ikke en forespørsel med en skadelig nyttelast. Når du først har sett det, slutter du å be Threat Prevention om å inspisere trafikk den holder i en forseglet konvolutt.

Hva Threat Prevention faktisk gjør på en Synology-ruter #

Threat Prevention er et system for inntrengningsdeteksjon og -forebygging bygget på Snort- og Suricata-arven. Det leser pakker etter hvert som ruteren videresender dem, sammenligner dem mot et signatursett, og enten registrerer et varsel eller slipper pakken. På vår RT6600ax er signaturfeeden ET Open, gratisversjonen av Emerging Threats-regelsettet, oppdatert daglig kl. 09:00.

Tre egenskaper følger av det designet, og alle tre betyr mer enn noen avkrysningsboks i grensesnittet:

• 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. Det er ingen TLS-avskjæring noe sted i Threat Prevention, så en kryptert nyttelast er ugjennomsiktig.
• 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.

Ingenting av det er en feil. En IPS ved nettverksperimeteret er en rimelig og nyttig ting å ha. Feilen er å anta at perimeteret er der et nettsted blir angrepet.

Threat Prevention vs. en webapplikasjonsbrannmur #

Den klareste måten å se gapet på er å sette Threat Prevention ved siden av en webapplikasjonsbrannmur og spørre hva hver av dem har i hendene når de tar sin beslutning. Threat Prevention holder en pakke. En WAF holder en dekryptert HTTP-forespørsel.

Question	Router IPS	Reverse-proxy WAF
Hvor den går	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

Dette er ikke konkurrerende produkter. De dekker ulike segmenter av den samme reisen, og et egenhostet nettsted trenger det andre langt mer enn det første. Vi beholder begge, og vi forventer helt forskjellige ting fra hver av dem.

Lesing av 595 hendelser fra én uke på vår egen ruter #

Her er Threat Prevention-oversiktsskjermen til produksjonsruteren vår den 25. oktober 2026. Fem hundre og nittifem skadelige hendelser over sju dager, 75 av dem med høy alvorlighetsgrad. Det fremstår som en mur som holder tilbake en flom.

To detaljer på den skjermen er verdt mer enn overskriftstallet. Den første er at bare én enhet i det hele tatt vises under potensielle trusler, og det er REVERSE_MAIL, maskinen som terminerer TLS og kjører MailPlus. Den andre er signaturdatoen ved siden av den grønne haken. Åpne nå en enkelt hendelse og les hva som faktisk ble utløst.

Klassifisering Misc Attack, alvorlighetsgrad Medium, status Alert, signaturnavn ET CINS Active Threat Intelligence Poor Reputation IP group 24. Åpne regelteksten, og den starter med alert ip og deretter en lang liste med adresser. Det er et oppslag i en blokkeringsliste. Ingen del av HTTP-forespørselen ble lest, fordi ingen del av den kunne leses. Vi tok stikkprøver av hendelser mot et annet destinasjonsmål, vår Virtual DSM-vert, og fant samme klasse regel med et annet gruppenummer.

Så den ærlige oppsummeringen av én uke er dette: ruteren gjenkjente noen hundre tilkoblinger fra adresser som allerede hadde et dårlig rykte. Det er genuint nyttig. Det er ikke deteksjon av webangrep, og ingen bør lese tallet 595 som om det var det.

Slik reviderer du Threat Prevention på 4 trinn #

Før du stoler på Threat Prevention med noe som helst, bruk ti minutter på å finne ut hva den faktisk gjør på ditt eget nettverk. Hvert trinn nedenfor er skrivebeskyttet og endrer ingenting.

Hvor den genuint fortjener sin plass #

Vi holder Threat Prevention slått på, og ikke av overtro. Det er fire oppgaver den gjør som ingenting annet i stacken vår gjør.

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

Det disse fire har til felles, er at ingen av dem er et angrep på et nettsted.

Hvorfor en nettstedseier ber Threat Prevention om feil ting #

Når du hoster et nettsted på en NAS, har forespørselsbanen vanligvis en reverse proxy i seg. Vår ser slik ut, og formen er det som avgjør alt:

• The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
• What is left crosses the router, hvor Threat Prevention ser en kryptert TLS-strøm og ingenting mer.
• 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.

Les de fire linjene sammen, og fellen er åpenbar. Det eneste segmentet der forespørselen eksisterer i lesbar form er det siste hoppet, og det er det ene segmentet ruteren ikke kan observere. Overalt hvor ruteren kan observere, er forespørselen kryptert. Det finnes ingen avkrysningsboks som løser en slik motstrid, og Threat Prevention feiler ikke når den forblir stille. Den rapporterer nøyaktig om trafikk den strukturelt sett ikke er i stand til å lese.

Dette er også grunnen til at det ikke fungerer å peke Threat Prevention mot et spesifikt nettsted. Pakken er bundet til rutergrensesnitt, ikke til vertsnavn. Den har ingen formening om hvilke av nettstedene dine en tilkobling tilhører, fordi den aldri ser Host-headeren.

Tre grunner til at PHP2Shell var usynlig på ruteren #

PHP2Shell, paret med sårbarheter for fjernkjøring av kode før autentisering sporet som CVE-2026-109618 og CVE-2026-109619, lakk ut 20. oktober 2026 og ble feilrettet oppstrøms dagen etter. Det er akkurat den typen ting folk håper en ruter-IPS vil fange opp, og det er verdt å være spesifikk om hvorfor den ikke kunne det.

For det første var trafikken kryptert på hvert eneste segment ruteren overvåker. 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.

For det andre finnes det ingen Threat Prevention-signatur å slå på. 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.

For det tredje, og mest grunnleggende, har dette angrepet ingen nyttelastform å matche. 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.

Den første forespørselen defineres av hvor mye minne den forbruker, ikke av en sekvens av bytes, og en stor opplasting, en enorm JSON-brødtekst, en dyp matrise og en lang streng i et regulært uttrykk er alle kvalifiserte. Den andre inneholder ingen skadelige bytes i det hele tatt. En IPS tar avgjørelser per pakke og per flyt. Den har ingen modell for en arbeidsprosess som bærer med seg kontaminert tilstand fra én forespørsel til den neste, som er nøyaktig der denne feilen ligger.

Dette setter også grensene for nødløsningen som sirkulerte på det tidspunktet, som var å slå av session.upload_progress i PHP-konfigurasjonen. Det fjerner én veldokumentert måte å nå den andre CVE-en på, og på en maskin du virkelig ikke kan oppdatere, er det bedre enn ingenting. Det er ingen permanent løsning: minneuttømming er ikke bare oppnåelig gjennom den ene funksjonen, og innstillingen har overhode ingen innvirkning på CVE-2026-109618. Vi brukte det som en midlertidig løsning på én enkelt vert og behandlet det som lånt tid, ikke som en endelig løsning. Den fullstendige redegjørelsen for hvordan vi oppdaterte finner du i vår PHP2Shell write-up.

"Fail Open" etter design, og dagen det kostet oss e-posten vår #

Det er én egenskap til som er verdt å kjenne til før du behandler Threat Prevention som et sikkerhetstiltak du kan stole på. Den anbefalte standardinnstillingen er nettverksstabilitetsprioritert modus, og grensesnittet angir hva det betyr uten omsvøp: når trafikken overstiger behandlingskapasiteten, omgås ventende pakker uten filtrering. Alternativet, sikkerhetsprioritert modus, forkaster dem i stedet og advarer om at tilkoblingen vil være ustabil inntil problemet er løst.

Det er en fornuftig standardinnstilling for en hjemmeruter. Det betyr imidlertid at Threat Prevention er på sitt svakeste i nøyaktig det øyeblikket du skulle ønske den var på sitt sterkeste, fordi en oversvømmelse av trafikk er både det du vil ha filtrert og det som overstiger kapasiteten.

Vi har også den andre feilmodusen registrert. Den 2. august 2026 var det noen som angrep vår reverse proxy 116 ganger med en exploit for en Windows PHP-CGI-feil som overhodet ikke kan fungere mot Linux. Threat Prevention forkastet nok pakker til at dens egen tilstand låste seg, og begynte deretter å avvise den utgående trafikken til selve maskinen den forsvarte. E-postkøen vår stoppet opp, og symptomet så akkurat ut som en DNS-feil. Å starte ruteren på nytt løste det. Ingenting dukket opp i proxyens tilgangslogg, fordi ingenting noen gang nådde proxyen. Et angrep som var strukturelt ute av stand til å lykkes krevde likevel sin pris i form av et avbrudd, ved hjelp av det som var ment å stoppe det.

Se på antall aktiverte regler i den listen mens du er der. Web Application Attack viser 5 928 av 6 010 regler aktive, og forholdet er lignende på tvers av klassene vi bryr oss om. Å slå på en klasse slår ikke på hver eneste regel i den, og grensesnittet gir deg ingen måte å se hvilke av de gjenstående du mangler.

Plasser en proxy i front, og lås deretter origin til den #

Hvis du betjener et nettsted fra en NAS, er tiltaket som gjør jobben ruteren ikke kan gjøre, en reverse-proxy WAF. Vi bruker Cloudflare, og årsaken er plassering snarere enn merkevare: TLS termineres ved kanten, så hele forespørselen er lesbar i det øyeblikket beslutningen tas. Metode, sti, spørring, headere, cookies og body er alle tilgjengelige for en regel.

Det var derfor PHP2Shell-beskyttelsene kom der og ikke på ruteren. Da CVE-ene ble kjent, fikk det administrerte regelsettet syv regler for paret innen to dager, og de var live på alle fire sonene vi driver før vi var ferdige med å gjenoppbygge våre egne containere. Ingen tilsvarende dukket noen gang opp i Threat Prevention-feeden, og fem dager senere finnes det fortsatt ingen offentlig Snort- eller Emerging Threats-regel å installere.

Én advarsel som betyr mer enn valget av leverandør. En proxy i front hjelper bare så lenge den ikke kan omgås. Hvis origin-adressen din svarer det offentlige internettet direkte, vil alle som oppdager den omgå hver eneste edge-regel du har skrevet. Begrens port 443 på origin til proxy-nettverksområdene, hent disse områdene fra leverandørens endepunkt i stedet for å hardkode dem, og verifiser låsen ved å forespørre nettstedet direkte fra adressen dets. Vårt større oppsett, og de fire lagene bak dette, er beskrevet i the five layers we run.

Grenser for Threat Prevention og sikkerhetsmerknader #

Threat Prevention krever ekstern lagring på ruteren og er ikke tilgjengelig på alle modeller, så bekreft støtte for maskinvaren din før du planlegger ut fra det. Motoren er også det som krever mest av ruteren din, og på en forbrukerenhet er det komponenten som er mest sannsynlig å bli flaskehalsen for gjennomstrømning. Mål før og etter i stedet for å stole på markedsføringstallene.

Behandle hvert tall på oversiktsskjermen som et antall signaturtreff, ikke et antall stansede angrep. De to er forskjellige i begge retninger. Et omdømmetreff mot en skanner som uansett aldri ville ha oppnådd noe blåser opp totalen, og en rolig uke beviser ingenting om HTTPS-trafikken motoren ikke kan lese.

I Threat Prevention betyr status like mye som alvorlighetsgrad. «Drop high-risk packets automatically» fungerer bare på det høye båndet, slik at oppføringer med middels alvorlighetsgrad blir registrert og videresendt. Et grensesnitt som sier Alert forteller deg at pakken ble levert.

Signaturfeeden er en leverandørkjede. ET Open oppdateres etter tidsplan, ligger bak det kommersielle regelsettet, og leverer kanskje ingenting for en sårbarhet som er flere dager gammel. Et dashbord som rapporterer at databasen er oppdatert, rapporterer at den samsvarer med feeden, ikke at feeden dekker det som for øyeblikket utnyttes.

Ingenting av dette erstatter patching. Hvert lag som diskuteres her kjøper tid for det som faktisk lukker en sårbarhet, nemlig å oppdatere den berørte programvaren. For PHP2Shell betydde det nye PHP-pakker og gjenoppbygde containere, og ingen nettverkskontroll kunne erstatte det.

Til slutt bør du motstå fristelsen til å slå på hver klasse etter å ha lest en sikkerhetsadvarsel. Klasser som Misc activity inneholder tusenvis av lavverdiregler som for det meste genererer støy og forbruker den samme kapasiteten som de nyttige klassene trenger. En rolig, godt tilpasset hendelsesliste som du faktisk leser, slår en støyende en som du lærer deg å ignorere.

Ofte stilte spørsmål #

Referanser og videogjennomganger #

Primærkilder for alt som er nevnt ovenfor, pluss tre gjennomganger verdt tiden.

• Synology kunnskapssenter: 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-områder is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.