Sobre instalações Debian

Há anos que confio no Debian. Não por romantismo, mas por pura razão: ciclos de lançamento estáveis, manutenção sólida de pacotes, enorme difusão, ecossistema facilmente compreensível.

Mas: o que fica no disco após a instalação é uma piada de mau gosto em termos de segurança. Um Debian recém-instalado é – para dizer de forma simpática – aberto como uma porta de celeiro.

Ao mesmo tempo, tenho uma realidade muito concreta e nada romântica:

• Paisagem heterogénea de hosts bare metal e VMs KVM/QEMU
• Nenhuma infraestrutura gigantesca que justifique um universo completo de Cloud-Init ou Ansible
• Altas exigências de segurança, criptografia, capacidade zero trust
• Ideias muito específicas sobre esquema de particionamento, criptografia, layout btrfs e cadeia de inicialização

Após várias rodadas com Preseed, scripts personalizados e internos do Debian Installer, chegou-se a um ponto em que ficou claro:

Ou eu construo o meu próprio Live Builder reproduzível, além de um Debian Installer completamente novo, ou passo o resto da minha vida lutando contra a tradicional pilha de instalação do Debian.

Optei pela segunda variante.

O resultado chama-se:

• CISS.debian.live.builder
• CISS.debian.installer

O meu ambiente consiste numa mistura de:

• servidores raiz clássicos / bare metal
• ambientes KVM e QEMU em diferentes provedores

Portanto, preciso de uma ferramenta que:

• possa criar condições idênticas tanto no centro de dados como na nuvem
• funcione independentemente do hipervisor
• impõe todas as decisões críticas de segurança já na compilação e na fase inicial de arranque

O Debian foi escolhido conscientemente:

• Sem lançamentos contínuos, ou seja, sem surpresas semanais
• Alta maturidade, muito boa manutenção a longo prazo

Mas: o endurecimento «de fábrica» praticamente não existe.

Quem já se ocupou seriamente com endurecimento SSH, parâmetros do kernel, políticas de montagem do sistema de ficheiros, auditd, registo, arranque seguro e criptografia sabe:

A ISO padrão do Debian é um produto de conveniência, não um ponto de partida seguro.

Para grandes ambientes, Cloud-Init, MAAS, Ansible & Co. fazem sentido. A minha realidade é diferente:

• O número de máquinas é limitado, o Ansible só entra em ação na etapa após a instalação
• Ainda assim, quero instalar máquinas de forma determinística, reproduzível e com o máximo de proteção
• Não quero construir outro grande projeto apenas para orquestrar o instalador

Assim fica claro:

O próprio instalador deve ser tão poderoso que possa implementar um sistema completamente protegido sem «magia» posterior.

O ponto de viragem real foi em novembro de 2024.

Naquela época, passei um mês inteiro a ajustar a configuração do Preseed e o analisador para que o esquema de partição CISS desejado fosse possível:

• Criptografia completa com LUKS2
• Partições separadas
• btrfs com subvolumes separados para /.snapshots
• Sem a obrigatoriedade de «LVM para todos»
• Número flexível de dispositivos e partições

O problema:

• Toda a lógica do instalador Debian baseia-se em suposições antigas e é apenas parcialmente personalizável
• Os módulos de particionamento funcionam em padrões padrão antigos, que não se adequam a um design FDE/btrfs moderno
• O Preseed só ajuda, desde que se permaneça dentro dos limites previstos

Após inúmeras personalizações, testes e tentativas falhadas, a conclusão foi simples:

O instalador Debian não foi concebido para reproduzir configurações Crypto e btrfs modernas e altamente flexíveis sem a obrigatoriedade do LVM.

Portanto: recomeçar. Framework próprio.

O CISS.debian.live.builder começa exatamente onde o padrão termina: no sistema live, que serve como um ambiente de pré-instalação altamente confiável.

Objetivo:

Um Live-ISO que estabelece uma cadeia de confiança contínua e criptograficamente segura, desde a primeira instrução da CPU que afeta o meu ISO até ao arranque do instalador, especialmente numa situação remota de confiança zero.

