DEV Community

Cover image for CloudTrail - Root failed login alarm
Luis Eduardo Lunar Guevara
Luis Eduardo Lunar Guevara

Posted on

CloudTrail - Root failed login alarm

#aws #cloudskills #tutorial #cloudtrail

Típica pregunta de examen, muy fácil de memorizar y màs fácil si llegas a reconocer el patrón del caso de uso:

Digital Café Luna wants to notify the security operations team if the AWS account root user makes more than three failed console login attempts within 10 minutes. The security team wants to generate a threshold-based alarm from CloudTrail log data and notify an SNS topic.

Which solution will meet these requirements?

A. Configure AWS Config to detect failed root user login attempts and send notifications to an SNS topic.
B. Configure CloudTrail to send logs to CloudWatch Logs, create a metric filter for failed root user console login attempts, create a CloudWatch alarm with a threshold greater than 3 within 10 minutes, and notify an SNS topic.
C. Configure Amazon GuardDuty to detect failed root user login attempts and send findings directly to an SNS topic.
D. Configure IAM Access Analyzer to detect failed root user authentication attempts and trigger an EventBridge rule.

✅ Correct answer: B

La pregunta tiene varias claves que nos ayuda a identificar la respuesta:

  • Se quiere detectar más de tres intentos fallidos.
  • La venta de evaluación es de 10 minutos.
  • La alarma se dispara desde CloudTrail logs.
  • La notificación debe llegar por AWS SNS.

El patrón sale prácticamente solo:

CloudTrail → CloudWatch Logs → Metric Filter → CloudWatch Alarm → SNS
Enter fullscreen mode Exit fullscreen mode

CloudTrail registra los eventos de inicio de sesión en la consola,luego esos eventos llegan a CloudWatch Logs, estando allí, podemos crear un metric filter para buscar los intentos fallidos de login, convertirlos en una métrica, crear una alarma y notificar a través de AWS SNS. Y se acabó.

¿Por qué las otras son incorrectas?

A: AWS Config no es la mejor opción para estos casos, AWS Config es mejor para evaluar configuración y compliance de recursos.
C: GuardDuty no tiene que ver ni de cerca con este patrón, es mejor para detectar actividad sospechosa y generar findings.
D: IAM Access Analyzer tampoco llega a esta fiesta, su foco esanalizar accesos y políticas entre otras cositas.

Vamos a darle.

Antes OJO TÉCNICO en un ambiente real, este patrón se alimenta desde CloudTrail enviando eventos hacia CloudWatch Logs, solo para efectos de este lab no vamos a intentar fallar el login real del root user, mejor simulamos eventos con una estructura parecida a CloudTrail dentro de un log group de laboratorio. Así validamos la lógica sin tocar ni poner en riesgo tu cuenta cuenta root y MENOS LA MÍA!!! jaja.

Primero nos ubicamos en nuestra región de lab: us-east-1 (N. Virginia), este tipo de pregunta pertenece a los temas de monitoreo, detección y respuesta de la certificación AWS Certified Security – Specialty (SCS-C03).

Nuevamente, como nos estamos especializando, lo haremos en lo posible vía CLI.

Paso 1 — Preparamos las variables del lab 

REGION="us-east-1"
LAB_ID="scs-root-login-alarm"

LOG_GROUP="/aws/lab/${LAB_ID}"
LOG_STREAM="simulated-cloudtrail-events"

SNS_TOPIC_NAME="${LAB_ID}-topic"
Enter fullscreen mode Exit fullscreen mode

Paso 2 — Creamos el SNS topic

Debemos notificar a un SNS topic, así que vamos a crear uno.

SNS_TOPIC_ARN=$(aws sns create-topic \
  --region "$REGION" \
  --name "$SNS_TOPIC_NAME" \
  --query "TopicArn" \
  --output text)
Enter fullscreen mode Exit fullscreen mode

Y luego validamos.

echo "SNS_TOPIC_ARN=$SNS_TOPIC_ARN"
Enter fullscreen mode Exit fullscreen mode

Vamos a validar efectivamente que el topic existe.

