[RÉGLÉ] Site bloqué, getLanguage() retourne "null"

[Caramel256]

Bonjour,

Hébergé par OVH,
php 8.2,
mysql 8.0.39-30,
joomla 5.2.0

Depuis ce matin, mon site ne fonctionne plus, ni en front-end, ni en back-end.

Je reçois un message d'erreur qui indique que dans le fichier

libraries/src/WebAsset/AssetItem/LangActiveAssetItem.php

l'instruction

$langTag = Factory::getApplication()->getLanguage()->getTag();

ne passe pas.

Factory::getApplication()->getLanguage() retourne "null".

(Factory::getApplication()->getConfig() est correct)

Il n'y a pas eu de changement de mon fait entre hier où tout fonctionnait normalement et aujourd'hui.

J'ai vidé (sous mysql) la table jnew_session, sans effet.

Merci pour votre aide.

[RobertG]

Bonjour,

J'ai eu le même problème sur le site d'un client chez OVH en raison apparemment d'un blocage de la base de données pour dépassement de quota lié à la saturation de la table des sessions.
N'as-tu pas eu d'avertissement de l'hébergeur ?

[Caramel256]

Bonsoir,

Effectivement il y a une anomalie avec la base de données. Je me suis aperçu que sa taille est anormale, alors qu'elle ne contient que des tables joomla:

+--------------------+--------------------------------------+
| NomBaseDeDonnees | BaseDonneesMo |
+--------------------+--------------------------------------+
| information_schema | 0.00 |
| performance_schema | 0.00 |
| mabase1 | 402.44 |
+--------------------+-------------------------------------+

J'ai fait repartir mon site en

1- redéployant l'arborescence joomla de la veille (sans doute inutilement)

2- en rechargeant les tables joomla sur un autre base de données (sur un autre serveur)
+--------------------+---------------------------------------+
| NomBaseDeDonnees | BaseDonneesMo |
+--------------------+--------------------------------------+
| information_schema | 0.00 |
| performance_schema | 0.00 |
| autrebase | 0.27 |
+--------------------+-------------------------------------+

402.44 ~ 1500 x 0.27 !!!!

En fait, j'ai commencé par les tables joomla de la veille, puis j'ai effectuéun dump de la base erronée avec mysqldump. Une fois cette base restaurée, le site fonctionne, la taille de la base est donnée ci-dessus.

J'ai du mal à comprendre ce qui a pu se passer ...

Merci pour ton aide.
~

[RobertG]

Bonjour,

Tu as fait à mon avis beaucoup de manipulations peut-être inutiles.
La première chose à faire dans un cas similaire est de simplement regarder avec phpMyAdmin la liste des tables et leur taille pour savoir laquelle a pris tant de poids.
En général c'est la table de sessions qui ne s'est pas nettoyée alors qu'elle se remplit trop vite.
La vider (sans la supprimer) va résoudre le problème immédiat ; il faut dans la foulée vérifier si le site ne fait pas l'objet de connexions inutiles (à bloquer éventuellement) et jouer sur le rythme de nettoyage défini dans les tâches planifiées (page "système").

[Caramel256]

Bonjour,

Effectivement, OVH m'a envoyé un message (que je ne lis que ce matin):

"Vous avez dépassé le quota autorisé (détails visibles dans votre Espace Client) Votre base de données n'est plus accessible qu'en lecture seule ..."

et un deuxième
"L'accès à la base de données xxxxx.mysql.db a été ré-ouvert..."

J'en déduis (est-ce correct ?) que le vidage de la table "jnew_session" n'a pas été effectif, bien que je n'ai vu aucun message en ce sens.

Je suis un peu perplexe concernant les tailles : cohérentes aujourd'hui, elles sont différentes de celles indiquées dans mon précédent post.

