TP : Détecter une attaque par force brute avec Elastic Security avec correction

Ce que vous allez apprendre dans ce TP

• Produire des événements ECS
• Écrire une règle de seuil
• Écrire une règle EQL
• Trier et investiguer

Introduction #

Ce que vous allez apprendre dans cette section

• Produire des événements ECS
• Écrire une règle de seuil
• Écrire une règle EQL
• Trier et investiguer

Contexte. Un serveur exposé subit des tentatives de connexion. Vous écrivez les règles qui détectent la rafale d'échecs puis la connexion réussie qui la suit.

Prérequis : le labo start-local du TP précédent, jq  ·  Durée estimée : 40 min

Licence : ce TP fonctionne aussi avec la licence Basic gratuite : règles de seuil et EQL, alertes, timelines et cases y sont inclus. Seules les règles de type machine learning et les notifications vers des outils externes (Slack, Jira…) demandent un abonnement ou l'essai.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Des événements d'authentification

   Pourquoi ? Les règles d'Elastic Security s'appuient sur ECS : event.category, event.outcome, source.ip, user.name.

   Voir la correction

   source elastic-start-local/.env && export PASS=$ES_LOCAL_PASSWORD
   B=$(( $(date -u +%s) - 120 ))   # événements horodatés sur les deux dernières minutes, le succès après les échecs
   evt() { printf '{"create":{}}\n{"@timestamp":"%s","event":{"category":["authentication"],"outcome":"%s"},"source":{"ip":"203.0.113.50"},"user":{"name":"admin"},"host":{"name":"srv-web-01"},"message":"%s password for admin"}\n' "$(date -u -d @$1 +%Y-%m-%dT%H:%M:%SZ)" "$2" "$3"; }
   { for i in $(seq 12); do evt $((B + i)) failure Failed; done; evt $((B + 30)) success Accepted; } > auth.ndjson
   curl -s -X POST 'localhost:9200/logs-authlab-default/_bulk?refresh=true' -u elastic:$PASS -H 'Content-Type: application/x-ndjson' --data-binary @auth.ndjson | jq .errors   # false

2. 2. Une règle de seuil

   Créez une règle qui alerte au-delà de 10 échecs depuis une même adresse IP.

   Voir la correction

   curl -s -X POST localhost:5601/api/detection_engine/rules -u elastic:$PASS -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d '{
     "rule_id": "lab-force-brute", "name": "Lab - force brute", "description": "Plus de 10 échecs de connexion depuis une même IP",
     "type": "threshold", "index": ["logs-authlab-*"], "language": "kuery",
     "query": "event.category:authentication and event.outcome:failure",
     "threshold": { "field": ["source.ip"], "value": 10 },
     "risk_score": 73, "severity": "high", "interval": "1m", "from": "now-10m", "enabled": true, "tags": ["lab"]
   }' | jq '{id, name, enabled}'

3. 3. Une règle EQL

   Pourquoi ? Une rafale d'échecs suivie d'un succès pour le même compte est bien plus grave qu'une rafale seule : la séquence EQL l'exprime directement.

   Voir la correction

   curl -s -X POST localhost:5601/api/detection_engine/rules -u elastic:$PASS -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d '{
     "rule_id": "lab-echecs-puis-succes", "name": "Lab - échecs puis succès", "description": "Échec puis succès de connexion pour le même compte et la même IP",
     "type": "eql", "language": "eql", "index": ["logs-authlab-*"],
     "query": "sequence by source.ip, user.name with maxspan=10m [authentication where event.outcome == \"failure\"] [authentication where event.outcome == \"success\"]",
     "risk_score": 90, "severity": "critical", "interval": "1m", "from": "now-10m", "enabled": true, "tags": ["lab"]
   }' | jq '{id, name, enabled}'

4. 4. Les alertes

   Attendez une minute, puis listez les alertes produites.

   Voir la correction

   sleep 70
   curl -s -X POST localhost:5601/api/detection_engine/signals/search -u elastic:$PASS -H 'kbn-xsrf: true' -H 'Content-Type: application/json' \
     -d '{ "query": { "match_all": {} }, "size": 10 }' | jq '.hits.hits[]._source | {regle: .["kibana.alert.rule.name"], severite: .["kibana.alert.severity"]}'

5. 5. Trier et investiguer

   Dans Security › Alerts, ouvrez l'alerte critique, examinez la séquence dans une timeline, ajoutez-la à un case, puis passez l'alerte en « Acknowledged ».

   Voir la correction

   Dans la timeline, la requête source.ip : 203.0.113.50 montre les 12 échecs puis le succès. Le case garde la trace de l'analyse et peut être transmis à un outil de ticketing par un connecteur.

   Bonne pratique : Ajoutez une exception sur la règle de seuil pour les scanners de vulnérabilités internes plutôt que de relever le seuil pour tout le monde.

Niveau de difficulté : ●●●○○ (3/5)