Para evitar isso, o protocolo SSH possui um recurso muito interessante: a autenticação por meio de chaves públicas, que evita a necessidade de prover senhas durante a abertura de sessões SSH em máquinas remotas onde a chave pública do usuário já foi previamente copiada. Normalmente, esse processo se dá através da criação de um par de chaves criptográficas por meio do comando ssh-keygen, conforme apresentado no exemplo a seguir:

jansen@scadufax $ ssh-keygen -t dsa

Nesse caso, um par de chaves (pública e privada) está sendo criado usando-se o algorimo DSA. As chaves privada e pública, recém-criadas, são gravadas, nesse caso, nos arquivos id_dsa e id_dsa.pub, respectivamente, e ficam localizadas no diretório .ssh, dentro do home do usuário. Para se valer do recurso de não precisar prover senhas é preciso, então, copiar a chave pública para o arquivo .ssh/authorized_keys nos diretórios home dos usuários remotos, usando-se, por exemplo, o seguinte comando:

jansen@scadufax $ scp ~/.ssh/id_dsa.pub jsena@smeagol:~/.ssh/authorized_keys

Nesse caso, quando o usuário jansen, a partir da máquina scadufax, tentar abrir uma sessão SSH com o usuário jsena na máquina smeagol, nenhuma senha será necessária. O processo de autenticação se dará através das chaves criptográficas. Até nenhuma novidade, certo? Entretanto, imagine que mais de um usuário deseje acessar a conta jsena na máquina smeagol. Pode até ser a mesma pessoa utilizando um par de chaves criptográficas diferentes do anterior, gerado, por exemplo, em outro computador. Nesse caso, se o mesmo procedimento anterior for utilizado, o arquivo authorized_keys, que já contém a chave pública de outro usuário, será sobrescrito, passando a invalidar o acesso cadastrado anteriormente. Para evitar esse problema, a partir do segundo usuário, seria necessário adotar outros procedimentos para a cópia da chave-pública de forma a não sobrescrever o conteúdo já existente no arquivo authorized_keys.

Para facilitar esse processo, existe um utilitário chamado ssh-copy-id que é desconhecido por uma parcela considerável dos usuários de SSH. Essa pequena ferramenta resolve esse problema da cópia de diversas chaves para um mesmo arquivo authorized_keys:

jansen@scadufax $ ssh-copy-id jsena@smeagol

Caso seja necessário copiar outras chaves para acessar a conta jsena na máquina smeagol, basta utilizar o mesmo comando. Caso um mesmo usuário tenha mais de um par de chaves (sim, isso é possível), pode-se indicar quais delas se deseja copiar para a máquina remota:

jansen@gandalf $ ssh-copy-id -i .ssh/id_rsa.pub jansen.sena@boromir

Simples, não? Bem, acho que é isso.

IMPORTANTE: Para que o mecanismo de autenticação através de chaves públicas funcione corretamente, é necessário que o servidor SSH esteja configurado para tal. Mas isso é assunto para outro momento!

Para verificar algumas das informações comumente reveladas por um servidor Web aos clientes que conectam-se a ele, basta utilizar o antiquado mas ainda útil telnet. Nesse caso, é suficiente escolher um site qualquer, direcionar a conexão para a porta 80 e submeter ao servidor algumas das poucas informações obrigatórias do protocolo HTTP (GET e Host, por exemplo), conforme mostrado a seguir:

# root@scadufax:~# telnet www.xxxxx.com.br 80
Trying 201.123.123.121...
Connected to server.xxxxx.com.br.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.xxxxx.com.br

Após a cláusula “Host”, pressione duas vezes Enter. Em seguida, o servidor Web deve retornar os cabeçalhos HTTP de resposta e o conteúdo da página, de acordo como mostrado abaixo:

HTTP/1.1 200 OK
Date: Fri, 08 Jul 2011 00:47:40 GMT
Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny10 with Suhosin-Patch
Last-Modified: Thu, 20 Apr 2006 18:44:51 GMT
ETag: "9f132-c96-411e12ad8aec0"
Accept-Ranges: bytes
Content-Length: 3222
Content-Type: text/html; charset=ISO-8859-1

<<< CONTEÚDO DA PÁGINA>>>

Dentre os cabeçalhos de resposta, dedique atenção especial ao “Server”, em destaque. Nele, é possível identificar o servidor Web (Apache), sua versão (2.2.9), o sistema operacional (Debian) e ainda a versão do PHP (5.2.6-1+lenny10). Tais informações já ajudam um atacante a escolher quais ferramentas ele poderá ajudar em um eventual ataque. Pior ainda: o atacante consegue descobrir se seu servidor encontra-se completamente desatualizado e, portanto, possivelmente vulnerável contra um conjunto maior de exploits. Revelar essas informações no cabeçalho “Server” é o comportamento mais comum para um servidor Apache instalado diretamente dos repositórios de pacotes de sua distribuição.

Outra forma de identificar se o servidor está revelando mais informações do que deveria consiste simplesmente em provocar algum erro, acessando, por exemplo, uma página que, certamente, não existe naquele servidor Web:

http://www.xxxxx.com.br/abcdefghijklmnop

Servidor Apache revelando informações desnecessárias.

Normalmente, em sites mais bem configurados, as páginas de erro são todas customizadas. Nesses casos, algumas vezes, as informações sobre o servidor não são apresentadas.

Surpreso? É nesse estado que se encontra seu servidor? Bem, então é hora de corrigir esse problema.

O Apache possui duas configurações bem simples mas que são costumeiramente ignoradas, fundalmentalmente pelos administradores de sistemas menos experientes: ServerTokens e ServerSignature que podem impedir que o servidor revele informações mais detalhadas no cabeçalho “Server” do HTTP e que informações desnecessárias sejam apresentadas nas páginas de erro default do Apache, respectivamente. Para fazê-las desempenhar essas funções, basta adicioná-las no arquivo de configuração do Apache da seguinte maneira:

ServerTokens Prod
ServerSignature Off

Depois, reinicie o seu servidor Apache e veja se agora, seu servidor passou a “falar” um pouco menos…

Logicamente que existem muitas outras providências a serem tomadas para fazer um bom trabalho de hardening de um servidor Apache. Entretanto, deixaremos isso para uma outra oportunidade.

Bem, acho que é isso. Até o próximo post.

Bem, primeiramente, permita que eu me desculpe por ‘descortinar’ essa verdade caso você ainda achasse, até o parágrafo anterior, que um “rm -f” era um comando forte e com tanta ‘personalidade’ ao ponto de mandar pro espaço qualquer arquivo ou diretório. O fato é que ao remover um arquivo com esse comando o sistema operacional, em poucas palavras, simplesmente retira os “ponteiros” para os blocos de dados que formavam o arquivo. Por outro lado, esses blocos estão lá em seu HD e podem, com a ajuda de algumas ferramentas, ser recuperados. Provavelmente esses blocos irão ser sobrescritos apenas quando novos arquivos forem utilizando aqueles mesmos espaços e isso pode demorar um tempo bastante considerável principalmente se o computador em questão não tiver operações um fluxo de gravação de arquivos muito intenso.

E, antes que você se pergunte, mas quem pode ter acesso ao meu HD? Bem, fácil. Seu computador pode ser invadido através da Internet, você pode perdê-lo, você pode ser roubado, você pode vendê-lo ou você pode mandá-lo para uma assistência técnica para consertar um problema, por exemplo. Enfim, são muitas as possibilidade, não é verdade? Pior ainda quando se está falando dos pequenos e portáteis pen drives que carregamos conosco o tempo todo para todo lugar. Quando é possível, pode-se utilizar os sistemas de arquivos criptografados. Entretanto, em situações onde não é possível utilizar essas soluções, é preciso tomar cuidado para garantir que arquivos sensíveis foram, de fato, removidos.

