Atendo a uma empresa que trabalha com dados pra lá de sigilosos. Então me pediram pra arrumar um jeito de aumentar a segurança dos dados em disco, prevendo uma situação onde o computador ou o próprio HD pudesse vir a parar na mão de terceiros.
Criando um volume criptografado em partição ReiserFS
ATENÇÃO: Para acompanhar o artigo é necessário
ter o kernel 2.6.X ou superior em sua instalação Linux.
1 - Primeiramente verifiquemos se todos os componentes do
kernel necessários à criptografia estão devidamente instalados
carregando os módulos. Não precisamos lembrar que todo o
processo deve ser efetuado como root.
2 - Carregamos o cryptoloop com o comando:
# modprobe cryptoloop
3 - Carregamos o algoritmo de criptografia com o
comando abaixo; embora hajam outros, o twofish é um dos
mais rápidos e tem por default 128 bits de tamanho de
chave:
# modprobe twofish
4 - Caso não tenhamos criado a partição a ser criptografada,
esse é o próximo passo, no meu caso usei o cfdisk:
# cfdisk /dev/hdb
ATENÇÃO: Apenas crie a partição e não formate-a diretamente,
ela será formatada através do dispositivo de loop, se for
formatada diretamente a criptografia não surtirá qualquer
efeito.
5 - Para aumentarmos ainda mais a segurança, vamos antes de tudo
entupir a partição com LIXO, com o objetivo de tornar o volume,
ainda que criptografado, seja praticamente impossível de
distinguir o que é informação e o que é lixo.
# dd if=/dev/random of=/dev/hdb1
ATENÇÃO: Este procedimento é extremamente demorado, dependendo
do tamanho do disco rígido, caso deseje um pouco mais de rapidez,
use o parâmetro urandom ao invés de random.
6 - Criaremos agora o loop apontando para a partição em
questão. O sistema irá lhe pedir para criar uma senha, isso
somente ocorrerá uma única vez, não esqueça esta senha, pois
será praticamente impossível recuperar o conteúdo do volume
sem ela:
# losetup -e twofish /dev/loop0 /dev/hdb1
7 - Formate a partição através do dispositivo de loop com o
comando:
# mkreiserfs /dev/loop0
Usei o ReiserFS pois já é o sistema de arquivos default do
Slackware 10.1, que é a distro em questão. Outros sistemas
de arquivos podem ser usados sem qualquer problema.
[1] Comentário enviado por Tango em 01/05/2005 - 13:07h
Matéria interessantíssima! Apesar de tal metodologia ser geralmente desnecessário em computadores desktop caseiros, num ambiente corporativo isso é frequentemente necessário e NÃO IMPLEMENTADO. Algumas informações que senti falta são:
- Onde fica localizada a chave para o acesso à unidade?
- Se sim, em que estágio do acesso (Montagem? Leitura?) à unidade é requerida a senha?
No mais um artigo que cobre uma área utilíssima, mas pouquíssimo explorada, não só no Linux mas em quase todos os sistemas operacionais com essa capacidade.
[2] Comentário enviado por CapitainKurn em 01/05/2005 - 13:56h
Eu poderia ter feito um script para isso, ou usar um dispositivo usb para tal, so que isso gera um inconveniente, alguem poderia ter acesso ao script ou chaveiro usb. Por isso optei que ao se chegar pela manha o administrador monte o volume manulmente e insira sua senha.
Quando vocë levanta o dispositivo de loop ele pede uma passwd aotomaticamente. que deve ser igual a que foi criada quando voce criou o loop da primeira vez.
Mas valeu a observacao vou implementar uma forma mais amigavel de se fazer isso. Lembro ainda que saiu na Linux Magazine uma materia sobre isso embora eu a tenha achado um tanto incompleta.
[3] Comentário enviado por Tango em 01/05/2005 - 22:11h
Pelo que pude ver d processo, é simples e indolor, e ainda deve permitir (corrija-me se eu estiver errado) o uso de uma imagem ReiserFS como dispositivo de loop criptografado. Não sei se você percebeu (ou conhece o PGP), mas dessa forma é possível simular um comportamento extremamente semelhante ao PGPDisk, disponível em versões corporativas do PGP (http://www.pgp.com/).
Isso é um trunfo incrível. Por sinal, deixarei então você com esta dica, se for do seu interesse: um artigo sobre o uso de dispositivos criptografados em arquivos de imagem de filesystem.
[5] Comentário enviado por CapitainKurn em 02/05/2005 - 23:10h
Nunca implementei nada com PGP mas vou experimentar, mas o fato de eu haver feito o volume com uma ou melhor com duas partições Reiser foi o fato de serem mais imunes a corrupções do sistema de arquivos, também poderia ter feito um arquivão sendo montado como fs mas não julguei muito confiável além do fato de ter uma rotina de backup no crontab que sincroniza a cada 2 horas a /mnt/hda3 e a /mnt/hdb3 o pequeno servidor tem dois hds
[6] Comentário enviado por agk em 04/05/2005 - 10:23h
Parabéns excelente artigo. O artigo aborta um ponto muito importante e quase nunca observado pelos administradores de rede que é a segurança referente ao acesso local da máquina. Muitos se preocupam com os acessos remotos e nem ligam para a segurança local. Restringir o boot loader com senha até ajuda, mas pense, se tiver algum outro meio de dar boot no sistema, qualquer live-cd ou até uma mini-distro em disquete consegue entrar no sistema e obter acesso total ao seus preciosos arquivos.
[7] Comentário enviado por rufoz em 09/06/2005 - 22:07h
Interessante o seu artigo, no entanto é sim possível fazer isso com kernel 2.4.x, só que é necessário aplicar um patch tanto no kernel como no pacote util-linux.
O projeto chama-se loop-AES e é inclusive citado na referida matéria da Linux Magazine. O readme é beeem completo e contém informações muito detalhadass, informando inclusive como utilizar uma chave GPG como "senha" (continua existindo a possibilidade de uma senha, no caso a passphrase da chave)
Só uma dúvida, utilizando ReiserFS não pode haver inconsistencias no journal? Eu optei por utilizar ext2 devido a essa possibilidade, mas se não tiver nenhum problema com o journaling eu pretendo mudar
[9] Comentário enviado por leomarie em 13/12/2007 - 08:19h
Ótimo artigo!
Mas tive um probleminha... estou realizando a criptografia com kernel 2.6.23,
Recompilei o kernel com as opções aqui citadas, gerei o dd conforme informado, mas ao criar o Loop, digito a senha e ele me informa o seguinte erro:
- ioctl: LOOP_SET_STATUS: No such file or directory
[11] Comentário enviado por leomarie em 19/12/2007 - 11:44h
Bom. Resolvi o problema anterior, e consegui, aparentemente, criptografar a partição. Ao compartilhar a partição via Samba, criei um arquivo .txt com um conteúdo. Copiei o mesmo para uma outra maquina, local. Pelo que entendi do artigo, deveria estar criptografado o .txt, mas não é isso que acontece, consigo abrir e ler normalmente o mesmo. Sera que tem algo errado com minhas configurações?
[12] Comentário enviado por capitainkurn em 19/12/2007 - 16:37h
Nao... nao ha nada errado, quando vocë monta a particao criptografada ela fica inteiramente transparente para voce, o que ocorre e que voce nao conseguiria monta-la sem sua chave e se seu disco rigido fosse colocado em uma outra maquina para uma analise simplesmente seria impossivel montar a particao ou resgatar qualquer dado dela mesmo desmontada.
[13] Comentário enviado por leomarie em 19/12/2007 - 17:09h
Ah sim! mas pro samba, isso nao interfere entao! Bom. e nao tem uma forma de eu criptografar todos os arquivos usados em um compartilhamento samba?
É que meu caso, é parecido com o seu. Porém a empresa quer proteger os arquivos até mesmo dos próprios funcionários, tipo: O joão 'rouba' um projeto da empresa e envia por e-mail, copia num pendrive, etc.. mas quando vai abrir em outro computador, o arquivo pede a senha de criptografia, entende como eh?
Se tiver essa solução, ficaria grato.
[14] Comentário enviado por capitainkurn em 20/12/2007 - 12:17h
Um projeto de seguranca elaborado como o que voce precisa nao se faz assim, requer um trabalho de analise que pode ser mais ou menos demorado e conhecer os metodos de trabalho da empresa.
E nao basta so fazer implementacoes de hardware e software, e preciso adotar certos procedimentos no nivel social.
Eu presto estes servicos.
Mas a grosso modo voce poderia implementar um projeto de virtualizacao onde a " maquina" virtual totalmente isolada da sua rede manipularia os arquivos sigilosos ou seja somente entra ou sai da maquina virtual o que o administrador determinar.
Ex:
Uma estacao Linux ou mesmo windows em sua rede executaria uma maquina virtual que estaria em uma imagem em um servidor e esta por sua vez rodaria os aplicativos usados no projeto porem sem nehum contato com a rede ou mundo exterior.