none
Registros do Banco estão Desaparecendo RRS feed

  • Pergunta

  • Olá Pessoal, 

    Estou passando por um problema que estou ficando sem opções.

    Recentemente, sumiram os registros do banco de várias tabelas. A princípio, acreditamos ser uma invasão de algum hacker, e realmente achamos várias falhas de páginas que aceitam SQL Inject. Nisso tomamos várias providências:

    - URLScan
    - Acesso restrito por IP
    - Tirei a permissão de DELETE, CREATE, do usuário do SQL Server que usamos na aplicação
    - Criei uma Trigger na tabela, usando INSTEAD OF DELETE, para além de não deixar apagar, ele registra quem tentou apagar.

    Enfim, eu faço os testes e funciona tudo certinho. Dá acesso negado, porém se deleto o registro por outra coisa ele registra o LOG, perfeito.

    Aí essa noite, sumiu os registros novamente, de madrugada, sem deixar rastros. Nenhum LOG no SQL Server, nenhum LOG no IIS, nada!!!

    Alguém faz idéia do que pode estar acontecendo?

    Estou suspeitando já que é problema no SQL Server, sei la !!


    Fabio A. Morais

    quinta-feira, 7 de março de 2013 05:53

Respostas

  • Fábio, bom dia.

    Para minimizar a perda de dados primeiramente coloque a sua base para recovery model para "FULL". Faça um backup full da sua base e no final do dia faça backups de logs. Isto fará com que a perda de dados seja reduzida.

    Sem avisar ninguém, deixe rodando o SQL trace por alguns dias para capturar todos os eventos T-SQL. É um pouco pesado, dependendo da carga de trabalho em seu servidor, mas é uma maneira de capturar se alguém ou processo está executando comandos que não deveriam.

    Abs.


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp

    • Marcado como Resposta Fabio A. Morais sexta-feira, 8 de março de 2013 13:56
    quinta-feira, 7 de março de 2013 13:03

