Comment puis-je bloquer les tentatives de piratage visant phpMyAdmin?

Mon site Web reçoit quotidiennement des milliers de visites de différentes adresses IP:

/php-myadmin/
/myadmin/
/mysql/

... et des milliers d'autres variations. Aucun de ces répertoires n'existe, je n'ai même pas phpmyadmin sur mon serveur.

Je pense qu'aucune de ces tentatives n'a abouti. Toutefois, ils doivent peser lourdement sur les ressources du serveur et gaspiller de la bande passante. Je souhaiterais donc les arrêter si possible. J'ai bloqué une poignée de ces adresses IP, mais elles reviennent sans cesse avec de nouvelles adresses IP. Existe-t-il un moyen d'éviter ce problème de manière plus permanente?

Ne t'inquiète pas pour ça. Servir un 404 est un travail minuscule pour un serveur Web. Vous pourriez probablement desservir dix 404 par seconde en utilisant un 486. La bande passante par 404 est négligeable; une petite requête GET et une minuscule réponse 404.

Sérieusement; ne t'inquiète pas pour ça. Cela fait partie intégrante de l’exécution d’un serveur sur Internet.

Malheureusement pour vous, voici comment Internet fonctionne. N'y faites pas attention. Des milliers de robots / chevaux de Troie scannent Internet. L'IP source sera toujours aléatoire. Il n'y a pas de cure.

La seule solution à 100% pour éliminer ce trafic est illustrée ci-dessous:

Une alternative consiste à:
- passer avec https / http du port 80/443 à autre chose. Les robots ne recherchent généralement pas de serveur http sur tous les autres ports 65k.
- utilisez un VPN pour vous connecter au serveur (je suppose que cela n’est pas possible si vous hébergez un site Web public).

Ce que vous voulez, c'est Fail2ban (en supposant qu'il s'agisse d'une machine linux, vous n'avez pas dit ...)

Qu'est-ce que Fail2ban?

Fail2ban analysera les journaux système pour rechercher les expressions régulières à bloquer. Lorsqu'il trouve une correspondance (ou plusieurs correspondances provenant de la même adresse IP, selon la manière dont vous l'avez configurée), il se bloque, généralement via IPTables. Généralement, cette option est utilisée pour bloquer les tentatives d’authentification ayant échoué contre SSH ou des serveurs Web.

