Leia sobre dicas e funcionalidades da GoCache CDN para melhorar a seguranca do seu site, loja virtual ou app mobile.

Uma solução de Segurança da Informação e Gestão de Eventos (SIEM) é fundamental para manter a segurança da rede de uma organização, monitorando diversos tipos de dados. Os registros de log são essenciais, pois registram todas as atividades nos dispositivos e aplicativos em toda a rede. Para avaliar adequadamente a postura de segurança de uma rede, as soluções SIEM devem coletar e analisar diversos tipos de dados de log. Além disso, é importante ressaltar que os diferentes tipos de logs fornecem uma visão abrangente dos diferentes componentes da infraestrutura da organização. Os formatos dos logs também variam de acordo com a ferramenta de SIEM utilizada, o que requer uma compreensão detalhada das diferentes plataformas disponíveis para uma implementação eficaz da SIEM.

Este artigo explora os diferentes tipos de dados de log que você deve coletar e analisar usando uma solução SIEM para garantir a segurança da rede.

Tipos de dados de log:

Diferentes tipos de logs são gerados por uma variedade de dispositivos e aplicativos, cada um fornecendo informações valiosas sobre a saúde e segurança da rede. Neste contexto, exploraremos os principais tipos de logs, desde dispositivos de perímetro até dispositivos IoT, destacando a importância de cada um e como eles contribuem para a compreensão e proteção da infraestrutura de rede de uma organização.

1. Logs de dispositivos de perímetro

Os dispositivos de perímetro monitoram e regulam o tráfego de e para a rede. Firewalls, redes privadas virtuais (VPNs), sistemas de detecção de intrusões (IDSs) e sistemas de prevenção de intrusões (IPSs) são alguns dos dispositivos de perímetro. Esses dispositivos geram logs contendo uma grande quantidade de dados, e os logs de dispositivos de perímetro são vitais para entender os eventos de segurança que ocorrem na rede. Os dados de log no formato syslog ajudam os administradores de TI a realizar auditorias de segurança, solucionar problemas operacionais e entender melhor o tráfego que passa pela rede corporativa.

2. Logs de eventos do Windows

Os logs de eventos do Windows registram tudo o que acontece em um sistema Windows. Esses dados de log são classificados em:

– Logs de aplicativos do Windows

– Logs de segurança

– Logs do sistema

– Logs de serviços de diretório

– Logs do servidor DNS

– Logs do serviço de replicação de arquivos

3. Logs de endpoints

Os endpoints são dispositivos conectados à rede que se comunicam com outros dispositivos por meio de servidores. Alguns exemplos incluem desktops, laptops, smartphones e impressoras.

4. Logs de aplicativos

As empresas executam vários aplicativos, como bancos de dados, servidores web e outros aplicativos internos, para realizar funções específicas. Todos esses aplicativos geram log data que fornece insights sobre o que está acontecendo dentro dos aplicativos.

5. Logs de proxy

Os servidores proxy desempenham um papel importante na rede de uma organização, fornecendo privacidade, regulando o acesso e economizando largura de banda. Como todas as solicitações e respostas da web passam pelo servidor proxy, os logs do proxy podem revelar informações valiosas sobre estatísticas de uso e o comportamento de navegação dos usuários finais.

6. Logs de IoT

A Internet das Coisas (IoT) refere-se a uma rede de dispositivos físicos que trocam dados com outros dispositivos na Internet. Esses dispositivos são incorporados com sensores, processadores e software para permitir a coleta, processamento e transmissão de dados. Assim como os endpoints, os dispositivos que compõem um sistema IoT geram logs.

Os logs de todas as fontes acima geralmente são encaminhados para a solução de log centralizada que correlaciona e analisa os dados para fornecer uma visão geral da segurança de sua rede. Os logs são armazenados e transmitidos em diferentes formatos, como CSV, JSON, par de chaves e formato de evento comum.

Formatos de log diferentes: 

Existem diversos formatos de log, como por exemplo CSV (Comma-Separated Values), JSON (JavaScript Object Notation), Syslog, entre outros. É necessário entender que cada formato possui características específicas que o tornam adequado para diferentes tipos de análises e aplicativos. Neste contexto, exploraremos a importância e as características de cada formato de log, destacando como eles contribuem para o gerenciamento eficaz de logs em ambientes de rede.

CSV (Comma-Separated Values): O CSV é um formato de arquivo que armazena valores separados por vírgula. É um formato de arquivo de texto simples, o que permite que os arquivos CSV sejam facilmente importados para um banco de dados de armazenamento, independentemente do software usado. Como os arquivos CSV não são hierárquicos ou orientados a objetos, também são mais fáceis de converter em outros tipos de arquivos.

JSON (JavaScript Object Notation): O JSON é um formato de texto para armazenar dados. É um formato estruturado, o que facilita a análise dos logs armazenados. Também pode ser consultado por campos específicos. Esses recursos adicionais tornam o JSON um formato muito confiável para o gerenciamento de logs.

