web-dev-qa-db-fra.com

Quels moyens peuvent être utilisés pour se connecter à Wordpress?

FYI: Cela a également été posté ici car je suis assez nouveau sur ce site et je ne savais pas que le Wordpress une partie existait. Désolé pour le repost.

J'essaie actuellement de renforcer la sécurité d'un site Web qui s'exécute sur wordpress (installation séparée, pas sur wordpress.org/.com). J'ai installé Wordfence qui bloque toutes les adresses IP qui essaient d'utiliser un nom d'utilisateur non valide instantanément, ce qui fonctionne assez bien (environ 200 adresses IP bloquées/jour).

Depuis que notre FAI donne des noms d’hôtes comme

www-xxx-yyy-zzz.my.isp.tld

et il n'y a aucun utilisateur qui ait besoin de se connecter en dehors de moi. J'ai pensé ajouter un moyen d'empêcher davantage les attaques par force brute.

Le WP Codex comporte une section sur la prévention de l'accès à wp-login.php pour les personnes qui ne le soumettent pas. À mes yeux, cela devrait éliminer tous les scripts qui tentent de forcer brutalement leur chemin comme:

www.mydomain.tld/wp-admin.php?log=admin&pwd=alex

Maintenant, pour quiconque soumettant le formulaire, cela ne fonctionnerait pas, alors j'ai ajouté une partie au sommet de wp-login.php qui vérifie le nom d'hôte, puis la redirige si elle ne correspond pas à notre fournisseur d'accès Internet:

<?PHP
if (strpos(gethostbyaddr($_SERVER['REMOTE_ADDR']),'my.isp.tld') == false) {
    header('Location: http://www.google.com/');
}
?>

Je l'ai vérifié et cet article fonctionne bien également. Lorsque j'essaie d'accéder à wp-login.php sur mon téléphone portable, il me renvoie à Google. De plus, je reçois un courrier électronique lorsque quelqu'un tente de le faire. Jusqu'à présent, seules 3 à 4 tentatives de connexion ont été empêchées grâce à cette méthode.

Maintenant, de mon point de vue, je me suis occupé de tout, mais Wordfence m'enverra quand même des notifications concernant les tentatives de connexion bloquées.

Pour voir si cela aide, j’ai ajouté ce qui suit au fichier . Htaccess qui se trouve dans le dossier principal de Wordpress, qui, à mon sens, devrait refuser tout accès sauf en venant de mon fournisseur d'accès:

<Files "wp-login.php">
    order deny,allow
    allow from my.isp.tld
</Files>

Les courriels arrivent toujours par avion. Maintenant, la question est:

Existe-t-il un autre moyen d'appeler wp-login.php pour essayer de vous connecter, ce que je n'ai pas encore pensé? Il semble qu'il existe encore des moyens utilisables qui ne font pas partie des scénarios mentionnés ci-dessus.

Comme indiqué dans l’autre question: Les adresses IP ayant échoué ne sont pas falsifiées pour correspondre à la mienne.

Toutes les idées, commentaires, etc. sont grandement appréciés.

Si longtemps

2
MDschay

La réponse à ma question sur les autres possibilités de connexion a été donnée dans à la question posée par birgire .

Il s'avère qu'après la désactivation de tout accès à distance à xmlrpc.php, les attaques sont tombées à zéro.

Toutefois, cela pourrait avoir des conséquences graves sur votre site Web, car il est utilisé par exemple. jetpack entre autres et je ne le recommande donc pas.

Comme Mark Kaplun l’a mentionné, il existe probablement d’autres attaques plus sérieuses et, de l’analyse de mes journaux, ces attaques par force brute sont très élémentaires et n’ont aucune chance de l’être:

  • Changez le nom d'utilisateur admin pour autre chose que "admin"
  • Utilisez des mots de passe appropriés
0
MDschay

a écrit quelque chose de long et a décidé de supprimer parce que le Dr utilise un bon mot de passe et cesse de prétendre savoir comment sécuriser des sites, vous êtes plus susceptible de réduire les performances du site (votre code DNS inverse) ou de verrouiller vous-même alors empêcher réellement une attaque.

La sécurité concerne le contexte et, dans le contexte de wordpress, l’attaque par force brute est probablement le moindre de vos soucis, elle ne vous aurait pas empêché d’être piraté via http://wptavern.com/wordpress -security-alert-new-zero-day-vulnérabilité-découvert-dans-timthumb-script

ou http://wptavern.com/critical-security-vulnerability-found-in-wordpress-slider-revolution-plugin-immediate-update-advised

ou https://blog.sucuri.net/2015/10/security-advisory-stored-xss-in-jetpack.html

Et avant même d’avoir accès aux plugins, j’aurais peut-être dû demander si votre hébergement était sécurisé? (Vous ne trouvez pas le lien et vous ne savez pas quelle grande société d'hébergement a été piratée)

1
Mark Kaplun