Carlos Wagner Sousa Da Costa

o Universidade Federal do Maranha ncias Exatas e Tecnologia Centro de Cie ncia da Computa o Curso de Cie ca
Carlos Wagner Sousa da Costa
Mecanismos de Seguran ca para o Ambiente de Virtualiza c ao do NTI / UFMA
S ao Lu s 2010
Monograa apresentada ao Curso de Ci encia da Computa c ao da UFMA, como requisito para a obten c ao parcial do grau de LICENCIADO em Ci encia da Computa c ao.
Orientador: Francisco Jos e da Silva e Silva

Doutor em Ci encia da Computa c ao, UFMA
S ao Lu s 2010
Costa, Carlos Mecanismos de Seguran ca para o Ambiente de Virtualiza ca o do NTI / UFMA / Carlos Costa - 2010 xx.p
1.Inform atica 2. Virtualiza ca o.. I.T tulo. CDU 536.21
Monograa apresentada ao Curso de Ci encia da Computa c ao da UFMA, como requisito para a obten c ao parcial do grau de LICENCIADO em Ci encia da Computa c ao.
Aprovado em 09 de julho de 2010
BANCA EXAMINADORA
Francisco Jos e da Silva e Silva

M ario Antonio Meireles Teixeira

Geraldo Braz J unior