Princípios fundamentais:

1. Âncora de confiança na borda do ISO, não apenas «em algum lugar do sistema»
2. Cadeia de verificação em duas etapas:
   • Verificação antecipada do conteúdo do ISO, antes mesmo de qualquer coisa essencial ser montada
   • Atestado tardio do sistema de ficheiros raiz descriptografado
3. Endurecimento da camada de armazenamento e do bloco
   • LUKS2 com AES-XTS-512
   • dm-integrity com HMAC-SHA-512 por bloco
4. Desbloqueio remoto através do Dropbear endurecido no initramfs, sem as superfícies de ataque SSH habituais
5. Fail-closed em vez de «vai correr tudo bem»

Esbocei brevemente a documentação técnica sobre a cadeia de arranque e confiança no repositório, utilizando diagramas:

https://git.coresecret.dev/msw/CISS.debian.live.builder/src/branch/master/docs/MAN_CISS_ISO_BOOT_CHAIN.md

Visão geral da cadeia de inicialização e confiança

1. Inicialização segura, se disponível

Se o hardware permitir, a cadeia funciona assim:

1. A inicialização segura UEFI carrega e verifica o shim
2. O shim verifica e carrega o GRUB
3. O GRUB carrega o kernel e o initramfs do sistema live CISS.debian.live.builder

Assim, a minha verificação já começa na cadeia de inicialização segura.

Se o arranque seguro não estiver disponível, a âncora de confiança é consistentemente movida para a frente, para a borda ISO (ver abaixo), mas permanece criptograficamente limpa.

2. SquashFS encriptado com LUKS no contentor

O Live-Rootfs real não fica sem encriptação como filesystem.squashfs, mas sim:

1. Sistema de ficheiros ISO → Ficheiro de contentor (por exemplo, live/ciss_rootfs.crypt)
2. Camada dm-integritycom HMAC-SHA-512
3. LUKS2 (aes-xts-plain64, chave de 512 bits, setores de 4 KiB, argon2id)
4. Nele: SquashFS com o Live-Rootfs real

Com isso, tenho um comportamento funcional semelhante ao AEAD no nível do bloco:

As manipulações não levam a um «comportamento estranho», mas a erros de E/S claros e graves.

3. Verificação antecipada do ISO Edge

Ainda antes de o contentor LUKS ser aberto, acontece no initramfs:

• Verificação de um ficheiro de assinatura (por exemplo, sha512sum.txt.sig) com gpgv
• Verificação da lista de hash correspondente
• Fingerprint-Pinning: apenas a impressão digital GPG exatamente esperada é aceite

Isso garante que:

Se a ISO ou os seus artefactos principais tiverem sido manipulados, o ambiente nem sequer arranca num estado «semi-confiável», permanecendo corretamente parado.

4. Atestado tardio do rootfs

Depois que o contentor LUKS é aberto e o SquashFS é montado, segue-se a segunda etapa:

• Os ficheiros de atestado no rootfs são verificados contra listas de hash assinadas
• Nova verificação FPR contra o chaveiro incorporado
• Verificação da topologia real do dmsetup(Crypt e Integrity, como esperado)

Isso garante criptograficamente não apenas a borda ISO, mas também o estado interno da camada Live-Rootfs.

5. Dropbear reforçado para desbloqueio remoto

As instalações remotas são inerentemente Zero-Trust:

• Muitas vezes, não controlo o hipervisor
• Não confio na rede

Por isso, na fase initramfs, é executado um Dropbear reforçado que:

• permite exclusivamente a autenticação por chave pública
• utiliza apenas combinações KEX/Cipher modernas
• não permite o encaminhamento de agente, X11 ou TCP
• escuta numa porta dedicada
• termina de forma limpa e rigorosa em caso de erros

Com isso, posso:

• Inicializar remotamente o Live-ISO
• iniciar sessão com segurança na fase initramfs
• abrir o contentor LUKS
• controlar a instalação

sem o habitual peso do SSH e sem que o sistema inicie com uma «assinatura pouco clara».

Porquê um instalador próprio?