Vous le configurez pour les interdire pendant un certain temps (il peut s'agir de minutes, de jours ... dépend de leur persistance), après quoi l'interdiction expirera, à moins qu'ils n'essayent à nouveau.

Comment cela aide-t-il à bloquer les robots d'analyse de phpmyadmin?

Il peut tout aussi bien être utilisé pour faire correspondre les signes courants d’une attaque, comme tenter d’accéder à des dossiers phpmyadmin non existants. Vous devrez trouver la bonne expression régulière pour correspondre à de telles tentatives et vous assurer de ne pas bloquer les utilisateurs légitimes.

La configuration donnée dans cet article de blog peut fonctionner verbatium ou nécessiter quelques ajustements pour votre configuration.

Pourquoi devrais-je les bloquer? Les erreurs 404 ne coûtent pas cher

Les bloquer dans iptables a une certaine utilité - s'ils vérifient les vulnérabilités de phpmyadmin, il est probable qu'ils essaieront également d'autres services pour les vulnérabilités, jusqu'à ce qu'ils rencontrent quelque chose qui fonctionne. Si vous les bannissez, la plupart des scripts / scripts abandonneront après un certain temps et ils passeront à de meilleures cibles.

Même si les analyses ne coûtent pas cher (sauf si elles trouvent réellement une vulnérabilité), elles inondent vos journaux, ce qui rend plus difficile la détection d'attaques réussies et de problèmes avec votre serveur Web.

Comme le dit le commentaire ci-dessous, Fail2ban nécessite certaines ressources système. Mais pas beaucoup. À tout le moins, je peux dire que je n’ai jamais eu un problème de performance que je pourrais attribuer à Fail2ban. J'ai toutefois eu des problèmes de performances avec des scripts très agressifs qui essayaient de forcer brutalement les mots de passe ou qui lançaient des milliers de tentatives d'injection SQL et d'autres exploits par seconde sur mon serveur. Les bloquer au niveau du pare-feu nécessite FAR moins de ressources que les bloquer au niveau du serveur / de l'application. Il peut également être étendu pour exécuter des scripts personnalisés pour interdire les adresses IP. Ainsi, au lieu de les interdire dans IPtables, vous pouvez éventuellement les interdire dans un pare-feu matériel ou envoyer un e-mail à quelqu'un si la même personne continue de vous attaquer pour pouvoir vous plaindre. auprès de votre fournisseur de services Internet ou demandez à votre centre de données de les bloquer sur leur pare-feu.

Des autres conseils?

Il est FORTEMENT RECOMMANDÉ de mettre en liste blanche quelques adresses IP que vous contrôlez afin de ne pas vous verrouiller accidentellement.

Ce que je fais est de mettre un petit script dans le répertoire approprié, de sorte qu'il s'exécute si quelqu'un accède à / phpmyadmin /. Ce script ne fait rien d'autre qu'appeler iptables (sous Linux), qui bloque l'adresse IP qui accède au script pendant 30 minutes (après quoi une tâche cron efface la chaîne iptables à laquelle l'adresse IP est ajoutée).

L'avantage par rapport à fail2ban est que vous n'utilisez aucune ressource pour analyser le journal syslog / access-log. L’inconvénient, bien sûr, est que vous ne vérifiez rien d’autre, si ce n’est accéder à cette adresse très spécifique.

Pourquoi je fais ça? Bien sûr, servir un serveur 404 serait facile pour le serveur, mais je ne veux pas qu’ils fouillent, aussi simple que cela. Je veux perdre le temps de leur outil en attendant que le serveur réponde, en essayant de relancer jusqu'à ce qu'il abandonne. En outre, si vous ne les bloquez pas, ils essaieront de nombreuses URL différentes avant de passer à autre chose - parfois plus de mille. En fonction de l'outil, il peut être "sympa" et les espacer de quelques heures, ou ne pas s'en soucier et écraser votre serveur en quelques minutes.

Pourquoi ne sers-je pas une page valide? Leur outil peut arrêter de vous scanner et alerter le skiddie qui l’exécute - qui doit alors vérifier le fichier manuellement. Le revers de la médaille est qu’ils donneront à votre serveur un aspect beaucoup plus attentif qu’ils ne l’auraient fait, si leur analyse ne vous faisait pas apparaître les résultats. Peut-être vont-ils en fouiller un peu plus, peut-être quelques analyses de ports, peut-être vous les énervez, et ils lancent un DoS pour voir s’ils peuvent faire quelque chose. Le simple fait de les bloquer (ce qui, de leur point de vue, fait que le serveur expire au moment où ils accèdent au script phpmyadmin), est un gaspillage efficace du temps de leur outil, tout en évitant toute attention indésirable.

Si vous avez phpMyAdmin sur le serveur, une solution efficace peut être de le placer dans un répertoire séparé et d'utiliser le contrôle des mots de passe de votre serveur Web (.htpasswd pour Apache) pour bloquer l'accès avant même que quoi que ce soit ne l'atteigne.

FWIW, nous limitons l’accès à / phpmyadmin / aux adresses IP de la liste blanche uniquement.

Nous utilisons également mod_evasive (sur apache2) pour dissuader les attaques par script sous DOS / mal conduites.

lier l'outil d'administration mysql à l'adresse de votre machine 127.0.0.1

Ensuite, utilisez ssh avec la redirection de port pour accéder à votre back-office admin.

ajoutez une couche de sécurité supplémentaire qui peut être assez transparente.

Le meilleur moyen que nous ayons trouvé est de protéger par mot de passe le dossier dans lequel phpmyadmin se trouve. En outre, n'utilisez rien qui soit en relation avec phpmyadmin en tant que nom de dossier: pma, phpm, etc ...