Virtualização é a simulação de um hardware/software que roda sobre outro software.

Este conceito de ambiente simulado é chamando de máquina virtual (VM – Virtual

Machine) [Scarfone et al.2011].

O conceito de virtualização, apesar de ser muito comentando atualmente, não é

novo. As técnicas de virtualização já eram aplicadas em mainframes lançados pela IBM.

Existem registros do uso da virtualização de meados de 1960, quando a IBM

desenvolveu o M44-44X, um sistema operacional experimental [Laureano e Maziero

2008]. A partir daí a própria IBM investiu no conceito e lançou outras versões de

sistemas operacionais voltados para a virtualização, por exemplo o OS/370.

Na década de 1980, com a popularização de plataformas de hardware baratas

como o PC, a virtualização perdeu importância. Afinal, era mais barato, simples e

versátil fornecer um computador completo para cada usuário do que investir em

sistemas de grande porte, caros e complexos [Laureano e Maziero, 2008]. Porém, a

virtualização voltou à tona em meados de 1990, quando os equipamentos/ambientes

passaram a ter um poder de processamento melhor, surgindo a partir daí tecnologias

inovadoras por diversas empresas, sendo as mais notórias a VMware e Microsoft.

Basicamente, a virtualização permite que as organizações possam trabalhar com

diversas plataformas de software (sistemas operacionais) não havendo necessidade de

aumento no número de máquinas físicas. Ou seja, a virtualização permite um alto nível

de flexibilidade e portabilidade. Com isso desmitificou-se a ideia de que para um novo

serviço de TI a ser implantado em um ambiente era necessário uma máquina física

nova.

Outra característica deste tipo de tecnologia é o compartilhamento dos recursos

de hardware (processador, memória, interface de rede, disco, etc.) do host físico com

todas as máquinas virtuais ali presentes. Por exemplo, caso um host possua quatro

processadores, ele pode compartilhar um processador com cada uma das quatro

máquinas virtuais.

Todo o gerenciamento e alocação de recursos de hardware de uma máquina

virtual é feito pelo Hypervisor ou Monitor de Máquina Virtual (VMM – Virtual

Machine Monitor). O Hypervisor é uma camada de software localizada entre a camada

de hardware e o sistema operacional. É, também, responsável por controlar o acesso do

sistema operacional visitante (máquina virtual) aos dispositivos de hardware. Ele

também deve prover recursos que garantam a segurança das máquinas virtuais através

de mecanismos como isolamento, particionamento e encapsulamento.

A virtualização é dividida, basicamente, em paravirtualização e virtualização

completa. Na completa, o hypervisor simula todo o hardware da máquina física,

fazendo com que as máquinas virtuais executem de forma isolada. Em outras palavras, o

hypervisor emula todo o hardware para as VMs, fazendo com que o sistema operacional

execute como se não estivesse em um ambiente virtual. Sua vantagem é a larga

aceitação por parte de diversos tipos de sistemas operacionais.

Já a paravirtualização entrega para as VMs um hardware igual ao real, com isso

o sistema a ser virtualizado pode sofrer alterações no decorrer do tempo. Funcionalidade

que a virtualização completa não permite, já que nela o hardware é entregue de forma

virtual. A principal característica da paravirtualização é o desempenho, ou seja, sua

facilidade em se adaptar às modificações do sistema operacional devido a sua

similaridade com o hardware real.

A virtualização contribuiu para o desenvolvimento e aprimoramento de outras

tecnologias já existentes, fazendo com que elas se aperfeiçoassem, tais como: sistemas

operacionais, componentes de hardware, storage e rede.

Com os avanços desta tecnologia, as técnicas e melhorias em segurança em

ambientes deste tipo também tiveram que ser aperfeiçoadas e recriadas para garantir a

integridade e segurança de dados e hardware.

O objetivo deste trabalho é analisar ambientes virtualizados quanto à segurança,

trazendo à tona assuntos às vezes incomuns quando se fala de virtualização. Este

trabalho pretende verificar o quanto o hypervisor é seguro. Para isso, identificará

possíveis brechas para ataques, descreverá quais são estes ataques e as contramedidas

oferecidas pelas soluções disponíveis no mercado.

Em complemento, este trabalho também objetiva estabelecer um contraponto

entre as tecnologias existentes, mostrando como algumas tratam a temática da segurança

e como as organizações podem se precaver de incidentes e ameaças.

Este artigo possui mais 5 seções, além da introdução. Na seção 2 é apresentada

uma visão geral do hypervisor, ator principal da virtualização, abordando sua

arquitetura e funcionalidades. A seção 3 traz um panorama de segurança para ambientes

virtuais, destacando o porquê é importante pensar em segurança para esses ambientes,

traz também alguns recursos e seus benefícios para a segurança, além dos tipos mais

comuns de ataques e ameaças. Na seção 4 são abordadas algumas recomendações para

se manter um ambiente virtual seguro. Em seguida, a seção 5 apresenta uma forma de

planejar, executar e manter um ambiente virtual seguro. E por fim, a seção 6 apresenta

as considerações finais deste trabalho e trabalhos futuros.

2. Visão Geral do Hypervisor

O Hypervisor é uma camada de software localizada entre o hardware e as máquinas

virtuais, sendo responsável por fornecer recursos (storage, CPU, memória, rede, etc.) da

máquina física para a máquina virtual. Ele permite que vários sistemas operacionais

possam ser executados em um mesmo host.

A virtualização do tipo completa fornece dois tipos de hypervisor. O tipo 1,

chamado de bare-metal e tipo 2, chamado de hosted. O hypervisor do tipo bare-metal

interage diretamente com o hardware da máquina física. Ele é completamente

independente do sistema operacional do host. Já no tipo hosted, o hypervisor roda sobre

o sistema operacional do host, sendo isto possível em qualquer tipo de SO.

Como mostra a Figura 1, o tipo hosted possui uma camada a mais de aplicação

junto com a camada do hypervisor, e ambas sobre o sistema operacional do host. Esta

camada de aplicação permite, por exemplo, a troca de arquivos entre o SO do host com

o ambiente virtual e também permite que os usuários possam executar aplicações tais

como web browsers e clientes de e-mail paralelamente ao ambiente virtualizado. Isto

