Serveur temporairement hs sans raison

Bonjour !
J’ai perdu l’accès à tous mes services Yunohost (à l’exception du SSH) pendant quelques (très longues) minutes. En essayant un upgrade, j’ai eu ce retour :

Re-diagnosing server health...
Error: Found 1 significant issue(s) related to Base system!
Warning: Found 1 item(s) that could be improved for Internet connectivity.
Error: Found 1 significant issue(s) (and 13 warning(s)) related to DNS records!
Success! Everything looks good for Ports exposure!
Error: Found 2 significant issue(s) related to Web!
Error: Found 1 significant issue(s) related to Email!
Success! Everything looks good for Services status check!
Success! Everything looks good for System resources!

Je n’ai pas trouvé dans la doc les commandes pour revérifier ces erreurs et en savoir davantage.
Un nouvel upgrade ne m’a rien revoyé. À l’heure actuelle tout fonctionne mais je souhaite faire un état des lieux car un serveur qui tombe comme ça ce n’est pas normal.

Autres remarques : mon ssh était lent à réagir au moment du problème, les logs de fail2ban montrent pas mal d’erreurs iptables.

Depuis cette mise à jour manuelle, je reçois deux fois par jour un rapport d’erreur un peu plus détaillé.

J’ai pu régler quelques soucis dns signalés (des changements DKIM principalement, apparus tous seuls, je n’avais jamais eu ça jusqu’à présent et un ajout XMPP qui doit venir de la mise à jour).

Également trois signalements :

Domain *machin.truc* appears unreachable through HTTP from outside the local network.

Ces signalements d’erreurs ne correspondent pas à la réponse de mon serveur puisque je peux joindre sans problème les adresses en question par http/https (comme c’est le cas pour mes autres adresses).

Je n’ai absolument rien touché à la configuration du serveur depuis plusieurs mois, hormis une sauvegarde manuelle faite en webadmin récemment. Cette dernière mise à jour manuelle a-t-elle intégré ou rétabli un outil de diagnostic avec envoi de mails récapitulatifs ? La détection des erreurs aurait-elle un souci ?

Pour info, ce serveur, je ne l’ai jamais bidouillé, je n’ai réalisé que des actions classiques via l’outil Yunohost depuis que je l’ai mis en place.

Quelqu’un a-t-il une idée de ce qu’il se passe ? Une expérience similaire ?

Tu n’as pas mis la config matérielle ? Et en fonction de la quantité d ip bloquées et du Matos concerne y a peut-être un lien

C’est un VPS OVH avec processeur Intel :

model		: 60
model name	: Intel Core Processor (Haswell, no TSX)

8GiB de RAM, 1GiB de swap, pas de saturation de stockage.

Je viens de mettre à jour le reverse proxy, je vais bien voir si les alertes disparaissent pour les ndd injoignables.

Par contre ça ne me dit pourquoi j’ai perdu mes services sans crier gare avant de les récupérer quelques instants plus tard…

Note : depuis l’incident et la mise à jour, je n’ai plus d’erreurs du côté de fail2ban.

Oui donc ça peut pas être ça. Tu as vérifié dans les journaux via l interface web où les logs si il y avait eu une action particulière à ce moment là ?
Et tu as vérifié auprès d’objets si il y a pas eu une perte de connectivité à ce moment là ?

Et t’as combien d’ip bloquées actuellement sur fail2ban?

L’évènement le plus proche est appelé migration sur la webadmin : https://paste.yunohost.org/raw/akuqoluxev

À part ça, rien vu de significatif dans les logs, j’ai tout un tas d’erreurs du côté de nginx (fastcgi et overlay notamment) mais rien qui soit critique au point de ne plus pouvoir joindre les services.

C’est-à-dire ?

Aucune.