Mestre em Engenharia da Eletricidade, UFMA
Aos meus pais e irm aos. Aos amigos, pelo apoio e companheirismo. ` minha amada pelo carinho e paci A encia.
Resumo
Virtualiza ca o e a t ecnica que permite particionar um u nico sistema computacional em v arios outros denominados de m aquinas virtuais. Cada m aquina virtual oferece um ambiente completo muito similar a uma m aquina f sica. Com isso, cada m aquina virtual pode ter seu pr oprio sistema operacional cada qual com seus aplicativos e servi cos de rede que podem ser administradas por meio de hipervisores, monitores de m aquinas virtuais que permitem utilizar um computador f sico para executar v arios computadores virtuais. O uso de t ecnicas de virtualiza c ao em uma infraestrutura de servidores pode trazer diversos benef cios, tais como: menor custo de aquisi c ao de equipamentos e menor custo operacional; consolida c ao dos servi cos de Internet; uso ordenado dos dispositivos de armazenamento; alta disponibilidade e balanceamento de carga; e recupera c ao em caso de desastres. O n umero crescente de incidentes de seguran ca relatados ao CERT.br evidencia que um bom projeto de virtualiza c ao deve levar em considera ca o o uso adequado de mecanismos de seguran ca. Deve-se evitar brechas de seguran ca que comprometam os sistemas hospedeiros e suas m aquinas virtuais, que podem sofrer ataques a partir de fontes externas ou internas. Este trabalho monogr aco descreve o estudo e implementa c ao de ferramentas e t ecnicas de seguran ca empregados no projeto de virtualiza ca o dos servi cos disponibilizados pela infraestrutura computacional do N ucleo de Tecnologia da Informa c ao da UFMA. Para tanto, s ao empregados mecanismos para garantir a integridade do pr oprio hipervisor e seu sistema hospedeiro, bem como dos sistemas convidados instalados em m aquinas virtuais gerenciadas atrav es do Citrix XenServer. Palavras-chaves: Seguran ca, virtualiza c ao, m aquinas virtuais.
R esum e
La virtualisation est une technique qui permet de partitionner un syst` eme unique plusieurs autres de calcul appel ee machines virtuelles. Chaque machine virtuelle fournit un environnement complet tr` es similaire a ` une machine physique. Ainsi, chaque machine virtuelle peut avoir son propre syst` eme dexploitation de chaque avec leurs applications et services r eseau qui peuvent etre g er e par les hyperviseurs, des moniteurs de machine virtuelle qui vous permettent dutiliser un ordinateur physique dex ecuter plusieurs ordinateurs virtuelle. Lutilisation des techniques de virtualisation dans une infrastructure serveur peut apporter plusieurs avantages comme la r eduction du co ut dacquisition l equipement et les co uts dexploitation, la consolidation des services Internet; utilisation rationnelle des p eriph eriques de stockage, de haute disponibilit e et l equilibrage de charge; et la r ecup eration en cas de catastrophes. Le nombre croissant dincidents de s ecurit e signal es ` a CERT.br montre que la projet de virtualisation devrait tenir compte de lutilisation appropri ee m ecanismes de s ecurit e. Vous devez eviter que les violations de la s ecurit e compromettre le syst` eme h ote et les machines virtuelles, qui peuvent sourir attaques a ` partir de sources externes ou internes. Cette monographie d ecrit l etude et mise en uvre doutils de s ecurit e et les techniques employ ees dans projet de virtualisation des services fournis par le Centre de Technologie de lInformation pour UFMA. Par cons equent, il est m ecanismes utilis es pour assurer lint egrit e de lhyperviseur lui-m eme et ses syst` eme h ote, ainsi que des syst` emes install es sur les machines h otes Virtual g er e par Citrix XenServer. Mots-cl es: Securit e, virtualization, machines virtuelles.
Agradecimentos
A Deus, pois sem Sua vontade nada e poss vel. A todos os meus parentes, pelo encorajamento e apoio. Aos meus companheiros de trabalho por se fazerem presentes sempre que poss vel. Ao professor Francisco pela orienta ca o, amizade e principalmente, pela paci encia, sem a qual este trabalho n ao se realizaria. Aos professores do Departamento de Inform atica pelos seus ensinamentos e aos funcion arios do curso, que durante esses anos, contribuiram de algum modo para o nosso enriquecimento pessoal e prossional. ` Gil por tudo que passamos juntos e ainda vamos passar nessa vida. Te amo. A
Aprenda como se voc e fosse viver para sempre. Viva como se voc e fosse morrer amanh a. Mahatma Gandhi
Sum ario
Lista de Figuras 1 Introdu c ao 1.1 1.2 1.3 1.4
8 10
Parque de servidores do NTI . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Organiza ca o da Monograa . . . . . . . . . . . . . . . . . . . . . . . . . . 14 15
2 Conceitos de Virtualiza c ao 2.1 2.2
Breve Hist orico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Tipos de Virtualiza ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.1 2.2.2 2.2.3 Emula ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Virtualiza ca o Completa . . . . . . . . . . . . . . . . . . . . . . . . 17 Paravirtualiza ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3
Produtos de Virtualiza ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7 Bochs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 MAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 VMWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Hyper-V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Linux KVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Linux em modo usu ario . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.8 2.4
Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Conclus oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 26
3 XenServer 3.1 3.2 3.3 3.4 3.5
Estrutura do XenServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Caracter sticas Principais do XenServer . . . . . . . . . . . . . . . . . . . . 28 Ferramentas de Gerenciamento . . . . . . . . . . . . . . . . . . . . . . . . 29 Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Conclus oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Aspectos e Mecanismos de Prote c ao e Seguran ca Implementados no Projeto de Virtualiza c ao dos Servi cos do NTI 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 38
Seguran ca de Ambientes Virtualizados . . . . . . . . . . . . . . . . . . . . 39 Isolamento Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Cuidados com o Hipervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Autentica c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 IDS/IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 VLAN - Rede Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Conclus oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 59 61
5 Conclus ao e Trabalhos Futuros Refer encias Bibliogr acas
Lista de Figuras
1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2
Sistema de virtualiza c ao sendo executado em um servidor . . . . . . . . . . 10 Hipervisor Xen rodando v arias m aquinas virtuais . . . . . . . . . . . . . . 11 Parque atual dos servidores do NTI-UFMA . . . . . . . . . . . . . . . . . . 12 Totais de incidentes de seguran ca relatados ao CERT.br . . . . . . . . . . 13
Emula c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Virtualiza ca o completa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Paravirtualiza ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Estrutura de um sistema XenServer e seus dom nios . . . . . . . . . . . . . 27 An eis de execu c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Congurando a conex ao com um hipervisor remoto no virt-manager . . . . 31 Congurando a conex ao com um servidor no XenCenter . . . . . . . . . . . 32 Acesso ao console do XenServer pelo XenCenter. . . . . . . . . . . . . . . . 33 Exemplo de um sistema capaz de prover alta disponibilidade. . . . . . . . . 34 Isolamento de m aquinas virtuais da rede externa. . . . . . . . . . . . . . . 41 Op c ao do menu que permite o XenCenter congurar o login do servidor em um AD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 4.4 4.5 4.6 4.7
Esquema da estrutura da rede da UFMA.
. . . . . . . . . . . . . . . . . . 44
Fluxograma do processamento de pacotes pelo iptables. . . . . . . . . . . . 48 Conte udo do arquivo interfaces. . . . . . . . . . . . . . . . . . . . . . . . . 49 DMZ protegida por rewall. . . . . . . . . . . . . . . . . . . . . . . . . . . 50 DMZs de servidores p ublicos e internos. . . . . . . . . . . . . . . . . . . . . 51
4.8 4.9
HIDS ou LIDS monitorando a co es e logs do de um servidor. . . . . . . . . 52 Ambiente de aplica c oes em camadas. . . . . . . . . . . . . . . . . . . . . . 54
4.10 Esta co es agrupadas em VLANs conguradas em switches diferentes. . . . . 55 4.11 Congura ca o de esta c oes com DHCP nas redes internas da UFMA. . . . . 56 4.12 Separa c ao do tr afego de comunica c ao com o XenServer. . . . . . . . . . . . 57
10
1 Introdu c ao
A virtualiza ca o e a t ecnica que permite particionar um u nico sistema computacional em v arios outros denominados de m aquinas virtuais. Cada m aquina virtual oferece um ambiente completo muito similar a uma m aquina f sica. Com isso, cada m aquina virtual pode ter seu pr oprio sistema operacional cada qual com seus aplicativos e servi cos de rede que podem ser administradas por meio de hipervisores, monitores de m aquinas virtuais que permitem utilizar um computador f sico para executar v arios computadores virtuais.
Figura 1.1: Sistema de virtualiza c ao sendo executado em um servidor A Figura 1.1 mostra um esquema da estrutura de um ambiente virtualizado, com suas m aquinas virtuais e o software de virtualiza ca o sendo executado sobre o sistema operacional hospedeiro junto com os sistemas aplicativos do usu ario. O desenvolvimento dos hipervisores tem avan cado muito desde que os grandes fabricantes de processadores para computa ca o pessoal incluiram em seus produtos recursos para oferecer vantagens aos gerenciadores de m aquinas virtuais VMM (Virtual Machines Manager ) (INTEL, 2009b; AMD, 2009). Tais recursos zeram com que o desempenho dos sistemas de m aquinas virtuais cassem mais pr oximo das m aquinas reais, tornando a virtualiza c ao para arquitetura x86 uma possibilidade real e um atrativo para aplica c oes em empresas. Dentre os hipervisores mais utilizados est ao o VMWare ESX, Microsoft Hyper-V e o Citrix XenServer. Este u ltimo baseado em Software Livre de C odigo Aberto (SL/CA), e
1.1 Parque de servidores do NTI
11
um dos sistemas mais utilizados para prover virtualiza ca o a sistemas baseados em processadores x86, da Intel e AMD (Virtual Machines Manager ).
Figura 1.2: Hipervisor Xen rodando v arias m aquinas virtuais A Figura 1.2 mostra o funcionamento do hipervisor Xen, com suas estruturas principais destacadas: o software de gerenciamento (Domain0 control interface ) e os dispositivos virtuais usados pelas m aquinas virtuais. Sendo executado sobre um sistema operacional GNU/Linux, com sucesso em diversos ambientes de produ ca o dos mais variados tamanhos ao redor do mundo, o Xen foi o sistema selecionado para a solu ca o de virtualiza ca o de servidores do N ucleo de Tecnologia da Informa c ao da Universidade Federal do Maranh ao (NTI-UFMA), por ser SL/CA, atender v arios requisitos de desempenho e por ser capaz de aproveitar equipamentos constituintes do parque de servidores do setor.
1.1
Parque de servidores do NTI
Atualmente o NTI (N ucleo de Tecnologia da Informa c ao ) da UFMA (Universidade Federal do Maranh ao ) conta com 9 (nove) m aquinas servidoras, com arquitetura x86, somando 25 cores, 19 GigaBytes de mem oria RAM (Random Access Memory ) e aproximadamente 479 GigaBytes de disco r gido. Muitos dos servi cos executam sobre plataforma Linux, em sua maioria sobre a distribui ca o Debian Etch, embora alguns Fedora, CentOS e Suse tamb em sejam utilizados para execu ca o de aplica c oes baseadas na web. No NTI existem ainda alguns servidores
1.1 Parque de servidores do NTI
12
com Microsoft Windows 2003 Server, instalados para execu c ao de bancos de dados e aplica c oes legadas. O NTI est a realizando um projeto de virtualiza ca o que consiste na virtualiza c ao de servidores f sicos instalados em suas depend encias. Estes servidores executam aplica co es diversas como servidores de p aginas, bancos de dados, aplica c oes Java para web e diversas aplica c oes legadas.
Figura 1.3: Parque atual dos servidores do NTI-UFMA A Figura 1.3 representa os servidores dispon veis no NTI-UFMA. Pode-se perceber que algumas funcionalidades est ao multiplicadas em equipamentos diferentes, o que implica em desperd cio de recursos e diculdades em realizar manuten ca o. O projeto de virtualiza ca o do NTI tem como objetivos:
1. Consolida c ao dos servi cos de Internet; 2. Uso ordenado dos dispositivos de armazenamento; 3. Prover alta disponibilidade e balanceamento de carga; 4. Recupera ca o em caso de desastres (disaster recovery ).
Para atingir tais metas foram realizadas algumas pesquisas e, depois de alguns testes, o XenServer da Citrix foi instalado em tr es servidores de grande capacidade de processa-
1.2 Justicativa
13
mento e mem oria, e neles foram criadas m aquinas virtuais para prover a consolida c ao dos servidors de p aginas e algumas aplica c oes em Java.
1.2
Justicativa
Com a capacidade de executarmos v arias m aquinas virtuais no mesmo computador, muitas possibilidades s ao criadas, desde a vantagem de um melhor aproveitamento dos recursos computacionais dos equipamentos at e o aumento da vida u til de sistemas legados. Cada m aquina virtual com seu sistema operacional e suas aplica c oes deve ser tratada como um equipamento isolado, mas levando-se em considera ca o o fato de que executam em um outro equipamento e cada um desses componentes pode conter brechas de seguran ca. Devemos, ent ao, cercar tais brechas para que n ao comprometam os sistemas hospedeiros e suas m aquinas virtuais, que podem sofrer ataques a partir de fontes externas ou internas, do pr oprio sistema que executa o hipervisor ou a partir de um de seus sistemas convidados.
Figura 1.4: Totais de incidentes de seguran ca relatados ao CERT.br A Figura 1.4 representa o n umero de incidentes de seguran ca relatados ao CERT.br
1.3 Objetivos
14
(Centro de Estudos, Resposta e Tratamento de Incidentes de Seguran ca no Brasil ) (CERT.BR, 2009a). Pode-se notar uma tend encia crescente no n umero de ataques sofridos ao passar dos anos. Com base nesses ndices, conclu mos que os mecanismos de seguran ca devem ser levados em considera ca o em um bom projeto de virtualiza ca o.
1.3
Objetivos
O objetivo principal deste trabalho monogr aco ser a descrever o estudo e implementa ca o de ferramentas e t ecnicas de seguran ca a serem empregados no projeto de virtualiza c ao dos servi cos disponibilizados pela infraestrutura computacional do N ucleo de Tecnologia da Informa ca o da UFMA. Para tanto, ser ao empregados mecanismos para garantir a integridade do pr oprio hipervisor e seu sistema hospedeiro, bem como dos sistemas convidados instalados em m aquinas virtuais gerenciadas atrav es do Citrix XenServer. Objetivos espec cos:
1. Estudo dos mecanismos de seguran ca disponibilizados pelo Citrix XenServer; 2. Deni ca o da arquitetura de seguran ca para o projeto de virtualiza c ao do NTI UFMA; 3. Implementa ca o e avalia c ao dos mecanismos de seguran ca denidos.
1.4
Organiza c ao da Monograa
Este trabalho baseia-se no estudo de conceitos b asicos de virtualiza ca o, nos aspectos de seguran ca de ambientes virtualizados e ferramentas de seguran ca para o Citrix XenServer. Este trabalho est a organizado da seguinte forma: no cap tulo 2 s ao abordados conceitos b asicos de virtualiza ca o; no cap tulo 3 ser a mostrada a arquitetura do XenServer; no cap tulo 4 ser ao colocadas considera co es para a seguran ca de ambientes virtualizados;os resultados obtidos pela ferramenta s ao avaliados com um estudo de caso; o cap tulo 5 apresenta as conclus oes e sugest oes para trabalhos futuros.
15
2 Conceitos de Virtualiza c ao
Neste cap tulo ser ao apresentados os conceitos fundamentais utilizados neste trabalho bem como exemplos de produtos que os implemtam. Tamb em ser ao expostas algumas denomina c oes necess arias a ` compreens ao do assunto.
2.1
Breve Hist orico
A virtualiza ca o consiste no emprego de t ecnicas que permite dividir os recursos de um computador em m ultiplos ambientes de execu ca o, mediante a aplica ca o de um ou mais conceitos ou tecnologias, tais como particionamento de hardware e software, time-sharing, simula ca o parcial ou m aquina completa, emula ca o, qualidade de servi co, e muitos outros (SINGH, 2004). Ao contr ario do que parece, virtualiza ca o n ao e um assunto novo. As primeiras id eias sobre virtualiza ca o surgiram na d ecada de 1960, nos laborat orios do MIT (Massachusetts Institute of Technology ) para o desenvolvimento do CTSS (Compatible Time Sharing System ) para o IBM (International Business Machines ) 7094 e para o Projeto Atlas da Universidade de Manchester (LAVINGTON, 1998). Ainda na d ecada de 1960, novas t ecnicas e recursos de hardware foram empregadas no IBM System /360 Model 67, t ecnicas que permitiam a virtualiza ca o de todas as suas interfaces de hardware, permitindo executar outros sistemas operacionais. O termo supervisor foi adotado para o sistema operacional do mainframe. Mais tarde o termo hypervisor foi adotado para os sistemas que permitiam executar sistemas operacionais em outros sistemas operacionais. Nos anos de 1970 foi criada a t ecnica de P-Code (pseudo-code), que permitiu o desenvolvimento da virtualiza c ao de processadores. Esta t ecnica foi empregada no University of California, San Diego (UCSD) Pascal System (Sistema Pascal da Universidade da Calif ornia, San Diego). Este sistema compilava programas Pascal em pseudo-c odigo, para serem executados em m aquinas virtuais P-code. Algo similar era implementado na BCPL , cujo compilador gerava um c odigo intermedi ario de m aquina, denominado O-code (Object-
2.2 Tipos de Virtualiza ca o
16
code ), que em seguida seria compilado para a linguagem de m aquina de uma m aquina alvo, o que permitia portabilidade para novos equipamentos, bastando existir compilador de O-code para a segunda m aquina. O P-code e o precursor da t ecnica usada na linguagem Java que utiliza m aquinas virtuais para execu ca o de programas em diversas arquiteturas diferentes, se houver uma JVM (Java Virtual Machine ) para a arquitetura em quest ao. Em 1999, a VMWare lan ca o produto VMWare Virtual Platform para processadores com tecnologia Intel 32 bits. No ano seguinte a IBM lan ca z/VM para a famlia de grande porte System/370 (ou simplesmente S/370) Uma t ecnica relativamente recente de virtualiza ca o e a tradu c ao bin aria (binary translation ), ou virtualiza c ao de conjunto de instru co es (instructions set virtualization ) que utiliza um conjunto de instru co es virtuais que s ao dinamicamente traduzidas para o conjunto de instru c oes da m aquina f sica. Atrav es desta t ecnica pode-se, inclusive, realizar a atualiza c ao do conjunto de instru co es virtualizado. Essa t ecnica foi utilizada em 2000 nos processadores Cruseo e Eceon da empresa Transmeta e chamada de Code Morphing Software. Infelizmente a empresa encerrou as atividades em 2009, n ao dando continuidade ao desenvolvimento de seus produtos.
2.2
Tipos de Virtualiza c ao
A seguir explicamos as t ecnicas mais comuns de virtualiza c ao, citando alguns produtos que as utilizam. Daqui em diante ser ao denominados sistemas hospedeiros ou antri oes (host systems ) aqueles que executam os hipervisores ou hypervisors e sistemas h ospedes ou convidados (guest systems ) s ao aqueles que rodam dentro das m aquinas virtuais.
2.2.1
Emula c ao
Um computador inteiro e simulado por um programa, ou seja, existe um ou mais processadores, dispositivos de armazenamento, teclado, mouse, portas de entrada e sa da, BIOS (Basic Input/Output System ), controladoras, etc. que servem para enganar o sistema convidado. A emula ca o e muito u til quando e necess ario depurar um sistema que executa em uma
17
determinada plataforma que n ao seja de f acil aquisi c ao, como por exemplo consoles de videogames ou iperama antigos ou computadores que n ao s ao mais fabricados. Atrav es da emula ca o podemos executar as mais diversas combina c aes de sistemas hospedeiros e sistemas h ospedes, como por exemplo um sistema operacional Windows 98 da Microsoft sendo executado em um console Sony Playstation Port atil.
Figura 2.1: Emula c ao A Figura 2.1 mostra um sistema rodando duas m aquinas emuladas, com arquitetura de hardware diferente do hospedeiro. Seus sistemas operacionais enxergam a m aquina virtual como um sistema f sico normal. A principal vantagem da emula c ao e justamente o fato de podermos criar praticamente qualquer plataforma de hardware para ser executada em outra totalmente diferente, permitindo um grande n umeros de combina co es de sistemas hospedeiros e convidados. A maior desvantagem da emula c ao consiste na necessidade de tradu ca o de toda atividade no sistema h ospede para instru c oes do sistema hospedeiro. Isso geralmente torna o sistema hospedeiro muitas vezes mais lento do que se estivesse sendo executado em um sistema nativo.
2.2.2
Virtualiza c ao Completa
Tamb em conhecida como full virtualization e native virtualization (ou virtualiza ca o nativa) e capaz de executar sistemas hospedados sem modica ca o nas m aquinas virtuais com um desempenho razo avel Esta t ecnica utiliza um VMM que e respons avel por vigiar a execu c ao de instru co es privilegiadas diretamente no hardware hospedeiro, que e reetido para as m aquinas virtuais, ou seja, hospedeiro e convidados rodam na mesma arquitetura. O mecanismo-chave para virtualiza c ao completa e a intercepta c ao e simula ca o de
18
opera c oes privilegiadas, como instru c oes de entrada e sa da. Os efeitos de cada opera c ao realizada dentro de uma m aquna virtual deve ser mantida dentro da pr opria m aquina, ou seja, opera c oes virtuais n ao devem alterar o estado de outra m aquina virtual, do hipervisor ou do hardware real. Algumas instru co es de m aquina podem executar diretamente sobre o hardware, desde que seus efeitos estejam inteiramente contidos nos elementos gerenciados pelo hipervisor, como aloca co es de mem oria e registradores matem aticos. Instru co es que poderiam escapar da m aquina virtual n ao podem ter permiss ao para execu c ao. Elas devem ser prontamente capturadas e simuladas, pois poderiam acessar ou afetar o estado de informa c oes externas ` a m aquinab virtual (WIKIPEDIA, 2009). Por conta dessa necessidade de capturar essas instru co es e que modernas t ecnicas de tradu ca o din amica podem ser encontradas nos atuais modelos de full virtualization onde e empregada para encontrar e redirecionar instru c oes privilegiadas (CHEN et al., 2008). Nos sistemas x86 mais recentes, foram adicionadas instru c oes espec cas para virtualiza ca o. Estas instru c oes, ou extens oes de processadores, s ao o Intel VT (INTEL, 2009b) e o AMD AMD-V (AMD, 2009) respons aveis por traduzir instru co es das m aquinas virtuais que tentam acessar a reas restritas do sistema, como areas de mem orias e portas de entrada e sa da, o que n ao e desejado que aconte ca nas vers oes simplicadas da arquitetura x86, pois estas areas s ao restritas ao sistema operacional h ospede que e executado em um n vel privilegiado denominado Ring0. As extens oes de hardware para virtualiza c ao marcam as instru c oes das VMs que tentam esse acesso privilegiado e as repassam para o hipervisor, este e executado no Ring1, que as trata de forma que o acesso seja realizado de maneira segura, para suas respectivas a reas de mem oria, impedindo que este acesso invada a a rea de mem oria de outra VM ou do hipervisor, por exemplo.
Figura 2.2: Virtualiza c ao completa A Figura 2.2 mostra o esquema de um hipervisor realizando virtualiza ca o completa. As m aquinas virtuais convidadas executam sem altera c oes e percebem a mesma arquitetura
2.2 Tipos de Virtualiza ca o de hardware do sistema operacional antri ao.
19
2.2.3
Paravirtualiza c ao
Muito parecida com a virtualiza ca o completa, diferencia-se desta pelo fato do hipervisor entregar ao h ospede um sistema de hardware semelhante ao do hardware do hospedeiro, mas n ao igual. O princ pio de funcionamento da paravirtualiza ca o e a captura de instru co es privilegiadas das m aquinas virtuais pelo hipervisor que as reconnhece devido uma altera ca o na execu ca o dessas instru c oes por parte do h ospede. O hipervisor, reconhecendo tais instru co es modicadas, as repassa para o sistema antri ao, que as executa com mais agilidade, aumentando o desempenho do sistema virtualizado. Esse reconhecimento de instru c oes s o e poss vel por que a maioria dos sistemas operacionais que rodam em m aquinas virtuais paravirtualizadas s ao modicados para rotular, ou marcar, tais instru co es para que sejam adequadamente tratadas pelo hipervisor. Sistemas de paravirtualiza c ao s ao facilmente encontrados para sistemas operacionais de c odigo aberto, haja vista a facilidade de acessos ao c odigo fonte do sistema operacional convidado. Tal necessidade poderia ser um impedimento para que sistemas operacionais propriet arios fossem executados em m aquinas paravirtualizadas, mas h a relatos que servidores equipados com processadores Quad Core AMD Opteron executando sitemas Sun x64 disponibilizam a funcionalidade que habilita sistemas operacionais sem modica ca o a rodarem em m aquinas virtuais paravirtualizadas (GOLDEN; SCHEFFY, 2008). A principal vantagem da paravirtualiza ca o e que os sistemas h ospedes executam com um desempenho semelhante ao de quando rodam em sistemas f sicos, visto que alguns hipervisores disponibilizam aos h ospedes vers oes simplicadas dos componentes de hardware do hospedeiro.
Figura 2.3: Paravirtualiza c ao
2.3 Produtos de Virtualiza ca o
20
A Figura 2.3 mostra um sistema de paravirtualiza ca o rodando em uma determinada arquitetura de hardware. Essa mesma arquitetura e percebida pelos sistemas h ospedes atrav es de drivers de dispositivos alterados nas m aquina virtuais. Para um desempenho melhorado, o sistema operacional da m aquina virtual deve ser alterado.
2.3
Produtos de Virtualiza c ao
Com o passar dos tempos, as t ecnicas de virtualiza ca o foram ganhando terreno no campo da computa ca o pessoal. O que antes era visto apenas como divers ao, no papel de emuladores de videogames antigos, agora e uma ind ustria que movimenta milh oes de d olares por ano. A seguir s ao citados alguns produtos facilmente encontrados para download na Internet nos sites de seus produtores. Muitos s ao produtos com funcionalidades completas e prazo de uso para testes bem extenso. Outros s ao projetos de software livre de c odigo aberto que podem ser facilmente instalados em distribui c oes Linux e outros sistemas operacionais SL/CA e propriet arios. A apresenta ca o destes produtos segue a mesma ordem da apresenta c ao dos tipos de virtualiza ca o. Em primeiro lugar temos como exemplos de emula c ao o Bochs, QEMU e o MAME, seguidos pelos paravirtualizadores UML e Xen. Por u ltimo os virtualizadores completos VMWare, Hyper-V e Linux KVM.
2.3.1
Bochs
Bochs (BUTLER, 2009) e um emulador de sistemas x86 Open Source, distribu do atrav es da GNU (GNU Is Not Unix ) LGPL (Lesser General Public License ). Capaz de emular processadores do 386 at e sistemas x86-64. Programado em C++, pode ser executado em diversas plataformas, incluindo x86, PowerPC, SPARC (Scalable Processor Architecture ), Alpha e MIPS. Bochs Tamb em e capaz de emular instru co es espec cas dos processadores x86, como MMX (MultiMedia eXtension ), SSE (Streaming SIMD Extensions ), SSE2, 3DNow. Normalmente e instalado em sistemas Linux, Windows e Mac OS X.
21
2.3.2
QEMU
Semelhante ao Bochs, o QEMU (BELLARD, 2009) e emulador Open Source licenciado pela GPL e pode ser executado em diversas plataformas incluindo o ARM. Tamb em pode emular um sistema inteiro, mas ao contr ario do Bochs, outras plataformas al em das X8664 podem ser emuladas com tradu ca o din amica, como ARM, SPARC, PowerPC e MIPS. Outro modo de utiliza c ao, permite executar instru c oes x86 diretamente na CPU hospedeira. Neste caso e necess ario utilizar um driver chamado acelerador QEMU, Tamb em conhecido como KQEMU. O KQEMU necessita que tanto o hospedeiro como os h ospedes sejam m aquinas com processadores x86. Outra forma de executar o QEMU, conhecida como emulador de modo usu ario, permite que bin arios compilados de uma arquitetura diferente sejam executados em hospedeiros Linux.
2.3.3
MAME
MAME (SALMORIA, 2009) (Multiple Arcade Machine Emulator ) e um emulador de diversas plataformas de iperamas (ou arcades ) que pode ser executado em sistemas operacionais Linux, Windows e Mac OS X, sendo que algumas vers oes foram portadas para telefones celulares, PDAs (Personal Digital Assistants ), c ameras digitais, consoles de videogames, etc. O MAME emula diversos elementos ao mesmo tempo. Estes elementos replicam o comportamento do hardware presente nas m aquinas de iperama originais. O sistema pode emular diversos tipos e n umeros de CPUs (Central Processing Unit ), incluindo processadores, controladoras de v deo e som e microcontroladores. Al em de tratar da comunica ca o entre esses componentes e regi oes de mem oria, RAM, barramentos de dados, dispositivos de armazenamento, etc. MAME age como uma camada entre esses elementos virtualizados e o programa original do jogo para que o mesmo possa rodar no sistema hospedeiro. Os sistemas de arcade s ao especicados por drivers que tomam a forma de macros de linguagem C. Estes drivers especicam quais componentes ser ao emulados e como eles se comunicam entre si.
22
2.3.4
VMWare
Distribu do pela VMWare Inc, este sistema de virtualiza ca o completa pode ser adquirido como produto para servidor e para computadores pessoais baseados na arquitetura x86. Existem v arias vers oes do VMWare, sendo que a Workstation pode ser instalada em sistemas operacionais hospedeiros Linux ou Windows, enquanto a vers ao ESX Server pode ser instalada diretamente em servidores, sem a necessidade de um sistema operacional hospedeiro.
2.3.5
Hyper-V
Distribu do pela Microsoft, pode ser encontrado no Windows Server 2008. O Hyper-V (MICROSOFT, 2009b) implementa o isolamento entre as m aquinas virtuais por meio de parti c oes, que s ao unidades l ogicas de isolamento gerenciadas pelo hipervisor, nas quais os sistemas hospedados s ao executados. Uma inst ancia do hipervisor e executado em um sistema operacional Windows Server 2008 antri ao que recebe a denomina ca o de parti ca o pai. A pilha de virtualiza ca o executa na parti ca o pai e tem acesso direto ao hardware f sico. Atrav es de uma API chamada hypercall, a partir da parti ca o pai pode-se criar as m aquinas virtuais, denominadas parti c oes lhas que hospedam os sistemas operacionais convidados (MICROSOFT, 2009a). poss E vel executar outro virtualizador, como o VMWare dentro de uma parti c ao lha, e a partir desta instanciar outras m aquinas virtuais de 32 bits, em um ambiente aninhado, mas n ao e poss vel rodar m aquinas virtuais de 64 bits por que o Hyper-V n ao implementa as extens oes de virtualiza ca o de hardware para suas m aquinas virtuais.
2.3.6
Linux KVM
O LKVM (Kernel-based Virtual Machine ou M aquina Virtual Baseada no Kernel ) e uma solu ca o para virtualiza ca o total para Linux em arquitetura x86 que tenha extens oes de virtualiza ca o (Intel VT ou AMD-V). KVM consiste em um m odulo de kernel (kvm.ko) que disponibiliza a infraestrutura principal de virtualiza c ao e um m odulo espec co para cada tipo de processador, kvm-intel.ko ou kvm-amd.ko. O KVM necessita de uma vers ao modicada do QEMU para disponibilizar o acesso ao hardware atrav es da entrada
2.3 Produtos de Virtualiza ca o /dev/kvm do sistema hospedeiro.
23
O modo de funcionamento do KVM se diferencia dos demais produtos de virtualiza c ao pois cada m aquina virtual e executada como um processo, j a que cada sistema h ospede roda no espa co de usu ario do sistema hospedeiro. Isto torna essa abordagem mais fraca do ponto de vista do isolamento, pois cada m aquina virtual tem seus processos competindo com os demais processos do sistema hospedeiro, como se fossem processos normais do usu ario. Um novo modo de opera ca o, al em dos modo kernel e modo usu ario, e introduzido quando o KVM est a sendo executado. O modo hospedeiro, ou guest mode, e executado para toda opera c ao que n ao seja de E/S e tem seus pr oprios modos kernel e usu ario.
2.3.7
Linux em modo usu ario
UML (UML, 2009) (User mode Linux ) e um sistema de paravirtualiza c ao que permite que outros sistemas Linux sejam executados em espa co de usu ario, como um processo simples para o sistema operacional. Os h ospedes precisam ser modicados antes de sua compila c ao para serem executados no hospedeiro. Muito utilizado para depura ca o de programas e em honeypots 1 , o UML permite o aninhamento de m aquinas virtuais, ou seja, m aquinas virtuais rodando dentro de m aquinas virtuais. O UML faz parte da s erie 2.6 do kernel Linux, mas geralmente n ao est a habilitado por padr ao nas distribui c oes, o que indica a necessidade de instala c ao de uma vers ao do kernel com UML a partir dos reposit orios da distribui c ao ou a recompila c ao do c odigo fonte do kernel com a op ca o do UML habilitada. Os h ospedes utilizam os dispositivos f sicos do hospedeiro da mesma forma que um processo comum, sendo poss vel alterar a prioridade dos processos dos h ospedes normalmente, dessa forma controlando a utiliza c ao dos recursos por parte dos h ospedes.
1
Um honeypot e um recurso computacional de seguran ca dedicado a ser sondado, atacado ou compro-
metido (CERT.BR, 2009b).
2.4 Conclus oes
24
2.3.8
Xen
Solu ca o de c odigo aberto que utiliza paravirtualiza ca o. Foi criado pelo projeto XenoServer da Universidade de Cambridge, sendo mais tarde adquirido pela empresa Citrix que continua a desenvolv e-lo cooperativamente com desenvolvedores do mundo todo. O hipervisor Xen (CITRIX, 2009) colabora com o kernel do sistema operacional na paravirtualiza ca o, sendo necess arias modica c aes no kernel dos h ospedes para que os mesmos possam ter um desempenho pr oximo aos dos sistemas rodando em ambiente f sico. A modica ca o no c odigo dos sistemas h ospedes e uma grande vantagem para sistemas Linux que podem ser facilmente alterados, pois tem seu c odigo fonte dispon vel, o que n ao ocorre em sistemas propriet arios como o Windows da Microsoft, que ainda assim pode ser executado em servidores Xen rodando em processadores com extens oes de virtualiza ca o. Outros sistemas que tamb em s ao suportados pelo Xen s ao: Minix, Plan 9, NetBSD, FreeBSD, e OpenSolaris.
2.4
Conclus oes
Como foi visto, existem atualmente v arias t ecnicas de virtualiza c ao, cada qual com suas caracter sticas e aplicacabilidade pr oprias. Uma das caracter sticas mais procurada pelos usu arios e a capacidade de executar diversos sistemas operacionais diferentes e suas aplica co es em um mesmo equipamento. Economia de recurso de hardware, atrav es de seu uso otimizado pelos programas e usu arios, bem como economia de energia el etrica tamb em s ao caracter sticas usualmente importantes. A emula c ao, a paravirtualiza ca o e a virtualiza c ao completa ganham destaque em a reas e atua c oes distintas. Enquanto a primeira e muito utilizada para dar vida a antigos sistemas, como plataformas legadas de computa c ao e jogos, as outras duas s ao muito usadas em sistemas de virtualiza ca o mais complexos, como os da Microsoft, VMWare e Citrix que s ao utilizadas para virtualiza c ao em esta co es de trabalho para testes e avalia ca o de programas e em servidores que podem hospedar dezenas de m aquinas virtuais ao mesmo tempo.
2.4 Conclus oes
25
Na avalia ca o de qual t ecnica pode ser melhor empregada devemos tamb em levar em considera ca o o quadro atual das aplica c oes que s ao executadas ou que ser ao desenvolvidas e/ou instaladas nos servidores, visto que algumas t ecnicas de virtualiza c ao permitem ou at e mesmo exigem altera co es nos sistemas operacionais das m aquinas virtuais. Na pr atica, observa-se que a gama de sistemas operacionais que os usu arios necessitam virtualizar s ao predominantemente executados em arquitetura x86. Isto motivou o desenvolvimento de hardware espec co com extens oes de virtualiza ca o nos processadores modermos que permite a execu ca o de sistemas paravirtualizados e completamente virtualizados com pouca perda de desempenho. Diversos produtos implementam a virtualiza ca o em suas mais variadas formas, sendo que alguns projetos reutilizam c odigo de outros para alterar ou incrementar suas funcionalidades, como e o caso do XenServer que utiliza o c odigo aberto do Xen para implementar suas funcionalidades.
26
3 XenServer
Assim como o Xen, o XenServer1 e um hipervisor de paravirtualiza c ao, o que implica dizer que os sistemas convidados precisam ser alterados para serem instalados nas m aquinas virtuais. Neste trabalho, daremos enfase no uso do sitema Linux. No entanto, tamb em h a a possibilidade de instalar convidados Microsoft Windows em VMs XenServer. Para tanto, e necess aria a instala c ao de drivers para a m aquina Virtual dentro do sistema h ospede para que o mesmo tire proveito do desempenho do acesso ao hardware do sistema hospedeiro, executando sistemas virtuais paravirtualizados e em virtualiza ca o completa, este u ltimo com o aux lio das extens oes de virtualiza c ao dos processadores (PRATT et al., 2005).
3.1
Estrutura do XenServer
O Xen e executado na forma de um kernel Linux modicado com o hipervisor integrado. Existem v arias op co es de pacotes de kernel Linux com Xen dispon veis para as mais diversas distribui c oes. Devido a ` facilidade de instala c ao, opera c ao e funcionalidades, as distribui co es mais utilizadas s ao: SUSE (RYSMITH, 2009), Open SUSE, RedHat, Fedora e CentOS. O XenServer e distribu do junto a uma vers ao reduzida e modicada do CentOS de 64 bits, tornando-o um sistema operacional de f acil opera ca o e manuten ca o, j a que conta com consider avel n umero de ferramentas e comandos oriundos do RedHat Enterprise Linux, distribui ca o da qual o CentOS deriva, e que e l der no segmento Linux para servidores corporativos. A implementa c ao do sistema hospedeiro em 64 bits permite a utiliza ca o de servidores com alta capacidade de mem oria, superior ao limite de 4 GB encontrado em sistemas de 32 bits, bem como o uso de sistemas h ospedes de 64 bits e suas aplica co es. Sendo um hipervisor capaz de paravirtualizar os sistemas convidados, o XenServer ne1
O XenServer e a implementa c ao da empresa Citrix do hipervisor Xen. A vers ao mais atual e a 5.5,
que pode ser encontrado para download gratuito em (SYSTEMS, 2009).
3.1 Estrutura do XenServer
27
cessita de modica co es nos sistemas operacionais h ospedes para disponibilizar aos mesmos um desempenho bem pr oximo do encontrado em m aquinas f sicas.
Figura 3.1: Estrutura de um sistema XenServer e seus dom nios A estrutura do Xenserver e ilustrado na Figrua 3.1. O sistema hospedeiro do XenServer e denominado domain0 ou dom0 e suas m aquinas virtuais s ao chamadas domainU ou domU (U de Unprivileged ou sem privil egios). O dom0 e executado em um n vel privilegiado chamado ring0, enquanto os domUs s ao executados no ring1, com menos privil egios de acesso aos recursos da CPU do equipamento onde est ao instalados. Os an eis de prote ca o s ao mecanismos de seguran ca encontrado nos processadores x86 e compat veis. O ring0 e o n vel de execu ca o mais privilegiado, o que signica que os processos executados nesse n vel tem maior prioridade para o processador, conforme ilustrado na Figura 3.2. Por essa raz ao o ring0 e o local natural de execu c ao do kernel dos sistemas operacionais, como o hipervisor xen, que ser a respons avel por gerenciar adequadamente os domUs nos outros rings. Sendo executado no ring0, o dom0 e capaz de restringir o acesso a dados, portas de comunica ca o ou a execu ca o de instru c oes privilegidas (INTEL, 2009a) por parte dos domUs. O ring1 e utilizado pelos drivers de dispositivos do sistema antri ao e pelas m aquinas virtuais. Naturalmente, no dom0 encontram-se as ferramentas de adminstra c ao do XenServer. Tais ferramentas podem ser acessadas atrav es da interface de linha de comando ou atrav es de uma interface gr aca chamada XenCenter, dispon vel para istala ca o em esta c oes Win-
3.2 Caracter sticas Principais do XenServer
28
Figura 3.2: An eis de execu ca o dows. Tanto os comandos instalados no hospedeiro do XenServer quanto o XenCenter s ao capazes de criar e apagar domUs, criar, apagar e alocar dispositivos para as m aquinas virtuais, conectar o XenServer a outros servidores e storages trativas.
2
e demais tarefas adminis-
3.2
Caracter sticas Principais do XenServer
O XenServer 5.5 traz muitos melhoramentos em rela c ao a `s vers oes anteriores, al em do fato de poder ser baixado gratuitamente do site da empresa. Entre as caracter sticas destacadas pelo fabricante, est ao:
Backup e suporte a snapshot melhorados: permite realizar opera co es de snaphots e clones ao vivo, sem a necessidade de interromper a execu c ao das m aquinas virtuais. Os snapshots s ao c opias instant aneas da m aquina virtual em execu ca o, inclusive com seus metadados, que podem ser recuperedas em caso de emerg encia, enquanto clones s ao c opias de uma VM que pode ser usada para cria c ao de outra VM semelhante. Integra c ao com o Active Directory (AD):
3
permite a verica c ao de credenciais
por um servidor de AD, permitindo dar ou retirar acesso aos grupos de XenServer utilizando a infraestrutura de autentica c ao existente. Balanceamento de carga para otimizar a distribui ca o de m aquinas virtuais dentro
2
Storages s ao locais de armazenamento, geralmente discos r gidos locais, mas em alguns casos podem
ser equipamentos dedicados com v arios discos que podem ser acessados atrav es da rede. 3 O Active Directory e a implementa c ao da Microsoft do servi co de diret orio do protocolo LDAP (Lightweight Directory Access Protocol ) que armazena e disponibiliza informa c oes sobre objetos de rede de computadores a usu arios e administradores.
3.3 Ferramentas de Gerenciamento
29
de um grupo de XenServer. Realizado pelo servidor Workload Balancing, dispon vel para download. Integra c ao com servi cos de armazenamento da Citrix via linha de comando habilitando gerenciamento avan cado de armazenamento, como descoberta autom atica de storages, gerenciamento centralizado de storages e backups, biblioteca de clones de VMs e comunica c ao do XenServer com equipamentos de backup de terceiros. Suporte melhorado ` as novas vers oes de sistemas operacionais, como o Red Hat Enterprise Linux 5.3, Novell SLES 11 e Debian Lenny, pois estas distribui co es n ao eram suportadas pelas vers oes anteriores do XenServer. Melhorias no XenCenter, incluindo Folder View (vis ao em pasta), permitindo visualizar os recursos como lista simples ou dentro de pastas, e melhoria no mecanismo de pesquisa de m aquinas virtuais atrav es de palavras-chaves.
As capacidades do XenServer fazem dele um poderoso sistema, capaz de entregar aos seus operadores uma gama de poderosas caracter sticas para o gerenciamento das m aquinas virtuais. Muitas dessas funcionalidades n ao s ao encontradas em sistemas de virtualiza ca o propriet arios de custo elevado ou mesmo em outros projetos de virtualiza ca o SL/CA. Al em disso, a sua natureza de Software Livre e de C odigo Aberto permite que os mecanismos do XenServer sejam vistoriados e auditados caso haja necessidade, o que garante uma qualidade de c odigo fonte que pode ser questionada e vericada por um desenvolvedor ou equipe qualicados. A integra ca o dessas caracter sticas em produtos do mesmo fabricante garante uma alta compatibilidade, devido a utiliza ca o de bibliotecas, interfaces e ferramentas, muitas das vezes fechadas e propriet arias, comuns aos equipamentos e softwares de mesmo fabricante.
3.3
Ferramentas de Gerenciamento
Entre as vantagens da virtualiza ca o (MATHEWS et al., ) est a a otimiza ca o do uso dos recursos dos computadores que antes deveriam ser separados sicamente em servidores e segmentos de redes diferentes e que agora podem residir no mesmo equipamento e ainda assim serem isolados em redes distintas.
30
Para realizar as tarefas administrativas referentes aos ambientes virtualizados temos que utilizar as ferramentas de administra ca o disponibilizadas pelo pr oprio fabricante do hipervisor ou ent ao procurar solu co es padronizadas, seja pela ind ustria, seja por desenvolvedores ou grupos de programadores ou hackers envolvidos nos diversos projetos de virtualiza ca o j a mencionados, por exemplo. Os esfor cos para padroniza ca o da comunica c ao de hipervisores produziram a API (Application Programming Interface ) libvirt (LIBVIRT, 2009), um conjunto de bibliotecas que permite acessar e administrar diversos hipervisores como o Xen, KVM/QEMU, OpenVZ, UML e VirtualBox (SCHERF, 2009). Sendo um projeto de software livre, a libvirt pode ser compilada a partir do c odigo fonte ou instalada como pacote atrav es de ferramentas das principais distribui c oes Linux. A import ancia de uma ferramenta para gerenciar o servidor de m aquinas virtuais e atrav crucial para o aproveitamento dos recursos do equipamento entre as VMs. E es dela que as m aquinas virtuais s ao criadas, apagadas, movidas e clonadas A ferramenta deve tamb em disponibilizar os meios para a cria ca o, disponibiliza c ao e realoca ca o de dispositivos virtuais como discos, m dias de CD (Compact Disc ) e DVD (Digital Video Disc ), adaptadores de rede, segmentos de redes virtuais, entre outros componentes. Para um gerenciamento con avel dos servidores de m aquinas virtuais, a ferramenta de gerenciamento deve ser capaz de ser executada diretamente no sistema hospedeiro ou de se conectar remotamente de maneira segura, o que implica em pelo menos uma forma de autentica c ao. A libvirt e capaz de realizar essa conex ao atrav es de t unel SSH (Secure SHell ), TLS (Transport Socket Layer )/SSL (Secure Socket Layer ), com certicados X.509 e Kerberos. O XenServer tamb em permite conex oes via SSH e SSL, sendo essa u ltima utilizada pelo XenCenter para administra ca o de servidores e grupos de servidores. poss E vel acessar o XenServer atrav es do virt-manager, mostrado na Figura 3.3, uma interface gr aca para gerenciamento de hipervisores que utiliza a libvirt para repassar os comandos e instru co es partir de uma esta ca o Linux. No entanto, para isso e necess ario a instala c ao da libvirt no servidor e a execu c ao do daemon libvirtd e mandat oria nos dois pontos, para que haja di alogo entre a esta c ao de gerenciamento e o servidor gerenciado. A Figura 3.3 mostra a tela do virt-manager onde e congurada a conex ao com um
31
Figura 3.3: Congurando a conex ao com um hipervisor remoto no virt-manager servidor remoto e a Figura 3.4 mostra a tela do XenCenter onde e adicionada uma nova conex ao com um servidor XenServer. Apesar de ser executado e distribu do junto com uma distribui ca o Linux aberta, a Citrix desencoraja a instala ca o de qualquer programa dos reposit orios do CentOS em servidores XenServer, apesar dessa possibilidade existir j a que os reposit orios do CentOS continuam dispon veis na congura ca o do hospedeiro do XenServer. O fato e que a Citrix n ao d a suporte a aplica co es que n ao foram instaladas por padr ao junto com o XenServer, e a vers ao do CentOS que serve de base para o hipervisor e modicada, n ao havendo garantia para o funcionamento de outras aplica co es. O XenCenter, ilustrado na Figura 3.4, e um programa que pode ser baixado a partir do site da Citrix, para instala ca o em computadores com Microsoft Windows, n ao havendo vers oes para Linux. Ele e um painel de controle, do qual podem ser acessados e gerenciados servidores de m aquinas virtuais, pools de servidores e as m aquinas instaladas nesses servidores. O uso do XenCenter e necess ario para acessar facilmente todas as funcionalidades do hipervisor, o que n ao e poss vel com o virt-manager, que possui apenas funcionalidades b asicas. O XenCenter tamb em e capaz de acessar o console da linha de comando
3.4 Alta Disponibilidade
32
Figura 3.4: Congurando a conex ao com um servidor no XenCenter do servidor para uma manuten c ao mais renada, como pode ser visto na Figura e 3.5. O gerenciamento dos servidores XenServer do NTI e realizado atrav es de esta co es de trabalho que executam o XenCenter rodando em m aquinas virtuais Windows, isoladas da rede p ublica e da rede administrativa da UFMA.
3.4
Alta Disponibilidade
Uma das maiores preocupa co es da seguran ca de informa ca o e disponibilidade da informa ca o quando algo acontece com os servidores respons aveis pelo armazenamento das aplica c oes e dados. Um sistema de alta disponibilidade ou HA (High Availability ) e um sistema inform atico resistente a falhas de software, hardware e energia, cujo objetivo e manter os servi cos disponibilizados o m aximo de tempo poss vel (TAVARES, 2009). Boa parte dos hipervisores, incluindo o XenServer fazem uso da tecnologia desenvolvida para o sistema hospedeiro. O sitema operacional GNU/Linux, sobre o qual s ao executados o Xen e o XenServer tem uma vasta gama de op co es para prover alta disponibilidade.
33
Figura 3.5: Acesso ao console do XenServer pelo XenCenter. Atrav es do uso de t ecnicas como agrega c ao de interfaces de rede 4 , DRDB (LINBIT, 2009), HeartBeat (KLEINER, 2009) e recursos dispon veis nativamente em equipamentos NAS (Network Attached Storage - Armazenamento Ligado em Rede) e poss vel dispor de sistemas que podem sofrer falhas em alguns pontos de sua estrutura sem que isso implique em indisponibilidade da informa ca o. A princ pio, um sistema de alta disponibilidade necessita de um grande n umero de componentes duplicados. Discos r gidos, placas de rede, segmentos de conex ao, switches, reposit orios de dados, entre outros podem ser duplicados para que se obtenha um n vel aceit avel de disponibilidade de acesso ` as informa co es e arquivos providos pela estrutura de servidores. Em um ambiente virtualizado, podemos contar com alguns desses componentes virtualizados, o que pode ou n ao ser uma boa alternativa, visto que o pr oprio servidor onde as
4
A agrega c ao de interfaces ou Bonding ou ainda port trunking, permite que duas ou mais interfaces
f sicas de rede possam ser vistas como uma u nica interface l ogica, podendo servir para prover toler ancia a falhas entre links, alta disponibilidade (redund ancia) e balanceamento.
34
VMS e os componentes duplicados residem pode sofrer alguma avaria que os incapacite de prover seus recursos.
Figura 3.6: Exemplo de um sistema capaz de prover alta disponibilidade. No esquema da Figura 3.6, temos um exemplo de um sistema de alta disponibilidade. Os switches 1 e 2 tem congura co es semelhantes, inclusive o endere camento de rede, e est ao ligados entre si e aos demais equipamentos atrav es de portas de alta velocidade. Neste exemplo, apenas o switch 1 tem ativada a interface que o liga ` a rede externa para que n ao haja conito com o endere co de rede do switch 2. Se o switch 2 perceber que o switch 1 for desligado ou perder a comunica ca o, ativa a interface ligada a ` rede externa assumindo o endere co de rede do switch desativado. Este monitoramento m uto e feito atrav es das interfaces que interligam os dois switches. O mesmo esquema pode ser empregado nos servidores, sendo que cada um ca monitorando o outro atrav es de uma interface de comunica c ao dedicada, e quando um deles e desativado ou perde a comunica c ao o outro assume suas funcionalidades e suas m aquinas virtuais, armazenadas no storage centralizado. Os servidores XenServer s ao integrantes de um grupo de servidores (pool ), sendo que um deles atua como mestre do grupo, e e respons avel por gerenciar os metadados das m aquinas virtuais dos outros servidores do pool. O storage da Figura 3.6 pode ser tanto
35
um servidor de storage quanto um grupo deles, organizados em uma SAN (Storage Area Network) 5 , para maior redund ancia. Quando trabalham em sistema de alta disponibilidade, os servidores XenServer integrantes do poll vericam continuamente a sua sa ude e a dos demais servidores atrav es de sinais de heartbeat, literalmente batida card aca. Quando e detectada a aus encia de um dos servidores (ou a sua morte), signicando que houve uma queda de energia ou a interrup ca o de comunica ca o, as m aquinas virtuais e movida para outro servidor. A transfer encia de m aquinas virtuais entre servidores XenServer e poss vel devido ao fato de seus metadados e seus discos virtuais serem armazenados na estrutura de storage centralizado, seja ele um dispositivo ou um grupo deles, que devem ser registrados devidamente e associados ao pool de servidores XenServer. Algumas provid encias s ao tomadas pelo XenServer para assegurar que n ao haver a dois servidores em um pool executando as mesmas m aquinas virtuais. Caso um servidor perceba que est a sem comunica ca o com o pool, este realizar a um teste, denominado selffencing. Quando uma a ca o de self-fence e realizada por um servidor ele reinicia, parando automaticamente todas as suas VMs. Os outros servidores do pool detectam que as VMs n ao est ao mais sendo executadas e instanciam as VMs interrompidas. Posteriormente, o servidor que foi reiniciado tentar a entrar novamente no pool e recuperar suas m aquinas virtuais. Para que uma VM seja protegida por HA, ela precisa ser agil. Isto signica que: Ela precisa ter seus discos virtuais armazenados em storages compartilhados (qualquer tipo de storage compartilhado pode ser usado, inclusive servidores de arquivos remotos NFS (Network File System ) ou SMB/CIFS (Server Message Block/Common Internet File System ); LUNs (Logical Units ) iSCSI6 ou Fibre Channel 7 s ao requisitos para heartbeat de storage e podem ser usados para armazenamento de discos virtuais).
5
Diferentemente do NAS que compartilha diret orios, uma SAN disponibiliza dispositivos de blocos
atrav es da rede para seus clientes. 6 Protocolo de Internet orientado a conex ao, que possibilita o transporte de comandos SCSI atrav es de redes IP. 7 Tecnologia de rede de alta velocidade que utiliza o protocolo de transporte FCP (Fibre Channel Protocol ) para transporte de comandos e SCSI a equipamentos como os storages.
3.5 Conclus oes
36
N ao deve estar conectado a um drive f sico de DVD, pois a m aquina virtual n ao deve ter refer encias f sicas com o hospedeiro, para n ao conitar com outros dispositivos f sicos existentes em outros servidores. Deve ter suas interfaces virtuais de rede integrando a rede do pool de servidores pois os metadados dos dispositivos virtuais n ao devem pertencer apenas ao servidor. A Citrix recomenda fortemente o uso de uma interface de rede agregada (bonding ) para uso como interface de gerenciamento nos servidores do pool quando a alta disponibilidade estiver habilitada, al em de storage com multipath 8 para as interfaces do heartbeat. A alta disponibilidade e uma t ecnica bem madura e e suportada de diversas maneiras pelo Linux, o que foi aproveitado pela Citrix para desenvolver a sua solu c ao de HA baseada nas ferramentas j a desenvolvidas. Aproveitando o suporte nativo de equipamentos de storage, o XenServer e capaz de realizar a migra c ao de m aquinas virtuais de maneira quase impercept vel ao usu ario dos sistemas.
3.5
Conclus oes
O Citrix XenServer e um produto robusto e repleto de funcionalidades que podem e devem ser utilizadas em conjunto com caracter sticas de outros produtos como equipamentos de armazenamento e rede para prover um ambiente transparente ao usu ario. As diversas ferramentas de administra ca o compostas por interfaces de linha de comando e programas de interface gr aca auxiliam e se complementam para facilitar o trabalho da equipe de administradores dos servidores e suas m aquinas virtuais. A possibilidade de manter v arios servidores trabalhando em grupo tamb em permite o uso de recursos de alta disponibilidade, necess aria para garantir o m aximo de utiliza ca o dos sistemas em caso de falha de um dos servidores ou de algum componente do canal de conex ao entre os servidores e as esta c oes do cliente. O projeto de virtualiza ca o do NTI da UFMA contempla o uso do XenCenter, a prin8
O multipath e uma t ecnica que permite fazer com que duas ou mais interfaces de rede possam ser
utilizadas para trafegar a mesma informa c ao. A informa c ao pode ser distribu da entre as interfaces, aumentando a velocidade de comunica c ao. Caso seja detectado algum problema em uma delas, como queda na conex ao, falha na interface que participava da comunica c ao, ou perda da placa de rede
3.5 Conclus oes
37
cipal ferramenta de administra ca o do XenServer e um resposit orio centralizado para as m aquinas virtuais de um grupo de servidores interligados entre si atrav es de conex oes de alta velocidade que prover ao alta disponibilidade em diversos n veis. Estes mecanismos estar ao dispon veis aos usu arios de forma transparente, pois al em de serem utilizados equipamentos novos e mais potentes, tamb em ser ao utilizados canais redundantes e agregados de conex ao, permitindo um acesso mais agil a `s informa c oes necess arias para as comunidades acad emica, administrativa e os diversos clientes externos a ` Universidade.
38
4 Aspectos e Mecanismos de Prote c ao e Seguran ca Implementados no Projeto de Virtualiza c ao dos Servi cos do NTI
O NTI, enquanto respons avel pelos sistemas de informa ca o da UFMA, tem realizado diversos esfor cos para garantir a seguran ca dos dados administrativos da Universidade e dos servidores que guardam e processam suas informa co es, como p aginas de projetos de pesquisa, de pr o-reitorias e outros. Todo o conte udo dessas informa c oes deve ser protegido contra tentativas de acesso ou altera ca o n ao autorizados, que constituem os ataques e amea cas, mas os acessos leg timos devem ser plenamente atendidos pelos servi cos ofertados aos usu arios. O compartilhamento de sistemas computacionais por v arios usu arios pode levar a diversos problemas, como por exemplo o acesso n ao autorizado dos dados de um usu ario por terceiros, a altera ca o das informa co es por usu arios sem permiss ao para tal e a incapacidade dos sistemas em disponibilizar seus servi cos. A seguran ca em ambientes computacionais diz respeito ao tratamento dessas amea cas, preservando as informa co es corporativas ou pessoais. Neste caso, informa ca o e todo e qualquer conte udo ou dado que tenha valor para alguma organiza ca o ou pessoa. Ela pode estar guardada para uso restrito ou exposta ao p ublico para consulta ou aquisi c ao. Para casos de avalia c ao das medidas de seguran ca, podem ser estabelecidas m etricas para deni ca o do n vel de seguran ca existente e requerido, permitindo uma an alise para melhoria da seguran ca existente. A seguir s ao expostos alguns pontos que ser ao considerados importantes no projeto de virtualiza ca o da UFMA, bem como algumas t ecnicas que ser ao empregadas para prover a seguran ca necess aria para a execu ca o das aplica c oes em m aquinas virtuais hospedadas nos servidores do NTI.
4.1 Seguran ca de Ambientes Virtualizados
39
4.1
Seguran ca de Ambientes Virtualizados
A seguran ca de uma determinada informa ca o pode ser afetada por fatores comportamentais e de uso de quem se utiliza dela, pelo ambiente ou infra-estrutura que a cerca ou por pessoas mal intencionadas que tem como objetivos capturar, furtar, destruir ou modicar tal informa ca o. Segundo (KUROSE; ROSS, 2007) as propriedades da comunica c ao segura que orientam a an alise, o planejamento e a implementa c ao de pol ticas de seguran ca s ao: condencialidade, autentica c ao, integridade e disponibilidade.
Condencialidade - Propriedade que limita o acesso ` a informa c ao a `s entidades autorizadas pelo propriet ario da informa ca o; Autentica c ao - Propriedade que garante aos envolvidos a identidade de seus pares na troca de informa c oes; Integridade - Propriedade que garante que a informa c ao manipulada mantenha todas as caracter sticas originais estabelecidas pelo propriet ario da informa ca o, incluindo controle de mudan cas e garantia do seu ciclo de vida (nascimento, manuten c ao e destrui c ao); Disponibilidade - Propriedade que garante que a informa c ao esteja sempre dispon vel para o uso leg timo, ou seja, por aqueles usu arios autorizados pelo propriet ario da informa c ao. Em todas as fases da evolu ca o corporativa, e fato que as transa co es de toda a cadeia de produ ca o - passando pelos fornecedores, distribuidores e consumidores - sempre tiveram a informa c ao como uma base fundamental de relacionamento e coexist encia.
Estas caracter sticas devem ser observadas durante o projeto e an alise de solu co es de ambientes virtualizados, pois tanto os servidores de virtualiza c ao quanto as m aquinas virtuais devem contar com dispositivos que permitam ou garantam a comunica ca o segura entre os diversos componentes que formam a solu ca o a ser adotada, tais como acesso aos servidores e ` a ger encia das m aquinas virtuais a partir de esta c oes de trabalho para esta nalidade.
4.2 Isolamento Total
40
4.2
Isolamento Total
Em um ambiente heterog eneo onde v arios sistemas devem trocar informa co es importantes entre si n ao e raro o emprego de diversas solu co es para um determinado problema. Sistemas administrativos, de monitoramento, de controle de estoque, de recursos humanos, entre outros, que devem ter suas informa co es dispon veis aos usu arios e a outros sistemas geralmente s ao executados em m aquinas com arquiteturas distintas, cada qual com seu sistema operacional e aplicativos com fabricantes e vers oes diferentes. A integridade das informa co es trocadas entre os diversos sistemas deve ser assegurada e uma das muitas formas de se garantir que uma informa ca o e exatamente aquela solicitada e evitando que usu arios maliciosos tenham acesso ao meio de comunica ca o por onde trafegam os pacotes de comunica c ao entre os pontos envolvidos. O XenServer conta com caracter sticas dispon veis no sistema operacional Linux que disponibilizam um canal exclusivo de comunica c ao interno ao kernel entre suas interfaces de rede, f sicas ou n ao, podendo-se criar segmentos de rede num u nico servidor por onde podem trafegar as informa co es entre os servi cos. Essa comunica ca o interna tamb em pode ser feita entre VMs para isolar completamente os servi cos da rede externa. Onde n ao houver necessidade de comunica ca o com o meio externo, pode ser criado um segmento de rede interna para comunica ca o exclusiva entre as VMs envolvidas. Uma das VMs pode se comunicar com o mundo externo atrav es de outro segmento de um adaptador de rede virtual, ligado a um segmento de rede do Dom0. No Xenserver os adaptadores de rede ligados ao hospedeiro s ao chamados de PIFs (Physical Network Interfaces ), enquanto os adaptadores de rede das m aquinas virtuais s ao denominados VIFs (Virtual Network Interfaces ). Os segmentos de redes virtuais recebem o nome de networks e s ao tratados como switches virtuais de rede, aos quais as PIFs e as VIFs s ao ligadas. A interliga ca o das interfaces de rede f sicas e virtuais pode ser realizada pela interface de linha de comando ou atrav es do XenCenter, que oculta a complexidade da cria c ao e administra ca o dos objetos de rede do XenServer. O gerenciamento do XenServer e realizado internamente atrav es de chamadas ` a XAPI (Xen Enterprise Management API ), uma API capaz de ser utilizada com modernas lin-
4.2 Isolamento Total guagens de programa c ao como python ou mesmo java script1 .
41
Figura 4.1: Isolamento de m aquinas virtuais da rede externa. A Figura 4.1 demonstra uma maneira de como prover isolamento de rede de uma m aquina virtual. A m aquina virtual DomU A comunica-se com o hospedeiro atrav es da sua interface virtual de rede vif1.0 que est a interligada ao segmento de rede conectado a ` interface f sica eth0 do hospedeiro. Verique que n ao h a comunica ca o direta da DomU B e a rede externa, mas apenas com a DomU A, atrav es de um segundo segmento de rede virtual, interno ao dom0. Dessa forma, utilizando congura co es de rede pr oprias dos sistemas operacionais das VMs, elas podem trocar informa c oes entre si. Tal cen ario tamb em serve como base para uma aplica ca o de rewall, onde a DomU A pode servir de meio de prote c ao para uma ou mais m aquinas virtuais que estariam interligadas no segundo segmento de rede virtual. Para isso, o sistema operacional da VM deve ser capaz de prover roteamento entre suas interfaces de rede e realizar algum tipo de ltro de pacotes, como o Linux.
1
A documenta c ao da XAPI e alguns exemplos de uso da XAPI est ao dispon veis no endere co eletr onico
http://community.citrix.com/display/xs/Introduction+to+XenServer+XAPI
4.3 Cuidados com o Hipervisor
42
4.3
Cuidados com o Hipervisor
A seguran ca do hipervisor e um dos pontos cruciais do ambiente virtualizado, visto que o mesmo e o respons avel por controlar, acessar e gerenciar as atividades das m aquinas virtuais. O acesso ao hospedeiro do hipervisor deve ser o mais restrito poss vel, j a que a sua utiliza ca o por pessoal n ao credenciado e um risco a ` seguran ca das m aquinas virtuais e suas informa co es. A possibilidade de parada, apagamento ou captura de uma m aquina virtual e um fato relatado (QUYNH, 2007) e at e mesmo demonstrado em confer encias (RUTKOWSKA, 2008), portanto e um cuidado que deve ser muito bem planejado e implementado. A principal preocupa ca o nesses casos deve ser a seguran ca do hospedeiro do hipervisor, que a princ pio deve ser respons avel exclusivamente por administrar suas m aquinas virtuais. Quanto mais servi cos agregados ao hospedeiro, maiores s ao os riscos potenciais a ` seguran ca do equipamento, j a que diariamente s ao feitos v arios an uncios de vulnerabilidades de diversos produtos, como pode ser vericado em (SECUNIA, 2009) e (SECURITYFOCUS, 2009). Torna-se imprescind vel que a equipe de administradores esteja atenta a divulga c ao de vunerabilidades dos produtos que s ao executados em seus servidores para que as corre co es sejam aplicadas o mais r apido poss vel. Um aspecto importante relativo a ` seguran ca do hospedeiro e tomar provid encias para garantir que apenas usu arios leg timos do sistem tenham acesso ` as ferramentas administrativas, seja por meio da linha de comando ou atrav es de alguma interface gr aca, local ou remota.
4.4
Autentica c ao
Uma das maneiras mais simples de garantir acesso de um usu ario leg timo a um sistema computacional e realizando a autentica c ao deste usu ario e logo depois, aplicando regras de autoriza ca o de acordo com a parte do sistema que o usu ario deseja acessar. Dentre as diversas formas de autentica ca o, a mais usada ainda e o desao usu ario
4.4 Autentica ca o
43
X senha, onde um prompt ou tela de autentica c ao aguarda a entrada de um nome de usu ario do sistema e uma senha. Quando algu em entra com os dados, um sistema de autentica c ao verica se o usu ario existe e se a senha digitada confere com a do nome de usu ario declarado. Caso uma das informa co es n ao exista ou esteja incorreta o sistema de autentica c ao retorna a ` situa c ao inicial e aguarda uma nova entrada. Em sistemas Linux, a forma usual de autentica ca o e a que utiliza os arquivos /etc/passwd e /etc/shadow, que armazenam, respectivamente, os dados dos usu arios e suas senhas criptografadas. Existem outras formas de autentica ca o para Linux, muitas s ao implementadas como m odulos PAM (Pluggable Authentication Modules - M odulos de Autentica c ao PLug aveis ) (SAMAR; SCHEMERS, 1995). Existem diversos m odulos dispon veis, como pode ser visto em (kernel.org kernel.org, 2009), capazes de realizar autentica ca o a partir de bases de dados locais ou remotas, por meio de biometria, tokens como pen-drives USB (Universal Serial Bus ) ou dispositivos bluetooth, cando a crit erio da equipe de gerenciamento dos servidores como dar-se- a a autentica c ao dos usu arios nos equipamentos. Em ambientes corporativos que executam diversas aplica co es e comum que diversos sistemas interoperem para disponibilizar aos usu arios as ferramentas necess arias para sua produtividade, ent ao e f acil encontrar v arios produtos de software de diversas empresas diferentes em um mesmo ambiente, como processadores de textos, planilhas, sistemas operacionais, etc. Uma das formas mais comuns de autentica c ao encontrada em ambientes mistos de produ c ao e o login em um servidor centralizado de contas de usu arios, como o Active Directory 2 , produto integrante dos Windows 2003 Server e Windows 2008 Server da Microsoft. Al em de poder usar m odulos PAM para autentica ca o, o XenServer teve uma importante adi c ao em suas funcionalidades. A empresa Likewise Software, integrou o seu produto Likewise Open ao XenServer (LIKEWISE, 2009), possibilitando ao XenServer se beneciar das vantagens do dom nio AD (Active Diretory ), como autentica ca o, agrupamentos de usu arios e permiss oes de acessos a `s m aquinas virtuais. Esta funcionalidade pode ser ativada tanto no console do servidor, como atrav es da interface de gerenciamento XenCenter. Caso n ao seja acionada a autentica ca o em um AD, as formas de autentica c ao
2
O Active Directory e uma implementa c ao de servi co de diret orio no protocolo LDAP (Lightweight Di-
rectory Access Protocol ) que armazena informa c oes sobre objetos em rede de computadores e disponibiliza essas informa c oes a usu arios e administradores desta rede.
4.5 Firewall
44
dispon veis s ao: localmente atrav es de do login do usu ario root, remotamente atrav es de uma sess ao SSH ou atrav es do XenCenter, tamb em utilizando o usu ario root. A op ca o de menu do XenCenter onde pode ser congurado o login do sistema em um AD pode ser vista na Figura 4.2.
Figura 4.2: Op ca o do menu que permite o XenCenter congurar o login do servidor em um AD.
4.5
Firewall
Entre as medidas tomadas para refor car a seguran ca do ambiente computacional do NTI est a o emprego de um servidor de grande capacidade respons avel pelo rewall que ca entre a rede externa e as diversas redes que compoem a estrutura administrativa da UFMA, conforme mostrado na Figura 4.3.
Figura 4.3: Esquema da estrutura da rede da UFMA.
4.5 Firewall
45
O rewall escolhido e baseado no programa iptables, uma aplica c ao a n vel de usu ario utilizada para congurar as regras do ltro de pacotes do kernel Linux, netlter, das vers oes 2.4.x e 2.6x (AYUSO, 2009). O netlter processa sequ encias de pares de regras e a co es. As regras inseridas atrav es do iptables denem o pacote a ser controlado, as a co es denem o que fazer com estes pacotes. Quando o netlter encontra um pacote que casa com uma regra ele toma a a ca o correspondente ` aquela regra. O iptables trabalha com tabelas especializadas em cada tipo de tratamento de pacotes. As principais s ao: lter: tabela usada para ltragem de pacotes; nat: usada para realizar mudan cas nos cabe calhos dos pacotes; mangle: usada para realizar altera co es espec cas nos pacotes. Cada tabela e composta por cadeias (chains ), associada a cada tipo de tr afego. As cadeias mais comuns s ao: PREROUTING: tr afego ingressante na m aquina, inclusive gerado localmente com destino local; INPUT: tr afego cujo destino e a pr opria m aquina; FORWARD: tr afego que atrevassa as interfaces de rede da m aquina; OUTPUT: tr afego gerado localmente com destino remoto ou local; POSTROUTING: tr afego que sai da m aquina, gerado local ou remotamente. A cadeia FORWARD e a utilizada para tratamento de rewalls para redes, visto que ela lida com as conex oes que atravessam o kernel, por exemplo, de uma rede externa para uma ou mais redes internas. Nesse caso a m aquina Linux funciona como um roteador entre as duas ou mais redes. O kernel deve ter o seguinte par ametro ativado para poder funcionar como roteador: net.ipv4.ip_forward=1
4.5 Firewall
46
Este par ametro pode ser ativado manualmente atrav es da execu ca o do comando sysctl como usu ario root: # sysctl -w net.ipv4.ip_forward=1 Atrav es do comando echo , usado para modicar diretamente o estado do par ametro no diret orio /proc/sys/net/ipv4/ip forward: # echo "1" > /proc/sys/net/ipv4/ip_forward Ou atrav es da inclus ao da seguinte linha no arquivo /etc/sysctl.conf : net.ipv4.ip_forward=1 A linha em quest ao j a vem inserida no arquivo da maioria das distribui c oes, sendo necess aria apenas a retirada do caractere # na primeira posi c ao da linha, que indica que a mesma est a comentada. Ap os a ativa c ao do roteamento no kernel linux, e poss vel inserir regras ao ltro de pacotes, sendo que as seguintes regras podem ser inseridas: -p PROTOCOLO: especica um protocolo (por exemplo tcp ou udp); -s ENDERECO : especica um endere co de origem; -d ENDERECO : especica um endere co de destino; -i INTERFACE: especica a interface de rede na qual o pacote ingressou; -o INTERFACE: especica a interface de rede na qual o pacote sair a da m aquina;
As a c oes que podem ser usadas com o iptables determinam o que acontecer a com os pacotes que casam com as regras inseridas. As a c oes mais comumente usadas s ao: ACCEPT: o iptables para de tratar o pacote e entrega-o para a aplica ca o destino ou para o sistema operacional; DROP: o iptables para de tratar o pacote e este e rejeitado pelo rewall, n ao sendo repassado para o seu destino;
4.5 Firewall
47
REJECT: funciona como o DROP, mas uma mensagem de retorno e enviado ` a origem, dizendo que seu pacote fora descartado; LOG: a informa c ao sobre o pacote e repassado ao daemon de relat orios do sistema syslog, sendo repassado para a pr oxima regra na tabela que pode ser usada para bloqueio do pacote; DNAT: usado para tradu ca o de endere co de destino, geralmente alterando o endere co IP de destino do pacote; SNAT: usado para tradu ca o de endere co de origem, alterando o endere co IP de origem do pacote, o novo endere co de origem e denido pelo usu ario; MASQUERADE: usado para tradu ca o de endere co de origem, sendo que neste caso o endere co de origem utilizado e o mesmo da interface de rede do rewall.
O processamento do pacote pelas regras, dentro das cadeias e das tabelas obedece a ordem do uxograma ilustrado na Figura 4.4. O pacote e primeiramente examinado pela regras da cadeia PREROUTING na tabela mangle, se existirem. Em seguida e inspecionado pelas regras na cadeia PREROUTING na tabela nat para ver se se o pacote precisa de DNAT, ent ao ele e roteado. Caso o pacote seja destinado a ` rede interna, ent ao ele e ltrado pelas regras da cadeia FORWARD da tabela lter, se necess ario o pacote sofre SNAT na cadeia POSTROUTING antes de ser enviado a ` rede interna. Quando o servidor ou esta ca o de destino resolve responder, o pacote percorre a mesma sequ encia. As cadeias FORWARD e POSTROUTING podem ser conguradas para implementar qualidade de servi co (QoS) em suas tabelas mangle para priorizar servi cos. Se o pacote e destinado para o pr oprio rewall, ent ao ele passa atrav es da tabela mangle da cadeia INPUT, se congurado, antes de ser ltrado pelas regras na cadeia INPUT da tabela lter anterior. Se conseguir passar por esse testes o pacote e processado pela aplica ca o no rewall. Em algum ponto, o rewall precisa responder a algu em. Esta resposta e roteada e inspecionada pelas regras na cadeia OUTPUT na tabela mangle, caso haja alguma. Em seguida, as regras na cadeia OUTPUT da tabela nat determinam se e requerido DNAT e as regras na cadeia OUTPUT da tabela lter s ao inspecionadas para ajudar a restringir os pacotes n ao autorizados. Finalmente, antes dos pacotes serem
4.5 Firewall
48
Figura 4.4: Fluxograma do processamento de pacotes pelo iptables. enviados de volta a ` rede externa, a cadeia POSTROUTING pode realizar SNAT e marca c oes de QoS. Para implementa c ao das regras de rewall e necess aria a utiliza ca o do comando iptables obedecendo o seguinte modelo: ~O # iptables -t TABLE -A CADEIA REGRAS -j A CA Por exemplo, para permitir a passagem de pacotes da rede 200.137.131.0 para a rede interna 192.168.1.0, sendo eth0 a interface da rede externa e eth1 a interface interna, temos que realizar o seguinte comando: # iptables -t filter -A FORWARD -s 200.137.131.0/24 -d 192.168.1.0/24 \
4.5 Firewall -i eth0 -o eth1 -j ACCEPT
49
Uma das formas de constru ca o de um rewall Linux e atrav es de um shell script, um arquivo de texto que e interpretado por um shell, geralmente o bash (GNU, 2006), para execu ca o sequencial de instru c oes reservadas do shell e comandos externos, como o iptables, por exemplo. O shell tamb em permite deni ca o de vari aveis, que podem servir para armazenar endere cos IP de redes, de equipamentos, nomes de interfaces de redes e outras informa c oes necess arias a ` execu ca o do script. O script do rewall deve ser lido durante a carga do sistema operacional, preferencialmente logo ap os a congura ca o das interfaces de rede, o que pode ser feito atrav es da diretiva up no arquivo /etc/network/interfaces, como pode ser visto na Figura 4.5.
Figura 4.5: Conte udo do arquivo interfaces. No exemplo, as interfaces lo, eth0 e eth1 do servidor s ao conguradas de acordo com os par ametros indicados acima e ap os a interface ser inicializada, o comando bash /etc/networks/rewall.sh executa o shell script rewall.sh, carregando as regras do iptables. Atualmente a rede da UFMA conta com um rewall que e respons avel por manter a seguran ca das esta co es de suas redes internas, como pode ser vericado na Figura 4.3. Os servidores n ao encontram-se protegidos pelo rewall mas contam com sistemas individuais de prote c ao como rewall, antiv rus e antispywares. Isto se deve ao fato de que durante as diversas reestrutura co es do ambiente de rede e servidores da UFMA, estes u ltimos n ao poderiam deixar de disponibilizar seus servi cos, o que os deixou fora da cobertura do
4.6 DMZ
50
rewall, mas n ao sem a prote ca o de programas e outros sistemas de suporte a ` seguran ca local. O rewall existente protege a rede interna da UFMA e seus campi de ataques externos e evita que esta co es contaminadas da institui ca o provoquem ataques a servidores externos, diminuindo o n umero de notica co es do CAIS 3 , recebidas pela equipe de redes.
4.6
DMZ
Ap os algumas considera co es acerca da prote ca o dos servidores institucionais decidiu-se pelo uso de DMZ(DeMilitarized Zone ), um segmento de rede que ca entre a rede local e a rede externa, geralmente a Internet, mas sem conex ao direta com nenhuma delas, conforme a Figura 4.6. Essa separa c ao e monitorada e controlada por rewalls que repassam pacotes entre as redes de acordo com regras denidas pelos respons aveis pela seguran ca do ambiente computacional.
Figura 4.6: DMZ protegida por rewall. Esta abordagem permite que sejam realizados os monitoramentos adequados das conex oes provenientes das redes internas e da Internet, possibilitando o emprego mais preciso das regras para garantir o acesso seguro aos servi cos do NTI. Uma outra implementa ca o consiste na separa ca o dos servidores em VLANs de acordo com suas clientelas, em servidores p ublicos e servidores internos. Neste caso, cada grupo de servidores ser a protegido por um rewall diferente, interligados entre si para que seja poss vel aos usu arios das redes internas acesso a recursos de servi cos da Internet, conforme ilustrado na Figura 4.7.
3
Centro de Atendimento a Incidentes de Seguran ca da RNP - Rede Nacional de Pesquisa
(http://www.rnp.br/cais/)
4.7 IDS/IPS
51
Figura 4.7: DMZs de servidores p ublicos e internos. Com este esquema de interliga ca o, os rewalls s ao respons aveis por separar o tr afego para cada grupo de servidores, de acordo com as regras denidas pelo o iptables. A principal id eia e n ao permitir que os acessos sejam feitos diretamente aos servidores, impedindo que acessos indevidos das redes internas sejam feitos aos servidores internos, principalmente os servidores de bases de dados, que devem ser acessados apenas pelos servidores das aplica co es e em raras ocasi oes, pelos administradores de suas bases de dados, e mesmo assim, apenas a partir da rede interna do NTI.
4.7
IDS/IPS
Os sistemas de detec ca o de intrus ao (IDS - Intrusion Detection Systems ) e de prote ca o a intrus ao (IPS - Intrusion Protection Systems ) podem ser vistos como complementos do rewall uma vez que o IDS emite avisos mediante poss veis casos de ataques, deixando qualquer altera ca o das pol ticas a cargo dos administradores dos servidores, o IPS pode, de fato, realizar as altera co es automaticamente, tomando uma contra-medida relacionada ao ataque detectado. Os IDS podem ser classicados quanto ao tipo de an alise de informa c oes que realizam. Segundo (ALDER et al., 2004), eles podem ser: HIDS: os Host Based Intrusion Detection Systems realizam an alises somente no equipamento onde est a instalado, geralmente um servidor;
4.8 VLAN - Rede Virtual
52
NIDS: os Network Based Intrusion Detection Systems analisam o tr afego de um segmento de rede, independetemente do n umero de servidores naquele segmento. Estes ainda podem ser classicados em NIDS baseados em assinaturas ou NIDS baseados em tr afego; KIDS: os Kernel Based Intrusion Detection Systems monitoram o comportamento de aplica co es para, basicamente alertatrem e previnir buerOverow; LIDS: os Log Based Intrusion Detection Systems realizam an alise em logs de sistemas, em vez de pacotes de rede. O Linux tem um sistema de relat orios chamado syslog (PARKANSKY, ), que e respons avel por gerar e gerenciar os diversos logs do sistemas e de outras aplica co es como servidores de redes. Os pacotes de rede direcionados ao servidor podem ser registrados pelo syslog se houver uma regra do iptables denindo a a c ao LOG para os pacotes entrantes. Estes registros podem ser feitos nos arquivos /var/log/syslog ou /var/log/messages que devem monitorados pelo IDS para envio de mensagens aos administradores dos servidores e sistemas, conforme ilustra a Figura 4.8.
Figura 4.8: HIDS ou LIDS monitorando a c oes e logs do de um servidor.
4.8
VLAN - Rede Virtual
A principal fun ca o de um ambiente cliente/servidor e proporcionar o acesso de esta co es remotas a recursos localizados em servidores. Para tal deve ser disponibilizado um ambiente
4.8 VLAN - Rede Virtual de rede para conectar os envolvidos na comunica c ao.
53
Devido ao tipo de aplica co es utilizadas pelos usu arios, alguns segmentos de rede s ao mais utilizados que outros, e essa utiliza c ao excessiva pode acabar prejudicando outros usu arios que n ao est ao envolvidos na comunica c ao, mas compartilham o mesmo meio f sico, sendo desejada ou mesmo necess aria a separa c ao f sica das esta co es em redes menores. Em ambientes de rede com um n umero reduzido de esta co es e servidores n ao h a necessidade dessa separa ca o entre os v arios n os que comp oem a estrutura de rede. J a em casos onde existe um grande n umero de esta c oes e servidores, talvez seja desej avel separar sicamente as conex oes entre diversos coponentes da institui c ao como salas, pavilh oes e pr edios, de acordo com (TANENBAUM, 2003). Algumas raz oes para essa separa ca o podem ser: a) reduzir o dom nio de broadcast, diminuindo a lentid ao da rede e a possibilidade de indisponibilidade de servi cos pelo excesso de tr afego, b) gerenciamento melhorado do parque de esta co es, permitindo aos administradores da rede identicar focos de a co es que comprometam a estabilidade e a seguran ca dos sistemas, c) congura ca o ecaz dos endere cos de rede das esta co es, atrav es de repasse de pacotes do protocolo DHCP (Dinamic Host Conguration Protocol - Protocolo de Congura ca o Din amica de Equipamentos). As raz oes citadas acima foram consideradas importantes pela equipe de administradores de rede do NTI para utiliza ca o de VLANs nas estruturas das v arias redes da UFMA. Al em disso, em muitas congura co es de ambientes de produ ca o, como o encontrado no NTI da UFMA, alguns servidores s ao acessados diretamente por outros servidores e n ao por esta c oes, numa estrutura de camadas, para distribui ca o de processamento ou separa c ao de responsabilidades: enquanto uns servidores executam a aplica ca o do cliente, outros s ao respons aveis por bases de dados e outro tipo de processamento, como por exemplo decodica ca o de arquivos multim dia. A Figura 4.9 representa o modelo cliente-servidor em camadas onde um cliente acessa um servidor de aplica co es que por sua vez recebe os dados de consultas de um servidor de banco de dados. Muitos hipervisores s ao capazes de criar segmentos de redes virtuais, que podem ser usados pelos adaptadores de rede das m aquinas virtuais para comunica ca o entre as VMs, entre as VMs e o hipervisor ou entre as VMs e o mundo externo.
54
Figura 4.9: Ambiente de aplica c oes em camadas. O XenServer e capaz de trabalhar com VLANs4 internamente, entre as VMs, e externamente, para acesso do dom0 a ` rede f sica. O que possibilita isolamento l ogico de redes, onde houver suporte por parte de outros equipamentos de rede como switches e roteadores. At e pouco tempo atr as a rede da UFMA comportava-se como uma rede at, sem separa c ao f sica ou l ogica. A congura c ao das esta co es e dos servidores era feita manualmente, o que demandava um esfor co muito grande por parte dos administradores de rede para gerenciar corretamente o acesso ` a congura c ao dos equipamentos. N ao raramente os usu arios alteravam as congura c oes das esta co es, inclusive, com endere cos de rede reservados para os servidores da institui c ao, ocasionando conitos de endere cos, o que geralmente causava indisponibilidade de servi cos importantes, como DNS, p aginas web e email. Atualmente a rede da UFMA encontra-se segmentada em diversas redes locais virtuais (VLANs) (Virtual Local Area Network ), que e implementada em switches com essa caracter stica que marcam pacotes com identica c oes para que sejam recebidos e repassados
4
VLAN e um padr ao especicado na norma IEEE 802.1Q (IEEE, 1998), que determina como isolar o
tr afego de informa c oes entre componentes de uma rede conectados a swicthes e outros equipamentos
55
apenas por switches que fazem parte da VLAN em quest ao. Outros pacotes com marca ca o de outras VLANs n ao s ao entregues aos switches que n ao fazem parte da VLAN, consequentemente s ao ignorados pelas esta c oes ou servidores que n ao est ao conectados a `s portas marcada.
Figura 4.10: Esta co es agrupadas em VLANs conguradas em switches diferentes. Na Figura 4.10 algumas portas dos swithces 1 e 2 est ao marcadas como pertencentes a ` VLAN CINZA, enquanto outras est ao marcadas como sendo parte da VLAN BRANCA. As portas que interligam os dois switches fazem parte das duas VLANs. Uma esta ca o ligada a uma porta da VLAN CINZA do switche 1 s o consegue se comunicar com outra esta ca o da sua pr opria VLAN, mesmo que a outra esta ca o esteja ligada numa porta do switche 2. Os swicthes entregam os pacotes de uma VLAN apenas para as portas que fazem parte daquela VLAN. Uma forma de haver comunica c ao entre as duas VLANs e conectando um roteador ou um rewall com duas interfaces de rede em duas portas de VLANs diferentes do mesmo switche. A congura ca o de endere co de rede das esta co es e feita automaticamente por meio de um servidor DHCP (Dynamic Host Conguration Protocol ) dedicado (IETF, 1997a) e (IETF, 1997b), que atualiza entradas de um servidor DNS (Domain Name System ) (IETF, 1987) interno para reconhecimento das esta c oes por nome e dom nios das VLANs. A congura ca o de rede dos servidores e feita manualmente. O servidores de DHCP e DNS internos est ao situados na rede interna do NTI, para garantir sua seguran ca e administra ca o facilitada pelos respons aveis do setor que alteram a congura c ao dos servi cos para cada nova VLAN. A congura c ao autom atica das esta c oes e poss vel, pois a estrutura de rede da UFMA
56
conta com equipamentos capazes de realizar retransmiss ao de DHCP atrav es de agentes (TANENBAUM, 2003) que capturam a requisi c ao de DHCP, na forma de um pacote dhcp discover, repassando-a para outros agentes, at e que esta chegue ao servidor. Este entrega a congura c ao adequada ao agente dhcp relay de sua rede, que o entrega ao agente da VLAN de onde a requisi ca o e proveniente, entregando a congura ca o a ` esta c ao que gerou a requisi ca o de congura ca o, conforme a Figura 4.11.
Figura 4.11: Congura ca o de esta co es com DHCP nas redes internas da UFMA. Na nova estrutura de ambiente virtualizado, a implementa ca o de VLANs ainda ser a respons avel por isolar o tr afego das redes internas aos servidores e ainda entre as diversas redes constituintes da solu c ao de virtualiza ca o, que devem fazer parte de: rede de administra c ao, rede de storage e rede de acesso, conforme a Figura 4.12, separando os tr afegos de rede direcionados ao XenServer. Essa separa ca o e opcional para o funcionamento do XenServer, mas importante para manter a seguran ca da administra c ao dos servidores de m aquinas virtuais, ao mesmo tempo em que a comunica ca o das m aquinas virtuais com os clientes de seus servi cos e mantido por outra VLAN. Na Figura 4.12 tamb em e mostrada a comunica c ao do servidor das m aquinas virtuais com o equipamento de storage, respons avel por armazenar os discos virtuais das VMs e que tamb em pode ser utilizada para implementar a alta disponibilidade.
4.9 Conclus oes
57
Figura 4.12: Separa c ao do tr afego de comunica c ao com o XenServer.
4.9
Conclus oes
Neste cap tulo foram vistos alguns aspectos de seguran ca que ser ao implementados no ambiente de virtualiza ca o de servidores do NTI da UFMA, visando garantir a maior disponibilidade poss vel dos servi cos a seus usu arios, servidores, alunos e comunidade em geral. Como se pode avaliar, o uso da virtualiza ca o traz muitas vantagens, mas tamb em algumas desvantagens que devem ser levadas em considera ca o quando se resolve adotar essa solu ca o. Uma dessas e a economia em aquisi ca o de muitos servidores e o melhor aproveitamento de servidores adequados a ` virtualiza ca o, bem como a economia com energia e a diminui ca o do espa co ocupado por diversos servidores. Por outro lado, uma das desvantagens do uso da virtualiza ca o e a centraliza c ao de v arias m aquinas virtuais em um u nico servidor, o que signica um risco muito alto no caso de queda desse servidor, fazendo dele um ponto de falha que deve ser protegido e at e mesmo replicado para promover a alta disponibilidade. Pelos altos investimentos feitos e pela possibilidade de indisponibilidade de servi cos e informa co es a seguran ca dos servidores de virtualiza ca o torna-se cr tica, visto que os mesmos concentram a execu c ao das aplica c oes do ambiente em suas m aquinas virtuais. Por esse motivo as informa co es sobre as vulnerabilidades de cada sistema operacional
4.9 Conclus oes
58
convidado, das aplica co es que rodam nesses sistemas operacionais e do hipervisor devem ser continuamente vericadas e sempre devem ser aplicadas as u ltimas atualiza c oes e recomenda co es dos produtores dos softwares e equipamentos constituintes da solu c ao. Neste cap tulo foram descritos aspectos e t ecnicas de seguran ca que ser ao considerados e implementados no projeto de virtualiza ca o do NTI da UFMA. O isolamento total de equipamento e m aquinas virtuais pode ser implementado atrav es de equipamentos de rede ou mesmo dentro do servidor de virtualiza ca o, o que pode signicar uma economia na aquisi c ao de ativos de rede como switches. A autentica ca o para acesso aos servidores de virtualiza c ao tem que ser realizada, para dicultar o acesso indevido ` as m aquinas virtuais. Sistemas como rewall e IDS/IPS tamb em devem ser considerados pois s ao mecanismos que auxiliam a seguran ca de servidores e outros sistemas atrav es da deni c ao de regras e vistoria constante de uxos de rede e logs de aplicativos servidores. As VLANs servem para prover a separa c ao de acessos a recursos de rede importantes como sistemas internos de gerencia, sistemas gerenciadores de bancos de dados, interfaces de administra c ao de equipamentos como switches e storages. Alguns desses itens j a s ao utilizados em alguma parte na estrutura atual da rede da UFMA e ter ao suas capacidades ampliadas, visando aumentar a seguran ca individual e coletiva dos servidores de virtualiza c ao, de suas m aquinas virtuais e dos sistemas que nelas s ao executadas.
59
5 Conclus ao e Trabalhos Futuros

