bdd bloquée chez Ionos

Général
,
1

salut
depuis hier un site « https://archivesautonomies.org » est inaccessible ,
dernier mail de ionos: "

"nous n’avons pas de chat, pas de pub, et nous ne sauvegardons pas les visites du site.

je leur ai dit plusieurs fois de foutre une sauvegarde d’il y a une dizaine de jour, puisque apparemment, ils ont des sauvegardes.
ils nous demande de faire le nécessaire, nous sommes allé en ssh, et nous n’avons pas trouvé de fichiers php suspect.
j’ai cru comprendre que la bdd à était corrompu, par où sont ils passés ? mystère.
il est très difficile de causer avec les gens du support Ionos, car ils ne savent rien, ils ne font que remonter les infos aux admins techniques avec qui il est impossible d’avoir un contact.
n’ayant plus aucun accès, ni du site, ni de phpmyadmin, depuis le blocage, suis à la merci des techniciens, j’ai demandé d’avoir un dump de la base corrompue (pas de réponse).
Alors j’attends, Si quelqu’un à déjà eu un problème similaire chez Ionos, est-ce que cet état de fait est normal, je crois comprendre qu’ils doivent nous proposer un service payant ? … j’attends leur mail

le dernier Mail disait:
Votre base de données db454756464 a été verrouillée car la charge ainsi que le nombre d’accès sont trop élevés et ne correspondent donc plus à une utilisation standard.

La base de données concernée est rattachée au contrat IONOS Hébergement Web Premium Plus 42900281.

Important : Comme votre base de données a été verrouillée, l’accès en lecture ou en écriture n’est plus possible. Les applications liées à cette base de données ne peuvent plus y accéder.

Nous vous recommandons de ne pas utiliser votre base de données pour des applications dites à forte charge (par exemple, les systèmes de chat, d’interprétation de logs, de clics publicitaires, etc). Lorsque vous programmez, veillez à ce que les serveurs de la base de données ne soient pas soumis à une charge trop importante. Utilisez des index pertinents dans la mesure du possible.

Veuillez nous contacter pour plus d’informations, ou dès que vous aurez pris les mesures nécessaires. Nous débloquerons votre base de données dès que possible.

dans le premier mail il y avait aussi :
« Cette base de données a été bloquée car soit elle a dépassé le nombre maximum de connexion simultanées(il est de 18), soit qu’il a y eu trop de requêtes ce qui ne correspond plus à une utilisation standard ou pourrait indiquer un problème de sécurité sur votre site. »

18 connexions ?

je vois pas « les mesures nécessaires » ? surtout sans aucun accés, ou bien y a t’il quelque chose à faire dans un fichier ?
puisque j’ai l’accès ssh

2

Bonjour,

Quelle version de SPIP et php ?
Pas de trojan ou autre dans le serveur ?

3

php 8.3 spip 4.6.6

on à rien vu de suspect
je reçois ce mail maintenant
.
"Je fais suite à votre demande concernant le blocage sur votre base de données.
Nous vous informons que nous ne faisons pas d’intervention d’optimisation de sites.

Afin de pouvoir débloquer votre base de données, une optimisation de votre site est nécessaire pour éviter une nouvelle surcharge. Il est fortement recommandé de faire appel à un webmaster ou développeur pour :

  • Analyser les requêtes lourdes ou anormales

  • Nettoyer et optimiser la base

  • Mettre à jour PrestaShop et ses modules, si nécessaire

Notre équipe ne propose pas d’intervention d’optimisation ou de développement sur les sites clients.

Tant que la base de données reste bloquée, aucune restauration ne peut être effectuée. Une fois les optimisations réalisées, et si vous êtes prêt à agir sur votre site, le support pourra procéder au déblocage."
non mais là c’est fous

4

et le blocage est suite à un passage sur SPIP 4.4.6 ou autre ?
Via ftp dans les log on voit quoi avant la coupure ?

5

c’est à dire, avant la coupure ? , y’a des logs du premier septembre à aujourd’hui, on à fait des zcat access.logxxx, rien vu de méchants à première vue .
on à fait aussi
tail -f access.log.current

rien de bien parlant là non plus

je comprends pas leur proposition :
Une fois les optimisations réalisées, et si vous êtes prêt à agir sur votre site, le support pourra procéder au déblocage."

si c’est de vider les caches, ça c’est fait, je vais le refaire

6

Et dans mysql.log tu as quoi ?

7

j’y suis justement, et y’a pas de mysql.log
je viens de récuperer une sauvegarde sqlite dans tmp/dump
je pense c’est la personne qui fait le site qui l’a mis là ?
je vais la regarder
.
est-ce que je peux virer le fichier tmp/visites ?
et zut! je rapatrie le site chez moi, on verra bien

8

bonjour Momo,

Je pense que derrière il est proposé/imposé de passer à un option plus performante/couteuse. Le site en question est très visité aussi ou je serais déçu :slight_smile:
J’ai eu un problème similaire chez Infomaniak car trop de charge (données, requêtes).
EN quelques années de 27 euros par an chez lautre à 50 euros par mois chez Infomaniak. Et ce sera probablement trop juste en espace de données un jour proche.

amicalement
Claude

9

je reçois ce mail de Ionos, il y a peu de temps
:"Nous faisons suite à votre demande d’intervention concernant votre base de données.

Nous vous informons que vider les caches n’est qu’une partie de la solution pour éviter une
surcharge du serveur.

