Ambiente "Auto-Limpante" via Virtualização Ultra-Leve Descartável

Aqui na Tempest criamos uma versão personalizada do Ubuntu integrada com o Linux-VServers para rodar as aplicações (navegador, email, etc.) em "servidores virtuais" isolados que podem ser recriados em segundos. Por serem "descartáveis", quaisquer malwares contraídos durante seu uso são destruídos quando da sua recriação, conferindo um caráter "auto-limpante" ao sistema. No artigo de hoje, cumprirei uma antiga promessa de descrever, comentar e, melhor ainda, disponibilizar essa solução, na forma de uma máquina virtual do VMWare que o leitor poderá baixar e usar no seu próprio computador.

O foco deste artigo é nos resultados e consequências da solução já pronta; os detalhes técnicos de como montá-la ficarão para artigos futuros. Tentei manter o texto acessível a uma audiência ampla, enfatizando mais as características conceituais de "alto nível" e os pontos mais visualmente perceptíveis. Não resisti a salpicar alguns detalhes técnicos pelo texto afora para atiçar o apetite dos leitores mais tecnicamente inclinados, mas eles podem ser ignorados sem prejuízo para o entendimento da essência do texto.

Introdução

Para os impacientes, a idéia básica é tornarmos o software dos computadores algo como os copos descartáveis: nós os jogamos fora após cada uso – assim, germes ou vírus morrem no descarte. Tal como um copo descartável recém tirado da embalagem, cada vez que reiniciamos nossas aplicações elas estarão no estado que estavam imediatamente após terem sido instaladas – que é o momento em que podemos ter mais certeza de que elas não têm vírus nem foram "invadidas".

Em mais detalhes – imagine que você tivesse dois computadores:

  • Um que você só usasse de vez em quando para acessar seu banco via Internet e mais nada.
  • Um que você usa todo dia, inclusive para acessar aqueles sites duvidosos cheios de anúncios e popups irritantes – mas você jamais usa seu banco via Internet nele.

Parece natural esperar que o primeiro computador se mantenha livre de vírus por bastante tempo, posto que ele só é usado ocasionalmente, para uma finalidade muito restrita e para acessar sites "de boa reputação."

Na mesma linha, seria natural esperar que o segundo computador acabe sendo infectado com mais frequência. Digamos que, por isso mesmo, você nem se dê ao trabalho de passar o anti-vírus nele; ao invés, você simplesmente o resintala do zero a partir das mídias originais cada vez antes de usá-lo.

Como são dois computadores isolados, o vírus que infecta seu computador de navegação geral não tem acesso imediato ao computador que você usa para acessar o banco via Internet. Claro, também não é uma garantia absoluta de que o vírus jamais vai chegar lá, mas pode ser uma barreira considerável que lhe compra tempo – talvez justamente o tempo até você reinstalar de novo o computador que tinha o vírus.

Se levada ao pé da letra, essa idéia parece boa na teoria mas inconveniente na prática – você teria de andar com dois notebooks, além de que reinstalar tudo a partir do zero toma um tempão e dá uma trabalheira danada.

Acontece que, usando a tecnologia da virtualização ultra-leve, é possível fazer esses dois computadores caberem confortavelmente dentro um computador real. Na realidade, dá pra colcar dezenas de "computadores" virtuais, a ponto de podermos chegar ao cúmulo de criar uma máquina virtual para cada aplicativo – e isso tudo de forma a não consumir nem memória, nem processador, nem disco demais, ficando assim tão rápido quanto um sistema convencional.

Além disso, também é possível fazer com que reinstalação das máquinas virtuais (e os aplicativos dentro dela) ocorram de forma totalmente automática e levem poucos segundos, viabilizando esse conceito de "computador descartável". É exatamente isso que vamos demonstrar.

Baixando e Instalando a Máquina Virtual de Demonstração

Para que o leitor possa acompanhar tudo isso que vamos discutir neste artigo, preparamos uma máquina virtual com uma demonstração 100% funcional desse sistema de virtualização, clonagem e descarte. Naturalmente, você pode continuar lendo este artigo sem instalar a demonstração, mas será bem mais divertido e proveitoso se o fizer. Os requisitos são poucos:

  • O VMWare Player, que você pode baixar daqui. É gratuito, mas você terá de se registrar no site deles. (Naturalmente, também funciona nos outros produtos da VMWare, como o Server, Workstation, etc. Também funciona no VirtualBox se você configurar manualmente, pois as versões mais recentes são capazes de ler os arquivos .vmdk criados pelo VMware.)

