Synology Threat Prevention: Amit elkap, és amit nem lát

A Threat Prevention az a csomag, amelyhez a legtöbben nyúlnak abban a pillanatban, amikor úgy döntenek, hogy webhelyet hosztolnak egy Synology NAS-on. A routeren fut, pajzs ikonja van, a műszerfala pedig százas nagyságrendben számolja a támadásokat, így úgy tűnik, mint ami biztonságban tartja a nyilvános webhelyet. Egy RT6600ax eszközön futtatjuk az összes saját gépünk előtt, és megérte használni. Ugyanakkor egy saját hostingolású webhely szempontjából szinte teljesen lényegtelen.

Ez a NAS Hosting 101 cikk megnyitja a saját routerünket, kiolvassa belőle egy valódi hét eseményeit, és pontosan megmutatja, hol nem tud már segíteni a Threat Prevention, a PHP2Shell példáján keresztül szemléltetve egy olyan támadást, amelyet a Threat Prevention soha nem vett volna észre.

SynoPower Club pont: Hosszú időt töltöttem a Synology támogatási oldalán, és a kérdés folyamatosan felmerült: melyik opciót kapcsoljam be a támadás megállításához. Ez a helyes ösztön, de a rossz dobozra irányul. Számomra az hozta meg az áttörést, amikor a funkcióoldal helyett a saját eseménylistánkat olvastam el. Minden riasztás, amelyet az útválasztónk ebben a hónapban rögzített, rossz hírnevű cím volt, nem pedig rossz hasznos teherrel rendelkező kérés. Ha ezt egyszer meglátja, nem kéri többé a Threat Prevention-t, hogy ellenőrizze a lezárt borítékban tartott forgalmat.

Mit csinál valójában a Threat Prevention egy Synology routeren #

A Threat Prevention egy behatolásészlelő és -megelőző rendszer, amely a Snort és Suricata alapjaira épül. Beolvassa a csomagokat, miközben a router továbbítja azokat, összehasonlítja őket egy aláíráskészlettel, és vagy rögzít egy riasztást, vagy eldobja a csomagot. Az RT6600ax készülékünkön az aláírásforrás az ET Open, az Emerging Threats szabálykészlet ingyenes szintje, amely naponta 09:00-kor frissül.

Ebből a felépítésből három tulajdonság következik, és mindhárom fontosabb, mint a felület bármelyik jelölőnégyzete:

• 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. A Threat Prevention sehol nem végez TLS-betekintést, így a titkosított hasznos teher átláthatatlan.
• 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.

Ezek egyike sem hiba. Egy IPS a hálózat peremén ésszerű és hasznos dolog. A hiba az a feltételezés, hogy a webhelyet a peremen éri támadás.

Threat Prevention vs. Webalkalmazás-tűzfal (WAF) #

A különbség legtisztább megértéséhez állítsuk a Threat Prevention-t egy webalkalmazás-tűzfal mellé, és kérdezzük meg, mit tart a kezében mindegyik, amikor meghozza a döntését. A Threat Prevention egy hálózati csomagot tart. A WAF egy dekódolt HTTP-kérést tart.

Question	Router IPS	Reverse-proxy WAF
Hol fut	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

Ezek nem egymással versengő termékek. Ugyanazon folyamat más-más szakaszát fedik le, és egy saját hostingolású webhelynek sokkal inkább szüksége van a másodikra, mint az elsőre. Mi mindkettőt megtartjuk, és teljesen eltérő dolgokat várunk el tőlük.

595 esemény kiolvasása egyetlen hétből a saját routerünkön #

Íme a termelési routerünk Threat Prevention áttekintő képernyője 2026. október 25-én. Ötszázkilencvenöt rosszindulatú esemény hét nap alatt, ebből 75 magas súlyosságú. Úgy néz ki, mint egy gát, amely visszatartja az áradatot.

Két részlet ezen a képernyőn többet ér, mint a főszám. Az első az, hogy mindössze egyetlen eszköz jelenik meg a potenciális fenyegetések alatt, és az a REVERSE_MAIL, a gép, amely lezárja a TLS-t és futtatja a MailPlus-t. A második a zöld pipa melletti aláírás dátuma. Most nyisson meg egyetlen eseményt, és olvassa el, mi aktiválódott valójában.

