Synology Threat Prevention: Hvad den opfanger, og hvad den ikke kan se

Threat Prevention er pakken, de fleste rækker ud efter, i det øjeblik de beslutter sig for at hoste et websted på en Synology NAS. Den ligger på routeren, har et skjold-ikon, og dens kontrolpanel tæller angreb i hundredvis, så den ligner den ting, der holder et offentligt websted sikkert. Vi kører den på en RT6600ax foran hver eneste maskine, vi ejer, og den har været værd at have. Den er også, for et selvhostet websted, næsten fuldstændig ved siden af skiven.

Denne NAS Hosting 101-artikel åbner vores egen router, læser en reel uges hændelser ud af den og viser præcis, hvor Threat Prevention holder op med at kunne hjælpe, ved at bruge PHP2Shell som et eksempel på et angreb, som Threat Prevention aldrig ville opdage.

SynoPower Club Punkt: Jeg brugte lang tid i Synology-supporten, og spørgsmålet kom hele tiden: hvilken indstilling skal jeg slå til for at stoppe dette angreb. Det er det rigtige instinkt rettet mod den forkerte boks. Det, der endelig fik det til at falde på plads for mig, var at læse vores egen hændelsesliste i stedet for funktionssiden. Hver eneste advarsel, vores router har registreret i denne måned, var en adresse med et dårligt omdømme, ikke en anmodning med en dårlig payload. Når du først har set det, holder du op med at bede Threat Prevention om at inspicere trafik, som den opbevarer i en forseglet konvolut.

Hvad Threat Prevention reelt gør på en Synology-router #

Threat Prevention er et system til registrering og forebyggelse af indtrængen, bygget på Snort- og Suricata-arven. Det læser pakker, mens routeren videresender dem, sammenligner dem med et signatursæt og enten registrerer en advarsel eller afviser pakken. På vores RT6600ax er signatur-feedet ET Open, den gratis udgave af Emerging Threats-regelsættet, som opdateres dagligt kl. 09:00.

Tre egenskaber følger af det design, og alle tre betyder mere end et hvilket som helst afkrydsningsfelt i brugerfladen:

• 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. Der er ingen TLS-opsnapning nogen steder i Threat Prevention, så en krypteret payload er uigennemsigtig.
• 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.

Intet af det er en defekt. En IPS ved netværksperimeteren er en rimelig og nyttig ting at have. Fejlen er at antage, at perimeteren er der, hvor et websted angribes.

Threat Prevention i forhold til en Web Application Firewall #

Den klareste måde at se forskellen på er at sætte Threat Prevention ved siden af en web application firewall og spørge, hvad hver enkelt står med, når den træffer sin beslutning. Threat Prevention står med en pakke. En WAF står med en dekrypteret HTTP-anmodning.

Question	Router IPS	Reverse-proxy WAF
Hvor den kører	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

Det er ikke konkurrerende produkter. De dækker forskellige segmenter af den samme rejse, og et selvhostet websted har langt mere brug for den sidstnævnte end den førstnævnte. Vi beholder begge dele, og vi forventer helt forskellige ting af hver af dem.

Læsning af 595 hændelser fra én uge på vores egen router #

Her er oversigtsskærmen for Threat Prevention på vores produktionsrouter den 25. oktober 2026. Femhundrede og femoghalvfems ondsindede hændelser over syv dage, 75 af dem af høj alvorlighed. Det ser ud som en mur, der holder en oversvømmelse tilbage.

To detaljer på det skærmbillede er mere værd end overskriftstallet. Den første er, at kun én enhed overhovedet vises under potentielle trusler, og det er REVERSE_MAIL, maskinen der afbryder TLS og kører MailPlus. Den anden er signaturdatoen ved siden af det grønne flueben. Åbn nu en enkelt hændelse og læs, hvad der reelt blev udløst.

Klassificering Misc Attack, alvorlighed Medium, status Alert, signaturnavn ET CINS Active Threat Intelligence Poor Reputation IP group 24. Åbn regelteksten, og den starter med alert ip og derefter en lang liste af adresser. Det er et opslag i en blokeringsliste. Ingen del af HTTP-anmodningen blev læst, fordi ingen del af den kunne læses. Vi stikprøvede hændelser mod en anden destination, vores Virtual DSM-vært, og fandt den samme regelklasse med et andet gruppenummer.

Så det ærlige resumé af én uge er dette: Routeren genkendte et par hundrede forbindelser fra adresser, der allerede havde et dårligt rygte. Det er virkelig nyttigt. Det er ikke registrering af webangreb, og ingen bør fortolke tallet 595, som om det var.

Sådan gennemgår du Threat Prevention i 4 trin #

