Prevenindo ataques de força bruta no MySQL?


9

Eu preciso ativar a rede para o MySQLd, mas toda vez que o faço, o servidor fica brutalmente forçado ao esquecimento. Algum script médio de adivinhação de senha começa a martelar no servidor, abrindo uma conexão na porta 3306 e tentando senhas aleatórias para sempre.

Como posso impedir que isso aconteça?

Para SSH, eu uso denyhosts, que funciona bem. Existe uma maneira de fazer denyhosts funcionarem com o MySQLd?

Também considerei mudar a porta em que o MySQL está sendo executado, mas isso é menos do que o ideal e é apenas uma solução sem interrupção (e se eles descobrirem a nova porta?)

Alguém tem outras idéias?

Se for diferente, estou executando o MySQL 5.x no FreeBSD 6.x.

Respostas:


9

Não conheço nenhum pacote de software semelhante ao denyhosts para o MySQL, mas tenho algumas soluções:

  • Limite o login a endereços IP específicos. Não use% para permitir que todos os hosts se conectem ao servidor.
  • Ainda mais seguro, configure o iptables para permitir apenas o acesso ao 3306 a partir de endereços IP autorizados.
  • Canalize seu tráfego para a caixa com ssh e conecte-se via localhost
  • Modifique os scripts Denyhosts ou BFD para analisar os logs de acesso mysql e bloquear qualquer tentativa de força bruta no firewall

Editar :

Para responder seu comentário, tente o seguinte :

iptables -A INPUT -p tcp -s 202.54.1.50 --sport 1024:65535 -d 202.54.1.20 --dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s 202.54.1.20 --sport 3306 -d 202.54.1.50 --dport 1024

Onde .20 é o seu MySQL e .50 é o endereço IP de conexão remota.


Algumas notas: Como posso restringir o acesso à porta 3306 a apenas um determinado conjunto de endereços IP? Apenas restringir os usuários do MySQL não funciona, pois as máquinas remotas ainda podem se conectar e fazer força bruta para senhas. Os túneis SSH parecem um pouco inconvenientes para serem configurados para o usuário final ... Você tem um exemplo do IPTables para fazer isso?
Keith Palmer Jr.

2

1: Altere a porta de 3306. Não por motivos de melhor segurança, mas para carregar o servidor para lidar com ataques de login falso

2: Crie um certificado SSL e ative-o no seu servidor MySQL (é necessário criptografar sua conexão cliente-servidor de qualquer maneira)

3: Crie um ou mais certificados de cliente (todos os clientes precisam ter o certificado e o software-cliente precisa ser configurado para usá-lo). Se seus clientes forem .Net, será necessário converter o certificado do cliente no formato pkcs12, mas isso é fácil, consulte este guia.

4: Defina as contas de usuário do MySQL para exigir o certificado de cliente x509; então, um invasor precisará das credenciais de login E do certificado do cliente (você pode até colocar uma senha no certificado do cliente e, em seguida, o invasor também precisará disso).

Usei este guia para criar os certificados e os arquivos de chave, mas existem muitos guias por aí.

Prefiro usar apenas minha conexão SSH para acessar minha caixa Linux para fins de administração, não para acesso de clientes.


Obrigado pela resposta. Usei este guia para fazer os nºs
ofri cofri

1

Usando o MySQL Proxy, você pode escrever um pequeno script LUA que leva uma combinação de usuário / passagem, mas espera X segundos para processar o logon se a solicitação de conexão vier de um intervalo de IP não aprovado.

Além disso, você pode adicionar um pouco de lógica extra ao script LUA nos intervalos de IP da lista negra após três tentativas falhas.

No fim das contas, é tecnicamente viável, mas vou com as outras recomendações para fazer o túnel via SSH ou VPN para um intervalo de IP comum, na lista de permissões (via FW ou outros meios).


+1 ainda um outro uso para MySQL Proxy :)
Andy

0

por que não permitir acesso à porta mysqld apenas de hosts seguros?


Eu considerei isso, mas isso significa que eu teria que monitorar alterações de endereço IP para mais de 1.000 clientes. Isso seria uma dor gigantesca na bunda ... Como posso fazer isso de qualquer maneira? Não ajuda para bloqueá-los para fora dentro de MySQL, porque eles ainda podem se conectar ao servidor MySQL, só não realmente escolher qualquer banco de dados ...
Keith Palmer Jr.

1
citando dave drager acima: "Modificar os scripts denyhosts ou BFD para analisar logs de acesso mysql e bloquear qualquer tentativa de força bruta no firewall" parece ser a melhor idéia ou usar algumas senhas hierogliphic :)
quaie

0

Embora essa não seja uma resposta "real" - não sei por que você precisa expô-la diretamente ao mundo exterior.

Você não pode ativar o ssh nessa caixa e usar o tunelamento para acessar o mecanismo db?

Ou qualquer outra solução VPN para acessá-lo (openvpn vem à mente).


0

Não é uma solução real para o problema, mas pode ajudar se você apenas executar o servidor em uma porta diferente. A maioria desses bots de varredura provavelmente está programada para verificar apenas 3306. Isso não resolverá o problema, mas você provavelmente obterá muito menos varreduras apenas mudando a porta.


-1 para segurança por obscuridade
thepocketwade 23/09/09

@thepocketwade - É por isso que eu disse que não é uma solução real para o problema. Mas ainda pode ser útil.
Eric Petroelje

0

Acredito que as conexões devem ser protegidas por firewall: rápido e agradável. Há muitos tutoriais para o iptables e o que for :)

Além disso, você pode instalar um cronjob nos hosts dos clientes que executarão o smth em um servidor para impedir que o firewall bloqueie os hosts conhecidos.


0

Usar o ssh para túneis seria o melhor, mas você pode tentar usar o fail2ban em vez de denyhosts, porque eu acho que ele visa monitorar aplicativos mais diferentes, portanto não deve ser um problema adicionar o log do mysql.


0

Sugestão a considerar na sua seção my.cnf-ini [mysqld]

max_connect_errors=10  # to limit hacker/cracker attempts to guess a password.

para evitar as centenas de tentativas em 90 segundos. Pique-os em 10 tentativas.

Considere, uma vez por dia, o FLUSH HOSTS para limpar as pessoas legítimas que tentam usar o seu sistema que NÃO PODEM Lembrar sua senha. Talvez daqui a alguns dias eles consigam.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.