Por que bloquear as portas de VPN não impede os túneis não autorizados

Uma regra de firewall nega o tráfego que ela abrange. Ela não nega todos os usos de uma conexão que permite, e é nessa lacuna que falham a maioria das políticas contra túneis não autorizados. Bloquear as portas do cliente que era popular há cinco anos deixa intacto tudo o que passa pela 443, e não diz nada sobre um dispositivo que consegue reescrever as suas próprias rotas. Construa o controlo em torno da autoridade e dos destinos, e depois leia os fluxos que realmente permite.

Por que uma lista de portas não é uma política

As portas são um conceito da camada de transporte, e várias tecnologias de túnel não usam nenhuma. Outras partilham deliberadamente uma porta com o tráfego web comum, porque essa porta é a que tem passagem garantida. Uma regra baseada numa porta histórica enumera, portanto, um punhado de implementações em vez da classe de comportamento. Também envelhece mal: no momento em que um fornecedor muda os valores predefinidos, a lista descreve o passado.

Pior ainda, um bloqueio bem-sucedido numa porta pode ser lido como prova de que todo o problema está resolvido, o que atrasa os controlos que teriam importado.

Números de protocolo e portas são espaços de nomes diferentes

A GRE é atribuído o número de protocolo IP 47. Não é a porta TCP 47 nem a porta UDP 47, e um filtro escrito para uma porta não o afeta. ESP e AH ocupam os números de protocolo 50 e 51 com a mesma propriedade. O tráfego encapsulado também se pode esconder dentro de uma conexão permitida, e é por isso que uma categoria ou assinatura pode ajudar, mas nunca certifica o propósito por si só. A confiança e a cobertura pertencem a um produto e a uma versão específicos, não ao conceito.

nft list ruleset | grep -nE 'gre|esp|ah|47|50|51'
cat /proc/net/protocols | head -20
ss -tn state established '( dport = :443 )'

O primeiro comando mostra o que realmente escreveu; o segundo mostra a tabela de protocolos que a pilha conhece; o terceiro mostra quantas sessões estão a usar a porta web neste momento. Nenhum deles diz para que servem essas sessões. A interceção de TLS é uma decisão separada, com os seus próprios custos de confiança, privacidade e compatibilidade com os clientes. Não é um pré-requisito para negar um destino nomeado, e também não é uma garantia de reconhecimento de túneis.

Controle a autoridade de que o dispositivo dispõe

Um dispositivo que pode alterar a sua própria tabela de encaminhamento e a sua filtragem tem capacidades que uma aplicação comum não tem. A gestão de admissão e de configuração é o que remove essa capacidade, e atua independentemente da porta que o túnel viesse a usar.

Isso significa que as ligações aprovadas recebem o seu papel declarado em vez de permissão ilimitada para reencaminhar por outros dispositivos, e significa que os direitos de instalação e de administração de rede fazem parte da política em vez de serem uma reflexão tardia.

Observe os fluxos que restam. Correlacione a identidade do dispositivo, o papel atribuído e os metadados do fluxo, e trate a classificação como evidência com limites em vez de veredicto.

conntrack -L | awk '{print $1, $4, $5}' | sort | uniq -c | sort -rn | head
ip -br addr show
ip route show default

Uma sessão cifrada de longa duração ou uma grande contagem de bytes não são prova de uso indevido: as cópias de segurança, as ferramentas de suporte e as ligações entre locais parecem iguais. Mantenha a recolha limitada à investigação e conserve o que encontrar sob o processo que é seu proprietário.

Torne as exceções explícitas

Cada ambiente tem destinos que devem permanecer acessíveis para atualizações, autenticação e recuperação. Anote-os com um propósito e um responsável, e reveja-os em vez de os descobrir uma falha de cada vez.

Quando o negócio permite genuinamente um serviço externo amplo, avalie a autoridade que esse serviço fornece em vez de assumir que o rótulo do destino torna qualquer uso aceitável.

Uma exceção não revista é um buraco com um número de ticket. Uma exceção com um nome, um motivo e uma data de revisão é uma decisão.

Aceite com um plano escrito, não com um slogan

A aceitação tem duas metades: o trabalho aprovado continua a ter sucesso e os casos proibidos específicos falham num teste autorizado. Ambas têm de ser escritas antes da alteração e repetidas depois.

Inclua as alterações de endpoint e de política nessa revisão, porque uma rota adicionada num portátil pode anular um filtro que funcionava perfeitamente na periferia.

O resultado é um limite de saída com proprietário e uma lista conhecida de risco remanescente. Afirmar que algumas portas fechadas puseram fim ao uso não autorizado de VPN não é isso.