Før du betror Threat Prevention noget som helst, bør du bruge ti minutter på at finde ud af, hvad den rent faktisk gør på dit eget netværk. Hvert trin nedenfor er skrivebeskyttet og ændrer ingenting.

Hvor den reelt gør sig fortjent til sin plads #

Vi beholder Threat Prevention slået til, og ikke af overtro. Der er fire opgaver, den udfører, som intet andet i vores stack gø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.

Hvad de fire har til fælles er, at ingen af dem er et angreb på et websted.

Hvorfor en webstedsejer beder Threat Prevention om det forkerte #

Når du hoster et websted på en NAS, har anmodningsstien normalt en reverse proxy i sig. Vores ser således ud, og opsætningen er det, der afgø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 krypteret TLS-strøm og intet andet.
• 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.

Læs de fire linjer igennem sammen, og fælden er åbenlys. Det eneste segment, hvor anmodningen findes i læsbar form, er det sidste hop, og det er præcis det ene segment, som routeren ikke kan observere. Alle steder, routeren kan observere, er anmodningen krypteret. Der findes intet afkrydsningsfelt, der løser en sådan modstrid, og Threat Prevention fejler ikke, når det forholder sig roligt. Det rapporterer nøjagtigt om trafik, det strukturelt set ikke er i stand til at læse.

Dette er også grunden til, at det ikke virker at pege Threat Prevention mod et specifikt websted. Pakken er bundet til routergrænseflader, ikke til værtsnavne. Den har intet begreb om, hvilket af dine websteder en forbindelse tilhører, fordi den aldrig ser Host-headeren.

Tre grunde til, at PHP2Shell var usynlig på routeren #

PHP2Shell, parret af sårbarheder til fjernkørsel af kode før godkendelse, der spores som CVE-2026-109618 og CVE-2026-109619, blev lækket den 20. oktober 2026 og rettet upstream den følgende dag. Det er præcis den type ting, folk håber, at en router-IPS vil absorbere, og det er værd at være specifik om, hvorfor den ikke kunne.

For det første var trafikken krypteret på hvert eneste segment, routeren overvåger. 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 andet eksisterer der ingen Threat Prevention-signatur, man kan slå til. 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 fundamentalt, har dette angreb ingen nyttelastform at 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 anmodning defineres af, hvor meget hukommelse den forbruger, ikke af en bestemt sekvens af bytes, og en stor upload, en enorm JSON-brødtekst, et dybt array og en lang streng i et regulært udtryk opfylder alle betingelserne. Den anden indeholder overhovedet ingen ondsindede bytes. En IPS træffer beslutninger pr. pakke og pr. flow. Den har ingen model for en worker-proces, der fører kontamineret tilstand fra én anmodning videre til den næste, hvilket er præcis der, hvor denne fejl ligger.

Det sætter også grænserne for den afbødning, der cirkulerede på det tidspunkt, som var at slå session.upload_progress fra i PHP-konfigurationen. Det fjerner ganske vist én veldokumenteret måde at nå det andet CVE på, og på en maskine, du reelt ikke kan patche, er det bedre end ingenting. Det er ikke en løsning: opbrug af hukommelse opnås ikke kun gennem denne ene funktion, og indstillingen har overhovedet ingen indflydelse på CVE-2026-109618. Vi brugte det som en midlertidig løsning på præcis én vært og betragtede det som lånt tid, ikke som en endelig løsning. Den fulde beretning om, hvordan vi patchede, findes i vores PHP2Shell write-up.

Fejlåben af design, og den dag det kostede os vores mail #

Der er endnu en egenskab, der er værd at kende, før du betragter Threat Prevention som en kontrolforanstaltning, du kan stole på. Dens anbefalede standard er netværksstabilitetsprioriteret tilstand, og grænsefladen angiver uden forskønnelse, hvad det betyder: Når trafikken overstiger behandlingskapaciteten, omgås afventende pakker uden filtrering. Alternativet, sikkerhedsprioriteret tilstand, afviser dem i stedet og advarer om, at forbindelsen vil være ustabil, indtil problemet er løst.

Det er en fornuftig standardindstilling for en hjemmerouter. Det betyder dog, at Threat Prevention er svagest på det nøjagtige tidspunkt, hvor du ville ønske, at det var stærkest, fordi et oversvømmelsesangreb både er det, du ønsker filtreret, og det, der overstiger kapaciteten.

