Qual é a melhor estratégia para detectar invasões de banco de dados?

Question

As intrusões do sistema de arquivos podem ser detectadas usando ferramentas como o Snort, mas é mais difícil detectar intrusões em um banco de dados, como exclusão de linhas, modificação de tabelas etc. Qual é a melhor maneira de monitorar isso para detectar alterações indesejadas? o DB?

Estou usando o MySQL para que qualquer coisa que não seja independente de banco de dados seja idealmente voltada para o MySQL.

    

Answer 1

Depende de como você se conecta ao seu banco de dados. Se você estiver usando um aplicativo da Web, o Snort (e outros NIDS) poderá detectar injeções de SQL e outros ataques que acontecem por HTTP.

O problema é que, se você estiver usando SSL ou conexões criptografadas com seu banco de dados, seus NIDS ficarão cegos para o tráfego.

É por isso que a análise de log é muito importante. A única maneira de o seu banco de dados falar com você é através dos logs e muitos DBAs não estão familiarizados com ele. Eu realmente não entendo porque todo mundo aceita web log como familiar, mas negligenciam logging de db (eu vou reclamar mais sobre isso em outra ocasião).

Para ativar o log do mysql: link

Eu também uso o OSSEC de código aberto para monitorar meus logs do MySQL e ele funciona muito bem.

    

Answer 2

Eu não uso o MySQL, então não posso falar com nenhum recurso específico da plataforma.

Parece que você quer uma trilha de auditoria de algum tipo. Falando em um sentido geral do RDBMS, você pode usar gatilhos para obter algumas das funcionalidades que está procurando. Eu não acho que você vai ter uma trilha de auditoria de modificação de esquema a menos que o MySQL represente o esquema como tabelas que podem, por sua vez, ter gatilhos colocados nelas.

Naturalmente, tudo o que dispara bobagens é discutível se alguém obtiver acesso "root" ao banco de dados e apenas desconectar os gatilhos antes que eles iniciem o monkeying com os dados. Nesse ponto, todas as apostas estão desativadas. (... e isso nem sequer começa a lidar com alguém que está obtendo acesso de nível "raiz" ao sistema operacional que hospeda o banco de dados ... manipulação de nível de byte dos arquivos de banco de dados, montando-os em uma instância de banco de dados que teve segurança características "hackeadas", etc. smile )

    

Answer 3

Se você realmente quiser acompanhar todas as mudanças em suas tabelas, você terá que fazer algo louco, como ativar o log de consultas do MySQL e procurar por coisas ruins usando algo como o Simple Event Correlator. Não faça isso, porque vai matar o desempenho do seu servidor.

Honestamente, sua melhor aposta é evitar alterações indesejadas, em primeiro lugar, usando as permissões do MySQL.

    

Answer 4

O Snort ainda pode ser útil. O problema é saber de onde o tráfego do banco de dados deve vir. Se vier de uma fonte diferente da que é aprovada, você pode bloqueá-la, obviamente, dentro do MySQL. No entanto, você também pode configurar alertas no seu IDS para ver esse tipo de coisa.

Com relação a um ataque proveniente de um endereço IP autorizado, isso é um desafio. A questão chave é o que uma conexão deve ser permitida e o que não deveria? E isso volta a definir as permissões corretamente. Se um usuário legítimo se conecta de um IP legítimo e precisa de permissões DELETE e deseja ser malicioso, não há muito o que fazer sobre isso durante a modificação real. Uma sugestão foi dada para auditoria, mas isso prejudica seu desempenho. Não tenho certeza se você tem um controle efetivo se os usuários puderem acessar diretamente o banco de dados e fazer alterações. Todas as plataformas de banco de dados, não apenas o MySQL, lutam com isso. Você tem um usuário confiável fazendo uma alteração autorizada. Há tanta coisa que você pode fazer.

    

Answer 5

Existem produtos comerciais projetados para isso. Eu acho que nós olhamos para o DbProtect (www.appsecinc.com) e foi um grande investimento para implementar, mas acabamos não fazendo isso. Eu também vi o Guardium (www.guardium.com). Ambos afirmam apoiar alguma versão do MySQL.

    

Answer 6

O SQL Server 2005 introduziu gatilhos DDL, que podem ser disparados sempre que alguém executar um código de Linguagem de Definição de Dados, como alterar uma tabela, adicionar um índice ou eliminar uma exibição.

    

Answer 7

Eu não acredito que existam métodos adequados para fazer isso no MySQL. Você deve se certificar de que uma soma de verificação de segurança das classificações seja aplicada a todas as modificações legítimas, usando uma chave secreta de algum tipo, portanto, se os dados da linha diferirem da soma de verificação, você sabe que uma modificação não autorizada foi feita.

Quanto ao seu checksum, e como você mantém a chave em segredo, essa é uma história completamente diferente, da qual você pode se sentir livre para me enviar um e-mail, se você descobrir através deste site (sou novo aqui e não configurado corretamente ainda).

Realisticamente, apenas os backups off-site irão ajudá-lo a se proteger contra a exclusão de linhas, e observe que o uso do mysqldump é o único método 'oficialmente' suportado para fazer isso.

Embora copiar os arquivos subjacentes (MyISAM) funcionem na grande maioria dos casos para esse tipo de tabela, ele cai de vez em quando, então eu não confiaria nele sozinho para qualquer missão crítica.

    

Answer 8

Implementamos o DbProtect em um banco de dados do SQL Server. Não foi muito difícil e permitiu algumas políticas bem granulares para auditoria. No entanto, como mencionado por bobwood, não é barato.