Dans cet article hors sujet, je vais discuter de certains « amusements » en coulisses qui peuvent survenir lors de la gestion du serveur Web utilisé pour héberger le site Web de Raspberryme Software. De temps en temps, le serveur devient inaccessible, mais je peux toujours accéder à sa console, et remarquer une charge CPU très élevée (plus de 100) sur un VPS à quatre cœurs, alors que la charge CPU est généralement de 0,5 à 2 dans des circonstances normales.
Cela est généralement dû à un DoS (déni de service), DDoS (déni de service distribué) ou à un bug que je ne parviens pas à identifier. Un moyen simple de résoudre ce problème consiste à vous connecter à Cloudflare et à activer le « Mode sous attaque ».
Il montrera à tous les visiteurs un défi JavaScript lors de leur première visite sur le site Web, et l’utilisation du processeur reviendra généralement à son niveau normal en une minute environ. Cela signifie que je peux accéder à mon site Web, tout comme les visiteurs réguliers. C’est désormais sans inconvénient, car le flux RSS ne fonctionne plus et certains navigateurs semblent avoir quelques problèmes avec le défi JavaScript qui passe en boucle. Je l’active donc généralement temporairement pendant quelques heures jusqu’à ce que l’attaque (D)DoS disparaisse.
Dans le cas d’une attaque DoS dans laquelle un ou quelques hôtes seulement peuvent être à l’origine d’une utilisation élevée du processeur, par opposition à une attaque DDoS impliquant de nombreux hôtes, il est également possible d’utiliser l’application d’analyse Web open source GoAccess. pour surveiller les adresses IP avec beaucoup de requêtes. Sur un serveur Ubuntu/Debian, il peut être installé comme suit :
Si l’on souhaite analyser un access.log généré par nginx, nous pouvons exécuter la commande suivante :
et sélectionnez « Format de journal commun ».
Il traitera toutes les entrées dans access.log et fournira un résumé des indicateurs clés. Mais ce n’est pas super utile pour lutter contre les attaques DoS puisque les données ne contiennent pas que des entrées récentes, et dans mon cas, il s’agissait d’environ 5 jours de trafic, donc les principales adresses IP provenaient de Googlebot et de Bingbot qui sont tous deux dites « bonnes ». des robots ».
Heureusement, l’outil ne peut également afficher que des statistiques en temps réel. Nous devrons d’abord modifier le fichier de configuration /etc/goaccess/goaccess.conf pour activer les paramètres affichés dans la capture d’écran ci-dessus. Il s’agit simplement de décommenter quelques lignes :
|
# Le format d’heure suivant fonctionne avec n’importe lequel des # Formats de journaux Apache/NGINX ci-dessous. # format d’heure %H:%M:%S … # Le format de date suivant fonctionne avec n’importe lequel des # Formats de journaux Apache/NGINX ci-dessous. # format de date %d/%b/%Y … # Format de journal commun (CLF) format de journal %h %^[%d:%t %^] « %r » %s %b |
Nous pouvons maintenant désactiver « En mode attaque » dans CloudFlare et exécuter la commande suivante :
|
tail -f access.log | aller accéder – |
Nous pouvons le laisser fonctionner pendant une minute ou deux et afficherons les mesures les plus diverses, y compris les fichiers les plus consultés, les adresses IP des principaux visiteurs, etc.
L’étape suivante consiste à vérifier les adresses IP. Par exemple, 2a06:98c0:3600::103 est une adresse IPv6 CloudFlare conçue pour les travailleurs. Bien que cela puisse poser problème, je ne vais pas le bloquer. Les adresses 66.249.65.xx 66.249.75.xxx proviennent généralement de divers robots Google, nous les laisserons donc également de côté. Mais on ne sait pas exactement à quoi sert 4.227.36.7 et certains sites Web le signalent comme une adresse IP de spam. Je l’ai donc ajouté aux règles d’accès IP dans Cloudflare-> Sécurité-WAF-> Outils avec d’autres adresses IP suspectes signalées dans GoAccess. et a activé un « défi géré » pour chacun d’eux afin d’essayer d’atténuer l’attaque DoS actuelle.
Après un certain temps, il semble que cela ait partiellement fonctionné puisque la charge du processeur est tombée de 3 à 5. Je ne suis pas sûr que ce soit la meilleure solution, mais c’est ce que je fais pour essayer de maintenir le site Web en marche. C’est un combat continu puisque les robots vont changer d’adresse IP et de vecteurs d’attaque, j’utilise donc également d’autres mécanismes, mais ceux-ci sont spécifiques à WordPress.
Retrouvez l’histoire de Raspberry Pi dans cette vidéo :