A notícia boa é que existe um “irmão” do rm que pode ser utilizado para fazer a remoção de arquivos cujo conteúdo você deseja manter longe das mãos dos curiosos. Trata-se do shred. E sabe o qué melhor? Provavelmente ele já encontra-se instalado em seu sistema GNU/Linux mesmo que você nunca o tenha utilizado. Vamos, então, dar uma olhada nesse comando?

Suponnha que você tenha um arquivo com algum dado sensível:

$ echo "Esse arquivo possui dados secretos." > /tmp/segredo.txt
$ cat /tmp/segredo.txt
Esse arquivo possui dados secretos.

Em seguida, utilize o comando shred simplesmente indicando o arquivo recém-criado:

$ shred /tmp/segredo.txt

E agora, tente dar uma olhada no conteúdo do arquivo utilizando o comando cat:

$ cat /tmp/segredo.txt

E aí, surpreso com o que você viu?

Caso você deseje que o shred remova o arquivo após “bagunçar” seus dados você pode utilizar a opção “-u”. E ainda, se quiser acompanhar de perto o que o shred está fazendo durante seu período de execução basta acrescentar, como em muitos outros comandos dos sistemas Unix, o parâmetro “-v”. Então, experimente executar o shred com a seguinte sintaxe:

$ shred -u -v /tmp/segredo.txt

shred: /tmp/segredo.txt: pass 1/3 (random)...
shred: /tmp/segredo.txt: pass 2/3 (random)...
shred: /tmp/segredo.txt: pass 3/3 (random)...
shred: /tmp/segredo.txt: removing
shred: /tmp/segredo.txt: renamed to /tmp/00000000000
shred: /tmp/00000000000: renamed to /tmp/0000000000
shred: /tmp/0000000000: renamed to /tmp/000000000
shred: /tmp/000000000: renamed to /tmp/00000000
shred: /tmp/00000000: renamed to /tmp/0000000
shred: /tmp/0000000: renamed to /tmp/000000
shred: /tmp/000000: renamed to /tmp/00000
shred: /tmp/00000: renamed to /tmp/0000
shred: /tmp/0000: renamed to /tmp/000
shred: /tmp/000: renamed to /tmp/00
shred: /tmp/00: renamed to /tmp/0
shred: /tmp/segredo.txt: removed

É interessante notar que durante sua execução, o shred preencheu o conteúdo do arquivo três vezes com dados aleatórios e depois, antes de removê-lo, o comando renomeou o arquivo 11 vezes.

Para promover um processo um pouco mais seguro, você pode ainda selecionar o número de interações que o shred irá fazer substituindo o conteúdo do arquivo utilizando o parâmetro “-n <qtde>”. Por exemplo:

$ shred -n 25 -u -v /tmp/segredo.txt

Observe que, nesse caso, alternou o processo de substituição do conteúdo com alguns padrões fixos e dados aleatórios. Outra opção interessante até para “esconder” a ação do shred é solicitar que depois de todas as interações, ele substitua os dados do arquivo com zeros. Isso pode ser feito por meio da adição do parâmetro “-z”:

$ shred -n 25 -u -v -z /tmp/segredo.txt

Como “tudo” em sistemas GNU/Linux (Unix, na verdade) é representado por meio de arquivos, você pode utilizar o shred como uma ferramenta para apagar HDs ou outros dispositivos de armazenamento inteiros. Isso pode ser útil quando você vai repassar esse equipamento para outra pessoa. Para isso, basta passar como argumento o arquivo que representa o seu dispositivo de armazenamento. Por exemplo:

# shred -n 30 -v -z /dev/sda