não é possível no tipo bare-metal.

Figura 1. Ilustração do hypervisor tipo hosted e bare-metal, adaptado de [Gleeson

Os servidores são frequentemente virtualizados no modo bare-metal. Já o hosted

é comumente utilizado em soluções voltadas para uso em desktops, como o Virtualbox.

A maioria dos hypervisors oferecem recursos adicionais de hardware, que vão desde

controladores USB até direct memory access (DMA), visando com o DMA melhorar o

desempenho de controladores de storage (no que diz respeito a acesso a disco) e placas

de rede.

Visto isso, a decisão de usar hypervisor bare-metal ou hosted vai além de “ter ou

não ter sistema operacional no host”. A primeira opção, por exemplo, por estar situada

diretamente sobre o hardware, consegue prover um número maior de opções de acesso

de entrada e saída (I/O access) disponibilizando mais desempenho para aqueles que

optam por essa arquitetura.

Já a segunda opção consegue prover maior compatibilidade de hardware, o que

permite executar o software de virtualização em uma gama mais ampla de

configurações de hardware, diferentemente do modo bare-metal.

O hypervisor utiliza os recursos oferecidos pelo sistema operacional nativo para

oferecer recursos virtuais ao sistema operacional convidado que executa sobre ele.

Medidas operacionais e de segurança também devem ser levadas em

consideração na escolha da arquitetura utilizada, como será apresentado nas próximas

seções.

3. Segurança em Ambientes Virtualizados

Segundo Holland (2012), uma pesquisa da Associação Brasileira de ebusiness

(ebusiness Brasil) realizada em 2012 constatou que os investimentos em virtualização

nos ambientes de TI aumentaram cerca de 80% em relação aos últimos 3 anos. A

pesquisa, que durou cerca de 1 ano e entrevistou mais de 500 investidores, constatou um

aumento gradativo a partir de 2009, principalmente com o surgimento e aprimoramento

da técnica de computação em nuvem.

Outra pesquisa, também em 2012, constatou que 85% das organizações de todo

o mundo planeja ou já possui virtualização em seus ambientes de TI. E 52% de todos os

ambientes, com servidores x86, são virtualizados, sendo esperado um aumento para

75% em dois anos [Holland, 2012].

Tais pesquisas indicam a importância que a virtualização vem conquistando nos

ambientes de tecnologia da informação. Ainda assim, existe uma certa resistência em

seu uso. De um lado existem benefícios como: redução de custos com energia elétrica

(com a redução de equipamentos de hardware), redução de investimento em hardware

(tanto em compra de equipamento, como em manutenção), flexibilidade,

disponibilidade, etc.

Do outro, a segurança neste tipo de ambiente ainda provoca dúvidas nos

profissionais de TI. Fazendo uma análise hipotética, supondo que um ambiente

totalmente virtualizado sofra qualquer tipo de ataque à integridade física (hardware) ou

lógica (software) do host e o mesmo venha a parar, as máquinas virtuais ali presentes

também irão parar. Causando sérios danos à empresa/organização.

Por mais que existam técnicas de replicação, backup e cluster, ainda há o risco

de um ataque que, a depender da intensidade, acabe afetando a disponibilidade das

máquinas virtuais. Até porque, se algum invasor conseguir penetrar em uma VM –

Virtual Machine (máquina virtual), ele provavelmente vai conseguir acesso a alguma

outra. E acessando qualquer máquina virtual ele pode apagar dados de backup, dados do

storage, apagar as máquinas virtuais do host, etc.

Em fevereiro de 2011, uma companhia farmacêutica japonesa, Shionogi, foi

invadida por um administrador de TI, chamado de Jason Cornish. Jason utilizou uma

conta de serviço para acessar a rede da companhia. Estando dentro do ambiente da

empresa, Jason, através de uma instalação do VMware vSphere deletou 88 máquinas

virtuais. Sendo que dentro dessa contagem de VMs excluídas há servidores de e-mail,

BlackBerry Server, servidores de aplicações financeiras, etc. [Holland, 2012].

A Shiononi passou alguns dias para conseguir se reestabelecer, perdendo vendas,

comunicação por e-mail, entre outros prejuízos. A partir deste exemplo, é notório os

prejuízos que qualquer tipo de indisponibilidade em um ambiente de TI pode causar,

principalmente quando se trata de ambiente virtualizado, já que o host físico acomoda

diversas VMs com funcionalidades distintas.

Vale ressaltar que este exemplo não é caracterizado como um ataque, mas sim

como uma falha humana, já que a credencial de acesso do funcionário deveria ter sido

desativada uma vez que ele havia sido demitido. Contudo, falhas humanas também

podem acarretar em brechas que possam facilitar a vida de um invasor.

3.1. Técnicas de Segurança em Ambientes Virtualizados

O simples fato de migrar um ambiente de TI para um ambiente virtual não traz

praticamente nenhuma ameaça à segurança ou um aumento ou diminuição das ameaças

e vulnerabilidades. Independente se um ambiente é virtual ou não, quando ocorre a

migração, as mesmas ameaças, vírus e vulnerabilidades continuam presentes. O que

pode ocorrer é uma forma diferente de ataque e defesa devido ao acréscimo de uma

funcionalidade ou uma camada de software.

Este tópico foca justamente nesta discussão, mostrando alguns recursos da

virtualização e como eles se relacionam com a segurança.

3.1.1 Anéis de Proteção (Protection Rings)

A família de CPUs x86 fornece quatro modos de operação para o processador em sua

arquitetura, que são comumente chamados de anéis de proteção (protection rings) que

são identificados de 0 a 3. Esses anéis funcionam como mecanismos de proteção de

dados e funcionalidades contra falhas e ações maliciosas. Esses níveis de proteção são

níveis de hierarquia de privilégio dentro de uma arquitetura de computação.

Como mostra a figura 2, eles são organizados na hierarquia do mais privilegiado

(0 é considerado o de maior nível hierárquico) ao menos privilegiado (os de maior

número). O anel 0 interage mais especificamente com o hardware físico (CPU e

memória) e é utilizado pelo sistema operacional. Ele pode executar qualquer tipo de

instrução de CPU ou endereçamento de memória. Falhas neste nível do anel são

catastróficas tendo como consequência uma possível parada da máquina.

Saiba mais...  A mudança no licenciamento do #VMware #vSphere 5

Já o anel 3 é empregado para os processos do usuário. Caso um processo do

usuário tente acessar alguma instrução privilegiada do anel 0, uma exceção (trap) é

gerada. Este nível não permite o acesso aos níveis mais baixos e privilegiados. Por conta

deste isolamento, falhas no modo usuário são, na maioria dos casos, passíveis de

recuperação.

Figura 2 – Anéis de Proteção [Fawzi 2009].

3.1.2. Isolamento da Máquina Virtual (Guest OS Isolation)

O hypervisor é responsável por gerenciar o acesso ao hardware pelos sistemas

operacionais das VMs. Ele particiona tais recursos de forma que ele seja visto pelas

VMs como se não fossem um hardware dedicado apenas aquela VM. Ou seja, cada

máquina acessa seu recurso como se fosse exclusivo, de forma isolada. Isso possibilita

que uma VM funcione de forma separada uma da outra, não havendo possibilidade de

uma acessar o recurso da outra. Por esta razão o recurso foi batizado de “isolamento da

máquina virtual” e, por exemplo, está presente em ferramentas como Hyper-V e

VMware ESXi [BAKER, 2008] [WMware, 2011].

Os recursos são divididos em duas categorias: lógica e física. A divisão lógica

significa que o hypervisor entrega recursos para uma máquina virtual ou para várias

máquinas virtuais. Isso quer dizer que os recursos (memória e processador, por

exemplo) podem ou não ser compartilhados com várias VMs, como se fosse um pool de

recursos, com o mesmo nível de impacto de segurança e com o hypervisor

intermediando o acesso a eles. A divisão física propõe limitações à alocação de recursos

para uma determinada VM, pois não compartilha com as outras máquinas virtuais. O

hypervisor aloca um recurso fixo para uma determinada VM, o que significa que se

determinada máquina virtual utilizar apenas uma parte do seu recurso disponível, o que

não é utilizado por ela acaba ficando ocioso.

Essas características impostas pelo hypervisor possibilitam que caso uma VM

seja infectada por algum malware, por exemplo, ele potencialmente não atinja a outra

máquina virtual ou algum arquivo infectado de uma acabe passando para outra. Porém,

foi emitido um alerta sobre este risco em meados de 2010 pela IBM, através de um de

seus relatórios de segurança que medem a ocorrência de vulnerabilidades em ambientes

virtualizados. Este relatório apontava a ocorrência de um novo tipo de vulnerabilidade,

chamado de “escape-to-hypevisor”, onde um invasor a partir de uma máquina virtual

podia acessar qualquer outro recurso de uma VM qualquer.

A vulnerabilidade foi confirmada dois anos depois pela U.S Computer

Emergency Readiness Team (US-CERT) que afirmava que alguns sistemas

operacionais x64 rodando em hardware Intel eram vulneráveis a ataques do tipo

“escape-to-hypevisor” [Schwartz 2012]. A partir daí diversos outros fabricantes de

hypervisor passaram a buscar correções para o “bug”.

A partir do exemplo de vulnerabilidade relatado acima, percebe-se que o

hypervisor ainda não pode ser classificado como um componente intransponível, como

muitos o classificam. Ainda existem falhas e a cada dia são descobertas novas, fazendo

com que seja necessário um cuidado especial na hora de levar algum serviço específico

e de pouca possibilidade de paradas para um ambiente virtual.

3.1.3. Monitoramento da Máquina Virtual (Guest OS Monitoring)

O hypervisor possui recurso de auditoria em tudo o que é feito sob seu domínio, tendo

plena capacidade de monitorar cada sistema operacional que executa sobre ele, sendo

esta técnica conhecida como introspecção. A introspecção pode prover um

monitoramento completo, que pode incluir tráfego de rede, memória, processos e

diversos outras funcionalidades de um SO, mesmo quando a segurança do SO já foi

comprometida.

Muitos produtos de virtualização incorporam a isso algumas outras

funcionalidades, muitas vezes adicionando outras ferramentas para auxiliar, como por

exemplo a VMware através do Vsphere [WMware, 2010]. Isto, em conjunto com a

auditoria de introspecção, pode fornecer uma variedade extensa de parâmetros que

controlam e monitoram os acessos à VM.

3.1.4. Imagem e Gerenciamento de Snapshot

Diversas ferramentas de virtualização disponibilizam para seus usuários a

funcionalidade de snapshot, que permite que o sistema grave o estado atual da VM para

que a mesma possa ser restaurada para algum ponto anteriormente capturado a qualquer

momento. Pode-se citar o Hyper-V da Microsoft como um dos exemplos de ferramentas

que possuem a funcionalidade de snapshot [McShinsky, 2009].

Oferecem também outra funcionalidade que é a imagem ou clone, que permite

ao usuário criar uma cópia de VM e utilizar ela como sendo outra VM. Em outras

palavras, supondo a necessidade de se criar uma VM nova no ambiente, o usuário pode

recorrer à uma imagem/clone de uma VM, uma máquina virtual base, e a partir dela

criar uma nova acrescentado apenas as funcionalidades necessárias.

Nota-se que o maior problema no uso das técnicas é o fato delas possuírem

dados sensíveis (senhas, dados pessoais de usuários e etc.), similarmente como um disco

rígido (HD) de um computador. Tal comparação fica evidenciada na facilidade de

manuseio das imagens e snapshots, por isso o contraste com o HD e por isso, também, a

necessidade de cuidados especiais.

Um snapshot pode prover mais riscos de segurança do que as imagens, pois o

mesmo além dos dados sensíveis, traz também conteúdo da memória, e isso pode incluir

informações confidenciais que nem sequer foram armazenadas na unidade.

Uma aplicação e sistemas operacionais podem ser configurados, testados e

instalados em uma imagem e ser distribuída para diversos hosts. Tal prática proporciona

ganho de tempo considerável, especialmente ao se imaginar a criação de muitas

máquinas virtuais novas, operação que normalmente levaria um tempo considerável.

Com isso, o controle de acesso a essas imagens é importante, visto que uma imagem em

poder de alguém não autorizado se torna vulnerável à modificações indevidas e/ou

maliciosas.

3.1.5. Movimentação de Máquinas Virtuais

Outra funcionalidade bastante presente nas ferramentas de virtualização (por exemplo o

Vmotion no VMware ESXi [WMware, 2007]) é a movimentação das máquinas

virtuais presentes em um host, que compreende em fornecer alta disponibilidade ao

ambiente virtual. Por exemplo, caso seja necessário o desligamento ou reinicialização

do host físico, é possível mover as máquinas virtuais ali presentes para outro host, sem

que as mesmas desliguem, mantendo a disponibilidade. O recurso também é utilizado

em caso de ameaça de ataques ao host físico, tentando eliminar a chance da VM sofrer

com o ataque.

O hypervisor é capaz de realizar esta movimentação de forma automática a

depender das configurações realizadas. Por exemplo, quando a carga de processamento

em um dado host estiver muito alta, o hypervisor identifica isso e automaticamente

move algumas VMs para outro host. Muitas vezes este host secundário fica em standby

justamente para ocasiões desta natureza.

Contudo, não há garantia de sucesso nesse tipo de procedimento, até porque

outros fatores estão envolvidos em uma movimentação como aspectos de rede, por

exemplo. Se houver falha na rede durante a movimentação, o risco da movimentação

falhar e a VM desligar é grande.

Uma desvantagem em nível de segurança que merece ser destacada é que caso

uma máquina virtual esteja infectada ou comprometida, e ela seja movida para outro

host físico, isso pode acabar infectando, também, o próximo hospedeiro. O mesmo pode

ocorrer em caso de migração de uma máquina física para virtual.

3.1.6. Criptografia de Máquina Virtual

Uma máquina virtual é essencialmente composta por arquivos, por conta disso um

possível roubo de uma VM se torna ainda mais fácil. Sair de uma empresa com um

pendrive é muito mais discreto do que sair com um servidor nas mãos [Shackleford,

2013].

Existem diversas formas de se criptografar os arquivos de uma máquina virtual,

independentemente de onde ela esteja, se em um datacenter ou na nuvem, por exemplo.

Cada forma de criptografia possui prós e contras, principalmente quando se trata de

gerenciamento de chaves de decriptação [Shackleford, 2013].

A seguir, alguns exemplos locais onde as máquinas virtuais e seus dados podem

ser criptografados [Shackleford, 2013]:

• Dentro da própria máquina virtual. Exceto quando estão armazenadas em

arquivos VMDK (Formato de arquivo desenvolvido pela VMware);

• Dentro do hypervisor. Porém, ainda não há indícios de criptografia no

hypervisor em virtualização de servidores;

• Em um dispositivo de armazenamento NAS – Network-Attached Storage

(qualquer dispositivo com quantidade grande de disco e que funcione

como armazenador de dados). Com a vantagem de poder escolher qual

parte da VM será criptografada caso o protocolo entre o dispositivo e o

hypervisor seja o NFS;

• Dentro de storage (dispositivo com grande quantidade de discos para

armazenamento, que oferece redundância de fontes de energia, alta

disponibilidade, etc). Geralmente utilizado em criptografia de todo o

disco através da tecnologia FDE (Full Disk Encryption), que criptografa

todo o disco em nível de hardware.

Todas as opções listadas acima podem garantir alguma proteção para uma

máquina virtual, porém elas não garantem flexibilidade para acompanhar o fluxo de

trabalho de um ambiente de TI [Shackleford, 2013]. Em alguns momentos os

administradores de TI veem a necessidade de migrar algum serviço para a nuvem, o que

no caso de adoção de alguns desses locais a migração perderia a criptografia

configurada, já que não há como levar um disco para a nuvem, por exemplo.

Uma forma de solucionar esta questão seria adotar algum modelo de

armazenamento flexível, que englobaria tanto a criptografia como uma gerência melhor

das chaves de descriptografia.

3.2.Ameaças e Ataques mais Comuns em Ambientes Virtuais

Embora a virtualização forneça inúmeras funcionalidades, ainda não é possível afirmar

sua contribuição com relação à segurança. Além dos problemas de segurança

enfrentados pelos profissionais de TI em ambientes físicos, a virtualização traz um novo

risco associado ao hypervisor.

O principal ponto de falhas e ataques em ambientes virtualizado é o hypervisor.

Por ser o elemento central de todo o sistema de virtualização e por gerenciar todo o

ambiente virtual em um host físico, reunindo as principais funcionalidades e portas de

acesso às VMs.

Em alguns sistemas de virtualização existe uma funcionalidade que permite que

as máquinas virtuais sejam movidas de um host para o outro. Esta funcionalidade é

acionada quando é necessário fazer alguma manutenção no host, quando há falhas e

ameaças contra o hypervisor ou sistema operacional. A movimentação pode ocorrer

mesmo quando a VM está em execução

As empresas fornecedoras de hypervisor buscam a todo momento formas de

aumentar a segurança do seu produto e, consequentemente, passar mais credibilidade

aos seus usuários. De acordo com Schwartz (2010), um estudo realizado pela IBM em

2010, contabilizou que cerca de 35% dos ataques em ambientes virtualizados são

direcionados ao hypervisor. Como consequência, há uma preocupação dos fabricantes

em consertar a todo momento suas vulnerabilidades.

A todo momento um ambiente de TI está sujeito a sofrer com os diversos tipos

de ameaças à segurança, desde erros de algum funcionário até programas maliciosos

que roubam dados. Em ambientes virtuais existem outros parâmetros que merecem ser

analisados com cautela ao se manter ou projetar um ambiente virtualizado. Dentre os

parâmetros existentes, destacam-se o controle de expansão do ambiente virtual, falta ou

pouco monitoramento do ambiente, gerenciamento das responsabilidades perante o

gerenciamento do ambiente virtual, detalhes de configuração (firewall e networking)

entre outros.

As ameaças e ataques que serão expostos a seguir se tratam de visões

abrangentes e em muitos casos não se houve comprovação de em qual tecnologia de

virtualização (VMware, Hyper-V, Xen, etc.) especifica poderá ocorrer tal

ataque/ameaça. Portanto, na sequencia será visto alguns tipos de ataques/ameaças, assim

como técnicas para mitiga-los.

3.2.1. VM Escape

O assunto mais discutido quando se fala em segurança em virtualização e o mais temido

entre os profissionais de TI é o VM Escape (escape to hypervisor, fuga do hypervisor),

Saiba mais...  Aplicações para procurar emprego e divulgar seu currículo

que se trata de uma brecha de segurança em hypervisors VMware ESXi. Através dessa

brecha um invasor consegue executar códigos maliciosos dentro de uma máquina virtual

e, com isso, ele consegue executar comandos entre uma VM e outra e também no

hypervisor [SHACKLEFORD, 2013].

Alguns fabricantes possuem ferramentas que se assemelham ao comportamento

do VM Escape, porém não foram classificadas como tal e não têm o mesmo objetivo.

As ferramentas se caracterizam em permitir a livre transferência de dados entre uma

VM e outra, necessitando que ambos os lados estejam com a ferramenta ativa.

O que difere totalmente das características do VM escape, onde não há

necessidade de se ter o mesmo código executando na outra VM. O invasor consegue

acessar a outra VM se beneficiando de vulnerabilidades do sistema, até mesmo por onde

há controle de acesso [SHACKLEFORD, 2013].

Existem outros tipos de ataques dentro dos conceitos de VM Escape que

surgiram nos últimos anos:

• Directory Traversal Attack (Ataque de Passagem de Diretório): A maior

parte dos ataques VM espace partiram de ataques de passagem de diretório, que

consistem em um atacante obter acesso a pastas/diretórios considerados seguros

e com controle de acesso. O problema consistia na forma como os nomes dos

arquivos eram salvos, o que permitia um atacante salvar arquivos em diretórios

até então restritos a alguns usuários. Tal falha surgiu na funcionalidade de

compartilhamento de pastas da VMware Workstation.

Washington, DC, Tom Liston e Ed Skoudis apresentaram uma noção muito real

de VM escape. Eles apresentaram ferramentas que exemplificavam como era

possível ataques de VM escape. Dentre elas, destacam-se duas: VMchat e VM

Drag-n-Sploit. A VMchat utilizava o canal de comunicação do hypervisor da

VMware para passar mensagens entre máquinas virtuais e/ou entre máquina

virtual e host. Não requerendo nenhum tipo de código especial e nenhum recurso

Em uma das conferências realizadas na SANSFIRE 2007, em

adicional de redes, ou seja, a aplicação consistia em apenas um mensageiro

comum. A VM Drag-n-Sploit utilizava os benefícios fornecidos pelo VMchat e

com isso conseguia interceptar os dados que transitavam pelo canal de

comunicação, podendo ele alterar os dados que estavam trafegando por ali. Isso

era possível através da funcionalidade “drag-n-drop” (função de arrastar e

soltar, geralmente utilizada para transferir um dado de uma VM para outra)

fornecida pelo própria VMware.

• Blue Pill: Criado pela pesquisadora Polonesa, Joanna Rutkowska, a Blue Pill

[SHACKLEFORD 2013] causou uma grande comoção na época. O ataque foi

caracterizado como do tipo rootkit. Ataques deste tipo tem como princípio passar

despercebido por métodos de detecção de intrusão. No caso da Blue Pill o

objetivo era passar despercebido também pela auditoria do hypervisor. O que

gerou bastante contestação de diversos outros pesquisadores, já que para eles

passar despercebido pelo hypervisor seria muito difícil.

seja, ele encapsulava o funcionamento do SO. Com isso o sistema operacional

não o reconhecia como uma virtualização, porém estava virtualizado

[Shackleford 2013]. Tudo isso sem paradas no sistema, com todos os serviços

executando normalmente e nenhuma degradação de desempenho foi notada,

tendo assim o rootkit total gerenciamento do sistema operacional.

encapsulamento invisível citado por Joanna, pois é extremamente difícil fazer

com que uma virtualização via software consiga o mesmo tempo de execução de

instrução que o hardware, tornando assim improvável a invisibilidade da Blue

Pill.

• TXT Hack: Também criado pela pesquisadora Joanna Rutkowska e outros

pesquisadores [TERESHKIN et al., 2009], o ataque visava invadir a ferramenta

Trusted Execution Technology (TXT), construído em chips Intel vPro. O TXT foi

desenvolvido como uma extensão de hardware para processadores Intel, tendo

como objetivo permitir mais segurança aos usuários e organizações. Segurança

no sentido de fornecer mais controle no acesso aos dados, componentes de

geração, armazenamento de chave secreta e acesso autenticado a dados

criptografados, além de proteção de página DMA (Direct Acess Memory). Um

exemplo de hypervisor que pode ser afetado é o Xen da IBM [TERESHKIN et

al., 2009].

Intel seguido de um ataque contra uma falha de software TXT. Isso acabou

permitindo que eles obtivessem acesso a áreas de memória até então tidas como

altamente protegidas. Tal proteção no acesso a memória é considerado ainda

mais privilegiado que o anel 0 de proteção (mencionado na seção 3.1.1). O

sucesso do ataque se deu também em virtude de alguns erros de implementação

de alguns módulos de código de autenticação que estão presentes nos chips TXT,

os chamados SINIT (Authenticated Code Module Privilege Escalation).

todo o processo e comprovando a vulnerabilidade. A Intel confirmou a existência

A Blue Pill agia em sistemas operacionais como um hypervisor falso, ou

A contestação da comunidade de virtualização veio justamente sobre o

Os pesquisadores tiveram que explorar um bug no software do sistema

Em 30 de setembro de 2009, foi enviado à Intel um relatório contendo

da mesma e anunciou posteriormente um novo pacote de atualização para o

SINIT, corrigindo assim a falha.

Em meados de 2010, um grupo de pesquisa da North Carolina State University

divulgou documento relatando a criação de uma mecanismo baseado em segurança do

hypervisor e monitoramento, chamada de HyperSafe. A plataforma garantia que

qualquer malware ou outros ataques do tipo VM Escape não pudessem modificar a

plataforma de execução do hypervisor. O HyperSafe foi criado com três propostas

básicas, a primeira de não afetar em nada o hypervisor original, mantendo assim sua

estrutura padrão de funcionalidades e recursos, não causando impacto algum ao usuário.

A segunda é promover autoproteção do hypervisor, agindo de forma proativa e

confiável, até mesmo ao se reportar um bug em endereçamentos de memória, o que

poderia causar catástrofes ao sistema. E por fim, a terceira proposta é a compatibilidade

com os diversos tipos de hardware existentes, fornecendo assim uma gama de

possibilidades de proteção aos mais diversos ambientes virtualizados.

3.2.2. VM-Aware Malware

Uma das preocupações mais recorrentes desde 2006 são os ataques de malwares a

ambientes virtualizados [SHACKLEFORD 2013], o que compreende uma leva

considerável de bots, worms, rootkits, e diversos outros tipos de códigos maliciosos, que

são capazes de identificar em que ambientes estão sendo executados (virtuais ou físicos)

tendo como base informações de memória, hardware, processos e etc.

A maior preocupação ocorre devido à presença crescente de vírus “inteligentes”,

que identificam se estão executando em uma máquina virtual ou não. A partir desta

informação ele irá dificultar a análise de seu comportamento. Por exemplo, caso alguém

necessite analisar o comportamento de algum vírus é necessário executá-lo em uma VM

e isso dificulta e muito o combate a este tipo de ameaça, pois o mesmo tende a mascarar

seu real funcionamento ao identificar que está sendo analisado.

3.2.3. Roubo de Máquina Virtual

Uma preocupação recorrente com a segurança das máquinas virtuais é o roubo delas.

Tendo em vista que as máquinas virtuais são apenas arquivos, um usuário/funcionário

com acesso físico ao local de armazenamento (em geral storages) onde os dados das

VMs estão guardados, ou até mesmo acesso a um local do hypervisor, pode copiar todos

os arquivos das VMs em uma mídia local, por exemplo, e removê-los posteriormente.

3.2.4. Injeção de Código/Arquivo Malicioso

Pelo fato das máquinas virtuais serem, a grosso modo, apenas arquivos armazenados,

qualquer alteração realizada nesses arquivos pode trazer grandes riscos. Sejam

alterações de adição ou alteração de algum dado específico da VM, os ataques de

injeção de código malicioso visam fazer com que o código injetado seja executado

[CAICEDO et al. 2012]. Com isso, abre-se precedentes para diversas possibilidades de

ataques, dentre elas ataques de negação de serviço (DoS – Denial of service)

[SHACKLEFORD 2013].

Em ataques de injeção de código, uma máquina virtual com um vírus ou

qualquer outro código malicioso pode ser inserido dentro de um ambiente virtual através

dos seguintes métodos [CAICEDO et al. 2012]:

• Um invasor pode comprometer uma máquina virtual utilizando o hypervisor

para transferir uma VM infectada para um outro host via FTP e iniciando-a do

outro lado;

• O invasor pode ser passar por um “man-in-the-middle” (homem no meio, em

tradução livre), que significa que o invasor fica “escutando” a comunicação

entre o host físico e a máquina virtual, conseguindo assim modificar a troca de

informação ali e fazer com que uma VM infectada se passe como uma VM

segura;

• Uma outra forma de ataque ocorre quando o invasor faz uma busca na rede pelo

local onde a máquina virtual está armazenada, e caso não haja controle de acesso

lá é possível fazer uma cópia da mesma para um outro local. A partir daí o

atacante fica em condições de tentar qualquer modificação que lhe convenha.

3.2.5. Ataque de Negação de Serviço (DoS – Denial of Service)

Ataques de negação de serviço são inerentes a qualquer tipo de sistema ou aplicação.

DoS utiliza grande número de pacotes ou pacotes maliciosos endereçados a algum

sistema ou aplicação, acarretando um alto processamento no alvo que está sendo

acatado, causando falhas no sistema [SHACKLEFORD 2013].

É comum encontrar ataques DoS em ambientes virtuais devido à funcionalidade

de compartilhamento de recursos entre as VMs e o host físico. Se várias VMs

começarem a consumir muito processamento, memória, processamento de disco, banda

de rede no host físico, a tendência é esse host não conseguir mais operar de forma

correta ou até mesmo seus recursos ficarem inacessíveis, podendo gerar danos às outras

máquinas virtuais.

Um exemplo de ocorrência de ataques DoS foi em ambientes com VMware

ESXi, onde uma vulnerabilidade no protocolo NFC (Network File Copy) permitia a

modificação do tráfego NFC entre o cliente e o servidor ESXi [Kovacs, 2013].

3.2.6. Footprinting

Footprinting é uma técnica de invasão baseada em conseguir informação de um possível

alvo sem parecer que aquilo é um ataque. Geralmente a obtenção dessas informações se

dá a partir de comandos remotos direcionados a quem se quer atacar. As respostas

obtidas vão desde qual sistema operacional que está sendo executado na máquina alvo,

quais portas estão abertas até mesmo qual a ferramenta de proteção utilizada na

máquina virtual [CAICEDO et al. 2012].

O objetivo de quem está tentando invadir é traçar um perfil daquele alvo,

identificando padrões anômalos de tráfego pela rede. Por exemplo, para identificar se o

sistema alvo é uma VM ou não, os invasores analisam o tempo de sincronização entre

um host e seu SO e o tempo de uma VM com seu SO. Geralmente a taxa de

sincronização, alocação de um processo por exemplo, em uma VM é baixa, o que não

ocorre no host.

Outra forma de mapear os hosts virtuais em um segmento de rede é através da

alteração ou não do endereço MAC [CAICEDO et al. 2012]. Em máquinas ativas o

endereço tende a não mudar, porém a partir de alguma eventualidade se o MAC for

comprometido, fica claro que ali se trata de uma máquina virtual [CAICEDO et al.

2012].

Existem ferramentas open source (i.e VMDetect, ScoopyNG) que auxiliam o

invasor na identificação se o alvo é virtual ou não, utilizando diversos outros métodos

de detecção [CAICEDO et al. 2012]. Sendo assim, o simples fato do atacante identificar

que ali se trata de uma VM ou não o ajuda bastante no direcionamento das ações de

invasão.

4.Recomendações de Segurança para Ambientes Virtualizados

Mediante os ataques e ameaças destacadas na seção 3 desde artigo, identifica-se que o

hypervisor tem um papel primordial no combate ou prevenção desses ataques. Tendo em

vista que é o principal componente do sistema, acaba sendo muito visado e por conta

Saiba mais...  Salvando vidas e economizando com Big Data

disso precisa de uma atenção especial para torná-lo seguro. Para isso, é necessário

adotar medidas não apenas específicas ao hypervisor, mas sim a todo o ambiente em

que ele está inserido, como storage, máquina física, infraestrutura de rede e desktops.

O foco das próximas seções é destacar algumas formas de tentar fornecer mais

segurança tanto ao hypervisor como em boa parte dos componentes que fazem parte de

um ambiente de virtualização.

4.1 Hypervisor

Quando se fala em segurança do hypervisor é necessário pensar no software de

gerenciamento que o controla. É a partir desse software que é estabelecida a

comunicação entre o usuário e o hypervisor. Com ele se torna possível usufruir das

funcionalidades que o hypervisor proporciona, desde o gerenciamento de imagens até

configurações de processador e memória.

Por conta disso, o primeiro parâmetro quando se pensa em formas de manter o

hypervisor seguro é garantir ao máximo a segurança do software de gerenciamento

[SCARFONE et al. 2011]. A maioria das ferramentas de gerenciamento utilizam o

tradicional controle de acesso por login/senha, o que a depender das normas de

segurança da empresa pode ser insuficiente, fazendo com que muitas empresas adotem

outras medidas de segurança. Muitos sistemas de gerenciamento fornecem o controle de

acesso baseado em permissões, onde apenas um grupo tem acesso irrestrito e outros

apenas leitura, por exemplo.

Existem várias formas de gerenciar o hypervisor, que, independente da forma

que é utilizada é imprescindível assegurar um bom gerenciamento das interfaces de

acesso à ele, tanto local como remoto. Caso o acesso local ou remoto estejam

habilitadas, é aconselhado o uso do firewall para controlar o tráfego de rede

[SCARFONE et al. 2011]. Toda e qualquer comunicação com redes externas devem ser

criptografadas utilizando métodos da própria ferramenta de virtualização ou de

terceiros, por exemplo uma rede privada com VPN (Virtual Private Network)

[SCARFONE et al. 2011].

Abaixo segue listagem de mais algumas recomendações de segurança para o

hypervisor:

• Instalar todas as atualizações disponíveis sempre que disponibilizadas pelo

fabricante;

• Restringir o acesso não autorizado à central de gerenciamento do hypervisor.

• Desconectar componentes de hardware que não estejam em uso. Por exemplo,

discos removíveis utilizados para armazenar backups das máquinas virtuais;

• Manter desativado os recursos de compartilhamento e transferência de arquivos

entre máquinas virtuais e/ou host físico. Como foi discutido na seção 3.2.1, pode

haver potenciais ataques a partir dessas funcionalidades através do

“escape-to-hypervisor”;

• Analisar continuamente o hypervisor e seu log com o objetivo de identificar

ocasionais anormalidades;

• Prover controle ao acesso físico ao host em que o hypervisor se encontra

prevenido contra reinicialização inesperada, ou a inserção de algum componente

USB, por exemplo.

É importante que as empresas e os profissionais de TI ao implantarem um

ambiente de virtualização saibam que não se deve levar em consideração apenas o

hypervisor, muitas vezes um ataque surge em componentes ou recursos que estão fora

dele, mas que possuem contato e caminho facilitado para chegar até ele.

4.2 Máquina Virtual

O sistema operacional de uma máquina virtual que executa em um ambiente virtual se

comporta de forma semelhante a um sistema operacional de uma máquina física.

Portanto, todas as considerações de segurança recomendados para sistemas operacionais

em máquina física também se aplicam aos virtuais.

A maior preocupação é o fato de uma VM infectada poder contaminar outras no

mesmo ambiente. Por conta disso, é necessário uma preocupação que vai além de

proteger o host físico, para isso medidas preventivas podem ser tomadas para prever

alguma eventualidade. Abaixo são listadas algumas delas [CAICEDO et al. 2012]]:

