[Problème] Tentative de hacking via l'interface d'administration

[didier l]

Bonjour,

Je viens de constater au travers du journal des actions des tentatives de connexion sur notre site, connexion via l'interface d'administration

• 250 tentatives le 18/12/2024 avec le même nom d'utilisateur (ou alias), en moins de 2 minutes,
• depuis 44 tentatives avec des noms d’utilisateurs différents (25 noms d’utilisateurs différents)

C'est toujours la même adresse IP 141.98.81.38 difficile à localiser : certains outils WHOIS déclarent ne pas pouvoir identifier l'adresse, quelques uns déclarent une adresse IP localisée aux Pays Bas, ISP/Provider = Flyservers S.A. basée apparemment au Panama ...

Mes questions :

• Si le hacker utilise un alias qui n'existe pas, le journal des actions en conserve t'il une trace ?
• Le fait que le hacker ait trouvé 25 alias corrects tient-t'il du hasard ou le hacker a t'il pu avoir accès la liste des alias dans la base de données du site ? Les alias correspondent à des prénoms, parfois des prénoms étrangers.
• Le hacker peut-il peut t'il s'apercevoir que le nom testé existe ou non dans la base ?

Merci pour vos réponses !


Remarques :

• Mon hébergeur est un hébergeur payant de bonne réputation ; il a détecté une attaque sur mon site,
• Le site existe depuis 2009, il hébergeait une partie Extranet (ce qui explique le nombre d'utilateurs avec un profil Enregistré) ; cette fonctionnalité étant inhibée, j'ai décidé de désactiver tous ces utilisateurs,
• J'ai pris les précautions habituelles (sauvegardes régulières, mots de passe robustes, mise à jour régulières du site, suppression des extensions non utilisées).

[Helloo]

Bonjour,

1. Quelles sont toutes les extensions tierces installées ?
2. As-tu protégé ton dossier "administrator" par mot de passe ?

[didier l]

Bonjour,

Je n'ai que des extensions assez standard et mises à jour régulièrement

• Admin Tools et Akeeba backup
• Acymailing
• JEvents et ses extensions associées
• JCE Editor
• JoomlArt : template JAStack, T4 et moduels associés,
• Des captcha Captcha Fireindly et hCaptcha

Je n'ai pas mis de mot de passe pour protéger le dossier administrator

Par ailleurs, en discutant un peu autour de moi, j'ai l'imprssion que ce type d'attaques est assez fréquent, que souvent les attaques sont infructueuses, que les administrateurs ne s'en aperçoivent pas toujours ...

Il est difficile de trouver une information fiable sur le sujet : connaissez vous un site qui donne des infos claires et pré&cises ?
Les seules infos dont on dispose généralement sont des infos fournies par les hébergeurs ou des vendeurs de logiciels qui essaient de nous vendre des outils de sécurité. Comment faire la part des choses ?
Merci

[Helloo]

Je n'ai pas mis de mot de passe pour protéger le dossier administrator

Bonjour,

Il faudrait impérativement protéger le dossier "administrator" de Joomla.

Chez la plupart des hébergeurs, il est possible de la faire en un clic.

docs.joomla.org/How_do_you_password_protect_directories_using_htac cess%3F

L'authentification de base ne peut pas être considérée comme sécurisée, même dans un sens très large du terme. Bien que le mot de passe soit stocké sur le serveur sous forme cryptée, il est envoyé du client au serveur sous forme claire sur le réseau. N'importe qui peut donc intercepter le mot de passe et le nom d'utilisateur à l'aide d'un outil de capture de paquets.

[RobertG]

Bonjour,

Si AdminTools est installé, si je ne me trompe il y a un moyen de protection de l'administration à activer.

[didier l]

Bonjour,

Plus d'attaques massives mais des visites régulières de l'espace d'administration.
Je viens d'installer CG Secure pour filtrer les urls sur les formulaires

Voir https://www.conseilgouz.com/en/cg-secure-component

[pmleconte]

Bonjour Didier,

Merci de votre confiance.

Comme évoqué par Robert, il convient de cacher l'administration et c'est possible avec CG Secure : Composant CG Secure, menu Configuration, onglet Admin, entrez un mot de passe et sélectionnez le mode "compatibilité".

Ainsi, pour voir et vous connecter à l'administration, vous devrez entrer administrator?<votre mot de passe>

Personnellement, j'envoie à AbuseIPDB les tentatives de hacking en mettant le paramètre Report (tiens, bizarre ma traduction...) sur oui après m'être enregistré sur AbuseIPDB (ce qui est gratuit).

Cela m'a permis de voir que j'ai bloqué plus de 250.000 IP (sur la vingtaine de sites dont je m'occupe) depuis la création de ce composant (octobre 2019).

Ces IP sont bloquées grâce au fichier .htaccess (onglet HTAccess, paramètre "Activation" sur Oui, "Bloquer les IPs" sur Oui). J'ai mis un paramètre "Durée de vie des IP", durée pendant laquelle les IPs restent dans le fichier .htaccess (elles sont directement rejetées).

Il ne faut pas mettre une durée trop longue car la taille de votre fichier .htaccess peut augmenter (même si je n'ai pas encore eu de problème de limite, mais, cela peut jouer sur les performances, je pense), donc, j'ai mis 10 jours par défaut.

Pendant ces 10 jours, ils n'ont plus aucun accès à votre site, ensuite, je repasse par AbuseIPDB pour vérifier s'ils sont toujours actifs et, si oui, retour dans le fichier .HTAccess.

Pascal

[didier l]

Bonjour,

Merci pour vos informations

Une petite question pour être sûr de bien comprendre : dans le journal des Logs, dans la plupart des cas, l'action associée à l'attaque est AuthentCGSecure ; ceci signifierait que l'attaque a été détectée par le Plugin Authentication CG Secure, c'est à dire que l'attaquant a envoyé une requête avec un identifiant et un mot de passe pour essayer de se connecter ?

Une autre question : le Plugin bloque t'il toutes les tentatives ou uniquement les requêtes "correctes" (syntaxe correcte, identifiant existant dans la base des utilisateurs) ?

Dans le journal de Logs, il y a une douzaine de tentatives d'attaques par jour ; les adresses IP viennent de pays "corrects" (FR, NL, US, DE, DK ...)

Merci
Didier

[pmleconte]

Bonjour Didier,

Il est possible d'appeler le formulaire de connexion à partir du site en entrant /index.php?option=com_users&layout=edit&id=0

Le plugin, au moment de l'envoi, va vérifier si la connexion est valide ou non en contrôlant si l'adresse est connue en tant que hackeur, si le pays est autorisé.

Au niveau des blocages, il y a 2 niveaux :
- via le .htaccess, les attaques "habituelles" telles que l'accès à des répertoires interdits, les attaques type SQL injections, ... Le fichier htaccess fourni contient environ 300 lignes,
- via le contrôle d'IP par rapport à la base AbuseIPDB et le pays d'origine des demandes.

Pour information, la génération du fichier htaccess provient de plusieurs sources (sur ma page https://www.conseilgouz.com/composant-cg-secure) :

Cette sécurisation reprend les exemples fournis par https://docs.joomla.org/Htaccess_examples_(security), par https://perishablepress.com/category/htaccess/ ainsi que par AESecure. La différence vient dans la possibilité de bloquer les hackeurs avérés (attaques XSS, SQL injection,...) au niveau du fichier .htaccess afin de bloquer les attaques au plus tôt.

Vous pouvez activer les fonctions log pour le contrôle de IP et sur les blocages htaccess :


Dans la version 3.2.10, je viens d'ajouter la possibilité de consulter ces fichiers log en passant par le menu CG Secure, sous-menu Logs :


Ces logs vous permettent de voir que la majorité des attaques sont des robots qui testent les failles wordpress.

Note : dans les versions récentes, j'ai aussi ajouté un blocage optionnel des robots IA....

Bon weekend,

Pascal

[pmleconte]

En complément, le plugin user CG Secure bloque les hackeurs avant affichage du formulaire de connexion si vous avez com_users dans la liste des composants à contrôler (il y est à l'installation) et ne doit pas arriver jusqu'à l'authentification.

Au niveau de l'administrateur, avez-vous activé le mode compatibilité dans l'onglet admin avec un mot de passe ?

Si oui, l'administration ne sera accessible qu'avec administrator?<votre mot de passe>
Si non, le module de connexion de l'administration est affiché et c'est le plugin d'authentification de CG Secure qui fera la blocage.

Pascal

[didier l]

Merci pour toutes ces infos !

Je savais bien que tous les sites web étaient visités par des robots plus ou moins bien intentionnés ; avec ce plug-in, les choses sont plus concrètes et visibles !

[Wismer]

Salut

Personnelement, j'utilise le composant Brute Force Stop pour bloquer les tentatives.
Il est simple et efficace.

++
Wis

[RobertG]

Bonjour,

Je m'incruste. Sur un site 5.3.0 sous PHP 8.2 où je viens d'installer CGSecure, message :

Notice: Only variables should be passed by reference in /plugins/system/cgsecure/services/provider.php on line 37

[pmleconte]

Bonjour Robert,

Merci d'avoir signalé ces "notices" qui ne sont visibles que si 'rapport d'erreur' est sur maximum. Elles n'ont pas d'impact sur le fonctionnement des plugins actuellement, mais qui causeront une erreur PHP dans les futures versions PHP.

Note : mes sites sont en PHP 8.4 et cela fonctionne.

Donc, la nouvelle version 3.2.13 corrige ces notices (elles apparaissaient sur les formulaires de connexion, de contact en plus du plugin système).

Pascal

[RobertG]

Merci Pascal !