
Synology Threat Prevention: Co zachytí a co nevidí
19 min read
- Zobrazit jako Markdown Otevřít tuto stránku jako obyčejný Markdown (otevře se v nové záložce)
- Otevřít v ChatuGPT Ptejte se na tuto stránku (otevře se v nové záložce)
- Otevřeno v Claude Ptejte se na tuto stránku (otevře se v nové záložce)
- Otevřít v Google AI Studiu Ptejte se na tuto stránku (vyžadován účet Google) (otevře se v nové záložce)
Threat Prevention je balíček, po kterém většina lidí sáhne ve chvíli, kdy se rozhodnou hostovat web na Synology NAS. Běží na routeru, má ikonu štítu a jeho přehled počítá útoky na stovky, takže vypadá jako věc, která udržuje veřejný web v bezpečí. Provozujeme jej na RT6600ax před každým strojem, který vlastníme, a vyplatilo se ho mít. Pro svépomocně hostovaný web je však téměř zcela mimo mísu.
Tento článek z řady NAS Hosting 101 otevírá náš vlastní router, čte z něj reálný týden událostí a přesně ukazuje, kde Threat Prevention přestává pomáhat, přičemž jako příklad útoku, který Threat Prevention neměl šanci zachytit, používá PHP2Shell.
Bod SynoPower Club: Strávil jsem dlouhou dobu na zákaznické podpoře Synology a tato otázka přicházela neustále: kterou možnost mám zapnout, abych tento útok zastavil. Je to správný instinkt zaměřený na špatný box. To, co mi to konečně objasnilo, bylo čtení našeho vlastního seznamu událostí namísto stránky s funkcemi. Každé upozornění, které náš router tento měsíc zaznamenal, byla adresa se špatnou reputací, nikoli požadavek se špatným užitečným obsahem (payloadem). Jakmile to uvidíte, přestanete po Threat Prevention požadovat, aby kontroloval provoz, který drží v zapečetěné obálce.
Co Threat Prevention na routeru Synology skutečně dělá #
Threat Prevention je systém detekce a prevence průniku (IDS/IPS) postavený na rodině nástrojů Snort a Suricata. Čte pakety při jejich směrování routerem, porovnává je se sadou podpisů a buď zaznamená varování, nebo paket zahodí. Na našem RT6600ax je zdrojem podpisů ET Open, bezplatná úroveň sady pravidel Emerging Threats, aktualizovaná denně v 09:00.
Z tohoto návrhu vyplývají tři vlastnosti a na všech třech záleží více než na jakémkoli zaškrtávacím políčku v rozhraní:
- 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. V Threat Prevention nikde neprobíhá zachytávání TLS, takže šifrovaný užitečný obsah je nečitelný.
- 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.
Nic z toho není chyba. IPS na obvodu sítě je rozumná a užitečná věc. Chybou je předpokládat, že obvod je místem, kde dochází k útoku na webové stránky.
Threat Prevention vs. Web Application Firewall #
Nejjasnější způsob, jak uvidět tento rozdíl, je postavit Threat Prevention vedle webového aplikačního firewallu (WAF) a zeptat se, co každý z nich drží v ruce, když se rozhoduje. Threat Prevention drží paket. WAF drží dešifrovaný požadavek HTTP.
| Question | Router IPS | Reverse-proxy WAF |
|---|---|---|
| Kde to běží | 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 |
Nejedná se o konkurenční produkty. Pokrývají různé úseky stejné cesty a svépomocně hostovaný web potřebuje ten druhý o mnoho více než ten první. Ponecháváme si oba a od každého očekáváme úplně jiné věci.
Čtení 595 událostí za jeden týden na našem vlastním routeru #
Zde je přehledová obrazovka balíčku Threat Prevention našeho produkčního routeru ze dne 25. října 2026. Pět set devadesát pět škodlivých událostí za sedm dní, z toho 75 s vysokou závažností. Vypadá to jako hráz zadržující povodeň.

Dva detaily na této obrazovce mají větší hodnotu než samotné celkové číslo. Prvním je, že se mezi potenciálními hrozbami objevuje vůbec jen jedno zařízení, a to REVERSE_MAIL, stroj, který ukončuje TLS a provozuje MailPlus. Druhým je datum podpisu vedle zelené fajfky. Nyní otevřete jednu událost a přečtěte si, co se vlastně spustilo.