• Seguir melhores práticas recomendadas pelos fabricantes de hardware, boas

práticas em gerenciamento de log, autenticação e acesso remoto;

• Manter o sistema sempre atualizado de acordo com os updates recomendados

pelos fabricantes;

• Manter rotinas de backup das máquinas virtuais;

• Desconectar componentes de hardware não utilizados, evitando assim que

alguma manobra maliciosa, por exemplo, uso de dispositivos USB que podem

conter códigos maliciosos possam infectar o host;

• Utilizar soluções de autenticação de usuários separadas para cada host,

dificultando assim que caso uma senha seja descoberta o invasor consiga acesso

a outras máquinas.

4.4 Infraestrutura de Virtualização

Prevenir e manter uma infraestrutura de virtualização seguindo as recomendações de

segurança significa não apenas olhar para o hypervisor, host físico ou sistema

operacional. A virtualização compreende também interfaces de armazenamento e rede,

por conta disso, o acesso a este tipo de dispositivo deve ser bem controlado, limitado

apenas aos sistemas operacionais que o utilizam. Por exemplo, caso um disco rígido de

um dispositivo de armazenamento seja compartilhado com duas máquinas virtuais, é

preciso que haja um controle de acesso para que apenas essas duas venham a acessá-los

[CAICEDO et al. 2012].

 Com relação aos componentes de rede, alguns switchs não fornecem formas de