A segunda parte do projeto é o CISS.debian.installer, que se baseia neste ambiente Live.

Os requisitos são deliberadamente ambiciosos:

1. Máxima flexibilidade no particionamento
   • Qualquer número de dispositivos e partições
   • Funções livremente definíveis (por exemplo, root, log, auditoria, instantâneos, scratch)
   • Sem LVM forçado, especialmente como pré-requisito para FDE
   • Suporte nativo para subvolumes btrfs na estrutura da minha preferência
2. Controlo declarativo da instalação
   • Configuração por ficheiros YAML
   • Validação de esquema claramente definida
   • Resultados reproduzíveis em diferentes máquinas e fornecedores
3. Segurança como padrão, não como um hack posterior
   • FDE como caso normal, não como opção
   • Separação de diretórios críticos (/var/log, /var/log/audit, /var/tmp, /.snapshots)
   • Opções de montagem seguras (noexec, nodev, nosuid, compressão zstd, estratégias de descarte, etc.)
   • Fortalecimento de parâmetros do kernel, SSH, registo, auditoria já incorporados no instalador
4. Caminho de instalação compatível com Zero Trust
   • Toda a cadeia, desde a compilação ISO até ao arranque e ao instalador, permanece criptograficamente rastreável
   • As verificações de integridade e autenticidade são aplicadas antes mesmo de um único byte de «produção» ser gravado
5. Sem dependência do Calamares
6. O Calamares não faz parte da configuração de propósito.
7. Não tenho interesse em usar um instalador crítico para a segurança cuja cultura de desenvolvimento coloca prioridades ideológicas visíveis acima do rigor técnico.

Efeitos práticos: reforçado desde o primeiro segundo

O ambiente ao vivo que sai do CISS.debian.live.builder não é uma ISO «montada rapidamente», mas sim:

• Auditoria Lynis em cerca de 96% para o sistema ao vivo
• Configuração SSH que se mantém estável na faixa de 100% em auditorias especializadas
• Parâmetros de kernel reforçados, políticas restritivas de iptables/nftables e registo
• Escopo de serviço mínimo possível, superfície de ataque mínima

O ponto decisivo:

Este endurecimento não começa após a instalação, mas com o arranque do próprio ambiente ao vivo.

Isso diferencia o CISS.debian.live.builder fundamentalmente de uma ISO normal do instalador Debian.

Por que o esforço vale a pena

Sim, teria sido mais conveniente aceitar as limitações do instalador Debian, envolver três camadas de Ansible em torno dele e considerar tudo isso como «bom o suficiente».

Decidi conscientemente não fazer isso por três motivos:

1. A segurança deve ser determinística
2. Quero ter uma cadeia de artefactos (ISO, assinaturas, listas de hash, ficheiros de certificação) que possa verificar criptograficamente a qualquer momento.
3. Criptografia flexível e arquitetura de partição não são um luxo
4. Layouts Btrfs, designs FDE e cadeias de arranque não são trivialidades, mas os pilares da arquitetura do sistema. Quem faz concessões aqui, constrói sobre areia a médio prazo.
5. Zero-Trust significa: não confio no hipervisor
6. Tenho de partir do princípio de que os fornecedores de nuvem, nós intermédios e terceiros não são meus amigos.
7. Por isso, é imprescindível que o instalador funcione num ambiente certificado e com o máximo de segurança.

Conclusão

O CISS.debian.live.builder não é «mais um gerador de Live ISO», mas sim:

• uma combinação deliberadamente reforçada de estrutura de compilação, pilha de criptografia, cadeia de arranque e cadeia de confiança,
• que fornece um ambiente Live totalmente seguro,
• que, por sua vez, constitui a base para um instalador Debian flexível, declarativo e centrado na segurança.

O objetivo é simples, mas tecnicamente exigente:

novas máquinas, sejam elas bare metal ou VM, devem poder ser reproduzidas a partir de uma única ISO bem definida, criptograficamente certificável e reforçada desde o primeiro segundo.

Para os meus fins, qualquer outra opção simplesmente não é viável.