Além disso, você vai precisar de uns 10GB de espaço em disco livre. A memória da máquina virtual está dimensionada como 512MB, de sorte que a demonstração deve rodar em qualquer computador com 1GB de memória ou mais.

Para instalar a demonstração, faça o seguinte:

  • Baixe este arquivo, que é o pacote de 1,5GB com a máquina virtual do VMWare compactada com o 7zip
  • Usando o 7zip, descompacte o arquivo para dentro da pasta de VMs do VMWare (ficará com 5,5G após descompactado);
  • Execute o VMWare, abra a pasta que que acabou de descompactar e dê "play" para dar partida à máquina virtual;

Executando a Demonstração

Ao executar a máquina virtual pela primeira vez, o VMware provavelmente mostrará uma mensagem tal como a abaixo:

Responda a opção padrão "I Copied".

Terminado o processo de "bootstrap" da máquina virtual, você se deparará com a tela de login padrão do GNOME que vem com o Ubuntu 10.04. Clique no usuário "guest", mas não digite a senha ainda.

O idioma padrão do sistema está para Inglês, mas nesse momento você pode clicar no seletor de idiomas no canto inferior esquerdo, tal como mostrado na figura abaixo. Se desejar, escolha "Português (Brasil)":

Mas você pode deixar em inglês mesmo, se quiser.

Por fim, clique na caixa de digitação da senha, que é demovs ("demonstração dos 'virtual servers'"). Caso você tenha pedido para trocar o idioma para Português, o Ubuntu vai lhe perguntar se você quer mudar os nomes dos diretórios padrão para esse idioma, tal como na figura abaixo. Responda como quiser, tanto faz.

Deve aparecer ainda uma mensagem de boas vindas:

A Primeira Aplicação Virtualizada

Vamos aceitar o convite proposto pela mensagem que aparece na figura acima. Examinando os ícones no painel principal do GNOME, no canto superior da tela, vemos algo como o seguinte:

Clique no ícone do "Firefox Miscelâneo". Em uns cinco segundos (dois, se você estiver usando um SSD) aparecerá uma janela como essa:

Como a propria mensagem da tela inicial do navegador já explica, aconteceu muito mais do que apenas "abrir o navegador". O que realmente aconteceu "por debaixo dos panos" é que o sistema deu partida em uma nova máquina virtual chamada ffox_misc, com seu sistema operacional próprio e, dentro dela, foi dada a partida no navegador.

Poderíamos obter o mesmo efeito com dois computadores conectados em rede: um rodando o servidor X com o desktop do GNOME e outro rodando o navegador. Pra isso, valemo-nos do fato que o Sistema de Janelas X é, antes de tudo, um protocolo de rede e foi projetado desde o princípio para suportar esse tipo de operação remota. Precisaríamos configurar o servidor X para aceitar conexões de rede via TCP1 e ajustar seu sistema de permissões para aceitar conexões remotas. Foi exatamente isso que fizemos ao preparar essa demonstração, exceto que os dois computadores são virtuais, coabitando o mesmo "computador real" graças à virtualização ultra-leve.

Quem também segue essa filosofia de ser um serviço de rede é o PulseAudio, que controla o subsistema de som do computador. Nessa máquina de demonstração, nós o configuramos para aceitar conexões via TCP2 e configuramos a máquina virtual ffox_misc para mandar o som pra lá.

O resultado combinado desses serviços de rede é que a "emenda" as máquinas vsdemo e ffox_misc fica visualmente quase indistinguível do que seria se o navegador estivesse rodando mesmo na máquina vsdemo. Repare na figura que a única dica visual denunciando o que realmente ocorre é uma sutil mensagem no final da barra de título dizendo "(em ffox_misc)"3.