Todas as Respostas

  • Fabio, bom dia ! qual a versão do sql que voce esta utilizando ? Não creio que isto seja um problema do proprio SQL deletar registros sem mais nem menos.

    Os registros costumam sumir sempre no mesmo horario ? quantas pessoas tem permissão alem de leitura na base que esta sumindo dados ? Muitas vezes pode ser até alguem de dentro fazendo isto ou até alguem que saiu da empresa que antes de sair deixou no meio de alguma proc algo assim, de uma olhada nos jobs que rodam durante a madrugada e vasculhe se ha algo relacionado, outra coisa é mudar algumas senhas, como a senha de SA, a senha utilizada na aplicação e outras que não são de uso pessoal.

    De uma olhada tambem em SQL Audit para fazer uma auditoria em cima destas tabelas, mas quanto menos pessoas na sua propria empresa souberem do sql audit melhor.


    Alexandre Matayosi Conde Mauricio. Se esta sugestão for útil, por favor, classifique-a como útil. Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    quinta-feira, 7 de março de 2013 11:07
  • Olá Alexandre,

    Estamos usando o SQL Server 2008 R2, instalado no Windows Server 2008 R2, ambos versão Standard.

    Isso já ocorreu 5 vezes, em dias e horários variados.

    A primeira vez que isso ocorreu, alteramos todas as senhas (inclusive do sa) por senhas mais complexas. E todas as senhas usadas em aplicações Web, tirei a permissão de DELETE.

    E embora o banco de dados tenha várias databases, o problema ocorre com um único banco e apenas em 4 tabelas específicas, sempre.

    E o que mais me intriga, se entro no computador, com a senha administrativa e tento excluir um registro via SQL ( DELETE FROM tabela ...), além do SQL Server não permitir, ele registra LOG por tudo quanto é lado.

    Assim como pode, sumir os registros da tabela, sem deixar LOG em parte alguma?

    Se o usuário fez uma rotina para excluir os LOGS, isso seria fácil ao ver o intervalo do PK da tabela de LOG, mas isso também não existe. Além do mais, o IIS também registra os Log de acesso. Se for um SQL Inject, ou algo parecido, teria ainda outros LOGs.

    Quanto a senha de acesso, só eu e mais uma pessoa na empresa que tem acesso.

    O Audit não tem na versão Stantard, assim eu fiz uma Trigger para fazer o Audit manualmente, e mesmo assim, não registrou nenhuma ação.


    Fabio A. Morais

    quinta-feira, 7 de março de 2013 12:32
  • Bom dia Fabio! Tudo tranquilo?

    Vamos lá: tive alguns casos desse no passado. O que foi checado:

    > Existe algum job de backup ou sincronismo com outra tabela/banco? O próprio job poderia estar "resetando" sua tabela. Entretanto você disse que não tem nenhum log, o que é estranho
    > Quem mais tem acesso ao servidor?
    > Você implementou segurança somente no banco SQL ou também no Windows Server aonde está hospedada? Já tive casos de ferramentas de backup retornando arquivos "originais", o que consequentemente zerava o banco. Ou alguém parando o serviço do SQL e substituindo o arquivo do banco.
    > Troque a senha de SA urgente e implante o SQL Audit como nosso amigo Alexandre recomendou.

    Abraços!

    Felipo Gonçalves
    Microsoft Contingent Staff

    quinta-feira, 7 de março de 2013 12:46
  • Fábio, bom dia.

    Para minimizar a perda de dados primeiramente coloque a sua base para recovery model para "FULL". Faça um backup full da sua base e no final do dia faça backups de logs. Isto fará com que a perda de dados seja reduzida.

    Sem avisar ninguém, deixe rodando o SQL trace por alguns dias para capturar todos os eventos T-SQL. É um pouco pesado, dependendo da carga de trabalho em seu servidor, mas é uma maneira de capturar se alguém ou processo está executando comandos que não deveriam.

    Abs.


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp

    • Marcado como Resposta Fabio A. Morais sexta-feira, 8 de março de 2013 13:56
    quinta-feira, 7 de março de 2013 13:03
  • Como a sua versão não é a Enterprise, faça como o Eduardo disse, deixe um trace rodando e quando ver que houve o delete de dados indevidos de uma olhada no tracing, com certeza constará la.

    Alexandre Matayosi Conde Mauricio. Se esta sugestão for útil, por favor, classifique-a como útil. Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    quinta-feira, 7 de março de 2013 13:11
  • Bom dia Fabio! Tudo tranquilo?

    Vamos lá: tive alguns casos desse no passado. O que foi checado:

    > Existe algum job de backup ou sincronismo com outra tabela/banco? O próprio job poderia estar "resetando" sua tabela. Entretanto você disse que não tem nenhum log, o que é estranho
    > Quem mais tem acesso ao servidor?
    > Você implementou segurança somente no banco SQL ou também no Windows Server aonde está hospedada? Já tive casos de ferramentas de backup retornando arquivos "originais", o que consequentemente zerava o banco. Ou alguém parando o serviço do SQL e substituindo o arquivo do banco.
    > Troque a senha de SA urgente e implante o SQL Audit como nosso amigo Alexandre recomendou.

    Abraços!

    Felipo Gonçalves
    Microsoft Contingent Staff

    Olá Felipo, 

    Os únicos JOB´s que tem o SQL Agent , é o de fazer Backup de cada 2 horas. Já apaguei todos os backups antigos, e não temos nenhuma rotina para recuperar as bases.

    Só eu e o dono da empresa temos acesso ao servidor.

    Implementamos segurança também no servidor, ou seja, só acessa o banco de dados de IP´s liberados. Assim liberamos os IP dos sites que usam a aplicação, que no caso são 3 servidores de hospedagem. Nem da minha casa, eu consigo acessar o banco devido ao IP dinâmico.


    Fabio A. Morais

    quinta-feira, 7 de março de 2013 13:34
  • Fábio, bom dia.

    Para minimizar a perda de dados primeiramente coloque a sua base para recovery model para "FULL". Faça um backup full da sua base e no final do dia faça backups de logs. Isto fará com que a perda de dados seja reduzida.

    Sem avisar ninguém, deixe rodando o SQL trace por alguns dias para capturar todos os eventos T-SQL. É um pouco pesado, dependendo da carga de trabalho em seu servidor, mas é uma maneira de capturar se alguém ou processo está executando comandos que não deveriam.

    Abs.


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp

    Olá Eduardo, 

    Fiz as duas coisas que você me orientou. Recovery FULL, SQL Trace rodando.

    Só ainda não entra na minha cabeça como os dados podem sumir sem tem um registro da ação do usuário, na Trigger e ou LOG´s do IIS ou SQL Server!? Por que tem o LOG também do SQL Transaction!! e nada..

    É possível isso?


    Fabio A. Morais

    quinta-feira, 7 de março de 2013 13:37
  • Fábio, bom dia.

    Para minimizar a perda de dados primeiramente coloque a sua base para recovery model para "FULL". Faça um backup full da sua base e no final do dia faça backups de logs. Isto fará com que a perda de dados seja reduzida.

    Sem avisar ninguém, deixe rodando o SQL trace por alguns dias para capturar todos os eventos T-SQL. É um pouco pesado, dependendo da carga de trabalho em seu servidor, mas é uma maneira de capturar se alguém ou processo está executando comandos que não deveriam.

    Abs.


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp

    Eduardo, 

    Eu fiz isso, e consegui pegar a ação do usuário, agora sei o que está acontecendo. Ele está dando um SQL Injection via POST num WebService. Agora que ví que o URL Scan, não está bloqueando POST de variáveis. Estou tentando achar como fazer isso agora.

    Outra coisa, para rastrear este usuário estou usando o SPID, porém pelos sys_process, cada hora que consulto pelo SPID usado no ataque, dá um usuário diferente.

    Você sabe uma forma correta de rastrear o usuário pelo SPID, no momento do ataque? Pelo menos para saber a máquina, ou IP que foi usado no ataque?


    Fabio A. Morais

    sexta-feira, 8 de março de 2013 14:00