Tivemos o mesmo problema em um servidor aqui hoje também. Eu duvido muito que tenha recuperação, porque assim... O cara excluiu todas as tabelas da base de dados, e criou somente uma com os dados para pagamento.
A base que tínhamos era bem grande, tenho muitas duvidas se o cara que fez isto realmente fez o download de todos os registros e estrutura do banco para depois excluir e pedir o resgate. Creio que ele simplesmente excluiu todas as tabelas e somente deixou a mensagem de resgate, para neste caso alguém pagar, e mesmo assim não obter os dados de volta. Imagina quanto de espaço e banda o cara precisaria para pegar todos os dados dos que sofreram com isto. Então creio que o único modo de recuperação seja alguma forma de backup efetuada anteriormente. Em 20 de abril de 2017 14:17, <siste...@mvsoftware.com.br> escreveu: > Olha o dono da empresa que teve esse problema tentou entrar em contato com > o cara que fez, era de fora, mas ele percebeu que o cara ia pegar a grana e > ja era... > As vezes um zé mané na web, pega esse virus em sites que ensinam usar > esses virus, e manda bala, ele mesmo nao sabe reverter o processo, entao > ele esta atras da grana e que se dane a empresa/usuario > O cara tem que te enviar pelo menos uma parte dos dados pra provar que > pode lhe dar tudo de volta. > Muito cuidado, não dê dinheiro a niguém sem estar certo de que vai receber > seus dados de volta, isso vai influenciar mais criminosos > > > > Marcelo > > *From:* Pedro B. Alves > *Sent:* Thursday, April 20, 2017 1:25 PM > *To:* Comunidade PostgreSQL Brasileira > *Subject:* Re: [pgbr-geral] RES: RES: PostgreSQL ataque??? > > >> >> >> O firewall não é o problema aqui. >> >> Se a porta do banco de dados está aberta para a internet por algum >> requisito de negócio (conexões de outros sistemas/clientes/etc) o firewall >> teria que liberar a porta de qualquer maneira. Caso não haja esta >> necessidade de estar aberta para a internet, então neste caso sim, o >> firewall deveria bloquear este acesso. >> >> De qualquer forma, o principal ponto aqui é: >> >> 1. o pg_hba não pode estar como trust para qualquer ip >> 2. é necessário sempre ter uma política de backup madura (backup + >> armazenamento do backup fora do servidor + testes de restore do backup para >> validar o mesmo) >> >> Isto porque o atacante apenas aproveitou uma brecha de configuração >> (pessoas com bancos de dados na porta padrão, expostas na internet e sem >> requisitos de senha), ou seja, não foi um ataque sofisticado do ponto de >> vista do banco de dados. >> > > > o banco de dados possuía senha. não temos nenhum banco sem senha. > > > > > ------------------------------ > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