Os usuários que já usaram Ubuntu provavelmente notarão que não há nenhuma diminuição perceptível na velocidade e fluidez no uso do navegador virtualizado em relação a um sistema convencional sem virtualização. Aqui você começa a entender porque nós a chamamos de "virtualização ultra-leve". Mais adiante você verá que esse "ultra-leve" é um conceito multifacetado que se aplica a vários outros quesitos também.

O que se ganha virtualizando o navegador? Ganha-se isolamento, ou, para usar um termo técnico mais empolado, "sandboxing": ao melhor estilo "cada um no seu quadrado", o que acontecer nesse navegador praticamente não afetará as outras máquinas virtuais nem a máquina real.

Clones Descartáveis

Podemos levar a idéia de máquinas virtuais isoladas a um extremo curioso: podemos criar uma máquina virtual com uma ou mais aplicações quaisquer (vamos usar o novamente exemplo do navegador) e usá-la como "matriz" para uma série de clones descartáveis. Para ver isso funcionando na nossa demonstração, clique no ícone do "Firefox para Sites Bancários":

Esse aí demora um pouco mais para abrir, algo como uns 10 a 15 segundos (um terço disso se você estiver usando um SSD). Isso porque o que realmente está sendo feito é que uma nova máquina virtual está sendo copiada a partir de uma matriz chamada ffox_bank.

Os clones são máquinas virtuais completas e independentes; como tais, são isoladas de todas as demais máquinas virtuais, inclusive de seus próprios irmãos. Quando a janela abre, o que realmente abre é o clone, e não a matriz:

Repare que no final da barra de título aparece um texto "(em ffox_bank_xxxxxxxx)", onde o "xxxxxxxx" são vários dígitos numéricos diferentes cada vez que você clica novamente no ícone de partida.

Na máquina principal vsdemo, instalamos um programa "coletor de lixo", executado de um em um minuto, que remove clones que já não estejam mais em uso (naturalmente, deixando as matrizes e demais máquinas virtuais intactas).

Essa clonagem e descarte nos permite conferir às nossas máquinas virtuais (e aplicações hospedadas dentro delas) aquele caráter semelhante ao dos copos descartáveis: a cada uso temos um "novo", sobre cujo estado inicial temos algumas garantias.

Se porventura, durante o uso da máquina-clone, visitarmos algum site que se aproveite de alguma vulnerabilidade no navegador para infectar nosso sistema, a "infecção" ficará contida dentro daquela máquina virtual e (na presumida ausência de falhas no isolamento provido pela virtualização) não poderá se espalhar para as demais máquinas virtuais nem para o sistema principal. E, melhor ainda: quando o clone for descartado, o software invasor também será destruído automaticamente.

Em outras palavras, usamos a virtualização para minimizar o ciclo de vida efetivo do malware invasor: no sistema virtualizado, as infecções são passageiras, limitados ao próprio tempo de vida efêmero das máquinas-clone. Contraste isso com um sistema não virtualizado: nele, a infecção dura muito mais tempo porque a reinstalação total é infrequente por ser incômoda (e por cima disso tipicamente se acrescenta o incômodo extra do anti-vírus, que por vezes não resolve.)

Mapa Geral e Outras Demonstrações

Recomendo que o leitor experimente os outros ícones do menu principal, que dão acesso a outras aplicações, algumas delas com máquinas virtuais configuradas de diferentes maneiras. Para ajudá-lo a se orientar, segue um diagrama da disposição das aplicações versus máquinas virtuais:

A área cinza no diagrama representa a sua máquina real e nela você tem um sistema operacional qualquer, seus aplicativos, pastas e arquivos. Nela você instalou o VMWare, que implementa um hipervisor de virtualização de hardware abaixo da camada do sistema operacional. Por isso, seu sistema pode ser um Windows ou MacOS e mesmo assim poderá rodar essa demonstração (cujo sistema operacional subjacente é um Linux) sem problemas.

Ou seja: na realidade, estamos usando duas soluções de virtualização; a primeira é o VMWare. A segunda é o Linux-VServers. Esta última usa a abordagem de "contêineres", que, por ser integrada ao sistema operacional (o Linux, no caso), permite um reuso muito mais aprofundado de disco e memória, que é responsável pelo seu caráter "ultra-leve". Por outro lado, todos os contêineres compartilham o mesmo núcelo ("kernel"). Isso significa que eles só podem rodar Linux; não podem rodar Windows ou outros sistemas operacionais.

