Ouvre le dossier du projet
Mets le log d’accès exporté et une copie des réglages de ton serveur dans un même dossier, puis ouvre ce dossier dans SmartCode Relay.
Flux de travail
Layer 7 DDoS protection : du log exporté au runbook
03
Un pic de trafic sur le site d’une petite boutique
Le site de ta boutique a ramé la nuit dernière. Pourquoi ? Une campagne comme un flood de couche 7 pourraient l’expliquer. Tu as un log d’accès exporté et une copie des réglages de ton serveur, et ce guide en tire une synthèse, un brouillon de limite de débit et un runbook.
Résume les requêtes
Demande à l’agent d’exécuter ton script de synthèse des logs et d’enregistrer les requêtes par adresse et par chemin dans un fichier CSV.
Rédige la limite de débit
Laisse-le modifier la copie de tes réglages, relis le diff, puis exécute ta propre commande de test sur cette copie.
Écris et vérifie
Enregistre ddos-runbook.txt, relis-le ligne par ligne, et utilise Plan only pour lister ce qui reste avant d’appliquer quoi que ce soit.
Exemple : un runbook de réponse d’une page
Écris ddos-runbook.txt pour le site de la boutique à partir de la synthèse du log et des notes de l’hébergeur.
- read_file
exports/summary.csvlu - http_get
your provider's status pagerécupéré - write_file
ddos-runbook.txtenregistré - grep
^step ddos-runbook.txt6 correspondances
En attente de ton accord avant l’étape suivanteRefuserAccepter
ddos-runbook.txt
# ddos-runbook.txt - small shop site
# Owner: site admin
trigger: slow pages and an odd log summary
step 1: check the provider status page
step 2: raise the provider protection level
step 3: review the log summary for top paths
step 4: apply a rate limit, then test it
step 5: keep the origin address private
step 6: record times, rules and who was called
rollback: remove the limit if real visitors are refused
review: update this file after each incidentC’est du texte brut. Chaque étape nomme une action pour toi ou pour ton hébergeur, aucune ne contient de commande d’attaque, et les deux dernières lignes disent comment revenir en arrière et quand relire.
Deux autres flux de travail
Écris des seuils pour ta propre supervision DDoS
Les seuils relèvent du système de supervision que tu utilises déjà, et l’agent ne t’aide qu’à choisir les chiffres. Il ne configure aucune alerte lui-même. read_file ouvre la synthèse du log d’une journée chargée mais normale, grep y cherche les chemins qui comptent, et write_file enregistre un court fichier de notes avec les valeurs à saisir. Faire face à une attaque DDoS contre un site web se passe mieux quand les seuils ont été écrits avant la nuit où on en a besoin. Utilise d’abord Plan only pour lire le plan des étapes, puisque ce mode n’exécute rien, puis passe en Ask first pour que l’agent lise la synthèse et que write_file enregistre les notes. Compare chaque chiffre avec tes propres analytics, saisis-le toi-même et surveille attentivement la première alerte.
Distingue une adresse très active de nombreuses adresses
Atténuer du trafic DDoS venu d’IP distribuées ne peut pas reposer sur le blocage d’une seule adresse, donc compare les comptes par adresse et par chemin de ta synthèse. De nombreux petits émetteurs s’additionnent. La protection DDoS de couche 7 s’appuie sur des limites par chemin, car chaque requête paraît normale isolément. Shell relance ton script de synthèse des logs pour qu’il regroupe par chemin, et grep cherche dans la nouvelle synthèse les chemins qui t’intéressent. Quand les attaques DDoS semblent acharnées et que tu ne peux pas les contenir sur le serveur, le runbook dit quand appeler l’hébergeur. Relis la synthèse en mode Ask first et teste toute nouvelle limite sur une copie.
