Site inaccessible : log : "MaxRequestWorkers"

[passion]

Bonjour,

Je ne peux pas vous donner accès à l'url de mon site (site de ma boite), de toute façon, vous ne verriez rien puisque le site est indisponible (ça mouline).
Voilà... depuis 16h30-17h, le site est donc HS.
En regardant les logs apache, j'ai ceci:

[Tue Jan 23 16:29:56.602114 2018] [mpm_prefork:error] [pid 3605] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

J'ai bien compris que les logs m'indique que la limite de requêtes est atteinte. Elle est par défaut à 150. Je ne veux pas y toucher car je doute qu'il y a une merde. Augmenter la limite n'est pas une solution...

Mon interface serveur m'indique pas de surcharge serveur extraordinaire.
Par contre, en regardant analytics en "temps réel", cela m'indique entre 10 et 15 sessions alors qu'en détail, cela m'indique qu'un seul utilisateur sur la page d'accueil et ça m'affichait des urls referer us. Là, ça c'est calmé mais le site est toujours lent.

J'ai redémarré le serveur, rien...

Une idée ?

 

[colonies]

Peut-être une attaque DDoS ? Dans ce cas tu ne risques pas de la voir dans Analytics, mais plutôt dans le(s) log(s) type access.log (voir même error.log) d'Apache.
Ton MaxRequestWorkers ne me semble pas élevé si tu es en HTTP(s)/1.1, personnellement j'utilisais :
MaxRequestWorkers 600
et MaxConnectionsPerChild 10000 (au cas où...)

Tu aurais pu au moins faire le test au lieu de carrément redémarrer la machine

En HTTP2, puisqu'il n'y a qu'une connexion pour envoyer une page (pour peu ), il n'y a plus besoin d'autoriser autant de connexions.
Ceci étant dit, maintenant j'utilise le mpm-event.

Bref, si la commande top t'indique que ton serveur ne sature pas niveau CPU/RAM, peut-être que les logs te montreront une avalanche d'appels à des URL qui ne demandent pas beaucoup de CPU (par exemple, pas de pages web, mais plutôt des images... qui peuvent saturer toutes tes connexions quand même).
Si tu as correctement configuré ton serveur Apache, tu ne logues probablement pas les appels aux ressources comme les images, donc il faudra penser à les réactiver le temps de l'analyse.

Une fois les IP qui surchargent ton serveur trouvées, tu peux les bannir.

Et accessoirement, tu peux peut-être optimiser ta configuration d'Apache pour qu'elle sature moins facilement.

 

[passion]

Merci de ta réponse.
Oui je suis passé sur debian 9, apache2.4.25 et http/2.
Effectivement, par défaut c'est mpm_preforks.
Mais j'ai changé de distrib, y a env. 1 mois et je n'avais pas de prob avec cette config ?!
Le site tourne à env. 150/200 visites/jour et là, hier j'ai dépassé le 1000 visites.
En regardant analytics, les referer me donnent ça:


J'ai installé fail2ban. Je vais passer en mpm_event mais par contre, ça ne résoud pas mon prob si c'est un DDOS.
je peux augmenter la limite de requêtes mais le prob reste présent.

 

[passion]

je suis resté sur mpm_prefork
En faisant :

netstat -an | egrep ':80|:443' | grep ESTABLISHED | awk '{print $5}' | grep -o -E "([0-9]{1,3}[\.]){3}[0-9]{1,3}" | sort -n | uniq -c | sort -nr

Cette commande me permet de lister les IPs par ordre croissant et la 1ére commence à 2 fois !
Et la commande:

netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

Me donne:

41 CLOSE_WAIT
3 CLOSING
240 ESTABLISHED
10 FIN_WAIT1
6 FIN_WAIT2
27 LAST_ACK
10 LISTEN
128 SYN_RECV
3 TIME_WAIT

Donc rien de particulier ??!!

Comprends pas ?!
Je ne voulais pas augmenter la limite sans avoir être certain qu'il ne s'agisse pas de Ddos attack mais c'est bizarre ?!

 

[colonies]

Fail2ban c'est un indispensable, mais ça ne changera rien à ton problème de serveur web.

Sinon, les données de ton

netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

ne me semblent pas normales. Voici ce que j'ai avec mon serveur :

3 CLOSING
     79 ESTABLISHED
      9 FIN_WAIT2
      1 LAST_ACK
      9 LISTEN
      6 SYN_RECV
    140 TIME_WAIT

...sauf que mon site fait plutôt 28.000-32.000 visites/jour en ce moment
Tu as plus de connexions ouvertes que moi qui fait 28/32x plus de visites qu'à ton max, et quelque chose de l'ordre de 150x ta vitesse de croisière, ça interpelle !

Ce que je vérifierais si j'étais toi :
- Que j'ai bien activé les Connection: keep-alive pour réutiliser les connexions ouvertes (mais ça, c'est surtout bon pour les vrais utilisateurs)
- Que j'ai bien activé mod_reqtimeout pour éviter les attaques de type slowloris ( https://en.wikipedia.org/wiki/Slowloris_(computer_security) )
- Éventuellement, bloquer les requêtes ayant pour referrer how-to-buy*
- Analyse des logs et blocage des plages d'IP suspectes. Ou plus rapide : pour ta première commande, le détail des ESTABLISHED te montre-t-il de nombreuses connexions depuis une IP ou quelques IP proches ?

 

[passion]

Mon prob n'est pas résolu mais j'ai plus de pistes mais pas de solutions pour autant actuellement.

