Voici une liste de contrôle rapide pour activer les connexions à distance pour MySQL, mais lisez d'abord (6). Si j'ai oublié quelque chose, n'hésitez pas à le modifier.
1) Votre utilisateur distant se connecte via un compte qui a été créé avec le user,host approprié entrées (regardez la sortie de select user,host from mysql.user order by 1,2 ). Sinon, regardez dans le CREATE USER
et/ou GRANT
commandes. Examinez la sortie de SHOW GRANTS
pour l'utilisateur.
2) Vous avez fait flush privileges;
(Certains disent que c'est inutile, d'autres disent que oui).
3a) Localisez votre fichier de configuration mysql référencé dans 3b) ci-dessous en examinant les informations dans Ce document
(ou pour Windows, probablement dans C:\ProgramData\MySQL\MySQL Server 5.NNN chemin). Cela varie selon la distribution pour Linux.
3b) Vous avez modifié et enregistré my.ini (Windows) ou my.cnf (Linux) et modification de bind-address loin de 127.0.0.1 ou localhost , en faveur de 0.0.0.0 . Et vous avez créé et Remplacez la ligne suivante :#skip-networking . Cela ressemblera à ceci :
[mysqld]
bind-address=0.0.0.0
#skip-networking
4) Redémarrez le démon mysql. La façon dont on procède varie selon la distribution.
5) Problèmes de pare-feu. Assurez-vous que le port, par défaut étant 3306 , est ouvert sur le monde extérieur (qui peut en fait n'être que votre intranet). Cela inclut toutes les autres couches de pare-feu, telles que les groupes de sécurité AWS EC2 ou similaires, le cas échéant.
6) Comprenez qu'il existe un risque de sécurité associé à cela. À moins que vous ne sachiez comment exposer votre serveur mysql à des connexions distantes, n'effectuez pas cette opération.
7) Veuillez effectuer des évaluations de sécurité fréquentes avec select déclaration répertoriée dans 1. ci-dessus, y compris l'examen des SHOW GRANTS pour ces utilisateurs. Ne sur-accordez pas inutilement des utilisateurs avec des caractères génériques. Donnez plutôt aux utilisateurs les privilèges minimaux pour qu'ils puissent faire leur travail.
8) Examinez fréquemment les tentatives de connexion échouées via le journal général et le journal des erreurs, comme brièvement présenté ci-dessous.
Pour les appels entrants, vous pouvez consulter le journal général des requêtes.
select @@general_log; -- a 1 indicates it is turned on for capture
select @@general_log_file; -- the file that it logs to
Ainsi, toutes les requêtes peuvent être connecté au journal général des requêtes
si le paramètre est activé. Examinez le journal pour "connecter", mais surtout pour Access denied for user pour voir les tentatives infructueuses. Faites-le régulièrement (pas toutes les quelques années). Je le fais au moins deux fois par jour. Notez que vous pouvez évidemment automatiser le reporting via un programme externe. Le monde extérieur va battre votre serveur pour entrer comme l'image ci-dessous. C'est une réalité; préparez-vous.
Consultez la page de manuel pour Le journal des erreurs également, en notant les niveaux d'avertissement et les paramètres de verbosité en fonction de votre version.
Je recommanderais de créer une copie de sauvegarde par date (nommée comme telle) et de supprimer les fichiers journaux après la sauvegarde pour recommencer à zéro après la sauvegarde. Les fichiers journaux peuvent rapidement grossir, en particulier le journal général. N'oubliez pas si vous avez activé ou non le paramètre de journalisation.
Vous pouvez utiliser les deux journaux pour déterminer si votre tentative de connexion a dépassé le pare-feu au cours des étapes ici.
