Como construir um bunker digital: repositório imutável com Linux e XFS

Você acorda às 3 da manhã com o telefone tocando. Não é um alerta de disco cheio. É o silêncio ensurdecedor dos seus sistemas de monitoramento parando, um por um. Quando você chega ao console, a nota de resgate já está na tela. Seu primeiro instinto é: "Sem problemas, eu tenho backup". Você abre o software de backup e percebe o verdadeiro horror: os repositórios estão vazios, formatados ou criptografados.

Seus backups estavam na rede. Eles eram acessíveis. E, portanto, eram vulneráveis.

A mentalidade de "fazer backup" morreu. O que importa hoje é a recuperabilidade. Se o seu armazenamento de backup pode ser modificado, excluído ou criptografado pelo mesmo usuário que gerencia o ambiente (ou por um atacante que roubou essa credencial), você não tem um backup. Você tem apenas uma cópia de dados esperando para ser destruída. Neste artigo, vamos descer ao nível do sistema de arquivos e construir o que chamo de "Bunker Digital": um repositório Linux endurecido (hardened), usando XFS e bits de imutabilidade que desafiam até o usuário root.

Resumo em 30 segundos

• Protocolos Padrão Matam: Usar SMB (CIFS) ou NFS abertos para repositórios de backup é convidar o ransomware para entrar. O isolamento deve ser total.
• Imutabilidade é Lei: Não confie em permissões de usuário. A proteção deve ocorrer no nível do sistema de arquivos (filesystem) com flags de imutabilidade que bloqueiam a exclusão e alteração de blocos.
• XFS é Obrigatório: Além da estabilidade, o XFS com tecnologia Reflink permite "Fast Clone", economizando espaço em disco e reduzindo janelas de backup de horas para minutos.

O pesadelo do backup criptografado e a falha da regra 3-2-1 clássica

Todos nós conhecemos a regra 3-2-1: três cópias dos dados, em duas mídias diferentes, sendo uma fora do local (offsite). Por décadas, isso foi o evangelho. O problema é que o cenário de ameaças evoluiu, mas a infraestrutura de armazenamento de muitos administradores não.

Hoje, o ransomware moderno não criptografa apenas a produção. Ele é projetado para caçar o backup. Ele varre a rede procurando compartilhamentos, portas de gerenciamento de storage e agentes de backup. Se a sua cópia "offsite" está conectada via VPN permanente e montada como um drive de rede, ela não é realmente offsite; ela é apenas uma extensão da sua superfície de ataque.

⚠️ Perigo: Um repositório de backup montado como uma letra de unidade (E:, F:) no Windows ou um mount point NFS padrão no Linux é visível para qualquer malware que ganhe privilégios administrativos. Se o sistema operacional consegue ver e escrever no disco, o ransomware também consegue.

A regra 3-2-1 precisa de uma atualização para 3-2-1-1-0: 3 cópias, 2 mídias, 1 offsite, 1 imutável (ou air-gapped) e 0 erros na verificação de restore. A imutabilidade não é um recurso de luxo; é a única garantia de que, quando o botão de "delete" for pressionado, o armazenamento responderá com um sonoro "não".

Por que protocolos SMB e NFS são vetores de ataque

A conveniência é inimiga da segurança. Protocolos como SMB (Server Message Block) e NFS (Network File System) foram criados para compartilhamento fácil de arquivos, não para segurança de bunkers de dados.

Quando você configura um NAS (seja um Synology, QNAP ou um servidor TrueNAS) e apresenta o armazenamento via SMB para seu servidor de backup, você está criando uma ponte bidirecional. O protocolo SMB é "falador". Ele anuncia sua presença. Vulnerabilidades históricas (como o EternalBlue) e a simples força bruta de credenciais tornam esses compartilhamentos alvos fáceis.

Mais crítico ainda é o conceito de "Air Gap Lógico". Em um design seguro, o repositório de backup não deve ter nenhum protocolo de compartilhamento de arquivos aberto escutando na rede. O servidor de backup (o proxy/gateway) deve se conectar ao repositório através de um túnel único e seguro, autenticar-se, transferir os dados e desconectar.

Fig. 1: O isolamento lógico do Hardened Repository elimina protocolos de compartilhamento (SMB/NFS) persistentes.

Ao eliminar o SMB e o NFS da equação e usar um transporte proprietário ou SSH restrito diretamente para um servidor Linux, reduzimos drasticamente a superfície de ataque. O armazenamento deixa de ser uma "pasta pública" e passa a ser uma caixa preta que só aceita dados novos, mas recusa modificações nos antigos.

A ilusão da segurança via permissões e snapshots

Muitos administradores de storage acreditam que estão seguros porque usam snapshots no nível do array de armazenamento. "Se o ransomware criptografar o volume, eu reverto o snapshot do storage", dizem eles.

