Empêcher le server inutilisable sur les attaques wordpress bruteforce

Je gère un server avec de nombreuses installations de création de wordpress. En recherchant une solution pour éviter une CPU élevée sur les attaques bruteforce, cela rend le server inutilisable quelques heures par jour.

Ce sont les cibles:

  • La détection des references n'est pas suffisante ( EXEMPLE ) (déjà essayé cette solution, mais les pirates qui m'attaquent peuvent le contourner et remplir le processeur de toute façon).
  • La protection par mot de passe sur "wp-login.php" via .htaccess n'est pas une bonne solution ( EXEMPLE ) (exigences de l'entreprise).

3 Solutions collect form web for “Empêcher le server inutilisable sur les attaques wordpress bruteforce”

Il y a plein de choses que vous pouvez faire pour empêcher les attaquants de mâcher vos ressources.

(re) envisager d'utiliser la protection par mot de passe pour les zones d'administration

Vous pouvez avoir des raisons valables de ne pas l'utiliser sur tout ou certains sites, mais ne sous-estimez pas l'utilité de cette technique. Utilisez autant que possible.

En obligeant les users à se connecter au niveau du server Web, vous minimisez les attaques endommagées par les attaquants, limitez les ressources nécessaires pour faire face à ces attaques et protégez davantage vos sites Web susceptibles d'avoir des vulnérabilités.

restreindre la connection admin à une list ip-whitelist (server web)

Vous pouvez refuser l'access à des parties de votre site Web. Même si vous devez ouvrir un sous-réseau assez grand d'adresses IP, il vaut mieux laisser au monde entier!

Dans nginx, cela pourrait ressembler à ceci:

location /wp-admin { # block one workstation deny 192.168.1.1; # allow anyone in 192.168.1.0/24 allow 192.168.1.0/24; # drop rest of the world deny all; } 

rendre plus difficile à find

Les attaques de la force brute font un certain nombre d'hypothèses. Si vous pouvez renommer votre dossier wp-admin, renommez wp-login.php ou exécutez wp-admin sur un port non standard, vous n'aurez plus à dépenser vos ressources précieuses en essayant de valider ces connections de la force brute.

essayez fail2ban

http://wordpress.org/plugins/wp-fail2ban/

fail2ban est l'une des mesures de security les plus simples et les plus efficaces que vous pouvez mettre en œuvre pour éviter les attaques de saisie de mot de passe de force brute.

fail2ban a quelques fonctionnalités intéressantes:

Bloquer les tentatives de connection avec un nom d'user incorrect

De nombreux attaquants tentent de se connecter avec des noms d'users communs, tels que l'admin. C'est une bonne pratique de ne pas utiliser ces noms d'user, auquel cas vous pouvez bloquer toute personne qui essaie de vous connecter avec eux.

WPf2b vous permet maintenant de spécifier un regex qui raccourcit le process de connection si le nom d'user demandé correspond

définissez ('WP_FAIL2BAN_BLOCKED_USERS', '^ admin $');

ip-whitelist (fail2ban)

L'idée ici est d'énumérer les adresses IP des proxies de confiance qui apparaîtront comme IP à distance pour la request.

 define('WP_FAIL2BAN_PROXIES','192.168.0.42,192.168.0.43'); 

Je peux penser à quelques possibilités tout au plus haut de ma tête; dans l'ordre de l'invasion à peu près croissante des users légitimes:

  • Renommez wp-login.php à autre chose? (Nécessite d'être maintenu lors de la mise à niveau, dépend de la security par obscurité, mais devrait arrêter la plupart des attaques scriptées non ciblées avec un minimum de problèmes pour les users légitimes.)
  • CPU-limite le process du server Web? (Le server Web devient un peu plus lent pendant les inondations de requêtes, mais devrait permettre la maintenance du server, même en cas de lourde attaque, même si seulement 5% du CPU restant devraient être nombreux. Peut-être besoin d'une coordination avec le process du server de database.)
  • Les requests de limite de taux pour wp-login.php dans un équilibreur de charge ou un pare-feu en face avant? (Cela donnera aux users légitimes un problème lors d'une inondation de requête, mais au less le rest du server, y compris l'access public au contenu du blog, devrait continuer de se déplacer heureusement.)

J'ai écrit un plugin WordPress que vous findez probablement utile.

Le mauvais comportement a un bon bilan de l'arrêt de ces attaques de force brutale. Il s'agit d'un pare-feu minimalist d'application Web qui bloque le spam de liens et d'autres trafics malveillants très tôt, avant que WordPress ne soit chargé, ce qui permet d'économiser de l'UC et d'autres ressources. (Je dis minimalist parce que ce qui peut être fait uniquement sur cette couche est minimal par rapport à ce que vous pouvez faire sur le server Web ou même avec un appareil séparé, bien qu'il ait été conçu pour les personnes n'ayant aucune autre option).

Vous le findez dans le repository de plugins WordPress .


Comme vous exécutez le server, vous pouvez également utiliser ModSecurity avec Core Rule Set . Beaucoup de règles du Bad Behavior sont réembeddedes ici (searchz mon nom et / ou le nom du Bad Behavior en eux) et le jeu de règles contient également beaucoup d'autres règles qui peuvent vous être utiles.

  • Plugin WordPress pour TRAC?
  • Vernis 4 Configuration de travail (optimisé) pour Wordpress (default.vcl)
  • Wordpress wp-admin redirige la boucle derrière IIS ARR Reverse Proxy
  • Comment créer un miroir du site wordpress en cours sur le même server?
  • Comment pointer un server Web Windows subdir vers un subdir du server Centos en permanence?
  • Pourquoi le server hôte affiche-t-il plus d'un process du file d'index?
  • sed regexp pour replace xxx dans define ('DB_PASSWORD', 'xxxx') ;?
  • Réécris une URL Wordpress sur .htaccess
  • WordPress: comment maintenir "www" dans l'URL?
  • Déniérant le dossier dans Nginx, ce qui entraîne la non-priorité de PHP-FPM
  • Wordpress / IIS / PHP ne peut pas download de files avec des caractères non ASCII
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.