aws sns get-topic-attributes \
  --region "$REGION" \
  --topic-arn "$SNS_TOPIC_ARN" \
  --query "Attributes.{TopicArn:TopicArn,DisplayName:DisplayName}" \
  --output table
Enter fullscreen mode Exit fullscreen mode

La salida debe darte una tabla con 2 columnas, DisplayName y TopicArn, si es asi vamos bien.

Ahora probemos una notificación por email.

aws sns subscribe \
  --region "$REGION" \
  --topic-arn "$SNS_TOPIC_ARN" \
  --protocol email \
  --notification-endpoint "tu-correo@example.com"
Enter fullscreen mode Exit fullscreen mode

Revisa el email que debió habernos llegado y confirmamos la suscripción, si no lo hacemos solo tendríamos el topic pero nunca recibiriamos la alarma por email.

Y validemos si la suscripción esta Ok

aws sns list-subscriptions-by-topic \
  --region "$REGION" \
  --topic-arn "$SNS_TOPIC_ARN" \
  --output table
Enter fullscreen mode Exit fullscreen mode

Si todo esta Ok deberíamos tener como salida una tabla con todas nuestras suscripciones.

Paso 3 — Creamos el log group y log stream de laboratorio

Como te comentaba arriba, en un ambiente real, CloudTrail enviaría los eventos hacia CloudWatch Logs. Para este lab vamos a crear un log group propio y vamos a insertar eventos simulados con una estructura parecida a CloudTrail, esto nos permitirá validar la lógica sin tocar nuestro root user.

Vamos a crear el grupo, es como el contenedor principal donde viven los logs.

aws logs create-log-group \
  --region "$REGION" \
  --log-group-name "$LOG_GROUP"
Enter fullscreen mode Exit fullscreen mode

Ahora creamos el stream, es la secuencia de los eventos dentro del log group.

aws logs describe-log-groups \
  --region "$REGION" \
  --log-group-name-prefix "$LOG_GROUP" \
  --query "logGroups[*].{LogGroupName:logGroupName,CreationTime:creationTime}" \
  --output table
Enter fullscreen mode Exit fullscreen mode 
aws logs describe-log-streams \
  --region "$REGION" \
  --log-group-name "$LOG_GROUP" \
  --log-stream-name-prefix "$LOG_STREAM" \
  --query "logStreams[*].{LogStreamName:logStreamName,StoredBytes:storedBytes}" \
  --output table
Enter fullscreen mode Exit fullscreen mode

Hasta aquí tenemos la linea base del lab, SNS topic para la notificación, los log group y los log stream donde vamos a insertar los eventos simulados.

Paso 4 — Creamos el metric filter

Ahora vamos a crear el metric filter. Aquí tomamos el patrón dentro de CloudWatch Logs y lo convertimos en una métrica. En nuestro caso, queremos contar eventos que representen un login fallido del root user.

Entonces, primero definamos las variables de la métrica:

FILTER_NAME="${LAB_ID}-filter"
METRIC_NAMESPACE="DigitalCafeLuna/Security"
METRIC_NAME="RootFailedConsoleLoginCount"
Enter fullscreen mode Exit fullscreen mode

Ahora creamos el metric filter:

aws logs put-metric-filter \
  --region "$REGION" \
  --log-group-name "$LOG_GROUP" \
  --filter-name "$FILTER_NAME" \
  --filter-pattern '{ ($.eventSource = "signin.amazonaws.com") && ($.eventName = "ConsoleLogin") && ($.userIdentity.type = "Root") && ($.responseElements.ConsoleLogin = "Failure") }' \
  --metric-transformations \
      metricName="$METRIC_NAME",metricNamespace="$METRIC_NAMESPACE",metricValue=1
Enter fullscreen mode Exit fullscreen mode

Validemos que quedó creado:

aws logs describe-metric-filters \
  --region "$REGION" \
  --log-group-name "$LOG_GROUP" \
  --filter-name-prefix "$FILTER_NAME" \
  --query "metricFilters[*].{FilterName:filterName,Pattern:filterPattern,MetricName:metricTransformations[0].metricName,Namespace:metricTransformations[0].metricNamespace}" \
  --output table
