
Synology Threat Prevention: lo que detecta y lo que no puede ver
19 min read
- Ver como Markdown Abrir esta página como Markdown sin formato (Se abre en una pestaña nueva)
- Abrir en ChatGPT Haz preguntas sobre esta página. (Se abre en una pestaña nueva)
- Abierto en Claude Haz preguntas sobre esta página. (Se abre en una pestaña nueva)
- Abrir en Google AI Studio Haz preguntas sobre esta página (se requiere una cuenta de Google). (Se abre en una pestaña nueva)
Threat Prevention es el paquete al que la mayoría de la gente recurre en el momento en que decide alojar un sitio web en un Synology NAS. Se ubica en el enrutador, tiene un icono de escudo y su panel de control cuenta los ataques por cientos, por lo que parece lo que mantiene seguro un sitio público. Lo ejecutamos en un RT6600ax frente a cada máquina que poseemos y ha valido la pena tenerlo. También es, para un sitio web autoalojado, casi totalmente irrelevante.
Este artículo de NAS Hosting 101 abre nuestro propio enrutador, lee una semana real de eventos de él y muestra exactamente dónde Threat Prevention deja de poder ayudar, usando PHP2Shell como ejemplo de un ataque que Threat Prevention nunca iba a ver.
Punto SynoPower Club: Pasé mucho tiempo en el área de soporte de Synology y la pregunta era constante: qué opción debo activar para detener este ataque. Es el instinto correcto pero enfocado en el equipo equivocado. Lo que finalmente me hizo comprenderlo fue leer nuestra propia lista de eventos en lugar de la página de funciones. Cada alerta que nuestro enrutador ha registrado este mes era una dirección con mala reputación, no una solicitud con una carga útil maliciosa. Una vez que ve eso, deja de pedirle a Threat Prevention que inspeccione el tráfico que sostiene en un sobre sellado.
Qué hace realmente Threat Prevention en un enrutador Synology #
Threat Prevention es un sistema de detección y prevención de intrusiones basado en el linaje de Snort y Suricata. Lee los paquetes a medida que el enrutador los reenvía, los compara con un conjunto de firmas y registra una alerta o descarta el paquete. En nuestro RT6600ax, el flujo de firmas es ET Open, el nivel gratuito del conjunto de reglas de Emerging Threats, actualizado diariamente a las 09:00.
De ese diseño se derivan tres propiedades, y las tres importan más que cualquier casilla de verificación en la interfaz:
- 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 readNo hay intercepción TLS en ninguna parte de Threat Prevention, por lo que una carga útil cifrada es opaca.
- 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.
Nada de eso es un defecto. Un IPS en el perímetro de la red es algo razonable y útil. El error es asumir que el perímetro es donde se ataca un sitio web.
Threat Prevention frente a un Firewall de aplicaciones web #
La forma más clara de ver la diferencia es poner Threat Prevention junto a un firewall de aplicaciones web y preguntar qué sostiene cada uno cuando toma su decisión. Threat Prevention sostiene un paquete. Un WAF sostiene una solicitud HTTP descifrada.
| Question | Router IPS | Reverse-proxy WAF |
|---|---|---|
| Dónde se corre | 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 |
Esos no son productos competidores. Cubren diferentes segmentos del mismo trayecto, y un sitio autoalojado necesita el segundo mucho más que el primero. Mantenemos ambos y esperamos cosas completamente diferentes de cada uno.
Lectura de 595 eventos de una semana en nuestro propio enrutador #
Aquí está la pantalla de visión general de Threat Prevention de nuestro enrutador de producción el 25 de octubre de 2026. Quinientos noventa y cinco eventos maliciosos durante siete días, 75 de ellos de gravedad alta. Parece un muro que retiene una inundación.

Dos detalles en esa pantalla valen más que la cifra principal. El primero es que solo un dispositivo aparece bajo amenazas potenciales, y es REVERSE_MAIL, la máquina que finaliza TLS y ejecuta MailPlus. El segundo es la fecha de la firma junto a la marca de verificación verde. Ahora abra un solo evento y lea qué se activó realmente.