Existem v arias solu c oes para virtualiza ca o de servi cos dispon veis no mercado. As solu co es baseadas em Software Livre e de C odigo Aberto tem demonstrado n ao dever nada a seus concorrentes comerciais, mas a sua utiliza c ao deve ser bem estudada, sendo que um item determinante para sua ado ca o e a realiza c ao de testes para compara ca o entre a m aquina real e a virtual para verica c ao de viabilidade da solu c ao a ser adotada. Cada solu ca o tem sua pecualiaridade e deve ser bem avaliada no momento do projeto para que n ao haja maiores diculdades na implementa ca o. Aspectos como boa documenta c ao, suporte e agilidade de publica ca o de corre co es por parte do fabricante, ferramentas de administra ca o e mecanismos de seguran ca devem ser postos na balan ca para que n ao surjam surpresas desagrad aveis no futuro. O XenServer e um bom exemplo da qualidade de um produto de Software Livre e C odigo Aberto que tem aumentado a sua utiliza ca o em diversos ambientes e a sua integra ca o com o kernel o GNU/Linux demonstra que os dois projetos s ao maduros e tem muito a oferecer a institui c oes que necessitam de produtos de qualidade e com um ciclo de desenvolvimento agil que permitam manter os seus servi cos com seguran ca e relativa facilidade. A escolha dos equipamentos, como servidores e dispositivos de conectividade e armazenamento deve levar em considera ca o a conformidade a padr oes estabelecidos, ou pelo menos a homologa c ao por parte do produtor do sistema de virtualiza ca o, para que seja poss vel a utiliza ca o de todo o potencial do hardware em benef cio dos sistemas instalados nas m aquinas virtuais. O preparo da equipe que ir a administrar e manter os servidores e toda a estrutura funcionando e imprescind vel para a avalia c ao e dimensionamento dos componentes do neces projeto. E ario dar aos administradores as ferramentas necess arias para a formula ca o do projeto bem como para administra c ao, avalia ca o e aprimoramento das solu co es adotadas, haja vista a integra c ao de tantas tecnologias e produtos de fornecedores diferentes.
5 Conclus ao e Trabalhos Futuros
60
Solu co es exaustivamente testadas e utilizadas nomundo real como rewall e IDS/IPS devem ser utilzadas para aumentar a seguran ca tanto dos servidores de solu c ao para virtualiza c ao quanto para as m aquinas virtuais hospedadas. Estas solu co es podem ser implementadas em servidores reais ou virtuais, tendo como crit erios a disponibilidade de equipamentos e tamb em a arquitetura da solu c ao a ser empregada. Etapas futuras para o projeto de virtualiza c ao do NTI podem incluir a amplia ca o do sistema para previnir, tratar e recuperar incidentes de seguran ca, mediante o emprego de outros sistemas como: IDS/IPS mais inteligentes, emprego de grupos de storages, inclusive com a possibilidade de cria ca o de arranjos de redund ancia entre si, aquisi c ao de sistemas de backup em ta ou outra m dia que permita o seu transporte para locais afastados das salas de servidores, cria ca o de grupos para tratamento de incidentes de seguran ca que possam investigar, tratar e agir com anteced encia a futuros incidentes de seguran ca como ataques de crackers, v rus, cavalos de tr oia, entre outras medidas. Tamb em deve ser considerada uma mobiliza c ao junto a ` dire ca o da Universidade para que a mesma, sob a orienta ca o do NTI, possa implementar uma pol tica de seguran ca da informa ca o, para ajudar a previnir e agir corretivamente com rela c ao ` as tentativas de acessos n ao autorizados ` as informa c oes importantes da institui ca o.
Refer encias Bibliogr acas

ALDER, R. et al. Snort 2.1 Intrusion Detection Second Edition. [S.l.]: Syngress Publishing, Inc, 2004. ISBN 1-931836-04-3. AMD. AMD Virtualization (AMD-V) Technology. [S.l.], 2009. [Online; acessado 02 de Dezembro de 2009]. Dispon vel em: <http://www.amd.com/us/products/technologies/virtualization/Pages/amd-v.aspx>. AYUSO, P. N. About the netlter/iptables project. [S.l.], 2009. Dispon vel em: <http://www.netlter.org/>. BELLARD, F. QEMU. [S.l.], 2009. [Online; acessado 03 de Dezembro de 2009]. Dispon vel em: <http://www.qemu.org/>. BUTLER, T. R. bochs: The Open Source IA-32 Emulation Project (Home Page). [S.l.], 2009. [Online; acessado 03 de Dezembro de 2009]. Dispon vel em: <http://bochs.sourceforge.net/>. CERT.BR. Estat sticas do CERT.br Incidentes. [S.l.], 2009. [Online; acessado 03 de Dezembro de 2009]. Dispon vel em: <http://www.cert.br/stats/incidentes/>. CERT.BR. Honeypots e Honeynets: Deni c oes e Aplica c oes. [S.l.], 2009. [Online; acessado 02 de Dezembro de 2009]. Dispon vel em: <http://www.cert.br/docs/whitepapers/honeypots-honeynets/>. CHEN, W. et al. A novel hardware assisted full virtualization technique. Young Computer Scientists, International Conference for, IEEE Computer Society, Los Alamitos, CA, USA, v. 0, p. 12921297, 2008. CITRIX. Welcome to xen.org, home of the Xen hypervisor, the powerful open source industry standard for virtualization. [S.l.], 2009. [Online; acessado 02 de Dezembro de 2009]. Dispon vel em: <http://www.xen.org>. GNU. BASH - GNU Project - Free Software Foundation (FSF). 2006. Dispon vel em: <http://www.gnu.org/software/bash/>.
REFERENCIAS BIBLIOGRAFICAS
62
GOLDEN, B.; SCHEFFY, C. Virtualization for Dummies - A Reference for the Rest of Us! [S.l.]: Wiley Publishing, Inc, 2008. ISBN 978-0-470-29264-8. IEEE. IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks. [S.l.], dez. 1998. Dispon vel em: <http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf>. IETF. RFC1035 - Domain names - implementation and specication. [S.l.], 1987. Dispon vel em: <http://www.faqs.org/rfcs/rfc1035.html>. IETF. IETF RFC 2131 - Dynamic Host Conguration Protocol. [S.l.], 1997. Dispon vel em: <http://www.rfc-archive.org/getrfc.php?rfc=2131>. IETF. IETF RFC 2132 - DHCP Options and BOOTP Vendor Extensions. [S.l.], 1997. Dispon vel em: <http://www.rfc-archive.org/getrfc.php?rfc=2132>. INTEL. Intel R 64 and IA-32 Architectures Software Developers Manual Volume 1: Basic Architecture. sep 2009. Dispon vel em: <http://www.intel.com/Assets/PDF/manual/253665.pdf>. INTEL. Virtualization technologies from Intel. [S.l.], 2009. [Online; acessado 03 de Dezembro de 2009]. Dispon vel em: <http://www.intel.com/technology/virtualization/>. kernel.org kernel.org kernel.org kernel.org. Linux-PAM modules etc. page. [S.l.], 2009. Dispon vel em: <http://www.kernel.org/pub/linux/libs/pam/modules.html>. KLEINER, D. HomePage: Linux HA. [S.l.], 2009. Dispon vel em: <http://www.linuxha.org/>. KUROSE, J. F.; ROSS, K. W. Redes de computadores e a Internet - Uma abordageem top-down. 3a.. ed. [S.l.]: Wesley, Pearson Addison, 2007. ISBN 9-885-8863918-8. LAVINGTON, S. A history of Manchester computers. segunda. [S.l.]: British Computer Society, 1998. ISBN 0-902505-01-8. LIBVIRT. libvirt: The virtualization API. [S.l.], 2009. Dispon vel em: <http://libvirt.org/>. LIKEWISE. Likewise Open Now Integrated in Citrix XenServer. [S.l.], may 2009. Dispon vel em: <http://www.likewise.com/news events/press releases/pr 5122009.php>.
REFERENCIAS BIBLIOGRAFICAS
63
LINBIT. DRBD:What is DRBD. [S.l.], 2009. Dispon vel em: <http://www.drbd.org/>. MATHEWS, J. N. et al. Executando o Xen - Um Guai Pr atico para a Arte da Virtualiza c ao. [S.l.: s.n.]. ISBN 978-85-7608-317-7. MICROSOFT. Hyper-V Architecture. [S.l.], 2009. Dispon vel em: <http://msdn.microsoft.com/en-us/library/cc768520 MICROSOFT. Windows Server 2008 R2: Virtualization with Hyper-V: Home. [S.l.], 2009. [Online; acessado 02 de Dezembro de 2009]. Dispon vel em: <http://www.microsoft.com/windowsserver2008/en/us/hyperv-main.aspx>. PARKANSKY, K. How To Set Up A Debian Linux Syslog Server. Dispon vel em: <http://www.aboutdebian.com/syslog.htm>. PRATT, I. et al. Xen 3.0 and the art of virtualization. Proceedings of the Linux Symposium - Volume Two, 2005. QUYNH, N. A. Hijacking (Xen) Virtual Machine for Fun and Prots. [S.l.], 2007. Http://www.bellua.com/bcs2005/asia07.materials/nguyen anh quynh.pdf. RUTKOWSKA, J. The Invisible Things Lab s blog: Our Xen 0wning Trilogy Highlights. [S.l.], ago. 2008. Http://theinvisiblethings.blogspot.com/2008/08/our-xen-0wningtrilogy-highlights.html. RYSMITH. Linux OS | SUSE Linux Enterprise. [S.l.], 2009. Dispon vel em: <http://www.novell.com/linux/>. SALMORIA, N. MAME - Multiple Arcade Machine Emulator. [S.l.], 2009. [Online; acessado 03 de Dezembro de 2009]. Dispon vel em: <http://mamedev.org/>. SAMAR, V.; SCHEMERS, R. UNIFIED LOGIN WITH PLUGGABLE AUTHENTICATION MODULES (PAM). [S.l.], out. 1995. (Request For Comments 86.0). Dispon vel em: <http://www.kernel.org/pub/linux/libs/pam/pre/doc/rfc86.0.txt.gz>. SCHERF, T. Um dentro do outro. Linux Magazine, n. 57, aug 2009. ISSN 1806-9428. Dispon vel em: <http://www.linuxmagazine.com.br>. SECUNIA. Secunia Advisories - Vulnerability Information - Secunia.com. [S.l.], 2009. Dispon vel em: <http://secunia.com/advisories/>.
REFERENCIAS BIBLIOGRAFICAS SECURITYFOCUS. SecurityFocus. [S.l.], 2009.
64
Http://www.securityfocus.com/vulnerabilities. SINGH, A. An Introduction to Virtualization. [S.l.], 2004. [Online; acessado 03 de Dezembro de 2009]. SYSTEMS, C. Citrix Systems - Citrix Downloads. dec 2009. Dispon vel em: <http://www.citrix.com/English/ss/downloads/>. TANENBAUM, A. S. Redes de Computadores. [S.l.]: ELSEVIER, 2003. ISBN 85-352-1185-3. TAVARES, N. Sistema de alta disponibilidade - Wikip edia, a enciclop edia livre. [S.l.], 2009. Http://pt.wikipedia.org/wiki/Sistema de alta disponibilidade. UML. Main Page - KVM. [S.l.], 2009. [Online; acessado 02 de Dezembro de 2009]. Dispon vel em: <http://user-mode-linux.sourceforge.net/old/index.html>. WIKIPEDIA. Full virtualization - Wikipedia, The Free Encyclopedia. 2009. [Online; acessado em 05-12-2009].

Carlos Wagner Sousa Da Costa

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Carlos Wagner Sousa Da Costa

Transféré par

Droits d'auteur :

Formats disponibles

o Universidade Federal do Maranha ncias Exatas e Tecnologia Centro de Cie ncia da Computa o Curso de Cie ca

Carlos Wagner Sousa da Costa

Mecanismos de Seguran ca para o Ambiente de Virtualiza c ao do NTI / UFMA

Carlos Wagner Sousa da Costa

Mecanismos de Seguran ca para o Ambiente de Virtualiza c ao do NTI / UFMA

Orientador: Francisco Jos e da Silva e Silva

1.Inform atica 2. Virtualiza ca o.. I.T tulo. CDU 536.21

Carlos Wagner Sousa da Costa

Mecanismos de Seguran ca para o Ambiente de Virtualiza c ao do NTI / UFMA

Aprovado em 09 de julho de 2010

Francisco Jos e da Silva e Silva

M ario Antonio Meireles Teixeira

Geraldo Braz J unior

Lista de Figuras 1 Introdu c ao 1.1 1.2 1.3 1.4

2 Conceitos de Virtualiza c ao 2.1 2.2

3 XenServer 3.1 3.2 3.3 3.4 3.5

5 Conclus ao e Trabalhos Futuros Refer encias Bibliogr acas

4.3 4.4 4.5 4.6 4.7

Esquema da estrutura da rede da UFMA.

HIDS ou LIDS monitorando a co es e logs do de um servidor. . . . . . . . . 52 Ambiente de aplica c oes em camadas. . . . . . . . . . . . . . . . . . . . . . 54

1.1 Parque de servidores do NTI

Parque de servidores do NTI

1.1 Parque de servidores do NTI

Breve Hist orico

2.2 Tipos de Virtualiza ca o

2.2 Tipos de Virtualiza ca o

2.2 Tipos de Virtualiza ca o

2.2 Tipos de Virtualiza ca o de hardware do sistema operacional antri ao.

Figura 2.3: Paravirtualiza c ao

2.3 Produtos de Virtualiza ca o

2.3 Produtos de Virtualiza ca o

2.3 Produtos de Virtualiza ca o

2.3 Produtos de Virtualiza ca o /dev/kvm do sistema hospedeiro.

Linux em modo usu ario

Um honeypot e um recurso computacional de seguran ca dedicado a ser sondado, atacado ou compro-

metido (CERT.BR, 2009b).

2.4 Conclus oes

2.4 Conclus oes

que pode ser encontrado para download gratuito em (SYSTEMS, 2009).

3.1 Estrutura do XenServer

3.2 Caracter sticas Principais do XenServer

e demais tarefas adminis-

Caracter sticas Principais do XenServer

permite a verica c ao de credenciais

3.3 Ferramentas de Gerenciamento

3.3 Ferramentas de Gerenciamento

3.3 Ferramentas de Gerenciamento

3.4 Alta Disponibilidade

3.4 Alta Disponibilidade

3.4 Alta Disponibilidade

3.4 Alta Disponibilidade

3.5 Conclus oes

3.5 Conclus oes

4.1 Seguran ca de Ambientes Virtualizados

Seguran ca de Ambientes Virtualizados

4.2 Isolamento Total

4.3 Cuidados com o Hipervisor

Cuidados com o Hipervisor

Figura 4.3: Esquema da estrutura da rede da UFMA.

4.5 Firewall -i eth0 -o eth1 -j ACCEPT

Centro de Atendimento a Incidentes de Seguran ca da RNP - Rede Nacional de Pesquisa

4.8 VLAN - Rede Virtual

Figura 4.8: HIDS ou LIDS monitorando a c oes e logs do de um servidor.

VLAN - Rede Virtual