
Synology Threat Prevention: Vad det upptäcker och vad det inte kan se
19 min read
- Visa som nedskrivning Öppna den här sidan som vanlig Markdown (öppnas i en ny flik)
- Öppna i chattenGPT Ställ frågor om den här sidan (öppnas i en ny flik)
- Öppet i Claude Ställ frågor om den här sidan (öppnas i en ny flik)
- Öppna i Google AI Studio Ställ frågor om den här sidan (Google-konto krävs) (öppnas i en ny flik)
Threat Prevention är paketet de flesta väljer i samma ögonblick som de bestämmer sig för att vara värd för en webbplats på en Synology NAS. Det ligger på routern, har en sköldikon och dess instrumentpanel räknar attacker i hundratal, så det ser ut som det som håller en offentlig webbplats säker. Vi kör det på en RT6600ax framför varje maskin vi äger, och det har varit värt att ha. För en egenvärdad webbplats är det dock nästan helt irrelevant.
Den här "NAS Hosting 101"-artikeln öppnar vår egen router, läser av en riktig vecka med händelser från den och visar exakt var Threat Prevention slutar kunna hjälpa till, med PHP2Shell som exempel på en attack som Threat Prevention aldrig någonsin skulle se.
SynoPower Club-punkt: Jag tillbringade lång tid på Synology-supporten, och frågan kom in konstant: vilken inställning ska jag slå på för att stoppa den här attacken? Det är rätt instinkt riktad mot fel låda. Det som slutligen fick det att klicka för mig var att läsa vår egen händelselista istället för funktionssidan. Varje larm som vår router har spelat in denna månad var en adress med ett dåligt rykte, inte en begäran med en dålig nyttolast. När du väl har sett det slutar du be Threat Prevention att inspektera trafik som den håller i ett förseglat kuvert.
Vad Threat Prevention faktiskt gör på en Synology-router #
Threat Prevention är ett system för intrångsupptäckt och intrångsskydd som bygger på Snort- och Suricata-arvet. Det läser paket när routern vidarebefordrar dem, jämför dem med en signaturuppsättning och spelar antingen in en varning eller släpper paketet. På vår RT6600ax är signaturflödet ET Open, gratisversionen av regleruppsättningen Emerging Threats, som uppdateras dagligen kl. 09:00.
Tre egenskaper följer av den konstruktionen, och alla tre spelar större roll än någon kryssruta i gränssnittet:
- 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 finns ingen TLS-inspektion någonstans i Threat Prevention, så en krypterad nyttolast är ogenomskinlig.
- 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.
Inget av detta är en defekt. Ett IPS vid nätverksperimetern är en rimlig och användbar sak att äga. Misstaget är att anta att perimetern är där en webbplats attackeras.
Threat Prevention jämfört med en webbapplikationsbrandvägg #
Det tydligaste sättet att se klyftan är att ställa Threat Prevention bredvid en webbapplikationsbrandvägg och fråga vad var och en håller i när den fattar sitt beslut. Threat Prevention håller i ett paket. En WAF håller i en dekrypterad HTTP-begäran.
| Question | Router IPS | Reverse-proxy WAF |
|---|---|---|
| Vart den löper | 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 är inte konkurrerande produkter. De täcker olika delar av samma resa, och en egenvärdad webbplats behöver den senare betydligt mer än den förra. Vi behåller båda, och vi förväntar oss helt olika saker av dem.
Att läsa av 595 händelser från en vecka på vår egen router #
Här är översiktsskärmen i Threat Prevention för vår produktionsrouter den 25 oktober 2026. Femhundranittiofem skadliga händelser under sju dagar, varav 75 med hög allvarlighetsgrad. Det ser ut som en mur som håller tillbaka en översvämning.

Två detaljer på den skärmen är värda mer än den övergripande siffran. Den första är att endast en enhet överhuvudtaget visas under potentiella hot, och det är REVERSE_MAIL, maskinen som terminerar TLS och kör MailPlus. Den andra är signaturdatumet bredvid den gröna bocken. Öppna nu en enskild händelse och läs vad som faktiskt utlöstes.

