Comment puis-je bloquer les tentatives de piratage ciblant phpMyAdmin?
Mon site Web reçoit chaque jour des milliers de visites de différentes adresses IP essayant d'accéder à:
/php-myadmin/
/myadmin/
/mysql/
... et des milliers d'autres variantes. Aucun de ces répertoires n'existe, je n'ai même pas de phpmyadmin sur mon serveur.
Je ne pense pas que l'une de ces tentatives ait réussi, mais elles doivent faire des ravages sur les ressources du serveur et gaspiller la bande passante, donc je voudrais 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 de les empêcher de manière plus permanente?
Ne t'en fais pas. Servir un 404 est un travail minuscule, minuscule, minime pour un serveur Web. Vous pourriez probablement servir dix 404 par seconde en utilisant un 486. La bande passante par 404 est négligeable; une minuscule requête GET et une minuscule réponse 404.
Sérieusement; ne t'en fais pas. Ce n'est qu'une partie intégrante de l'exécution d'un serveur sur Internet.
Malheureusement pour vous, c'est ainsi que fonctionne Internet. N'y faites pas attention. Des milliers de robots/chevaux de Troie analysent Internet. L'IP source sera toujours aléatoire. Il n'y a pas de remède.
La seule solution à 100% pour éliminer ce trafic est illustrée ci-dessous: 
Une alternative est:
- pour passer avec https/http du port 80/443 à autre chose. Les bots 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 ce n'est pas possible si vous hébergez un site Web public).
Ce que vous voulez c'est Fail2ban (en supposant que c'est une machine Linux, vous n'avez pas dit ...)
Qu'est-ce que Fail2ban?
Fail2ban analysera les journaux système, recherchant des expressions régulières particulières à bloquer. Lorsqu'il trouve une correspondance (ou plusieurs correspondances à partir de la même IP, selon la façon dont vous le configurez), il se bloque, généralement via IPTables. Généralement, ceci est utilisé pour bloquer les tentatives d'authentification échouées contre SSH ou les serveurs Web.
Vous le configurez pour les interdire pendant une durée définie (peut être des minutes, des jours ... dépend de leur persistance), après quoi l'interdiction expirera, à moins qu'ils ne réessayent.
Comment cela aide-t-il à bloquer les robots d'analyse phpmyadmin?
Il peut tout aussi bien être utilisé pour faire correspondre les signes courants d'une attaque, comme essayer d'accéder à des dossiers phpmyadmin inexistants. Vous devrez trouver l'expression régulière correcte pour correspondre à de telles tentatives et vous assurer de ne pas bloquer les utilisateurs légitimes.
La configuration donnée dans ce billet 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é - les chances sont que s'ils recherchent des vulnérabilités phpmyadmin, ils peuvent également essayer d'autres services pour des vulnérabilités, jusqu'à ce qu'ils atteignent quelque chose qui fonctionne. Les interdire fera abandonner la plupart des bots/scripts après un certain temps, et ils passeront à de meilleures cibles.
Même à travers les analyses ne coûtent pas cher (à moins qu'elles ne découvrent une vulnérabilité), elles inondent vos journaux, ce qui rend plus difficile la détection des attaques et des problèmes réussis avec votre serveur Web.
Comme l'indique 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 de problème de performance que je pourrais attribuer à Fail2ban. J'ai cependant eu des problèmes de performances à partir de scripts très agressifs essayant de forcer les mots de passe ou de lancer 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 de 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.Au lieu de les interdire dans IPtables, vous pouvez éventuellement le faire interdire dans un pare-feu matériel ou envoyer un e-mail à quelqu'un si la même personne essaie toujours de vous attaquer afin que vous puissiez vous plaindre à leur FAI ou demandez à votre centre de données de les bloquer sur leurs pare-feu.
D'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, c'est de mettre un petit script dans le répertoire approprié, donc il s'exécute si quelqu'un accède à/phpmyadmin /. Ce script ne fait rien d'autre qu'invoquer iptables (sous Linux), qui bloque l'adresse IP accédant au script pendant 30 minutes (après quoi un cron-job vide 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 syslog/access-log. L'inconvénient, bien sûr, est que vous ne vérifiez rien d'autre que d'accéder à cette adresse très spécifique.
Pourquoi est-ce que je fais ça? Bien sûr, servir un 404 serait facile pour le serveur, mais je ne veux pas qu'ils fouinent, aussi simple que cela. Je veux perdre le temps de leur outil, attendre que le serveur réponde, réessayer jusqu'à ce qu'il abandonne finalement. De plus, si vous ne les bloquez pas, ils essaieront beaucoup d'URL différentes avant de passer enfin - parfois plus d'un millier. Selon l'outil, il peut être "agréable" et les espacer sur quelques heures, ou il peut ne pas se soucier et marteler votre serveur avec tous en quelques minutes.
Pourquoi je ne diffuse pas une page valide? Leur outil peut arrêter de vous scanner et alerter le skiddie qui l'exécute - qui doit ensuite vérifier manuellement. Le revers de la médaille est qu'ils donneront à votre serveur un aspect beaucoup plus proche qu'ils ne l'auraient fait, si leur analyse ne vous faisait pas apparaître dans leurs résultats. Peut-être qu'ils vont fouiner un peu plus, peut-être quelques scans de ports, peut-être les rendre fous, 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 expirer le serveur au moment où ils accèdent au script phpmyadmin - est une perte de temps efficace pour 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 de mot de passe de votre serveur Web (.htpasswd pour Apache) pour bloquer l'accès avant que quoi que ce soit ne l'atteigne.
FWIW nous limitons l'accès à/phpmyadmin/aux adresses IP sur liste blanche uniquement.
Nous utilisons également mod_evasive (sur Apache2) pour dissuader les attaques scriptées DOS/mal comportées.
lier l'outil d'administration mysql à l'adresse de bouclage de votre machine 127.0.0.1
puis utilisez ssh avec redirection de port pour accéder à votre back-end administrateur.
ajouter une couche de sécurité supplémentaire qui peut être assez transparente.