Oi, habrozhiteli! Um aplicativo em execução na nuvem tem muitas vantagens, mas ao mesmo tempo está sujeito a ameaças especiais. A tarefa das equipes de DevOps é avaliar esses riscos e fortalecer a proteção do sistema contra eles. O livro é baseado na experiência única do autor e oferece as soluções estratégicas mais importantes para proteger aplicativos da Web contra ataques, para impedir tentativas de invasão. Você verá como garantir a confiabilidade com testes automatizados, entrega contínua e principais processos de DevOps. Aprenda a identificar, avaliar e corrigir vulnerabilidades existentes no seu aplicativo. O autor o ajudará a navegar nas configurações da nuvem, bem como a aplicar ferramentas de automação populares. Requer conhecimento do Linux e conhecimento das práticas padrão do DevOps, como CI, CD e teste de unidade.
Trecho. Capítulo 8. Análise de Log para Detecção de Intrusão e Ataque
Neste capítulo:
- Explorando componentes no nível da análise em um pipeline de log.
- Detecte intrusões e ataques usando assinaturas de string, estatísticas e dados históricos.
- Gerenciando a melhor maneira de notificar os usuários.
No Capítulo 7, você aprendeu como criar um pipeline de log que coleta, transfere, analisa e armazena logs de toda a infraestrutura e também fornece acesso a eles. Um pipeline de vários níveis cria uma infraestrutura flexível na qual os logs de várias fontes são usados para monitorar a atividade dos serviços da organização. O Capítulo 7 forneceu uma visão geral da funcionalidade fornecida por todos os níveis do pipeline. Neste capítulo, focaremos no terceiro nível - o nível de análise - e abordaremos técnicas e exemplos de códigos relacionados à detecção de invasões e ataques a serviços.
O pipeline de registro usado pelo Mozilla ao escrever o livro é semelhante ao mostrado no capítulo 7. O pipeline é usado para monitorar o estado dos clientes Firefox (chamados
telemetria ) em um ambiente natural, processar logs de aplicativos e serviços e detectar atividades incomuns. O centro lógico do pipeline está no nível da análise, composto por muitos pequenos programas que procuram constantemente algo incomum. Esses pequenos programas não são tão avançados a ponto de lidar com a entrada e saída de eventos de log; portanto, transferem essa tarefa para um data center dedicado - o programa Hindsight (http://mng.bz/m4gg), projetado para executar o trabalho de analisar plug-ins em fluxos de dados .
Neste capítulo, usaremos o Hindsight para ler vários tipos de revistas e escrever plugins originais para analisá-los.
NOTA
Os logs e plugins de amostra deste capítulo estão localizados em securing-devops.com/ch08/logging-pipeline . Você precisa copiar este repositório para sua máquina local e obter o contêiner do Hindsight Docker para executar os exemplos.
Vamos começar descrevendo como as várias partes do nível de análise são organizadas: a retrospectiva está localizada no meio e os níveis de coleta e armazenamento estão nos dois lados. Depois, falaremos sobre três abordagens diferentes para detectar invasões e ataques. Para os mais simples deles, são usadas assinaturas de cadeias que contêm informações sobre ataques conhecidos para enviar notificações. Em seguida, comparamos os modelos estatísticos e a abordagem com as assinaturas e também aprendemos como essas duas abordagens se complementam. Por fim, vamos dar uma olhada em maneiras de aplicar dados históricos da atividade do usuário para identificar áreas suspeitas entre conexões.
A última seção do capítulo é sobre o envio de notificações. É improvável que você deseje receber milhares de notificações do nível de análise todos os dias, o que criará muito ruído, em vez de ser útil. Se isso não for alterado, os destinatários considerarão as notificações como spam e as ignorarão. Na seção final deste capítulo, examinaremos as práticas recomendadas para enviar notificações e discutiremos maneiras de enviar notificações com precisão e eficiência aos administradores e usuários finais.
8.2 Detectando ataques usando assinaturas de string
Ao trabalhar com logs, você trabalha com seqüências de caracteres. E isso significa que a maneira mais fácil de identificar sinais de fraude é comparar os logs com uma lista de linhas maliciosas conhecidas. Pode parecer simples, mas foi justamente nesses anos que o setor de segurança estava envolvido. Os firewalls de aplicativos da Web (WAFs), tão populares em meados dos anos 2000, eram essencialmente um repositório de expressões regulares, que eram verificadas em relação a todas as solicitações enviadas a um aplicativo da Web.
Não confie em expressões regulares
Certa vez, trabalhei em um banco no qual esse tipo de proteção era amplamente utilizado. A equipe de segurança era responsável pelo suporte ao WAF, que protegia uma variedade de serviços online, incluindo um serviço de negociação para clientes. Cada solicitação da Web enviada para este serviço passou por centenas de expressões regulares antes de chegar ao servidor de aplicativos. Uma vez que um desenvolvedor de uma equipe de serviços de negociação online decidiu dar uma olhada nessas expressões regulares. Não sei o que levou o engenheiro a começar a ler o conteúdo do arquivo, que é principalmente preenchido com barras, símbolos de dólar, asteriscos, vantagens, quadrados e parênteses, mas ele aceitou. E em algum lugar da linha 418 em uma expressão regular complexa, ele encontrou uma combinação suspeita de ". +". Dois personagens inocentes que permitiam que absolutamente tudo continuasse sem dor: essa expressão regular é semelhante ao valor "permitir tudo".
Nosso orgulho é o firewall do aplicativo Web por vários milhares de euros, apoiado por uma equipe inteira, que realizou centenas de verificações de expressões regulares, afetando o desempenho e complicando o design de um sistema já complexo, e tudo para pular tudo sem impedimentos. Obviamente, logo resolvemos o problema, mas minha crença no uso de expressões regulares para garantir a segurança não aumentou desde então. Se você deseja implementar esse tipo de sistema de proteção em sua organização, leve em consideração a complexidade para que isso não aconteça com você.
Quando usadas corretamente, as expressões regulares podem se tornar uma ferramenta poderosa, mas são incrivelmente difíceis de escrever, manter ao longo do tempo - ainda mais difíceis, e sua implementação em larga escala é cara. Dê uma olhada na expressão regular ((\% 3C) | <) ((\% 2F) | \ /) * [a-z0-9 \%] + ((\% 3E) |>). Você não vai adivinhar para que é usado, por isso vou lhe dizer: ele pode ser usado para procurar injeções nas sequências de solicitação HTTP, revelando a presença de abertura e fechamento de caracteres de desigualdade <> e seu conteúdo. Você receberá esse tipo de linha de solicitação HTTP de um invasor que está tentando injetar código JavaScript malicioso no seu aplicativo para acabar com um ataque de script entre sites, que discutimos no Capítulo 3.
Essa expressão regular pode ser usada para identificar solicitações suspeitas que contêm tentativas de injeção. A Listagem 8.7 mostra um analisador de exemplo que implementa isso, verificando correspondências de expressão regular em cada um dos logs de acesso NGINX transmitidos. A expressão regular é armazenada na variável local xss, seu valor é comparado com cada valor de Fields [request] usando a função rex.match ().
Se houver correspondências, a função add_to_payload () envia uma notificação de que o plug-in de saída pode receber e transmitir para o destino.
Listagem 8.7. Um plug-in que detecta mensagens de log contendo sinais de ataque na sequência de consultas
Um exemplo de saída desse plug-in é mostrado na Listagem 8.8. Existem várias notificações geradas por amostras de revistas, algumas das quais se revelaram falso-positivas. Isso aconteceu em parte porque os logs de amostra foram criados artificialmente usando o ZAP Vulnerability Scanner e também porque as cadeias de consulta não tendem a conter tags HTML. Em particular, essa expressão regular não terá uma taxa muito alta para encontrar correspondências falsas positivas.
Listagem 8.8. Exemplos de notificações geradas pelo plug-in de análise XSS
Esta é apenas uma expressão regular para um tipo específico de ataque. Para que essa abordagem seja útil, você precisa encontrar algo mais que expressões regulares. Para iniciantes, você pode coletar assinaturas de várias fontes e, à medida que mais e mais sinais suspeitos são encontrados nos logs, aumente gradualmente o tamanho do seu banco de dados.
A Listagem 8.9 mostra uma versão modificada do analisador XSS que procura vários sinais de um ataque (http://mng.bz/62h8). Este script mostra como você pode usar as tabelas Lua para armazenar uma lista de atributos e usá-lo ciclicamente para analisar os eventos recebidos. Neste exemplo de código, a tabela suspicious_terms é uma linha simples de linhas que usa substrings para procurar expressões regulares, o que é muito mais rápido. A tabela suspicious_terms usa o formato de valor-chave para armazenar rótulos junto com a expressão para poder lembrá-lo de que a expressão deve ser encontrada.
Listagem 8.9. Procure sinais de ataques usando seqüências de caracteres e expressões
Você pode executar este analisador usando as configurações de teste descritas no início do capítulo. Inicie o contêiner do Docker com diretórios montados e a saída do analisador será gravada em output / payload / analysis.suspicious_signatures.alerts.txt. O plug-in enviará milhares de notificações, o que é esperado, uma vez que esses logs são gerados pelo verificador de vulnerabilidades ZAP. Essa abordagem pode ser considerada bem-sucedida, mas possui falhas que você deve considerar.
- Expressões regulares são difíceis de escrever e ainda mais difíceis de ler . Você cometerá erros que não são fáceis de investigar e que exigirão horas de depuração dolorosa. Existem apenas quatro expressões regulares neste analisador, mas a leitura desta parte do código já é difícil. Não importa o quão poderosa e atraente a ferramenta possa ser expressões regulares, eu não recomendaria trabalhar com elas constantemente.
- Com essa abordagem, muitas notificações são geradas . Os aplicativos da Web abertos à Internet recebem muito tráfego incomum, malicioso e pouco. A geração de notificações para cada sinal incomum deixará qualquer equipe de segurança louca por várias semanas, mesmo que a taxa de falsos positivos seja baixa. Tráfego anormal é uma ocorrência natural para serviços em execução na Internet.
Você pode corrigir esses dois problemas aplicando uma abordagem matemática e tornando este sistema perfeito para detectar anomalias um pouco menos perfeito. Na próxima seção, veremos como usar métodos estatísticos para enviar notificações quando um limite for superado, como uma maneira de reduzir o ruído da lógica de detecção de anomalias.
Sobre o autor
Até o momento,
Julien Vehen está gerenciando a equipe de segurança operacional do Firefox, Mozilla. Ele é responsável por criar, implementar e operar uma estratégia de segurança de serviços da Web com a qual milhões de usuários do Firefox interagem todos os dias. Julien se concentrou em proteger os serviços de rede no início dos anos 2000. Ele começou a trabalhar como administrador de sistemas no Linux e, em 2007, obteve um mestrado em segurança da informação.
»Mais informações sobre o livro podem ser encontradas no
site do editor»
Conteúdo»
TrechoCupom de 25% de desconto para
vendedores ambulantes -
DevOpsApós o pagamento da versão impressa do livro, um livro eletrônico é enviado por e-mail.