monitoramento de tráfego para atividade suspeita e também não oferecem um

gerenciamento qualificado. Por conta disso, é comum adotar tecnologias de segurança

adicionais para garantir o monitoramento, controle e inspeção da rede [CAICEDO et al.

2012].

5.Como Planejar e Manter Ambientes Virtualizados Seguros

A parte mais crítica na implantação de um projeto de virtualização segura é o

planejamento cuidadoso antes da implantação, configuração e instalação [KISSEL et al.

2008]. Isso tornará mais fácil seguir as políticas organizacionais e pode garantir maior

segurança para o ambiente. Muito dos problemas de segurança e desempenho ocorrem

devido a problemas de planejamento de implementação [SCARFONE et al. 2011].

Aspectos de segurança devem ser os primeiros a serem levados em consideração

no planejamento para melhorar a segurança e diminuir os custos. Até porque é muito

mais caro tratar a segurança após a implantação e implementação [SCARFONE et al.

2011]. Os aspectos tratados nas sessões 2 e 3 desde artigo devem ser levadas em

consideração para uma melhor estruturação das medidas a serem adotadas no projeto,

visando auxiliar as organizações no melhor caminho a seguir na implantação de

soluções de virtualização.

As próximas sessões serão dedicadas a exploração de um ciclo de vida de cinco

