web-dev-qa-db-fra.com

Utiliser .htaccess nier renvoyer 302 et non 403 interdit

Je suis en train d'ajouter une couche de sécurité supplémentaire à certaines de mes WordPress installations, car certains sites de mes clients utilisent un hébergement partagé et n'interdisent généralement pas les utilisateurs pour des tentatives de force brutale sur le WordPress pages de connexion. Généralement, j'utiliserais fail2ban, mais malheureusement, ces comptes sont hébergés sur un hébergement partagé et ne sont pas en mesure de l'utiliser.

Je sais qu'il existe WordPress plug-ins pour empêcher la force brutale, mais plutôt une méthode simple .htaccess qui bloquera pratiquement toutes les tentatives via le fichier wp-login.php.

J'ai donc créé ce code simple qui bloquera les utilisateurs autres que moi, ou du moins ceux qui n'utilisent pas mon fournisseur d'accès.

<FilesMatch "wp-login.php">
    deny from all
    allow from .isp.example.com
</FilesMatch>

Le code fonctionne très bien, mais je m'attendrais à voir un 403 interdit mais Firebug révèle que 302 ont été temporairement déplacés. Le retour de l'état de l'en-tête ressemble à ceci:

HTTP/1.1 302 Moved Temporarily    
Date: Thu, 31 Dec 2015 00:24:15 GMT    
Server: Apache    
X-Powered-By: PHP/5.3.29    
Expires: Wed, 11 Jan 1984 05:00:00 GMT    
Cache-Control: no-cache, must-revalidate, max-age=0    
Pragma: no-cache    
Link: <http://www.example.com/wp-json/>; rel="https://api.w.org/"    
Location: http://www.example.com/wp-login.php    
Vary: Accept-Encoding    
Content-Type: text/html; charset=UTF-8    
Transfer-Encoding: chunked

Bien que cela semble arrêter les attaques brutales, il provoque des tentatives d'accès multiples inutiles sur le serveur, par exemple, voici à quoi ressemble FireBug:

123

Autre que d’utiliser une redirection plutôt que de refuser, y at-il quelque chose que je puisse faire à ce sujet?

  • Comment puis-je retourner 403 avec deny (pas rediriger)
  • Est-ce normal? ou dois-je contacter l'hébergeur?
htaccesswordpresssecurity302-redirect403-forbidden
2
Simon Hayter

Essayez ceci si vous avez installé le module de réécriture:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^(.*)wp-login.php$
RewriteCond %{REMOTE_ADDR} !^xxx\.xxx\.xxx\.xxx$
RewriteRule ^(.*)$ - [R=403,L]

remplacez les xxx par chaque octet de votre adresse IP. Par exemple, si votre adresse IP est 111.222.333.444, remplacez

RewriteCond %{REMOTE_ADDR} !^xxx\.xxx\.xxx\.xxx$

avec

RewriteCond %{REMOTE_ADDR} !^111\.222\.333\.444$

Si cela ne fonctionne pas, utilisez ceci:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^xxx\.xxx\.xxx\.xxx$
RewriteRule ^(.*)wp-login.php$ - [R=403,L]

La bonne chose à propos de ces scripts est que les règles s'appliquent également à tout type d'URL se terminant par wp-login.php que je doute fort que 99% des sites Web veuillent mettre à la disposition du grand public.

Je suggère également d’utiliser les adresses IP au lieu des noms d’hôte, car le nom d’hôte devra quand même être résolu en adresse IP de toute façon, et comme la mise à jour .htaccess ne demande pas de temps à Apache pour reconnaître les modifications, je suggère que chaque fois que vous êtes connecté à votre compte. ISP, vous notez votre adresse IP et utilisez celle-ci dans le script ci-dessus pour que seul votre ordinateur ait accès au script wp-login.php.

1
Mike

Juste pour ajouter quelque chose à ceci pour d'autres qui peuvent rencontrer le même problème. Je recevais la même série de 5 erreurs 302 séquentielles si j'utilisais:

<Files wp-login.php>
order deny,allow
deny from all
allow from xxx.xxx.xxx.xxx
</Files>

ou en utilisant la règle de réécriture montrée ci-dessus dans mon fichier .htaccess.

La raison en est que je n'avais pas réussi à créer une page '403.shtml' J'ai créé la page à l'aide de cpanel et je reçois maintenant une seule erreur '403' lorsqu'une adresse IP refusée tente d'accéder au fichier. ... comme un idiot, j'avais supposé qu'Apache générerait une page 403 par défaut ce qu'il fait correctement sur des sites autres que Wordpress - mais il semble que wordpress tente de gérer l'erreur la page elle-même - la création d'un fichier 403.shtml oblige wordpress à laisser .htaccess faire son travail ...

1
swagIT

Est-ce normal? ou dois-je contacter l'hébergeur?

Non, ce n'est pas normal.

X-Powered-By: PHP/5.3.29
:
Link: <http://www.example.com/wp-json/>; rel="https://api.w.org/"

Mais l'en-tête de réponse HTTP présenté a transité par PHP (WordPress?), Pas seulement Apache, comme on peut s'y attendre avec une directive raw deny from .... Cet en-tête Link: suggère que WP est en quelque sorte responsable.

Soit il y a une sorte de conflit? Ou une coutume (PHP) 403 ErrorDocument pourrait être définie et remplacer la réponse attendue? Ou la demande est en cours d'acheminement via WP/quelle URL est demandée?

0
MrWhite