Ce jour-là, à trois heures du matin, alors que j'étreignais mon édredon en rêvant d'épouser ma belle-fille, mon téléphone portable s'est soudain mis à trembler comme un catalyseur. Le trafic de l'environnement de production du client a instantanément augmenté de 20 fois par rapport à la normale, les connexions TCP ont explosé, la réponse de l'entreprise est lente comme un escargot. Première réaction : un nouveau DDoS. J'ai pris mon téléphone portable et j'ai appelé le fournisseur de CDN pour lui demander de procéder à un nettoyage urgent, tout en maudissant la connexion à la console pour bloquer l'IP. Après une demi-heure, le problème a finalement été résolu, mais le lendemain, le patron m'a poursuivi et m'a demandé : "Qui a bien pu faire ça ? Comment pouvons-nous l'éviter la prochaine fois ?" J'ai regardé fixement l'arrière-plan des segments IP bloqués et j'ai soudain réalisé qu'en l'absence d'analyse des journaux, la sécurité n'est qu'un combat les yeux bandés.
Le CDN haute-défense, cette chose, beaucoup de gens pensent à acheter un paquet, avec un nom de domaine CNAME sur la fin de la question. Les attaques viennent par les vendeurs pour nettoyer, tous les jours compter sur l'accélération du cache, les journaux ? Ce n'est pas cela qui occupe le disque dur ? Mais sur le vrai champ de bataille, le journal est le véritable "enregistreur du champ de bataille". Vous avez bloqué chaque IP, bloqué chaque requête malveillante, mis en cache chaque résultat, tout est là. Les ingénieurs en sécurité qui ne creusent pas les journaux, c'est comme tenir un bol d'or pour de la nourriture - les ressources sont là, mais vous ne les utiliserez pas.
Quel trésor est caché dans le journal ? Par exemple, la dernière fois que j'ai rencontré une attaque CC, l'autre partie a utilisé des milliers de marionnettes IP à faible fréquence pour escalader l'interface de connexion, le trafic n'est pas important mais extrêmement dégoûtant. Les règles WAF habituelles n'ont pas été déclenchées, mais l'entreprise n'a cessé de signaler une augmentation du nombre d'erreurs CAPTCHA. J'ai directement tiré les journaux en temps réel de CDN07 (sa famille prend en charge la seconde poussée de journaux), écrit un script Python pour exécuter des statistiques sur le terrain :
J'ai immédiatement sorti une douzaine d'IP : chaque IP demande environ 30 fois par minute, renvoie toutes 200 mais avec la marque d'erreur CAPTCHA. Vous voyez, il suffit de regarder la courbe de trafic fart ne peut pas être trouvé, mais les journaux vous donne directement un portrait de l'attaquant - concentration de segment IP, User-Agent déguisé en Chrome, Referer uniformément pour le vide. Plus tard, directement à ce groupe d'IP, il a ajouté des règles de limitation de vitesse : plus de 10 demandes de connexion par minute pour sauter le CAPTCHA, l'attaque sur le jour de repos.
Tracer la source de l'attaque ? Vous êtes aveugle sans journal. Ne croyez pas à la propagande vantant les mérites de la "traçabilité en un clic" ; en réalité, au moment de l'attaque, l'autre partie a déjà mis en place le pool d'adresses IP et la chaîne de procurations. Mais les journaux peuvent vous aider à expliquer la chaîne d'attaque. Par exemple, l'année dernière, je suis tombé sur une bande de maîtres chanteurs qui utilisait l'IP élastique d'AWS pour pénétrer dans l'interface API de l'un de nos clients. En m'appuyant sur les journaux détaillés de CDN5 (sa famille enregistre par défaut les X-Forwarded-For et les IP réelles des clients), j'ai rétabli la chronologie de l'attaque :
En l'absence de journaux, le plus que l'on puisse voir est le résultat final du "vol d'adresses IP aux États-Unis". Cependant, en combinant les horodatages, les URI et les changements géographiques d'IP, vous pouvez inverser la chaîne d'outils et la stratégie de proxy de l'attaquant - c'est trop critique pour un renforcement ultérieur : les règles WAF ont ajouté l'empreinte Sqlmap, et des anomalies géographiques ont été ajoutées à l'interface de connexion (par exemple, les IP vietnamiennes ont soudainement sauté aux États-Unis et ont directement déclenché l'authentification secondaire).
Optimiser les stratégies de défense ? Régler les paramètres au feeling relève de la métaphysique. J'ai vu beaucoup d'équipes acheter un CDN de haute défense, l'utiliser selon les règles par défaut, et quand elles sont touchées, elles ajoutent des vérifications de curseurs comme des fous, et les utilisateurs normaux se plaignent. En fait, les logs vous ont déjà indiqué comment optimiser. Prenons le journal de 08Host comme exemple, chacune de leurs requêtes est marquée par un "label d'événement de sécurité" (tel que "attaque Web", "attaque CC", "requête normale"). J'écris directement un script pour analyser les logs de la semaine dernière :
Il s'avère que l'interface /api/v1/payment callback est balayée tous les jours, mais que les requêtes malveillantes 80% proviennent d'un segment IP sous le même ASN. C'est assez simple : ajouter directement une limite de trafic intelligente à ce numéro ASN, avec des règles aussi souples que 5 requêtes par seconde (ce qui est suffisant pour une activité normale, mais pas assez pour une explosion), et zéro faux positif. Et économisez de l'argent en achetant des packs de protection CC supplémentaires.
Comment jouez-vous avec des billes dans la vie réelle ? Premièrement.N'utilisez pas la version castrée de la vue du journal de la console.-Les champs sont incomplets, le taux d'échantillonnage est pitoyable, la recherche est lente à douter de la vie. CDN07 et CDN5 supportent les logs en temps réel à pousser, 08Host doit ajouter de l'argent pour acheter la version entreprise (ici pour cracher : est-ce que la haute défense est encore une caractéristique clé de la journalisation ?) Je ne suis pas sûr que vous puissiez faire cela. J'ai l'habitude de ne pas aimer directement la pile ELK, de prendre Kibana pour faire de la visualisation. Je partage une configuration Kanban commune que j'utilise :
Deuxièmement.Ne vous concentrez pas uniquement sur le blocage des adresses IP.. Les attaquants avancés changent d'IP plus souvent que de chaussettes. Je préfère analyser les modèles de session : par exemple, la même IP accédant à la "page de connexion -> page d'accueil de l'utilisateur -> page de commande" pendant une courte période est un comportement normal, mais la "page de connexion -> interface CAPTCHA -> page de connexion" tournant 10 fois est définitivement une explosion. Pour ce faire, il faut corréler plusieurs entrées de journal en sessions - nous recommandons d'écrire une règle en temps réel à l'aide de Flink ou de Spark Streaming, qui fonctionne beaucoup mieux qu'un seul point de blocage d'IP.
Ajoutez-y un dernier cas de force majeure.Un jour, un client a été victime d'une attaque lente, où chaque connexion TCP était maintenue pendant plusieurs minutes avant d'envoyer quelques octets. Le moniteur de trafic ne voyait aucune anomalie. Plus tard, nous avons extrait les journaux TCP du CDN5 (attention : pas les journaux HTTP !) et avons constaté qu'un grand nombre de connexions provenaient du segment IP d'un fournisseur de services en nuage de niche. J'ai constaté qu'un grand nombre de connexions provenaient du segment IP d'un fournisseur de services en nuage de niche, et que chaque connexion avait survécu pendant plus de 300 secondes, mais que les données transférées étaient inférieures à 1 Ko. J'ai directement écrit des règles iptables pour bloquer l'ensemble de l'ASN :
Le monde est propre. Il n'est même pas possible de déterminer le type d'attaque sans journal, et encore moins de la bloquer avec précision.
Sérieusement, de nos jours, même les CDN doivent "prévenir les coéquipiers" - certains fournisseurs, afin de montrer un "bon effet défensif", filtrent délibérément les journaux d'attaque, la console ne vous donnant à voir que le nombre d'interdictions. L'infiltration avancée que l'on a vraiment rencontrée, telle que les personnes qui frappent la station source, n'a pas été remarquée. C'est pourquoiIl est plus important que tout de conserver une copie du registre original à la maison.Le jour où les défenses seront démantelées, vous pourrez toujours compter sur les journaux pour faire une autopsie numérique.
En résumé, l'analyse des journaux du CDN haute défense n'est pas du tout une "fonction optionnelle", mais le centre nerveux du système de défense. En vous appuyant sur elle, vous pouvez avoir une vue d'ensemble de l'attaque, ajuster la précision de la stratégie et même repousser les intentions de l'attaquant. N'attendez pas que les douves soient percées pour creuser des tranchées - commencez dès aujourd'hui à collecter des rondins. (Et bien sûr, n'oubliez pas d'acheter un disque dur, ne me demandez pas comment je le sais).