autrebase (où il y a eu recopie du mysqldump de mabase1)
+--------------------+---------------+
| NomBaseDeDonnees   | BaseDonneesMo |
+--------------------+---------------+
| information_schema |          0.00 |
| performance_schema |          0.00 |
| autrebase          |         59.30 | (contient autre chose que joomla)
+--------------------+---------------+
+------------------------------+------------+-----------+
| Table                        | TABLE_ROWS | Size (KB) |
+------------------------------+------------+-----------+
| jnew_finder_links            |        487 |     11216 |
| jnew_finder_links_terms      |      54150 |      7728 |
| jnew_finder_terms            |       9842 |      3232 |
| jnew_content                 |        727 |      2736 |
| jnew_session                 |        527 |      1696 |
+------------------------------+------------+-----------+

mabase1 (inchangée depuis l'incident, sauf vidage de jnew_session)
+--------------------+---------------+
| NomBaseDeDonnees   | BaseDonneesMo |
+--------------------+---------------+
| information_schema |          0.00 |
| performance_schema |          0.00 |
| mabase1            |         31.28 |
+--------------------+---------------+
+------------------------------+------------+-----------+
| Table                        | TABLE_ROWS | Size (KB) |
+------------------------------+------------+-----------+
| jnew_finder_links            |        597 |     11936 |
| jnew_finder_links_terms      |      46867 |      6688 |
| jnew_content                 |        759 |      3760 |
| jnew_session                 |          0 |        64 |
+------------------------------+------------+-----------+
​
[FONT=Courier New][/FONT]

jnew_content contient 727 entrées dans un cas et 759 dans l'autre ?? Je ne comprends pas pourquoi.

Merci pour ton aide.

[RobertG]

Ces valeurs semblent cohérentes, mais la question va être de savoir pourquoi cette table sessions a autant gonflé.
Il faut surveiller et si besoin regarder dans les logs si une IP ou une série d'IP revient de manière très fréquente, et si besoin la (les) bloquer dans le .htaccess.

[Caramel256]

Bonjour,

J'ai regardé les logs comme tu le suggères. Je n'y vois rien d'anormal :

L'alerte d'OVH est datée du 13/12/2024 à 0h45 UTC = 1h45.

Logs du 15 de 15/Dec/2024:00:00:52 +0100 à 15/Dec/2024:23:59:33 +0100
12620 lignes, 51.77.x.y : 5150 lignes (IP connue)
Logs du 14
12537 lignes, 51.77.x.y : 5138
Logs du 13
24853 lignes, 147.45.47.228 : 12787 (IP ukrainienne, non déclarée robot)
Logs du 12
13278 lignes, 51.77.x.y : 5135
Logs du 11
11602 lignes, 51.77.x.y : 5136

Remarque : les clics du 147.45.47.228 (le 13/12/2024) ont été réalisés à partir de 16h57, quand le site est reparti)

La table jnew_session (de mabase1) a encore grossi (16/12/2024 09h)

+--------------------+---------------+
| NomBaseDeDonnees   | BaseDonneesMo |
+--------------------+---------------+
| information_schema |          0.00 |
| performance_schema |          0.00 |
| mabase1            |         33.90 |
+--------------------+---------------+
​
+------------------------------+------------+-----------+
| Table                        | TABLE_ROWS | Size (KB) |
+------------------------------+------------+-----------+
| jnew_finder_links            |        380 |     11936 |
| jnew_finder_links_terms      |      51709 |      6688 |
| jnew_content                 |        808 |      3760 |
| jnew_finder_terms            |       9364 |      3232 |
| jnew_session                 |       1326 |      2752 |
+------------------------------+------------+-----------+

Quelle est la bonne façon de la vider ?

Merci pour ton aide.

J-P.

[RobertG]

Bonjour,

Chaque entrée dans la table des logs déclenche une inscription de session. Ma question est donc de savoir si les IP que tu cites sont ou non licites et s'il ne faudrait pas les bloquer.
La valeur actuelle de la table session est à estimer en fonction de la fréquentation de ton site.

Il y a une tâche de vidage automatisé (page système, tâches planifiées)qui par défaut est lancée toutes les 24 heures. Tu peux réduire ce temps.

[Caramel256]

Je connais l'IP 51.77.x.y. Ses clics sont licites.