Duas observações importantes aqui: primeiro, essa operação, salvo alguma configuração prévia, requer privilégios de root (observe o prompt como “#” no exemplo anterior). Segundo, tome muito cuidado para não passar o dispositivo errado e apagar coisas erradas! Ou seja, esse comando não é recomendado se você não estiver em paz e bem tranquilo!

Sim, é certo que com algum investimento em tecnologias mais avançadas de hardware e software, é possível recuperar dados mesmo que eles tenham sido sobrescritos diversas vezes.

Quem lida com um terminal de comandos em ambientes Linux frequentemente, especialmente através do bash, sabe o quanto o histórico de comandos é útil. Ele economiza ao longo do dia um bom tempo de digitação ajudando com a reutilização de comandos que já foram executaados anteriormente. Com alguns atalhos disponibilizados pela própria shell é possível tirar proveito ainda mais eficiente desse poderoso recurso, útil aos administradores de sistemas e a todos os usuários que necessitam do terminal. Além de facilitar a utilização, o histórico de comandos também é uma ferramenta importante para conduzir algumas investigações do que pode ter sido feito em um determinado sistema, uma vez que ele mostra a sequência de comandos executados. Para vê-lo, como muitos já estão cansados de saber, basta executar o comando “history”.

E o que tem de novidade nisso? Nada a não ser pelo fato de que, muitas das vezes, os horários em que os comandos foram executados podem representar uma valiosa informação para quem está consultando o histórico. Essa informação torna-se ainda mais importante quando se tenta correlacionar comandos executados em computadores diferentes. O que poucos sabem, entretanto, é que isso é possível de configurar utilizando um recurso muito simples disponibilizado pela prória shell bash. Outra novidade? Essa informação está na própria man page da bash.

Para habilitar esse recurso, basta, por exemplo, abrir um terminal e definir a variável de ambiente HISTTIMEFORMAT por meio da execução do seguinte comando:

$ export HISTTIMEFORMAT="[%y%m%d %H:%M:%S] "

Feito isso, experimente executar o comando “history” novamente… Interessante, não? Note que você pode definir o formato e quais informações de tempo mais lhe interessam. Para tal, utilize a mesma representação de tempo implementada no comando date.

Para fazer com que os históricos de comandos sempre apresentem as informações de tempo, insira a definição dessa variável nos arquivos apropriados do seu sistema como os arquivos .bashrc e .bash_profile que ficam nos diretórios home dos usuários, por exemplo.

Bem, é isso.

Essas facilidades, entretanto, aumentam em muito a possibilidade de se perder esses equipamentos ou mesmo tê-los furtados por outra pessoa. Ainda que sejam arquivos de natureza pessoal, tais como fotos, e-mails e outros documentos, a maioria das pessoas não gostaria de ver esses arquivos em mãos erradas, não é mesmo? Trocando o contexto para o meio corporativo, o comprometimento de informações pode inviabilizar projetos, negócios, estratégias e até a própria sobrevivência da instituição. Por outro lado, são poucas as pessoas e as instituições que têm implementados mecanismos que possam proteger as informações contra a perda ou o roubo dos meios de armazenamento. A grande maioria prefere sofrer com o arrependimento e com as lamentações quando perdem seus dados e os deixam expostos sem qualquer proteção para evitar que os mesmos sejam acessados (e explorados) livremente.

A boa notícia é que existem recursos muito simples para instalar e configurar alguns mecanismos e ferramentas para melhorar a confidencialidade de suas informações. Dentre os diversos recursos e ferramentas disponíveis, uma das mais eficazes são os sistemas de arquivos criptografados e, em ambientes GNU/Linux é algo simples de fazer. A seguir, compartilho uma das maneiras que costumo utilizar para criar, rapidamente, sistemas de arquivos criptografados. Vamos lá?

Irei tomar como referência o Ubuntu Linux. Entretanto, respeitadas as diferenças no processo de instalação dos pacotes necessários, o restante do processo é semelhante em outras distribuições. Em tempo, o processo a seguir mostra os procedimentos utilizando-se utilitários de linha de comando. Com isso, esse mesmo processo pode ser utilizado para criar sistemas de arquivos criptografados em servidores e/ou desktops da mesma maneira.

O primeiro passo consiste em instalar os pacotes necessários. Para tal, a partir de um terminal com privilégios de super-usuário, execute o seguinte comando:

# apt-get install cryptsetup cryptmount

Em seguida, supondo que você reservou a partição /dev/sda5 para criar o seu sistema de arquivos seguro, o próximo passo consiste em formatá-la já considerando a camada de criptografia. Esse processo irá exigir a inserção de uma “frase-senha” que irá proteger o sistema de arquivos. Portanto, a segurança de seus dados será proporcional à força dessa senha. Esse passo deve ser executado por meio do comando abaixo:

# cryptsetup luksFormat /dev/sda5

WARNING!
========
This will overwrite data on /dev/sda5 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:

IMPORTANTE: Caso você esteja criptografando o conteúdo de um pen drive ou de qualquer outro dispositivo de armazenamento que já contenha um sistema de arquivos convencional e que seja, por conta disso, montado automaticamente em seu ambiente, tome o cuidado de desmontá-lo antes de prosseguir com as configurações. Caso contrário, o comando “cryptsetup luksFormat” irá falhar!

Observe que, antes de solicitar a senha, o comando irá confirmar se pode prosseguir sua execução uma vez que esse processo irá sobrescrever todos os dados que possam estar, eventualmente, presentes nessa partição. Para confirmar, é necessário responder com “YES” (em caixa alta). Logo depois, a “frase-senha” e sua respectiva confirmação são solicitadas.

Uma vez criado o sistema criptografado, é necessário “abrir” o dispositivo de forma que ele possa ser acessado como um device convencional e que, portanto, possa conter um sistema de arquivos como o ext3, por exemplo. Isso deve ser feito através do seguinte comando que irá solicitar a “frase-senha”:

# cryptsetup luksOpen /dev/sda5 MYCRYPT
Enter passphrase for /dev/sda5:
Key slot 0 unlocked.

Executado esse comando, o sistema operacional deve ter criado um dispositivo chamado /dev/mapper/MYCRYPT que é, na verdade, um dispositivo normal de armazenamento como outro qualquer e que pode, portanto, ser formatado. Entretanto, nesse caso, os dados armazenados em /dev/mapper/MYCRYPT são salvos, fisicamente, no sistema de arquivos criptografado criado em /dev/sda5. Em outras palavras, uma vez que seus meios de armazenamento caiam em mãos erradas, o que o “novo dono” terá acesso é um monte de dados criptografados que não representam nada (a não ser que você tenha deixado sua “frase-senha” à mostra em algum lugar).

Para formatar o sistema de arquivos mapeado com ext3, por exemplo, utilize o próprio comando mkfs.ext3:

# mkfs.ext3 -L MYCRYPT /dev/mapper/MYCRYPT

Criado o sistema de arquivos, monte-o normalmente para poder começar a salvar seus dados mais sensíveis:

# mount  /dev/mapper/MYCRYPT /media

No Ubuntu Desktop, o processo de montagem também pode ser feito pela própria interface gráfica. Ou seja, após criar e formatar o sistema de arquivo, ao acessar a opção Places (Lugares) na barra superior, já é possível ver o reconhecimento do dispositivo criptografado recém-criado. Ao selecionar esse disco, o próprio ambiente gráfico já solicita a senha para montagem do dispositivo.

Voltando pra linha de comando, após utilizar o sistema de arquivos seguro, você deve desmontá-lo e, em seguida, desfazer o mapeamento criado entre o dispositivo criptografado (/dev/sda5) e o mapeado (/dev/mapper/MYCRYPT):

# umount /media

# cryptsetup luksClose MYCRYPT

Para explorar mais funcionalidades tais como trocar ou adicionar senhas para o sistema de arquivos criptografos, consulte a man page do comando cryptsetup.

Existem ainda opções para fazer com que o sistema de arquivos criptografado seja montado automaticamente todas as vezes que o usuário efetua o seu login no sistema. Isso pode ser feito por meio do PAM combinado com outras configurações. Mas, vamos deixar isso pra uma outra oportunidade.

Espero que essa dica seja, de alguma maneira, útil e que, depois dela, seus dados mais críticos recebam a proteção que eles merecem!

]]> http://www.jsena.info/2010/10/24/criando-um-sistema-de-arquivos-criptogrado-no-gnulinux/feed/ 1 http://www.jsena.info/2009/10/09/palestra-de-seguranca-no-latinoware-2009/ http://www.jsena.info/2009/10/09/palestra-de-seguranca-no-latinoware-2009/#comments Fri, 09 Oct 2009 14:41:10 +0000 Jansen Sena http://www.jsena.info/2009/10/09/palestra-de-seguranca-no-latinoware-2009/ Infelizmente, por motivos profissionais, não tive como participar da memorável décima edição do FISL (Fórum Internacional de Software Livre) em Porto Alegre. Entretanto, mesmo não tendo estado presente, por todos os relatos que recebi e por ter conhecimento a respeito da competência dos organizadores, tenho certeza que foi um grande evento e uma conquista para o movimento de software livre no Brasil por ter um fórum desse porte chegando em sua décima edição.

