Máquinas Virtuais - Possível Restaurar Substituir o Kernel sem Reconstruir?

Question

Estou usando máquinas virtuais Linux (Wheezy, Linux Vserver), cada uma com um ambiente de desktop incluindo o Firefox.

Se uma Máquina Virtual for comprometida (por exemplo, SQL injection ) para que o kernel seja hackeado e o controle tenha sido tomado da VM (não do host), é possível reconstruir a VM e mova os dados para a VM reconstruída para corrigir o problema.

P: Essa pode ser uma pergunta estúpida, mas é possível, em vez disso, uma alternativa para copiar alguns arquivos para a VM comprometida (por exemplo, uma versão limpa de tudo na partição /boot )? As VMs estão bem fechadas para começar.

O argumento aqui sendo este pode ser um pouco mais rápido do que reconstruir a VM. Ou a "resposta certa" pode ser "não, você precisa reconstruir a VM para ter certeza de que ela não foi comprometida". Se a abordagem alternativa valesse a pena considerar, o que precisaria ser sobrescrito e substituído para ter um kernel "novo"?

    

Answer 1

Primeiro, você precisa saber exatamente o que mudou sem sua permissão. Se eu fosse projetar um sistema como você deseja, eu faria:

• Manter hashes criptográficos dos arquivos do kernel em execução, que consistem no conteúdo de /boot no meu sistema Ubuntu
• Mantenha hashes de todas as bibliotecas, aplicativos, binários, etc. instalados no sistema que não fazem parte dos aplicativos internos internos implementados.
• Esses hashes são mantidos fora da máquina e comparados com frequência.
• Saiba que as atualizações acionarão alertas e as resolverão manualmente.

Ou, eu considero o que é para mim a abordagem mais simples de recriar uma nova VM rapidamente, sem configuração manual (Chef, Puppet, etc) e, em seguida, implantar meus aplicativos personalizados (principalmente aplicativos da web no meu caso) e conteúdo do banco de dados) de forma rápida e fácil para a nova VM.

Acho que, embora seja possível fazer todas as coisas acima, e isso pode ajudá-lo a detectar quando algo mudou, o que é fundamental para saber que você foi comprometido, é muito mais difícil desfazer essas alterações em um conteúdo reproduzível. meio caminho do desastre. Manter toda a configuração da máquina em algum sistema de criação de máquina, como o Chef, permite que você crie uma nova VM com rapidez suficiente, o que provavelmente lhe custará muito tempo no final.

    

Answer 2

Eu discordo. Eu suspeito que é o espaço de usuário do guest do VM que foi comprometido, em vez do kernel.

De qualquer maneira, você provavelmente nunca saberá qual era, então a coisa mais segura a fazer é Nuke de órbita.

Você pode restaurar um instantâneo anterior para um último estado de configuração válida.