Klassificering Misc Attack, allvarlighetsgrad Medium, status Alert, signaturnamn ET CINS Active Threat Intelligence Poor Reputation IP group 24. Öppna regeltexten så börjar den med alert ip och sedan en lång lista med adresser. Det är en spärrlistuppslagning. Ingen del av HTTP-begäran lästes, eftersom ingen del av den kunde läsas. Vi tog stickprov på händelser mot ett annat mål, vår Virtual DSM-värd, och hittade samma regelklass med ett annat gruppnummer.
Så den ärliga sammanfattningen av en vecka är denna: routern kände igen några hundra anslutningar från adresser som redan hade ett dåligt rykte. Det är genuint användbart. Det är inte upptäckt av webbattacker, och ingen bör läsa siffran 595 som om den vore det.
Hur du granskar Threat Prevention i 4 steg #
Innan du litar på Threat Prevention med något, ägna tio minuter åt att ta reda på vad det faktiskt gör på ditt eget nätverk. Varje steg nedan är skrivskyddat och ändrar ingenting.
Öppna en händelse och läs signaturens brödtext #
Gå till Threat Prevention, sedan Händelser (Events), och klicka på valfri post. Titta förbi den färgade allvarlighetsbrickan till rutan Signaturregler. En regel som börjar med alert ip matchar enbart på adressrykte. En regel som innehåller content eller pcre matchar på nyttolast (payload). Räkna hur många av varje du kan hitta i din egen lista innan du bestämmer dig för vad Threat Prevention skyddar.
Kontrollera vilka gränssnitt som övervakas #
Öppna Inställningar och läs tabellen Övervakade gränssnitt. Endast de gränssnitt som är ikryssade där inspekteras, och i en normal distribution är dessa de som är vända mot internet. Trafik mellan två enheter på samma LAN-subnät switchas snarare än routas, så den når aldrig inspektionsmotorn och ingen inställning på den här sidan kan ändra det.
Ta reda på vad som händer när routern är upptagen #
I samma panel, titta på standardläget. Prioritet för nätverksstabilitet innebär att när trafiken överskrider vad motorn kan hantera släpps det överskjutande igenom ofiltrerat. Säkerhetsprioritet innebär att det överskjutande istället kastas. Det ena valet är fail-open och håller din linje uppe, det andra är fail-closed och tar ner din linje. Bestäm vilket alternativ du faktiskt vill ha.
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.
Där det verkligen förtjänar sin plats #
Vi håller Threat Prevention aktiverat, och inte av skrockfullhet. Det finns fyra uppgifter det gör som inget annat i vår miljö 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.
Vad dessa fyra har gemensamt är att ingen av dem är en attack mot en webbplats.
Varför en webbplatsägare ber Threat Prevention om fel sak #
När du är värd för en webbplats på en NAS innehåller sökvägen för begäran vanligtvis en omvänd proxy. Vår ser ut så här, och formen är vad som avgör allt:
- The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
- What is left crosses the router, där Threat Prevention ser en krypterad TLS-ström och 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.
Läs de fyra raderna tillsammans och fällan är uppenbar. Det enda segmentet där begäran finns i läsbar form är det sista hoppet, och det är det enda segment som routern inte kan observera. Överallt där routern kan observera är begäran krypterad. Det finns ingen kryssruta som löser en sådan motsägelse, och Threat Prevention misslyckas inte när det förblir tyst. Det rapporterar korrekt om trafik som det strukturellt inte kan läsa.
Detta är också anledningen till att det inte fungerar att rikta Threat Prevention mot en specifik webbplats. Paketet är bundet till routergränssnitt, inte till värdnamn. Det har inget begrepp om vilken av dina webbplatser en anslutning tillhör, eftersom det aldrig ser Host-headern.

Tre anledningar till att PHP2Shell var osynligt vid routern #
PHP2Shell, paret av sårbarheter för fjärrkörning av kod före autentisering som spåras som CVE-2026-109618 och CVE-2026-109619, läckte den 20 oktober 2026 och korrigerades uppströms dagen efter. Det är precis den typ av sak folk hoppas att ett router-IPS ska fånga upp, och det är värt att vara specifik om varför det inte kunde göra det.
För det första var trafiken krypterad på varje segment som routern övervakar. 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.
För det andra finns det ingen Threat Prevention-signatur att 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.

