Registrar tentativas de login no MySQL

De tempos em tempos, há tentativas fracassadas de login em nosso servidor de produção MySQL (o painel MySQL nos alerta). Existe uma maneira de registrar todos os sucessos e falhas no login no servidor MySQL sem ativar general_log?

Achamos que general_lognão é uma opção porque é um servidor de produção com alta carga.

apenas para informar o curioso: cave no seu log de erros e pronto!

(1) edite my.cnf (documentação de configurações encontrada aqui )

[mysqld]

: #Insira um nome para o arquivo de log de erros. Caso contrário, um nome padrão será usado.

log_error = / var / log / mysql / error

: # padrão para 1. Se o valor for> 1, as conexões abortadas e os erros de acesso negado para novas tentativas de conexão serão gravados no log de erros

log_warnings = 2

...

(2) na execução do comando

$ sudo cat /var/log/mysql/error.err | egrep '[aA] acesso negado'

(3) e você tem!

(4) se você precisar restringir o usuário (tentativa de recuperação de senha de usuário do mysql ou do ataque em um banco de dados multiusuário), então ( http://dev.mysql.com/doc/refman/5.5/en/user-resources.html )

mysql> GRANT USO EM *. * PARA 'atacante' @ 'localhost' COM MAX_CONNECTIONS_PER_HOUR 100;

restringir a apenas 100 tentativas de recuperação de senha por hora.

Acho que o log geral pode registrar todas as tentativas de login (êxito e falha) entre muitas outras coisas. O principal problema é que o log geral afetará o desempenho do seu banco de dados. Você pode ativar o log geral com a consulta

SET GLOBAL general_log = 'on'

para versões mais recentes do MySQL.

Oi eu não acho que é possível.

A partir do mysql 5.1.29 - você pode especificar a opção de armazenamento (tabela ou arquivo) e o local e o log que deseja - erro, consulta geral, binária ou lenta. Tanto quanto eu sei - você não pode especificar o formato do log ou o que é registrado. Posso estar errado - mas acho que todas as tentativas de logon serão registradas no log geral, e não no erro.

No entanto, supondo que o servidor mysql esteja sendo executado em uma máquina separada, a partir do servidor de aplicativos, e você precise da porta 3306 (ou qualquer outra) aberta e que não possa usar o túnel ssh, o servidor mysql ainda não deve ser acessível por ninguém. nulo. Eu recomendo não expô-lo ao tráfego da Web e, se você precisar (como no caso de residir em algum lugar fora do firewall), vinculá-lo ao endereço IP ou ao bloco IP do seu servidor de aplicativos e ao seu acesso de administrador ip (onde você está acessando de)

Espero que ajude.

Pode-se registrar connecte quitcomandar usando o mysql-audit-plugin.

1. Encontre a versão correta no mysql-audit-plugin release , usei o mysql 5.7, então usei audit-plugin-percona-5.7-1.1.7-805-linux-x86_64.zip.
2. realoque o soarquivo baixado para o local indicado por mysqladmin variables | grep plugin_dir.
3. mysql>install plugin audit soname 'libaudit_plugin.so'
4. ativando a função de log,, mysql>set global audit_json_file=ONpor padrão, registra todas as operações bem-sucedidas. configurando set global audit_record_cmds='quit,connect'-o, log apenas conecta e encerra, suponho, de acordo com a configuração do mysql-audit-plugin .

É assim que aparece no arquivo para login e 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 o servidor em questão não tiver conexões externas, conforme configurado, eu ficaria preocupado com algum tipo de ataque ao servidor de aplicativos, a menos que os logons com falha sejam de novos aplicativos sendo lançados antes da configuração do usuário / passe.

se o servidor estiver exposto de alguma forma a conexões externas no 3306, a menos que seja intencional e necessário, eu definiria a configuração como Nick disse e também usaria o iptables para restringir o tráfego para 3306 apenas dos servidores de aplicativos.

Em http://www.mysqlperformanceblog.com/2008/11/07/poor-mans-query-logging/ , o autor mostra um método para capturar os pacotes usando tcpdump e filtrando a saída com base na string.

Isso soluciona suas preocupações com o general_log e o desempenho, embora o tcpdump possa incorrer em uma penalidade de desempenho menor. Essa solução também registrará menos dados que o Registro de consulta geral.

Eu não usei isso sozinho, mas parece muito útil.