Par de Chaves (Key-Value Pair): Um par de chaves consiste em dois elementos: uma chave e um valor mapeado para ela. A chave é constante e o valor é variável em diferentes entradas. A formatação envolve a agrupamento de conjuntos semelhantes de dados sob uma chave comum. Ao executar a consulta para uma chave específica, todos os dados sob essa chave podem ser extraídos.

Formato de Evento Comum (Common Event Format – CEF): O Formato de Evento Comum, comumente referido como CEF, é um formato de gerenciamento de logs que promove a interoperabilidade tornando mais fácil coletar e armazenar dados de log de diferentes dispositivos e aplicativos. Ele usa o formato de mensagem syslog. Este formato de log é amplamente utilizado, é suportado por uma variedade de fornecedores e plataformas de software, e consiste em um cabeçalho CEF e uma extensão CEF que contém dados de log em pares de chave-valor.

ETFL (Extended Tag Format Log): O ETFL é um formato de log que estende o formato de log tradicional, como o syslog, adicionando informações adicionais e estruturadas aos registros de log. Ele é projetado para fornecer informações mais detalhadas e contextuais sobre eventos de segurança, permitindo uma análise mais profunda e eficaz. O ETFL é especialmente útil em ambientes de segurança cibernética, onde a compreensão completa de um evento é crucial para a resposta adequada a incidentes.

Syslog: O syslog é um protocolo padrão usado para enviar mensagens de log em uma rede IP. Ele é comumente usado para registrar eventos do sistema e de segurança em dispositivos de rede, servidores e aplicativos. O syslog também é usado como um formato de log, onde as mensagens são estruturadas em diferentes níveis de gravidade (como informações, avisos, erros e críticos) e contêm informações sobre o tempo, o dispositivo de origem e o conteúdo da mensagem. O syslog é altamente flexível e pode ser configurado para enviar mensagens para um servidor de log centralizado, facilitando a análise e o gerenciamento centralizado de logs em uma rede.

Coletar manualmente esses logs de todas as diferentes fontes em uma rede e correlacioná-los é um processo tedioso e demorado. Uma solução SIEM pode ajudá-lo com isso. Uma solução SIEM analisa os logs coletados de diferentes fontes, correlaciona os dados de log e fornece insights para ajudar as organizações a detectar e se recuperar de ciberataques.

Packet Capture (PCAP): Arquivos de captura de pacotes, comumente criados por ferramentas como Wireshark, contêm dados brutos de tráfego de rede capturados de uma interface de rede. Embora não seja estritamente um formato de log, os arquivos PCAP são frequentemente usados para análise de segurança de rede e investigações forenses.

Ransomware é um malware que emprega criptografia para manter as informações da vítima sob resgate. Os dados críticos de um usuário ou organização são criptografados para que eles não possam acessar arquivos, bancos de dados ou aplicativos.

Um resgate é então exigido para fornecer acesso. O ransomware geralmente é projetado para se espalhar por uma rede e ter como alvo bancos de dados e servidores de arquivos, podendo assim paralisar rapidamente uma organização inteira. É uma ameaça crescente, gerando milhares de milhões de dólares em pagamentos a cibercriminosos e infligindo danos e despesas significativas a empresas e organizações governamentais.

Segundo o relatório da “IBM Security X-Force Threat Intelligence Index 2023”, os ataques de ransomware representaram 17% de todos os ataques cibernéticos em 2022.

Além disso, o relatório indica que nos últimos anos, os ataques de ransomware evoluíram para incluir ataques de extorsão dupla e de extorsão tripla, o que aumenta consideravelmente os riscos. Mesmo as vítimas que mantêm rigorosamente backups de dados ou pagam o pedido de resgate inicial estão em risco. Os ataques de dupla extorsão acrescentam a ameaça de roubar os dados da vítima e vazá-los online. Além disso, os ataques de extorsão tripla ameaçam usar os dados roubados para atacar os clientes ou parceiros de negócios da vítima.

Um pouco sobre a história do Ransomware

Chantagear e extorquir desta forma as empresas não é uma invenção do século XXI. No final da década de 1980, os criminosos já mantinham arquivos criptografados como reféns em troca de dinheiro enviado pelos correios. Um dos primeiros ataques de ransomware já documentados foi o trojan AIDS (PC Cyborg Virus), lançado em disquete em 1989. As vítimas precisavam enviar US$189 para uma caixa postal no Panamá para restaurar o acesso aos seus sistemas, mesmo sendo um vírus simples que utiliza criptografia simétrica. 

Os primeiros casos concretos de ransomware foram relatados na Rússia em 2005. Desde então, o ransomware se espalhou por todo o mundo, com novos tipos continuando a ter sucesso. Em 2011, foi observado um aumento dramático nos ataques de ransomware. No decorrer de novos ataques, os fabricantes de software antivírus têm concentrado cada vez mais os seus antivírus em ransomware, especialmente desde 2016.