Une optimisation en profondeur de votre site et de votre base de données est nécessaire.
Cela inclut la vérification du code dans son intégralité et les requêtes SQL.
Si vous n’avez pas l’expertise requise pour effectuer ces optimisations, il conviendra de faire appel
à un professionnel compétent, tel qu’un webmaster.
Cela garantira que votre site fonctionne de manière optimale et préviendra de futures surcharges. "

ah ben ! put de moine ! il veulent que je relise tous les fichiers de spip, et que je sache si ils sont pas vérolés ? y sont bargots, j’en regarde quelques uns, et déjà c’est pas simple.
faut il en relire certains en priorité ??

10

Ceci par exemple peut aider Nettoyer un site SPIP piraté - Le labo

11

Hello @lagrenouille ça donnerait plutôt envie de partir en courant les réponses du support. Comme opacité on ne fait pas mieux.
Pour essayer de dialoguer avec eux je proposerais :

  • déjà partir du principe qu’en soi SPIP est robuste et que tu ne vas pas relire les fichiers de SPIP ni y chercher un potentiel bug.
  • Si tu as quelque chose qui ne va pas ça ne peut-être qu’au niveau de ton squelettes, donc tu pourrais proposer de retirer le dossier squelettes et de voir au fur et à mesure ce qui ne va pas, si ton site est actif il est possible de voir si des requêtes sql sont gourmandes. Éventuellement tu peux voir ça en local avec des sauvegardes à jour,
  • Bien sûr il faut éliminer l’hypothèse d’un piratage comme suggère Pierre plus haut…
  • Mais est-ce que ton site ne serait pas victime simplement d’over-frequentation par des IA ?
  • Ou d’attaques parce qu’il n’est sans doute pas neutre politiquement ?

En tout cas moi la réponse d’Ionos me donnerait envie d’aller voir ailleurs le plus rapidement possible. Mais encore faut-il que ce soit possible…
Bon courage !

12

bon, je sens que je vais devenir obsolète

find IMG/ -iname "*.php"
aucune réponse
 grep -lr --include=*.php "base64"
là il y a pas mal de fichier et je sais pas trop quoi faire pour l'instant
quand à   rgrep base64

ouh ouh c'est affreux 
style 
IMG/distant/svg/cartes_choro3ca5.svg:    <image id="image-2" width="59px" height="103px" xlink:href="data:image/png;base64,iVBORw0KGgoA.....etc etc ..........0czP2yqmnaXbi/8LuDSMeHSIjBc+AI5i//gxDzid9rGj9XnPV/gGpF22HkSmEAAAAASUVORK5CYII="/>
c'est un peu comme une clé, j'ai pas tout mis, c'est long

faut l’arrêter avec Ctrl+c

Enfin, sous les conseils de Manu, je vais garder le connect.php et le dossier squelette, et IMG, pour le reste je mets un spip tout neuf, tout frais, pêcher le jour même

et oui, je vais voir chez Ouvaton ou Infomaniack et l’autre net, ce qu’ils racontent, et le prix

13

si c’est de vider les caches, ça c’est fait, je vais le refaire

Il me semble que le cache permet à Spip d’éviter, justement, de faire trop de requêtes en base de données (vu que si une page a déjà été calculée et mise en cache, Spip récupère la version en cache au lieu de lancer toutes les requêtes de calcul).

Il y a plusieurs autres personnes sur le forum qui ont fait remonter ce problème d’utilisation excessive de la base de données ces derniers temps, et vraisemblablement ça a à voir avec un robot IA qui vient aspirer les contenus. Peut-être que les statistiques de l’hébergeur peuvent indiquer un pic de visites ?

Quelques idées sinon :

  • les statistiques de visites Spip rajoutent des requêtes en BDD, surtout si tu as activé l’option suivi des Referers. Donc une optimisation possible peut être de désactiver ces statistiques dans la config Spip.
  • il me semble que le suivi des révisions des articles rajoute aussi des requêtes BDD et fait gonfler la taille de la base, mais ça c’est juste au moment de la modification d’un article donc ça ne devrait pas impacter lors des visites (mais ça peut te faire une « grosse » base qui peut faire râler l’hébergeur).
14

merci de vos conseils
je réinstalle spip

15

Bonsoir,

Je vois le prix minimum chez Ionos est à un peu moins de 8 euros par mois. Franchement un VPS chez OVH avec un cloudpanel, tu devrais être tranquille longtemps. Je parle bien sûr dans le cas où il n’y pas de soucis de sécurité.

16

chez Ionos, c’était 21,60 euros en 2004, je crois que ça a augmenté depuis, je ne m’occupe pas des paiements, mais je vois passer les factures dans les mails.
J’ai déjà maintenue un PMB et un spip chez OVH, je connais pas les prix, c’est pas moi qui payait. et j’ai plus envie d’aller chez eux
Infomaniak me semble le plus sérieux, de ce j’ai vu jusqu’à présent. le site pèse actuellement 223 Gio, et il est appelé à grossir.

17

Pour un site aussi lourd ce n’est pas cool de rester en mutualiste et peut être configurer bigup pour réduire les images au téléchargements

18

connais pas ce plugin, je regarderai la doc pour voir ce qu il fait exactement

19

En SPIP 4.4 il est de base sur le site.

20

Bigup est décrit sommairement dans l’article de release de SPIP 4
« Les documents / logos peuvent être téléversés par drag’n’drop, quelles que soient leurs tailles (intégration du plugin BigUp en plugins-dist, amélioré pour l’occasion). La taille maximum autorisée est configurable. »