Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
CloudWatch coleta dados de monitoramento e operação na forma de logs/métricas/eventos, fornecendo uma visão unificada dos recursos da AWS, aplicações e serviços. O evento de log do CloudWatch tem uma limitação de tamanho de 256KB em cada linha de log. Ele pode definir alarmas de alta resolução, visualizar logs e métricas lado a lado, tomar ações automatizadas, solucionar problemas e descobrir insights para otimizar aplicações.
Você pode monitorar, por exemplo, logs do CloudTrail. Eventos que são monitorados:
Mudanças em Grupos de Segurança e NACLs
Início, Parada, reinicialização e término de instâncias EC2
Mudanças nas Políticas de Segurança dentro do IAM e S3
Tentativas de login falhadas no Console de Gerenciamento da AWS
Chamadas de API que resultaram em autorização falhada
Filtros para pesquisar no cloudwatch: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html
Um namespace é um contêiner para métricas do CloudWatch. Ele ajuda a categorizar e isolar métricas, facilitando o gerenciamento e a análise delas.
Exemplos: AWS/EC2 para métricas relacionadas ao EC2, AWS/RDS para métricas do RDS.
Métricas são pontos de dados coletados ao longo do tempo que representam o desempenho ou a utilização dos recursos da AWS. As métricas podem ser coletadas de serviços da AWS, aplicações personalizadas ou integrações de terceiros.
Exemplo: CPUUtilization, NetworkIn, DiskReadOps.
Dimensões são pares chave-valor que fazem parte das métricas. Elas ajudam a identificar de forma única uma métrica e fornecem contexto adicional, sendo 30 o número máximo de dimensões que podem ser associadas a uma métrica. As dimensões também permitem filtrar e agregar métricas com base em atributos específicos.
Exemplo: Para instâncias EC2, as dimensões podem incluir InstanceId, InstanceType e AvailabilityZone.
Estatísticas são cálculos matemáticos realizados sobre os dados da métrica para resumi-los ao longo do tempo. Estatísticas comuns incluem Média, Soma, Mínimo, Máximo e Contagem de Amostras.
Exemplo: Calcular a média de utilização da CPU ao longo de um período de uma hora.
Unidades são o tipo de medição associado a uma métrica. As unidades ajudam a fornecer contexto e significado aos dados da métrica. Unidades comuns incluem Percentual, Bytes, Segundos, Contagem.
Exemplo: CPUUtilization pode ser medido em Percentual, enquanto NetworkIn pode ser medido em Bytes.
Painéis do CloudWatch fornecem visões personalizáveis das suas métricas do AWS CloudWatch. É possível criar e configurar painéis para visualizar dados e monitorar recursos em uma única visão, combinando diferentes métricas de vários serviços da AWS.
Principais Recursos:
Widgets: Blocos de construção dos painéis, incluindo gráficos, texto, alarmes e mais.
Personalização: O layout e o conteúdo podem ser personalizados para atender a necessidades específicas de monitoramento.
Exemplo de Caso de Uso:
Um único painel mostrando métricas-chave para todo o seu ambiente AWS, incluindo instâncias EC2, bancos de dados RDS e buckets S3.
Fluxos de Métricas no AWS CloudWatch permitem que você transmita continuamente métricas do CloudWatch para um destino de sua escolha em quase tempo real. Isso é particularmente útil para monitoramento avançado, análises e painéis personalizados usando ferramentas fora da AWS.
Dados de Métricas dentro dos Fluxos de Métricas referem-se às medições reais ou pontos de dados que estão sendo transmitidos. Esses pontos de dados representam várias métricas, como utilização da CPU, uso de memória, etc., para recursos da AWS.
Exemplo de Caso de Uso:
Enviando métricas em tempo real para um serviço de monitoramento de terceiros para análise avançada.
Arquivando métricas em um bucket Amazon S3 para armazenamento a longo prazo e conformidade.
Alarmes do CloudWatch monitoram suas métricas e realizam ações com base em limites predefinidos. Quando uma métrica ultrapassa um limite, o alarme pode realizar uma ou mais ações, como enviar notificações via SNS, acionar uma política de autoescalonamento ou executar uma função AWS Lambda.
Componentes Principais:
Limite: O valor em que o alarme é acionado.
Períodos de Avaliação: O número de períodos sobre os quais os dados são avaliados.
Pontos de Dados para Alarme: O número de períodos com um limite alcançado necessário para acionar o alarme.
Ações: O que acontece quando um estado de alarme é acionado (por exemplo, notificar via SNS).
Exemplo de Caso de Uso:
Monitorando a utilização da CPU da instância EC2 e enviando uma notificação via SNS se exceder 80% por 5 minutos consecutivos.
Detectores de Anomalias usam aprendizado de máquina para detectar automaticamente anomalias em suas métricas. Você pode aplicar a detecção de anomalias a qualquer métrica do CloudWatch para identificar desvios de padrões normais que possam indicar problemas.
Componentes Principais:
Treinamento de Modelo: O CloudWatch usa dados históricos para treinar um modelo e estabelecer como é o comportamento normal.
Banda de Detecção de Anomalias: Uma representação visual da faixa esperada de valores para uma métrica.
Exemplo de Caso de Uso:
Detectando padrões incomuns de utilização da CPU em uma instância EC2 que possam indicar uma violação de segurança ou problema de aplicação.
Regras de Insight permitem que você identifique tendências, detecte picos ou outros padrões de interesse em seus dados de métricas usando expressões matemáticas poderosas para definir as condições sob as quais ações devem ser tomadas. Essas regras podem ajudá-lo a identificar anomalias ou comportamentos incomuns no desempenho e utilização de seus recursos.
Regras de Insight Gerenciadas são regras de insight pré-configuradas fornecidas pela AWS. Elas são projetadas para monitorar serviços específicos da AWS ou casos de uso comuns e podem ser ativadas sem a necessidade de configuração detalhada.
Exemplo de Caso de Uso:
Monitorando o Desempenho do RDS: Ativar uma regra de insight gerenciada para o Amazon RDS que monitora indicadores-chave de desempenho, como utilização da CPU, uso de memória e I/O de disco. Se alguma dessas métricas exceder limites operacionais seguros, a regra pode acionar um alerta ou uma ação de mitigação automatizada.
Permite agregar e monitorar logs de aplicações e sistemas de serviços da AWS (incluindo CloudTrail) e de apps/sistemas (Agente do CloudWatch pode ser instalado em um host). Os logs podem ser armazenados indefinidamente (dependendo das configurações do Grupo de Logs) e podem ser exportados.
Elementos:
Grupo de Logs | Uma coleção de fluxos de log que compartilham as mesmas configurações de retenção, monitoramento e controle de acesso |
Fluxo de Log | Uma sequência de eventos de log que compartilham a mesma fonte |
Filtros de Assinatura | Definem um padrão de filtro que corresponde a eventos em um grupo de log específico, enviando-os para o fluxo do Kinesis Data Firehose, fluxo do Kinesis ou uma função Lambda |
O CloudWatch básico agrega dados a cada 5min (o detalhado faz isso a cada 1 min). Após a agregação, ele verifica os limites dos alarmes caso precise acionar um. Nesse caso, o CloudWatch pode estar preparado para enviar um evento e realizar algumas ações automáticas (funções AWS lambda, tópicos SNS, filas SQS, Fluxos Kinesis)
Você pode instalar agentes dentro de suas máquinas/containers para enviar automaticamente os logs de volta ao CloudWatch.
Crie um papel e anexe-o à instância com permissões que permitam ao CloudWatch coletar dados das instâncias, além de interagir com o AWS Systems Manager SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM)
Baixe e instale o agente na instância EC2 (https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip). Você pode baixá-lo de dentro da EC2 ou instalá-lo automaticamente usando o AWS Systems Manager selecionando o pacote AWS-ConfigureAWSPackage
Configure e inicie o Agente do CloudWatch
Um grupo de logs tem muitos fluxos. Um fluxo tem muitos eventos. E dentro de cada fluxo, os eventos são garantidos para estarem em ordem.
cloudwatch:DeleteAlarms,cloudwatch:PutMetricAlarm , cloudwatch:PutCompositeAlarmUm atacante com essas permissões poderia comprometer significativamente a infraestrutura de monitoramento e alerta de uma organização. Ao deletar alarmes existentes, um atacante poderia desativar alertas cruciais que notificam os administradores sobre problemas críticos de desempenho, violações de segurança ou falhas operacionais. Além disso, ao criar ou modificar alarmes de métrica, o atacante também poderia enganar os administradores com alertas falsos ou silenciar alarmes legítimos, efetivamente mascarando atividades maliciosas e impedindo respostas rápidas a incidentes reais.
Além disso, com a permissão cloudwatch:PutCompositeAlarm, um atacante seria capaz de criar um loop ou ciclo de alarmes compostos, onde o alarme composto A depende do alarme composto B, e o alarme composto B também depende do alarme composto A. Nesse cenário, não é possível deletar qualquer alarme composto que faça parte do ciclo, pois sempre haverá um alarme composto que depende daquele alarme que você deseja deletar.
O seguinte exemplo mostra como tornar um alarme de métrica ineficaz:
Este alarme de métrica monitora a utilização média da CPU de uma instância EC2 específica, avalia a métrica a cada 300 segundos e requer 6 períodos de avaliação (30 minutos no total). Se a utilização média da CPU exceder 60% por pelo menos 4 desses períodos, o alarme será acionado e enviará uma notificação para o tópico SNS especificado.
Ao modificar o Limite para ser mais de 99%, definir o Período para 10 segundos, os Períodos de Avaliação para 8640 (já que 8640 períodos de 10 segundos equivalem a 1 dia) e os Pontos de Dados para Alarme para 8640 também, seria necessário que a utilização da CPU estivesse acima de 99% a cada 10 segundos durante todo o período de 24 horas para acionar um alarme.
Impacto Potencial: Falta de notificações para eventos críticos, problemas potenciais não detectados, alertas falsos, supressão de alertas genuínos e potencialmente detecções perdidas de incidentes reais.
cloudwatch:DeleteAlarmActions, cloudwatch:EnableAlarmActions, cloudwatch:SetAlarmStateAo deletar ações de alarme, o atacante poderia impedir que alertas críticos e respostas automatizadas fossem acionados quando um estado de alarme é alcançado, como notificar administradores ou acionar atividades de auto-escalonamento. Habilitar ou reabilitar ações de alarme de forma inadequada também poderia levar a comportamentos inesperados, seja reativando ações previamente desativadas ou modificando quais ações são acionadas, potencialmente causando confusão e desvio na resposta a incidentes.
Além disso, um atacante com a permissão poderia manipular estados de alarme, sendo capaz de criar alarmes falsos para distrair e confundir administradores, ou silenciar alarmes genuínos para ocultar atividades maliciosas em andamento ou falhas críticas do sistema.
Se você usar SetAlarmState em um alarme composto, o alarme composto não é garantido para retornar ao seu estado real. Ele retorna ao seu estado real apenas uma vez que qualquer um de seus alarmes filhos muda de estado. Ele também é reavaliado se você atualizar sua configuração.
Impacto Potencial: Falta de notificações para eventos críticos, problemas potenciais não detectados, alertas falsos, suprimir alertas genuínos e potencialmente detecções perdidas de incidentes reais.
cloudwatch:DeleteAnomalyDetector, cloudwatch:PutAnomalyDetectorUm atacante seria capaz de comprometer a capacidade de detectar e responder a padrões ou anomalias incomuns em dados de métricas. Ao excluir detectores de anomalias existentes, um atacante poderia desativar mecanismos críticos de alerta; e ao criar ou modificar esses detectores, poderia desconfigurá-los ou criar falsos positivos para distrair ou sobrecarregar a monitoração.
O seguinte exemplo mostra como tornar um detector de anomalias de métricas ineficaz. Este detector de anomalias de métricas monitora a utilização média da CPU de uma instância EC2 específica, e apenas adicionando o parâmetro “ExcludedTimeRanges” com o intervalo de tempo desejado, seria suficiente para garantir que o detector de anomalias não analise ou alerte sobre dados relevantes durante esse período.
Impacto Potencial: Efeito direto na detecção de padrões incomuns ou ameaças à segurança.
cloudwatch:DeleteDashboards, cloudwatch:PutDashboardUm atacante poderia comprometer as capacidades de monitoramento e visualização de uma organização ao criar, modificar ou excluir seus painéis. Essas permissões poderiam ser utilizadas para remover a visibilidade crítica sobre o desempenho e a saúde dos sistemas, alterar painéis para exibir dados incorretos ou ocultar atividades maliciosas.
Impacto Potencial: Perda de visibilidade de monitoramento e informações enganosas.
cloudwatch:DeleteInsightRules, cloudwatch:PutInsightRule, cloudwatch:PutManagedInsightRuleAs regras de insight são usadas para detectar anomalias, otimizar o desempenho e gerenciar recursos de forma eficaz. Ao excluir regras de insight existentes, um atacante poderia remover capacidades críticas de monitoramento, deixando o sistema cego para problemas de desempenho e ameaças à segurança. Além disso, um atacante poderia criar ou modificar regras de insight para gerar dados enganosos ou ocultar atividades maliciosas, levando a diagnósticos incorretos e respostas inadequadas da equipe de operações.
Impacto Potencial: Dificuldade em detectar e responder a problemas de desempenho e anomalias, tomada de decisões mal informadas e potencialmente ocultando atividades maliciosas ou falhas no sistema.
cloudwatch:DisableInsightRules, cloudwatch:EnableInsightRulesAo desabilitar regras de insight críticas, um atacante poderia efetivamente cegar a organização em relação a métricas chave de desempenho e segurança. Por outro lado, ao habilitar ou configurar regras enganosas, poderia ser possível gerar dados falsos, criar ruído ou ocultar atividades maliciosas.
Impacto Potencial: Confusão entre a equipe de operações, levando a respostas atrasadas a problemas reais e ações desnecessárias com base em alertas falsos.
cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream , cloudwatch:PutMetricDataUm atacante com as permissões cloudwatch:DeleteMetricStream , cloudwatch:PutMetricStream seria capaz de criar e excluir fluxos de dados de métricas, comprometendo a segurança, monitoramento e integridade dos dados:
Criar fluxos maliciosos: Criar fluxos de métricas para enviar dados sensíveis a destinos não autorizados.
Manipulação de recursos: A criação de novos fluxos de métricas com dados excessivos poderia produzir muito ruído, causando alertas incorretos, mascarando problemas reais.
Interrupção do monitoramento: Ao excluir fluxos de métricas, os atacantes interromperiam o fluxo contínuo de dados de monitoramento. Dessa forma, suas atividades maliciosas estariam efetivamente ocultas.
Da mesma forma, com a permissão cloudwatch:PutMetricData, seria possível adicionar dados a um fluxo de métricas. Isso poderia levar a um DoS devido à quantidade de dados impróprios adicionados, tornando-o completamente inútil.
Exemplo de adição de dados correspondentes a 70% de utilização da CPU em uma determinada instância EC2:
Impacto Potencial: Interrupção no fluxo de dados de monitoramento, impactando a detecção de anomalias e incidentes, manipulação de recursos e aumento de custos devido à criação de fluxos de métricas excessivos.
cloudwatch:StopMetricStreams, cloudwatch:StartMetricStreamsUm atacante controlaria o fluxo dos dados de métricas afetados (cada fluxo de dados se não houver restrição de recursos). Com a permissão cloudwatch:StopMetricStreams, os atacantes poderiam ocultar suas atividades maliciosas ao parar fluxos de métricas críticos.
Impacto Potencial: Interrupção no fluxo de dados de monitoramento, impactando a detecção de anomalias e incidentes.
cloudwatch:TagResource, cloudwatch:UntagResourceUm atacante poderia adicionar, modificar ou remover tags de recursos do CloudWatch (atualmente apenas alarmes e regras do Contributor Insights). Isso poderia interromper as políticas de controle de acesso da sua organização com base em tags.
Impacto Potencial: Interrupção das políticas de controle de acesso baseadas em tags.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