Klasifikace Misc Attack, závažnost Střední, stav Alert, název podpisu ET CINS Active Threat Intelligence Poor Reputation IP group 24. Otevřete tělo pravidla a to začíná alert ip a pak dlouhým seznamem adres. Jedná se o vyhledávání v černém seznamu (blocklistu). Žádná část požadavku HTTP nebyla přečtena, protože ani přečtena být nemohla. Otestovali jsme události proti druhému cíli, našemu hostiteli Virtual DSM, a našli jsme stejnou třídu pravidla s jiným číslem skupiny.
Upřímné shrnutí jednoho týdne je tedy toto: router rozpoznal několik stovek připojení z adres, které již měly špatnou reputaci. To je opravdu užitečné. Není to však detekce webových útoků a nikdo by neměl číslo 595 interpretovat, jako by tomu tak bylo.
Jak provést audit Threat Prevention ve 4 krocích #
Než svěříte balíčku Threat Prevention cokoli, věnujte deset minut zjištění, co na vaší vlastní síti skutečně dělá. Každý níže uvedený krok slouží pouze ke čtení a nic nemění.
Otevřete jednu událost a přečtěte si tělo podpisu #
Přejděte do Threat Prevention, poté na Události a klikněte na libovolnou položku. Podívejte se za barevný odznak závažnosti do pole Pravidla podpisů. Pravidlo začínající na alert ip odpovídá pouze reputaci adresy. Pravidlo obsahující content nebo pcre odpovídá užitečnému obsahu (payload). Spočítejte, kolik od každého typu najdete ve svém vlastním seznamu, než se rozhodnete, co vlastně Threat Prevention chrání.
Zkontrolujte, která rozhraní jsou monitorována #
Otevřete Nastavení a prohlédněte si tabulku Monitored Interfaces. Kontrolována jsou pouze rozhraní, která jsou zde zaškrtnuta, a při běžném nasazení se jedná o rozhraní směřující do internetu. Provoz mezi dvěma zařízeními ve stejné podsíti LAN je přepínán, nikoli směrován, takže se nikdy nedostane ke kontrolovacímu modulu a žádné nastavení na této stránce to nemůže změnit.
Zjistěte, co se stane, když je router vytížený #
Ve stejném panelu se podívejte na výchozí režim. Priorita stability sítě znamená, že když provoz překročí kapacitu, kterou engine dokáže zpracovat, přebytečný provoz je propuštěn nefiltrovaný. Priorita zabezpečení znamená, že přebytek je místo toho zahozen. Jedna možnost při selhání zůstává otevřená a udrží vaši linku v provozu, druhá se při selhání uzavře a vaši linku shodí. Rozhodněte se, kterou vlastně chcete.
Zkuste přidat vlastní pravidlo #
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.
Kde si skutečně zaslouží své místo #
Ponecháváme Threat Prevention zapnutý, a to nikoli ze pověrčivosti. Dělá čtyři úkoly, které nic jiného v našem systému nedělá.
- 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.
Tyto čtyři věci mají společné to, že ani jedna z nich není útokem na webové stránky.
Proč vlastník webu požaduje po Threat Prevention nesprávnou věc #
Když hostujete web na NAS, cesta požadavku obvykle obsahuje reverzní proxy. Naše vypadá takto a její struktura rozhoduje o všem:
- The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
- What is left crosses the router, kde Threat Prevention vidí šifrovaný datový tok TLS a nic více.
- Ten/Ta/To 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.
Přečtěte si tyto čtyři řádky společně a léčka je zřejmá. Jediný úsek, kde požadavek existuje v čitelné podobě, je poslední skok, a to je právě ten úsek, který router nemůže sledovat. Všude, kde router sledovat může, je požadavek šifrován. Neexistuje žádné zaškrtávací políčko, které by vyřešilo takový rozpor, a Threat Prevention neselhává, když zůstává zticha. Hlásí přesně informace o provozu, který ze své podstaty nedokáže přečíst.
To je také důvod, proč nasměrování Threat Prevention na konkrétní web nefunguje. Balíček je vázán na rozhraní routeru, nikoli na názvy hostitelů. Nemá žádný pojem o tom, ke kterému z vašich webů připojení patří, protože nikdy nevidí hlavičku Host.

Tři důvody, proč byl PHP2Shell na routeru neviditelný #
PHP2Shell, dvojice zranitelností typu vzdáleného spuštění kódu před autentizací sledovaných jako CVE-2026-109618 a CVE-2026-109619, unikla 20. října 2026 a následující den byla opravena přímo u vývojářů. Je to přesně ten druh věci, o kterém lidé doufají, že jej zachytí IPS routeru, a stojí za to přesně vysvětlit, proč to nedokázal.
Za prvé, provoz byl šifrován na každém úseku, který router sleduje. 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.
Za druhé, neexistuje žádný podpis Threat Prevention, který by bylo možné zapnout. 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.