Muitas vezes, diferenças regionais podem ser vistas nos vários ataques de ransomware. Por exemplo:

• Mensagens incorretas sobre aplicativos não licenciados: Em alguns países, os Trojans notificam a vítima de que software não licenciado está instalado no seu computador. A mensagem então solicita que o usuário efetue um pagamento.

• Alegações falsas sobre conteúdo ilegal: Em países onde os downloads ilegais de software são uma prática comum, esta abordagem não é particularmente bem-sucedida para os cibercriminosos. Em vez disso, as mensagens de ransomware afirmam ser provenientes de agências de aplicação da lei e que pornografia infantil ou outro conteúdo ilegal foi encontrado no computador da vítima. A mensagem também contém a exigência do pagamento de uma multa.

E na prática, como funciona o ataque de Ransomware? 

Em média, o ciclo de vida do ransomware tem seis estágios gerais: distribuição e infecção de malware; comando e controle; descoberta e movimento lateral; roubo malicioso e criptografia de arquivos; extorsão; e resolução.

Estágio 1: Distribuição e infecção de malware

Antes que os invasores possam exigir um resgate, eles devem se infiltrar nos sistemas das vítimas e infectá-las com malware. Os vetores de ataque de ransomware mais comuns são phishing, Remote Desktop Protocol (RDP) e abuso de credenciais, além de vulnerabilidades de software exploráveis:

• Phishing: Este é o tipo mais popular de engenharia social e continua a ser o principal vetor de ataque para todos os tipos de malware. Os invasores associam e-mails aparentemente legítimos a links e anexos maliciosos para induzir os usuários a instalar malware involuntariamente. Ataques de smishing, vishing, spear phishing e watering hole são formas de phishing e golpes de engenharia social que os invasores usam para enganar as pessoas e fazê-las iniciar a instalação de malware.

• RDP e abuso de credenciais: Envolve o uso de ataques de força bruta ou de preenchimento de credenciais ou a compra de credenciais na dark web, com o objetivo de fazer login nos sistemas como usuários legítimos e, em seguida, infectar a rede com malware. O RDP, um dos favoritos dos invasores, é um protocolo que permite aos administradores acessar servidores e desktops de praticamente qualquer lugar e permite que os usuários acessem remotamente seus desktops. Implementações de RDP inadequadamente protegidas, no entanto, são um ponto de entrada comum de ransomware.

• Vulnerabilidades de software: Eles também são alvos frequentes de infecções por ransomware. Os invasores se infiltram nos sistemas da vítima atacando software sem correção ou desatualizado. Um dos maiores incidentes de ransomware da história, o WannaCry, está ligado à exploração EternalBlue, uma vulnerabilidade em versões não corrigidas do protocolo Windows Server Message Block (SMB).

Etapa 2: Comando e controle

Um servidor de comando e controle (C&C) configurado e operado pelos invasores do ransomware envia chaves de criptografia ao sistema alvo, instala malware adicional e facilita outros estágios do ciclo de vida do ransomware.

Etapa 3: Descoberta e movimento lateral

Esta fase de duas etapas envolve primeiro que os invasores coletem informações sobre a rede da vítima para ajudá-los a entender melhor como lançar um ataque bem-sucedido e, em seguida, espalhem a infecção para outros dispositivos e aumentem seus privilégios de acesso para buscar dados valiosos.

Estágio 4: Roubo malicioso e criptografia de arquivos

Nesse estágio, os invasores exfiltram dados para o servidor C&C para uso em ataques de extorsão no futuro. Os invasores então criptografam os dados e sistemas usando as chaves enviadas de seu servidor C&C.

Etapa 5: Extorsão

Os invasores exigem o pagamento de um resgate. A organização agora sabe que é vítima de um ataque de ransomware.

Etapa 6: Resolução

A organização vítima deve entrar em ação para enfrentar e recuperar do ataque. Isto pode envolver a restauração de backups, a implementação de um plano de recuperação de ransomware, o pagamento do resgate, a negociação com os invasores ou a reconstrução de sistemas do zero.

E como posso me proteger contra Ransomware?

Para se defenderem contra ameaças de ransomware, agências federais como CISA, NCIJFT e o Serviço Secreto dos EUA recomendam que as organizações tomem certas medidas de precaução, tais como:

• Manter backups de dados confidenciais e imagens do sistema, de preferência em discos rígidos ou outros dispositivos que possam ser desconectados da rede.

• Aplicar patches regularmente para ajudar a impedir ataques de ransomware que exploram vulnerabilidades de software e sistema operacional.

• Atualização de ferramentas de segurança cibernética, incluindo software antimalware e antivírus, firewalls, ferramentas de monitoramento de rede e gateways web seguros. Além disso, usando soluções corporativas de segurança cibernética, como orquestração, automação e resposta de segurança (SOAR), detecção e resposta de endpoint (EDR), gerenciamento de informações e eventos de segurança (SIEM) e detecção e resposta estendida (XDR). Essas soluções ajudam as equipes de segurança a detectar e responder a ransomware em tempo real.

