Est-il possible de servir des pages spécifiques en fonction de l'adresse IP?

8

J'ai été la cible d'une attaque par force brute sur deux sites WordPress que je possède. L'attaquant utilise la bonne vieille chose XML-RPC pour amplifier l'attaque par mot de passe par force brute. Heureusement, nous avons des mots de passe extrêmement bien générés, donc je doute fortement qu'il puisse jamais arriver n'importe où.

Je viens d'utiliser iptables pour bloquer ses demandes chaque fois qu'il réapparaît (toujours depuis le même fournisseur de cloud virtuel), mais je préférerais de beaucoup modifier le serveur pour qu'à chaque fois que son adresse IP demande une page, il reçoive une réponse lui disant pour avoir une vie. La plupart des demandes sont des POST, donc je voudrais idéalement juste modifier l'en-tête de réponse pour inclure quelque chose comme "Plus de chance la prochaine fois!" ou quelque chose de tout aussi satisfaisant.

Est-ce possible? Je suis loin d'être un expert d'Apache, donc je ne sais pas à quel point cela serait difficile à mettre en œuvre. Mais même si cela me prend des heures, la satisfaction sera inestimable.

Pour référence, j'utilise Ubuntu 16.04.2 LTS, avec Apache 2.4.18 hébergeant Wordpress 4.7.3.

apache-2.4 http-headers

— Aurelius
source

"toujours du même fournisseur de cloud virtuel" OVH? J'ai remarqué que de nombreux script kiddies utilisent leurs services pour une raison quelconque.

— hd.

Non, online.net ... jusqu'à présent, ils n'ont pas répondu à un seul de mes rapports d'abus. De plus, la première fois que j'ai envoyé une demande d'abus, j'ai découvert qu'ils transmettaient automatiquement la plainte au client. D'où comment il a trouvé mon site personnel. Bon travail, online.net ....

— Aurelius

25

Installez simplement fail2ban avec la prison appropriée et finissez-en . Ne vous embêtez pas à donner une réponse personnalisée, car il est très probable qu'elle ne sera jamais vue.

— EEAA
source

1

Pour sûr. Mais c'est définitivement quelque chose que j'ai toujours voulu faire. Même s'il ne le voit jamais, juste la possibilité me fait rire si fort que je pleure presque.

— Aurelius

14

Eh bien: 1) à mon humble avis trouver comment afficher une petite insulte à un script kiddie est hors sujet ici. 2) Cela consommera toujours vos ressources apache, tandis que fail2ban / iptables bloque les requêtes en amont, de sorte que votre application n'a jamais à les traiter.

— EEAA

1

Oh c'est sûr. Mais je veux m'amuser un peu avant la perma-ban. Que ce soit mesquin ou non, je veux juste rire, et c'est à la demande de la personne qui utilise le serveur.

— Aurelius

4

@Aurelius, si vous connaissez l'ip, et que cette personne ne le masque pas, pourquoi ne le faites-vous pas dans l'application elle-même, php dans ce cas. Vérifiez simplement si c'est ip xx.xx.xx.xx et si c'est simplement tuer le script avec une réponse,die("blah blah");

— Miguel

Accepté comme réponse, principalement parce que je ne connaissais pas fail2ban et donc c'est vraiment utile en général. La réponse de Miguel ci-dessus, ainsi que la réponse de BlackWebWolf ci-dessous, sont les deux choses que je vais examiner!

— Aurelius

5

Il est possible, et nous l'avons fait beaucoup, de renverser d'éventuelles attaques. Utilisez iptables pour rediriger le fournisseur de cloud (plage d'adresses) vers un port différent - et il sert une réponse à l'attaquant, même en en-têtes simples.

Dans Apache, vous pouvez modifier les en-têtes par exemple:

Header set GetOut "Better luck next time!"

— BlackWebWolf
source

Hehehe !! Voilà de quoi je parle. Bonne idée! J'examinerai cela.

— Aurelius

5

cette stratégie se retournera probablement contre la réponse, car elle permet à l'attaquant de savoir ce qui fonctionne et ce qui ne fonctionne pas, il est préférable de simplement passer silencieusement la demande à rien et de ne déclencher aucun indicateur d'alerte dans son logiciel d'attaque de bot. Idéalement renvoyer le html de la page demandée, par exemple. ils ne savent jamais que vous les avez attrapés, rien ne se passe et votre site est plus sûr. Résistez à l'envie de leur faire savoir, c'est toujours une ERREUR. Cela les aide simplement à déboguer le problème. Dans votre cas, passez simplement à des plages IP plus dynamiques, etc., ce qui rend le problème BEAUCOUP plus difficile à résoudre.

— Lizardx

1

Vous avez raison, ce n'est pas recommandé - c'est même peut-être dangereux. La stratégie avec le pot de miel est toujours meilleure, mais la question était claire - comment troller un attaquant :)

— BlackWebWolf

