Synology Prevenção de Ameaças: O que deteta e o que não consegue ver
Atualizado em 25 de outubro de 2026
Threat Prevention é o pacote que a maioria das pessoas procura no momento em que decide hospedar um site num NAS Synology. Ele fica no roteador, tem um ícone de escudo e seu painel conta os ataques às centenas, parecendo assim a ferramenta que mantém um site público seguro. Nós o executamos em um RT6600ax na frente de cada máquina que possuímos, e tem valido a pena ter. Também é, para um site auto-hospedado, quase inteiramente irrelevante.
Este artigo NAS Hosting 101 abre nosso próprio roteador, lê uma semana real de eventos nele e mostra exatamente onde o Threat Prevention deixa de poder ajudar, usando o PHP2Shell como exemplo de um ataque que o Threat Prevention nunca iria ver.
Ponto SynoPower Club: Passei muito tempo no suporte da Synology e a pergunta surgia constantemente: qual opção devo ativar para parar esse ataque. É o instinto certo voltado para a caixa errada. O que finalmente me fez entender foi ler nossa própria lista de eventos em vez da página do recurso. Cada alerta gravado pelo nosso roteador este mês era um endereço com má reputação, não uma solicitação com um payload malicioso. Uma vez que você vê isso, deixa de pedir ao Threat Prevention para inspecionar o tráfego que ele está segurando em um envelope selado.
O que o Threat Prevention realmente faz em um roteador Synology #
O Threat Prevention é um sistema de deteção e prevenção de intrusões construído com base nas famílias Snort e Suricata. Ele lê os pacotes conforme o roteador os encaminha, compara-os com um conjunto de assinaturas e registra um alerta ou descarta o pacote. Em nosso RT6600ax, o feed de assinaturas é o ET Open, a camada gratuita do conjunto de regras do Emerging Threats, atualizado diariamente às 09:00.
Três propriedades decorrem desse projeto, e todas as três importam mais do que qualquer caixa de seleção na interface:
- 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. Não há interceptação TLS em nenhum lugar do Threat Prevention, portanto, um payload criptografado é opaco.
- 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 disso é um defeito. Um IPS no perímetro da rede é algo razoável e útil de se possuir. O erro é presumir que o perímetro é onde um site é atacado.
Threat Prevention vs Web Application Firewall #
A maneira mais clara de ver a lacuna é colocar o Threat Prevention ao lado de um firewall de aplicação web (WAF) e perguntar o que cada um está segurando quando toma sua decisão. O Threat Prevention está segurando um pacote. Um WAF está segurando uma solicitação HTTP descriptografada.
| Question | Router IPS | Reverse-proxy WAF |
|---|---|---|
| Onde ele 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 |
Esses não são produtos concorrentes. Eles cobrem segmentos diferentes da mesma jornada, e um site auto-hospedado precisa muito mais do segundo do que do primeiro. Mantemos ambos e esperamos coisas completamente diferentes de cada um.
Lendo 595 eventos de uma semana em nosso próprio roteador #
Aqui está a tela de visão geral do Threat Prevention do nosso roteador de produção em 25 de outubro de 2026. Quinhentos e noventa e cinco eventos maliciosos ao longo de sete dias, 75 deles de alta gravidade. Parece uma parede contendo uma inundação.
Dois detalhes nessa tela valem mais do que o número principal. O primeiro é que apenas um dispositivo aparece em ameaças potenciais, e é o REVERSE_MAIL, a máquina que encerra o TLS e executa o MailPlus. O segundo é a data da assinatura ao lado do sinal de verificação verde. Agora abra um único evento e leia o que realmente disparou.
Classificação Misc Attack, gravidade Média, status Alerta, nome da assinatura ET CINS Active Threat Intelligence Poor Reputation IP group 24. Abra o corpo da regra e ele começa com alert ip e depois uma longa lista de endereços. Isso é uma consulta a uma lista de bloqueios. Nenhuma parte da solicitação HTTP foi lida, porque nenhuma parte dela poderia ser. Amostramos eventos em um segundo destino, nosso host Virtual DSM, e encontramos a mesma classe de regra com um número de grupo diferente.
Portanto, o resumo honesto de uma semana é este: o roteador reconheceu algumas centenas de conexões de endereços que já tinham uma má reputação. Isso é verdadeiramente útil. Não é uma deteção de ataque web, e ninguém deve ler o número 595 como se fosse.
Como auditar o Threat Prevention em 4 etapas #
Antes de confiar no Threat Prevention para qualquer coisa, dedique dez minutos para descobrir o que ele realmente está fazendo em sua própria rede. Cada etapa abaixo é somente leitura e não altera nada.
Abra um evento e leia o corpo da assinatura #
Vá para Threat Prevention, depois Eventos e clique em qualquer entrada. Olhe além do selo de gravidade colorido na caixa de regras de assinatura. Uma regra que começa com alert ip corresponde apenas à reputação do endereço. Uma regra que contém content ou pcre corresponde ao payload. Conte quantas de cada você consegue encontrar em sua própria lista antes de decidir o que o Threat Prevention está protegendo.
Verifique quais interfaces são monitoradas #
Abra as Configurações e consulte a tabela Interfaces Monitoradas. Apenas as interfaces assinaladas lá são inspecionadas e, em uma implantação normal, essas são as voltadas para a internet. O tráfego entre dois dispositivos na mesma sub-rede LAN é comutado em vez de roteado, portanto nunca atinge o mecanismo de inspeção e nenhuma configuração nesta página pode alterar isso.
Descubra o que acontece quando o roteador está ocupado #
No mesmo painel, observe o modo padrão. Prioridade de estabilidade da rede significa que, quando o tráfego excede o que o mecanismo pode processar, o excesso é passado sem filtragem. Prioridade de segurança significa que o excesso é descartado em vez disso. Uma escolha falha aberta e mantém sua linha ativa, a outra falha fechada e derruba sua linha. Decida qual delas você realmente deseja.
Tente adicionar uma regra própria #
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.
Onde ele realmente conquista seu lugar #
Mantemos o Threat Prevention ativado, e não por superstição. Existem quatro tarefas que ele faz e que mais nada em nossa pilha de softwares faz.
- 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.
O que essas quatro têm em comum é que nenhuma delas é um ataque a um site.
Por que o proprietário de um site pede a coisa errada ao Threat Prevention #
Quando você hospeda um site em um NAS, o caminho da solicitação geralmente inclui um proxy reverso. O nosso se parece com isto, e a sua estrutura é o que decide tudo:
- The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
- What is left crosses the router, onde o Threat Prevention vê um fluxo TLS criptografado e nada mais.
- O 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.
Leia essas quatro linhas juntas e a armadilha fica óbvia. O único segmento onde a solicitação existe em forma legível é o salto final, e esse é o único segmento que o roteador não pode observar. Em todos os lugares que o roteador pode observar, a solicitação está criptografada. Não existe uma caixa de seleção que resolva uma contradição como essa, e o Threat Prevention não está falhando quando permanece em silêncio. Ele está relatando com precisão sobre um tráfego que é estruturalmente incapaz de ler.
É também por isso que apontar o Threat Prevention para um site específico não funciona. O pacote está vinculado às interfaces do roteador, não aos nomes de host. Ele não tem conceito de a qual dos seus sites uma conexão pertence, porque ele nunca vê o cabeçalho Host.
Três Razões Pelas Quais o PHP2Shell Era Invisível no Roteador #
O PHP2Shell, o par de falhas de execução remota de código pré-autenticação rastreadas como CVE-2026-109618 e CVE-2026-109619, vazou em 20 de outubro de 2026 e foi corrigido upstream no dia seguinte. É exatamente o tipo de coisa que as pessoas esperam que um IPS de roteador absorva, e vale a pena ser específico sobre o motivo pelo qual ele não conseguiu.
Primeiro, o tráfego estava criptografado em todos os segmentos que o roteador monitora. 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.
Em segundo lugar, nenhuma assinatura do Threat Prevention existe para ser ativada. 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.
Terceiro, e mais fundamentalmente, este ataque não tem um formato de payload para corresponder. 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.
A primeira solicitação é definida pelo quanto de memória ela consome, e não por qualquer sequência de bytes; um upload grande, um corpo JSON enorme, um array profundo e uma string longa em uma expressão regular todos se qualificam. A segunda não carrega nenhum byte malicioso. Um IPS decide por pacote e por fluxo. Ele não tem modelo de um processo de trabalho carregando estado contaminado de uma solicitação para a próxima, que é exatamente onde esse bug reside.
Isso também estabelece os limites da mitigação que circulava na época, que era desativar session.upload_progress na configuração do PHP. Ela remove uma forma bem documentada de alcançar a segunda CVE e, em uma máquina que você realmente não pode aplicar patch, é melhor do que nada. Não é uma correção: o esgotamento de memória não é alcançável apenas através desse recurso, e a configuração não tem relação alguma com a CVE-2026-109618. Nós a usamos como uma solução temporária em exatamente um host e a tratamos como tempo ganho, não como uma resolução. O relato completo de como aplicamos o patch está em nosso PHP2Shell write-up.
Fail Open por Design, e o Dia em Que Isso Nos Custou Nosso E-mail #
Há mais uma propriedade que vale a pena saber antes de tratar o Threat Prevention como um controle no qual você pode confiar. Seu padrão recomendado é o modo de prioridade de estabilidade de rede, e a interface declara o que isso significa sem nenhum eufemismo: quando o tráfego excede a capacidade de processamento, os pacotes pendentes são ignorados sem filtragem. A alternativa, o modo de prioridade de segurança, ignora-os em vez disso e avisa que a conexão ficará instável até que o problema seja resolvido.
Esse é um padrão sensato para um roteador doméstico. Mas isso significa que o Threat Prevention é mais fraco exatamente no momento em que você mais gostaria que ele fosse forte, porque um flood é tanto o que você quer filtrado quanto o que excede a capacidade.
Também temos o outro modo de falha registrado. Em 2 de agosto de 2026, alguém atingiu nosso proxy reverso 116 vezes com um exploit para um bug do PHP-CGI do Windows que não pode funcionar de forma alguma contra o Linux. O Threat Prevention descartou pacotes suficientes para travar seu próprio estado e depois começou a recusar o tráfego de saída da própria máquina que estava defendendo. Nossa fila de e-mails parou e o sintoma parecia exatamente uma falha de DNS. Reiniciar o roteador resolveu o problema. Nada apareceu no log de acesso do proxy, porque nada chegou ao proxy. Um ataque que era estruturalmente incapaz de ter sucesso ainda nos custou uma interrupção, por meio da própria ferramenta que deveria pará-lo.
Observe as contagens de ativados nessa lista enquanto estiver lá. Web Application Attack mostra 5.928 de 6.010 regras ativas, e a proporção é semelhante nas classes com as quais nos importamos. Ativar uma classe não ativa todas as regras dentro dela, e a interface não oferece nenhuma maneira de ver quais das restantes você está perdendo.
Coloque um Proxy na Frente e Bloqueie a Origem para Ele #
Se você hospeda um site a partir de um NAS, o controle que faz o trabalho que o roteador não consegue fazer é um WAF de proxy reverso. Nós usamos a Cloudflare, e o motivo é a posição e não a marca: o TLS é finalizado na borda (edge), para que a solicitação completa possa ser lida no momento em que a decisão é tomada. Método, caminho, consulta, cabeçalhos, cookies e corpo estão todos disponíveis para uma regra.
É por isso que as proteções contra PHP2Shell chegaram lá e não no roteador. Quando os CVEs surgiram, o conjunto de regras gerenciado ganhou sete regras para a dupla em apenas dois dias, e elas já estavam ativas em todas as quatro zonas que operamos antes mesmo de terminarmos de reconstruir nossos próprios contêineres. Nenhum equivalente jamais apareceu no feed do Threat Prevention e, cinco dias depois, ainda não há uma regra pública do Snort ou Emerging Threats para instalar.
Um aviso que importa mais do que a escolha do provedor. Um proxy à frente só ajuda enquanto não puder ser contornado. Se o seu endereço de origem responder à internet pública diretamente, qualquer pessoa que o descobrir ignorará cada regra de borda que você escreveu. Restrinja a porta 443 na origem aos intervalos de rede do proxy, obtenha esses intervalos no endpoint do provedor em vez de inseri-los manualmente no código e verifique o bloqueio solicitando o site diretamente a partir de seu endereço. Nossa configuração mais ampla, e as quatro camadas por trás desta, são descritas em the five layers we run.
Limites e Notas de Segurança do Threat Prevention #
O Threat Prevention precisa de armazenamento externo no roteador e não está disponível em todos os modelos, portanto confirme o suporte para o seu hardware antes de planejar o uso. O mecanismo também é a tarefa mais exigente do seu roteador e, em uma unidade de consumo, é o componente com maior probabilidade de se tornar o limite de taxa de transferência. Meça antes e depois em vez de confiar nos números do marketing.
Trate cada número na tela de visão geral como uma contagem de correspondências de assinatura, e não como uma contagem de ataques interrompidos. Os dois diferem em ambas as direções. Um impacto de reputação contra um scanner que nunca alcançaria nada infla o total, e uma semana tranquila não prova nada sobre o tráfego HTTPS que o mecanismo não consegue ler.
No Threat Prevention, o status importa tanto quanto a gravidade. Descartar pacotes de alto risco automaticamente só atua na faixa alta, portanto, entradas de gravidade média são registradas e encaminhadas. Uma interface que exibe Alerta está informando que o pacote foi entregue.
O feed de assinaturas é uma cadeia de suprimentos. O ET Open é atualizado segundo um cronograma, fica atrás do conjunto de regras comercial e pode não fornecer nada para uma vulnerabilidade com dias de existência. Um painel que relata o banco de dados como atualizado está relatando que ele corresponde ao feed, não que o feed cobre o que está sendo explorado no momento.
Nada disto substitui a aplicação de patches. Cada camada discutida aqui ganha tempo para aquilo que realmente fecha uma vulnerabilidade, que é atualizar o software afetado. Para o PHP2Shell, isso significava novos pacotes PHP e contentores reconstruídos, e nenhum controlo de rede o substituiu.
Por fim, resista ao impulso de ativar todas as classes após ler um aviso de segurança. Classes como Misc activity contêm milhares de regras de baixo valor que geram maioritariamente ruído e consomem a mesma capacidade de que as classes úteis precisam. Uma lista de eventos silenciosa e bem ajustada que realmente lê é melhor do que uma ruidosa que aprende a ignorar.
Perguntas frequentes #
O Threat Prevention protege um site hospedado em meu NAS? #
Quase nada e não da maneira que o nome sugere. Um site é servido via HTTPS, e o Threat Prevention não realiza interceptação TLS, portanto, a solicitação é opaca onde quer que o roteador possa vê-la. Em uma configuração típica, a solicitação só se torna legível depois que um proxy reverso encerra o TLS, e esse salto geralmente está na mesma sub-rede, portanto, é comutado em vez de roteado e o roteador nunca o carrega. Use um WAF de proxy reverso para o site e mantenha o Threat Prevention para o que ele é bom.
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.
O Threat Prevention inspeciona o tráfego entre dispositivos na minha 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.
É seguro deixar o Threat Prevention ativado? #
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.
O Threat Prevention ajudou de alguma forma com o 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 um proxy reverso com um conjunto de regras gerenciado na frente do site e, em seguida, restrinja a origem para que a porta 443 responda apenas a essa rede proxy. Essas duas etapas juntas movem o ponto de inspeção para um local onde a solicitação é legível e removem o desvio que a anularia. Mantenha o Threat Prevention ativado depois para comando e controle de saída e para serviços em texto claro, onde ele faz o trabalho real.
Referências e tutoriais em vídeo #
Fontes primárias para tudo o que foi dito acima, além de três tutoriais que valem o tempo investido.
- Centro de Conhecimento da 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.
- Intervalos de IP do Cloudflare is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.