Vi har også den anden fejltilstand registreret. Den 2. august 2026 tæskede nogen vores reverse proxy 116 gange med et exploit til en Windows PHP-CGI-fejl, som overhovedet ikke kan fungere mod Linux. Threat Prevention afviste så mange pakker, at dets egen tilstand låste sig fast, og begyndte derefter at afvise den udgående trafik fra selvsamme maskine, det skulle forsvare. Vores mailkø gik i stå, og symptomet lignede nøjagtigt en DNS-fejl. En genstart af routeren løste det. Intet dukkede op i proxyens adgangslog, fordi intet nogensinde nåede frem til proxyen. Et angreb, der strukturelt set var ude af stand til at lykkes, kostede os alligevel et nedbrud på grund af den ting, der skulle stoppe det.

Kig på antallet af aktiverede i den liste, mens du er der. Web Application Attack viser 5.928 af 6.010 regler aktive, og forholdet er lignende på tværs af de klasser, vi bekymrer os om. At slå en klasse til slår ikke alle regler inde i den til, og grænsefladen giver dig ingen mulighed for at se, hvilke af de resterende du mangler.

Placer en proxy foran, og lås derefter origin-serveren til den #

Hvis du afvikler et websted fra en NAS, er den kontrol, der udfører arbejdet, som routeren ikke kan, en reverse-proxy WAF. Vi bruger Cloudflare, og grunden er placering snarere end brand: TLS terminerer ved kanten (edge), så den fulde anmodning kan læses i det øjeblik, beslutningen træffes. Metode, sti (path), query, headers, cookies og body er alle tilgængelige for en regel.

Det er grunden til, at PHP2Shell-beskyttelserne ankom der og ikke på routeren. Da CVE'erne blev offentliggjort, fik det administrerede regelsæt syv regler for parret inden for to dage, og de var live på alle fire af de zoner, vi kører, før vi var færdige med at genopbygge vores egne containere. Intet tilsvarende dukkede nogensinde op i Threat Prevention-feedet, og fem dage senere er der stadig ingen offentlig Snort- eller Emerging Threats-regel at installere.

Én advarsel, der betyder mere end valget af udbyder. En proxy foran hjælper kun, så længe den ikke kan omgås. Hvis din origin-adresse svarer det offentlige internet direkte, springer enhver, der opdager den, alle de edge-regler over, du har skrevet. Begræns port 443 på origin til proxyens netværksområder, hent disse områder fra udbyderens slutpunkt i stedet for at hårdkode dem, og bekræft låsningen ved at anmode om webstedet direkte fra dets adresse. Vores samlede opsætning og de fire lag bag dette beskrives i the five layers we run.

Threat Prevention-begrænsninger og sikkerhedsbemærkninger #

Threat Prevention kræver ekstern lagring på routeren og er ikke tilgængelig på alle modeller, så bekræft support for din hardware, før du planlægger ud fra det. Motoren er også det mest travle element på din router, og på en forbrugerenhed er det den komponent, der mest sandsynligt bliver gennemstrømningsloftet. Mål før og efter i stedet for at stole på markedsføringstallene.

Behandl ethvert tal på oversigtsskærmen som et antal signaturmatch, ikke som et antal stoppede angreb. De to adskiller sig i begge retninger. Et omdømmetræf mod en scanner, der alligevel aldrig ville opnå noget, puster totalen op, og en stille uge beviser intet om den HTTPS-trafik, som motoren ikke kan læse.

I Threat Prevention betyder status lige så meget som alvorlighedsgrad. "Drop high-risk packets automatically" gælder kun for højrisikobåndet, så poster med medium alvorlighedsgrad registreres og videresendes. En brugerflade, der viser Alert, fortæller dig, at pakken blev leveret.

Signaturfeedet er en forsyningskæde. ET Open opdateres efter en tidsplan, sakker bagud i forhold til det kommercielle regelsæt og leverer muligvis slet intet for en sårbarhed, der er flere dage gammel. Et kontrolpanel, der rapporterer, at databasen er opdateret, rapporterer, at den matcher feedet, ikke at feedet dækker det, der i øjeblikket bliver udnyttet.

Intet af dette erstatter patching. Hvert lag, der diskuteres her, køber tid til det, der reelt lukker en sårbarhed, hvilket er opdatering af den berørte software. For PHP2Shell betød det nye PHP-pakker og genopbyggede containere, og ingen netværkskontrol kunne erstatte det.

Til sidst bør du modstå trangen til at aktivere enhver klasse efter at have læst en sikkerhedsadvarsel. Klasser som Misc activity indeholder tusindvis af regler af lav værdi, som primært genererer støj og forbruger den samme kapacitet, som de nyttige klasser har brug for. En stille, veltilpasset hændelsesliste, som du faktisk læser, slår en støjende, som du lærer at ignorere.

Ofte stillede spørgsmål #

Referencer og videogennemgange #

Primære kilder til alt det ovenstående samt tre gennemgange, der er tiden værd.

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