Auteur Sujet: LaFibre.info sous Attaque DDOS ? (Lu 11476 fois)

cali · « **Réponse #48 le:** 02 mai 2015 à 10:47:51 »

Citation de: Damien le 02 mai 2015 à 10:26:51

SMF est assez optimisé pour les ressources. Vivien n'a pas réellement besoin de chercher à optimiser.

Il n'y a pas d'optimisation il y a juste faire du propre.

cali · « **Réponse #49 le:** 02 mai 2015 à 11:01:32 »

Citer

Warning

We do not recommend using a threaded MPM in production with Apache 2. Use the prefork MPM, which is the default MPM with Apache 2.0 and 2.2. For information on why, read the related FAQ entry on using Apache2 with a threaded MPM

https://php.net/manual/en/install.unix.apache2.php

Citer

Why shouldn't I use Apache2 with a threaded MPM in a production environment?

PHP is glue. It is the glue used to build cool web applications by sticking dozens of 3rd-party libraries together and making it all appear as one coherent entity through an intuitive and easy to learn language interface. The flexibility and power of PHP relies on the stability and robustness of the underlying platform. It needs a working OS, a working web server and working 3rd-party libraries to glue together. When any of these stop working PHP needs ways to identify the problems and fix them quickly. When you make the underlying framework more complex by not having completely separate execution threads, completely separate memory segments and a strong sandbox for each request to play in, further weaknesses are introduced into PHP's system.

If you want to use a threaded MPM, look at a FastCGI configuration where PHP is running in its own memory space.

https://php.net/manual/en/faq.installation.php#faq.installation.apache2

jack · « **Réponse #50 le:** 02 mai 2015 à 12:13:57 »

Citation de: vivien le 02 mai 2015 à 08:25:31

En cas d'attaque, les requêtes suivantes (> 256) sont mis en attente et donc traitées, mais avec du retard (quelques secondes). Une fois la connexion établie avec le client, ses requêtes sont traitées très rapidement, vu que le serveur n'est pas sur-chargé.

Ça fait quelque jour que tu as mis ça, non ?
Depuis quelque jours, la première connexion à lafibre.info, quand j'ouvre mon browser, est longue (la suite est rapide)

vivien · « **Réponse #51 le:** 02 mai 2015 à 12:39:20 »

Cali, comme l'indique les captures d'Apache, je n'utilise pas PHP + Apache2 worker mais PHP + Apache2 prefork conformèment aux recommandations.

jack, les requêtes sont mis en attentes, si tous les slot sont occupés (donc pendant un attaque tel que celle du 24 mars, les autres sont trop petites pour avoir un impact). C'est le comportement de tout serveur web Apache.

La chose qui a été modifiée, c'est le nombre de slots Apache passés de 150 à 256, suite au pic de consultation de la visites des NRO de Free :

Citation de: vivien le 19 février 2015 à 16:36:13

Augmentation du nombre de slots Apache2 réalisé e ce matin : On est passé de 150 à 256 :

[/size]

Je suis intéressé pour savoir ce qui fait que le site est long à la première connexion (hors SmokePing où c'est lié à SmokePing)

Au contraire j'ai réalisé une optimisation : il n'est plus nécessaire de faire une seconde connexion vers Akamai, pour vérifier si le certificat https est révoqué (gain de 400ms pour la première page) :

Citation de: vivien le 22 avril 2015 à 08:33:36

OCSP (Online Certificate Status Protocol) Stapling activé : un chargement plus rapide de la 1ère page

La fonctionnalité OCSP Stapling est activée sur lafibre.info depuis vendredi 17 avril 6h30

Cela sert à certifier que le certificat qui permet de chiffrer n'a pas été révoqué, sans faire de connexion vers un autre site.

Quels gains avec OCSP Stapling ?
- L'autorité de certification n'a pas accès à l'historique de navigation du client
- La vitesse de chargement de la première page est diminuée de plusieurs centaines de ms
- L'obtention du statut du certificat est plus efficace car elle n'est plus assujettie à une surcharge éventuelle des serveurs de l'autorité de certification (risque d'attaque par DDoS du serveur en question)
- Le client n'a donc pas besoin d'ouvrir une nouvelle connexion vers l'autorité de certification.

La charge du serveur de l'autorité de certification est moindre car la réponse qu'il a obtenu du répondeur OCSP peut être réutilisée par tous les clients qui utilisent le même certificat dans la limite du temps de validité de la réponse. Dans notre cas (StartSSL), c'était Akamai qui était utilisé pour vérifier la certification. chaque connexion à LaFibre.info entraînait une connexion chez Akamai.

Pour vous montrer en pratique le gain de temps pour charger la première page :

cali · « **Réponse #52 le:** 02 mai 2015 à 12:51:18 »

Citation de: vivien le 02 mai 2015 à 12:39:20

Cali, comme l'indique les captures d'Apache, je n'utilise pas PHP + Apache2 worker mais PHP + Apache2 prefork conformèment aux recommandations.

Oui mais c'est mauvais, le plus important est:

Citer

look at a FastCGI configuration where PHP is running in its own memory space.

C'est normal qu'en prefork ton apache ne réponde plus de rien après quelques requêtes, il te faut du multi-threading. Le prefork c'est apache 1.3 c'est tout vieux.