Criptografar servidor linux remoto

Question

Um de meus clientes solicitou que seu servidor da Web seja criptografado para impedir ataques offline a dados altamente confidenciais contidos em um banco de dados mysql e também / var / log. Eu tenho acesso root completo ao servidor dedicado em um host popular. Eu estou considerando 3 opções -

1. FDE - Isso seria ideal, mas apenas com acesso remoto (sem console) Eu imagino que isso seria muito complexo .

2. Xen - instalando o XEN e movendo seu servidor dentro de uma máquina virtual XEN e criptografando a VM - que parece mais fácil de fazer remotamente.

3. Parition - criptografa as partições não estáticas nas quais os dados confidenciais residem, / var / home etc.

Qual seria a abordagem simplista que satisfaz os requisitos?

Answer 1

Vale a pena verificar com o host para ver se eles podem conectar um IP KVM ou instalar um cartão de acesso remoto (IPMI, HP iLO, iDRAC ou RAS, conforme apropriado) para fornecer um criptografado strong e remota.

Com qualquer solução FDE, você necessariamente terá que ter um bootstrap do sistema não criptografado. No mínimo, isso consistirá no MBR, bootloader, kernel e initrd.

É possível ativar a rede do sistema de boot FDE usando algo como Mandos ou usando um sistema operacional inteiro instalação e, em seguida, alternar para o SO real executando remotamente scripts personalizados que utilizam o poder de pivot_root, chroot (ou kexec) após cryptsetup e mount.

Usar o Xen e ter uma VM com armazenamento criptografado é semelhante a usar um sistema operacional inteiro para bootstrap, mas com menos manutenção e manutenção. A única desvantagem nessa abordagem é a sobrecarga de virtualização.

A abordagem de dispositivo de bloco (LV, partição ou loopback) é certamente fácil de seguir, especialmente se você estiver tentando fazer a alteração em um sistema de produção.

Agora a parte de aconselhamento: Se você pode obter acesso remoto ao console (KVM completo, não serial) e você está construindo uma nova máquina, então vá com FDE. Todas as distribuições atuais o suportam no instalador e será a menor opção de manutenção.

Caso contrário:

• Nem pense em usar o FDE. Um sistema de bootstrap de acesso remoto será apenas muito frágil, e quando ele quebrar, será um pesadelo para consertar. Não tente converter um sistema em tempo real a menos que você realmente saiba realmente o que está fazendo.

• Se você estiver criando uma nova máquina para essa atualização de segurança e a sobrecarga de virtualização for aceitável, vá para a abordagem 2. Será a opção mais sensata para você e qualquer outro administrador de sistema do que entender / manter. Com essa abordagem, você pode usar a criptografia do instalador fornecida pelo sistema operacional na VM, em vez de criptografar o armazenamento no host, se desejar (pro / contras para ambas as abordagens com manutenção / migração / etc).

• Se você tiver que fazer essa alteração no sistema de produção (o que eu recomendo strongmente. Faça o cliente pagar por uma migração adequada com um segundo sistema), então vá com a abordagem 3 e use um dispositivo de bloco formatado LUKS (preferencialmente um volume lógico).

• Em qualquer um desses cenários, o sistema básico ou o código de inicialização pode obviamente ser trojaneado para que a chave de criptografia seja revelada. Não desperdice seu tempo tentando diminuir esse risco, a menos que você tenha muito tempo disponível e seu cliente tenha dinheiro para gastar. Se você tiver que atenuá-lo, então você deseja instalar algo como o Osiris.

Tenha em mente que os dados vão correr muito mais risco de erros de software, sistemas de backup, configuração incorreta, senhas incorretas, etc.

    

Answer 2

Em primeiro lugar, observe que você não precisa criar uma partição separada para criptografar dados; você pode usar uma montagem de loopback para montar um arquivo como uma partição (criptografada).

Mas, mais importante, você precisa de um modelo de ameaça claro. O que exatamente seu cliente tem medo?

Normalmente, um servidor hospedado deve estar acessível apenas para funcionários autorizados e algumas equipes especializadas do provedor de hospedagem. Eles temem que o provedor de hospedagem tente copiar os dados pelas costas? Eles têm medo de arrombamentos físicos? Eles querem se proteger de espionagem casual ou de um invasor sofisticado, possivelmente com acesso repetido?

Isso influenciará a solução de que precisam. Por exemplo. apenas criptografar os dados significa que o sistema operacional ainda está vulnerável à instalação de um trojan enquanto o sistema está offline. Um invasor pode colocar o sistema offline, instalar o cavalo de tróia, reiniciar o sistema; depois, eles podem copiar dados da área criptografada enquanto ela estiver acessível.

Além disso, qualquer solução de criptografia precisará de uma chave / frase secreta a ser fornecida para desbloquear a criptografia. Quando isso será fornecido? Como? Quais canais seguros você tem? E se, por exemplo, o sistema se tornar não inicializável e precisar ser recuperado? Alguém confiável para ter a chave terá que estar fisicamente presente; isso será viável?

Sem responder a todas essas perguntas (e mais), não há uma resposta razoável.

É claro que você pode simplesmente implantar algum tipo de criptografia e acabar com isso, mas isso pode falhar na proteção contra um ataque e apenas causar um custo desnecessário e uma falsa sensação de segurança.

Observação: há uma boa discussão sobre como criptografar dados em um servidor aqui: Inicializando e Protegendo Automaticamente um Servidor Linux com um Sistema de Arquivos Criptografado