• Treinamento de funcionários em segurança cibernética para ajudar os usuários a reconhecer e evitar phishing, engenharia social e outras táticas que podem levar a infecções por ransomware.

• Implementação de políticas de controle de acesso, incluindo autenticação multifatorial, arquitetura de confiança zero, segmentação de rede e medidas semelhantes. Essas medidas podem impedir que o ransomware atinja dados particularmente confidenciais e evitar que os criptoworms se espalhem para outros dispositivos na rede.

Muitas organizações implementam um firewall de aplicação web (WAF) para atender a requisitos de conformidade, mas para a maioria, o principal motivo para implementar um WAF é proteger servidores e aplicações web contra exploração por meio de vulnerabilidades de aplicação. Deve-se levar em consideração que a maioria das aplicações possui vulnerabilidades. Em um estudo recente, a equipe Trustwave identificou pelo menos uma vulnerabilidade em 100% das aplicações que investigaram. E a maioria tinha mais de uma.

Você pode se perguntar “por que não corrigir as vulnerabilidades e dispensar o WAF?” Embora haja uma tendência de incorporar o desenvolvimento seguro no início do processo de desenvolvimento de aplicações, o nível de expertise em segurança dentro das equipes de desenvolvimento varia amplamente. Práticas de desenvolvimento também podem introduzir vulnerabilidades. Além disso, é fundamental levar em consideração que aplicações legadas são alvos fáceis de atacantes, e muitas vezes os times de desenvolvimento evitam realizar alterações pela falta de confiança em corrigir algo em nível de segurança e prejudicar o funcionamento da aplicação.

Vulnerabilidades podem passar despercebidas em novas aplicações, à medida que os desenvolvedores são pressionados a entregar aplicações mais rapidamente do que nunca. O uso de componentes de código aberto e/ou código de terceiros pode levar a bugs e falhas desconhecidos se tornando parte das aplicações. No futuro previsível, organizações que desenvolvem aplicações devem esperar que essas aplicações tenham vulnerabilidades.

Por esse motivo, um WAF é uma ferramenta necessária para proteger servidores e aplicações web contra ataques. Como qualquer ferramenta de segurança, um WAF precisa ser implementado e gerenciado de forma eficaz para fornecer valor sustentável.

Melhores práticas de implementação do WAF

Quanto mais tempo você dedicar ao planejamento da implementação do seu WAF, mais eficaz será sua implementação ao longo do tempo. Trabalhe nessas melhores práticas antes e durante a implementação.

Documente sua tolerância a riscos de segurança web:

A tolerância ao risco da sua organização deve impactar como você configura suas políticas de WAF. Por exemplo, se sua organização é uma grande operação de comércio eletrônico, você pode ter uma tolerância alta para riscos. Você não quer que nenhum tráfego legítimo seja bloqueado, pois a receita que você obtém do seu negócio de comércio eletrônico supera o risco de ser atacado com sucesso. Por outro lado, se você suporta uma instituição financeira, sua tolerância ao risco pode ser muito baixa. Você está disposto a permitir que alguma atividade de usuário legítimo seja bloqueada como uma troca para evitar um ataque e a má publicidade que poderia vir com ele.

Documente aplicações e proprietários:

Diferentes aplicações servem a propósitos diferentes, então a tolerância ao risco geral da sua organização pode não se aplicar a cada aplicação. Fale com cada proprietário sobre que proteção sua aplicação requer. Ter o conhecimento sobre as aplicações e seu propósito ajudará você, como profissional de segurança, a apoiar seu negócio, em vez de impedi-lo. Também ajudará você a identificar rapidamente os proprietários se algo der errado.

Sua organização pode querer aplicar uma única política de segurança para todas as aplicações, ou você pode estar aberto a definir políticas diferentes para diferentes aplicações, conforme fizer sentido. 

Entender as aplicações também pode ajudar a definir políticas de WAF. 

• Implemente políticas de WAF que façam sentido para suas aplicações. Seu fornecedor de WAF provavelmente fornecerá um conjunto abrangente de políticas para uma variedade de aplicações e tecnologias. Dedique tempo para ajustar essas políticas. Por exemplo, se seu site é desenvolvido em um CMS conhecido, aplique as melhores práticas conhecidas. Isso economizará tempo na revisão de eventos, reduzirá a complexidade e os falsos positivos. Também economizará recursos de computação ao reduzir a carga no seu WAF e melhorará a responsividade do ponto de vista da latência.

• Se você conhece os serviços que estarão por trás do WAF, estenda as políticas do WAF para incluir todos eles (ou faça com que algum tráfego do serviço ignore o WAF). Frequentemente vemos implementações de WAF que procuram tráfego HTTP, mas ignoram o tráfego de aplicativos proveniente de aplicativos iOS ou Android.