Peu m'importe si c'est une erreur - j'ai installé fail2ban, et il sera banni de toute façon. Je doute fortement qu'il va réellement arriver quelque part; pour autant que je sache, les dernières versions de WordPress ont en fait corrigé ce bogue de sécurité? Sans oublier, les mots de passe de forçage brut qui sont plus longs que 20 caractères ... ouais, ça n'arrive pas dans la vie de notre univers.

— Aurelius

blackwebwolf, c'est similaire à quelqu'un qui demande comment implémenter l'extension mysql_ dépréciée de php, alors que l'on peut techniquement répondre à cette question, cette réponse est fausse car la vraie réponse signifie le faire correctement, dans ce cas, par exemple, en utilisant mysqli_ à la place ou xpdo. C'est juste l'idée, que beaucoup d'entre nous ont également faite dans notre passé, que répondre d'une manière quelconque comme la pêche à la traîne est autre chose qu'un énorme négatif, devrait être corrigé, car c'est une grave erreur, et si quelqu'un a déjà souffert à cause de cette erreur, on comprendrait immédiatement pourquoi la question était erronée.

— Lizardx

3

C'est très facile avec ModSecurity qui est un module WAF tiers pour Apache. Bien qu'il implique l'apprentissage de sa syntaxe de langage de règles.

Vous pouvez également utiliser ModSecurity pour simplement interrompre la connexion plutôt que de répondre du tout.

Cela dit, installer ModSecurity juste pour cela, alors que, comme d'autres l'ont suggéré, il est probable que les réponses seront ignorées pourrait bien être exagéré.

— Barry Pollard
source

2

J'irais avec fail2ban et abandonner les demandes des endroits connus pour abus. Et si vous pensez que le fournisseur de services de l'attaquant n'est pas à blâmer, signalez les attaques à son adresse e-mail d'abus.

Si vous voulez passer du temps à faire quelque chose qui ralentira l'attaquant, vous voudrez peut-être essayer de faire un tarpit . Vous devez d'abord bien sûr savoir d'où viennent les attaques. Ensuite, vous pouvez utiliser apache pour rediriger la demande de l'ip (plage?) Vers un script spécifique. Cela pourrait faire l'affaire, même si je ne l'ai pas essayé moi-même. Ensuite, implémentez simplement un script qui, par exemple, imprime un point (ou quelque chose de / dev / null) toutes les 15 secondes pour garder la connexion de l'attaquant ouverte indéfiniment.

Étant donné que l'attaquant utilise très probablement des scripts pour attaquer votre site, il peut prendre du temps pour remarquer que les attaques sont bloquées, car les connexions sont toutes apparemment actives, il n'y aura pas de délai d'expiration et la demande n'est pas refusée sur le champ.

Le problème est que vous consacrez du temps et des ressources à quelque chose qui ne sera probablement pas aussi utile que la préoccupation la plus importante: sécuriser votre connexion. Il est difficile d'attaquer lorsque vous ne savez pas où attaquer. Considérez certains des éléments suivants:

restreindre l'accès à la page de connexion (uniquement votre intranet? plage ip? vpn? autre?).
ajoutez reCaptcha ou une autre question de vérification pour vous connecter.
utilisez l' authentification multifacteur .
cachez votre page de connexion. Si possible, ne vous y connectez pas depuis votre page principale et n'utilisez pas / login ou un autre emplacement évident.

— Communauté
source

Merci pour l'info! Donc, pour clarifier les choses, A) les deux utilisateurs qui peuvent se connecter ont des mots de passe longs générés de manière aléatoire. B) Il y a une sorte de captcha sur la page de connexion. C) J'essaie de faire fonctionner .htaccess pour empêcher l'accès à cette page. Cependant, il semble que les normes pour .htaccess aient changé plusieurs fois - je vois toujours une syntaxe différente partout et jusqu'à présent, htaccess fonctionne à peine.

— Aurelius

De plus, j'ai signalé toutes les attaques à online.net sans aucune réponse.

— Aurelius

Quelques conseils utiles pour htaccess: stackoverflow.com/questions/6441578/… (je recommande fortement l'authentification Digest).

En regardant les commentaires sur cette page, le résumé ne semble pas être une bonne idée? httpd.apache.org/docs/2.4/mod/mod_auth_digest.html

— Aurelius

1

Vous m'avez bien eu. Oui, je me suis souvenu de l'époque où j'ai utilisé l'authentification Digest et ensuite nous n'avions pas https partout. La raison pour laquelle nous n'utilisons pas de mots de passe htacces est que ce n'est pas une solution à long terme. Vous pouvez l'utiliser pour masquer quelque chose une semaine avant la publication, mais pour une utilisation quotidienne, vous ne voulez pas d'un autre niveau de mots de passe. Ce n'est même pas beaucoup plus sûr. Lorsque la ressource est en place et ne s'affiche pas du tout sur Internet public, nous sommes sur la bonne voie.