Entretanto, se por um lado não foi possível participar do FISL, evento que já frequento há vários anos,  por outro, irei ter a oportunidade de conhecer um evento de software livre que ainda não havia participado mas que sempre tive vontade de colaborar e conhecer: o Latinoware. O evento acontece entre os dias 22 e 24 de outubro no Parque Tecnológico Itaipu (PTI) em Foz do Iguaçu e, até o momento, dia 09 de outubro, já conta com 3348 inscritos.

A convite de meu grande amigo Júlio Neves, minha participação no Latinoware 2009 será por meio da palestra de segurança "Port Knocking? Esqueça. Abrindo as portas remotamente no iptables com o Single Packet Authorization" que será apresentada na sala Florestan Fernandes (Bloco 13, Sala 1) no dia 23/10/2009 às 13:00. Na palestra será realizada, inicialmente, uma discussão a respeito do Port Knocking, uma técnica utilizada por administradores de sistemas para abrir, por demanda, as portas bloqueadas de um firewall, suas vantagens, suas desvantagens e vulnerabilidades. Com base nesses aspectos é que o Single Packet Authorization (SPA) será apresentado como uma alternativa mais segura, eficiente, robusta e de fácil implementação. Esse é um recurso bem simples e eficiente para ajudar administradores de sistemas a evitar a exposição desnecessária de portas de serviços cujo acesso é restrito, como por exemplo, um servidor SSH de um servidor púbilico utilizado apenas por um conjunto reduzido de usuários para fins de manutenção e monitoria.