• Você pode configurar a maioria dos WAFs para bloquear ou ignorar o tráfego usando métodos de conexão não utilizados por suas aplicações. Digamos que suas aplicações usem GET, POST e HEAD, mas não OPTIONS, PROPFIND ou PUT. Bloqueie aqueles que não são usados para evitar tráfego indesejado. Isso também protegerá sua aplicação para que métodos usados no desenvolvimento não sejam enviados para produção por engano.

Identifique o que você deve restringir e o que deve permitir

A implementação é um bom momento para identificar coisas básicas que você deseja restringir e permitir através do seu WAF. Restrições geográficas são um começo fácil. Se sua empresa opera em geografias específicas, restrinja o acesso aos portais de RH apenas aos países onde você tem funcionários. Isso reduzirá a carga no seu WAF e servidores web. Atacantes ao redor do mundo estão constantemente escaneando vulnerabilidades em sites para explorar. Restringir geografias onde você não opera pode reduzir a carga nos seus servidores web.

Da mesma forma, mas do ponto de vista de whitelist, configure seu WAF para permitir tráfego confiável. Um exemplo é permitir que seu scanner de vulnerabilidades interaja completamente com as aplicações web de back-end e não seja bloqueado pelo WAF. Fazendo isso, você poderá identificar vulnerabilidades em aplicações web que estão atualmente mitigadas pelo WAF. Do ponto de vista da varredura de aplicações, você obterá maior visibilidade e identificará vulnerabilidades que podem ser bons candidatos para os desenvolvedores abordarem em futuras versões.

Escolha uma solução de WAF aderente ao seu cenário 

Os WAFs têm diferentes modos de operação. Existem modos em linha, como proxy reverso e ponte transparente, onde o WAF fica entre as solicitações web e os servidores web. Um WAF em linha pode ter muito controle sobre as solicitações web, como bloquear e/ou mascarar o tráfego que não atende às políticas (tanto de entrada quanto de saída). Há também o modo fora de linha (às vezes chamado de modo fora de banda), onde o WAF investiga uma cópia do tráfego web. Nesse modo, a capacidade do WAF de bloquear o tráfego é limitada. Ele só pode enviar pacotes TCP-reset para interromper o tráfego, o que significa que algum tráfego malicioso pode chegar ao seu servidor web antes que o TCP-reset aconteça.

Como prática recomendada, escolha um modo em linha. Do ponto de vista de segurança, o risco com um WAF fora de linha de que o tráfego malicioso alcance seu servidor web e uma resposta bem-sucedida aos atacantes é muito grande. É melhor implantar um WAF em modo em linha de uma forma que atenda aos seus requisitos de segurança e aplicação do que assumir esse risco. Também há um problema em poder registrar o tráfego. Um WAF fora de linha não será capaz de descriptografar o tráfego Diffie-Hellman, que é o método de criptografia mais comum em uso hoje. Então, além do risco de segurança aumentado, você ficará cego para grande parte do seu tráfego web.

Crie uma conta para seus desenvolvedores 

Os desenvolvedores de aplicações podem se beneficiar das informações provenientes do WAF, então faz sentido configurar uma conta (ou contas) para eles. Embora um WAF seja, em primeiro lugar, um controle de segurança, a maioria dos WAFs fornece informações valiosas sobre o desempenho da aplicação. Essas informações incluem coisas como alertas de alteração da aplicação, métricas de desempenho, identificação de dados sensíveis e links quebrados.

Alguns mensagens de erro do WAF também serão de interesse para os desenvolvedores. O tráfego que parece malicioso é frequentemente criado por usuários não maliciosos que interagem com aplicações de formas que o desenvolvedor não antecipou. Mensagens de erro do WAF que contenham detalhes como configurações padrão do WAF ou listagens de diretórios de pastas e arquivos podem indicar problemas na aplicação que precisam ser resolvidos.

Na GoCache, oferecemos nossa solução de WAF que pode te ajudar a proteger seus sites e aplicações contra ataques que podem comprometer a integridade de dados sensíveis e privados. Nossos recursos são personalizados, permitindo que você adapte o nosso WAF para as regras de negócio de sua aplicação. E claro, se você precisar de ajuda e quiser que nosso time crie e monitore políticas de WAF para suas aplicações, recomendamos nossos serviços do GoCache Managed Security, onde nossa equipe realiza a monitoração contínua de seus serviços. 

Antes de bloquear, comece com o “simular”. 

A maioria dos WAFs oferecem opções para monitorar e/ou bloquear o tráfego de aplicações web, bem como, também possuem opções para gerar logs, sem necessariamente tomar ações. Escolha as opções de monitoramento e bloqueio que melhor suportam sua tolerância ao risco. Por exemplo, a instituição financeira que citamos no início do artigo poderia:

• Configurar seu WAF para bloquear o tráfego para todas as aplicações web.
• Configurar regras personalizadas, como o tempo que um visitante tem acesso ao seu site após completar um desafio-resposta como um teste CAPTCHA.
• Apresentar páginas de erro instrutivas, para que se um usuário legítimo for bloqueado, ele verá informações sobre outras formas de se envolver com o negócio.
• Configurar o WAF para gerar logs de eventos, e após coletar uma boa amostragem, decidir quais tipos de ação são mais compatíveis em cada situação. 
• Integrar sua aplicação com SIEM para analisar melhor os falsos positivos, e depois de ter tratado tudo, utilizar opções de desafiar, que é um modo mais leve, e depois, sem ocorrências de reclamações, alterar as regras para bloqueio.

DNSSEC é uma implementação segura do sistema DNS onipresente que garante integridade e confiança ao assinar todos os registros DNS com chaves de segurança para criar assinaturas criptográficas. Essas assinaturas são armazenadas junto com os registros DNS tradicionais (MX, A, AAAA, CNAME, etc.), e ao verificar a assinatura, garante que os registros retornados pelo servidor DNS venham do servidor de nomes autorizado para a zona determinada. 

Os sistemas DNS tradicionais são vulneráveis tanto a ataques man-in-the-middle, onde os registros DNS são alterados no caminho para o usuário, quanto a ataques de envenenamento de DNS, onde o resolvedor DNS local (provavelmente seu computador) recebe uma enxurrada de resoluções DNS ruins. que dizem ao resolvedor local para resolver um determinado domínio para o site do invasor, em vez do legítimo. 

Como um DNS funciona? 

Para entender as Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC), é útil ter um conhecimento básico do Sistema de Nomes de Domínio (DNS).

O bom funcionamento da Internet depende criticamente do DNS. Cada página da web visitada, cada e-mail enviado, cada imagem recuperada de uma mídia social: todas essas interações usam o DNS para traduzir nomes de domínio amigáveis (como gocache.com.br) para endereços IP (como 198.0.33.7 e 2001: 500:88:300::7) necessários a servidores, roteadores e outros dispositivos de rede para rotear o tráfego pela Internet até o destino adequado.

Usar a Internet em qualquer dispositivo começa com o DNS. Por exemplo, considere quando um usuário digita o nome de um site em um navegador de seu telefone. O navegador usa o resolvedor stub, que faz parte do sistema operacional do dispositivo, para iniciar o processo de tradução do nome de domínio do site em um endereço de protocolo da Internet (IP). Um resolvedor stub é um cliente DNS muito simples que retransmite a solicitação de dados DNS de um aplicativo para um cliente DNS mais complicado chamado resolvedor recursivo. Muitos operadores de rede executam resolvedores recursivos para lidar com solicitações ou consultas de DNS enviadas por dispositivos em sua rede. (Operadores e organizações menores às vezes usam resolvedores recursivos em outras redes, incluindo resolvedores recursivos operados como um serviço para o público, como Google Public DNS, OpenDNS e Quad9.)

O resolvedor recursivo rastreia ou resolve a resposta à consulta DNS enviada pelo resolvedor stub. Este processo de resolução exige que o resolvedor recursivo envie suas próprias consultas DNS, geralmente para vários servidores de nomes autoritativos diferentes. Os dados DNS de cada nome de domínio são armazenados em um servidor de nomes oficial em algum lugar da Internet. Os dados DNS de um domínio são chamados de zona. Algumas organizações operam seus próprios servidores de nomes para publicar suas zonas, mas geralmente as organizações terceirizam essa função para terceiros. Existem diferentes tipos de organizações que hospedam zonas DNS em nome de terceiros, incluindo registradores, registros, empresas de hospedagem na web, provedores de servidores de rede, apenas para citar alguns.

Mas o DNS não por si só não é seguro?

O DNS foi projetado na década de 1980, quando a Internet era muito menor e a segurança não era uma consideração primordial em seu design. Como resultado, quando um resolvedor recursivo envia uma consulta a um servidor de nomes autoritativo, o resolvedor não tem como verificar a autenticidade da resposta. O resolvedor só pode verificar se uma resposta parece vir do mesmo endereço IP para onde o resolvedor enviou a consulta original. Mas confiar no endereço IP de origem de uma resposta não é um mecanismo de autenticação forte, uma vez que o endereço IP de origem de um pacote de resposta DNS pode ser facilmente falsificado ou falsificado. 

Como o DNS foi originalmente projetado, um resolvedor não consegue detectar facilmente uma resposta forjada a uma de suas consultas. Um invasor pode facilmente se disfarçar como o servidor autoritativo que um resolvedor consultou originalmente, falsificando uma resposta que parece vir desse servidor autoritativo. Em outras palavras, um invasor pode redirecionar um usuário para um site potencialmente malicioso sem que o usuário perceba.

