web-dev-qa-db-fra.com

Consigner les tentatives de connexion MySQL

De temps en temps, il y a des tentatives de connexion infructueuses dans notre serveur de production MySQL (le tableau de bord MySQL nous alerte). Existe-t-il un moyen de consigner chaque réussite et échec de connexion au serveur MySQL sans activer general_log?

Nous pensons general_log n'est pas une option car c'est un serveur de production avec une charge élevée.

mysqllogginglogin
25
CarlosH

juste pour informer le curieux: Creusez dans votre journal des erreurs et hop!

(1). modifier my.cnf (documentation des paramètres trouvée ici )

[mysqld]

: #Entrez un nom pour le fichier journal des erreurs. Sinon, un nom par défaut sera utilisé.

log_error =/var/log/mysql/error

: #defaults to 1. Si la valeur est> 1, les connexions abandonnées et les erreurs d'accès refusé pour les nouvelles tentatives de connexion sont écrites dans le journal des erreurs

log_warnings = 2

...

(2). lors de l'exécution de la commande

$ Chat Sudo /var/log/mysql/error.err | egrep '[aA] ccess refusé'

(3). et vous l'avez!

(4). si vous devez restreindre l'utilisateur (attaque DOS ou tentative de récupération de mot de passe utilisateur mysql dans une base de données multi-utilisateurs), alors ( http://dev.mysql.com/doc/refman/5.5/en/user-resources .html )

mysql> GRANT USAGE ON *. * À 'attaquant' @ 'localhost' AVEC MAX_CONNECTIONS_PER_HOUR 100;

pour limiter à seulement 100 tentatives de récupération de mot de passe par heure.

20
centurian

Je pense que le journal général peut consigner toutes les tentatives de connexion (succès et échec) entre beaucoup d'autres choses. Le principal problème est que le journal général affectera les performances de votre base de données. Vous pouvez activer le journal général avec la requête

SET GLOBAL general_log = 'on'

pour les nouvelles versions de MySQL.

2
rmc00

Salut, je ne pense pas que ce soit possible.

Depuis mysql 5.1.29 - vous pouvez spécifier l'option de stockage (table ou fichier) et l'emplacement et le journal que vous souhaitez - erreur, requête générale, binaire ou lente. Autant que je sache - vous ne pouvez pas spécifier le format du journal ou ce qui est enregistré. Je peux me tromper - mais je pense que toutes les tentatives de connexion seront enregistrées dans le journal général, et non dans l'erreur.

Cependant, en supposant que votre serveur mysql fonctionne sur une machine distincte, à partir de votre serveur d'application, et que vous avez besoin du port 3306 (ou autre) ouvert et que vous ne pouvez pas utiliser le tunnel ssh, votre serveur mysql ne devrait toujours pas être accessible par quiconque le voudra- nilly. Je recommande fortement de ne pas l'exposer au trafic Web, et si vous devez (comme dans le cas où résider quelque part pas derrière votre pare-feu) le lier à l'adresse IP ou au bloc IP de votre serveur d'applications et à votre IP d'accès administrateur (où vous êtes accès depuis)

J'espère que cela pourra aider.

1
konung

On peut enregistrer la commande connect et quit en utilisant mysql-audit-plugin.

  1. Trouvez la bonne version de version mysql-audit-plugin , j'ai utilisé mysql 5.7, donc j'ai utilisé audit-plugin-percona-5.7-1.1.7-805-linux-x86_64.Zip.
  2. déplacer le fichier so téléchargé à l'emplacement indiqué par mysqladmin variables | grep plugin_dir.
  3. mysql>install plugin audit soname 'libaudit_plugin.so'
  4. activation de la fonction journal, mysql>set global audit_json_file=ON, par défaut, il enregistre toutes les opérations réussies. en définissant set global audit_record_cmds='quit,connect' il se connecte uniquement et se ferme je suppose, selon configuration mysql-audit-plugin .

Voici à quoi cela ressemble dans le fichier pour la connexion et la déconnexion:

{"msg-type":"activity","date":"1543740612328","thread-id":"1015112","query-id":"3045222","user":"root","priv_user":"skip-grants user","ip":"172.28.15.10","Host":"172.28.15.10","connect_attrs":{"_os":"Linux","_client_name":"libmysql","_pid":"11575","_client_version":"5.6.40","_platform":"x86_64","program_name":"mysql"},"cmd":"Quit","query":"Quit"} 

{"msg-type":"activity","date":"1543740724627","thread-id":"1015113","query-id":"0","user":"root","priv_user":"skip-grants user","ip":"172.28.15.10","Host":"172.28.15.10","connect_attrs":{"_os":"Linux","_client_name":"libmysql","_pid":"11863","_client_version":"5.6.40","_platform":"x86_64","program_name":"mysql"},"cmd":"Connect","query":"Connect"}
{"msg-type":"activity","date":"1543740724629","thread-id":"1015113","query-id":"3045223","user":"root","priv_user":"skip-grants user","ip":"172.28.15.10","Host":"172.28.15.10","connect_attrs":{"_os":"Linux","_client_name":"libmysql","_pid":"11863","_client_version":"5.6.40","_platform":"x86_64","program_name":"mysql"},"rows":"1","status":"0","cmd":"select","query":"select @@version_comment limit 1"}
1
Tiina

si le serveur en question ne devrait pas avoir de connexions externes, comme configuré, je serais inquiet à propos d'une sorte d'attaque contre votre serveur d'applications, à moins que les connexions échouées proviennent de nouvelles applications en cours de déploiement avant que l'utilisateur/pass ait été configuré.

si le serveur est en quelque sorte exposé à des connexions externes sur 3306, à moins que cela ne soit intentionnel et nécessaire, je définirais la configuration comme l'a dit Nick, et j'essaierais également d'utiliser iptables pour restreindre le trafic à 3306 uniquement à partir de vos serveurs d'applications.

0
cpbills

À http://www.mysqlperformanceblog.com/2008/11/07/poor-mans-query-logging/ , l'auteur montre une méthode pour capturer les paquets à l'aide de tcpdump et filtrer la sortie en fonction sur le fil.

Cela contourne vos préoccupations concernant le journal général et les performances, bien que tcpdump puisse lui-même encourir une pénalité de performance mineure. Cette solution enregistrera également moins de données que le journal général des requêtes.

Je ne l'ai pas utilisé moi-même, mais cela semble très utile.

0
Stefan Lasiewski