Respondendo ao Tailworm: como reforçamos nossa rede Tailscale sem interromper a produção

Como verificamos nossa rede Tailscale em relação às descobertas do Tailworm, eliminamos a exposição do Tailscale SSH e mantivemos todos os jobs de produção em execução.

Resumo

Em 25 de outubro de 2026, um pesquisador de segurança publicou o “Tailworm”: 11 descobertas no Tailscale e no headscale, divulgadas sem divulgação coordenada (coordinated disclosure). No momento em que este texto foi escrito, a Tailscale ainda não havia publicado uma correção. Na mesma noite, verificamos nossa própria rede Tailscale em relação a cada descoberta. Eliminamos a única exposição que se aplicava a nós, restringimos os acessos e mantivemos todos os jobs de produção em execução durante todo o processo.

Este artigo mostra o que verificamos, o que mudamos, como evitamos uma interrupção e o que aprendemos. Não se trata de uma verificação independente do relatório.

O que o Tailworm relatou, em resumo

As 11 descobertas se dividem em alguns grupos:

• Tailscale SSH (a mais grave). Uma sessão SSH autorizada podia ser escalada para root na máquina de destino. No laboratório do pesquisador, o ataque então se espalhou de máquina em máquina.
• App connectors. Os destinos não são validados.
• Esgotamento de memória, no servidor de controle e nos clientes.
• Casos extremos do Serve e do Funnel.

Todas as descobertas exigem que o invasor já tenha um ponto de apoio. Nenhuma delas é um ataque remoto a partir da internet. Alguns profissionais de segurança argumentam que a forma de apresentação exagera o risco, mas a principal exposição, o Tailscale SSH, é real e fácil de eliminar.

Passo 1: Verificar antes de mudar

Começamos com verificações somente leitura e registramos os resultados antes de mexer em qualquer coisa:

• as versões do cliente Tailscale em uso
• quais recursos estavam de fato ativados
• 60 dias de logs de sessões SSH, para ver quem se conectou de onde e se alguém usou encaminhamento de portas ou de sockets
• a lista de dispositivos, incluindo os que não apareciam havia meses

Resultados:

• O Tailscale SSH estava ativado em parte do nosso ambiente, portanto as descobertas F1–F3 e F5 eram relevantes para nós.
• Os recursos dos quais as demais descobertas dependem não estavam em uso, então a maioria não se aplicava.
• Os logs de SSH não mostraram origens inesperadas nem pedidos de encaminhamento.

Passo 2: Eliminar a exposição sem interrupção

A solução óbvia era desativar o Tailscale SSH e usar, em seu lugar, a autenticação padrão por chave do OpenSSH. Nossa verificação prévia encontrou uma armadilha.

O Tailscale SSH autentica pela identidade na tailnet, não pela chave SSH. Nossos scripts de automação passavam uma chave SSH na linha de comando, mas essa chave era protegida por senha (passphrase) e nunca poderia ter funcionado sem supervisão. Os jobs só rodavam porque o Tailscale SSH nunca olhava para a chave. Se tivéssemos simplesmente desativado o Tailscale SSH, todos os jobs automatizados teriam parado.

Por isso, fizemos a troca nesta ordem:

1. Criamos uma chave dedicada à automação, restrita a uma única máquina de origem e com encaminhamento desativado.
2. Testamos o novo caminho antes da troca. Abrimos uma porta OpenSSH temporária, acessível apenas dentro da tailnet, e nos conectamos a partir de um ambiente igual ao dos nossos jobs (sem agente SSH, sem terminal), usando todas as formas pelas quais nossos scripts chamam o SSH.
3. Fizemos testes negativos. A nova chave foi rejeitada fora da origem permitida, e os pedidos de encaminhamento foram recusados.
4. Preparamos primeiro um rollback automático. Antes de desativar o Tailscale SSH, agendamos um timer que o reativaria sozinho. Esse caminho de recuperação não dependia do funcionamento do SSH.
5. Fizemos a troca e verificamos cada job automatizado com novas conexões. Cada job concluiu uma execução real. Não consideramos uma sessão já aberta como prova.
6. Removemos os elementos temporários — a porta extra, a regra de firewall e o timer de rollback — e verificamos mais uma vez.