Os resolvedores recursivos armazenam em cache os dados DNS que recebem de servidores de nomes autorizados para acelerar o processo de resolução. Se um resolvedor “stub” solicitar dados DNS que o resolvedor recursivo possui em seu cache, o resolvedor recursivo poderá responder imediatamente, sem o atraso introduzido pela primeira consulta a um ou mais servidores autorizados. No entanto, essa dependência do cache tem uma desvantagem: se um invasor enviar uma resposta DNS forjada que seja aceita por um resolvedor recursivo, o invasor envenenará o cache do resolvedor recursivo. O resolvedor irá então retornar os dados DNS fraudulentos para outros dispositivos que os consultam.

Como exemplo da ameaça representada por um ataque de envenenamento de cache, considere o que acontece quando um usuário visita o site do seu banco. O dispositivo do usuário consulta seu servidor de nomes recursivo configurado para obter o endereço IP do site do banco. Mas um invasor poderia ter envenenado o resolvedor com um endereço IP que apontasse não para o site legítimo, mas para um site criado pelo invasor. Este site fraudulento se faz passar pelo site do banco e tem a mesma aparência. O usuário desconhecido digitaria seu nome e senha, como de costume. Infelizmente, o usuário forneceu inadvertidamente suas credenciais bancárias ao invasor, que poderia então fazer login como esse usuário no site legítimo do banco para transferir fundos ou realizar outras ações não autorizadas.

Então usar um sistema de DNSSEC é fundamental? 

Os engenheiros da Internet Engineering Task Force (IETF), a organização responsável pelos padrões do protocolo DNS, perceberam há muito tempo que a falta de uma autenticação mais forte no DNS era um problema. O trabalho em uma solução começou na década de 1990 e o resultado foram as Extensões de Segurança DNSSEC.

DNSSEC fortalece a autenticação no DNS usando assinaturas digitais baseadas em criptografia de chave pública. Com o DNSSEC, não são as consultas e respostas DNS em si que são assinadas criptograficamente, mas sim os próprios dados DNS são assinados pelo proprietário dos dados.

Cada zona DNS possui um par de chaves pública/privada. O proprietário da zona usa a chave privada da zona para assinar dados DNS nesta zona, assim gerando assinaturas digitais sobre esses dados. Como o nome “chave privada” indica, esse material de chave é mantido em segredo pelo proprietário da zona. 

A chave pública da zona, entretanto, é publicada na própria zona para que qualquer pessoa possa recuperá-la. Qualquer resolvedor recursivo que procure dados na zona também recupera a chave pública da zona, que usa para validar a autenticidade dos dados DNS. O resolvedor confirma que a assinatura digital dos dados DNS recuperados é válida. Nesse caso, os dados DNS são legítimos e são devolvidos ao usuário. Se a assinatura não for validada, o resolvedor assume um ataque, descarta os dados e retorna um erro ao usuário.

DNSSEC adiciona dois recursos importantes ao protocolo DNS:

• A autenticação da origem dos dados permite que um resolvedor verifique criptograficamente se os dados recebidos realmente vieram da zona onde acredita que os dados foram originados.

• A proteção da integridade dos dados permite que o resolvedor saiba que os dados não foram modificados em trânsito desde que foram originalmente assinados pelo proprietário da zona com a chave privada da zona.

E quais são os principais ataques que o DNSSEC mitiga?

Entre os principais ataques mitigados pelo DNSSEC, podemos destacar: 

DNS Cache Poisoning

O envenenamento do cache DNS (dns poisoning) ocorre quando um agente de ameaça alimenta informações falsas no cache DNS, fazendo com que o navegador do usuário retorne uma resposta incorreta.

Essa resposta geralmente redireciona os usuários para um site diferente daquele que pretendiam visualizar. Quando isso acontecer, um worm, spyware, programa de sequestro de navegador da Web ou outro tipo de malware poderá ser baixado para o computador do usuário a partir de um local não autorizado.

Os resolvedores de DNS não podem verificar os dados armazenados em seus caches, o que significa que as informações incorretas permanecem no cache até que o TTL expire ou até que o problema seja resolvido manualmente. Embora o envenenamento de cache não desconecte o site real de seu endereço IP real, se as informações incorretas permanecerem no cache DNS, os usuários continuarão a ser direcionados ao site não autorizado, o que pode levar a maiores comprometimentos.

DNS Hijacking

O sequestro de servidor de nomes de domínio (DNS) Hijacking, também chamado de redirecionamento de DNS, é um tipo de ataque de DNS no qual as consultas de DNS são resolvidas incorretamente para redirecionar inesperadamente os usuários para sites maliciosos. Para realizar o ataque, os perpetradores instalam malware nos computadores dos usuários, assumem o controle dos roteadores ou interceptam ou hackeiam a comunicação DNS.

O sequestro de DNS pode ser usado para pharming (nesse contexto, os invasores normalmente exibem anúncios indesejados para gerar receita) ou para phishing (exibindo versões falsas de sites acessados pelos usuários e roubando dados ou credenciais).

