Stopper les attaques DDoS ? Planifie les couches que tu gères

Ce que l’agent sait faire

• Fichiers read_file ouvre tes réglages et tes logs exportés, grep et glob les parcourent, et edit_file et write_file rédigent les changements et le runbook dans le dossier de travail du chat.
• Shell exécute ton propre script de synthèse des logs et ta commande de test de configuration, puis indique le vrai code de sortie. Les commandes dangereuses sont bloquées.
• Web web_search et http_get lisent la documentation de ton hébergeur ou de ton serveur web, si bien que les noms des réglages viennent de la source.
• Captures d’écran et images ocr lit le texte d’une capture du tableau de bord d’un hébergeur ou d’une page d’erreur, et gen_image enregistre des fichiers image.
• Orchestration task lance des sous-agents en parallèle, run_on_model envoie une étape difficile à un modèle plus gros, et skill conserve des procédures réutilisables comme le format de ton runbook.
• Modes de validation Auto-run agit tout de suite, Ask first marque une pause avant les actions qui modifient quelque chose, et Plan only écrit un plan et n’exécute rien tant que tu ne changes pas de mode.
• Cron lance un prompt selon un calendrier, par exemple la même analyse de logs sur les exports que tu déposes chaque matin dans le dossier du projet.
• Modèles utilise un fournisseur d’IA dans le cloud via un point de terminaison d’API standard, un modèle qui tourne en local sur ton PC, ou le modèle intégré.

Deux tâches, pas à pas

Lis les chiffres derrière un pic

Distinguer à la main un pic de trafic d’un flood DDoS de couche 7 demande de croiser trois sources. read_file ouvre le rapport d’analytics exporté et ton calendrier de campagnes, Shell exécute ton script de synthèse des logs, et grep cherche dans la synthèse enregistrée les chemins que tu soupçonnes. Un lancement amène de nombreux réseaux et des pages variées, alors qu’un flood venu de nombreuses sources montre souvent des requêtes identiques vers un ou quelques chemins, à des débits très élevés par client. Les logs donnent des indices, pas des preuves. L’agent se contente de résumer les comptes par adresse et par chemin, et c’est toi qui juges. Compare la synthèse avec tes propres analytics, et interroge ton hébergeur quand le tableau n’est pas clair.

Vérifie tes propres scripts à la recherche de boucles de relance

Un script qui s’emballe, une boucle de relance ou un outil de supervision mal configuré peuvent surcharger ton propre serveur par accident. Pour le trouver, pointe grep vers tes scripts et les réglages de supervision pour repérer les lignes de relance et d’intervalle. read_file ouvre chaque résultat, et edit_file propose un délai plus long avec un diff. Shell lance ensuite ta commande de test sur une copie et indique le code de sortie. Les clients internes ont aussi besoin de limites. Si c’est ta connexion internet domestique qui reçoit du trafic DDoS, la première chose à faire est d’appeler ton fournisseur d’accès. En mode Ask first, chaque modification s’arrête pour attendre ton accord, donc relis le diff et relance le test.