Clasificación Misc Attack, gravedad Media, estado Alert, nombre de firma ET CINS Active Threat Intelligence Poor Reputation IP group 24. Abra el cuerpo de la regla y comienza con alert ip y luego una larga lista de direcciones. Eso es una búsqueda en lista de bloqueo. Ninguna parte de la solicitud HTTP fue leída, porque ninguna parte podía serlo. Tomamos muestras de eventos contra un segundo destino, nuestro host de Virtual DSM, y encontramos la misma clase de regla con un número de grupo diferente.
Así que el resumen honesto de una semana es este: el enrutador reconoció unos cientos de conexiones de direcciones que ya tenían mala reputación. Eso es realmente útil. No es una detección de ataques web, y nadie debería interpretar el número 595 como si lo fuera.
Cómo auditar Threat Prevention en 4 pasos #
Antes de confiar algo a Threat Prevention, dedique diez minutos a averiguar qué está haciendo realmente en su propia red. Cada paso a continuación es de solo lectura y no cambia nada.
Open one event and read the signature body #
Vaya a Threat Prevention, luego a Eventos y haga clic en cualquier entrada. Mire más allá del distintivo de gravedad en color, en la casilla Reglas de firma. Una regla que comienza con alert ip coincide únicamente con la reputación de la dirección. Una regla que contiene content o pcre coincide con la carga útil. Cuente cuántas de cada una puede encontrar en su propia lista antes de decidir qué está protegiendo Threat Prevention.
Check which interfaces are monitored #
Open Settings and read the Monitored Interfaces table. Only the interfaces ticked there are inspected, and in a normal deployment those are the internet-facing ones. Traffic between two devices on the same LAN subnet is switched rather than routed, so it never reaches the inspection engine and no setting on this page can change that.
Find out what happens when the router is busy #
In the same panel, look at the default mode. Network stability priority means that when traffic exceeds what the engine can process, the excess is passed through unfiltered. Security priority means the excess is dropped instead. One choice fails open and keeps your line up, the other fails closed and takes your line down. Decide which one you actually want.
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ónde se gana realmente su lugar #
Mantenemos Threat Prevention activado, y no por superstición. Hay cuatro tareas que realiza y que ninguna otra herramienta de nuestro stack hace.
- 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.
Lo que esos cuatro tienen en común es que ninguno de ellos es un ataque a un sitio web.
Por qué el propietario de un sitio le pide a Threat Prevention lo equivocado #
Cuando aloja un sitio en un NAS, la ruta de la solicitud suele tener un proxy inverso. El nuestro se ve así, y esa estructura es lo que lo decide todo:
- The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
- What is left crosses the router, donde Threat Prevention ve un flujo TLS cifrado y nada más.
- El 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.
Lea esas cuatro líneas juntas y la trampa es evidente. El único segmento donde la solicitud existe en forma legible es el salto final, y ese es el único segmento que el enrutador no puede observar. En todos los lugares donde el enrutador puede observar, la solicitud está cifrada. No hay ninguna casilla de verificación que resuelva una contradicción como esa, y Threat Prevention no está fallando cuando permanece en silencio. Simplemente está informando con precisión sobre el tráfico que, estructuralmente, no puede leer.
Esta es también la razón por la que apuntar Threat Prevention a un sitio específico no funciona. El paquete está vinculado a las interfaces del enrutador, no a los nombres de host. No tiene noción de a cuál de sus sitios pertenece una conexión, porque nunca ve el encabezado Host.

Tres razones por las que PHP2Shell fue invisible en el enrutador #
PHP2Shell, el par de fallas de ejecución remota de código antes de la autenticación rastreadas como CVE-2026-109618 y CVE-2026-109619, se filtró el 20 de octubre de 2026 y se corrigió en el proyecto original al día siguiente. Es exactamente el tipo de cosa que la gente espera que un IPS de enrutador absorba, y vale la pena ser específicos sobre por qué no pudo hacerlo.
En primer lugar, el tráfico estaba cifrado en cada segmento que el enrutador supervisa. 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.
En segundo lugar, no existe ninguna firma de Threat Prevention que se pueda activar. 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.