Désolé la frappe prédictive m’a empêché d’écrire ovh donc je voulais dire, as tu vérifié auprès d’ovh si il n’y avait pas eu de problèmes de services de leur côté ? Je connais suffisamment de personnes ayant des serveurs chez ovh que pour savoir qu’il y a des interruptions de services régulières.
Je dis ça car tu signalés que tu as eu une coupure de tous tes services sauf ssh et que même ssh était donc lent.
Ça m’embête car ça pourrait très bien pu être temporairement un problème réseau de leur part, une trop grande charge sur le serveur sur lequel tu es hébergée de la part des autres allocataires etc. Tu n’es pas sans savoir que ton vps n’est pas un serveur dédié mais une espèce de containers parmi x dizaines d’autres sur un serveur.
Ce qui m’embête aussi c’est ton problème de fail2ban. Si il a crash il a pu foutre le bordel dans iptables, à cause de trop de fail ssh ou autre.
Ce qui 'm’étonne aussi c’est que tu me dises que tu n’aies aucune ip bloquées.
Sur ma bete brique internet à la maison j’en ai déjà 700 sur un mois et demi de temps.
Il est vrai que j’ai modifié quelque peu les timers pour que les échecs soient enregistrés sur une plus grande période de temps et que le ban soit exponentiellement plus grand.
Sur mes vps sur divers providers je dois en avoir aux alentours de 7000 ou 15000 quand il y a un pic tous les 6 mois. Conclusion si tu as une ip fixe, t’es obligé d’avoir des ip bloquées vu la quantité de bots qui scannent en permanence les ip fixes.

Oui je sais bien et c’est la première chose que j’ai vérifiée car j’ai déjà eu le cas avec eux. Mais rien n’a été signalé publiquement à ce sujet au moment de ma panne.

Pour info j’ai désactivé la connexion par id/mdp sur le ssh. J’ai quelques ip bloquées sur mes divers jails mais très peu et aucune au moment où j’écris ces lignes.

Il serait peut-être bon de voir ça avec le service technique. Ils ont certainement des logs d’utilisation et des graphes.

Pour ce qui est, de fail2ban c’est quand même étrange. Moi je vérifierais mon jail ssh au moins. Que tu aies mis accès qu’avec les clés rsa ou autre n’ont rien à voir avec les tentatives des bots. Ça sera quand même loggé, donc tu devrais avoir des ip bloqués au moins sur ton jail ssh. Ou bien t’es vraiment le mec le plus chanceux que je connaisse:)

Sinon tu pourrais regarder tes logs systèmes en ssh pour voir si tu as d autres erreurs, le service cron etc et vérifier par rapport à l’heure environ ou ça s’est produit.

fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	1025
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	16
   `- Banned IP list:

J’ai pas mal d’attaques côté auth.log pourtant mais rien qui ne soit banni. Le service est bien démarré, les jails bien activés. J’ai testé manuellement sur un de mes services, le bannissement fonctionne et est répertorié dans les status. À croire que les ip parasites n’insistent pas jusqu’au bannissement… :thinking:

À ce propos, mon ip banni je peux quand même accéder à quelque chose sur ma webadmin et ce, avec le même look que le jour du plantage (html sans css avec quelques boutons qui ne fonctionnent pas et des liens yunohost). Cela voudrait donc signifier que mon ip était bannie.

Ceci dit, je n’en vois pas la raison ! Je n’ai pas tenté de m’authentifier et de toute façon mes id/mdp sont enregistrés, je ne me plante que très rarement. Je me suis retrouvé devant le fait accompli en tentant de me connecter. Fichtre.

Oui mais le fait que tu aies énormément de fails il faudrait vérifier sur le log évidemment pour être sûr mais typiquement je dirais que c’est parce que le timer pendant lesquels les ip peuvent essayer est trop courts, ils ont donc des paramètres d’essais qui prennent un peu plus de temps entre chaque que les paramètres par défaut de fail2ban que tu as laissé tel quel je suppose ?

Du coup tu as un nombre de fails importants et peu d ip bannies. Et même si tes ip sont bannies elles ne le sont qu’une heure je suppose si tu l as laissé tel quel donc c est très vite debanni aussi contrairement à moi.

Pour ce qui est du fait que tu aies pu accéder aux restes ça dépend des paramètres fail2ban mais je suis pas sur qu il banisse la partie admin et même si il le fait j suis pas sur que ce soit un bannissement complet quand il y a un bannissement sur ssh. à vérifier.
Mais fais un screen de ce à quoi tu as accès, parce qu il se peut que ce soit juste une réminiscence de ton cache navigateur.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.