VPNs e firewalls costumam ser vistos apenas como mecanismos de proteção, afinal, são eles que controlam conexões, restringem acessos, filtram tráfego e ajudam a separar a infraestrutura interna da Internet. O problema é que essa visão pode criar uma falsa sensação de segurança, porque esses mesmos dispositivos também fazem parte da superfície de ataque.
Uma VPN precisa receber conexões externas, um firewall precisa processar tráfego vindo da Internet e um gateway precisa se comunicar com outras redes. Em muitos ambientes, esses equipamentos ainda expõem interfaces administrativas, serviços auxiliares e diferentes protocolos de gerenciamento, o que significa que aquilo que protege a infraestrutura também precisa ser protegido.
Dispositivos de borda também são ativos críticos
Firewalls, concentradores de VPN, roteadores e gateways ficam posicionados justamente na fronteira entre a rede interna e ambientes externos, desempenhando uma função estratégica para a segurança e a conectividade da organização. Essa posição, porém, também aumenta a exposição.
Esses equipamentos executam firmware, possuem interfaces web, protocolos de administração, mecanismos de autenticação e diversos serviços que podem apresentar vulnerabilidades ou configurações inadequadas. Por isso, tratar um firewall apenas como uma barreira de proteção cria um ponto cego: ele também precisa ser inventariado, atualizado, monitorado e analisado como qualquer outro ativo crítico.
O Think Ahead Report 2025, da SEK, chama atenção justamente para o interesse crescente de atacantes em dispositivos de borda, incluindo firewalls, VPNs, roteadores e gateways. O relatório destaca que esses ativos podem oferecer persistência e acesso privilegiado justamente por estarem diretamente conectados ao ambiente externo.
O atacante não precisa escolher sua empresa
Um dos pontos mais importantes quando se fala em exposição externa é entender que o atacante não precisa necessariamente escolher uma organização específica como alvo. Ele pode começar pela tecnologia.
Serviços públicos de indexação, mecanismos de busca de dispositivos conectados e ferramentas próprias de varredura permitem localizar equipamentos acessíveis pela Internet em larga escala. A busca pode ser feita por uma determinada família de firewall, uma interface de VPN, uma porta específica ou até por características presentes em uma resposta HTTP.
Isso muda bastante a lógica do risco, porque uma empresa pode entrar no radar simplesmente porque um ativo seu respondeu a uma varredura. Para um processo automatizado, o tamanho da organização importa pouco; o que realmente importa é aquilo que está exposto e pode ser identificado.
Seu firewall pode revelar mais do que parece
Um serviço acessível externamente frequentemente fornece informações antes mesmo de qualquer tentativa de exploração. Uma conexão pode retornar um banner indicando qual software está em execução, uma página administrativa pode apresentar características que identificam o fabricante e um certificado TLS pode revelar nomes de host ou subdomínios associados à organização.
Até mesmo cabeçalhos HTTP podem fornecer pistas sobre as tecnologias em uso. Esse processo é conhecido como fingerprinting e tem como objetivo criar uma espécie de impressão digital do ativo.
Ao combinar endereço IP, portas abertas, certificados, respostas dos serviços e comportamento da aplicação, é possível inferir o que existe naquele endereço e responder perguntas importantes, como qual produto parece estar rodando, se existe uma interface administrativa exposta, qual protocolo está disponível e se a tecnologia aparenta estar desatualizada.
É por isso que exposição não deve ser analisada apenas pela existência de uma vulnerabilidade conhecida. Antes mesmo de explorar alguma falha, o atacante pode obter contexto suficiente para decidir qual caminho seguir.
A pergunta que vem antes do patch
Quando uma vulnerabilidade crítica é divulgada em uma solução de VPN ou firewall, a reação natural é procurar imediatamente pela correção. Isso é importante, mas existe uma pergunta que deveria vir antes: a empresa utiliza essa tecnologia?
A partir daí, outras perguntas precisam ser respondidas: em quais ativos ela está presente, quais versões estão em uso e quais desses dispositivos estão expostos à Internet?
Essas questões parecem simples, mas nem sempre são fáceis de responder. Ambientes mudam ao longo do tempo, equipamentos são substituídos, projetos são encerrados, novos serviços são publicados e algumas soluções temporárias acabam permanecendo ativas por muito mais tempo do que deveriam.
Com isso, surgem ativos esquecidos. Uma empresa pode ter substituído seu firewall principal, mas mantido outro equipamento em uma filial; pode existir uma VPN criada para um fornecedor ou um appliance antigo ligado a um projeto que já perdeu importância. O risco está justamente naquilo que continua existindo sem receber o mesmo nível de atenção.
O ativo esquecido continua visível
Para a empresa, um equipamento pode ter deixado de ser relevante, mas para a Internet ele continua existindo enquanto estiver respondendo e acessível.
Uma interface administrativa antiga não desaparece porque ninguém mais a utiliza, uma VPN de um projeto encerrado não deixa de ser encontrada porque saiu da rotina e um roteador legado não fica invisível apenas porque deveria ter sido substituído.
Esses ativos costumam concentrar alguns dos piores cenários: menor frequência de atualização, pouca clareza sobre responsabilidade e quase nenhuma revisão de exposição. Para o atacante, porém, nada disso importa. Se o ativo está acessível, ele pode ser identificado, analisado e testado.
VPN não é sinônimo de segurança
VPN é uma tecnologia importante para proteger conexões remotas e permitir acesso controlado a recursos internos, mas a existência de uma VPN não significa que o acesso esteja automaticamente seguro.
É possível utilizar autenticação forte e, ao mesmo tempo, executar uma versão vulnerável do serviço. Também é possível adotar MFA e ainda manter uma interface administrativa desnecessariamente exposta.
Existe ainda outra categoria de risco que merece atenção: vulnerabilidades exploráveis antes da autenticação. Nesses casos, usuário e senha deixam de ser a primeira barreira, porque o problema está no próprio componente responsável por receber a conexão.
Isso muda bastante o modelo de segurança, já que uma senha complexa ou autenticação multifator não impedem a exploração de uma falha que ocorre antes do processo de login. Por isso, segurança de VPN não pode ser resumida a credenciais; versão, firmware, exposição, configuração e comportamento do serviço também precisam fazer parte da análise.
O patch pode existir e o risco continuar
Dispositivos de borda apresentam outro desafio importante: atualização nem sempre é simples. Em uma estação de trabalho, muitas correções podem ser aplicadas automaticamente, enquanto em um firewall que mantém uma operação funcionando a situação costuma ser diferente.
Uma atualização pode exigir reinicialização, janela de manutenção, validação de compatibilidade, backup da configuração e até um plano de retorno caso algo dê errado. Isso cria um conflito operacional, porque a equipe sabe que precisa atualizar, mas também sabe que uma intervenção mal planejada pode causar indisponibilidade.
O resultado, muitas vezes, é o adiamento, e cada dia de atraso mantém aberta uma janela entre a publicação da correção e sua aplicação efetiva.
Nessa situação, inventário e contexto de exposição fazem diferença. Um equipamento vulnerável e isolado internamente pode ter uma prioridade diferente de outro que recebe conexões diretamente da Internet.
O risco não está apenas na CVE
É comum associar vulnerabilidade apenas à existência de uma CVE, mas nem toda exposição depende de uma falha crítica conhecida.
Um equipamento totalmente atualizado ainda pode apresentar risco se sua interface administrativa estiver aberta para qualquer origem. Um serviço antigo pode continuar habilitado sem necessidade, uma porta pode permanecer pública porque nunca foi revista e protocolos de gerenciamento podem aceitar conexões de redes muito mais amplas do que deveriam.
Nada disso exige uma nova vulnerabilidade publicada. Às vezes, o problema está simplesmente na forma como o ativo foi exposto.
Por isso, uma análise de exposição precisa ir além da pergunta “existe uma CVE?” e considerar também o que alguém consegue alcançar a partir da Internet, quais serviços estão acessíveis e se aquela exposição realmente faz sentido.
Interface administrativa pública merece atenção
Imagine um firewall atualizado e sem vulnerabilidades críticas conhecidas. Aparentemente, tudo está certo, mas esse cenário muda se a interface de gerenciamento estiver acessível publicamente.
Mesmo sem uma falha crítica conhecida, o serviço pode ser identificado, receber tentativas automatizadas de autenticação, participar de processos de reconhecimento e fornecer informações úteis para mapear a tecnologia utilizada.
Em muitos casos, a organização não precisa manter essa interface disponível para toda a Internet. É possível restringi-la a endereços específicos, redes administrativas ou outros mecanismos controlados de acesso.
Essa é uma diferença importante entre serviço necessário e exposição necessária. Um serviço pode precisar existir sem precisar estar acessível para qualquer origem.
Quanto menos exposição desnecessária, melhor
Redução de superfície de ataque não significa simplesmente fechar portas sem critério; significa questionar o motivo de cada exposição.
Vale entender por que determinada interface está pública, quem realmente precisa acessá-la, de onde esse acesso deve acontecer, se o protocolo ainda é necessário e se existe uma forma mais restrita de administração.
Uma VPN destinada a usuários externos provavelmente precisará responder publicamente, enquanto uma interface administrativa do equipamento, muitas vezes, não precisa.
Essa distinção é fundamental porque, em vários casos, uma melhoria relevante de segurança não depende da compra de uma nova ferramenta, mas apenas da remoção de algo da Internet que nunca precisou estar exposto.
A borda também pode ser usada para persistência
Outro risco importante está na persistência. Endpoints costumam receber atenção constante de ferramentas de detecção, como antimalware, EDR e políticas específicas de endpoint, enquanto em equipamentos de rede essa cobertura pode ser diferente.
Um firewall comprometido pode ter regras alteradas, novos usuários administrativos podem ser criados, chaves de acesso podem ser adicionadas e logs podem ser reduzidos ou desabilitados. O invasor também pode tentar utilizar essa posição como ponte para outros sistemas.
A borda, portanto, não deve ser vista apenas como o lugar por onde o ataque entra; ela também pode se tornar o lugar onde o atacante tenta permanecer.
O Think Ahead Report chama atenção justamente para esse tipo de comprometimento persistente e difícil de detectar em dispositivos de borda.
Os logs também precisam sair do firewall
Se um atacante obtiver privilégios administrativos sobre um equipamento e todos os registros relevantes estiverem armazenados apenas naquele próprio dispositivo, surge outro problema: o invasor pode tentar alterar ou eliminar evidências.
Por isso, a centralização de logs faz diferença. Eventos relacionados a autenticação administrativa, alterações de configuração, criação de usuários, mudanças em regras e reinicializações podem ser enviados para outro local, reduzindo a dependência dos registros mantidos no equipamento comprometido.
Isso também melhora a correlação. Um login administrativo realizado fora do horário habitual, seguido pela criação de uma regra incomum e por um aumento inesperado de tráfego, passa a contar uma história muito mais clara quando os eventos são observados em conjunto.
Monitorar só notebooks e servidores deixa uma lacuna
Uma organização pode ter boa visibilidade dos endpoints e, ao mesmo tempo, pouca informação sobre sua borda, criando uma assimetria perigosa.
Firewalls, VPNs e roteadores conseguem registrar tentativas de autenticação, acessos administrativos, alterações de política, mudanças em certificados, atualizações e outros eventos de rede que podem ser extremamente valiosos durante uma investigação.
Esses registros também ajudam a identificar situações que talvez não gerem um alerta tradicional de malware, como a criação de um novo administrador sem solicitação, uma alteração de configuração fora da janela prevista, a desativação do logging ou uma interface de gerenciamento que passou a aceitar conexões externas.
Descoberta externa e inventário interno precisam conversar
Uma empresa pode possuir um bom inventário interno e ainda assim não saber exatamente como seus ativos aparecem para a Internet. O contrário também acontece: uma varredura externa pode identificar diversos serviços, mas, sem contexto interno, é difícil saber quem é responsável por cada um ou por que estão publicados.
É quando essas duas visões se encontram que o cenário começa a ficar realmente útil.
O inventário informa o que deveria existir, enquanto a visão externa mostra aquilo que efetivamente pode ser visto. Quando os dois não coincidem, existe algo que precisa ser entendido.
Pode ser apenas um ativo legítimo ainda não documentado, um serviço antigo, um subdomínio esquecido ou uma exposição que não deveria existir. Em qualquer um desses casos, a diferença merece investigação.
Saber o que está exposto muda a resposta
Considere a divulgação de uma vulnerabilidade crítica em determinada família de firewalls.
Em uma organização sem visibilidade, começa uma investigação interna: alguém procura planilhas, outra pessoa verifica equipamentos, a equipe tenta descobrir quem utiliza aquela tecnologia, confirma versões e só depois identifica quais ativos estão acessíveis externamente.
Enquanto isso, a vulnerabilidade já é pública.
Em um ambiente com inventário e acompanhamento de exposição, a resposta pode ser muito mais rápida, porque a organização consegue identificar se a tecnologia existe, quais ativos a utilizam, quais versões estão presentes, quais dispositivos estão expostos e qual deles deve ser tratado primeiro.
Essa diferença não é apenas administrativa; é uma diferença no tempo de resposta, e tempo importa muito quando uma vulnerabilidade começa a ser explorada.
Gestão de vulnerabilidades começa pela descoberta
Não é possível avaliar aquilo que não se conhece, e esse princípio explica boa parte dos problemas envolvendo ativos externos.
Antes de discutir criticidade ou prazo de correção, é necessário saber onde o ativo está e, antes disso, saber que ele existe.
Por esse motivo, descoberta de ativos e gestão de vulnerabilidades não deveriam funcionar como processos separados. Um domínio pode levar a um subdomínio, o subdomínio pode apontar para um endereço IP, esse endereço pode apresentar um serviço, o serviço pode revelar uma tecnologia e essa tecnologia pode estar associada a uma vulnerabilidade.
É essa sequência que transforma uma simples lista de falhas em contexto real.
A borda também faz parte da superfície de ataque
Quando se fala em superfície de ataque, é comum pensar em aplicações web, APIs, servidores e endpoints, mas VPNs, firewalls, roteadores e gateways também precisam fazer parte do mesmo mapa.
Eles podem estar expostos, possuir tecnologias identificáveis, apresentar vulnerabilidades, conter configurações inadequadas e fornecer acesso privilegiado a outras partes do ambiente.
A diferença é que esses equipamentos foram criados para proteger, e talvez justamente por isso seja tão fácil esquecer que também precisam ser protegidos.
VPNs e firewalls continuam sendo componentes fundamentais da segurança corporativa, mas não são barreiras invisíveis ou imunes a ataques. São ativos conectados, executam software, possuem versões, recebem atualizações, expõem serviços e geram logs.
O risco aumenta quando a organização perde visibilidade sobre esses dispositivos. Um firewall esquecido, uma VPN antiga ou uma interface administrativa publicada sem necessidade podem permanecer disponíveis por muito mais tempo do que deveriam.
Por isso, a proteção da borda começa antes da correção de uma vulnerabilidade. Começa sabendo o que existe, entendendo o que está acessível e avaliando o que realmente precisa continuar exposto.
No fim, a pergunta que dá título a este artigo resume exatamente o ponto central:
VPN e firewall: você sabe o que está exposto?