Isso é uma meia-verdade perigosa.

Snapshots são excelentes para recuperações rápidas operacionais, mas não são backups imutáveis por definição padrão. Se um atacante comprometer o console de gerenciamento do seu storage array (e eles tentarão, muitas vezes usando credenciais padrão ou explorando interfaces web não corrigidas), o primeiro comando que executarão será delete all snapshots.

💡 Dica Pro: Permissões de arquivo padrão (chmod 700, chown root) protegem apenas contra usuários honestos ou incompetentes. Se um atacante escalar privilégios para root (o que é trivial se ele já estiver dentro da máquina), ele pode alterar as permissões e deletar os arquivos. A verdadeira segurança exige que o próprio sistema de arquivos impeça o root de agir.

A segurança baseada em identidade (usuário/senha) falha porque identidades podem ser roubadas. A segurança baseada em capacidade do armazenamento (WORM - Write Once, Read Many) prevalece porque as regras físicas do disco (ou lógicas do filesystem) ignoram a identidade de quem está solicitando a exclusão.

Engenharia do repositório 'hardened': isolamento, XFS e o bit de imutabilidade

Aqui entramos na "carne" do projeto. Para construir um bunker digital, não precisamos de appliances milionários. Precisamos de um servidor x86 genérico, discos de alta capacidade (HDDs SAS/SATA para densidade) e uma distribuição Linux sólida (Ubuntu LTS ou RHEL/AlmaLinux).

O sistema de arquivos: XFS e Reflink

A escolha do sistema de arquivos é crítica. EXT4 é sólido, mas para repositórios de backup modernos, XFS é o rei. O motivo tem três letras: Reflink.

O XFS suporta nativamente a tecnologia de Reflink (Reference Link), que permite que múltiplos arquivos compartilhem os mesmos blocos físicos no disco. Em softwares de backup modernos (como Veeam Backup & Replication), isso habilita o recurso de "Fast Clone".

Quando o software de backup precisa sintetizar um backup completo (Full) a partir de incrementais anteriores, ele não precisa ler e reescrever terabytes de dados. Com XFS e Reflink, ele apenas manipula os metadados, apontando o novo arquivo para os blocos de dados já existentes no disco.

Benefícios diretos para o Storage:

1. Velocidade: Operações de mesclagem (merge) que levavam horas ocorrem em minutos.

2. Espaço: Um backup Full sintético ocupa quase zero espaço adicional no disco, pois são apenas ponteiros.

3. Vida útil do disco: Menos escritas físicas (I/O) significam menor desgaste, especialmente importante se você estiver usando SSDs para tiers de performance.

Fig. 2: A tecnologia Reflink do XFS permite que múltiplos backups compartilhem os mesmos blocos físicos sem duplicação.

O cadeado digital: Chattr +i

A imutabilidade no Linux pode ser alcançada através de atributos estendidos do sistema de arquivos. O comando chave aqui é chattr (change attribute).

Quando aplicamos o atributo +i (immutable) a um arquivo ou diretório:

• O arquivo não pode ser excluído.

• O arquivo não pode ser renomeado.

• Não é possível criar links para este arquivo.

• Nenhum dado pode ser escrito no arquivo.

O segredo do "Hardened Repository" é ter um serviço (daemon) que gerencia esses atributos. O software de backup escreve o arquivo de dados (.vbk ou .vib) e, assim que a escrita termina, o serviço aplica o atributo +i por um período definido (ex: 14 dias).

Durante esses 14 dias, nem mesmo o comando rm -rf executado pelo usuário root funcionará. Para remover a imutabilidade, o atacante precisaria ter acesso físico ao servidor, reiniciá-lo em modo de usuário único (single-user mode) e remover o atributo manualmente — um processo que dispara alarmes e exige presença física, algo que hackers remotos não possuem.

Isolamento de Credenciais

Para que isso funcione, o servidor Linux do repositório não deve fazer parte do domínio (Active Directory). Ele deve ser uma ilha. Além disso, o serviço SSH deve ser desabilitado ou configurado para aceitar apenas autenticação por chave, e as credenciais para esse servidor não devem ser armazenadas em nenhum gerenciador de senhas acessível pela rede corporativa. Use credenciais de uso único (Single-use credentials) para a instalação inicial e depois remova-as.

Teste de fogo: simulando um ataque de destruição

Teoria é linda, mas no mundo do storage, só acreditamos no que vemos falhar (ou resistir). Vamos simular o que acontece quando um script malicioso tenta purgar seu repositório endurecido.

Imagine que você acessou o terminal do seu repositório Linux. Você navega até a pasta onde estão os backups críticos de 50TB da sua empresa. O comando da morte é digitado:

sudo rm -rf /mnt/backup-repo/*

Em um repositório padrão (SMB/NFS ou Linux sem hardening), o cursor piscaria por alguns segundos e retornaria ao prompt. O silêncio indicaria que seus dados se foram.

Em um repositório XFS com imutabilidade ativa, o resultado é uma cascata de erros gloriosa:

rm: cannot remove '/mnt/backup-repo/Backup_Job_1.vbk': Operation not permitted
rm: cannot remove '/mnt/backup-repo/Backup_Job_1.vib': Operation not permitted
rm: cannot remove '/mnt/backup-repo/Meta.vbm': Operation not permitted

Fig. 3: O atributo de imutabilidade (+i) em ação, bloqueando a destruição de dados mesmo sob comando forçado.

O sistema operacional está protegendo você de si mesmo e de qualquer agente malicioso. O atributo de imutabilidade atua como um escudo no nível do kernel. Mesmo que o malware tente criptografar o arquivo (o que tecnicamente é uma reescrita), a operação de escrita (write) é bloqueada. O arquivo é somente leitura para todos, inclusive para o sistema.

💡 Dica Pro: A imutabilidade deve ser configurada com sabedoria. Se você definir todos os backups como imutáveis por 5 anos, seu storage encherá rapidamente e você não conseguirá deletar os backups antigos para liberar espaço. O ideal é alinhar a imutabilidade com sua política de retenção de curto prazo (ex: 7 a 30 dias) e usar fitas (LTO) ou Object Storage (S3 com Object Lock) para retenção de longo prazo.

O futuro é paranoico

Se você trabalha com infraestrutura e armazenamento, precisa aceitar uma verdade dura: sua rede já pode estar comprometida. O tempo de permanência (dwell time) médio de um atacante antes de ativar o ransomware é de dias ou semanas. Eles estão observando, aprendendo onde seus backups vivem.

Construir um repositório imutável com Linux e XFS não é apenas "boas práticas"; é a única barreira real entre a recuperação do negócio e a falência digital. Não confie em "ar-condicionado" de data center para proteger seus dados. Confie na matemática do sistema de arquivos e na rigidez do kernel Linux.

Mude sua postura hoje. Desmonte aqueles compartilhamentos SMB. Formate aquele volume em XFS. Ative a imutabilidade. E lembre-se: no final do dia, ninguém se importa com o backup, todos só querem saber se o restore funciona. Garanta que você tenha de onde restaurar.

Referências & Leitura Complementar

• Veeam Hardened Repository Guide: Documentação técnica sobre implementação de repositórios Linux imutáveis.

• Red Hat Enterprise Linux - XFS Documentation: Detalhes sobre alocação de blocos, reflink e tuning de performance para XFS.

• NIST SP 800-209: Security Guidelines for Storage Infrastructure - Padrões governamentais para segurança de armazenamento.

• Man pages (chattr & lsattr): Documentação oficial dos utilitários de atributos de arquivo do Linux.

Perguntas Frequentes

1. O XFS é obrigatório para ter imutabilidade no Linux? Não estritamente para a imutabilidade (que depende do sistema de arquivos suportar atributos estendidos), mas é altamente recomendado para performance. O recurso Reflink do XFS é o que viabiliza a economia de espaço com backups sintéticos (Fast Clone). Sem ele, a imutabilidade funciona, mas o consumo de disco será duplicado em operações de full backup.

2. Posso usar um NAS barato (QNAP/Synology) como repositório imutável? Depende. Se você usar o NAS apenas como "disco" (iSCSI) apresentado a um servidor Linux físico ou virtual que gerencia o sistema de arquivos XFS, sim. Se você tentar usar os recursos nativos de "WORM" ou "Lock" do sistema operacional do NAS, tenha cuidado: muitas implementações proprietárias de NAS têm backdoors de reset ou vulnerabilidades de firmware que um servidor Linux hardened bem configurado não tem.

3. O que acontece se o disco físico encher com arquivos imutáveis? O backup vai parar. E você não conseguirá deletar os arquivos antigos para liberar espaço até que o período de imutabilidade expire. Por isso, o monitoramento de capacidade (Capacity Planning) é crítico em repositórios imutáveis. Sempre dimensione seu storage com uma margem de segurança de 20-30% acima da retenção estimada.

4. O usuário root realmente não consegue deletar? No modo de operação padrão (multi-user), não. O comando chattr +i bloqueia o root. No entanto, alguém com acesso físico ao servidor (console) pode reiniciar a máquina, entrar em modo de recuperação/single-user e remover o atributo. Por isso, a segurança física do servidor (ou acesso ao console do hypervisor) também faz parte do conceito de "Bunker".