Besorolás: Misc Attack, súlyosság: Medium, állapot: Alert, aláírás neve: ET CINS Active Threat Intelligence Poor Reputation IP group 24. Nyissa meg a szabály törzsét, és az alert ip-vel kezdődik, majd egy hosszú címlistával. Ez egy tiltólista-lekérdezés. A HTTP-kérés egyetlen részét sem olvasta el, mert semelyik részét nem tudta elolvasni. Mintát vettünk az eseményekből egy második célpont, a Virtual DSM gazdagépünk ellen is, és ugyanazt a szabályosztályt találtuk egy másik csoportszámmal.

Egy hét őszinte összefoglalása tehát a következő: a router felismerte a már rossz hírű címekről érkező néhány száz kapcsolódást. Ez valóban hasznos. De ez nem webes támadásészlelés, és senkinek sem szabad úgy értelmeznie az 595-ös számot, mintha az lenne.

A Threat Prevention auditálása 4 lépésben #

Mielőtt bármit rábízna a Threat Prevention-re, szánjon tíz percet arra, hogy kiderítse, mit csinál valójában a saját hálózatán. Az alábbi lépések mindegyike csak olvasható, és semmit sem változtat meg.

Hol van valóban jogosultsága #

Bekapcsolt állapotban tartjuk a Threat Prevention-t, és nem babonából. Négy olyan feladatot lát el, amelyeket semmi más nem végez el a rendszerünkben.

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

Ebben a négyben az a közös, hogy egyik sem egy webhely elleni támadás.

Miért vár el egy webhelytulajdonos rossz dolgot a Threat Prevention-től #

Amikor egy webhelyet NAS-on hosztol, a kérési útvonalban általában van egy reverse proxy. A miénk így néz ki, és a felépítése az, ami mindent eldönt:

• The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
• What is left crosses the router, ahol a Threat Prevention egy titkosított TLS-folyamot lát, és semmi mást.
• A 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.

Ha elolvassa ezt a négy sort együtt, a csapda nyilvánvaló. Az egyetlen szakasz, ahol a kérés olvasható formában létezik, az utolsó ugrás, és ez az egyetlen olyan szakasz, amelyet a router nem tud megfigyelni. Mindenhol, ahol a router megfigyelhetne, a kérés titkosított. Nincs olyan jelölőnégyzet, amely feloldana egy ilyen ellentmondást, és a Threat Prevention nem vall kudarcot, amikor hallgat. Pontosan számol be arról a forgalomról, amelyet strukturálisan képtelen elolvasni.

Ez az oka annak is, hogy a Threat Prevention egy adott webhelyre irányítása nem működik. A csomag a router interfészeihez van kötve, nem a gazdanevekhez. Fogalma sincs arról, hogy egy kapcsolat melyik webhelyéhez tartozik, mert soha nem látja a Host fejlécet.

Három ok, amiért a PHP2Shell láthatatlan volt a router számára #

A PHP2Shell, a CVE-2026-109618 és CVE-2026-109619 néven nyomon követett hitelesítés előtti távoli kódvégrehajtási hibapár 2026. október 20-án szivárgott ki, és a következő napon javították a felső tagozaton (upstream). Ez pontosan az a fajta dolog, amit az emberek remélnek, hogy egy router IPS elnyel, és érdemes pontosítani, miért nem volt képes rá.

Először is, a forgalom minden olyan szakaszon titkosítva volt, amelyet a router figyel. 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.

Másodszor, nem létezik bekapcsolható Threat Prevention aláírás. 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.

Harmadszor, és ami a legalapvetőbb, ennek a támadásnak nincs illeszthető hasznos teher (payload) formája. 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.

Az első kérést az határozza meg, hogy mennyi memóriát fogyaszt, nem pedig a bájtok bármely szekvenciája; egy nagy feltöltés, egy hatalmas JSON törzs, egy mély tömb és egy hosszú karakterlánc egy reguláris kifejezésben mind megfelel. A második egyáltalán nem tartalmaz kártékony bájtokat. Az IPS csomagonként és folyamonként dönt. Nem rendelkezik olyan modellel, amelyben egy munkafolyamat szennyezett állapotot visz át az egyik kérésből a másikba, holott ez a hiba pontosan itt található.