Passo 3: Reforçar o que restou

• Esvaziamos a política do Tailscale SSH. A política padrão permitia que qualquer dispositivo de um usuário abrisse sessões SSH nos outros dispositivos do mesmo usuário, inclusive como root, bastando uma nova aprovação semanal no navegador. Nós a esvaziamos, de modo que reativar o Tailscale SSH por engano já não concede acesso.
• Fechamos o SSH para a internet. Antes de fechá-lo, confirmamos que o login por um console fora de banda (out-of-band) funciona, para não ficarmos trancados do lado de fora. Depois, verificamos a partir de uma rede externa que o SSH não responde mais.
• Exigimos aprovação de dispositivos. Novos dispositivos precisam ser aprovados por um administrador antes de entrar.
• Verificamos as chaves de registro. Não havia nenhuma a revogar.
• Confirmamos o MFA na conta de administrador. Os controles de rede podem ser desfeitos por qualquer pessoa que assuma o login de administrador.
• Começamos a observar o tráfego real entre dispositivos, para que o próximo passo — restringir quais dispositivos podem falar com quais serviços — se baseie em evidências, não em suposições.

O Tailnet Lock e a aprovação de dispositivos protegem contra a entrada de um dispositivo indevido, mas não podem ser usados juntos; escolha um deles de forma consciente.

Passo 4: Corrigir o runbook, não só o servidor

Nosso antigo procedimento de recuperação mandava reconectar o servidor com o Tailscale SSH ativado. Seguido depois desta mudança, ele teria trazido de volta, silenciosamente, o recurso arriscado. Nós o reescrevemos:

• Diagnosticar primeiro. A conexão de rede caiu ou o problema é o próprio SSH (chaves, configuração, firewall)? Os dois têm correções diferentes.
• Reconectar sem alterar configurações. Não use flags adicionais, salve as configurações do nó antes de reconectar e compare-as depois.
• Abrir acesso de emergência somente com timer. Obtenha aprovação antes, agende o fechamento automático antes de abrir, restrinja a origem e verifique IPv4 e IPv6.
• Não reativar o Tailscale SSH, nem em emergências. A mudança na política de acesso que ele exige não pode ser revertida automaticamente.

O que aprendemos

1. Saiba o que um recurso de segurança realmente autentica antes de removê-lo. A chave indicada nos nossos scripts nunca tinha sido usada.
2. Teste exatamente o caminho para o qual você está migrando, no mesmo ambiente em que seus jobs rodam, antes de fazer a troca.
3. Prepare um rollback que não dependa daquilo que você está mudando. Um timer, não “depois a gente entra por SSH e conserta”.
4. Verifique o acesso de recuperação antes de fechar uma porta. Confirmamos o acesso ao console antes de fechar o SSH para a internet.
5. Atualize o runbook na mesma mudança. Um passo de recuperação antigo pode desfazer uma correção de segurança meses depois.
6. Leia as políticas padrão. “Permitir os próprios dispositivos, inclusive como root” era o padrão com que começamos.
7. Separe “a mudança funcionou” de “a vulnerabilidade foi resolvida”. Já não estamos expostos às descobertas do Tailscale SSH, mas o Tailworm como um todo só estará encerrado quando as correções upstream forem lançadas. Atualizaremos nossos clientes quando isso acontecer.
8. Meça e depois restrinja. O tráfego observado e uma lista de dependências reais vêm antes de regras de acesso mais rígidas, para que o reforço da segurança não prejudique o negócio.

Próximos passos

Estamos restringindo o acesso de rede entre dispositivos ao mínimo de que cada serviço precisa, com base no tráfego observado. Instalaremos as correções da Tailscale assim que forem lançadas.

Referências: o relatório Tailworm (tailworm.com) e a documentação da Tailscale sobre o Tailnet Lock.