Note que fazemos uso do VMWare só para você poder rodar nossa demonstração sem precisar desinstalar seu sistema já existente. Se você instalasse a nossa máquina vsdemo nativamente em seu computador (que é como a gente usa aqui na Tempest), não haveria necessidade do VMWare em absoluto.

Continuando a análise do diagrama: a área laranja clara representa a nossa máquina virtual vsdemo que está rodando "dentro" do VMWare. Nela instalamos um Ubuntu Linux 10.04.4 "Lucid Lynx", mas trocamos o núcleo que vem por padrão no Ubuntu por um outro especial do projeto Linux-VServers que acrescenta a tal virtualização ultra-leve via "contêineres". O resto do software na máquina vsdemo é um Ubuntu relativamente comum, apenas com alguns acréscimos que criamos para integrar os servidores virtuais "filhos" ao ambiente gráfico e ao subsistema de rede.

Como a figura mostra, dentro da vsdemo existem oito servidores virtuais (na realidade, a figura omite mais três sobre o qual vou falar em um outro artigo). Os que têm os nomes em amarelo estão configurados para operar no modo de clonagem+descarte que descrevemos na seção anterior; os demais estão configurados para execução direta.

Dentre esses oito servidores virtuais, já abordamos dois deles: o ffox_misc e o ffox_bank. Existem mais dois outros vservers com navegadores:

  • O ffox_corp: é muito semelhante ao ffox_misc, no sentido que ele roda diretamente, sem clonagem a partir de uma matriz. Por isso, os dados do navegador (favoritos, histórico, cache, senhas armazenadas, etc.) são preservados. Todavia, a idéia é usá-la exclusivamente para sites internos (o "portal" ou "intranet") da sua empresa/instituição. O benefício principal aqui é o isolamento da navegação "para a Internet pública" feita no ffox_misc.

  • O ffox_dirty é parecido com o ffox_bank no sentido que ele é recriado a partir de uma matriz, de sorte que tudo nele é descartado cada vez que for fechado. Todavia, o ffox_dirty implementa uma camada de isolamento a mais: ao invés da aplicações nele contidos falarem diretamente com o servidor X principal da máquina vsdemo, elas o fazem por intermédio de um programa chamado Xephyr. Se algum malware tipo "gravador de teclado" (keylogger) ou que tire "screenshots" da tela for executado, ele só conseguirá acessar o que está dentro da janela do Xephyr e não tudo mais que estiver no seu desktop – mantendo, digamos, a senha e o teclado virtual do site de banco via Internet (que você deveria usar apenas através do ffox_bank) fora do alcance.

Políticas de Uso

Já que o ffox_dirty é o servidor virtual com a maior quantidade de técnicas de proteção e isolamento, algumas pessoas me pergutam por que não usá-lo para navegação em geral, ao invés do ffox_misc. A resposta é: nada lhe impede de fazer isso, se quiser. Trata-se de uma política de uso que você precisa definir. A questão é o balanceamento "segurança versus conveniência": por ser recriada a partir da matriz cada vez que é disparada, a ffox_dirty não preserva favoritos, logins/senhas, etc., ao passo que a ffox_misc preserva.

Como as instruções que aparecem quando você abre os navegadores já dizem, as políticas de acesso sugeridas são mais ou menos essas:

  • O ffox_corp deve ser usado para acessar apenas a "intranet" da sua empresa/instituição;
  • O ffox_bank deve ser usado apenas para os sites de banco via Internet;
  • O ffox_dirty deve ser usado para sites "duvidosos" que você suspeite que carreguem malware e que você não se importa que os favoritos, histórico, etc., não sejam preservados;
  • O ffox_misc deve ser usado para navegação em geral nos sites "de boa reputação" que você frequenta;

Instalamos diferentes temas para particularizar cada navegador de cada servidor virtual com esquemas de cores e adornos visuais que facilitem o reconhecimento instintivo instantâneo. Se todos os navegadores fossem visualmente idênticos (o que seria natural dado que todos foram instalados a partir de um mesmo pacote), confundi-los seria corriqueiro.