fases que ajudam as organizações a definir em qual momento na implantação de um

ambiente de virtualização uma recomendação de segurança pode ser relevante. O

modelo é baseado em um ciclo de vida voltado para sistemas, chamado de “Security

Considerations in the Information System Development Life Cycle” [KISSEL et al.

2008] e o adaptou para o planejamento de ambientes virtuais seguros. As fases do ciclo

são definidas em Iniciação (seção 5.1), Planejamento (seção 5.2), Implementação (seção

5.3), Operação e Manutenção (seção 5.4) e Eliminação (seção 5.5).

5.1. Fase 1: Iniciação

Esta fase compreende as tarefas necessárias que uma organização deve levar em

consideração ao projetar uma solução de virtualização para seu ambiente de TI, levando

em conta os preceitos de confiabilidade, integridade e disponibilidade. Ou seja, a fase de

iniciação envolve muitas ações preparatórias, como a identificação das necessidades

atuais e futuras, e especificação de requisitos de desempenho, funcionamento e

segurança [KISSEL et al. 2008].

Deve-se pensar como essas soluções serão administradas analisando também a

possibilidade de atualização das políticas, tendo em vista a probabilidade de mudanças

tecnológicas ou nas políticas de segurança da empresa.

Todos esses aspectos são necessários por se tratarem de pontos chave, já que a