Za třetí, a to je zásadní, tento útok nemá žádný tvar užitečného zatížení (payloadu), který by se dal zachytit. 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.
Řetězec vyžaduje dva požadavky. První musí dotlačit PHP k vyčerpání jeho paměťového limitu, což způsobí, že stroj opustí požadavek cestou, která přeskočí úklid a zanechá za sebou určitý globální stav. Druhý požadavek je běžný a je to ten, který dosáhne neplatného ukazatele (stale pointer) a promění se ve spuštění kódu. První požadavek je definován tím, kolik paměti spotřebuje, nikoli jakoukoli sekvencí bajtů; vyhovuje mu velký upload, obrovské tělo JSON, hluboké pole i dlouhý řetězec v regulárním výrazu. Druhý požadavek neobsahuje vůbec žádné škodlivé bajty. IPS rozhoduje na úrovni jednotlivých paketů a toků. Nemá žádný model pracovního procesu (worker process) přenášejícího kontaminovaný stav z jednoho požadavku do druhého, což je přesně místo, kde tato chyba žije.
To také stanovuje limity mitigace, která v té době kolovala, což bylo vypnutí session.upload_progress v konfiguraci PHP. Odstraňuje sice jeden dobře zdokumentovaný způsob, jak dosáhnout druhého CVE, a na stroji, který opravdu nemůžete aktualizovat, je to lepší než nic. Není to však oprava: vyčerpání paměti není dosažitelné pouze prostřednictvím této jediné funkce a toto nastavení nemá vůbec žádný vliv na CVE-2026-109618. Použili jsme ho jako provizorní řešení na přesně jednom hostiteli a přistupovali k němu jako k získanému času, ne jako k vyřešení problému. Celý popis toho, jak jsme prováděli opravu, naleznete v našem PHP2Shell write-up.
Návrhové selhání do otevřeného stavu (Fail Open) a den, kdy nás to stálo poštu #
Existuje ještě jedna vlastnost, kterou stojí za to znát, než začnete Threat Prevention považovat za prvek, na který se můžete spolehnout. Jeho doporučeným výchozím nastavením je režim priority stability sítě a rozhraní uvádí, co to znamená, bez jakýchkoli eufemismů: když provoz překročí kapacitu zpracování, částečně vyřízené pakety jsou přemostěny bez filtrování. Alternativa, režim priority zabezpečení, je místo toho zahazuje a varuje, že připojení bude nestabilní, dokud nebude problém vyřešen.
To je rozumné výchozí nastavení pro domácí router. Znamená to však, že Threat Prevention je nejslabší v přesně ten moment, kdy byste chtěli, aby byl nejsilnější, protože nápor provozu je jak věcí, kterou chcete filtrovat, tak věcí, která překračuje kapacitu.
Máme zaznamenán i druhý způsob selhání. Dne 2. srpna 2026 někdo 116krát zaútočil na náš reverzní proxy server pomocí exploitu na chybu PHP-CGI ve Windows, která proti Linuxu nemůže vůbec fungovat. Threat Prevention zahodil dostatečné množství paketů na to, aby zablokoval svůj vlastní stav, a poté začal odmítat odchozí provoz přesně toho stroje, který bránil. Naše poštovní fronta se zastavila a příznak vypadal přesně jako selhání DNS. Restartování routeru to opravilo. V protokolu přístupů proxy se nic neobjevilo, protože k proxy nic nedorazilo. Útok, který byl strukturálně neschopný uspět, nás přesto stál výpadek, a to prostřednictvím věci, která mu měla zabránit.

