Agora, vários atacantes estão explorando bases mal configuradas e pedindo o pagamento de resgates pelos dados apagados. Os pesquisadores NeilMerrigan (@nmerrigan) e Victor Gevers (@0xDUDE) acreditam que já podemos ter mais 32 mil servidores comprometidos.
Pensando nesses usuários, a MongoDB publicou em seu blog um guia com as melhores práticas de segurança para a proteção dessas bases.
Considerando que existem hoje mais de 500 bases MongoDB abertas hospedadas no Brasil, tomei a liberdade de traduzir o post deles para que usuários que estejam passando por problemas possam mais facilmente encontrar alguma ajuda.
Só gostaria de deixar claro que não tenho nenhuma ligação com a empresa MongoDB. O texto abaixo é uma tradução pessoal que compartilho com vocês.
Recentemente houve relatos de ataques contra instâncias MongoDB expostas publicamente na Internet. O atacante apagou os dados e pediu o pagamento de um resgate antes de devolver as bases.
Esses ataques podem ser prevenidos com o uso de medidas de proteção abrangentes, do próprio MongoDB. Mas você precisa usar essas funcionalidades de forma correta, e nossa documentação de segurança vai te ajudar nisso. Aqui estão alguns links para as partes relevantes da documentação e alguns outros materiais úteis:
- Segurança é tratada com detalhes no Manual de Segurança. Recentemente nós também expandimos nosso treinamento online de segurança como parte do currículo da Universidade MongoDB
- Siga os passos no nosso Checklist de Segurança. Ele discute como exigir autenticação, habilitar controles de acesso, limite exposição de rede, e outras boas práticas importantes
- O instalador mais popular do MongoDB (RPM) limita o acesso via rede ao localhost, por padrão. Use essa configuração também se você está instalando de outras maneiras.
- Os serviços MongODB Cloude Manager e o MongoDB Ops Manager fornecem backup continuo com recuperação em qualquer ponto, e usuários podem habilitar alertas para detectar se suas instalados estão expostas na internet (veja a Figura 1 abaixo).
Figura 1: Crie um novo alerta para lhe notificar se um host estiver exposto na Internet
- O MongoDB 3.4 permite que você configure autenticação para um sistema desprotegido sem tirar o serviço do ar.
- O serviço de banco de dados MongoDB Atlas fornecer múltiplos níveis de segurança para sua base de dados por padrão. Essas incluem controles de acesso robustos, isolamento de redes usando Amazon VPCs e VPC Peering, lista branca de IP, criptografia dos dados em transmissão usando TLS/SSL, e criptografia opcional do sistema de arquivos.
- Nós encorajamos que os usuários que passaram por um incidente de segurança com o MongoDB criem um relatório de vulnerabilidade. Instruções de como fazer isso, ou de como nos contatar, podem ser encontradas aqui.
Passos para diagnosticar e responder a um ataque
- Se você está interessado em aprender mais sobre as melhores práticas de segurança, por favor leia nosso Guia de Arquitetura de Segurança.
Como saber se um atacante comprometeu seus dados?
- Se o controle de acesso está configurado corretamente para a base de dados, os atacantes não devem ter conseguido acesso aos seus dados. Veja nosso Checklist de Segurança para ajudar a identificar todas as potenciais vulnerabilidades.
- Verifique suas bases de dados e coleções. Nos casos que temos visto recentemente, o atacante apagou a base de dados e/ou as coleções e as substituiu por uma nova com uma demanda de resgate
Se você está executando uma instância insegura do MongoDB que foi comprometida
- Se o controle de acesso está ativado, verifique os logs de sistema para tentativas de acesso não autorizadas ou atividades suspeitas.
- Se você tem um suporte comercial, cria um ticket P1 IMEDIATAMENTE e nossos Engenheiros de Serviços Técnicos podem guiar você pelo procedimento abaixo.
- Sua prioridade tem de ser tronar seu(s) cluster(s) seguros para prevenir outros acessos não autorizados. Siga os passos de nosso Checklist de Segurança.
- Se você já tinha usuários no sistema, verifique que nenhum usuário foi criado, removido ou modificado usando o comando usersInfo.
- Examine os logs para encontrar a hora do ataque. Procure por comandos que removeram seus dados, modificaram usuários ou criaram o registro de pedido de resgate.
- Se você faz backup dos dados comprometidos regularmente, você pode restaurar o backup mais recente; você vai precisar analisar que data pode ter mudado desde o último backup e a hora do ataque. Se você usa o Ops Manager ou o Cloud Manager para fazer os backups, você pode fazer uma restauração point-in-time de antes do ataque. Verifique se você ainda está na janela para a restauração point-in-time (as últimas 24 horas, a não ser que você tenha alterado a configuração). Se estiver, execute a restauração antes que o período do point-in-time passe. Se você já estiver fora da janela do point-in-time, você ainda pode fazer uma restauração do backup mais recente.
- Se você não tem um backup ou, por outra razão, não pode restaurar os dados, infelizmente seus dados podem estar perdidos para sempre.
- Você deve assumir que o atacante tem uma cópia de todos os dados das bases de dados afetadas. Nesse caso siga seus próprios procedimentos de segurança para um vazamento de informações.
- Finalmente, verifique nossas melhores práticas e recursos de segurança para proteger seus dados no futuro.