depender da escolha de uma política de segurança, isso pode impactar no tipo de

virtualização a ser adotada no ambiente [SCARFONE et al. 2011].

5.2. Fase 2: Planejamento

Passada a fase de iniciação, escolha da política de segurança e definições do que será

necessário para a realização do projeto, o próximo passo é planejar a solução a ser

implantada. Esta fase de planejamento engloba o detalhamento das características da

solução escolhida, como qual método de autenticação será utilizado e mecanismos de

criptografia, por exemplo. Tudo isso baseado em três parâmetros: arquitetura,

criptografia e autenticação.

A arquitetura constitui na escolha do tipo de virtualização, do software de

virtualização, assim como armazenamento, topologia de rede, entre outros. Já a

autenticação fica responsável por definir quais camadas de virtualização vão precisar de

políticas de autenticação, tais como: SO da máquina virtual, hypervisor, SO do host

físico, etc. E, por último, a criptografia que inclui as escolhas do algoritmo de

criptografia e proteção da integridade das comunicações de virtualização.

Nessa fase também é definido e documentado o plano de segurança a ser

adotado para aquele projeto.

5.3. Fase 3: Implementação

A implementação compreende a instalação e validação de todo o ambiente que foi

previamente discutido e definido na fase de planejamento (seção 5.2) da solução. Além