Enter fullscreen mode Exit fullscreen mode

Si vamos bien, deberíamos ver el nombre del filtro, el patrón y la métrica asociada.

Paso 5 — Creamos la CloudWatch Alarm

Ahora que podemos convertir los eventos en métrica ,necesitamos una alarma que la evalúe.

La pregunta dice:

more than three failed console login attempts within 10 minutes

Eso se traduce en:

  • Ventana de evaluación: 10 minutos.
  • Period: 600 segundos.
  • Umbral: 3.
  • Condición: GreaterThanThreshold.
  • Acción: notificar al SNS topic.

Vamos a definir una variable con el nombre de la alarma.

ALARM_NAME="${LAB_ID}-cw-alarm"
echo "$ALARM_NAME"
Enter fullscreen mode Exit fullscreen mode

Y ahora la creamos.

aws cloudwatch put-metric-alarm \
  --region "$REGION" \
  --alarm-name "$ALARM_NAME" \
  --namespace "$METRIC_NAMESPACE" \
  --metric-name "$METRIC_NAME" \
  --statistic Sum \
  --period 600 \
  --evaluation-periods 1 \
  --threshold 3 \
  --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions "$SNS_TOPIC_ARN"
Enter fullscreen mode Exit fullscreen mode

Y como hemos venido haciendo en todos los labs, TODO hay que validarlo y la alarma no será la excepción.

aws cloudwatch describe-alarms \
  --region "$REGION" \
  --alarm-names "$ALARM_NAME" \
  --query "MetricAlarms[0].{AlarmName:AlarmName,State:StateValue,Threshold:Threshold,Comparison:ComparisonOperator,Period:Period,EvaluationPeriods:EvaluationPeriods,MetricName:MetricName,Namespace:Namespace}" \
  --output table
Enter fullscreen mode Exit fullscreen mode

Paso 6 — Insertamos eventos simulados

Ahora vamos a insertar los eventos simulados en el log stream como hemos mencionados antes. No vamos a intentar fallar el login real del root user, vamos a crear cuatro eventos con estructura parecida a CloudTrail para validar que la métrica funciona.

cat > /tmp/root-failed-login-events.json <<EOF
[
  {
    "timestamp": $(date +%s000),
    "message": "{\"eventSource\":\"signin.amazonaws.com\",\"eventName\":\"ConsoleLogin\",\"userIdentity\":{\"type\":\"Root\"},\"responseElements\":{\"ConsoleLogin\":\"Failure\"}}"
  },
  {
    "timestamp": $(date +%s000),
    "message": "{\"eventSource\":\"signin.amazonaws.com\",\"eventName\":\"ConsoleLogin\",\"userIdentity\":{\"type\":\"Root\"},\"responseElements\":{\"ConsoleLogin\":\"Failure\"}}"
  },
  {
    "timestamp": $(date +%s000),
    "message": "{\"eventSource\":\"signin.amazonaws.com\",\"eventName\":\"ConsoleLogin\",\"userIdentity\":{\"type\":\"Root\"},\"responseElements\":{\"ConsoleLogin\":\"Failure\"}}"
  },
  {
    "timestamp": $(date +%s000),
    "message": "{\"eventSource\":\"signin.amazonaws.com\",\"eventName\":\"ConsoleLogin\",\"userIdentity\":{\"type\":\"Root\"},\"responseElements\":{\"ConsoleLogin\":\"Failure\"}}"
  }
]
EOF
Enter fullscreen mode Exit fullscreen mode 
aws logs put-log-events \
  --region "$REGION" \
  --log-group-name "$LOG_GROUP" \
  --log-stream-name "$LOG_STREAM" \
  --log-events file:///tmp/root-failed-login-events.json
Enter fullscreen mode Exit fullscreen mode

Validemos qué eventos hay en el stream.

aws logs get-log-events \
  --region "$REGION" \
  --log-group-name "$LOG_GROUP" \
  --log-stream-name "$LOG_STREAM" \
  --limit 5 \
  --query "events[*].message" \
  --output text
Enter fullscreen mode Exit fullscreen mode

Esperemos un rato para probar la alarma, anda y tómate un café, revisa el teléfono pero tranquilo que esto se puede tardar un ratito.

