Casos para usar ferramentas de análise de anomalias de rede: detecção de vazamentos

Em um dos eventos, houve uma discussão interessante sobre a utilidade das soluções da classe NTA (Network Traffic Analysis), que, usando a infraestrutura de rede de telemetria Netflow (ou outros protocolos de fluxo), possibilita detectar uma ampla variedade de ataques. Meus oponentes argumentaram que, ao analisar os cabeçalhos e informações relacionadas (e o NTA não analisa o corpo dos dados do pacote, diferentemente dos sistemas clássicos de detecção de ataques, IDS), você não pode ver muita coisa. Neste artigo, tentarei refutar essa opinião e tornar a conversa mais substantiva; darei alguns exemplos reais quando o NTA realmente ajudar a identificar várias anomalias e ameaças que estão faltando no perímetro ou mesmo além do perímetro. E começarei com a ameaça que veio em primeiro lugar na classificação de ameaças do ano passado e, acho, continuará sendo este ano.Será sobre vazamentos de informações e a capacidade de detectá-los via telemetria de rede.

Não considerarei a situação com as mãos tortas dos administradores que deixaram a Internet parecendo desprotegidos Elastic ou MongoDB. Vamos falar sobre as ações direcionadas dos atacantes, como foi o caso da aclamada história das agências de crédito Equifax. Deixe-me lembrá-lo de que, nesse caso, os invasores primeiro penetraram na vulnerabilidade não corrigida no portal da Web público e depois nos servidores de banco de dados internos. Permanecendo despercebido por vários meses, eles conseguiram roubar dados de 146 milhões de clientes de agências de crédito. Esse incidente poderia ser identificado usando soluções DLP? Provavelmente não, pois os DLPs clássicos não são adaptados à tarefa de monitorar o tráfego de bancos de dados usando protocolos específicos, e mesmo sob a condição de que esse tráfego seja criptografado.Mas a solução da classe NTA pode facilmente detectar esses vazamentos excedendo um certo valor limite da quantidade de informações baixadas do banco de dados. A seguir, mostrarei como tudo isso é configurado e descoberto usando a solução Cisco Stealthwatch Enterprise.

Portanto, a primeira coisa que precisamos fazer é entender onde nossos servidores de banco de dados estão localizados na rede, determinar seus endereços e agrupá-los. No Cisco Stealthwatch, a tarefa de inventário pode ser executada manualmente ou usando um classificador especial que analisa o tráfego e, de acordo com os protocolos usados ​​e o comportamento do nó, permite atribuí-lo a uma ou outra categoria.



Depois de termos informações sobre todos os servidores de banco de dados, iniciamos uma investigação para descobrir se estamos vazando grandes quantidades de dados do grupo de nós desejado. Vemos que, no nosso caso, os bancos de dados se comunicam mais ativamente com servidores DHCP e controladores de domínio.



Os invasores geralmente estabelecem controle sobre qualquer um dos nós da rede e o usam como ponte para desenvolver seu ataque. No nível do tráfego de rede, parece uma anomalia - a varredura em rede desse nó está se tornando mais frequente, os dados estão sendo capturados a partir do compartilhamento de arquivos ou da interação com qualquer servidor. Portanto, nossa próxima tarefa é entender com quem exatamente nossos bancos de dados costumam se comunicar.



No grupo de servidores DHCP, verifica-se que este é um nó com o endereço 10.201.0.15, interação com a qual responde por cerca de 50% de todo o tráfego dos servidores de banco de dados.



A próxima pergunta lógica que nos colocamos como parte da investigação é: “E como é esse nó como 10.201.0.15? Com quem ele está interagindo? Com que frequência? Quais protocolos? ”



Acontece que o nó de interesse para nós se comunica com vários segmentos e nós da nossa rede (o que não é surpreendente, pois é um servidor DHCP), mas a questão causa muita interação com o servidor de terminal com o endereço 10.201.0.23. Isso é normal? Existe claramente algum tipo de anomalia. Um servidor DHCP não pode se comunicar tão ativamente com um servidor de terminal - fluxos de 5610 e 23,5 GB de dados.



E essa interação é realizada através do NFS.



Damos o próximo passo e tentamos entender com quem nosso servidor de terminal interage? Acontece que ele tem uma comunicação bastante ativa com o mundo exterior - com nós nos EUA, Grã-Bretanha, Canadá, Dinamarca, Emirados Árabes Unidos, Catar, Suíça, etc.