disso, trata da validação e teste dos aspectos de segurança definidos para aquele

ambiente/solução. Ou seja, é a fase em que tudo é instalado, configurado e testado,

porém ainda não é colocado em produção.

Nessa fase alguns aspectos precisam ser validados:

• Introspecção: determinar se a solução de virtualização escolhida no

planejamento fornece informações necessárias para monitorar eventos de

segurança que ocorrem no SO das máquinas virtuais;

• Autenticação: garantir que haja autenticação nas diversas camadas de

virtualização;

• Conectividade: verificar se os usuários estão acessando o que a eles foi

permitido e se acessam o que foi negado. Havendo divergência nesses pontos, é

preciso rever a política de acesso;

• Segurança da implementação: mesmo na fase de implementação pode haver

riscos do ambiente sofrer algum ataque. Por conta disso, é aconselhável manter

atualizado e configurado corretamente todos os componentes que estão

envolvidos na implementação do projeto de virtualização.

5.4. Fase 4: Operação e Manutenção

Nesta etapa os sistemas estão instalados, em operação, além de melhorias e

modificações estarem sendo desenvolvidas e testadas. O sistema como um todo é

monitorado para verificar se os requisitos de segurança estão sendo alcançados e como

as modificações que estão sendo desenvolvidas e testadas estão agindo dentro do