För det tredje, och mest fundamentalt, har denna attack ingen nyttolastform att matcha. 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örsta begäran definieras av hur mycket minne den förbrukar, inte av någon sekvens av byte, och en stor uppladdning, en enorm JSON-textkropp, en djup matris och en lång sträng i ett reguljärt uttryck uppfyller alla kraven. Den andra innehåller inga skadliga byte alls. Ett IPS fattar beslut per paket och per flöde. Det har ingen modell för en arbetsprocess som bär ett kontaminerat tillstånd från en begäran till nästa, vilket är precis där den här buggen finns.
Det sätter också gränserna för den tillfälliga åtgärd som cirkulerade då, vilken var att stänga av session.upload_progress i PHP-konfigurationen. Det tar bort ett väldokumenterat sätt att nå det andra CVE:et, och på en maskin som du verkligen inte kan korrigera är det bättre än ingenting. Det är ingen permanent lösning: minnesuttömning kan inte nås enbart via den funktionen, och inställningen har ingen som helst inverkan på CVE-2026-109618. Vi använde det som en nödlösning på exakt en värd och behandlade det som lånad tid, inte som en slutgiltig lösning. Den fullständiga redogörelsen för hur vi korrigerade finns i vår PHP2Shell write-up.
Standardmässigt öppen vid fel, och dagen då det kostade oss vår e-post #
Det finns ytterligare en egenskap som är värd att känna till innan du behandlar Threat Prevention som en säkerhetskontroll du kan lita på. Dess rekommenderade standardläge är nätverksstabilitetsprioriterat läge, och gränssnittet anger vad det innebär utan några eufemismer: när trafiken överskrider bearbetningskapaciteten förbigås väntande paket utan filtrering. Alternativet, säkerhetsprioriterat läge, släpper dem i stället och varnar för att anslutningen kommer att vara instabil tills problemet har lösts.
Det är en förnuftig standardinställning för en hemrouter. Det innebär dock att Threat Prevention är som svagast i det ögonblick då du vill att det ska vara som starkast, eftersom en överbelastning både är det du vill ha filtrerat och det som överskrider kapaciteten.
Vi har också det andra felsättet dokumenterat. Den 2 augusti 2026 attackerade någon vår omvända proxy 116 gånger med ett exploit för en Windows PHP-CGI-bugg som inte alls kan fungera mot Linux. Threat Prevention släppte tillräckligt med paket för att låsa sitt eget tillstånd och började sedan avvisa utgående trafik från samma maskin som det var satt att försvara. Vår e-postkö stannade och symptomet såg ut precis som ett DNS-fel. Omstart av routern löste det. Inget dök upp i proxyns åtkomstlogg, eftersom ingenting någonsin nådde proxyn. En attack som strukturellt var oförmögen att lyckas orsakade ändå ett avbrott för oss, via det verktyg som var avsett att stoppa den.

