A filtragem de DNS (Domain Name System) apresenta algumas diferenças em comparação com a filtragem de conteúdo web. Para DNS, se analisa o domínio, sendo uma proteção de tempo de resposta relativamente rápido, porém, sem muita precisão, pois o bloqueio ocorre no domínio inteiro, provocando um efeito “tudo ou nada”. Já para conteúdo web, analisamos a URL e, dessa forma, conseguimos ser mais precisos ou granular, pois dentro de um domínio é possível separa serviços em subdomínios ou até pastas, cobrando um tempo de resposta maior, pois geralmente é necessária a inspeção SSL/TLS. Sua utilidade é voltada não só para segurança, mas também produtividade. Neste projeto, utilizamos o recurso de proteção de DNS de uma solução SASE (Secure Access Service Edge), que monitora o tráfego de uma filial, no modo inline, conforme topologia a seguir. Antes de testar a proteção, verificamos como ocorre a sequência de pacotes a um típico website legítimo: Verificamos que inicialmente o client faz a consulta DNS para o site cookpad, ao IP 10.254.254.1, que é o servidor DNS da solução SASE. Ele será sempre consultado (para fins de DNS), independente do roteador e/ou a placa de rede estarem apontados para outro servidor DNS, público ou privado. Isso ocorre porque a solução SASE atua também como um serviço DNS integrado à sua nuvem, que automaticamente intercepta, inspeciona e resolve consultas DNS, garantindo segurança e acesso aos recursos internos. Posterior a isso, como o site é legítimo, o conteúdo HTTP (HyperText Transfer Protocol) é entregue. Agora vamos ao 1º teste de proteção DNS: Ao tentarmos acessar o site hsdps.cc, o servidor DNS SASE decide não resolver o domínio e devolve uma resposta “no such name” à consulta DNS e uma mensagem “ERR_NAME_NOT_RESOLVED” no navegador. O que aconteceu, neste caso, foi que a nuvem SASE, ao verificar que o domínio em questão está atrelado a uma assinatura conhecida (cis_dns_feed_malware_vt_domain), já efetuou o bloqueio na etapa de consulta de DNS. Tal assinatura, inclusive, reconhece que acesso ao website traria o risco da tática Command & Control, do MITRE Attack. Como a contenção é feita ainda na fase de consulta DNS, o tráfego ocorre apenas entre filial e nuvem SASE, e sua direção é denominada WANBOUND. Por isso, não houve identificação de nenhum pacote diferente de UDP/DNS. Para o 2º caso, foi testado o site foreignabnormality.com, o qual, casou, no mecanismo de proteção de DNS, com a regra “Phishing”. Como a solução está configurada para a ação Sinkhole à tal regra, foi exatamente isso que ocorreu. Ao analisarmos a captura de pacotes, vemos que, a resposta à consulta DNS, dessa vez, aponta para o IP 10.254.254.107, conforme o pacote nº 2587. Este IP corresponde justamente ao IP Sinkhole, ou também conhecido como “blackhole”. E este é motivo pelo qual, após o website ser resolvido para tal IP, há uma enorme taxa de retransmissão. Inclusive, no primeiro pacote dessa natureza (nº 2611) , é verificada a flag TCP “This frame is a (suspected) retransmission”, comportamento típico de quando realmente o Sinkhole entra em ação. O client tem a expectativa de se conectar ao site real, mas recebe um IP “falso” no seu lugar. O tal IP “falso” é programado para não responder com o conteúdo, ou simplesmente descartar o tráfego, provocando o client a tentar a retransmissão sucessivas vezes. Usamos normalmente Sinkhole para podermos analisar ameaças desconhecidas ou furtivas. Assim se ganha mais visibilidade, expondo o IP interno do client que seria a origem do comprometimento. Mesmo após o casamento da regra de Phishing, ocasionando efeito de Sinkhole, a regra Malicious Domains é ativada, porém gerando uma ação de “Block”. Primeiramente o Sinkhole já provoca o navegador para que informe de um mensagem do tipo “ERR_CONNECTION_TIMED_OUT”.