Outras palestras bem interessantes estão publicadas na grade de programação do Latinoware. Para verificar, basta clicar AQUI.

Abaixo segue o resumo da palestra. Nos vemos por lá!

Port Knocking? Esqueça. Abrindo as portas remotamente no iptables com Single Packet Authorization

Uma forma de impedir que atacantes explorem servidores remotamente consiste em bloquear o acesso às suas portas, liberando-as por demanda conforme a necessidade de acessá-las. Essa técnica, quando utilizada, costuma ser implementada por meio do mecanismo de port knocking. Entretanto, essa técnica contém um conjunto de limitações que podem torná-la pouco eficiente e ainda sujeita a ataques. A palestra apresenta o SPA (Single Packet Authorization) e sua implementação em ambientes GNU/Linux com alternativa ao port knocking.

A Internet é, atualmente, o termômetro mais importante e instantâneo da sociedade da informação. Em outras palavras, análises da rede mundial de computadores podem refletir, com uma razoável margem de certeza, os próprios interesses, as opiniões, os questionamentos e as ações de muitos segmentos sociais. Nesse contexto, quanto mais amplo for o nível de certos acontecimetnos, maior deve ser o impacto na Internet. Caso contrário, o falecimento de Michael Jackson, no último dia 25 de junho, não teria provocado tantas consequências quase que instantâneas na grande rede.