Titta på antalet aktiverade i den listan när du ändå är där. Web Application Attack visar 5 928 av 6 010 regler aktiva, och förhållandet är liknande i de klasser vi bryr oss om. Att aktivera en klass aktiverar inte alla regler i den, och gränssnittet ger dig inget sätt att se vilka av de återstående du saknar.
Placera en proxy framför, lås sedan ursprunget till den #
Om du tillhandahåller en webbplats från en NAS är den kontroll som gör jobbet som routern inte klarar av en reverse proxy-WAF. Vi använder Cloudflare, och anledningen är position snarare än varumärke: TLS termineras i kanten (edge), så hela förfrågan är läsbar i det ögonblick beslutet fattas. Metod, sökväg, query, headers, cookies och body är alla tillgängliga för en regel.
Det är därför PHP2Shell-skydden hamnade där och inte på routern. När dessa CVE:er upptäcktes fick den hanterade regeluppsättningen sju regler för paret inom två dagar, och de var aktiva på alla fyra zoner vi kör innan vi hade hunnit bygga om våra egna containrar. Ingen motsvarighet dök någonsin upp i Threat Prevention-flödet, och fem dagar senare finns det fortfarande ingen offentlig Snort- eller Emerging Threats-regel att installera.
En varning som är viktigare än valet av leverantör. En proxy framför hjälper bara så länge den inte kan kringgås. Om din ursprungsadress svarar det offentliga internet direkt kommer alla som upptäcker den att förbigå varje kantregel du har skrivit. Begränsa port 443 på ursprunget till proxyns nätverksintervall, hämta dessa intervall från leverantörens slutpunkt snarare än att hårdkoda dem, och verifiera låsningen genom att begära webbplatsen direkt från dess adress. Vår utökade konfiguration, och de fyra lagren bakom denna, beskrivs i the five layers we run.
Begränsningar och säkerhetsanteckningar för Threat Prevention #
Threat Prevention kräver extern lagring på routern och finns inte tillgängligt på alla modeller, så bekräfta stödet för din hårdvara innan du planerar utifrån det. Motorn är också det mest krävande din router kör, och på en konsumentenhet är det den komponent som är mest benägen att bli flaskhalsen för genomströmningen. Mät före och efter i stället för att lita på marknadsföringssiffran.
Behandla varje siffra på översiktsskärmen som ett antal signaturträffar, inte ett antal stoppade attacker. De två skiljer sig åt i båda riktningarna. En ryktessträff mot en skanner som ändå inte skulle åstadkomma något blåser upp totalsumman, och en lugn vecka bevisar ingenting om den HTTPS-trafik som motorn inte kan läsa.
I Threat Prevention spelar status lika stor roll som allvarlighetsgrad. "Släpp högriskpaket automatiskt" agerar bara på den höga nivån, så poster med medelhög allvarlighetsgrad registreras och vidarebefordras. Ett gränssnitt som visar Alert talar om för dig att paketet levererades.
Signaturflödet är en leveranskedja. ET Open uppdateras enligt ett schema, ligger efter den kommersiella regeluppsättningen och skickar kanske inte ut någonting alls för en sårbarhet som är flera dagar gammal. En instrumentpanel som rapporterar att databasen är uppdaterad rapporterar att den matchar flödet, inte att flödet täcker det som för närvarande utnyttjas.
Inget av detta ersätter patchning. Varje lager som diskuteras här köper tid för det som faktiskt täpper till en sårbarhet, vilket är att uppdatera den drabbade programvaran. För PHP2Shell innebar det nya PHP-paket och ombyggda containrar, och ingen nätverkskontroll kunde ersätta det.
Slutligen, motstå frestelsen att slå på varje klass efter att ha läst ett säkerhetsmeddelande. Klasser som Misc activity innehåller tusentals regler med lågt värde som mestadels genererar brus och förbrukar samma kapacitet som de användbara klasserna behöver. En tyst, väljusterad händelselista som du faktiskt läser slår en högljudd som du lär dig att ignorera.
Vanliga frågor #
Skyddar Threat Prevention en webbplats som är värd på min NAS? #
Knappast, och inte på det sätt som namnet antyder. En webbplats levereras över HTTPS, och Threat Prevention utför ingen TLS-inspektion, så begäran är ogenomskinlig varhelst routern kan se den. I en typisk installation blir begäran läsbar först efter att en omvänd proxy (reverse proxy) terminerar TLS, och det hoppet är vanligtvis på samma undernät, så det växlas snarare än dirigeras och routern hanterar det aldrig. Använd en omvänd proxy-WAF för webbplatsen och behåll Threat Prevention för det som det är bra på.
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.
Inspekterar Threat Prevention trafik mellan enheter på mitt 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.
Är det säkert att lämna Threat Prevention aktiverat? #
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.
Hjälpte Threat Prevention med PHP2Shell överhuvudtaget? #
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? #
Placera en omvänd proxy med en hanterad regeluppsättning framför webbplatsen, och begränsa sedan ursprunget så att port 443 endast svarar mot det proxynätverket. Dessa två steg tillsammans flyttar inspektionspunkten till någonstans där begäran är läsbar och tar bort den kringgående väg som skulle upphäva det. Håll Threat Prevention aktiverat efteråt för utgående command and control och för klartexttjänster, vilket är där det gör verkligt arbete.
Referenser och videogenomgångar #
Primära källor för allt som anges ovan, plus tre genomgångar som är värda tiden.
- Synology Kunskapscenter: 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-intervall is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.