Registra i tentativi di accesso a MySQL

Di tanto in tanto ci sono tentativi di accesso falliti nel nostro server di produzione MySQL (la dashboard di MySQL ci avvisa). Esiste un modo per registrare ogni singolo successo e accesso non riuscito al server MySQL senza abilitare general_log?

Pensiamo che general_lognon sia un'opzione perché è un server di produzione con un carico elevato.

solo per informare il curioso: scavare nel registro degli errori e presto!

(1). modifica my.cnf (documentazione delle impostazioni disponibile qui )

[Mysqld]

: #Immettere un nome per il file di registro degli errori. Altrimenti verrà utilizzato un nome predefinito.

log_error = / var / log / mysql / error

: #defaults a 1. Se il valore è> 1, le connessioni interrotte e gli errori di accesso negato per i nuovi tentativi di connessione vengono scritti nel registro errori

log_warnings = 2

...

(2). a comando eseguito

$ sudo cat /var/log/mysql/error.err | egrep "[aA] ccess denied"

(3). e ce l'hai!

(4). se è necessario limitare l'utente (dos attack o tentativo di recupero password utente mysql in un database multiutente), quindi ( http://dev.mysql.com/doc/refman/5.5/en/user-resources.html )

mysql> UTILIZZO GRANT ON *. * TO 'attacker' @ 'localhost' WITH MAX_CONNECTIONS_PER_HOUR 100;

limitare a soli 100 tentativi di recupero password all'ora.

Penso che il registro generale potrebbe registrare tutti i tentativi di accesso (esito positivo e negativo) tra molte altre cose. Il problema principale è che il registro generale influirà sulle prestazioni del database. È possibile attivare il registro generale con la query

SET GLOBAL general_log = 'on'

per le versioni più recenti di MySQL.

Ciao, non credo sia possibile.

A partire da mysql 5.1.29, è possibile specificare l'opzione di archiviazione (tabella o file), la posizione e il registro desiderato: errore, query generale, binaria o lenta. Per quanto ne so, non è possibile specificare il formato del registro o ciò che viene registrato. Potrei sbagliarmi, ma penso che tutti i tentativi di accesso verranno registrati nel registro generale e non in quello di errore.

Tuttavia, supponendo che il tuo server mysql sia in esecuzione su una macchina separata, dal tuo server appliciton, e hai bisogno della porta 3306 (o qualunque altra cosa) aperta e non puoi usare il tunnel ssh, il tuo server mysql non dovrebbe essere accessibile da nessuno nilly. Consiglio vivamente di non esporlo al traffico web e se è necessario (come nel caso in cui risieda da qualche parte non dietro il firewall) associarlo all'indirizzo IP o al blocco IP del proprio server delle applicazioni e al proprio IP di accesso all'amministratore (dove ci si trova accedendo da)

Spero che sia d'aiuto.

Si può accedere connecte quitcomandare usando mysql-audit-plugin.

1. Trova la versione giusta dalla versione mysql-audit-plugin , ho usato mysql 5.7, quindi ho usato audit-plugin-percona-5.7-1.1.7-805-linux-x86_64.zip.
2. riposizionare il sofile scaricato nel luogo indicato da mysqladmin variables | grep plugin_dir.
3. mysql>install plugin audit soname 'libaudit_plugin.so'
4. attivando la funzione log mysql>set global audit_json_file=ON, per impostazione predefinita registra tutte le operazioni riuscite. impostandolo set global audit_record_cmds='quit,connect'registra solo la connessione e la chiusura suppongo, secondo la configurazione di mysql-audit-plugin .

Ecco come appare nel file per il login e il logout:

{"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"}

se il server in questione non dovrebbe avere connessioni esterne, come configurato, sarei preoccupato per una sorta di attacco contro il tuo server di app, a meno che gli accessi non riusciti provengano da nuove applicazioni che vengono lanciate prima che l'utente / pass siano stati configurati.

se il server è in qualche modo esposto a connessioni esterne su 3306, a meno che ciò non sia intenzionale e necessario, imposterei la configurazione come ha detto Nick, e guarderei anche usando iptables per limitare il traffico a 3306 solo dai tuoi server di app.

A http://www.mysqlperformanceblog.com/2008/11/07/poor-mans-query-logging/ , l'autore mostra un metodo per acquisire i pacchetti utilizzando tcpdump e filtrando l'output in base alla stringa.

Ciò aggira le tue preoccupazioni in merito a general_log e alle prestazioni, sebbene tcpdump stesso possa incorrere in una penalità minore per le prestazioni. Questa soluzione registrerà anche meno dati del registro delle query generali.

Non l'ho usato da solo, ma sembra molto utile.