Ez egyben kijelöli az akkoriban közkézen forgó enyhítés határait is, amely a session.upload_progress kikapcsolása volt a PHP-konfigurációban. Valóban eltávolít egy jól dokumentált módot a második CVE elérésére, és egy olyan gépen, amelyet valóban nem tud frissíteni, ez is jobb a semminél. Ez nem javítás: a memóriakimerülés nem csak ezen az egy funkción keresztül érhető el, és a beállítás egyáltalán nincs hatással a CVE-2026-109618-ra. Ezt áthidaló megoldásként használtuk pontosan egy gazdagépen, és kölcsönzött időként kezeltük, nem pedig megoldásként. A frissítés teljes története a következő helyen található: PHP2Shell write-up.

Kialakításból adódó nyitott hibaállapot (Fail Open), és a nap, amikor ez a levelezésünkbe került #

Van még egy tulajdonság, amit érdemes tudni, mielőtt a Threat Prevention-re megbízható vezérlőként tekintene. Az ajánlott alapértelmezett beállítása a hálózati stabilitást előnyben részesítő mód, és a felület köntörfalazás nélkül leírja, hogy ez mit jelent: amikor a forgalom meghaladja a feldolgozási kapacitást, a függőben lévő csomagok szűrés nélkül áthaladnak. Az alternatíva, a biztonságot előnyben részesítő mód inkább eldobja őket, és figyelmeztet, hogy a kapcsolat instabil lesz a probléma megoldásáig.

Ez egy ésszerű alapértelmezés egy otthoni router esetében. Ez azt jelenti, hogy a Threat Prevention éppen abban a pillanatban a leggyengébb, amikor a legerősebbnek szeretné, mivel az elárasztás (flood) egyszerre az a dolog, amit szűrni szeretne, és az a dolog, ami meghaladja a kapacitást.

A másik meghibásodási módról is van feljegyzésünk. 2026. augusztus 2-án valaki 116-szor támadta meg a fordított proxy-nkat egy olyan Windows PHP-CGI hiba exploitjával, amely Linux ellen egyáltalán nem működhet. A Threat Prevention elegendő csomagot dobott el ahhoz, hogy beékelje a saját állapotát, majd elkezdte visszautasítani éppen azon gép kimenő forgalmát, amelyet védett. A levelezési sorunk leállt, és a tünet pontosan úgy nézett ki, mint egy DNS-hiba. A router újraindítása megoldotta a problémát. Semmi nem jelent meg a proxy hozzáférési naplójában, mert semmi nem érte el a proxy-t. Egy olyan támadás, amely strukturálisan képtelen volt a sikerre, mégis leállást okozott nekünk azon eszköz révén, amelynek meg kellett volna állítania azt.

Nézze meg az engedélyezési számokat abban a listában, amíg ott van. A Web Application Attack 6010 szabályból 5928 aktív szabályt mutat, és az arány hasonló az általunk fontosnak tartott osztályok esetében is. Egy osztály bekapcsolása nem kapcsol be minden benne lévő szabályt, és a felület nem ad lehetőséget arra, hogy lássa, a fennmaradókból melyek hiányoznak.

Helyezzen el egy proxyt a rendszer előtt, majd korlátozza az eredeti szervert arra #

Ha webhelyet szolgál ki egy NAS-ról, az a védelmi eszköz, amely elvégzi a router által el nem végezhető feladatot, egy fordított proxy WAF. Mi a Cloudflare-t használjuk, és ennek az oka a pozíció, nem pedig a márka: a TLS a hálózat szélén fejeződik be, így a teljes kérés olvasható a döntéshozatal pillanatában. A metódus, az útvonal, a lekérdezés, a fejlécek, a sütik és a törzs mind elérhetők a szabályok számára.