Un grand nombre de clics provient de robots et d'IP comme 147.45.47.228 qui apirent toutes les données possibles.

A première vue, tout cela semble normal.

J-P.

[RobertG]

Plus de 12.000 connexions par jour, soit 500 par heure depuis cette IP ça me semble beaucoup !
Y a-t-il tant de pages/adresses à explorer ?

[Caramel256]

Effectivement mon site a un très grand nombre de "pages/adresses à explorer", c'est pourquoi le chiffre de 12620 clics ne pas effrayé.

Mais en regardant de plus près ceux provenant de 47.45.47.228, je vois qu'ils contiennent des requêtes licites, genre

"GET xyz?view=article&id=290&...&tri=1",

mais aussi d'autres, du genre

"GET le_meme_xyz?view=article&id=290&...&tri=1&MCcb=646 5%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL% 2C%27%3Cscript%3Ealert%28%22XSS%22%29%3C%2Fscript% 3E%27%2Ctable_name%20FROM%20information_schema.tab les%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_cmdshell%28%27cat%20.. %2F..%2F..%2Fetc%2Fpasswd%27%29%23"

En fait, les 12620 clics concernent tous "GET le_meme_xyz ....", ils sont enrichis d'expressions comme ci-dessus.

Il s'agit bien d'une attaque, (de 13/Dec/2024:16:58:07 +0100 à 13/Dec/2024:18:30:24 +0100), je suis perplexe !!!

Mais, encore une fois, ces clics sont postérieurs à la fermeture de la base. Ils n'ont pas été relevés par OVH.

Merci pour ton aide,

J-P.

[RobertG]

Perso, je bloquerais cette IP dans le .htaccess

[pmleconte]

Bonjour,

Il faut mettre quelques sécurités supplémentaires sur votre site.

J'ai utilisé longtemps AeSecure de Christophe. Malheureusement, AeSecure a disparu des radars il y a 5 ans : https://forum.joomla.fr/forum/joomla...coup-de-gueule

AeSecure générait un fichier .htaccess qui bloquait les intrus, y compris les tentatives d'injection SQL.

Pour développer mon propre composant CG Secure, j'ai repris des infos de https://docs.joomla.org/Htaccess_examples_(security) , https://perishablepress.com/7g-firewall/ et d'AeSecure.

Ce composant génère un fichier .htaccess qui bloque lui aussi les intrus, contrôle le pays et peut envoyer leurs adresses à AbuseIPDB . Frâce à cela, ils ne parviennent pas jusqu'au site.

Il existe d'autres composants qui peuvent aussi bloquer ces intrus :
- Akeeba AdminTools
- récemment, @daneel a conseillé N3t Multi Captcha qui, en plus de la gestion des captchas, ajoute des contrôles au niveau des adresses IP

Pascal

[Caramel256]

Bonjour,

Je remarque que la table jnew_session ne maigrit pas:

+------------------------------+------------+-----------+
| Table                        | TABLE_ROWS | Size (KB) |
+------------------------------+------------+-----------+
| jnew_finder_links            |        470 |     11936 |
| jnew_finder_links_terms      |      52142 |      6688 |
| jnew_session                 |       3372 |      6320 |
| jnew_content                 |        715 |      3760 |
+------------------------------+------------+-----------+
​

Je suis surpris des dates "Date de dernière exécution" et "Next Run Date" indiquées à la ligne "SessionsGC" de "Système/Tâches planifiées" :

Session GC Purge des données de session 29-10-2024 19:19 30-10-2024 19:19 Normal 2

(dates identiques dans l'historique)

En cliquant sur "Exécuter le test" rien ne se passe !

Je me demande si cette tâche planifiée est correctement installée ?

Merci pour votre aide.

[Caramel256]

Encore moi,

En utilisant phpmyadmin, ce que je ne fais jamais, les chiffres sont bien différents de ceux que j'obtiens avec mysql en direct :

jnew_content 867 3.7 MiB (c'est correct)
jnew_session 4,695 6.2 MiB

(jen déduis que ma façon "mysql" de compter lignes et taille doit être incorrect !!!!)

J-P.