Mas, como dissemos, essas as políticas de uso listadas acima são apenas sugestões, de uso totalmente voluntário. Não há realmente nada que impeça o usuário de violá-las.

Não seria muito difícil implementar mecanismos que analisassem os endereços sendo acessados pelos navegadores e bloqueassem os acessos que não se enquadrassem na política. De fato, fizemos isso nos notebooks da gente aqui na Tempest. Só não coloquei isso nessa demonstração porque exigiria uma configuração relativamente complexa que eu queria evitar em um artigo introdutório como este.

Os Outros Servidores Virtuais

Voltando ao nosso diagrama: além dos vservers dos navegadores, há também um chamada evolution contendo programa homônimo do GNOME para uso de correio eletrônico, contatos e "groupware" (um equivalente ao "Outlook", para a galera Windows). Essa máquina virtual naturalmente precisa preservar estado e não está sujeita a clonagem/descarte.

O diagrama também mostra que há um vserver chamado libreoffice que engloba os seis programas da suite LibreOffice (equivalente ao Microsoft Office do Windows): o editor de textos Writer, a planilha eletrônica Calc, o editor de slides e apresentações Impress, o banco de dados Base, o editor de desenhos Draw e o editor de equações Math.

Para ilustrar o fato que os VServers podem rodar outras distribuições de Linux, há ainda um vserver onde instalamos o Slitaz, uma distribuição minimalista (a imagem do CD de instalação tem meros 30MB e o sistema completo cabe em 200MB) que tem feito muito sucesso recentemente. Para executá-la, peça a opção "Aplicativos", "Outros", "Servidor Virtual com o Slitaz 4.0rc2";

Se quiser, você pode criar outros servidores virtuais com o outras distribuições do Linux, tais como um Fedora, CentOS, ArchLinux, Gentoo, Slackware, entre outras.

Unificação

O fato de quase todos os vservers (todos menos o slitaz4) usarem o mesmo sistema-base (um Debian 6.0.4 "Squeeze") se traduz em uma economia enorme de espaço em disco: empregamos um recurso chamado "unificação" que faz com que arquivos idênticos em diferentes vservers ocupem uma vez só o espaço em disco – isso apesar de cada vserver achar que tem o aquivo exclusivamente para si só.

Se você está curioso para saber como isso é possível, aqui vai a essência da idéia: arquivos unificados nada mais são do que hard-links com um bit extra (só honrado nos kernels com suporte a vservers) que faz com que qualquer tentativa de alterá-los "quebre o link", realizando uma cópia completa de seus conteúdos antes da alteração ser feita. Ou seja, é uma forma de "copy-on-write" implementada no nível do sistema de arquivos.

Por isso, a unificação não compromete o isolamento: se algum vserver precisar alterar algum arquivo unificado, o kernel automática e transparentemente o "desunificará", fazendo uma cópia dele que, então, ocupará outro lugar no disco.

Além disso, os arquivos unificados também efetivam uma economia no consumo de memória, pois o segmento de texto deles só é carregado uma única vez. Este é o segredo do caráter "ultra-leve" da virtualização por contêineres, e é uma das razões pelas quais você pode abrir todas as aplicações da nossa demonstração simultaneamente e elas cabem confortavelmente em 512MB de memória.

Desvantagens e Inconvenientes

Vale lembrar que o isolamento implica em que cada vserver não enxerga os arquivos do outro. Isso alguns inconvenientes de usabilidade, dentre os quais podemos citar:

  • Se você estiver no Evolution e clicar em um link dentro do texto de uma mensagem, ele não abrirá automaticamente o navegador. Há uma solução simples mas ligeiramente inconveniente: você terá de copiar o link pela área de transferência ("clipboard") e colar na barra de endereços do navegador desejado.

  • Ainda sobre o Evolution: se você receber um anexo e quiser abri-lo no LibreOffice, terá de movê-lo manualmente da pasta de recebimentos do Evolution para a dentro da pasta do LibreOffice. E vice-versa: se quiser enviar um documento do LibreOffice via um anexo de email, terá de copiá-lo para a pasta do Evolution. Naturalmente, essa cópia precisa ser feita fora de todos os vservers, na máquina vsdemo, pois o isolamento impede que um vserver possa enviar arquivos para outro.