Když už tam jste, podívejte se na počty povolených položek v tomto seznamu. Web Application Attack zobrazuje 5 928 z 6 010 aktivních pravidel a poměr je podobný ve všech třídách, které nás zajímají. Zapnutí třídy nezapne každé pravidlo uvnitř a rozhraní vám nedává žádný způsob, jak zjistit, která ze zbývajících pravidel vám chybí.
Umístěte proxy dopředu a poté k ní uzamkněte origin #
Pokud provozujete web z NAS, prvkem, který odvede práci, kterou směrovač nezvládne, je reverzní proxy WAF. Používáme Cloudflare, a důvodem je spíše pozice než značka: TLS končí na okraji (edge), takže celý požadavek je čitelný v okamžiku, kdy se přijímá rozhodnutí. Metoda, cesta, dotaz, hlavičky, cookies i tělo jsou pro pravidlo plně dostupné.
Proto se ochrany PHP2Shell objevily tam a ne na směrovači. Když se objevily zranitelnosti CVE, spravovaná sada pravidel získala během dvou dnů sedm pravidel pro tuto dvojici a ta byla aktivní ve všech čtyřech námi provozovaných zónách dříve, než jsme dokončili přestavbu vlastních kontejnerů. V kanálu Threat Prevention se nikdy žádný ekvivalent neobjevil a ani o pět dní později stále neexistuje žádné veřejné pravidlo pro Snort nebo Emerging Threats ke instalaci.
Jedno varování, které je důležitější než volba poskytovatele. Proxy v popředí pomáhá pouze tehdy, dokud ji nelze obejít. Pokud vaše adresa původu odpovídá přímo do veřejného internetu, každý, kdo ji objeví, obejde všechna edge pravidla, která jste napsali. Omezte port 443 na původu pouze na síťové rozsahy proxy, načítejte tyto rozsahy z koncového bodu poskytovatele namísto jejich pevného kódování a ověřte uzamčení vyžádáním webu přímo z jeho adresy. Naše širší nastavení a čtyři vrstvy za touto jsou popsány v the five layers we run.
Omezení a bezpečnostní poznámky k aplikaci Threat Prevention #
Threat Prevention vyžaduje externí úložiště ve směrovači a není k dispozici u všech modelů, proto před plánováním ověřte podporu pro váš hardware. Engine je také nejvytíženější činností vašeho směrovače a na spotřebitelské jednotce je to komponenta, u níž je nejpravděpodobnější, že se stane stropem propustnosti. Měřte před a po, než abyste věřili marketingovému číslu.
Považujte každé číslo na obrazovce přehledu za počet shod signatur, nikoli za počet zastavených útoků. Tyto dvě hodnoty se liší v obou směrech. Zásah reputace vůči skeneru, který by nikdy ničeho nedosáhl, navýší celkový počet, a klidný týden nic nedokazuje o provozu HTTPS, který engine nedokáže přečíst.
V aplikaci Threat Prevention záleží na stavu stejně jako na závažnosti. Volba Automaticky zahazovat vysoce rizikové pakety funguje pouze pro vysoké pásmo, takže záznamy se střední závažností jsou zaznamenány a předány dál. Rozhraní zobrazující Alert vám oznamuje, že paket byl doručen.
Kanál signatur je dodavatelský řetězec. ET Open se obnovuje podle plánu, zaostává za komerční sadou pravidel a pro několik dní starou zranitelnost nemusí dodat vůbec nic. Ovládací panel, který hlásí databázi jako aktuální, hlásí, že odpovídá kanálu, nikoli to, že kanál pokrývá to, co je v současnosti zneužíváno.
Nic z toho nenahrazuje patchování. Každá zde probíraná vrstva vám získává čas pro to, co zranitelnost skutečně odstraňuje, a tím je aktualizace dotčeného softwaru. V případě PHP2Shell to znamenalo nové balíčky PHP a znovu sestavené kontejnery a žádné síťové opatření to nemohlo nahradit.
A konečně, odolejte pokušení zapnout každou třídu po přečtení bezpečnostního varování. Třídy jako Misc activity obsahují tisíce pravidel s nízkou hodnotou, která většinou jen generují šum a spotřebovávají stejnou kapacitu, kterou potřebují užitečné třídy. Tichý, dobře vyladěný seznam událostí, který si skutečně přečtete, je lepší než hlučný, který se naučíte ignorovat.
Často kladené otázky #
Chrání Threat Prevention webové stránky hostované na mém NAS? #
Téměř ne a ne způsobem, který název napovídá. Webové stránky jsou poskytovány přes HTTPS a Threat Prevention neprovádí žádnou zachytávání TLS (TLS interception), takže požadavek je všude, kde ho router vidí, nečitelný. Při běžném nastavení se požadavek stane čitelným až poté, co reverzní proxy ukončí TLS, a tento skok je obvykle na stejné podsíti, takže je přepínán (switched), nikoli směrován (routed), a router jej nikdy nepřenáší. Pro webové stránky použijte WAF s reverzní proxy a Threat Prevention si ponechte na to, v čem je dobrý.
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.
Kontroluje Threat Prevention provoz mezi zařízeními v mé síti 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.
Je bezpečné nechat Threat Prevention zapnutý? #
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.
Pomohl Threat Prevention s PHP2Shell vůbec nějak? #
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? #
Umístěte před web reverzní proxy se spravovanou sadou pravidel a potom omezte původ tak, aby port 443 odpovídal pouze síti této proxy. Tyto dva kroky společně přesunou bod kontroly na místo, kde je požadavek čitelný, a odstraní obcházení, které by jej zneplatnilo. Poté ponechte Threat Prevention zapnutý pro odchozí komunikaci s řídicími servery (command and control) a pro služby v nešifrovaném textu, což je oblast, kde odvádí skutečnou práci.
Reference a video návody #
Primární zdroje pro vše výše uvedené a navíc tři návody, které stojí za pozornost.
- Centrum znalostí 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.
- Rozsahy IP adres Cloudflare is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.