Tentatives de connexion à répétition

J’ai eu dimanche après-midi comme une intuition et j’ai voulu consigner, dans un fichier de log spécifique, l’activité autour du fichier de connexion à mes blogs WordPress wp-login.php en modifiant le paramétrage de mon serveur Apache comme suit :

SetEnvIf Request_URI "/wp-login\.php(?|$|/)" login
CustomLog "logs/login_log" combined env=login

J’ai ensuite recherché des accès à la page wp-login.php à l’aide de la commande :

cat /var/log/httpd/login_log|grep -P "23/Apr"|grep " 200 "|more

Et je suis tombé là-dessus :

2a01cb0808f14c0088210bf60eb73e71.ipv6.abo.wanadoo.fr - - [23/Apr/2018:05:49:39 +
 0200] "GET /wp-login.php HTTP/1.1" 200 2520 "-" "Mozilla/5.0 (Windows NT 6.1; WO
 W64; rv:40.0) Gecko/20100101 Firefox/40.1"

Tentatives de connexion réussie : toutes mes félicitations !Il y a des chances que ce bot soit parvenu à se connecter sous un compte « Abonné« , afin de me déposer en masse les spams de commentaires dont je suis assailli. J’ai observé d’autres accès à la page wp-login.php en date du 22 avril par ce même bot.

Renforcement de la sécurité

En plus des mesures actuelles, dans le doute, j’ai tout d’abord changé le mot de passe de mon compte principal. Puis, j’ai désactivé tous les comptes inactifs à l’aide du plugin WordPress Disable Users. Je suis allé au plus pressé. Enfin, j’ai ajouté ces lignes supplémentaires à la configuration de mon serveur Apache pour bloquer mon valeureux assaillant qui a l’odeur et la couleur d’un sale méchant bot :

RewriteCond %{HTTP_USER_AGENT} "Firefox/40\.1$" [NC]
RewriteCond %{REMOTE_HOST} \.(wanadoo\.fr|sfr\.net)$ [NC]
RewriteRule "/wp-login\.php($|\?|/)" "%{HTTP_HOST}/index.html" [QSA,R=301,L]

NB Depuis la mise en oeuvre de ces mesures, je n’ai déploré aucune connexion à la page wp-login.php. J’ai eu droit à 1889 tentatives de connexion, dans la journée du 23 avril. 

Sécurité  / Apache Formateur Apache Formateur LAMP Formateur Sécurité informatique Formateur WordPress Lamp Sécurité informatique Wordpress 

Commentaires

Ah comme je te comprends, de mon côté je suis passe par un tout autre moteur, je suis maintenant sur un gestionnaire de site statics. Depuis je suis tranquille, plus de faille PHP, pas de faille du CMS ou d’un plugin, pas de compte admin ou user, même si on casse le site, hop je le remet aussitôt via ssh ou http://FTP... Puisque la base est sur ton pc .

Bref, j’aurais du mal à revenir en arrière.

Bonjour,

Consigner les tentatives de connexion à WordPress dans un fichier spécifique est peut-être utile, mais on obtiendra plus simplement la me chose avec une simple commande grep sur le fichier des logs d’accès au site.

Il y a évidemment beaucoup de tentatives de connexion sur un tel site, parfois des dizaines par jour… Si les mots de passe sont solides et le WordPress correctement sécurisé, il n’y a pas vraiment à s’en soucier.
D’autre part les requêtes GET réussies sur le fichier wp-login.php concernent simplement l’affichage de la page de connexion à l’administration. Pour surveiller les tentatives de connexion avortées ou réussie il faut filtrer les requêtes POST.

Enfin créer des règles de réécritures basées sur une tentative particulière de connexion c’est inefficace et c’est un puits sans fond. Vous n’allez pas passer votre temps à décortiquer les logs à à créer de nouvelles règles pour chaque ligne suspecte.

@bruno

J’ai regardé dans le fichier error_log à la date et à l’heure de la connexion. Or il n’y a pas eu d’erreur. L’assaillant qui doit être très probablement un bot a bien réussi à se connecter.

Il n’y a plus eu de connexion réussie à la page wp-login.php depuis les corrections apportées. CQFD.

« J’ai regardé dans le fichier error_log à la date et à l’heure de la connexion. Or il n’y a pas eu d’erreur. L’assaillant qui doit être très probablement un bot a bien réussi à se connecter. »

La réponse à la requête POST sur la page de login est en status 200 en cas d’échec de login (visible dans le moniteur réseau de la console développeur du navigateur). Donc aucun raison que cet échec de login apparaisse dans le error_log d’Apache. Un status 200, du point de vue d’Apache ce n’est pas une erreur.

Et ça se confirme en faisant un tail -f sur mon error_log : je ne vois rien arriver quand je fais une tentative infructueuse de login.

Ce qu’il faut chercher, c’est en fait des POST sur wp-login.php en status 200 dans le access_log. Un login réussi, c’est un POST sur wp-login.php en status 302 (du fait de la redirection vers l’admin).

Ex :
– login infructueux :
80.214.213.56 – – [27/Apr/2018:12:01:39 +0200] « POST /wp/wp-login.php HTTP/1.1 » 200 4516 « https://*****/ » « Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 »
– login réussi :
80.214.213.56 – – [27/Apr/2018:12:01:52 +0200] « POST /wp/wp-login.php HTTP/1.1 » 302 3468 « https://*****/ » « Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 »

@LFS

Exact. Et merci. J’ai modifié le contenu de mon billet.

Laisser un commentaire

(requis)

(requis)