En tercer lugar, y lo más fundamental, este ataque no tiene una forma de carga útil que coincidir. 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.
La primera solicitud se define por la cantidad de memoria que consume, no por ninguna secuencia de bytes; una carga grande, un cuerpo JSON enorme, una matriz profunda y una cadena larga en una expresión regular son todos válidos. La segunda no contiene ningún byte malicioso en absoluto. Un IPS decide por paquete y por flujo. No tiene ningún modelo de un proceso de trabajo que transporte un estado contaminado de una solicitud a la siguiente, que es precisamente donde reside este error.
Eso también establece los límites de la mitigación que circulaba en ese momento, que consistía en desactivar session.upload_progress en la configuración de PHP. Elimina una forma bien documentada de alcanzar la segunda CVE, y en una máquina que realmente no se puede parchear es mejor que nada. No es una solución definitiva: el agotamiento de la memoria no es accesible solo a través de esa única característica, y la configuración no tiene ninguna relación con la CVE-2026-109618. La usamos como medida temporal en exactamente un host y la tratamos como tiempo prestado, no como una resolución. El relato completo de cómo parcheamos está en nuestro PHP2Shell write-up.
Apertura por fallo de diseño y el día que nos costó nuestro correo #
Hay una propiedad más que vale la pena conocer antes de tratar a Threat Prevention como un control en el que se pueda confiar. Su valor predeterminado recomendado es el modo de prioridad de estabilidad de la red, y la interfaz declara lo que eso significa sin ningún eufemismo: cuando el tráfico excede la capacidad de procesamiento, los paquetes pendientes se omiten sin filtrar. La alternativa, el modo de prioridad de seguridad, los descarta en su lugar y advierte que la conexión será inestable hasta que se resuelva el problema.
Ese es un valor predeterminado sensato para un enrutador doméstico. Sin embargo, significa que Threat Prevention es más débil en el momento exacto en que desearía que fuera más fuerte, porque una inundación es tanto lo que desea filtrar como lo que excede la capacidad.
También tenemos registrado el otro modo de fallo. El 2 de agosto de 2026, alguien atacó nuestro proxy inverso 116 veces con un exploit para un error de PHP-CGI en Windows que no puede funcionar en absoluto contra Linux. Threat Prevention descartó suficientes paquetes como para bloquear su propio estado y luego comenzó a rechazar el tráfico saliente de la misma máquina que estaba defendiendo. Nuestra cola de correo se detuvo y el síntoma parecía exactamente un fallo de DNS. Reiniciar el enrutador lo solucionó. No apareció nada en el registro de acceso del proxy, porque nada llegó nunca al proxy. Un ataque que era estructuralmente incapaz de tener éxito nos costó una interrupción del servicio debido a aquello que debía detenerlo.