Muitos provedores de serviços de Internet (ISPs) também usam um tipo de sequestro de DNS para assumir as solicitações de DNS de um usuário, coletar estatísticas e retornar anúncios quando os usuários acessam um domínio desconhecido. Alguns governos usam o sequestro de DNS para censura, redirecionando os usuários para sites autorizados pelo governo.

E como posso usar o recurso de DNSSEC em minhas aplicações web? 

Como vimos neste artigo, quando se trata de implementar o DNSSEC, é fácil subestimar sua complexidade. Ainda mais se pensarmos em uma estrutura DNS centralizada e automatizada. 

No mínimo, a implementação manual requer manutenção de registros e substituição de chaves (atualização periódica das chaves para reduzir as chances de comprometimento).

Na GoCache é possível utilizar os recursos nativos de DNSSEC em nossa plataforma, permitindo que suas aplicações tenham toda a segurança de DDSSEC, sem esforços de implementação e manutenção. 

Para utilizar o DNSSEC em seu domínio na GoCache é necessário fazer a configuração tanto no Painel da GoCache, quanto no registro, onde o seu domínio foi comprado. Trata-se de uma configuração extremamente simples e que é feita em poucas etapas. 

Caso queira saber um pouco mais sobre implementação de DNSSEC na GoCache, leia nossa documentação sobre o tema. 

Desde os primórdios da internet, existem dois tipos de usuários heavy users que gostam de Cyber Security: aqueles que gostam de provocar incidentes e aqueles que protegem aplicações contra incidentes. 

É claro que, com a evolução dos mecanismos de defesa, aqueles que buscam vulnerabilidades passaram a utilizar recursos cada vez mais tecnológicos, e que podem provocar danos severos. Mas, é fundamental entender que por muitas vezes as ferramentas de ataque podem ser utilizadas incorretamente, e ainda mais, podem ser distribuídas para outros atacantes com erros, gerando bizarrices. 

Ano passado, algumas variações de user-agent contendo “Mozlila” foram identificadas pelo nosso time de cibersegurança. Algo que nos chamou atenção foi a similaridade com o nome “Mozilla”,  amplamente utilizado na internet, constantemente identificado como legítimo por quem administra aplicações web. 

E como descobrimos esse user-agent? 

Um dos analistas de Cyber Security do time da GoCache notou que um cliente específico recebia acessos do user-agent contendo a palavra “Mozlila”, e no início parecia se tratar apenas de um erro pontual de digitação por parte de algum atacante. 

Investigando mais a fundo, notou-se que havia uma quantidade constante de acessos vindo deste user-agent, e boa parte proveniente da Europa e Ásia.

Vamos dar uma olhada nos números? 

Dados da rede da GoCache sobre a requisição do “Mozlila”

Além do volume de requisições, nosso time também buscou entender a origem desse user-agent. Descobrimos que mais de ¼ desses acessos vieram de Singapura. Confira abaixo a distribuição dos acessos por geocalização. 

Dados da rede da GoCache sobre geolocalização do “Mozlila”

Mas afinal, o que é esse tal de “Mozlila” buscava fazer? 

Após análise das URLs de acesso, foi possível identificar que o alvo específico desse user-agent eram aplicações em WordPress. Basicamente, ele tenta encontrar vulnerabilidades no CMS, bem como, oportunidades em backdoors e variáveis de ambiente. 

Atualmente, este caso do “Mozlila” já é amplamente conhecido, e é bloqueado por padrão em sistemas de segurança mais atualizados. 

A Trunc montou um artigo bem interessante sobre o assunto, mostrando passo a passo como eles identificaram a origem dos ataques, e como descobriram que tratava-se na verdade de um suposto erro de digitação banal. Caso queira ler o artigo da Trunc, basta clicar aqui. 

Sim, o user-agent suspeito “Mozlila” que fez nosso time de segurança realizar uma investigação a fundo no ano passado era aparentemente um erro de copiar e colar do script de um atacante, que foi replicado em várias ferramentas e scanners, e o resultado final foi a introdução de um novo agente de usuário no ecossistema de quem lida com segurança web.

O que devo fazer para me proteger?

Para se proteger, você tem algumas soluções à disposição. A primeira seria bloquear esse user-agent em seu servidor web, fazendo com que sempre que esse user-agent for detectado, ele seja interceptado antes de se transformar em uma requisição legítima.

Além disso, é possível adicionar regras no firewall para esse tipo de user-agent, opção mais simples e rápida para aqueles que já têm contratado este recurso.

Como a GoCache ajuda?

Clientes da GoCache têm, via de regra, um firewall de borda que permite que o cliente crie regras para bloquear acessos provenientes de algum user-agents. 

É necessário levar em consideração que diferentes user-agents e bots são criados diariamente, tornando cada vez mais complexo o dia a dia de quem gerencia aplicações web.

Para casos mais avançados,  recomendamos que nossos clientes utilizem o nosso Bot Mitigation , que identifica e bloqueia automaticamente diferentes bots, sem a necessidade de criar regras para cada caso.