Como limpar dados ao limpar / reinstalar um servidor comprometido?

Question

Eu tenho um servidor que foi comprometido, onde os logs foram apagados e não tenho nem capacidade nem tempo para descobrir quais partes reais do sistema foram modificadas. O servidor foi colocado offline e cerca de 400 GB de dados de pesquisa de vários usuários foram colocados em outro backup offline. Eu verifiquei os diretórios com o Clam, mas estou preocupado que possa haver restos de código malicioso em algum lugar nos milhares de arquivos.

Os arquivos representam anos de registro de dados, mas não tenho backups com os quais eu possa compará-los (Essa penetração foi a primeira a ser informada sobre esses servidores "sob meu controle" e algumas mudanças sérias estão chegando) do que deveria / não deveria estar contido. Existe algum método mais completo para garantir que os dados não contenham partes inativas de códigos maliciosos? Eu posso tentar impedir que scripts sejam executados de dentro dos meus diretórios de backup, mas estou assumindo que em algum momento um dos usuários se perguntará por que algum código que eles escreveram 2 anos atrás não está funcionando e acabará com qualquer segurança que eu adicione.

TL; DR : eu fui o dono. Como posso ter certeza de que os dados que estou copiando para a nova instalação do servidor não conterão códigos potencialmente mal-intencionados?

    

Answer 1

Resposta para novatos:

• monte com a noexec option para que os executáveis e as bibliotecas não possam ser executados (os scripts também não podem ser executados, mas eles ainda podem ser chamados com bash malicious.sh ).

Ou

• configure algum tipo de ambiente chroot seguro para que você não se importe de explodir todo o "sistema" quando um vírus tentar neutralizá-lo, à la honeypot.

A opção 1 tem a desvantagem óbvia de que você não pode executar qualquer código legítimo, a opção 2 tem a desvantagem óbvia de que um único executável que se comporta mal pode neutralizar todos os seus dados legítimos.

Além disso, um bom design de permissão (usuários, grupos, bit pegajoso, bit setuid etc.) e umask restritivo devem garantir que um usuário só consiga explodir seus próprios arquivos ( ou em sua responsabilidade), que é melhor que uma completa destruição em caso de ataque.

Você também pode usar um sistema de arquivos com suporte a snapshot (não vou anunciar muito o ZFS, ele tem coisas boas e ruins, você pode tentar). Isso não impedirá que um ataque de privilégio de escalação ganhe raiz e exclua seus instantâneos, mas se for apenas a destruição de dados, você poderá reverter para um estado anterior).