J'ai reçu un mail d'ovh pour me prévenir d'une attaque DDos puis d'un 2ème mail pour me prévenir que le serveur était sorti de cette attaque. Ceci remonte à hier donc cependant malgré avoir banni l'adresse IP de "bitcoin" (cf analytics) et j'ai installé "fail2ban" et "mod_evasive". J'ai vérifié les logs puis rebooté le serveur et rien n'y fait !!!
Le monitoring ovh ne m'affiche aucun pic aujourd'hui.
Malgré tout, le site ne répond toujours pas.
J'ai même augmenté en dernier recours le "MaxRequestWorkers" et "serviceLimit", redémarré le serveur et toujours rien ! Maintenant, j'ai essayé de me connecter en FTP, j'ai voulu faire un backup, au cas où cela devenait encore plus critique, je n'ai pas pu ! J'étais tout le temps déconnecté.
Je me suis connecté SSH via putty, j'ai voulu faire un simple "apt-get update", histoire de faire une maj de la distrib si ça pouvait aidé et la console me répondait : "plus de mémoire alloué !".

J'ai même fait un test en autorisant QUE mon IP, pour accéder à mon site (bloquer par htaccess). Et bien, site indisponible !

J'en conclus que c'est comme si malgré tous mes efforts à relancer apache, tuer les processus en cours, rebooté, etc... n'empêchait pas de saturer les processus. Ce qui expliquerait pourquoi le site ne répond plus, que je ne peux rien faire en ftp, console ssh, etc... car le gestionnaire de processus a complètement saturé et n'accepte plus rien.
Comment faire pour réinitialiser ces processus et récupérer une machine opérationnelle ?

Normalement une attaque DDos est ciblée dans un instant T, non ? J'en suis sorti depuis hier, non ? Pourquoi malgré tout, je ne peux plus rien faire ?! Comme si un script en boucle, créé des processus pour saturer la mémoire d'allocation des processus ?!

Pour rappel, ma config:
Debian 9 stretch, apache 2.4.25, php7, mpm-prefork avec mod-php, https et http2 activé.
Cette distribution est en place depuis 1 mois et aucun prob jusqu'à hier soir !

Merci de votre aide.

 

[colonies]

Ah, c'était bien une attaque (ou du moins ça a été détecté comme tel).
Vu le temps qu'a mis OVH pour te prévenir, je ne dirais pas que tu en es sorti. Tu vas peut-être recevoir un autre mail pour te signaler que tu es attaqué...

Regarde ce qui se passe au niveau réseau :

netstat -tn 2>/dev/null

Si tu as une avalanche d'IP avec des ports autres que 443 (https) ou 80 (http), c'est qu'il y a probablement une attaque qui ne passe pas par le serveur web. Ou même si tu as beaucoup d'accès sur un port pour lequel tu as un service comme webmin, éventuellement (par défaut sur :10000).

Si ce sont des connexions vers 80 et/ou 443, ce sont des accès web... Reste que tu peux bloquer celles qui te semblent illégitimes.

Tu peux aussi, peut-être, avoir un historique graphique du traffic dans l'interface de ton serveur (ou d'OVH) pour voir si tout à coup le volume augmente (en particulier en entrée).

Attention aussi aux attaque asymétriques. J'ai déjà parlé de slowloris dans un message précédent, mais ça n'était qu'un exemple. Par exemple, si tu décompresse des fichiers uploadés par les utilisateurs, il est assez simple de saturer un serveur en envoyant une archive prévue pour exploser les ressources (Zip bomb : https://en.wikipedia.org/wiki/Zip_bomb ).

Mais bref, commence déjà par la base :
- commande top pour voir où tu en es au niveau des ressources, et qu'est-ce qui consomme éventuellement trop de RAM ou CPU
- liste des connexions en cours avec la commande netstat ci-dessus, et blocage via iptables (DROP), cf Google si tu ne connais pas
- df -h pour savoir s'il te reste de l'espace disque (ça peut aussi être un problème)

 

[passion]

Bon, depuis ce matin, c'est revenu à la normale. J'ai dû redémarrer le serveur.
Je pense que la machine a tellement été surchargé que plus rien n'y faisait.
Putain, si je tenais devant moi celui qui s'est amusé à ça, je lui ferais passé l'envie de ré-essayer de si tôt.
D'ailleurs... j'ai pu remonté à la source, l'expéditeur de cette attaque DDos.
Il est aux usa. J'ai contacté son registrar du domaine et son hébergeur.
Je leurs ai envoyé un mail bien salé avec captures d'écrans du monitoring du serveur, analytics, etc... avec preuves à l'appui.
J'espère qu'ils vont prendre des sanctions contre ce conn**d.

Cette mauvaise expérience m'a donné envie de monter un serveur de secours. Il aura pour rôle de faire des backups journaliers du répertoire de travail + la bdd. et si un con**rd lui venait à nouveau l'idée de ce genre de méthodes, je bascule sur l'autre vps. Je pourrai prendre des IPS failover mais c'est pas la même utilisation pour moi. Mais bon, faut dire aussi que je l'ai renforcé en sécurité. ça m'a servi de leçon. pfffff

Tout ça pour dire que je tenais à te remercier sincèrement colonies pour ton aide précieuse. tu as pris le temps de m'aider. C'est facile de passer son chemin sur le web mais tu as pris le temps de m'aider.
Respect.

Merci encore.

 

[colonies]

De rien