ambiente de virtualização.

Apesar do sistema estar operacionalizado, caso seja necessário reimplementar ou

modificar algo, pode ocorrer do ciclo voltar a alguma fase anterior. Devido à

importância da manutenção do sistema/ambiente para a segurança é importante ficar

atento para os seguintes tópicos [SCARFONE et al. 2011] [KISSEL et al. 2008]:

• Administração: ter certeza de que apenas administradores possuem acesso ao

ambiente tanto de software como hardware;

• Atualização: verificar constantemente se há atualizações para hypervisor,

sistemas operacionais (tanto das VMs como dos hosts), além também da

atualização dos componentes que englobam o ambiente virtual;

• Sincronização: garantir que o relógio de sincronização de cada componente de

virtualização esteja sincronizado com o relógio dos outros sistemas. Geralmente

é utilizado o relógio do sistema operacional como guia;

• Controle: sempre manter as configurações de controle de acesso de acordo com

as políticas de segurança, mudanças tecnológicas e constatações da auditoria;

• Logging: documentar anomalias que indicam atividade maliciosa ou suspeitas

dentro do ambiente virtual. Anomalias que indicam atividade maliciosa ou

suspeitas.

As organizações devem revisar periodicamente esses tópicos a fim de confirmar

que as políticas da organização, segurança, procedimentos e processos estão sendo

seguidas corretamente [KISSEL et al. 2008].

5.5. Fase 5: Eliminação

Após o uso de um dispositivo de virtualização, sendo este destinado à devolução (em

caso de aluguel de equipamento) ou descarte, é preciso cuidado especial com a limpeza

das informação que permanecem naquele dispositivo [SCARFONE et al. 2011]. Tarefa

que se torna bastante complicada devido à disposição dos arquivos no dispositivo; não

há um local central onde os dados ficam armazenados e organizados, mas sim

espalhados.

Por conta disso, essa fase do ciclo precisa ser bem definida por cada organização

[KISSEL et al. 2008].