Validamos.

aws cloudwatch describe-alarms \
  --region "$REGION" \
  --alarm-names "$ALARM_NAME" \
  --query "MetricAlarms[0].{AlarmName:AlarmName,State:StateValue,Reason:StateReason}" \
  --output table
Enter fullscreen mode Exit fullscreen mode

7 — Validamos la métrica y la alarma

En el paso anterior insertamos cuatro eventos simulados, ahora vamos a validar si CloudWatch recibió la métrica generada por el metric filter.

Calculamos una ventana de tiempo reciente como referencia.

START_TIME=$(date -u -d '15 minutes ago' +"%Y-%m-%dT%H:%M:%SZ")
END_TIME=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

echo "START_TIME=$START_TIME"
echo "END_TIME=$END_TIME"
Enter fullscreen mode Exit fullscreen mode

Ahora si a consultar la métrica, deberíamos ver un datapoint con una suma cercana a 4, si todavía no aparece, puede es normal, CloudWatch puede tardar unos minutos

aws cloudwatch get-metric-statistics \
  --region "$REGION" \
  --namespace "$METRIC_NAMESPACE" \
  --metric-name "$METRIC_NAME" \
  --start-time "$START_TIME" \
  --end-time "$END_TIME" \
  --period 600 \
  --statistics Sum \
  --output table
Enter fullscreen mode Exit fullscreen mode

Luego validamos nuevamente la alarma.

aws cloudwatch describe-alarms \
  --region "$REGION" \
  --alarm-names "$ALARM_NAME" \
  --query "MetricAlarms[0].{AlarmName:AlarmName,State:StateValue,Reason:StateReason}" \
  --output table
Enter fullscreen mode Exit fullscreen mode

Si aparece ALARM, la lógica quedó validada:

  • Insertamos eventos simulados;
  • El metric filter hizo match;
  • La métrica subió;
  • La alarma evaluó más de 3 eventos en 10 minutos;
  • SNS quedó como acción de notificación.

Nuevamente no tocamos el login real del root user, pero sí comprobamos el patrón que la pregunta quiere evaluar: eventos tipo CloudTrail, metric filter, métrica, alarma y notificación.

Ojo: los comandos anteriores usan date -d, que funciona bien en CloudShell y Linux. Si estás en macOS local, usa esta variante:

Ahora activemos:

START_TIME=$(date -u -v-15M +"%Y-%m-%dT%H:%M:%SZ")
END_TIME=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
Enter fullscreen mode Exit fullscreen mode

Y listo debió habernos llegado el email con la alarma, ¿te llego?

Primero eliminamos la alarma:

aws cloudwatch delete-alarms \
  --region "$REGION" \
  --alarm-names "$ALARM_NAME"
Enter fullscreen mode Exit fullscreen mode

Eliminamos el metric filter:

aws logs delete-metric-filter \
  --region "$REGION" \
  --log-group-name "$LOG_GROUP" \
  --filter-name "$FILTER_NAME"
Enter fullscreen mode Exit fullscreen mode

Eliminamos el log group:

aws logs delete-log-group \
  --region "$REGION" \
  --log-group-name "$LOG_GROUP"
Enter fullscreen mode Exit fullscreen mode

Eliminamos el SNS topic:

aws sns delete-topic \
  --region "$REGION" \
  --topic-arn "$SNS_TOPIC_ARN"
Enter fullscreen mode Exit fullscreen mode

Mosca!!! No fue que se me olvidó. Al eliminar el SNS topic, también dejamos sin uso cualquier suscripción asociada al topic. No hace falta complicar el clean up con el manejo individual de suscripciones.

Cierre

Y se acabó el lab.

Si crees que este documento te ayuda, compártelo. Hay muchos compañeros con necesidad de practicar y aprender. Normalmente en los cursos no te dan este detalle, y no hablemos de cursos de plataforma, el tiempo no es su fortaleza.
Pero aquí tienes un ejercicio que puede servir para cuestionar, analizar cada línea y aprender para luego compartir.

Hasta una próxima y espero que les haya gustado.

Top comments (0)