Ezért érkeztek a PHP2Shell elleni védelmek oda, és nem a routerre. Amikor a CVE-k megjelentek, a felügyelt szabálykészlet két napon belül hét új szabállyal bővült a párhoz, és ezek mind a négy általunk üzemeltetett zónában éltek, mielőtt befejeztük volna a saját konténereink újraépítését. A Threat Prevention hírcsatornájában semmi sem jelent meg ezzel kapcsolatban, és öt nappal később még mindig nincs telepíthető nyilvános Snort vagy Emerging Threats szabály.

Egy figyelmeztetés, amely fontosabb, mint a szolgáltató kiválasztása. Az elé helyezett proxy csak addig segít, amíg nem lehet megkerülni. Ha az eredeti szerver címe közvetlenül válaszol a nyilvános internetnek, bárki, aki felfedezi, megkerüli az összes Ön által írt edge-szabályt. Korlátozza az eredeti szerver 443-as portját a proxy hálózati tartományaira, ezeket a tartományokat a szolgáltató végpontjáról kérje le a beégetés helyett, és ellenőrizze a zárolást úgy, hogy a webhelyet közvetlenül a saját címéről kéri le. A teljesebb konfigurációnk és az ez mögötti négy réteg leírása itt található: the five layers we run.

A Threat Prevention korlátai és biztonsági megjegyzések #

A Threat Prevention külső tárhelyet igényel a routeren, és nem érhető el minden modellnél, ezért a tervezés előtt ellenőrizze a hardver támogatottságát. A motor egyben a legforgalmasabb feladat, amit a router végez, és egy lakossági egységnél ez az a komponens, amely a legnagyobb valószínűséggel válik az áteresztőképesség felső korlátjává. Mérjen előtte és utána ahelyett, hogy megbízna a marketingadatokban.

Kezeljen az áttekintő képernyőn található minden számot a szignatúra-egyezések számaként, nem pedig a megállított támadások számaként. A kettő mindkét irányban eltérhet. Egy olyan szkenner elleni reputációs találat, amely amúgy sem ért volna el semmit, növeli az összesítést, egy csendes hét pedig semmit sem bizonyít a HTTPS-forgalomról, amelyet a motor nem tud elolvasni.

A Threat Prevention szolgáltatásban a státusz legalább annyira számít, mint a súlyosság. A „Nagy kockázatú csomagok automatikus eldobása” opció csak a magas kategóriára vonatkozik, így a közepes súlyosságú bejegyzések rögzítésre és továbbításra kerülnek. Egy olyan felület, amely Riasztás (Alert) állapotot mutat, azt jelzi, hogy a csomag kézbesítve lett.

A szignatúra-hírforrás egy ellátási lánc. Az ET Open ütemezés szerint frissül, elmarad a kereskedelmi szabálykészlettől, és előfordulhat, hogy egy többnapos sérülékenységhez egyáltalán nem ad ki semmit. Az az irányítópult, amely naprakésznek jelenti az adatbázist, azt jelzi, hogy az megegyezik a hírforrással, nem pedig azt, hogy a hírforrás lefedi a jelenleg kihasznált sérülékenységeket.

Ezek egyike sem helyettesíti a javítások telepítését. Az itt tárgyalt minden egyes réteg csupán időt nyer arra a lépésre, amely valóban megszünteti a sebezhetőséget: az érintett szoftver frissítésére. A PHP2Shell esetében ez új PHP-csomagokat és újraépített konténereket jelentett, és ezt semmilyen hálózati vezérlés nem helyettesíthette.

Végül ne engedjen a kísértésnek, hogy egy figyelmeztetés elolvasása után minden kategóriát bekapcsoljon. Az olyan kategóriák, mint a Misc activity, több ezer alacsony értékű szabályt tartalmaznak, amelyek főként csak zajt generálnak, és ugyanazt a kapacitást fogyasztják, amire a hasznos kategóriáknak lenne szükségük. Egy csendes, jól behangolt eseménylista, amelyet valóban elolvas, többet ér, mint egy zajos, amelyet megtanul figyelmen kívül hagyni.

Gyakran Ismételt Kérdések #

Referenciák és videók bemutatók #

Elsődleges források a fent leírtakhoz, valamint három útmutató, amelyekre érdemes időt szánni.

• Synology Tudásközpont: 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-tárházak is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.