Tão logo começaram a ser publicadas as suspeitas de que o astro do pop havia falecido, o tráfego na rede mundial aumentou de maneira considerável chegando, em alguns momentos, a derrubar diversos sites de notícias e buscas ao redor do mundo , reflexo de quão grande era o interesse coletivo em torno dos acontecimentos envolvendo Michael Jackson. O mesmo aconteceu em outras oportunidades em acontecimentos como os atentados de 11 de setembro, por exemplo.

Obviamente que, criptografia não se resume apenas a confidencialidade, que corresponde ao mecanismo de tornar restrito o acesso à alguma informação contida em um arquivo, por exemplo. Entretanto, esse é um dos seus serviços mais populares. Partindo de um exemplo muito simples e didático. Suponha que, em um arquivo texto, você guarde algumas senhas importantes para acesso a sistemas sobre sua administração. É mais do que prudente evitar que o conteúdo desse arquivo seja exposto facilmente e, nesse caso, confiar apenas nos recursos de controle de acesso do sistema de arquivo não é, certamente, uma prática muito segura.

Para essa finalidade é possível "criptografar" esse arquivo utilizando-se uma senha, simplesmente por meio do seguinte comando:

myhost$ gpg -c /home/user/passwords.txt

Em seguida, será solicitada uma senha e sua posterior confirmação. A proteção do conteúdo do seu arquivo será proporcional à complexidade da senha utilizada em seu processo de cifragem. Portanto, não escolha senhas fracas e fáceis de serem exploradas. O resultado da execução do comando anterior é a geração de um arquivo com mesmo nome daquele informado como parâmetro acrescido da extensão ".gpg". O arquivo original, a partir desse momento, pode ser descartado:

myhost$ rm /home/user/passwords.txt

Para obter o arquivo original novamente, deve-se "descriptografar" o conteúdo do arquivo /home/user/passwords.txt.gpg. Para isso, basta utilizar o seguinte comando:

myhost$ gpg -d /home/user/passwords.txt.gpg > /home/user/passwords.txt

Tão logo a senha utilizada no processo de cifragem seja inserida, o arquivo original será recuperado imediatamente. Esse mesmo recurso pode ser utilizado para "criptografar" arquivos de quaisquer formatos. Suficientemente simples para não deixar mais arquivos críticos desprotegidos em seu sistema de arquivos, não?

Vale lembrar que no exemplo apresentado utiliza-se criptografia simétrica, ou seja, tudo que é feito com uma chave (senha) é desfeito com a mesma chave. Portanto, é importante saber que se você esquecer a senha utilizada para criptografar um arquivo não será mais possível recuperar seu conteúdo.

O GPG tem muitos outros recursos interessantes, tais como a utilização de criptografia assimétrica, assinatura digital, dentre outros. Vale a pena conhecer!

Nesse caso, como vilão, entenda-se como sendo qualquer praga virtual (vírus e worms, por exemplo) capaz de expor os problemas de segurança dos sistemas produzidos pela gigante do software proprietário. Nesse contexto, a bola da vez é o Conficker, uma praga que tem uma arquitetura bem interessante de ser discutida e que, pelo seu impacto, tem provocado bastante dor de cabeça. Exatamente por isso, esse será o tema do texto da coluna  "Segurança High-tech" na Edição No. 86 da Revista PC&CIA, publicação nacional da qual sou colaborador há alguns anos.

Interessado em acompanhar essa discussão? Basta aguardar um pouco a Revista chegar às bancas…