A suspeita foi causada pelo fato da interação P2P com Porto Rico, responsável por 90% de todo o tráfego. Além disso, nosso servidor de terminal transmitiu mais de 17 GB de dados para Porto Rico através da 53ª porta, que está conectada ao protocolo DNS. Você pode imaginar que você tem esse volume de dados transmitidos via DNS? E lembro que, de acordo com a pesquisa da Cisco, 92% dos malwares usam DNS para ocultar sua atividade (baixar atualizações, receber comandos, descarregar dados).



E se o protocolo DNS da ITU não é apenas aberto, mas não inspecionado, temos um enorme buraco em nosso perímetro.



Assim que o nó 10.201.0.23 nos causou tais suspeitas, vamos ver com quem ele ainda está falando?



Nosso "suspeito" troca metade de todo o tráfego com o nó 10.201.3.18, que é colocado em um grupo de estações de trabalho de funcionários do departamento de vendas e marketing. Quão típicas são para a nossa organização o servidor de terminal "se comunicar" com o computador do vendedor ou comerciante?



Por isso, realizamos uma investigação e descobrimos a seguinte imagem. Os dados do servidor de banco de dados foram "derramados" em um servidor DHCP com sua subsequente transferência via NFS para um servidor de terminal dentro da nossa rede e, em seguida, para endereços externos em Porto Rico usando o protocolo DNS. Esta é uma violação clara das políticas de segurança. Ao mesmo tempo, o servidor de terminal também interagiu com uma das estações de trabalho na rede. O que causou esse incidente? Uma conta roubada? Dispositivo infectado? Nós não sabemos. Isso exigirá a continuação da investigação, baseada na solução da classe NTA, que permite analisar anomalias de tráfego na rede.



E agora estamos interessados ​​no que faremos com as violações identificadas da política de segurança? Você pode realizar análises regulares de acordo com o esquema acima, ou pode configurar a política NTA para que ela imediatamente sinalize quando violações semelhantes são detectadas. Isso é feito através do menu geral correspondente ou para cada conexão detectada durante a investigação.



Aqui está a aparência da regra de detecção de interação, cuja origem é o servidor de banco de dados e o destino são quaisquer nós externos e internos, exceto servidores Web.



Se um evento desse tipo for detectado, o sistema de análise de tráfego de rede gera imediatamente um sinal de alarme de correspondência e, dependendo das configurações, o envia para o SIEM, usando os meios de comunicação com o administrador, ou pode até bloquear automaticamente a violação detectada (o Cisco Stealthwatch faz isso interagindo com o Cisco ISE )



Lembre-se de que, quando mencionei o caso com o Equifax, mencionei que os atacantes usavam um canal criptografado para despejar dados. Para o DLP, esse tráfego se torna uma tarefa insolúvel, mas para as soluções da classe NTA, elas não o fazem - elas rastreiam qualquer tráfego em excesso ou interação não autorizada entre os nós, independentemente da criptografia.



Apenas um caso foi mostrado acima (nos seguintes materiais, consideraremos outros exemplos de uso do NTA para fins de segurança da informação), mas, de fato, as soluções modernas da classe Network Traffic Analysis permitem criar regras muito flexíveis e levar em conta não apenas os parâmetros básicos do cabeçalho do pacote IP:



mas também faça uma análise mais profunda, até associar o incidente ao nome de usuário do Active Directory, procurando arquivos maliciosos por hash (por exemplo, obtido como um indicador de comprometimento da SOSOPKA, FinCERT, Cisco Threat Grid, etc.), etc.



É fácil de implementar. Por exemplo, é assim que a regra usual procura detectar todos os tipos de interação entre servidores de banco de dados e nós externos usando qualquer protocolo nos últimos 30 dias. Vemos que nossos bancos de dados "se comunicaram" com nós externos ao segmento DBMS usando os protocolos DNS, SMB e porta 8088.



Além do formulário tabular para apresentação dos resultados de investigações ou pesquisas, também podemos visualizá-los. Para o nosso cenário, um fragmento do diagrama de fluxo da rede pode se parecer com o seguinte:



E, a partir do mesmo mapa, podemos gerenciar políticas - bloquear conexões ou automatizar o processo de criação de regras de monitoramento para os fluxos de interesse para nós.



Aqui está um exemplo bastante interessante e dinâmico do uso de ferramentas de monitoramento do Netflow (e outros protocolos de fluxo) para segurança cibernética. Nas notas a seguir, pretendo mostrar como você pode usar o NTA para detectar código malicioso (por exemplo, Shamoon), servidores maliciosos (por exemplo, a campanha de DNSpionage), programas de acesso remoto (RAT), ignorar proxies corporativos etc.

Source: https://habr.com/ru/post/undefined/