É possível escrever programas que realizem essas operações de cópia e movimento de dados automaticamente. Todavia, é importante lembrar que há várias fraudes via email que enviam URLs-armadilha; e que arquivos anexos em email são batidíssimos vetores de ataques. Por isso, o ideal seria ou que o usuário inspecionasse manualmente cada um desses itens, ou que isso fosse intermediado por um programa que realizasse essa inspeção, checando os endereços contra "listas negras" ou aplicando filtros de conteúdo mais sofisticados.

Iniciativas Correlatas

O conceito de "máquinas virtuais" seus benefícios de isolamento certamente não são idéias novas; de fato, elas remontam à era dos mainframes dos anos 1960 e, ao longo das décadas, passaram por vários ciclos de reencarnação. Mas foi só no final dos anos 90 que o VMWare foi pioneiro em oferecer uma solução de virtualização para PCs com desempenho bom o bastante para uso diário, baseado nos conceitos de virtualização de hardware e hipervisores. A esteio do sucesso do VMWare vieram outras soluções como o VirtualBox e o Parallels. No mundo do software livre surgiram o Xen e o Linux KVM.

Por mais bacana que a virtualização baseada em hipervisores seja, ela é "pesada", no sentido em que consomem bastante disco e memória. Apesar dos notebooks de hoje terem gigabytes de memória e terabytes de disco, rodar muito mais do que quatro ou cinco máquinas virtuais simultaneamente já deixa os computadores lentos e saturados. Presta para uso ocasional, mas deixa a desejar para uso constante no dia-a-dia. Não obstante, já é suficiente para usar um pouco desse paradigma de "máquinas descartáveis", como propus em um artigo de alguns anos atrás como solução para evitar vírus no Windows.

A abordagem de virtualização por contêineres também tem uma longa história. Ela remonta à célebre chamada chroot(3) do Unix, que permite fazer com que diferentes programas enxerguem apenas um subconjunto da árvore de arquivos e diretórios. O Openwall Linux talvez tenha sido um dos primeiros a adotar a idéia usar cada serviço de rede isolado com o chroot4. O FreeBSD estendeu o conceito de chroot para criar as famosas "jails" ("jaulas"). O Solaris também seguiu a onda, criando um recurso chamado de "zones", posteriormente renomeados para "Solaris Containers". Por serem intimamente ligados ao sistema operacional, essas soluções já tinham muito das características "ultra-leves".

Há pouco mais de dez anos, surgiu o projeto Linux-VServers (na época ainda sob o kernel 2.4), responsável por elevar o conceito de contêineres a novas dimensões, estendendo o isolamento para processos e rede, além de fazer bom uso dos "capabilites" do Linux para impedir métodos clássicos de burlar o isolamento.

Outros projetos seguindo linhas semelhantes são o OpenVZ e o Linux Containers. Mas até onde sei (faz tempo que eu não mexo com esses caras), eles não têm o recurso de "unificação" que o Linux-VServers tem e que dá o caráter "ultra-leve" essencial para viabilizar dezenas ou até centenas de servidores virtuais rodando em uma máquina real relativamente modesta.

Aqui na Tempest nós já vínhamos usando vservers há uns sete anos em aplicações para "servidor". Mas só de uns anos pra cá nos demos conta do seu potencial para revolucionar a segurança em ambientes desktop também – seu caráter ultra-leve é especialmente adequado para implementar os conceitos de "uma máquina virtual (ou quase) para cada aplicação" e de "clones descartáveis".

Certamente não somos os únicos a estar trabalhando nesse conceito: o Qubes OS tem muitas similaridades com essa nossa iniciativa, mas usando o Xen como tecnologia de virtualização subjacente. É uma abordagem interessante, mas, sem o recurso de unificação, a sobrecarga de disco e memória provavelmente será maior.

Conclusões

Em artigos vindouros, vou discorrer em detalhes sobre os fundamentos técnicos que viabilizaram essa solução – vou explicar a teoria e prática por trás dos Linux-VServers, a unificação que viabiliza o caráter "ultra-leve", como integramos os servidores virtuais com o ambiente desktop, etc.

