La Fibre
Fonctionnement du forum => A lire avant de commencer... => 
Évolution de LaFibre.info, bugs et critiques => Discussion démarrée par: vivien le 12 décembre 2017 à 09:08:46
-
Il y a deux jours, le site a été victime d'une attaque DOS qui a réussi à aspirer 17 000 pages du site en 4 minutes.
Le but est probablement la saturation du CPU du serveur vu qu'il a aspiré les pages en PHP et pas le contenu statique comme les images.
Le site a été ralenti, mais il a tenu.
Pour avoir un tel nombre de pages, l’attaquant a utilisé de nombreuses connexion CP en parallèle.
Pour éviter de dégrader les performances lors d'éventuels prochains épisodes, je vais limiter à 10 connexions TCP utilisées simultanèment par adresse IP.
Ce chiffre de 10 connexions TCP en parallèle ne devrait pas impacter les clients qui sont sur une IP partagée où plusieurs personnes regardent simultanèment le forum.
Pour ceux qui souhaitent regarder, voici les log Apache de l'attaque : 201712_attaque_dos.ods (http://lafibre.info/images/stats/201712_attaque_dos.ods) (fichier Libreoffice Calc, lisible également avec Microsoft Excel)
-
Beaucoup plus de chances que ce soit un crawler avec des paramètres trop agressifs qu'une attaque.
D'après l'historique DNS ça ressemble à un mutualisé chinois https://virustotal.com/fr/ip-address/74.91.24.130/information/
-
Salut,
Mon dernier aspirateur de site que j'avais utilisé a quelque chose comme ça en limite en dur (quelques dizaines, pas plus). Aucun risque que je fasse n'importe quoi.^^
Par contre, c'est en connexions ou requêtes?
Car dans le 2ème cas, en IP partagée, ou multi-user sur une IP, cela va bien ralentir. Il y a déjà plusieurs requêtes par page affichée.
J'ai déjà 99 requêtes, juste pour afficher la page d'accueil!
-
C'est en nombre de connexion TCP, généralement un navigateur ouvre une ou deux connexions TCP.
Après tu fais ce que tu souhaites comme requête sur ta connexion TCP, les demandes sont traites les unes après les autres.
La 17 000 requêtes sont sur 17 000 connexions TCP différentes, à chaque fois il faut des échanges TLS pour le chiffrement.
Le port source change a chaque fois et varie entre 1066 et 65347
A noter que ce n'est pas le comportement par défaut de Windows ou Linux de mettre des ports source < 32768
Les ports clients sont normalement dans la plage suivante :
- Windows 2000 / XP (sortie en 2001) : du port 1025 au port 5000
- Windows modernes (à partir de 2007) : du port 49152 au port 65535
- Linux avant 2001 (noyaux 2.2.x) : du port 1024 au port 4999
- Linux à partir de 2001 (noyaux 2.4.x à 3.13) : du port 32768 au port 61000
- Linux à partir de 2015 (noyaux 3.19 et suivants) : du port 32768 au port 60999
- MacOS X / FreeBSD modernes : du port 49152 au port 65535
-
Ok pour les connexions TCP.
Cela va bien ralentir uniquement dans des cas spécifiques. Genre >10 personnes sur la même IP partagée ou connexion internet... et qui veulent tous surfer sur ce forum en même temps.^^
Il y a 10 ans, je crois, Microsoft recommandait au maxi 600/IP/minute pour éviter les attaques DOS. Ne me demander pas pourquoi pour les minutes.
Et maxi 160/IP en simultané. Tout ceci en connexions TCP.
En ne regardant que l'overview de l'outil intégré au navigateur, il y aurait 2 connexions TCP... et les 99 requêtes sont traitées en moins de 1s. Donc la puissance de calcul est là.
-
Cela va bien ralentir uniquement dans des cas spécifiques. Genre >10 personnes sur la même IP partagée ou connexion internet... et qui veulent tous surfer sur ce forum en même temps.^^
Non, le timeout du KeepAlive est réduit à 2sec max déjà, donc même après le chargement de la page, les ressources sont libérées très très rapidement dans le cadre d'un surf.
C'est déjà plus délicat lors de longues sessions (de l'ordre de l'heure carrèment), genre des sessions Usenet avec des gens en VPN ou CGNAT en face :)
-
2 secondes?
La vache! C'est extrêmement court... :o
5 à 10 secondes serait plus adapté, tout en restant dans de petites valeurs.
C'est quoi par défaut? 2 minutes en moyenne des navigateurs, non?
Côté serveur, Apache recommande 5 secondes minimum. Et perso, 10 secondes minimum.
Mais pour le principe, c'est vrai que cela réduit encore les cas de ralentissement dû à ces paramètres.
-
2 secondes?
La vache! C'est extrêmement court... :o
5 à 10 secondes serait plus adapté, tout en restant dans de petites valeurs.
C'est quoi par défaut? 2 minutes en moyenne des navigateurs, non?
Côté serveur, Apache recommande 5 secondes minimum. Et perso, 10 secondes minimum.
Mais pour le principe, c'est vrai que cela réduit encore les cas de ralentissement dû à ces paramètres.
Attention, tu mélanges plusieurs notions.
Le KeepAlive, c'est la notion de garder une même connexion active après le chargement d'une ressource. De base, 1 connexion = 1 ressource (la page elle-même, les images, CSS, scripts, etc). Sauf que le KA permet d'éviter de fermer/ouvrir sans arrêt, et donc d'optimiser le temps de chargement. Donc là, la connexion se ferme 2sec après le chargement de la dernière ressource.
Après, tu as le timeout classique d'une connexion. Je ne m'étends pas là dessus, tu dois connaître.
Par contre, c'est pervers : une ressource doit être chargée en qq secondes : une page 1sec max, une image, 2sec, etc. Ta connexion n'a pas vocation à être ouverte pendant X minutes ! La connexion ne devrait donc pas durer pas plus de qq secondes, tout au plus. Sinon un gus peut facilement ouvrir des sockets dans une boucle... et saturer le serveur juste en 3/4 lignes de code. Il faut donc pouvoir couper les sessions inactives très rapidement.
-
Ce chiffre de 10 connexions TCP en parallèle ne devrait pas impacter les clients qui sont sur une IP partagée où plusieurs personnes regardent simultanèment le forum.
ca met une erreur HTTP type "too many connexion" si on depasse ?
-
La connexion est bloqué au niveau d'iptables, elle n'arrive pas à Apache, donc pas de message.
Voici c que j'utilise :
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 10 -j REJECT
ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 10 --connlimit-mask 64 -j REJECT
Dans ma configuration Apache, j'ai mis KeepAliveTimeout 2 soit deux secondes comme le dit Hugues.
La valeur par défaut est de 5 secondes. Cf doc Apache2.4 : https://httpd.apache.org/docs/2.4/mod/core.html#keepalivetimeout
MaxKeepAliveRequests 100 est à sa valeur par défaut : 100 cf https://httpd.apache.org/docs/2.4/mod/core.html#maxkeepaliverequests
j'ai baissé le timeout de 300 (valeur par défaut d'Ubuntu) à 60 secondes (valeur par défaut d'un apache non customisé par Ubuntu) : Timeout 60 C'est le temps maximum où le serveur ne reçois plus rien d'une connexion avant quelle ne soit fermée. J'ai fait pas mal de test et il ne faut pas descendre en dessous de 60 secondes sinon les clients Free en itinérance 3G Orange n'arriveront pas à charger la page (et même dans certains cas, il arrive que Free ne laisse rien passer pendant 60 secondes). Cf doc Apache 2.4 : https://httpd.apache.org/docs/2.4/mod/core.html#timeout
J'ai configuré mon serveur pour répondre à 1000 connexions simultanées :
<IfModule mpm_prefork_module>
StartServers 30
MinSpareServers 25
MaxSpareServers 75
MaxRequestWorkers 1000
ServerLimit 1000
MaxConnectionsPerChild 0
GracefulShutdownTimeout 3600
</IfModule>
GracefulShutdownTimeout 3600 permet d'éviter d'avoir des slots occupés pas des téléchargements qui durent plusieurs heures alors que apache2 souhaite réduire le nb de slots. Par défaut il n'y a pas de limite de temps (0). Là je coupe les connexions 3600 secondes après la demande pour libérer le slot (par exemple à chaque rotation de log). Je laisse donc un minimum d'une heure pour télécharger un fichier, cela me semble bien suffisant, même pour ceux qui ont des connexion à 36 Kb/s. Cf la doc https://httpd.apache.org/docs/2.4/mod/mpm_common.html#gracefulshutdowntimeout
Il faut prévoir tous les types d'abus... (si je l'ai mis en place, c'est que j'ai déjà vu des téléchargement qui dépassent les 24h)
Toujours dans les optim, j'ai mis dans /etc/sysctl.conf ces 3 lignes, pour réduire le swap et augmenter certaines limites
vm.swappiness = 10
net.ipv4.tcp_max_syn_backlog = 1024
net.core.somaxconn = 512
-
ok.
Disons que l'ensemble est fonctionnel, mais bon, je suppose que t'affineras selon la quantité de retours négatifs.
Je garde mes réserves, mais je comprends aussi que tu veuilles libérer des ressources serveur, entre l'augmentation des activités normales, et celle des activités douteuses.
-
bloquer en iptables c'est pour les gros trucs je pense... si tu trouves que ca DDOSe trop ok ca le fait mais là...
j'ai vu rapido qu'il y a des mods apache https://www.google.fr/search?q=limit+ddos+apache
PS: je te l'avais déjà dit sur le sujet des IP belges, choisis mieux tes ex ;)
-
Donc 10 connexions TCP, cela ne devrait pas gêner un utilisateur qui ouvre plusieurs onglets sur différents sujets de Lafibre.info ? Dans ce cas, cela me semble une bonne précaution.
Sinon, c'est quoi le user agent 'Pcore-HTTP/v0.44.0' ? D'après ce que j'ai vu sur Internet, ce serait un script Perl qui ferait du crawl robot ?
Je me demande si ce n'est pas une mauvaise manip ? Pourquoi vouloir s'en prendre au site lafibre;info ? En tout cas, il n'aura rien à gagner par exemple d'une demande de rançon pour cesser le DOS.
-
Je me demande si ce n'est pas une mauvaise manip ? Pourquoi vouloir s'en prendre au site lafibre;info ? En tout cas, il n'aura rien à gagner par exemple d'une demande de rançon pour cesser le DOS.
c'est ce que je crois aussi.....
-
Les attaques (D)DOS n'ont parfois aucune raison apparente, ou encore seulement d’embêter.
Mais je crois aussi à la mauvaise manip dans ce cas => durée courte.
Pour les onglets, cela dépends des navigateurs, et encore, dans l'hypothèse d'une ouverture/actualisation simultanée parfaite, et du nombre d'onglets vers lafibre.
Moi, à chaque démarrage de mon navigateur préféré, j'ai 4 onglets lafibre. Cela passe. Et j’ajoute ensuite ce que je veux pour le surf, y compris vers le forum lafibre.
-
bloquer en iptables c'est pour les gros trucs je pense... si tu trouves que ca DDOSe trop ok ca le fait mais là...
Au contraire, il me semble que bloquer comme ça impose Conntrack, ce qui est le premier truc que tu vires sur un serveur à fort trafic.
-
comme il a été dit, je sens plus l'érreur qu'autre chose...
si cela arrive trop souvent là oui on sort l'artillerie lourde pour se défendre....
-
Je viens de modifier la configuration qui limite à 10 connexions TCP par IPv4 et par plage /64 IPv6.
Pour les onglets, cela dépends des navigateurs, et encore, dans l'hypothèse d'une ouverture/actualisation simultanée parfaite, et du nombre d'onglets vers lafibre.
Moi, à chaque démarrage de mon navigateur préféré, j'ai 4 onglets lafibre. Cela passe. Et j’ajoute ensuite ce que je veux pour le surf, y compris vers le forum lafibre.
Tu peux refaire ton test, mais pour moi, cela devrait fonctionner simultanèment jusqu'à 10 onglets qui se chargent simultanèment : une connexion TCP par onglet. A vérifier, mais je ne suis pas sur qu'un navigateur va faire toutes ses demandes simultanèment.
Sinon, c'est quoi le user agent 'Pcore-HTTP/v0.44.0' ? D'après ce que j'ai vu sur Internet, ce serait un script Perl qui ferait du crawl robot ?
Rien ne dit que c'est le vrai user-agent. C'est facile de mettre un faux user agent pour brouiller les pistes.
Disons que l'ensemble est fonctionnel, mais bon, je suppose que t'affineras selon la quantité de retours négatifs.
Oui, au moindre retour qui me montre qu'il est possible légitimement atteindre 10 connexions TCP par IP j'augmente la imite, mais sil me semble que les cas > 10 connexions par IP sont assez irréalistes.
-
Sinon, c'est quoi le user agent 'Pcore-HTTP/v0.44.0' ? D'après ce que j'ai vu sur Internet, ce serait un script Perl qui ferait du crawl robot ?
Non, ce n'est pas un script, c'est une bibliothèque qui implèmente des fonctions de client HTTP tout à fait génériques (comme urllib2 en Python).
Rien ne dit que c'est le vrai user-agent. C'est facile de mettre un faux user agent pour brouiller les pistes.
Non. Là on est à environ 0 % de probabilité en termes de malveillance. Le client se comporte comme un crawler et non pas un script d'attaque (un script d'attaque n'a pas de raison de se comporter comme un crawler). Ensuite se faire passer pour un navigateur peut augmenter les facteurs d'acceptation d'un client HTTP, mais se faire passer pour une bibliothèque Perl à usage générique n'a aucun intérêt. Ensuite la Chine n'a pas de raison d'avoir une dent contre Lafibre.info, ni même de lui provoquer 2 h de downtime pour des raisons politiques.
-
Je viens de modifier la configuration qui limite à 10 connexions TCP par IPv4 et par plage /64 IPv6.
Mal lu le 1er post. Je pensais que c'était déjà le cas.
My bad.
Tu peux refaire ton test, mais pour moi, cela devrait fonctionner simultanèment jusqu'à 10 onglets qui se chargent simultanèment : une connexion TCP par onglet. A vérifier, mais je ne suis pas sur qu'un navigateur va faire toutes ses demandes simultanèment.
J'ai refais avec les 4 onglets de départ.
Test insuffisant, mais j'en profite pour remarquer que mon navigateur a d'ailleurs, à part un cas normal (avec une image en tout), un comportement binaire au cas par cas:
- 2 connexions TCP pour une page de forum, qu'il y ait domaine tiers ou pas (et avec un début différé, et sous-utilisation de la 2eme connexion TCP)
- 1 connexion TCP pour une page de SmokePing
- 1 connexion TCP pour n'avoir qu'une image en tout (normal)
- 2 connexions TCP pour la page "IP", dont la 2eme uniquement pour le sous-domaine "ipv4" presque à la fin (contrairement au 1er cas).
Pour que ce soit simultané, il faudra que je teste 5 à 10 onglets lafibre au démarrage, dont des pages forum pour que ce soit plus rapide vers une éventuelle erreur.
Tester aussi avec Bouygues Telecom mobile.
Enfin bref, je ne pense pas que ce sera aujourd'hui, mais j'ai de quoi tester un peu.^^
-
ca met une erreur HTTP type "too many connexion" si on depasse ?
Cela dépend a quel niveau c'est limité.
Sur un autre site, on a 2 types d'erreur sur les téléchargements simultanées uniquement:
- une erreur 503 classique "Service Unavailable" si on tente entre 2 et 6 téléchargements, avec des critères compliqués (je ne comprends d'ailleurs pas leur philo dans ces cas là).Mais en persévérant plus ou moins, c'est bon.
- une requête en attente "infinie" (doit y avoir un timeout quand même mais jamais tenté la longue attente) où le navigateur met tout en bas "en attente de connexion", ou un truc du genre le temps que le serveur libère un slot sur l'IP, si on a déjà atteint les 6 téléchargements simultanées en cours.
Sinon, il n'y a pas d'erreur HTTP type "too many connexion". Le plus proche, mais pas adapté ici, c'est l'erreur 429 "Too Many Requests"
-
Je me demandais d'où venait mon problème, voilà que j'ai la réponse :)
-
Bonjour,
Serait-il possible d'en dire plus ?
Quelle utilisation nécessite plus de 10 connexions TCP simultanées sur LaFibre.info ?
Cela permet d'avoir une centaines de personnes sur la même IP qui consultent le forum simultanèment.
-
Salut,
J'ai parfois, sans raison apparente, du "En attente de lafibre.info..." durant pas mal de secondes (>10 secondes).
Peut être ce que voulais dire Pierre.
Mais je ne pense pas que ce soit lié à ce paramètre. :-\
J'ai retrouvé le message d'info du navigateur dans ce genre de cas: "En attente d'une interface de connexion disponible", que j'ai sur un autre site qui limite les téléchargements simultanés.