Observe los recuentos de habilitación en esa lista mientras esté allí. Ataque de aplicación web muestra 5.928 de 6.010 reglas activas, y la proporción es similar en todas las clases que nos interesan. Activar una clase no activa todas las reglas que contiene, y la interfaz no ofrece ninguna forma de ver cuáles de las restantes le faltan.
Coloque un proxy delante y, luego, restrinja el origen a él #
Si aloja un sitio web desde un NAS, el control que realiza el trabajo que el router no puede hacer es un WAF de proxy inverso. Utilizamos Cloudflare, y la razón es la posición más que la marca: TLS termina en el borde (edge), por lo que la solicitud completa es legible en el momento en que se toma la decisión. El método, la ruta, la consulta, los encabezados, las cookies y el cuerpo están todos disponibles para una regla.
Por eso las protecciones para PHP2Shell llegaron allí y no al router. Cuando se publicaron los CVE, el conjunto de reglas gestionado incorporó siete reglas para el par en dos días, y ya estaban activas en las cuatro zonas que gestionamos antes de que termináramos de reconstruir nuestros propios contenedores. Nunca apareció ningún equivalente en la fuente de Threat Prevention, y cinco días después todavía no hay ninguna regla pública de Snort o Emerging Threats para instalar.
Una advertencia que importa más que la elección del proveedor. Un proxy delante solo ayuda mientras no se pueda eludir. Si la dirección de origen responde directamente a la Internet pública, cualquiera que la descubra omitirá cada regla de borde que haya escrito. Restrinja el puerto 443 en el origen a los rangos de red del proxy, obtenga esos rangos desde el endpoint del proveedor en lugar de codificarlos de forma fija y verifique el bloqueo solicitando el sitio directamente desde su dirección. Nuestra configuración más amplia, y las cuatro capas detrás de esta, se describen en the five layers we run.
Límites y notas de seguridad de Threat Prevention #
Threat Prevention necesita almacenamiento externo en el router y no está disponible en todos los modelos, por lo que debe confirmar la compatibilidad de su hardware antes de planificar en función de él. El motor es también el proceso que más recursos consume en su router y, en una unidad de consumo, es el componente con más probabilidades de convertirse en el límite de rendimiento. Mida antes y después en lugar de confiar en la cifra de marketing.
Considere cada número de la pantalla de visión general como un recuento de coincidencias de firmas, no como un recuento de ataques detenidos. Ambos difieren en ambas direcciones. Una coincidencia de reputación contra un escáner que nunca iba a lograr nada infla el total, y una semana tranquila no prueba nada sobre el tráfico HTTPS que el motor no puede leer.
En Threat Prevention, el estado importa tanto como la gravedad. Descartar paquetes de alto riesgo automáticamente solo actúa sobre la banda alta, por lo que las entradas de gravedad media se registran y reenvían. Una interfaz que dice Alerta le está indicando que el paquete fue entregado.
La fuente de firmas es una cadena de suministro. ET Open se actualiza según una programación, va por detrás del conjunto de reglas comercial y es posible que no publique nada para una vulnerabilidad que tiene varios días. Un panel de control que informa que la base de datos está actualizada está indicando que coincide con la fuente, no que la fuente cubra lo que se está explotando actualmente.
Nada de esto reemplaza la aplicación de parches. Cada capa analizada aquí gana tiempo para lo que realmente cierra una vulnerabilidad, que es actualizar el software afectado. Para PHP2Shell, eso significó nuevos paquetes PHP y contenedores reconstruidos, y ningún control de red pudo sustituirlo.
Por último, resista la tentación de activar todas las clases tras leer un aviso de seguridad. Clases como Misc activity incluyen miles de reglas de poco valor que solo generan ruido y consumen la misma capacidad que necesitan las clases útiles. Una lista de eventos silenciosa y bien ajustada que realmente lea supera a una ruidosa que aprenda a ignorar.
Preguntas frecuentes #
¿Protege Threat Prevention un sitio web alojado en mi NAS? #
Apenas, y no de la manera que sugiere el nombre. Un sitio web se sirve a través de HTTPS y Threat Prevention no realiza ninguna intercepción TLS, por lo que la solicitud es opaca allí donde el enrutador la ve. En una configuración típica, la solicitud solo se vuelve legible después de que un proxy inverso finaliza TLS, y ese salto suele estar en la misma subred, por lo que se conmuta en lugar de enrutarse y el enrutador nunca la transporta. Utilice un WAF con proxy inverso para el sitio web y mantenga Threat Prevention para aquello en lo que es bueno.
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.
¿Inspecciona Threat Prevention el tráfico entre dispositivos de mi 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.
¿Es seguro dejar activado Threat Prevention? #
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.
¿Ayudó en algo Threat Prevention con PHP2Shell? #
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? #
Coloque un proxy inverso con un conjunto de reglas gestionado frente al sitio web y, a continuación, restrinja el origen para que el puerto 443 solo responda a esa red de proxy. Esos dos pasos juntos trasladan el punto de inspección a un lugar donde la solicitud sea legible y eliminan la omisión que la anularía. Mantenga habilitado Threat Prevention después para el comando y control saliente y para los servicios en texto claro, que es donde realiza un trabajo real.
Referencias y tutoriales en vídeo #
Fuentes primarias de todo lo expuesto anteriormente, además de tres guías paso a paso que valen la pena.
- Centro de conocimiento de 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.
- Rangos de IP de Cloudflare is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.