Storage criptografado em roteador residencial
Autor: * Coffnix
"Home Network Defense"
Utilize criptografia pra tudo
Motivo
Atualmente, existem muitas soluções de armazenamento projetadas para compartilhar arquivos em redes domésticas e empresariais. No entanto, muitas delas não priorizam mecanismos robustos de segurança. Portanto, para atender aos padrões de segurança desejados, é frequentemente necessário recorrer a soluções de terceiros, a nível de sistema operacional. Um exemplo notável é a criptografia de arquivos usando LUKS.
Requisitos
Adquira um storage que ofereça um volume de rede por meio de NFS ou SMB/CIFS, bem como um dispositivo externo USB.
MacOS que suporte HFS+ (opcional).
Linux com suporte a LUKS e ao módulo hfsplus.
Configuração do Storage ou Roteador
Para este exemplo, utilizaremos o roteador Archer GX90 (AX6600). Crie um novo usuário e defina uma senha robusta. Altere a senha do usuário guest ou, se preferir, desative-o.
Configuração do Dispositivo de Armazenamento USB
A grande maioria dos roteadores modernos suporta os sistemas de arquivos HFS+, NTFS, FAT32 e exFAT. Dada a necessidade de otimização de performance e aprimoramento da segurança dos dados, optaremos pelo HFS+. No entanto, se você encontrar um dispositivo que também suporte EXT4, este é igualmente recomendável, sendo um sistema de arquivos robusto e adequado para essa finalidade.
Formatação do Dispositivo de Armazenamento
Para formatar o dispositivo, o utilitário Diskutil no macOS é altamente recomendado. No entanto, ferramentas como parted, cfdisk e outras podem ser alternativas viáveis. Após a formatação, monte o disco em seu sistema local e proceda à criação de um arquivo vazio com as dimensões desejadas. Em nosso exemplo, trabalhamos com um disco USB de 1TB destinado a backups do Time Machine, e o arquivo criado possui 400GB.
Este procedimento é aplicável tanto no macOS quanto no Linux. Se necessário, ajuste o caminho de destino em of=/Volumes/wd-1tb/storage_file.img para refletir o diretório correto de montagem. A escolha de bs=10M foi feita considerando que o cliente deste volume de disco será um Raspberry Pi com processador ARMv8 rodando Linux, se comunicando via rede sob protocolo CIFS, com um roteador com processador Broadcom, ou seja, ambos bem lentos. Configurações como bs=512 ou bs=1M poderiam resultar em consumo elevado de CPU e rede, comprometendo a performance. Essas decisões exigem que você considere que o tempo de sistema da CPU é inversamente proporcional ao valor do block size. Isto é, quanto menor o bs, mais chamadas de sistema são geradas pelo comando dd e pelo uso em si do volume de disco.
Para sistemas de armazenamento mais robustos, com clientes de alto desempenho, pode ser benéfico experimentar valores menores para bs, como bs=1M. Em situações específicas com dispositivos de baixo desempenho, como cartões MMC, já utilizei valores extremamente reduzidos, como bs=4 (sim, apenas 4 bytes), atingindo taxas de transferência de até 12MB/s. Em contextos de HDD SATA, SCSI ou SAS ou para criação de imagens para LiveCD, geralmente emprego bs=512.
Execute o comando abaixo para criar o arquivo de imagem de disco:
root # dd if=/dev/zero of=/Volumes/wd-1tb/storage_file.img bs=10M count=40960
Após criar o arquivo, desmonte o disco e conecte-o ao roteador via porta USB. Ative o compartilhamento SMB e o Time Machine caso deseje utiliza-lo.
Monte o volume CIFS no Linux
Para acessar os recursos compartilhados via CIFS fornecidos pelo roteador, siga os passos abaixo. No exemplo em questão, o volume designado pelo roteador é "G" e seu endereço IPv4 é 192.168.20.1. É fortemente recomendado optar pelo protocolo CIFS em detrimento do SMBFS, dadas as vantagens em termos de estabilidade, eficiência no uso de cache e outros benefícios. O protocolo suportado pelo roteador é vers=2.0. Caso esteja utilizando um roteador mais antigo, você pode tentar usar vers=1.0, embora isso seja desaconselhado devido às vulnerabilidades de segurança associadas a essa versão. Adicionalmente, sugiro não configurar a montagem automática via /etc/fstab, uma vez que isso pode resultar em complicações durante o processo de inicialização.
root # mount -t': mount -t cifs //192.168.20.1/G /storage -o username=coffnix,password=area31@lalala,iocharset=utf8,vers=2.0
Caso deseje, adicione a seguinte linha no /etc/fstab:
//192.168.20.1/G /tp-share cifs username=coffnix,password=area31@lalala,iocharset=utf8,vers=2.0,noauto 0 0
Criação e Montagem da Imagem Encriptada com LUKS
Para aumentar a segurança, é fortemente aconselhado separar o cabeçalho (header) da imagem LUKS do restante da imagem. Armazene este cabeçalho localmente no diretório /etc/area31/headerstore. Não se esqueça de escolher uma senha robusta para proteger seus dados.
Visto que usaremos um raspberry Pi com seu ArmV8 Cortex-A72 sem suporte a AES (AES-NI), usaremos a cipher ChaCha20 (que tende a ser rápida em CPUs e SoCs sem aceleração AES) e a função de hash SHA-512 (que pode ter um bom desempenho em arquiteturas de 64 bits)::
root # mkdir -p /etc/area31/headerstore ; cryptsetup luksFormat --force-password --type luks2 --cipher twofish-xts-plain64 --hash sha512 --key-size 256 /tp-share/storage_file.img --align-payload 8192 --header /etc/area31/headerstore/header.img
Caso use CPU com suporte a AES opte por usar algo mais seguro:
root # mkdir -p /etc/area31/headerstore ; cryptsetup luksFormat --force-password --type luks2 --cipher aes-xts-plain64 --hash sha512 --key-size 512 /tp-share/storage_file.img --align-payload 8192 --header /etc/area31/headerstore/header.img
Em seguida, monte o volume LUKS utilizando a senha definida anteriormente:
root # cryptsetup open --header=/etc/area31/headerstore/header.img /tp-share/storage_file.img storage_file_luks
Caso queira montar o volume sem utilizar senha, basta criar um arquivo de chave para o LUKS:
root # mkdir -p /etc/area31/keys ; dd bs=512 count=4 if=/dev/random of=/etc/area31/keys/storage_file_luks.key
Você também pode criar o arquivo de chave utilizando openSSL:
root # mkdir -p /etc/area31/keys ; openssl genrsa -out /etc/area31/keys/storage_file_luks.key 4096
Corrija a permissão do arquivo de chave, adicione ao LUKS e monte o volume utilizando a chave criada:
root # chmod 400 /etc/area31/keys/storage_file_luks.key root # cryptsetup luksAddKey /tp-share/storage_file.img /etc/area31/keys/storage_file_luks.key --header /etc/area31/headerstore/header.img root # cryptsetup open --key-file /etc/area31/keys/storage_file_luks.key --header=/etc/area31/headerstore/header.img /tp-share/storage_file.img storage_file_luks
Se quiser visualizar as informações detalhadas do LUKS, execute:
root # cryptsetup status storage_file_luks
Ou
root # cryptsetup luksDump /tp-share/storage_file.img --header /etc/area31/headerstore/header.img
Formatação e Montagem do LUKS
O comando mkfs.ext4 é usado para criar um sistema de arquivos EXT4, que é uma versão avançada e amplamente utilizada do sistema de arquivos extensível. Ao criar um sistema de arquivos, especialmente um de grande tamanho, como uma imagem de 400GB gerada pelo dd, a inicialização padrão do sistema de arquivos pode ser um processo demorado.
A opção -E lazy_itable_init é particularmente útil neste contexto. Quando esta opção é ativada, a inicialização das tabelas de inode do sistema de arquivos é adiada até o primeiro montagem. Em outras palavras, em vez de inicializar todos os inodes durante a criação do sistema de arquivos, essa tarefa é adiada e realizada de forma preguiçosa, ou "lazy", em segundo plano, após o sistema de arquivos ser montado.
Ao não usar a opção -E lazy_itable_init, o processo de criação do sistema de arquivos pode se tornar extremamente lento, pois o mkfs.ext4 tentará inicializar todos os inodes imediatamente. Em uma imagem de 400GB, isso pode levar horas. Portanto, ao utilizar a opção -E lazy_itable_init, você está otimizando o processo de criação, tornando-o significativamente mais rápido.
Em resumo, o -E lazy_itable_init serve para acelerar o processo de criação de sistemas de arquivos em volumes grandes, adiando a inicialização das tabelas de inode para após a primeira montagem e realizando-a de forma incremental em segundo plano.
Após ter montado o volume CIFS, proceda à formatação do arquivo utilizando o sistema de arquivos EXT4 ou qualquer outro de sua preferência.
root # mkfs.ext4 -E lazy_itable_init /dev/mapper/storage_file_luks
Com o volume devidamente formatado, realize sua montagem:
root # mkdir -p /storage ; mount -o noatime,nobarrier /dev/mapper/storage_file_luks /storage
Se achar conveniente, pode adicionar este ponto de montagem ao /etc/fstab, usando a opção "noauto" para prevenir montagem automática e "nobarrier" por questões de performance:
/dev/mapper/storage_file_luks /storage ext4 noatime,nobarrier,noauto 0 2
Considerações sobre o "nobarrier" e "noatime" utilizado na montagem do EXT4
Ao optar pela opção "noatime" durante a montagem de um volume, você desativa a atualização dos registros de acesso (atime) dos arquivos. Isso pode proporcionar uma melhoria significativa na performance, pois o sistema não precisará registrar cada vez que um arquivo é lido.
Vantagem: Ao usar "noatime", o sistema de arquivos se torna mais rápido, especialmente em operações intensivas de leitura, porque evita escritas desnecessárias no disco.
Desvantagem: Alguns aplicativos, embora raros, podem depender da informação de "atime" para funcionar corretamente. Desativando o "atime", você pode perder a capacidade de rastrear a última vez que um arquivo foi acessado.
Dessa forma, é importante considerar as necessidades do seu sistema e os possíveis efeitos colaterais antes de optar por usar a opção "noatime".
Sobre o "nobarrier", convém contar uma historinha.... Antigamente, pra ser mais sincero a mais de 15 anos atrás, servidores Linux que utilizavam o sistema de arquivos Ext4, rodando um kernel Linux versão 2.6.32 ou superior, poderiam experimentar baixa performance e um alto valor de load average.
Alguns discos rígidos, mesmo os SCSI de "alta performance" da época, em situações de queda de energia, não conseguiam gravar completamente as informações contidas em seu cache de gravação. Isso poderia resultar em arquivos corrompidos e perda de dados. Até o kernel 2.6.31, o sistema de arquivos Ext4 apenas garantia que as informações haviam sido enviadas ao HD, sem necessariamente assegurar sua gravação permanente. No entanto, a partir do kernel 2.6.32, houve uma mudança: o Ext4 passou a assegurar que os dados foram, de fato, gravados no disco, minimizando o risco de corrupção de arquivos em quedas de energia. Esta mudança, embora positiva em termos de integridade dos dados, teve como consequência uma redução significativa na performance de certos softwares, como o PostgreSQL e Mysql.
Até hoje, a prática comum de mercado para servidores que possuem proteção contra quedas de energia, como no-breaks e UPSs, e que usem sistemas de arquivos Ext4 é de desativar o "barrier". Isso é feito desativando a verificação de escrita de dados via kernel ao montar o volume com a opção -o nobarrier.
Entretanto, ao optar pela opção "nobarrier", é essencial estar ciente dos riscos. Desativar o "barrier" pode comprometer a integridade dos dados, especialmente em situações de falha de energia ou crashes do sistema. O "barrier" é uma proteção que verifica se a escrita do dado foi bem-sucedida, garantindo a ordem das gravações no disco e proporcionando uma proteção adicional contra corrupção de dados. Ao desativar o "barrier", você prioriza a performance em detrimento da segurança dos dados. Portanto, é altamente recomendável avaliar cuidadosamente suas necessidades de performance e os riscos associados antes de desativar esta funcionalidade.
Conclusão
Com estas etapas concluídas, você possui um volume de rede montado no seu Linux, criptografado e com todas as vantagens do sistema de arquivos escolhido. Estas podem incluir funcionalidades como XATTR (atributos estendidos), Journaling, e suporte a CHATTR no caso do EXT4. Para um nível adicional de segurança, é sugerido utilizar o arquivo do cabeçalho LUKS de uma localização remota, obtendo-o via SCP (SSH).
