Antecedentes: Como líder mundial em importação e exportação, a Vandalay Industries tem sido alvo de muitos adversários que tentam perturbar os seus negócios online. Recentemente, Vandaly tem sofrido ataques DDOS contra seus servidores web.
Não apenas os servidores web foram colocados offline por um ataque DDOS, mas a velocidade de upload e download também foi significativamente afetada após a interrupção. Sua equipe de rede forneceu resultados de uma velocidade de rede executada na época do último ataque DDOS.
Arquivo de teste de velocidade
Captura de tela do arquivo 'server_speedtest.csv' carregado no Splunk:
eval , crie um campo chamado ratio que mostra a relação entre as velocidades de upload e download. Dica: O formato para criar uma proporção é: | eval new_field_name = 'fieldA' / 'fieldB'
Consulta usada no Splunk para gerar uma relação entre velocidades de upload e download - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS
Podemos ver a proporção de downloads e uploads desta consulta.
_timeIP_ADDRESSDOWNLOAD_MEGABITSUPLOAD_MEGABITSratioDica: Use o seguinte formato para o comando de tabela: | tabela campoA campoB campoC
Consulta usada no Splunk para gerar uma relação entre velocidades de upload e download - source="server_speedtest.csv" | eval ratio = DOWNLOAD_MEGABITS/UPLOAD_MEGABITS | table _time, IP_ADDRESS, DOWNLOAD_MEGABITS, UPLOAD_MEGABITS, ratio
Na captura de tela acima, podemos ver o cronograma total do evento de quando os downloads e uploads ocorreram.
Na captura de tela acima, podemos ver o horário em que ocorreram os downloads e uploads, bem como o endereço IP de origem que estava realizando essa ação.
Na captura de tela acima, podemos ver uma representação visual desses eventos de download e upload em formato de gráfico de coluna. A hora é exibida na parte inferior e isso torna nossos dados muito mais legíveis.
Com base em nossas descobertas nas consultas acima, podemos ver que a velocidade de download e upload caiu drasticamente aproximadamente às 14h30 do dia 23 de fevereiro. Podemos ver isso na imagem abaixo:
Podemos ver que os downloads caíram para 7,87 às 14h30. Esta é uma queda drástica em relação aos 109,16 megabits do evento anterior. É justo presumir que isso ocorreu quando o ataque começou.
Podemos ver na imagem acima que os megabits baixados aumentaram de 17,56 para 65,34, o que é um aumento drástico. Portanto, é seguro presumir que isso ocorreu quando o sistema começou a se recuperar e voltar ao fluxo normal de tráfego de rede.
Podemos ver na captura de tela acima que os megabits baixados saltaram de 78,34 para 123,91 aproximadamente às 23h30 do dia 23 de fevereiro. É seguro assumir que este é o momento em que o fluxo de tráfego da rede se estabilizou e voltou ao normal.
Envie uma captura de tela do seu relatório e a resposta às perguntas acima.
Contexto: Devido à frequência dos ataques, seu gerente precisa ter certeza de que os dados confidenciais dos clientes em seus servidores não estão vulneráveis. Como Vandalay usa scanners de vulnerabilidade Nessus, você realizou verificações nas últimas 24 horas para ver se há alguma vulnerabilidade crítica.
Para obter mais informações sobre o Nessus, leia o seguinte link: https://www.tenable.com/products/nessus
Resultados da verificação do Nessus
Captura de tela dos resultados da verificação do nessus carregados no Splunk:
10.11.36.23 . Use dest_ip="10.11.36.23" na consulta
Vale a pena notar que existem 5 tipos de níveis de severidade que esses logs procuram, conforme mostrado abaixo:
Queremos filtrar quaisquer vulnerabilidades em que o nível de gravidade seja um valor 'crítico'. Podemos usar severity="crtiical" em nossa consulta.
A consulta inteira é source="nessus_logs.csv" dest_ip="10.11.36.23" severity="critical"
Veja a captura de tela abaixo para toda a consulta que exibe a contagem de vulnerabilidades críticas do servidor de banco de dados do cliente a partir deste arquivo de log:
Foram encontradas um total de 49 vulnerabilidades críticas quando o IP de destino era 10.11.36.23 (que é o servidor de banco de dados).
[email protected] .Crie o alerta clicando em 'salvar como' e depois em 'alerta' depois de gerarmos nossos resultados da consulta acima:
Insira detalhes para gerar alertas sempre que o Nessus detectar uma vulnerabilidade no servidor de banco de dados. Insira o nome, a descrição e quaisquer outras informações relativas:
Insira os dados do e-mail para enviar o alerta gerado para - [email protected] e insira os dados da mensagem a ser enviada com o e-mail:
Continue inserindo os detalhes do alerta e clique em 'salvar':
Uma vez salvo, poderemos ver o alerta e editar se desejarmos:
Envie uma captura de tela do seu relatório e uma captura de tela comprovando que o alerta foi criado.
Histórico: Um servidor Vandalay também está enfrentando ataques de força bruta em sua conta de administrador. A gerência gostaria que você configurasse o monitoramento para notificar a equipe SOC se um ataque de força bruta ocorrer novamente.
Logins de administrador
Captura de tela do arquivo 'Administrator_logs.csv' carregado no Splunk:
Dicas:
Procure o campo de nome para encontrar logins com falha.
Observe que o ataque durou várias horas.
Como queremos procurar quaisquer indicadores de um ataque de força bruta, queremos detalhar os logs em que as contas falharam ao fazer logon. Se navegarmos até o campo 'nome' podemos ver os valores que ele contém nos logs. Nesse caso, podemos ver uma contagem de 1004 “Falha ao fazer logon na conta”. Este é um bom indicador de que ocorreu um ataque de força bruta. Veja a captura de tela:
Agora, se adicionarmos isto à nossa pesquisa, poderemos ver o total de eventos de quando isto ocorreu. Podemos então ver quando ocorreu a maioria destes eventos, o que é um bom indicador de quando isso ocorreu. Veja a captura de tela:
Como podemos ver, há um grande aumento nos eventos em que “Uma conta falhou ao fazer logon” por volta das 9h do dia 21 de fevereiro. Podemos ver do total de 1.004 eventos ocorridos, às 9h houve 124 desses eventos com números semelhantes aparecendo nas horas seguintes. Assim, acredito que o ataque começou por volta desta hora - 9h do dia 21 de fevereiro de 2020.
Podemos ver na linha do tempo desses eventos que 124 é um grande aumento. Nas horas que antecederam este evento, o maior número de maus logins rondava os 23. Podemos considerar este comportamento normal. Veja a captura de tela:
Com isso em mente e levando em conta que houve cerca de 124-135 tentativas de logon quando ocorreu o ataque de força bruta, eu consideraria uma linha de base de cerca de 40 logons incorretos por hora. Eu teria os intervalos para logons incorretos por hora da seguinte forma:
[email protected] se acionado.Para criar um alerta para esse tipo de evento, segui os seguintes passos:
Clique em 'salvar como' e depois em 'alerta':
Preencha os detalhes do alerta, incluindo quando acioná-lo (acima de 25 tentativas por hora):
Insira detalhes de uma ação. Neste caso enviaremos um email para [email protected] :
Salve o alerta e poderemos visualizá-lo:
Agora criamos com sucesso um alerta que será acionado quando houver mais de 25 eventos de falha no login de uma conta.
Envie as respostas às perguntas sobre o tempo de força bruta, linha de base e limite. Além disso, forneça uma captura de tela como prova de que o alerta foi criado.
