Synology Threat Prevention: Was es erkennt und was es nicht sieht
Aktualisiert am Oktober 2026
Threat Prevention ist das Paket, zu dem die meisten greifen, sobald sie beschließen, eine Website auf einem Synology NAS zu hosten. Es befindet sich auf dem Router, hat ein Schild-Symbol und sein Dashboard zählt Angriffe nach Hunderten – es sieht also genau nach der Lösung aus, die eine öffentliche Website schützt. Wir führen es auf einem RT6600ax vor allen unseren Geräten aus, und es war seine Anschaffung wert. Für eine selbst gehostete Website ist es jedoch fast völlig am Ziel vorbei.
Dieser „NAS Hosting 101“-Artikel öffnet unseren eigenen Router, liest die Ereignisse einer echten Woche aus und zeigt anhand von PHP2Shell als Beispiel eines Angriffs, den Threat Prevention niemals erkennen konnte, genau, wo Threat Prevention an seine Grenzen stößt.
SynoPower Club-Punkt: Ich habe lange im Synology-Support gearbeitet, und die Frage kam ständig auf: Welche Option muss ich aktivieren, um diesen Angriff zu stoppen? Es ist der richtige Instinkt, aber das falsche System. Was mir schließlich die Augen öffnete, war das Lesen unserer eigenen Ereignisliste anstelle der Funktionsseite. Jeder Alarm, den unser Router diesen Monat aufgezeichnet hat, betraf eine Adresse mit schlechtem Ruf, nicht eine Anfrage mit einer schädlichen Nutzlast. Sobald man das gesehen hat, hört man auf, von Threat Prevention zu verlangen, Verkehr zu prüfen, den es in einem versiegelten Umschlag hält.
Was Threat Prevention auf einem Synology Router wirklich tut #
Threat Prevention ist ein Intrusion Detection and Prevention System, das auf der Abstammung von Snort und Suricata basiert. Es liest Pakete beim Weiterleiten durch den Router, gleicht sie mit einem Signaturset ab und zeichnet entweder eine Warnung auf oder verwirft das Paket. Auf unserem RT6600ax ist der Signatur-Feed ET Open, die kostenlose Variante des Emerging Threats-Regelsatzes, der täglich um 09:00 Uhr aktualisiert wird.
Aus diesem Design ergeben sich drei Eigenschaften, und alle drei sind wichtiger als jedes Kontrollkästchen in der Benutzeroberfläche:
- 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. In Threat Prevention gibt es keine TLS-Entschlüsselung, sodass eine verschlüsselte Nutzlast undurchsichtig ist.
- 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.
Nichts davon ist ein Mangel. Ein IPS am Netzwerkperimeter ist eine sinnvolle und nützliche Sache. Der Fehler liegt in der Annahme, dass eine Website am Perimeter angegriffen wird.
Threat Prevention vs. eine Web Application Firewall #
Am deutlichsten wird der Unterschied, wenn man Threat Prevention neben eine Web Application Firewall stellt und prüft, was beide bei ihrer Entscheidung analysieren. Threat Prevention analysiert ein Paket. Eine WAF analysiert eine entschlüsselte HTTP-Anfrage.
| Question | Router IPS | Reverse-proxy WAF |
|---|---|---|
| Wo es verläuft | 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 |
Das sind keine konkurrierenden Produkte. Sie decken verschiedene Abschnitte derselben Strecke ab, und eine selbst gehostete Website benötigt das zweite weit mehr als das erste. Wir nutzen beide und erwarten von jedem etwas völlig anderes.
Auswertung von 595 Ereignissen aus einer Woche auf unserem eigenen Router #
Hier ist die Übersichtsansicht von Threat Prevention auf unserem Produktionsrouter vom 25. Oktober 2026. Fünfhundertfünfundneunzig bösartige Ereignisse in sieben Tagen, davon 75 mit hoher Schweregradstufe. Es liest sich wie eine Schutzmauer gegen eine Flut.
Zwei Details auf diesem Bildschirm sind mehr wert als die Gesamtzahl der Hauptüberschrift. Das erste ist, dass überhaupt nur ein Gerät unter den potenziellen Bedrohungen auftaucht, und zwar REVERSE_MAIL, das Gerät, das TLS beendet und MailPlus ausführt. Das zweite ist das Signaturdatum neben dem grünen Häkchen. Öffnen Sie nun ein einzelnes Ereignis und lesen Sie, was tatsächlich ausgelöst wurde.
Klassifizierung Misc Attack, Schweregrad Medium, Status Alert, Signaturname ET CINS Active Threat Intelligence Poor Reputation IP group 24. Öffnet man den Regel-Body, beginnt er mit alert ip gefolgt von einer langen Liste von Adressen. Das ist ein einfacher Blocklist-Abgleich. Kein Teil der HTTP-Anfrage wurde gelesen, weil kein Teil gelesen werden konnte. Wir haben Ereignisse an einem zweiten Ziel, unserem Virtual DSM-Host, stichprobenartig geprüft und dieselbe Regelklasse mit einer anderen Gruppennummer gefunden.
Das ehrliche Fazit einer Woche lautet also: Der Router hat ein paar hundert Verbindungen von Adressen erkannt, die bereits einen schlechten Ruf hatten. Das ist durchaus nützlich. Es ist jedoch keine Erkennung von Webangriffen, und niemand sollte die Zahl 595 so interpretieren, als wäre sie das.
So überprüfen Sie Threat Prevention in 4 Schritten #
Bevor Sie Threat Prevention irgendetwas anvertrauen, nehmen Sie sich zehn Minuten Zeit, um herauszufinden, was es in Ihrem eigenen Netzwerk tatsächlich tut. Jeder der folgenden Schritte ist schreibgeschützt und ändert nichts.
Öffnen Sie ein Ereignis und lesen Sie den Signatur-Body #
Gehen Sie zu Threat Prevention, dann zu Ereignisse, und klicken Sie auf einen beliebigen Eintrag. Blicken Sie hinter das farbige Schweregrad-Badge auf das Feld „Signaturregeln“. Eine Regel, die mit alert ip beginnt, basiert allein auf der Adress-Reputation. Eine Regel, die content oder pcre enthält, prüft die Nutzdaten (Payload). Zählen Sie, wie viele von jeder Regelart Sie in Ihrer eigenen Liste finden, bevor Sie entscheiden, was Threat Prevention schützt.
Überprüfen Sie, welche Schnittstellen überwacht werden #
Öffnen Sie die Einstellungen und lesen Sie die Tabelle der überwachten Schnittstellen. Nur die dort ausgewählten Schnittstellen werden überprüft, und bei einer normalen Bereitstellung sind dies die dem Internet zugewandten. Der Datenverkehr zwischen zwei Geräten im selben LAN-Subnetz wird geswitcht und nicht geroutet, sodass er die Überprüfungs-Engine nie erreicht und keine Einstellung auf dieser Seite dies ändern kann.
Finden Sie heraus, was passiert, wenn der Router ausgelastet ist #
Schauen Sie im selben Panel auf den Standardmodus. „Priorität auf Netzwerkstabilität“ bedeutet, dass bei Datenverkehr, der die Verarbeitungskapazität der Engine übersteigt, der Überschuss ungefiltert durchgelassen wird. „Priorität auf Sicherheit“ bedeutet, dass der Überschuss stattdessen verworfen wird. Eine Option arbeitet nach dem Fail-Open-Prinzip und hält Ihre Verbindung aufrecht, die andere nach dem Fail-Closed-Prinzip und unterbricht Ihre Verbindung. Entscheiden Sie, welche Option Sie tatsächlich möchten.
Versuchen Sie, eine eigene Regel hinzuzufügen #
Öffnen Sie die benutzerdefinierte Richtlinie. Sie können die Aktion für eine vom Anbieter bereits bereitgestellte Signatur ändern und diese nach Quell- oder Zieladresse eingrenzen. Es gibt nirgendwo ein Feld, das eine selbst erstellte Signatur akzeptiert. Wenn Ihre Bedrohung neuer ist als Ihr Signatur-Feed, werden Sie auf diesem Bildschirm feststellen, dass Sie keine Möglichkeit haben zu reagieren.
Wo es sich seinen Platz wirklich verdient #
Wir lassen Threat Prevention aktiviert, und das nicht aus Aberglauben. Es erledigt vier Aufgaben, die sonst nichts in unserem Stack übernimmt.
- 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.
Was diese vier gemeinsam haben: Bei keiner davon handelt es sich um einen Angriff auf eine Website.
Warum Website-Betreiber von Threat Prevention das Falsche erwarten #
Wenn Sie eine Website auf einem NAS hosten, enthält der Anfragepfad normalerweise einen Reverse Proxy. Unserer sieht folgendermaßen aus, und dessen Aufbau entscheidet über alles:
- The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
- What is left crosses the router, wo Threat Prevention einen verschlüsselten TLS-Stream sieht und mehr nicht.
- Der 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.
Liest man diese vier Zeilen zusammen, wird die Falle offensichtlich. Der einzige Abschnitt, in dem die Anfrage in lesbarer Form vorliegt, ist der letzte Hop, und genau das ist der eine Abschnitt, den der Router nicht beobachten kann. Überall sonst, wo der Router beobachten kann, ist die Anfrage verschlüsselt. Es gibt kein Kontrollkästchen, das einen solchen Widerspruch auflöst, und Threat Prevention versagt nicht, wenn es ruhig bleibt. Es berichtet präzise über Datenverkehr, den es strukturell nicht lesen kann.
Dies ist auch der Grund, warum es nicht funktioniert, Threat Prevention auf eine bestimmte Website auszurichten. Das Paket ist an Router-Schnittstellen gebunden, nicht an Hostnamen. Es hat keine Vorstellung davon, zu welcher Ihrer Websites eine Verbindung gehört, da es den Host-Header nie sieht.
Drei Gründe, warum PHP2Shell am Router unsichtbar war #
PHP2Shell, das Paar von Schwachstellen zur Remotecodeausführung vor der Authentifizierung, die als CVE-2026-109618 und CVE-2026-109619 nachverfolgt werden, wurde am 20. Oktober 2026 bekannt und am nächsten Tag upstream gepatcht. Es ist genau die Art von Sache, von der man hofft, dass ein Router-IPS sie abfängt, und es lohnt sich, genau zu erläutern, warum das nicht möglich war.
Erstens war der Datenverkehr auf jedem Abschnitt, den der Router überwacht, verschlüsselt. 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.
Zweitens gibt es keine Threat Prevention-Signatur, die man aktivieren könnte. 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.
Drittens, und am grundlegendsten, weist dieser Angriff keine Payload-Struktur auf, die abgeglichen werden könnte. 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.
Die erste Anfrage wird dadurch definiert, wie viel Speicher sie verbraucht, nicht durch eine Bytefolge, und ein großer Upload, ein riesiger JSON-Body, ein tiefes Array sowie eine lange Zeichenfolge in einem regulären Ausdruck erfüllen alle diese Voraussetzung. Die zweite enthält keinerlei bösartige Bytes. Ein IPS entscheidet pro Paket und pro Flow. Es verfügt über kein Modell eines Worker-Prozesses, der kontaminierten Status von einer Anfrage in die nächste überträgt – und genau dort befindet sich dieser Fehler.
Das setzt auch die Grenzen der Gegenmaßnahme, die zu dieser Zeit im Umlauf war und darin bestand, session.upload_progress in der PHP-Konfiguration zu deaktivieren. Sie entfernt zwar einen gut dokumentierten Weg zum zweiten CVE, und auf einem System, das man wirklich nicht patchen kann, ist sie besser als nichts. Es ist jedoch keine Lösung: Die Speichererschöpfung kann nicht nur über diese eine Funktion erreicht werden, und die Einstellung hat keinerlei Einfluss auf CVE-2026-109618. Wir haben sie auf genau einem Host als Übergangslösung eingesetzt und als gewonnene Zeit betrachtet, nicht als Lösung. Der vollständige Bericht darüber, wie wir gepatcht haben, befindet sich in unserem PHP2Shell write-up.
Fail-Open by Design und der Tag, an dem es uns unsere E-Mails kostete #
Es gibt noch eine weitere Eigenschaft, die man kennen sollte, bevor man Threat Prevention als verlässliche Schutzmaßnahme betrachtet. Der empfohlene Standardmodus ist der Prioritätsmodus für Netzwerkstabilität, und die Benutzeroberfläche erklärt ungeschminkt, was das bedeutet: Wenn der Datenverkehr die Verarbeitungskapazität übersteigt, werden ausstehende Pakete ohne Filterung durchgewinkt. Die Alternative, der Prioritätsmodus für Sicherheit, verwirft sie stattdessen und warnt davor, dass die Verbindung instabil ist, bis das Problem behoben ist.
Das ist eine sinnvolle Standardeinstellung für einen Heimrouter. Es bedeutet jedoch, dass Threat Prevention genau in dem Moment am schwächsten ist, in dem man es am stärksten bräuchte, da eine Flutwelle sowohl das ist, was man gefiltert haben möchte, als auch das, was die Kapazität übersteigt.
Wir haben auch die andere Fehlerart dokumentiert. Am 2. August 2026 bombardierte jemand unseren Reverse Proxy 116 Mal mit einem Exploit für einen Windows PHP-CGI-Fehler, der unter Linux überhaupt nicht funktionieren kann. Threat Prevention verwarf so viele Pakete, dass sich sein eigener Status festfuhr, und verweigerte schließlich den ausgehenden Datenverkehr genau der Maschine, die es schützen sollte. Unsere E-Mail-Warteschlange kam zum Stillstand und das Symptom sah genauso aus wie ein DNS-Fehler. Ein Neustart des Routers behob das Problem. Im Proxy-Zugriffsprotokoll erschien nichts, da nie etwas den Proxy erreichte. Ein Angriff, der strukturell nicht erfolgreich sein konnte, führte dennoch zu einem Ausfall – verursacht durch genau das System, das ihn eigentlich verhindern sollte.
Schauen Sie sich bei der Gelegenheit die Anzahl der aktivierten Regeln in dieser Liste an. Web Application Attack zeigt 5.928 von 6.010 Regeln als aktiv an, und das Verhältnis ist bei den für uns relevanten Klassen ähnlich. Das Aktivieren einer Klasse aktiviert nicht jede darin enthaltene Regel, und die Benutzeroberfläche bietet keine Möglichkeit zu sehen, welche der verbleibenden Regeln Ihnen fehlen.
Schalten Sie einen Proxy davor und beschränken Sie den Origin darauf #
Wenn Sie eine Website über ein NAS bereitstellen, ist eine Reverse-Proxy-WAF die Sicherheitsmaßnahme, die das erledigt, was der Router nicht kann. Wir nutzen Cloudflare, und der Grund dafür ist eher die Position als die Marke: TLS endet am Edge, sodass die vollständige Anfrage in dem Moment lesbar ist, in dem die Entscheidung getroffen wird. Methode, Pfad, Abfrage (Query), Header, Cookies und Body stehen einer Regel alle zur Verfügung.
Deshalb sind die PHP2Shell-Schutzmaßnahmen dort und nicht auf dem Router angekommen. Als die CVEs bekannt wurden, erhielt das verwaltete Regelset innerhalb von zwei Tagen sieben Regeln für das Paar, und diese waren in allen vier von uns betriebenen Zonen live, bevor wir den Neuaufbau unserer eigenen Container abgeschlossen hatten. Im Threat Prevention-Feed erschien nie ein Äquivalent, und fünf Tage später gibt es immer noch keine öffentliche Snort- oder Emerging Threats-Regel zur Installation.
Eine Warnung, die wichtiger ist als die Wahl des Anbieters: Ein vorgeschalteter Proxy hilft nur, solange er nicht umgangen werden kann. Wenn Ihre Origin-Adresse direkt auf das öffentliche Internet antwortet, überspringt jeder, der sie entdeckt, jede von Ihnen erstellte Edge-Regel. Beschränken Sie Port 443 auf dem Origin-Server auf die Netzwerkbereiche des Proxys, rufen Sie diese Bereiche vom Provider-Endpunkt ab, anstatt sie fest einzucodieren, und überprüfen Sie die Sperre, indem Sie die Website direkt über ihre Adresse aufrufen. Unser erweitertes Setup und die vier Ebenen dahinter werden beschrieben in the five layers we run.
Threat Prevention-Einschränkungen und Sicherheitshinweise #
Threat Prevention benötigt externen Speicher auf dem Router und ist nicht für jedes Modell verfügbar. Überprüfen Sie daher die Unterstützung für Ihre Hardware, bevor Sie damit planen. Die Engine ist zudem die meiste Arbeit, die Ihr Router verrichtet, und bei einem Verbrauchergerät ist sie die Komponente, die am ehesten zur Durchsatzgrenze wird. Messen Sie vorher und nachher, anstatt den Marketingzahlen zu vertrauen.
Betrachten Sie jede Zahl auf dem Übersichtsbildschirm als eine Anzahl von Signatur-Treffern, nicht als eine Anzahl verhinderter Angriffe. Die beiden weichen in beide Richtungen voneinander ab. Ein Reputations-Treffer gegen einen Scanner, der ohnehin nichts erreicht hätte, treibt die Gesamtzahl in die Höhe, und eine ruhige Woche beweist nichts über den HTTPS-Datenverkehr, den die Engine nicht lesen kann.
Bei Threat Prevention ist der Status ebenso wichtig wie die Schwere des Risikos. „Pakete mit hohem Risiko automatisch verwerfen“ wirkt sich nur auf den hohen Bereich aus, sodass Einträge mit mittlerer Schwere aufgezeichnet und weitergeleitet werden. Eine Benutzeroberfläche, die „Warnung“ anzeigt, teilt Ihnen mit, dass das Paket zugestellt wurde.
Der Signatur-Feed ist eine Lieferkette. ET Open wird nach einem Zeitplan aktualisiert, hinkt dem kommerziellen Regelset hinterher und liefert möglicherweise überhaupt nichts für eine Schwachstelle, die bereits Tage alt ist. Ein Dashboard, das meldet, dass die Datenbank auf dem neuesten Stand ist, meldet, dass sie mit dem Feed übereinstimmt – nicht, dass der Feed abdeckt, was derzeit ausgenutzt wird.
Nichts davon ersetzt das Einspielen von Patches. Jede hier besprochene Ebene verschafft Zeit für das, was eine Sicherheitslücke tatsächlich schließt: die Aktualisierung der betroffenen Software. Für PHP2Shell bedeutete dies neue PHP-Pakete und neu erstellte Container, und keine Netzwerksteuerung konnte dies ersetzen.
Widerstehen Sie schließlich dem Drang, nach dem Lesen einer Sicherheitswarnung jede Klasse einzuschalten. Klassen wie „Misc activity“ enthalten Tausende von geringwertigen Regeln, die hauptsächlich Rauschen erzeugen und dieselbe Kapazität verbrauchen, die die nützlichen Klassen benötigen. Eine ruhige, gut abgestimmte Ereignisliste, die Sie tatsächlich lesen, ist besser als eine laute, die Sie zu ignorieren lernen.
Häufig gestellte Fragen #
Schützt Threat Prevention eine auf meinem NAS gehostete Website? #
Kaum, und nicht auf die Weise, die der Name vermuten lässt. Eine Website wird über HTTPS bereitgestellt, und Threat Prevention führt keine TLS-Entschlüsselung durch, sodass die Anfrage überall dort, wo der Router sie sehen kann, undurchsichtig ist. Bei einem typischen Setup wird die Anfrage erst lesbar, nachdem ein Reverse Proxy TLS terminiert, und dieser Hop befindet sich gewöhnlich im selben Subnetz, sodass er geswitcht statt geroutet wird und der Router ihn nie verarbeitet. Verwenden Sie eine Reverse-Proxy-WAF für die Website und nutzen Sie Threat Prevention dafür, worin es gut ist.
Welche Option sollte ich aktivieren, um eine bestimmte CVE zu stoppen? #
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.
Überprüft Threat Prevention den Verkehr zwischen Geräten in meinem 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.
Ist es sicher, Threat Prevention aktiviert zu lassen? #
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.
Hat Threat Prevention bei PHP2Shell überhaupt geholfen? #
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? #
Schalten Sie einen Reverse Proxy mit einem verwalteten Regelsatz vor die Website und beschränken Sie den Ursprung so, dass Port 443 nur diesem Proxy-Netzwerk antwortet. Diese beiden Schritte verlegen den Prüfpunkt an eine Stelle, an der die Anfrage lesbar ist, und beseitigen die Umgehung, die ihn aufheben würde. Lassen Sie Threat Prevention danach für ausgehenden Command-and-Control-Verkehr und für Klartextdienste aktiviert, wo es seine eigentliche Arbeit leistet.
Referenzen und Video-Anleitungen #
Primäre Quellen für alles oben Genannte sowie drei Anleitungen, die Ihre Zeit wert sind.
- Synology Knowledge Center: 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-Bereiche is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.