E há muito trabalho ainda pela frente:

  • Como comentei anteriormente, toda a segurança depende de não haver brechas no isolamento. É preciso agregar a competência dos caçadores de vulnerabilidades para achar essas brechas e expurgá-las. É preciso lembrar que vulnerabilidades (tais como essa ou essa) têm demonstrado que a qualidade do código sendo aceito no kernel do Linux precisa melhorar.

  • É preciso ajustar as interfaces de usuário para eliminar as inconveniências do intercâmbio de dados entre os diferentes contêineres, mas de uma forma que não crie brechas que acabem por inutilizar os benefícios do isolamento.

Não obstante, esperamos ter convencido o leitor de que a virtualização ultra-leve provê uma solução prática com um balanceamento "segurança vs desempenho" particularmente interessante e hoje talvez sem paralelo. Estou tentando angariar adeptos para transformar esse esquema em uma "distro" completa. Se quise ajudar, poste um comentário e junte-se a nós!

Agradecimentos: João Paulo Campello deu várias dicas úteis de melhorias neste artigo e na infra de software da VM de demonstração. Paulo Silva me deu a dica que o VirutalBox consegue abrir a VM de demonstração perfeitamente bem.



1 no Ubuntu isso vem desativado "de fábrica", mas pode ser ativado manualmente; quando ativado, ele atende na porta 6000/TCP. [ voltar ]

2 isso também vem desabilitado por padrão; mas, após ativado, ele atende nas portas 4671/TCP e 16001/TCP. [ voltar ]

3 Mostrar de que máquina a conexão vem é uma cortesia do Metacity, o gerenciador de janelas padrão do GNOME 2. Se você trocá-lo pelo Compiz (ao ativar os efeitos visuais avançados), essas mensagens desaparecerão. Todavia, você pode ativá-los novamente no Compiz Settings Manager, caregoria "Title Bar Info", aba "General", item "Show Remote Machine Name" [ voltar ]

4 Nota histórica: na realidade, os servidores ftp do Unix já usavam chroot muito antes disso para prover o servço de 'ftp anônimo' [ voltar ]

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Pimps | 2012-06-22 12:06:07 | permalink | topo

Kiko,

Parabéns pelo post, ficou muito bom mesmo!

Abraço.

Marco Carnut | 2012-06-21 17:17:47 | permalink | topo

Tímido,

Isso depende de que informações, exatamente, tal o "módulo de proteção" colhe da máquina. Se for o nome, talvez dê diferença. Se for endereço MAC ou parâmetros semelhantes, daria a mesma coisa. Só analisando os detalhes técnicos e testando. Quem sabe alguns dos outros leitores possam compartilhar suas experiências nesse sentido.

Eu estou entre aqueles que ligaram pro SAC do banco exigindo que desligassem esse treco. Portanto, não sou afetado por isso.

O que eu também posso afirmar é que, se funcionar, tem de ser feito no "ffox_bank" usado como "matriz", para que seja automaticamente refeito toda vez a cada recriação do clone.

-K.

Tímido Visitante Anônimo | 2012-06-21 16:50:53 | permalink | topo

Os sites de bancos geralmente pedem para instalar um "módulo de proteção" em java. Esse módulo reconhece seu computador com um ID (único), que tem que ser habilitado na agência (ou terminal, ou via sms).

A minha dúvida é se nesta sua solução eu vou consigo manter o ID cadastrado na agência. Acredito que, em cada execução do ffox_bank, o sistema do banco vai reconhecer como um novo computador.

Marco Carnut | 2012-06-21 16:41:56 | permalink | topo

Victor,

Err,.. confesso que eu catei o link no Google e não assisti o video todo. :) Obrigado pelo link correto, corrigi no corpo do texto.

-K.

Victor Hora | 2012-06-21 16:27:27 | permalink | topo

Kiko,

Segue um vídeo que mostra o exploit efetivamente funcionando:

https://www.youtube.com/watch?v=TiI8MJbtpJI

Victor Hora | 2012-06-21 14:55:09 | permalink | topo

Kiko,

Muito bom o artigo. Bastante compreensível. O lance da VM pronta para testes, foi uma sacada muito boa.

A crítica fica para o link da primeira vulnerabilidade (http://www.youtube.com/watch?v=4kMZ7VBFOJw), o vídeo não mostra o exploit funcionando :)