CloudTrail - Root failed login alarm

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

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"

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)

Y luego validamos.

echo "SNS_TOPIC_ARN=$SNS_TOPIC_ARN"

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

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"

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

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"

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

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

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"

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

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

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"

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"

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

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

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

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

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

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"

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

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

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")

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"

Eliminamos el metric filter:

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

Eliminamos el log group:

aws logs delete-log-group \
  --region "$REGION" \
  --log-group-name "$LOG_GROUP"

Eliminamos el SNS topic:

aws sns delete-topic \
  --region "$REGION" \
  --topic-arn "$SNS_TOPIC_ARN"

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.

推荐订阅源

DEV Community