UNIVERSIDADE FEDERAL FLUMINENSE FÁBIO DE PAULA … · LISTA DE ABREVIATURAS E SIGLAS DMZ – Demilitarized Zone (Zona Desmilitarizada). DNS – Domain Name Service (Serviço de Nomes

UNIVERSIDADE FEDERAL FLUMINENSEFÁBIO DE PAULA JUNIOR

DMZ VIRTUAL

Niterói2008

FÁBIO DE PAULA JUNIOR

DMZ VIRTUAL

Trabalho de Conclusão de Curso subme-

tido ao Curso de Tecnologia em Siste-

mas de Computação da Universidade

Federal Fluminense como requisito par-

cial para obtenção do Tecnólogo em Sis-

temas de Computação.

Orientador:Leandro Soares de Sousa

NITERÓI2008

FÁBIO DE PAULA JUNIOR

DMZ VIRTUAL

Trabalho de Conclusão de Curso subme-

tido ao Curso de Tecnologia em Siste-

mas de Computação da Universidade

Federal Fluminense como requisito par-

cial para obtenção do Tecnólogo em Sis-

temas de Computação.

Niterói, ___ de _______________ de 2008.

Banca Examinadora:

_________________________________________

Prof. Leandro Soares de Sousa, Msc. – Tutor Orientador

UFF - Universidade Federal Fluminense

_________________________________________

Prof. Alexandre Domingues Gonçalves, Msc. – Avaliador

UFF - Universidade Federal Fluminense

Dedico este trabalho a todos os meus famili-

ares, em especial meus pais e meu irmão,

meu tio José Luiz, e as minhas tias Marly e

Regina.

AGRADECIMENTOS

Gostaria de agradecer primeiramente a todos

os funcionários do pólo do CEDERJ de Itape-

runa em especial a Jonatas, Penha, Leandro

(Coordenador do Curso) e Rita (Diretora do

pólo), que sempre me atenderam com muita

dedicação.

Ao meu orientador Leandro Soares de Sousa,

pela atenção concedida durante a construção

deste trabalho.

A todos os meus familiares e amigos pelo

apoio e colaboração.

“É fazendo que se aprende a fazer aquilo

que se deve aprender a fazer."

Aristóteles (Criador do pensamento lógico)

RESUMO

Este trabalho tenta demonstrar o uso da virtualização de servidores aplicada na construção de um ambiente comum nas empresas que precisam publicar recursos na Internet, o ambiente DMZ. De forma a alinhar o conhecimento do leitor apresento uma visão teórica e as vantagens e desvantagens da utilização desta tecnologia. Na seqüência um ambiente DMZ foi definido, implementado e validado, através de uma série de experimentos. Finalmente, exponho as conclusões obtidas durante a elabo-ração do trabalho.

Palavras-chaves: virtualização, DMZ, servidores, Internet, segurança.

LISTA DE ILUSTRAÇÕES

Figura 2-1: Diagrama da trihomed DMZ.....................................................................18

Figura 2-2: Diagrama da DMZ Back to Back..............................................................19

Figura 2-3: Diagrama da DMZ proposta neste trabalho.............................................21

Figura 4-4: Redes virtuais VMnet0, VMnet1 e VMnet2...............................................44

Figura 4-5: Tela de configuração das redes virtuais...................................................45

Figura 4-6 Diagrama físico da rede com o SVFW01 em destaque............................48

Figura 4-7 Diagrama físico da rede com o SVFW02 em destaque............................51

Figura 4-8 Diagrama físico da rede com o SVMAIL01 em destaque.........................54

Figura 4-9 Diagrama físico da rede com o SVWEB01 em destaque..........................57

Figura 4-10 Diagrama físico da rede com o SVWEB01 em destaque........................60

Figura 4-11 - Diagrama físico da rede com o SVFW01 em destaque........................63

Figura 4-12 - Diagrama de conexão com a Internet...................................................68

Figura 4-13 Diagrama físico da rede com o SVFW02 em destaque..........................77

Figura 5-14 - Visão geral da montagem física do experimento..................................88

Figura 5-15 Origem Internet (área verde) com destino a DMZ...................................90

Figura 5-16 - Evidência de acesso HTTP...................................................................91

Figura 5-17 - Evidência de acesso FTP......................................................................92

Figura 5-18 - Evidência de acesso SMTP...................................................................93

Figura 5-19 - Evidência de acesso POP3...................................................................94

Figura 5-20 - Evidências de bloqueio (Internet para DMZ).........................................95

Figura 5-21 Origem SVMAIL01 (área verde) com destino a Internet.........................95

Figura 5-22 Evidência de acesso DNS.......................................................................97

Figura 5-23 - Evidência de acesso SMTP...................................................................98

Figura 5-24 Origem LAN (área verde) com destino a Internet...................................99

Figura 5-25 - Evidência LAN acessando HTTP........................................................100

Figura 5-26 - Evidência LAN acessando HTTPS......................................................101

Figura 5-27 - Evidência LAN acessando FTP...........................................................102

Figura 5-28 - Origem estação do administrador (área verde) com destino ao

SVFW01....................................................................................................................103

Figura 5-29 - Evidência estação do administrador acessando SVFW01 via SSH...104

Figura 5-30 - Evidência estação do administrador testando conectividade com

SVFW01 utilizando ferramentas ICMP.....................................................................105

Figura 5-31 - Evidência de bloqueio do protocolo ICMP..........................................106

Figura 5-32 - Origem LAN (área verde) com destino a DMZ e Internet...................108

Figura 5-33 - Evidência LAN acessando HTTP localizado na DMZ.........................109

Figura 5-34 - Evidência LAN acessando FTP localizado na DMZ............................110

Figura 5-35 - Evidência LAN acessando SMTP localizado na DMZ........................111

Figura 5-36 - Evidência LAN acessando POP3 localizado na DMZ.........................112

Figura 5-37 - Evidência LAN consultando DNS localizado na DMZ.........................113

Figura 5-38 - Evidência LAN acessando o MySQL localizado na DMZ...................114

Figura 5-39 - Origem estação do administrador (área verde) com destino a DMZ e

SVFW02....................................................................................................................115

Figura 5-40 - Evidência estação do administrador acessando o SVFW02 via SSH 116

Figura 5-41 - Evidência estação do administrador testando conectividade com

SVFW02 utilizando ferramentas ICMP.....................................................................117

Figura 5-42 - Evidência estação do administrador acessando servidor na DMZ via

SSH...........................................................................................................................118


RDP...........................................................................................................................120


VNC...........................................................................................................................122

Figura 5-45 - Localização da origem dos experimentos (área verde)......................124

Figura 5-46 - Portscan na interface eth1 do SVFW02..............................................125

Figura 5-47 - Localização da origem dos experimentos (área verde) - estação do ad-

ministrador.................................................................................................................126

Figura 5-48 - Portscan na interface eth1 do SVFW02 a partir da estação do adminis-

trador.........................................................................................................................126

Figura 5-49 - Localização da origem dos experimentos DMZ (área verde).............127

Figura 5-50 - Portscan na interface eth0 do SVFW02 a partir da DMZ....................127

Figura 5-51 - Localização da origem dos experimentos DMZ (área verde).............128

Figura 5-52 - Portscan na interface em1 do SVFW01 a partir da DMZ....................128

Figura 5-53 - Localização da origem dos experimentos Internet "simulada" (área

verde).........................................................................................................................129

Figura 5-54 - Internet simulada.................................................................................130

Figura 5-55 - Portscan na interface em0 do SVFW01 a partir da Internet "simulada"

...................................................................................................................................131

LISTA DE TABELAS

Tabela 1: Custo de servidores (Fonte: www.dell.com.br em 30/10/2008)..................27

Tabela 2 Comparação de desempenho (Físico vs. Virtual)........................................35

Tabela 3: Quantidade de memória por servidor.........................................................39

Tabela 4: Fatores de decisão para escolha do software e virtualização....................42

Tabela 5 - Regras do firewall SVFW01.......................................................................65

Tabela 6 - Configuração do PF (/etc/pf.conf)..............................................................69


Tabela 8 - Configuração do iptables (/etc/rc.d/init.d/myfirewall).................................82


Tabela 10 - Regras do firewall SVFW02...................................................................107

LISTA DE ABREVIATURAS E SIGLAS

DMZ – Demilitarized Zone (Zona Desmilitarizada).

DNS – Domain Name Service (Serviço de Nomes de Domínio).

FreeBSD - é um sistema operacional livre do tipo Unix, descendente do BSD desen-

volvido pela Universidade de Berkeley.

FTP – File Transfer Protocol (Protocolo de Transferência de Arquivos).

IPTABLES – ferramenta que faz parte de praticamente todas as atuais distribuições

do Lunix.

FIREWALL - Quer dizer parede corta-fogo, utilizada em edifícios para evitar que um

incêndio se alastre por todo o prédio, em termos de informática significa um serviço

que controla a segurança entre duas ou mais redes.

HCL – Hardware Compatibility List (Lista de Compatibilidade de Hardware).

HTTP - Hypertext Transfer Protocol, é um protocolo de aplicação responsável pelo

tratamento de pedidos/respostas entre cliente e servidor na World Wide Web.

HTTPS - Hypertext Transfer Protocol Secure, é normalmente utilizado quando se de-

seja evitar que a informação transmitida entre o cliente e o servidor seja visualizada

por terceiros, como por exemplo no caso de compras via Internet.

LAN – Local Area Network (Rede Local).

Linux – Termo utilizado para designar sistemas operacionais que utilizam o núcleo

do Linux, criado por Linus Torwalds.

NAS - Network-Attached Storage - Dispositivo dedicado à armazenagem de arquivos

em uma rede, os dados podem ser acessados através de uma rede TCP/IP.

NAT – Network Address Translation (Tradução de Endereços de Rede).

MFLOPS - Millions of Floating Point Operations per Second (Milhões de Operações

de Ponto Flutuante por Segundo).

MIPS - Millions of Instruction per Second (Milhões de Instruções por Segundo).

P2V – Phisical to Virtual (Físico para Virtual).

PF – Packet Filter (Filtro de Pacote) subsistema do firewall dos sistemas operacio-

nais BSD.

PPP - Point-to-Point Protocol, é um protocolo para transmissão de pacotes através

de linhas seriais.

SAN - Storage Area Network (rede de armazenamento de dados) - é uma rede de

alta velocidade, dedicada a fornecer benefícios diversos relacionados ao acesso a

dados, normalmente acessados por via fibras ópticas.

SMTP - Simple Mail Transfer Protocol (Protocolo Simples de Transferência de Men-

sagens).

SSH – Secure Shell Protocol (Protocolo de Shell Seguro).

SUMÁRIO

RESUMO ...................................................................................................................... 7

LISTA DE ILUSTRAÇÕES .......................................................................................... 8

LISTA DE TABELAS .................................................................................................. 11

................................................................................................................................... 11

LISTA DE ABREVIATURAS E SIGLAS ..................................................................... 12

1 INTRODUÇÃO ......................................................................................................... 15

2 DMZ VIRTUAL: CONCEITOS .................................................................................. 17

3 DMZ VIRTUAL: VANTAGENS E DESVANTAGENS ............................................... 22

4 APLICANDO A TECNOLOGIA ................................................................................. 38

5 EXPERIMENTOS ..................................................................................................... 86

CONCLUSÕES ........................................................................................................ 132

CONCLUSÕES ........................................................................................................ 132

REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 134

REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 134

ANEXOS ................................................................................................................... 137

ANEXO A – COMANDOS ÚTEIS ............................................................................. 138

ANEXO B – SISTEMAS OPERACIONAIS UTILIZADOS NO TRABALHO ............. 141

ANEXO C – ARQUIVOS DE CONFIGURAÇÃO ..................................................... 144

1 INTRODUÇÃO

Neste trabalho aborda o que considero uma das grandes tecnologias que

despontaram nos últimos tempos: a virtualização. Apesar de já existir desde a déca-

da de sessenta, apenas recentemente esta tecnologia tomou conta das empresas.

Imagine ter dez servidores com apenas um hardware, esta é apenas uma das possi-

bilidades disponibilizadas por esta tecnologia. A virtualização oferece um melhor

aproveitamento do hardware e outros benefícios que introduzo no decorrer deste tra-

balho.

Com o objetivo de demonstrar as principais virtudes da virtualização decidi

criar um ambiente comum em empresas que possuem máquinas acessadas através

da Internet, a DMZ. Normalmente, uma DMZ é formada por diversos servidores físi-

cos, neste trabalho utilizo um único servidor físico e cinco virtuais, isto não é um limi-

tador visto que o ambiente virtual é escalável.

Trabalho há quatro anos com sistemas de virtualização (criando ambientes

novos, migrando ambientes físicos para virtuais e operações do dia-a-dia) e oito com

os ambientes Microsoft1 (desde programação em Visual Basic2, passando por Win-

dows Server, Active Directory3, SQL Server4 e ISA Server5). Vi neste trabalho uma

oportunidade de mostrar o que venho realizando com virtualização e, também, de

aprofundar meus estudos sobre outros sistemas operacionais tais como, por exem-

plo, o Linux e o FreeBSD.

1 Microsoft, empresa multinacional americana sendo a maior do mundo no ramo de software.2 Visual Basic, linguagem de programação muito popular produzida pela Microsoft.3 Active Directory, serviço de diretório (LDAP) da Microsoft, armazena informações sobre a rede como

contas de usuários.4 SQL Server é o serviço de banco de dados produzido pela Microsoft5 ISA Server (Internet Security and Acceleration) é um serviço de firewall e proxy produzido pela Mi-

crosoft

15

Este estudo introduz conceitos que podem auxiliar administradores de sis-

temas que queiram disponibilizar algum conteúdo na Internet e não dispõem de mui-

tos recursos para aquisição de hardware.

O trabalho foi organizado da seguinte forma, primeiro apresento os concei-

tos de Virtualização e DMZ (o que são), depois introduzo as vantagens e desvanta-

gens destas arquiteturas (o porque utilizar ou não), em seguida a montagem do am-

biente (como fazer) e finalmente avalio, através de experimentos, o ambiente de for-

ma a validar os conceitos introduzidos nas seções anteriores.

16

2 DMZ VIRTUAL: CONCEITOS

Neste capítulo introduzo os conceitos, nesta ordem: DMZ, virtualização e

a união dos dois.

2.1 DMZ

DMZ é a sigla para De-Militarized Zone (Zona Desmilitarizada), que tem

origem militar, e é utilizada para designar uma área que fica entre dois países na

qual é proibido qualquer tipo de atividade militar. Uma DMZ famosa, por exemplo, é

a que está entre a Coréia do Sul e Coréia do Norte.

Em termos de informática, DMZ também é conhecida como “Rede de Perí-

metro” e é utilizada para designar uma pequena rede situada entre uma rede não

confiável (Internet) e outra rede confiável (LAN). Nela ficam localizados os serviços

disponíveis para a Internet, tais como: sites, FTP, servidores de DNS, etc.

Uma peça fundamental na DMZ são os Firewalls6, pois são eles que deter-

minam quem entra ou quem sai da DMZ, no caso os pacotes. Como software de fi-

rewall, utilizo neste trabalho o iptables (Linux) e o PF (FreeBSD).

Existem dois tipos mais comuns de configurações para DMZ: Trihomed e

Back to Back [9].

6 Firewall – Quer dizer parede corta-fogo, utilizada em edifícios para evitar que um incêndio se alastre

por todo o prédio, em termos de informática significa um serviço que controla a segurança entre duas

ou mais redes.

17

O tipo trihomed possui um firewall que está ligado a três redes (por isso o

tri do trihomed), que são: Internet, rede local e DMZ. A Figura 2.1 ilustra esta confi-

guração.

Figura 2-1: Diagrama da trihomed DMZ

O tipo Back to Back foi selecionada para este trabalho (Figura 2.2). Neste

tipo temos dois firewalls e a DMZ fica exatamente entre eles, um dos firewalls fica li-

gado à Internet e o outro à rede local.

18

Figura 2-2: Diagrama da DMZ Back to Back

A configuração Back to Back foi escolhida porque acredito ser a mais se-

gura, pois utilizei firewalls diferentes nas duas pontas da rede. Para ilustrar esta

questão, imagine o seguinte cenário: é descoberta uma falha no iptables e se ambos

forem iptables, o que impediria um hacker que passou pelo primeiro também pas-

sasse pelo segundo. Por este motivo decidi utilizar um Linux com iptables e o outro

com o FreeBSD, executando o PF, assim posso evitar que eventuais falhas, nos fi-

rewalls e nos sistemas operacionais, possam ser utilizadas por hackers para ultra-

passar as duas barreiras e alcançar a rede local.

2.2 VIRTUALIZAÇÃO

A virtualização pode ser definida como uma camada que divide recurso do

hardware de um computador em vários ambientes (sistemas operacionais) de exe-

cução, aplicando um ou mais conceitos ou tecnologias, tais como: como partições de

19

hardware e software, tempo compartilhado, parcial ou simulação completa de uma

máquina, emulação, qualidade de serviço, entre muitas outras [4].

A virtualização já existe desde os anos sessenta, mas estava restrita às

grandes e ricas empresas. O computador Atlas, do departamento de engenharia elé-

trica de Manchester, e o projeto M44/44X da IBM são considerados os precursores

desta tecnologia.

Por volta do final dos anos noventa, passou a estar acessível a todos.

Hoje temos grandes empresas como Microsoft, VMWARE, IBM, SUN e Citrix inves-

tindo em virtualização bem como muitos projetos em open-source7.

Algumas definições sobre a tecnologia de virtualização são importantes e

devem ser introduzidas neste momento, pois serão muito citadas ao longo do texto,

e são elas:

• Máquina Host: é o servidor físico que possui um sistema de virtuali-

zação instalado;

• Máquina Guest: é uma máquina virtual propriamente dita, todos os

seus recursos, tais como: CPU, memória e disco são providos pela

máquina host.

• Disco Virtual: é um arquivo que funciona como um Hard Drive para

a máquina guest. Existem sistemas de virtualização nos quais vári-

as máquinas guests acessam o mesmo disco virtual, mas estão fora

do escopo deste trabalho.

7 Open-Source, quer dizer Código livre, termo criado pela OSI (Open Source Initiative), se refere aos

softwares que respeitam as definições da OSI como por exemplo: distribuição livre, código fonte dis-

ponível, não discriminação entre grupos e pessoas, entre outras.

20

2.3 DMZ VIRTUAL

Existem DMZs de diversos tamanhos, que podem variar de apenas um

servidor físico até DMZs com mais de cem servidores, mas o meu objetivo foi de co-

locar uma DMZ em uma “caixa” e mostrar que podemos ter as mesmas funcionalida-

des de um ambiente físico tradicional.

Figura 2-3: Diagrama da DMZ proposta neste trabalho

Na Figura 2.3 é apresentada, através de um esquema, uma síntese do

objetivo deste trabalho. A máquina host (nome SVVM01), delimitada na figura pela

área em amarelo, abrigará cinco máquinas guests (SVFW01, SVFW02, SVWEB01,

SVMAIL01 e SVDB01). Estas máquinas terão distintos sistemas operacionais e ser-

viços, mas utilizei softwares que normalmente estão disponíveis em uma DMZ

(como sites, FTP e DNS). Este estudo se concentrou na montagem do ambiente vir-

tual e nas suas entradas e saídas, ou seja, nos firewalls.

A DMZ selecionada foi do tipo Back to Back e teve uma interface ligada à

Internet (através do SVFW01) e outra a rede local (através do SVFW02). Antes de

passarmos à implementação desta arquitetura, no próximo capítulo, coloquei os as-

pectos relevantes na decisão de utilizar ou não uma DMZ virtual.

21

3 DMZ VIRTUAL: VANTAGENS E DESVANTAGENS

Neste capitulo coloquei algumas vantagens e desvantagens, principalmen-

te no tocante a virtualização. Nas subseções de segurança enfatizei a DMZ. Algu-

mas vantagens podem ser consideradas desvantagens, tais como custo e seguran-

ça, mas as considerei como vantagens pelos aspectos positivos que se sobressaem

aos negativos.

3.1 VANTAGENS

Algumas das principais vantagens de ter um ambiente virtualizado, tais

vantagens servem como justificativas para que uma empresa utilize esta tecnologia.

Em sua maioria são tópicos técnicos, mas, certamente, o tópico que introduz os cus-

tos desperta maior interesse para os gestores de TI.

3.1.1 Flexibilidade

A virtualização se mostra muito flexível, sob vários aspectos, vejamos al-

guns:

• Redução no tempo na instalação dos sistemas operacionais: a ins-

talação de um servidor, por exemplo, que em alguns casos pode le-

var até uma hora, em ambientes virtualizados pode ser apenas uma

questão de copiar arquivos. Podemos criar máquinas virtuais mode-

22

lo, por exemplo, uma máquina com o Windows 2003 instalado,

quando surgir à necessidade de disponibilizar um servidor virtual

com Windows 2003 teremos apenas fazer uma cópia da máquina

modelo, alterar o nome da nova máquina e executar um processo

chamado sysprep, que altera um identificador único contido em má-

quinas que rodam sistemas Windows (em máquinas com Linux e

FreeBSD isto não se faz necessário). Este processo leva menos de

dez minutos, em média, comparado com até uma hora que pode le-

var uma instalação completa.

• Movimentação de local simplificada: em empresas que possuem

duas salas com servidores pode-se mover um servidor virtual de

uma sala para outra apenas copiando arquivos. Este tipo de opera-

ção faz-se necessária nas empresas, geralmente, por motivos de

contingência. Evidentemente se faz necessário pelo menos um ser-

vidor host em cada uma das salas.

• Montagem rápida de ambientes de desenvolvimento e testes: Em

operações críticas como atualização de softwares, sistemas opera-

cionais ou testes com novos softwares, podemos criar ambientes

virtuais parecidos com o ambiente de produção, sem a necessidade

de investir na aquisição de hardware, que seria utilizado apenas

para testes.

• Precaução nas mudanças: um exemplo prático são as atualizações

de sistemas operacionais Windows, que acontecem em todas as

segundas terças-feiras de cada mês, estas atualizações podem ser

incompatíveis com algum software em execução no servidor. Se o

servidor for virtual pode-se fazer uma cópia do servidor antes da

atualização, caso venha a ocorrer algum problema com o servidor

após a atualização somente precisamos voltar à cópia anterior a

atualização.

23

3.1.2 Consolidação de servidores

Dos casos que conheço, o primeiro passo para a virtualização é a consoli -

dação de servidores. Isto significa selecionar os servidores candidatos, que tem uma

taxa de utilização baixa, e colocá-los em um mesmo hardware, em outras palavras,

eliminar máquinas físicas e assim diminuir o desperdício (o que é uma grande vanta-

gem).

A análise para a seleção dos candidatos não deve observar apenas a taxa

de utilização do processador, mas devemos verificar também utilização de memória,

arquivo de paginação e utilização de disco (espaço, leitura e escrita). Um servidor

pode ter uma taxa de processamento baixa, mas com alta taxa de acesso aos dis-

cos, devemos lembrar que este servidor compartilhará recursos com outros servido-

res, então ele poderia se tornar um gargalo de acesso ao disco no servidor de má-

quina virtual (host).

Um caso interessante de consolidação foi o da Caixa Econômica Federal,

que migrou 2123 servidores físicos para 244 servidores de máquinas virtuais, prati-

camente nove servidores virtuais por servidor host [18].

3.1.3 Redução no consumo de energia

Estamos em uma época na qual o mundo está cada vez mais preocupado

com a ecologia. Diversos relatórios dos cientistas, prevendo um futuro próximo ca-

tastrófico, fazem aumentar a responsabilidade de governos e empresas sobre o futu-

ro do nosso planeta. Neste cenário, o setor de TI das empresas tem um importante

papel, já que dispõem de uma ferramenta valiosa para ajudar a economizar recur-

sos: a virtualização.

24

Vejamos um cenário, no qual um servidor de máquinas virtuais suporta

dez máquinas virtuais, mesmo que o consumo de energia seja maior, pois a utiliza-

ção do servidor é maior, mas é inegável que teremos pelo menos nove servidores a

menos, ainda devemos considerar a diminuição na emissão de calor, que conse-

qüentemente economizará também a energia despendida no ar-condicionado.

Segundo reportagem da revista Computer World “A redução de custos

com a eliminação de servidores físicos pode ser sentida rapidamente: mais de 1,2

mil dólares de economia com eletricidade por servidor em um ano. Para um servidor,

você vai economizar de 300 dólares a 600 dólares diretamente em eletricidade. Esse

valor será o dobro em sistemas de refrigeração”, defende Mark Bramfitt, gerente sê-

nior em gestão de energia da PG&E. "A empresa oferece um ‘incentivo a virtualiza-

ção’ e paga de 150 dólares a 300 dólares por servidor removido como resultado da

consolidação” [3].

3.1.4 Suporte aos softwares legados

Os softwares legados são sistemas antigos, que são vitais para as empre-

sas, mas funcionam com tecnologias ultrapassadas. Vejamos como a virtualização

pode dar uma sobrevida a estes softwares.

Em 2007 vivi uma experiência desafiadora, na qual um servidor passou a

apresentar problemas de hardware. Esse servidor funcionava com o Windows NT e

em um hardware antigo, de um fabricante que não oferece mais suporte no Brasil

(Bull Computadores), e executava um software que ninguém na empresa sabia

como instalar e que não tinha mais contrato de suporte com o fabricante. O software

continha informações de contabilidade e que devem ser guardadas por um período

de tempo, para efeito de auditorias, neste caso encontrei a solução através da virtu-

alização.

25

A VMWare disponibiliza um software, chamado VMWARE Converter [22],

que é especializado em fazer migrações P2V, que significa Physical to Virtual (Físico

para Virtual). O VMWARE Converter faz a cópia de todos os arquivos do servidor fí -

sico para um servidor virtual, já alterando as configurações de drivers e sistema ope-

racional para o novo hardware (virtual). Resolvi dois problemas de uma só vez, não

precisei reinstalar nada e ainda me livrei de um equipamento, que já estava obsole-

to.

Os softwares P2V são de grande valia no caso da consolidação de servi-

dores, pois estes evitam os riscos envolvidos na reinstalação de todo um sistema.

Novamente, o caso da Caixa Econômica Federal serve como exemplo, no

qual as máquinas executavam Windows NT. A Microsoft tinha parado de oferecer

suporte ao sistema e o hardware estava dando sinais de fadiga. A saída foi consoli-

dar as máquinas, não tenho informações se foi utilizada a migração P2V, mas o que

quero com isto é oferecer um caso real de software legado que ganhou sobrevida

através da virtualização.

3.1.5 Custo

Dividimos esta seção em hardware e software, de forma a observarmos

esta questão sob estes dois pontos de vista.

a) Hardware

A diferença no custo entre um ambiente tradicional e um virtual depende

muito dos tipos de serviços que serão empregados no ambiente. A comparação que

fizemos, de forma a ilustrar esta questão, é apresentada na Tabela 1: Custo de ser-

vidores (Fonte: www.dell.com.br em 30/10/2008) e utiliza como base o ambiente de-

finido para este trabalho. A comparação foi efetuada a partir dos computadores

26

PowerEdge T105 e o PowerEdge 2900 geração lll. O T105 é um modelo de servidor,

no caso o mais simples que encontrei no site da Dell (Brasil) na ocasião da pesqui-

sa, do qual seriam compradas cinco unidades, no caso da montagem da DMZ no

modo tradicional. O modelo 2900 é um servidor com mais recursos (necessários,

pois será a base para cinco servidores guest), com quatro vezes mais memória e

discos mais rápidos, 10.000 rpms contra 7200 rpms do T105, e também procuramos

diminuir uma desvantagem, que será vista mais adiante, que é a disponibilidade. O

servidor 2900 possui recursos que aumentam sua disponibilidade, tais como: RAID-18, fontes de energia redundantes9 e placas de rede com suporte a Nic teaming.10

Tabela 1: Custo de servidores (Fonte: www.dell.com.br em 30/10/2008)

Modelo PowerEdge T105 (5 servidores) PowerEdge 2900 lll

ProcessadorProcessador AMD Opteron™ Dual-Core 1210 (1.80 GHz, 2X1 MB L2 cache)

Processador Intel® Xeon® Quad-Core E5410 (2.33 GHz, 2x6 MB L2 cache, 1333 MHz

FSB)Memória Memória de 1GB DDR2, 800MHz 4GB 667MHZ

Discos Rígidos Disco Rígido de 250GB 7.2K RPM SATA

2 x Discos Rígidos SAS de 400GB, 3,5 polegadas,

10K RPM, Hot PlugRAID Não RAID 1 (Espelhamento)Suporte (Garantia) 3 anos (5x10) 3 anos (5x10)

Placa de Rede On-Board Single Gigabit Broadcom Dual GigabitFonte Redundante Não Sim (2 fontes)

Total (R$) 8.180,00 (1.636,00 cada um) 8.662,00

O custo de aquisição no ambiente tradicional ficou menor do que no ambi-

ente virtual, cada T105 custaria R$ 1.636,00 como precisaríamos de cinco então o 8 RAID-1 (Mirroring) é um sistema que permite usar dois HDs, sendo que o segundo armazenará uma

imagem idêntica do primeiro, obviamente perdemos 50% do espaço (se você utilizar dois discos de

100Gb, não terá disponível 200Gb mas sim 100Gb), mas caso o disco titular falhe o outro assume

seu lugar, sem interromper os serviços.9 Fontes Redundantes, um servidor pode ter duas fontes de energia, preferencialmente cada uma li -

gada a um circuito de energia diferente da outra, assim caso ocorra uma falha em um dos circuitos ou

em uma das fontes o servidor não terá interrupção de energia.10 NIC Teaming faz-se duas placas de redes funcionarem como uma, assim se uma falha a outra as-

sume o seu lugar automaticamente.

27

total ficou em R$ 8.180,00 contra R$ 8.662,00. Agora vamos aprofundar mais este

estudo, vejamos alguns pontos:

• Aumento no preço do 2900 para diminuir riscos de falha total do

ambiente: o ambiente virtual teria um ponto de falha, ou seja, caso

o servidor 2900 falhasse então cinco servidores ficariam indisponí-

veis. Devido a esta questão adicionamos componentes para que

esta condição tivesse uma menor probabilidade de ocorrer (isto au-

mentou o preço do 2900, por exemplo, teríamos que comprar dois

discos ao invés de um), já nas T105, que não possuem estes com-

ponentes, o risco de todos os servidores ficarem indisponíveis é

menor.

• Consumo de Energia: A diferença de R$ 482,00 seria recuperada

facilmente com o menor consumo de energia do 2900 (Consumo

de um servidor 2900 contra cinco T105), lembre-se servidores nor-

malmente ficam 24 horas ligados e além do seu consumo também

necessitam de ar-condicionado, menos servidores é igual a um me-

nor calor gerado que é igual redução no consumo de ar-condicio-

nado.

• Suporte: Quando o contrato de suporte terminasse teríamos que

pagar cinco contratos de suporte do T105 contra apenas um do

2900 (obviamente o valor da manutenção do 2900 será maior que

a de um T105, mas certamente inferior a cinco máquinas T105).

Considerando todos os pontos abordados o menor custo seria de um ser-

vidor base para máquinas virtuais, o que compensaria o maior investimento inicial.

28

b) Software

Subdividimos este tópico entre licenças de software, manutenção e

software de virtualização:

b-1) Licenças de software

O ambiente utilizado neste trabalho não é um bom exemplo de ganho em

termos do custo das licenças, comparado a um ambiente físico tradicional, pois fiz

muito uso de software livre e utilizei apenas duas licenças de Windows, uma para a

máquina virtual SVMAIL01 e outra para a máquina host SVVM01. No ambiente tradi-

cional só utilizaría no servidor que faria o papel do SVMAIL01. Muitos acreditam que

por instalar o Windows em uma máquina virtual não necessitam de licença, apenas

a licença da máquina host, mas na verdade a Microsoft cobra a licença por máquina,

não faz diferença se física ou virtual, mas há exceções, que serão vistas a seguir.

Os ganhos com custo em termos de software acontecem nos seguintes cená-

rios:

• Ambiente focado na plataforma Microsoft e utilizando software de virtu-

alização Microsoft: quem compra a versão Enterprise do Windows

pode criar até quatro máquinas virtuais sem pagar licença adicional. O

preço da versão Enterprise é de aproximadamente R$ 5.000,00 e a

Standard R$ 1.550,00 (fonte: www.dell.com.br em 30/09/2008), isto se

utilizar o software de virtualização da Microsoft, o Virtual Server, se uti-

lizar algum outro, como o VMWare, então se paga uma licença por

cada máquina virtual.

• Economia no caso de softwares que cobram licenças por processador:

alguns softwares da Oracle, Symantec e Microsoft cobram licenças por

processador, isto é, se o software for instalado em uma máquina com

dois processadores serão cobradas duas licenças. O servidor host

pode ter vários processadores, mas a máquina virtual pode ser induzi-

da a “enxergar” apenas um. Alguns softwares de virtualização podem

29

até mesmo fazer com que a máquina guest “enxergue” apenas um pro-

cessador mas se beneficie do processamento de todos os processado-

res da máquina host. É importante verificar o contrato do software, pois

a virtualização não é uma tecnologia tão nova e os fabricantes de

software já podem estar se precavendo destas possíveis “artimanhas”

na economia com licenças.

Em resumo, nos ambientes que utilizam fortemente o software livre a re-

dução dos custos para aquisição de software são raramente percebidos, o que funci-

ona de forma diferente nos ambientes de softwares proprietários, mas ainda pode-

mos ter economia em ambientes com softwares que cobram licenças por processa-

dor e nos custos com tempo de suporte técnico na hora de fazer um upgrade.

b-2) Manutenção

Neste ponto destaco a economia no momento do upgrade do hardware da

máquina host. A cada ano que passa os softwares oferecem novos serviços e isso

demanda uma maior capacidade de processamento e memória. Devido a estes fato-

res, em apenas três anos, pode ser necessário adicionar mais memória à máquina

host ou até mesmo substituí-la. No caso do ambiente tradicional seria necessário

reinstalar todos os softwares nas máquinas novas, já no caso das virtuais seria ne-

cessário apenas instalar o sistema de virtualização na máquina nova e depois copiar

os arquivos das máquinas virtuais. Tais operações economizam tempo, dinheiro e

reduzem riscos de configurações inadequadas no caso de uma reinstalação.

b-3) Software de Virtualização

O software escolhido para este trabalho foi o VMWare Server, por ser gra-

tuito, mas para alguns tipos de negócios, que demandam alta disponibilidade, seria

interessante investir em softwares como o VMWare ESX (a versão mais barata custa

R$ 7.612,00, fonte: www.dell.com.br). O custo do mesmo seria justificado pelo me-

lhor desempenho e possibilidade de montar uma solução de alta disponibilidade.

30

3.1.6 Segurança

Uma das principais dúvidas relacionadas às máquinas virtuais é a seguin-

te: Se meu servidor host for invadido, as máquinas guests também serão comprome-

tidas? No caso da máquina host, o invasor poderia ter acesso ao software de virtuali-

zação e, conseqüentemente, poderia apagar as máquinas virtuais, mas quanto a

comprometer os dados contidos nas guest a resposta é não. Os dados das máqui-

nas guest estão tão seguros quanto os de uma máquina física tradicional. Isto por-

que os softwares de virtualização trabalham com a seguinte premissa: o que quer

que esteja executando em uma máquina virtual, não pode comprometer a segurança

do sistema host. O isolamento também existe entre as máquinas guest, por exem-

plo, se uma máquina guest for contaminada por um vírus, a chance de outra máqui-

na guest ser contaminada é a mesma chance de um servidor físico ser contaminado

por um vírus que esteja em outra máquina física, ou seja, ser virtual não deixa a má-

quina mais vulnerável, aliás, os mesmo cuidados tomados com uma máquina física

devem ser tomados em uma máquina virtual (antivírus, manter o sistema operacio-

nal atualizado, etc.).

A virtualização favorece um aspecto de segurança, que é a divisão de ser-

viços por servidor, isto é, ao invés de manter em apenas um servidor físico contendo

vários serviços, podemos criar várias máquinas virtuais cada uma com um serviço.

Por exemplo, ao invés de ter uma máquina física suportando o serviço de e-mail,

FTP e banco de dados, posso utilizar três máquinas virtuais, cada qual com um dos

serviços. Normalmente, estes três serviços são mantidos por diferentes profissio-

nais, principalmente o banco de dados (mantido por um DBA11), no que tange o fator

humano ao dividir em três máquinas, estou ajudando a separar as responsabilida-

des, isto é, cada administrador cuida da sua máquina. Esta separação, no fator tec-

nologia, pode evitar problemas de incompatibilidade entre dois softwares diferentes

na mesma máquina e diminuir a “superfície de ataque” a uma máquina. Imagine a si -

11 DBA – Database Administrator (Administrador de Banco de Dados), é o profissional que cuida dos

bancos de dados, tem como principais atividades manter a segurança dos bancos, analisar perfor-

mance, suporte a equipe de desenvolvimento, manter planos de recuperação, entre outras.

31

tuação, na qual, uma máquina contendo dois serviços, um deles poderia sofrer com

uma falha de segurança que levasse a indisponibilidade do servidor (ser vulnerável a

ataques do tipo DoS12), o outro ficaria indisponível por causa da falha do primeiro.

3.2 DESVANTAGENS

Vejamos algumas desvantagens e possíveis soluções, que visam minimi-

zar as mesmas.

3.2.1 Vários sistemas com um único ponto de falha

Diferente dos sistemas tradicionais, distribuídos entre vários servidores fí-

sicos, quando temos apenas um servidor físico suportando várias máquinas virtuais,

este se torna um ponto único de falha.

Existem maneiras de amenizar esta desvantagem, vejamos algumas de-

las:

• Utilizar um servidor com recursos de alta disponibilidade, como o

proposto na seção anterior referente aos custos, no qual a máquina

a ser utilizada como servidor host possui recursos como RAID-1 e

fontes redundantes.

• Utilizar softwares de virtualização com suporte para alta disponibili-

dade, o VMWARE ESX pode ser utilizado neste tipo de solução,

mas seriam necessárias pelo menos duas máquinas host e um sto-

12 DoS – Denial of Service (Ataque de Negação de Serviço), são técnicas de ataque que podem so-

brecarregar uma rede a tal ponto os usuários dela não consigam usá-la, por exemplo, fazer tantas re-

quisições a um site até que este não consiga mais ser acessado.

32

rage NAS13 ou SAN14. Neste caso, os arquivos das máquinas virtu-

ais ficam alocados em discos fora das máquinas host, mas acessí-

veis por todos os hosts participantes da solução. Vejamos um

exemplo prático: duas máquinas host acessam o mesmo disco em

um storage, no qual estão os arquivos das máquinas virtuais e ape-

nas um host gerencia as máquinas virtuais, caso esta falhar a má-

quina host que estava desocupada assume o gerenciamento das

máquinas virtuais. Esta solução teria um de downtime 15 pequeno,

mas com custo maior.

• Manter um plano de recuperação de desastres, que é um docu-

mento contendo informações de backup do ambiente e, também,

um passo a passo para a recuperação do ambiente em caso de fa-

lhas. Esta solução teria um downtime grande e que alguns negóci-

os não suportariam por ter um prejuízo grande decorrente da para-

da do sistema.

As melhores soluções são caras, o que devemos avaliar é o impacto da

indisponibilidade dos serviços sobre o negócio para avaliar se vale à pena o investi-

mento.

3.2.2 Desempenho

Como vimos anteriormente, os sistemas de virtualização acrescentam

mais uma camada, que cuida da separação dos recursos para as máquinas virtuais

guest. Esta camada adicional acaba por deteriorar o desempenho das máquinas

13 NAS - Network-Attached Storage - Dispositivo dedicado à armazenagem de arquivos em uma rede,

os dados podem ser acessados por outro servidor através de uma rede TCP/IP.14 SAN - Storage Area Network (rede de armazenamento de dados) é uma rede de alta velocidade de-

dicada a fornecer benefícios diversos relacionados ao acesso a dados, normalmente acessados via fi-

bras ópticas.15 Downtime, tempo de indisponibilidade de um servidor.

33

guest, pois a cada interação entre a máquina guest e a máquina host esta camada

tem que ser acionada.

Os sistemas que fazem intenso uso de disco (tais como: banco de dados e

serviços de impressão) são os mais comprometidos e que mais comprometem, pois

além de ter seu desempenho degradado pelo “passo a mais”, que é a camada de

virtualização, eles também comprometem o desempenho das outras máquinas

guest, pois concorrem com elas pelos recursos da máquina física.

Para este trabalho realizei testes simples de desempenho, de forma a

comparar uma máquina física com uma virtual e, com este objetivo, utilizei os

softwares Sisoftware Sandra Lite [20] e Super PI [21], efetuando somente o cálculo

do valor de PI.

A máquina física é o servidor utilizado neste trabalho, este foi detalhado no

Capítulo 4, e a máquina virtual foi criada, somente para esta avaliação, com sistema

operacional Windows 2003 (similar ao do host), 2048Mb de memória e disco de

4Gb.

34

Na Tabela 2 colocamos os resultados dos testes de desempenho realiza-

dos.

Tabela 2 Comparação de desempenho (Físico vs. Virtual)

Teste Físico Virtual SoftwareCPU MIPS16 5.7 3.41 Sandra MFLOPS17 5.97 3.55 Sandra Cálculo do PI (4Mb) 3m 35s 3m 43s Super PIDisco Driver Index 66,82 Mb/s 54,11 Mb/s Sandra Random Access 12 ms 17 ms SandraMemória Latency (Random Access) 138 ns 180 ns Sandra Speed Factor 91,5 171,5 Sandra

De forma a facilitar o entendimento dos dados contidos na Tabela 2 foram

utilizadas setas ao lado de cada teste. Estas indicam a melhor tendência, isto é, a

seta para cima () indica que quanto maior o valor melhor é o resultado e a seta

para baixo () indica que quanto menor o valor melhor é o resultado. Os resultados

foram descritos na seqüência.

a) CPU – MIPS

A avaliação de MIPS foi realizada com o software Sisoftware Sandra. O

experimento consiste em medir a quantidade de instruções realizadas pelo proces-

sador por segundo, quanto maior o valor indicado no teste melhor foi o desempenho.

A máquina física realizou 5,7 milhões de instruções por segundo contra 3,41 da má-

quina virtual (desempenho aproximadamente 40% inferior).

b) CPU – MFLOPS

16 MIPS (Milhões de Instruções por segundo) é um índice simples utilizado para medir a velocidade de

um processador.17 MFLOPS (Milhões de Operações de Ponto Flutuante), parecido com MIPS, mede a velocidade das

operações de Ponto Flutuante.

35

Neste experimento, semelhante ao MIPS, mas focado nas instruções de

ponto flutuante, também utilizamos o Sisosftware Sandra. Novamente a máquina vir-

tual foi inferior. Enquanto a máquina física realizou 5,97 milhões de instruções por

segundo a virtual realizou 3.55 milhões (aproximadamente 40% inferior).

c) CPU – Cálculo do PI (π)

O programa Super PI realiza o cálculo do PI18 com a quantidade de casas

decimais solicitadas, quanto menor for o tempo melhor é o resultado. Para o teste

solicitei o cálculo o PI com quatro milhões de dígitos. Na máquina física demorou

3:35 (3 minutos e 35 segundos) contra 3:43 da virtual.

d) Disco - Driver Index

O Index representa o desempenho de leitura e gravação em todo o disco,

utilizado o SiSoftware Sandra, quanto maior for a quantidade de MBytes gravados

por segundo melhor é o resultado. Obtive 66,82 Mb/s para a máquina física contra

54,11 da virtual (20% de redução de desempenho).

e) Disco - Random Access

Este teste feito pelo Sisoftware Sandra, que avalia o tempo médio em que

o disco necessita para encontrar um setor em um local aleatório no disco, quanto

menor for o tempo melhor. A máquina física teve resultado de 12 ms e a virtual 17

ms, ou seja, 40 % mais lenta.

18 Pi (π) é o valor da razão entre a circunferência de qualquer círculo e seu diâmetro, é a mais antiga

constante matemática que se conhece( 3,1408...).

36

f) Memória - Latência (Random Access)

A latência é o tempo decorrido do inicio de uma requisição até o tempo de

retorno da informação solicitada, o experimento foi feito com o software Sisoftware

Sandra. A máquina física registrou a marca de 138ns contra 180ns da máquina virtu-

al (desempenho 30% inferior).

g) Memória - Speed Factor

O Speed factor é a razão entre a velocidade do cachê da CPU e a veloci-

dade da memória (indica a diferença de velocidade entre os dois, a velocidade da

memória é mais lenta, quanto menor esta diferença melhor), utilizado o Sisoftware

Sandra. A máquina física foi muito superior com 91,5 contra 171,5, ou seja, a máqui -

na virtual foi 87% inferior.

h) Conclusão

Como esperado, devido à adição de uma camada de software, em todos

os testes realizados a máquina física teve um desempenho superior ao da máquina

virtual. Somente como um registro, estes experimentos podem ter resultados dife-

rentes se utilizarmos outros softwares de virtualização e avaliações desta natureza

podem não refletir o desempenho das operações do dia-a-dia dos servidores. De

fato existe uma degradação no desempenho, mas isto pode ou não ser um problema

que depende fundamentalmente do correto dimensionamento do servidor host para

as aplicações que este atenderá.

37

4 APLICANDO A TECNOLOGIA

Neste capítulo veremos a montagem e configuração do servidor host, do

software de virtualização e das máquinas virtuais que fazem parte da DMZ Virtual.

4.1 SERVIDOR HOST

Dividimos esta seção em hardware e software. A primeira descreve os

componentes físicos, utilizados no servidor host, e na segunda, mais extensa, deta-

lho a montagem do ambiente virtual.

4.1.1 Hardware

Utilizei um computador com os seguintes componentes: placa mãe ASUS

M2NPV-VM/S (som, placa de rede e vídeo on-board), processador AMD Athlon 64

X2 Dual Processor 4000+ (2.10 GHz), 4 Gb de memória RAM, 1 HD IDE de 40 Gb, 1

HD SATA de 250 Gb, placa de rede adicional Via de 100Mbps.

Estes componentes foram todos escolhidos por alguma razão específica, a

placa-mãe foi por questões de custo, pois possui componentes on-board, e, tam-

bém, por oferecer suporte ao processador Athlon 64 X2 4000+. Este processador

por sua vez foi selecionado, porque possui instruções necessárias por algumas apli-

cações de Virtualização como o XEN [25], isto garantiu mais opções de escolha do

software de virtualização. A utilização de memória é um ponto crítico na virtualiza-

ção, na Tabela 3 temos o cálculo da quantidade de memória por máquina, observe

38

que utilizei uma quantidade maior para os sistemas operacionais com interfaces grá-

ficas na sua operação (Windows e OpenSolaris) e para os demais 256 Mb foram su-

ficientes. Com um total de 3328Mb chegamos à conclusão que 4 Gb (4096 Mb) seri-

am mais que suficientes, permitindo até mesmo o acréscimo de mais uma máquina

virtual.

Tabela 3: Quantidade de memória por servidor

Nome Sistema Operacional Memória (em Mb)SVFW01 FreeBSD 7 256SVFW02 CentOS 5 256SVDB01 OpenSolaris 1024SVWEB01 Ubuntu 8 256SVMAIL01 Windows 2003 512

SVVM01 Windows 2003 (reserva para o servi-dor físico) 1024

Total 3328

Dois HDs foram incluídos procurando aumentar desempenho de

leitura/gravação dos mesmos (fator crítico em virtualização). O disco menor (HD

IDE) ficou reservado para o sistema operacional host e o HD SATA para os arquivos

dos sistemas Guest, assim garanti um fluxo separado entre os dados do host e das

guest. Por fim, uma placa de rede adicional para funcionar como porta de um dos la-

dos da DMZ, pois já tinha uma placa de rede on-board. O nome lógico deste compu-

tador será SVVM01.

4.1.2 Software

Existem várias opções de software de virtualização disponíveis, analisei

quatro dos principais softwares disponíveis: VMWARE ESXi, VMWARE Server, Mi-

crosoft Virtual Server e XEN. As características principais que levaram a escolha do

software foram: fabricantes de renome, custo, compatibilidade de hardware e siste-

39

mas guest, disponibilidade de instalação nos sistemas Windows e Linux. Vejamos a

análise de cada um dos itens.

4.1.2.1 Fabricante

A VMWare fabricante do ESXi e VMWARE Server é a empresa líder em

virtualização [2], “É líder incontestável, com mais da metade ou 80% do mercado uti-

lizando seu hipervisor, dependendo de quem está contando”.

A Citrix empresa conhecida pelo software Metaframe, adquiriu em 2007 o

software de virtualização XEN [1], além de produzir uma versão Enterprise, a empre-

sa se comprometeu a continuar com uma versão Open.

Por último a Microsoft, que dispensa maiores comentários, líder mundial

no mercado de software, entrou no mercado de virtualização com uma estratégia pa-

recida com que utilizou para vencer o Netscape com seu produto Internet Explorer.

Ela está oferecendo seus produtos de virtualização a um preço muito baixo ou até

mesmo gratuitamente, que foi o caso do Virtual Server e Virtual PC, mais recente-

mente lançou uma versão do Windows 2008 exclusivamente para utilização do Hy-

per-V, novo sistema de virtualização da Microsoft.

4.1.2.2 Custo

Em termos de custo as quatro opções são iguais, visto que todas possu-

em versões gratuitas.

40

4.1.2.3 Compatibilidade de hardware

Quanto à compatibilidade de hardware o VMWARE ESX e o XEN perde-

ram para as outras duas opções. O VMWARE ESX é um sistema de alto desempe-

nho e possui uma HCL (Hardware Compatibility List – Lista de compatibilidade de

hardware) menos flexível que os demais (alguns discos SATA, comuns nos compu-

tadores atuais não são homologados), é inegável que o VMWARE ESX é o melhor

software de virtualização do mercado, mas para este experimento o hardware não

atenderia, então o mesmo foi descartado.

O XEN também depende de instruções especificas do processador para

conseguir virtualizar o Windows, a máquina do nosso projeto atende ao requisito,

mas na escolha decidi utilizar um software que conseguisse suportar uma gama mai-

or de equipamentos. O objetivo desta escolha foi para que este trabalho pudesse

oferecer uma utilização mais ampla por parte de terceiros.

Neste quesito o MS Virtual Server e o VMWare Server atendem perfeita-

mente.

4.1.2.4 Suporte aos sistemas operacionais guest

O XEN só consegue virtualizar servidores com sistema operacional Win-

dows se o processador do Servidor Host possuir suporte para a virtualização e no

caso do Linux e do FreeBSD se faz necessário utilizar um Kernel19 diferente. O

hardware do experimento possui as características necessárias, mas no âmbito ge-

ral isto deixou o XEN menos flexível que o VMWARE Server e o Microsoft Virtual

Server. Todos conseguem virtualizar os principais sistemas operacionais, feita uma

19 O Kernel de um sistema operacional é entendido como o núcleo deste ou, numa tradução literal,

cerne. Ele representa a camada de software mais próxima do hardware, sendo responsável por ge-

renciar os recursos do sistema computacional como um todo

41

ressalva ao XEN, que depende do processador para Windows ou do Kernel modifi-

cado para Linux.

4.1.2.5 Disponibilidade de instalação no Windows ou Linux

Quanto à disponibilidade de instalação tanto em Windows quanto em

Linux, o XEN possui instalação apenas para Linux (existe uma a instalação para

Linux, mas é uma versão Linux otimizada que já instala o XEN). O Microsoft Virtual

Server funciona apenas para Windows. A versão ESXi do VMWARE tem seu próprio

sistema customizado e a versão Server é o único dos softwares avaliados que pos-

sui versão tanto para Windows quanto para Linux. Isto é importante, pois o conheci-

mento da equipe de informática, que irá implantar um sistema de virtualização, deixa

de ser um fator comprometedor para o projeto.

4.1.2.6 Resumo

Na Tabela 4 sintetizei a análise feita dos sistemas de virtualização.

Tabela 4: Fatores de decisão para escolha do software e virtualização

Nome Fabricante Reconhecido Custo Compatibilidade

Hard/SoftSistema Operacional

Host

Citrix XEN √ Gratuito Restrições Linux e Sistema Próprio

MS Virtual Server √ Gratuito √ Apenas WindowsVMWare ESXi √ Gratuito Restrições Sistema PróprioVMWare Server √ Gratuito √ Windows e Linux

42

Dados os fatores apresentados, minha opção foi pelo VMWARE Server,

pois atende a todas as características necessárias: fabricado pela VMWARE (núme-

ro um em virtualização), gratuito, boa compatibilidade de hardware e software e

pode ser instalado tanto no Windows quanto no Linux.

O software pode ser baixado no site do fabricante [23] e, após um regis-

tro, você receberá a chave de ativação do software por e-mail. A instalação é sim-

ples, com manual disponível no site do VMWARE [24].

4.2 INSTALAÇÃO E CONFIGURAÇÃO DO SOFTWARE

Para a instalação foi necessário alterar as configurações do Host e do

VMWARE Server.

Na máquina Host foram desabilitados os serviços de TCP/IP20 nas duas

placas de rede, isto serve para evitar que algum trafego de rede faça um bypass21

em nossa DMZ. O tráfego do trabalho requer que os pacotes, que passem pelo ser-

vidor, sejam inspecionados pelos dois firewalls, presentes na nossa DMZ. Caso o

TCP/IP estivesse habilitado no servidor Host, teria o risco de que este tráfego pas-

sasse somente através do Host. A configuração efetuada é uma precaução e pode,

até mesmo, ser considerada como uma medida de segurança.

No VMWARE precisei configurar as redes virtuais. Isto se deve ao fato de

que quando associamos uma placa de rede virtual a uma máquina guest ela pode

ser configurada de três formas diferentes: Bridge22, NAT23 e Host-only24, nos interes-

sam a Bridge e a Host-only, pois a configuração NAT depende do TCP/IP habilitado 20 TCP/IP é um conjunto de protocolos de comunicação entre computadores em rede. Seu nome vem

dos dois protocolos mais importantes do conjunto: o TCP (Transmission Control Protocol - Protocolo

de Controle de Transmissão) e o IP (Internet Protocol - Protocolo de Interconexão).21 Bypass em inglês quer dizer "desvio", onde em um sistema você consegue ser alimentado por ca-

minhos diferentes.

43

no Host (este fora desabilitado anteriormente). No caso de Bridge a placa virtual fica

associada a uma placa física, é como se a placa física ganhasse uma nova porta

acessível somente através da guest, isto é, se transforma em um switch25, se por

exemplo, à placa física está ligada a uma rede 10.0.0.0/8 a placa virtual também terá

acesso à mesma, independente da máquina host. No caso da configuração Host-

only a máquina guest tem acesso apenas às máquinas guest dentro da mesma rede

virtual sem qualquer contato com o mundo exterior.

Figura 4-4: Redes virtuais VMnet0, VMnet1 e VMnet2.

Na Figura 4.1 temos as três redes utilizadas neste trabalho:

22 Bridge (Ponte) configuração em que a máquina virtual tem acesso às redes externas através da

placa de rede da máquina host.23 NAT (Network Address Translation), sistema que possibilita uma rede privada ter acesso a uma

rede pública.24 Host-only (somente host) neste modo de configuração a placa de rede virtual tem acesso limitado

ao host.25 Switch é um dispositivo que tem a função de interligar os computadores de uma rede local.

44

• VMnet0 em modo bridge ligada à placa de rede física que é conectada a In-

ternet;

• VMnet1 no modo Host-only que não tem acesso ao mundo externo.

• VMnet2 em modo bridge ligada à placa de rede física conectada a rede local;

Na Figura 4.2 apresentamos a tela de configuração do software.

Figura 4-5: Tela de configuração das redes virtuais.

Repare ainda na Figura 4.2, que VMnet0, VMnet2 estão ligadas às placas

físicas do Host, NVIDIA nForce e VIA VT6105 Rhine lll respectivamente.

45

4.3 SERVIDORES GUEST

Neste trabalho utilizei cinco servidores guest, cada um executando um

sistema operacional diferente bem como disponibilizando deferentes serviços. Isto

teve o objetivo de demonstrar a flexibilidade dos sistemas de virtualização.

Para uma identificação rápida das máquinas guest, foram atribuídos no-

mes padrão para as mesmas, sendo que cada nome é formado por “SV” para indicar

que é um servidor. Para a função primordial de cada um juntei ao nome as siglas

FW para firewall, DB para Banco de Dados, WEB para serviços de Internet e MAIL para serviços de correio eletrônico. Além destas siglas adicionei uma numeração.

Em todas as máquinas virtuais fiz duas customizações nas suas configura-

ções, a primeira diz respeito ao usuário que executa o processo da máquina virtual,

para isso na opção “Settings”, abra “Options”, opção “Startup/Shutdown” foi configu-

rada para utilizar “Local system account”, ao invés da opção padrão “User that

powers on the virtual machine”, com a opção padrão as máquinas virtuais desligam

caso o usuário, que ligar a máquina virtual, não mantenha uma sessão aberta na

máquina host. Já a segunda customização foi efetuada no arquivo “.vmx”26 de cada

máquina virtual, editamos este arquivo adicionando ao final a opção “Ethernet0.virtu-

alDev = "e1000"”. Isto significa que a máquina virtual irá emular uma placa de rede

Intel ao invés da AMD (que não é compatível com alguns sistemas operacionais),

caso a máquina virtual tenha mais de uma placa de rede devemos adicionar uma li-

nha para cada placa, alterando somente a numeração do atributo. Por exemplo, se

forem duas placas, além de adicionar o atributo que já citado, também dever ser in-

cluído “Ethernet1.virtualDev ="e1000"”, repare que a outra era Ethernet0 – zero.

A seguir veremos informações sobre a montagem de cada uma das má-

quinas guest, as informações compreendem:

26 .vmx é a extensão que identifica arquivos com a configuração das máquinas virtuais do VMWARE,

este tipo de arquivo guarda informações como quantidade de memória que a guest utiliza, caminho

dos discos virtuais, etc.

46

• Sistema operacional utilizado: observe que a instalação dos siste-

mas operacionais seguiu uma linha padrão, isto é, sem alterar as

configurações sugeridas pelos programas de instalação dos mes-

mos. Em um ambiente de produção real, que normalmente não uti-

lizam tantos sistemas operacionais quanto neste projeto, devemos

observar as melhores práticas de instalação e configuração para

obtenção de desempenho e segurança.

• Recursos virtuais: são os recursos disponibilizados pelo VMWARE

Server, tais como: discos, placas de rede, etc.

• Configurações de rede: são os endereços IP das placas de rede,

gateways27 e rotas28 necessárias.

• Serviços: são os sistemas instalados no servidor, é a razão do ser-

vidor existir, não será dada ênfase nos detalhes destes serviços,

pois alguns destes, como o SMTP, merecem um trabalho à parte.

4.3.1 SVFW01

Este servidor é o responsável por controlar o tráfego de comunicação en-

tre o ambiente interno (DMZ e LAN) e o ambiente externo (Internet), como destaca-

do na Figura 4-3.

27 Gateway equipamento responsável por transferir dados de uma rede para outra.28 Rota é um par definido de endereços: um “destino” e um “gateway”. Para uma máquina ser capaz

de encontrar outra através de uma rede, é necessário um mecanismo que descreva como ir de uma

para a outra. Isto é chamado roteamento.

47

Figura 4-6 Diagrama físico da rede com o SVFW01 em destaque

4.3.1.1 SVFW01: Sistema operacional

Foi utilizado o sistema operacional FreeBSD 7 (ver Anexo B), que é um

sistema operacional robusto, como apresentado em [7], e é adequado ao tipo de ser-

viço que estará ativo nele, ou seja, o firewall.

O sistema operacional foi instalado com as opções Standard, que é um

tipo de instalação que inclui apenas os pacotes básicos para o seu funcionamento.

48

4.3.1.2 SVFW01: Recursos virtuais

Os seguintes recursos foram disponibilizados na máquina virtual:

• 256 Mb de memória RAM, o FreeBSD é um sistema que necessita de

pouca memória, durante os experimentos ele não chegou a utilizar 150

Mb. Vale lembrar utilizei um usuário no sistema, portanto 256Mb é um

bom começo para um ambiente com vários usuários.

• Dois discos virtuais, um para os arquivos do sistema e dos usuários e

outro exclusivo para swap29. O primeiro foi definido com 4 Gb e o se-

gundo com 600 Mb (mais de duas vezes o tamanho da memória RAM,

o que é o indicado para swap).

• Duas placas de redes, uma para conexão com a Internet (Vmnet0) e

outra conectada a DMZ (Vmnet1).

• Um processador.

• Um drive de DVD, necessário para instalação do SO.

4.3.1.3 SVFW01: Configurações de rede

Este servidor tem uma placa ligada a VMNet0 (Internet) e outra VMNet1

(DMZ), ilustradas na Figura 4-3, com as seguintes configurações:

29 Swap ou arquivo de troca, é um espaço utilizado em disco para gravar dados da memória RAM

quando esta já não tem mais espaço, quanto menos utilizada melhor pois a velocidade de gravação e

leitura em disco é menor do que o acesso a RAM.

49

• Placa um, identificada pelo sistema operacional como em0 está ligada

a Internet via VMNet0, suas configurações de rede estarão no modo

automático.

• Placa dois, identificada como em1, está ligada a DMZ via VMNet1 e

seu endereço IP é 192.168.0.100 com máscara 255.255.255.0.

No FreeBSD, a configuração de rede pode ser feita pelo programa sysins-

tall ou alterando o arquivo /etc/rc.conf (ver Anexo C).

Por padrão, o computador conhece as rotas para as redes das placas co-

nectadas a ele, como este computador não está conectado a rede LAN então foi ne-

cessário adicionar a rota para a rede 10.0.0.0/8 utilizando como gateway o endereço

192.168.0.200 do servidor SVFW02. Esta configuração foi feita no arquivo /etc/rc.-

conf (ver anexo C), no qual introduzi as linhas abaixo:

static_routes = “rlan”route_rlan = “-net 10.0.0./8 192.168.0.200”

4.3.1.4 SVFW01: Serviços

Os seguintes serviços estão foram habilitados no SVFW01:

• PF: é o firewall, principal função deste servidor. Este serviço será mais

detalhado na seção de segurança deste capítulo.

• Gateway: este servidor encaminhará pacotes entre os ambientes inter-

no e externo.

• FTP-Proxy: serviço necessário para publicar o serviço de FTP.

• SSH: serviço que disponibiliza acesso remoto ao servidor.

50

• PPP: serviço que efetua a discagem para Internet através de um mo-

dem ADSL30, configurado via o arquivo /etc/ppp/ppp.conf (ver anexo

C).

Todos estes serviços já estavam instalados no FreeBSD sendo necessá-

ria apenas a sua habilitação no arquivo /etc/rc.conf (ver anexo C).

4.3.2 SVFW02

Este servidor é o responsável por controlar o tráfego de comunicação en-

tre a DMZ e a LAN, conforme destaquei na Figura 4-4.


30 ADSL (Assymmetric Digital Subscriber Line) tecnologia que permite a transferência digital de dados

em alta velocidade por meio de linhas telefônicas comuns.

51

4.3.2.1 SVFW02: Sistema operacional

O sistema operacional utilizado foi o CentOS 5 (ver Anexo B), escolhido

por ser tratar de uma distribuição derivada do Red Hat Enterprise, que é uma distri-

buição Linux voltada para o mundo corporativo.

4.3.2.2 SVFW02: Recursos virtuais

Os seguintes recursos foram disponibilizados para a máquina virtual:

• 256 Mb de memória RAM, assim como o FreeBSD, também não utiliza

muita memória.

• Dois discos virtuais, um para os arquivos de sistema e dos usuários e

um exclusivo para swap, o primeiro com 8 Gb e o segundo com 1 Gb.

• Duas placas de redes, uma para conexão com a DMZ (Vmnet1) e ou-

tra conectada a LAN (Vmnet2).

• Um processador.


4.3.2.3 SVFW02: Configurações de rede

Este servidor tem uma placa ligada a VMNet0 (Internet) e outra VMNet1

(DMZ), conforme demonstrado na Figura 4-4, com as seguintes configurações:

• Placa um: identificada pelo sistema operacional como eth0 será ligada

a DMZ via VMNet1, e seu endereço IP é 192.168.0.200 com máscara

255.255.255.0 e DNS 192.168.0.10 (SVMAIL01).

52

• Placa dois, identificada como eth1, está ligada a LAN via VMNet2 e

seu endereço IP é 10.0.0.1 com máscara 255.0.0.0 e DNS

192.168.0.10 (SVMAIL01)

No CentOS, a configuração de rede pode ser feita pelo programa system-

config-network.

O SVFW02 conhece as redes DMZ e LAN, para que ele tenha acesso a

Internet foi configurado via system-config-network o default gateway para

192.168.0.100 que é o endereço do SVFW01.

4.3.2.4 SVFW02: Serviços

Os seguintes serviços foram instalados ou habilitados no SVFW02:

• Iptables v1.3.5: é o serviço de Firewall, maiores detalhes de sua confi-

guração serão visto na seção de segurança deste capítulo, ele foi ha-

bilitado utilizando o programa ntsysv.

• Gateway: este servidor encaminhará pacotes entre as redes DMZ e

LAN, este serviço foi habilitado configurando o arquivo /etc/sysctl.conf,

foi alterado o valor do atributo “net.ipv4.ip_forward” para “1” (Ferreira,

Rubens, 2003) [5].


53

4.3.3 SVMAIL01

Este contempla os serviços de e-mail e resolução de nomes. Está locali-

zado na DMZ, conforme destacado na Figura 4-5.

Figura 4-8 Diagrama físico da rede com o SVMAIL01 em destaque

4.3.3.1 SVMAIL01: Sistema operacional

Foi instalado o Windows Server 2003 Standard (ver Anexo B), sistema

operacional da Microsoft. Utilizamos as opções padrão para a instalação.

54

4.3.3.2 SVMAIL01: Recursos virtuais


• Com 512 Mb de memória RAM, que corresponde ao dobro da memó-

ria adicionada às máquinas anteriores já que este sistema operacional

utiliza interface gráfica.

• Um disco virtual com 10 Gb, já que o sistema operacional ocupa pou-

co mais de 3 Gb, mas por ter o serviço de e-mail ele pode precisar de

mais espaço em disco necessário para as caixas de correio dos usuá-

rios.

• Uma placa de rede, para se conectar a DMZ (Vmnet1).

• Um processador.


4.3.3.3 SVMAIL01: Configurações de rede

Este servidor tem apenas uma placa ligada a VMNet1 (DMZ), ela tem o IP

192.168.0.10, máscara 255.255.255.0, default gateway 192.168.0.100 e DNS

192.168.0.10 (SVMAIL01). Na Figura 4-5 represento as conexões do servidor SV-

MAIL01.

No Windows, a configuração de rede pode ser feita através da interface

gráfica, acessando ”Network Connections” do painel de controle ou utilizando o co-

mando netsh.

55

O SVMAIL01 conhece apenas a rede DMZ e tem acesso à Internet por ter

o default gateway apontando para o SVFW01, foi necessário adicionar uma rota es-

tática para a LAN, isto foi feito com o comando “route add 10.0.0.0 mask

255.255.255.0 192.168.0.200 –p”, isto significa que para se comunicar com a rede

10.0.0.0/8 (LAN) os pacotes de rede devem ser encaminhados para o SVFW02

(192.168.0.200).

4.3.3.4 SVMAIL01: Serviços

Os seguintes serviços foram habilitados ou instalados no SVMAIL01:

• DNS (Domain Name System): é o serviço responsável por traduzir no-

mes em endereços IP (e vice-versa) de um determinado domínio Inter-

net (Ferreira, Rubens, 2003). É um serviço nativo do Windows, é adici-

onado utilizando o programa “Add/Remove Programs” no painel de

controle do Windows. Foram feitas as seguintes configurações:

o Criada uma zona DNS chamada cederj.tcc.

o Criado os registros dos cinco servidores que fazem parte do tra-

balho.

o Configurado o DNS 200.184.23.6 (Intelig) como DNS Forward31.

• Mercury/32 [8]: disponibiliza os serviços de SMTP (envio de e-mail) e

POP3 (recebimento de e-mail), escolhido por ser simples e ter as fun-

cionalidades mínimas requeridas para testes do ambiente. Não reco-

mendamos para um ambiente de produção, para estes seria uma me-

lhor opção utilizar os softwares comerciais Microsoft Exchange ou Lo-

31 DNS Forward, quando um servidor DNS encaminha uma consulta para outro servidor DNS pois ele

não possui o registro solicitado.

56

tus Notes (Para Windows) ou, mesmo, os softwares gratuitos como

Postfix ou Sendmail (Para Linux).

• Remote Desktop: serviço que disponibiliza acesso remoto ao servidor

e foi utilizado para realizar as instalações dos serviços citados.

4.3.4 SVWEB01

Servidor com HTTP e FTP. Localizado na rede DMZ, conforme destacado

na Figura 4-6.

Figura 4-9 Diagrama físico da rede com o SVWEB01 em destaque

4.3.4.1 SVWEB01: Sistema operacional

Utilizamos o sistema operacional Ubuntu 8 (ver Anexo B), na sua instala-

ção, que é a distribuição Linux mais popular atualmente.

57

4.3.4.2 SVWEB01: Recursos virtuais


• 256 Mb de memória RAM, não foi instalada a interface gráfica o que

economiza no uso de RAM.

• Um disco virtual com 8 Gb, os aplicativos Web (http) não ocupam mui-

to espaço (100 Mb são mais que suficientes), neste caso a maior preo-

cupação reside na quantidade de arquivos que serão colocados no

FTP, mas em nosso caso alocamos apenas o necessário para as ava-

liações.


• Um processador.


4.3.4.3 SVWEB01: Configurações de rede

Na Figura 4-9 podemos identificar as conexões do servidor SVWEB01,

ele tem apenas a placa virtual identificada com eth0 ligada a DMZ através da Vm-

net1, a placa eth0 tem o IP 192.168.0.20, máscara 255.255.255.0, default gateway

192.168.0.100 e DNS 192.168.0.10 (SVMAIL01).

As configurações de rede podem ser alteradas no arquivo /etc/network/in-

terfaces (ver anexo C).

O SVWEB01 conhece apenas a rede DMZ e tem acesso à Internet por ter

o default gateway apontando para o SVFW01, foi necessário adicionar uma rota es-

tática para a LAN, isto foi feito adicionando a seguinte opção no arquivo

/etc/network/interfaces:

58

post-up route add -net 10.0.0.0/8 gw 192.168.0.200

4.3.4.4 SVWEB01: Serviços

Os seguintes serviços foram habilitados e instalados no SVWEB01:

• VSFTP: programa que implementa o serviço de FTP (File Transfer

Protocol), foi instalado utilizando os comandos “apt-get update” (para

atualizar a lista de versões dos programas) e “apt-get install vsftpd”

(para instalar o vsftp).

• APACHE: é o mais utilizado servidor WEB (serviço HTTP) do mundo,

já vem instalado e nada foi alterado em sua configuração padrão.


Estes serviços não tiveram suas configurações padrão alteradas, pois so-

mente foram utilizados nas avaliações de acesso.

59

4.3.5 SVDB01

Servidor de banco de dados. Localizado na DMZ, conforme destacado na

Figura 4-7.

Figura 4-10 Diagrama físico da rede com o SVWEB01 em destaque

4.3.5.1 SVDB01: Sistema operacional

Utilizamos o sistema operacional OpenSolaris 2008.05 (ver Anexo B), sis-

tema da SUN utilizado principalmente por desenvolvedores. O CD de instalação é

um LiveCD32, que oferece a opção de instalar o sistema no disco.

32 LiveCD é um CD ou DVD que contém um sistema operacional que não precisa ser instalado no dis-

co rígido, um exemplo são os DVDs do curso de Tecnologia em Sistemas da Computação do CE-

DERJ.

60

4.3.5.2 SVDB01: Recursos virtuais


• 1024 Mb de memória RAM, sistema utiliza interface gráfica, sem ne-

nhum serviço adicional já consome mais de 512 Mb.

• Definimos um disco virtual com 8 Gb, mas dependendo do tamanho da

base de dados, pode ser necessário mais espaço. Cabe ressaltar que

em um ambiente de produção recomendo um disco exclusivo para o

banco de dados.


• Um processador.


4.3.5.3 SVDB01: Configurações de rede

Este servidor terá apenas uma placa ligada a VMNet1 (DMZ), é identifica-

da pelo sistema operacional como e1000g0 (como pode ser visto na Figura 4-7), ele

tem o IP 192.168.0.30, máscara 255.255.255.0, default gateway 192.168.0.100 e

DNS 192.168.0.10 (SVMAIL01).

Para configurar a rede devemos fazer os seguintes passos:

1. Abrir um terminal e executar o comando “su” para habilitar o acesso

administrativo;

2. Executar “svcadm enable physical:default“ para habilitar a placa de

rede;

3. Executar “svcadm disable physical:nwam” para desabilitar a configura-

ção automática da placa de rede.

61

4. Configurar a placa com o programa “Network” no menu “System->Ad-

ministration”.

O SVDB01 conhece apenas a rede DMZ e tem acesso à Internet por ter o

default gateway apontando para o SVFW01, foi necessário adicionar uma rota estáti-

ca para a LAN, isto foi feito executando o seguinte comando:

route –p add 10.0.0.0 192.168.0.200

4.3.5.4 SVDB01: Serviços

O SVDB01 tem os seguintes serviços:

• MYSQL 5: Serviço gerenciador de banco de dados muito popular, ins-

talado através do programa “Package Manager”, após habilitar o servi-

ço o programa fez o download do MySql e o instalou.

• VNC: Serviço de acesso remoto disponível para várias plataformas, já

vem instalado no OpenSolaris sendo necessária apenas sua habilita-

ção no menu “System -> Preferences -> Remote Desktop”.

62

4.4 SEGURANÇA

Nesta seção veremos como foram configurados os dois firewalls do traba-

lho, que dividi em duas subseções (firewall externo e interno) e em cada uma expla-

narei sobre a função, premissas, uma breve introdução ao software do firewall e, fi-

nalmente, a implantação.

4.4.1 Firewall externo (SVFW01)

O Firewall configurado no SVFW01 é o responsável por controlar o tráfe-

go entre a Internet (ambiente externo) e a DMZ (ambiente interno) e vice-versa, con-

forme destacado na Figura 4-8. Através dele são providos serviços para usuários ex-

ternos (Internet) bem como oferecer uma barreira para impedir acesso a protocolos

não autorizados aos usuários internos.

Figura 4-11 - Diagrama físico da rede com o SVFW01 em destaque

63

4.4.1.1 Premissas (Regras)

As regras criadas no firewall devem atender as seguintes expectativas:

1. Todo o tráfego que tenha origem na Internet é bloqueado, com ex-

ceção aos serviços disponibilizados pela DMZ, através do redirecio-

namento das portas. Os serviços oferecidos serão HTTP, FTP,

SMTP e POP3.

2. Será permitido o tráfego com origem na LAN e com destino para a

Internet dos seguintes protocolos: HTTP, HTTPS e FTP.

3. O servidor SVMAIL poderá consultar servidores de DNS externos e

enviar e-mail para outros servidores SMTP.

4. A estação do administrador localizado na LAN poderá acessar o

servidor SVFW01 via ssh e também poderá utilizar testes que utili-

zem o protocolo ICMP (por exemplo, ping33).

5. Serão guardados, através de um arquivo, todos os acessos nega-

dos e acessos via SSH ao firewall.

33 Ping é um comando usado pelo protocolo ICMP para testar a conectividade entre equipamentos.

64

Na Erro: Origem da referência não encontrada estão listadas as regras

que foram definidas para o SVFW01.

Tabela 5 - Regras do firewall SVFW01

OrigemDestino Redirecionar para

Servidor / Rede Protocolo Porta Servidor IP

INTERNET DMZ TCP

80 (HTTP) SVWEB01 192.168.0.2021 (FTP) SVWEB01 192.168.0.20

25 (SMTP) SVMAIL01 192.168.0.10110 (POP3) SVMAIL01 192.168.0.10

SVMAIL01 INTERNET UDP 53 (DNS)TCP 25 (SMTP)

LAN INTERNET TCP

80 (HTTP)443

(HTTPS)21(FTP)

Estação do Admin DMZ

TCP 22 (SSH)ICMP

4.4.1.2 Software utilizado

O software de firewall utilizado no servidor SVFW01 é o PF (Packet Filter),

oriundo do sistema operacional OpenBSD, é utilizado para fazer NAT e filtragem de

pacotes, desenvolvido por Daniel Hartmeier, e hoje é mantido por ele e a equipe de

desenvolvimento do OpenBSD.

O PF já é instalado automaticamente no FreeBSD sendo necessária ape-

nas sua habilitação no arquivo /etc/rc.conf (ver anexo C).

As configurações do PF são feitas no arquivo /etc/pf.conf, conforme infor-

mado no site do projeto [17]. Este arquivo está dividido em sete partes, listadas na

seqüência:

65

1. Macros: São variáveis definidas pelo usuário, que podem armazenar endere-

ços IP, nomes de interface, etc.

2. Tabelas: Uma estrutura usada para armazenar listas de endereços IP.

3. Opções: Várias opções de controle do funcionamento do PF.

4. Scrub: Reprocessamento de pacotes para normalização34 e desfragmenta-

ção35.

5. Filas: Fornece controle de banda e priorização de pacotes.

6. Tradução: Controla NAT (Tradução do Endereço de Rede) e redirecionamen-

tos dos pacotes.

7. Regras de Filtragem: Permite selecionar pacotes para filtragem ou bloqueá-

los conforme chegam nas interfaces. Quando um pacote é verificado pelo PF

todas as regras são verificadas a última que coincidir com o pacote é a regra

que será aplicada (a exceção é quando a regra contém a opção quick que in-

terrompe imediatamente o processamento do pacote fazendo valer esta últi-

ma que foi processada).

Com exceção das macros e tabelas, cada seção deve aparecer nesta or-

dem no arquivo de configuração, contudo nem todas as seções precisam existir para

determinadas aplicações. Linhas em branco são ignoradas, e linhas iniciadas com o

caractere “#” são tratadas como comentários [17].

O PF oferece o utilitário de linha de comando pfctl, algumas de suas op-

ções podem ser vistas no Anexo C.

34 Normalização de pacotes, é o processo que inspeciona os pacotes para que não haja ambigüida-

des na interpretação pelo destino final do pacote.35 Desfragmentação de pacotes, remontagem de pacotes fragmentados, protege alguns sistemas

operacionais de algumas formas de ataque, e descarta pacotes TCP que possuam combinações de

flag (ou opções) inválidas

66

4.4.1.3 Implantação

A implantação do firewall externo teve os seguintes passos: configuração

da inicialização do sistema operacional, configuração de conexão com a Internet,

configuração do firewall e processo de inicialização do firewall. Veremos agora al-

guns dos detalhes de cada um dos passos.

4.4.1.3.1 Inicialização do sistema operacional

O sistema FreeBSD possui o arquivo /etc/rc.conf, ver no Anexo 3, no qual

são definidas as configurações, tais como as do IP e dos serviços que serão inicia-

dos junto com o sistema operacional. No que diz respeito ao firewall, as configura-

ções mais importantes foram a habilitação na inicialização do PF (pf_enable=”YES”),

do arquivo de Log (pflog_enable=”YES”) e, por fim, do gateway

(gateway_enable=”YES”), que é o serviço que faz o encaminhamento dos pacotes

entre as interfaces [6].

67

4.4.1.3.2 Conexão com a Internet

Existem várias formas de se conectar a Internet: discagem (dialup), links

dedicados, celulares, ADSL, cabo, etc. Neste trabalho utilizai um modem ADSL para

conexão com a Internet através da operadora Oi. Na Figura 4-12 - Diagrama de co-

nexão com a Internet destaco os componentes envolvidos no processo de conexão

com a Internet.

Figura 4-12 - Diagrama de conexão com a Internet

Iniciamos pelas conexões físicas, neste caso o servidor host (SVVM01)

está conectado diretamente ao modem ADSL (marca Thomson modelo ST510v6)

através de sua interface on-board, via um cabo de rede, e o modem se conecta a In-

ternet utilizando uma linha telefônica.

Para iniciar a conexão precisamos configurar um cliente PPP36 no servidor

SVFW01 (que está conectado ao modem, pois está utilizando a interface Vmnet0

como sua porta de saída para o mundo exterior). A configuração é feita no arquivo 36 PPP (Point-to-Point Protocol) é um protocolo para transmissão de pacotes através de linhas seriais.

O protocolo PPP suporta linhas síncronas e assíncronas. Normalmente, ele tem sido utilizado para a

transmissão de pacotes IP na Internet, em seu primeiro “salto”, ou seja, até o roteador de borda.

68

/etc/ppp/ppp.conf (ver anexo C), que contém as informações do usuário, senha e ou-

tras informações técnicas necessárias para acessar o serviço da Oi [19].

Depois de configurado, basta digitar o comando “ppp –b default” em um

terminal do servidor e, se tudo correr bem, será exibida a mensagem “PPP enabled”,

isto significa que o servidor SVFW01 já está conectado a Internet. Durante o proces-

so de conexão é criada uma interface da rede virtual chamada tun0, toda entrada e

saída de dados entre o SVFW01 e a Internet passa por esta interface, que utiliza a

interface em0 de forma trasparente para se comunicar com o modem ADSL.

4.4.1.3.3 Configuração das regras do firewall

As regras do firewall são lidas pelo software PF no arquivo /etc/pf.conf, lis-

tado na Tabela 6, que contém todas as linhas do arquivo. A seguir comento as confi-

gurações feitas no arquivo /etc/pf.conf.

Tabela 6 - Configuração do PF (/etc/pf.conf)

L Código123456789

10111213141516171819202122232425262728

# MACROSext_if = "tun0"int_if = "em1"rede_dmz = $int_if:networkrede_lan = "10.0.0.0/8"est_admin = "10.0.0.10"

client_out = "{ http, https, ftp, ftp-data }"proxy = "127.0.0.1" # ftp proxy IPproxyport = "8021" # ftp proxy portproxy2 = "127.0.0.1"proxyport2 = "2121" icmp_types = { echorep, echoreq, timex, unreach }

web_server = "192.168.0.20"dns_server = "192.168.0.10"ftp_server = "192.168.0.20"pop3_server= "192.168.0.10"smtp_server= "192.168.0.10"

# TABLES

# OPTIONSset loginterface $ext_ifset block-policy returnset skip on lo

69

293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576

# SCRUB - Mata pacotes fragmentados que chegam a interface externa scrub in on $ext_if

# QUEUING

# TRANSLATIONnat-anchor "ftp-proxy/*"rdr-anchor "ftp-proxy/*"

nat on $ext_if from $rede_lan to any -> $ext_ifnat on $ext_if from $rede_dmz to any -> $ext_if

rdr on $ext_if proto tcp from any to $ext_if port www -> $web_server port wwwrdr on $ext_if proto tcp from any to $ext_if port smtp -> $smtp_server port smtprdr on $ext_if proto tcp from any to $ext_if port pop3 -> $pop3_server port pop3

# - Proxy ftprdr pass on $int_if proto tcp from any to any port ftp -> $proxy port $proxyportrdr pass on $ext_if proto tcp from any to any port ftp -> $proxy2 port $proxyport2

# FILTERSblock in logpass out keep state

anchor "ftp-proxy/*"

pass in on $ext_if inet proto tcp from any to $web_server port www flags S/SA synproxy statepass in on $ext_if inet proto tcp from any to $smtp_server port smtp flags S/SA keep statepass in on $ext_if inet proto tcp from any to $pop3_server port pop3 flags S/SA keep statepass in on $ext_if inet proto tcp from any to $ftp_server port ftp flags S/SA keep statepass in on $ext_if inet proto tcp from any to $ftp_server port ftp-data flags S/SA keep state

pass in on $int_if inet proto udp from $dns_server to any port 53pass in quick on $int_if from $rede_dmz to $rede_lan

# - Regras para a estacao do Adminpass in quick on $int_if inet proto icmp from $est_admin to any icmp-type $icmp_typespass in log on $int_if inet proto tcp from $est_admin to any port ssh label "SSH - Admin"

# - Regras de saidas para os clientes da redepass inet proto tcp from $rede_lan to any port $client_outpass inet proto tcp from $pop3_server to any port pop3pass inet proto tcp from $smtp_server to any port smtp

# - Saida do Proxy FTPpass out proto tcp from $proxy to any port 21 keep state

Entre as linhas 1 e 19 temos as “macros”, que são variáveis que nos aju-

dam a simplificar a configuração do arquivo, por exemplo, a macro “est_admin” ar-

mazena o IP da estação do administrador, ela é referenciada duas vezes no código

(mas poderiam ser mais). Se, por ventura, o IP da estação do administrador for alte-

rado precisaríamos alterar apenas o valor desta variável ao invés de procurar em

todo o arquivo os locais onde é feita referência ao IP da estação. Agora descreverei

cada uma das macros:

• ext_if: representa a interface ligada a Internet que é a tun0.

• int_if: é a interface interna que está ligada a DMZ que é a em1.

70

• rede_dmz: utilizando a variável “int_if” com a opção “:network”, recuperamos

para está variável o valor “192.168.0.0/24”, que é o endereço da rede DMZ.

• rede_lan: é o endereço da nossa rede LAN (10.0.0.0/8).

• est_admin: endereço IP da estação utilizada pelo administrador da rede.

• client_out: representa os protocolos que serão permitidos sua saída para In-

ternet com origem na LAN, repare que está macro funciona como um vetor

pois armazena vários valores, sendo http, https, ftp e ftp-data. Para utilizar

uma macro como um vetor deve-se atribuir os valores entre os caracteres “{“

e “}”.

• proxy: é o endereço do proxy FTP que funciona no SVFW01, no caso o en-

dereço 127.0.0.1 que é um endereço utilizado como loopback37.

• proxyport: é a porta do proxy FTP que funciona no SVFW01, no caso a porta

8021.

• proxy2: é o endereço do segundo proxy FTP que funciona no SVFW01, no

caso o endereço 127.0.0.1 que é um endereço utilizado como loopback.

• proxyport2: é a porta do segundo proxy FTP que funciona no SVFW01, no

caso a porta 2121.

• icmp_types: macro que contém os tipos de ICMP que serão permitidos, no

nosso caso: echorep, echoreq, timex e unreach.

• web_server: contém o endereço do servidor HTTP SVWEB01

(192.168.0.20).

• dns_server: contém o endereço do servidor DNS SVMAIL01 (192.168.0.10).

• ftp_server: contém o endereço do servidor de FTP SVWEB01(192.168.0.20).

O servidor de HTTP e FTP são os mesmos, porque não utilizar a mesma ma-

cro? Utilizar macros diferentes para protocolos diferentes que estão no mes-

mo servidor cria flexibilidade na manutenção do firewall, caso no futuro des-

membrarmos o servidor de FTP do servidor HTTP precisaríamos apenas alte-

rar o endereço de uma das macros ao invés de conferir todo o script.

• pop3_server: endereço do servidor de POP3 SVMAIL01 (192.168.0.10).

37 Loopback é um canal de comunicação com apenas um ponto final. Qualquer mensagem transmitida

por meio de tal canal é imediatamente recebida pelo mesmo canal, em redes IP o endereço 127.0.0.1

é utilizado como endereço de loopback segundo a RFC 2606.

71

• smtp_server: endereço do servidor de SMTP SVMAIL01 (192,168.0.10).

Uma observação a ser feita é que para recuperar os valores das macros

deve-se utilizar o caractere “$” antes do nome da macro, como veremos em várias

exemplos a seguir.

Nas linhas 25 a 28 estão as opções do PF, sendo:

• set logininterface: define a interface que o PF recolherá estatísticas (como

por exemplo, quantidade de bytes entrando e saindo), foi definida a interface

externa em0 representada pela macro “$ext_if”.

• set block-policy: a mais interessante, foi configurada como “return”, isto faz

com que certos tipos de pacotes bloqueados retornem ao remetente com

uma mensagem avisando sobre o bloqueio, poderia ter sido configurado

como “block” assim nenhuma mensagem seria enviada, o pacote seria ape-

nas descartado.

• set skip on: define que determinada interface não sofrerá processamentos

por parte do PF, no caso foi definida a “lo” que é o nome da interface de loop-

back, isto significa que pacotes gerados pelo próprio firewall não serão avali-

ados.

Na linha 31 é utilizado o SCRUB na interface externa, representada pela

macro “$ext_if”, isto faz com que os pacotes fragmentados (pacotes fragmentados

podem ser ataques) com origem na Internet sejam descartados.

Na seção intitulada TRANSLATION temos três partes distintas: a configu-

ração do ftp-proxy (linhas 36-37), o NAT (linhas 39-40) e os redirecionamentos (li-

nhas 42 a 49), estas partes estão detalhadas na seqüência:

• Configuração do ftp-proxy: os comandos “nat-anchor “ftp-proxy/*”” e “rdr-an-

chor “ftp-proxy/*””, são âncoras que funcionam como chamadas as regras que

estão fora do arquivo atual, no caso estas duas linhas chamam regras que

72

são utilizadas pelo ftp-proxy (que controlam estados de conexões do ftp-

proxy), por exemplo.

• NAT: faz com que os computadores da LAN e DMZ possam acessar a Inter-

net utilizando o IP público do servidor SVFW01. Na linha 39 é feito o NAT

para a rede LAN e na 40 para a rede DMZ.

• Redirecionamentos: faz praticamente o inverso do NAT, eles possibilitam

aos usuários externos (que estão em casa, em outra empresa, ou seja, em

um lugar qualquer da Internet) o acesso aos servidores da DMZ, mesmo que

estes (servidores da DMZ) não tenham IP público. Na linha 57 podemos des-

crever o comando como sendo: redirecione o tráfego da interface externa (“rdr

on $ext_if) se o protocolo for o tcp (“proto tcp”) vindo de qualquer lugar (“from

any”) para a porta 80 (“port www”) então redirecione para (“->”) o endereço do

servidor web (“web_server”) na porta 80 (“port www”). O mesmo raciocínio é

utilizado para nas linhas 58 e 59 para os protocolos SMTP e POP3 sendo re-

direcionados para seus devidos servidores na DMZ. Nas linhas 47 e 48 são

feitos redirecionamentos dos proxy-ftp, o da linha 47 redireciona o tráfego de

saída (é, o tráfego dos computadores da LAN que estão acessando servido-

res FTP que estão na Internet) para o serviço de proxy-ftp que está ativo na

porta 8021 (macro $proxyport), já a linha 48 redireciona o tráfego de entrada

(usuários da Internet acessando nosso FTP localizado na DMZ) para o segun-

do ftp-proxy que está ativo na porta 2121 (macro $proxyport2).

Da linha 51 em diante temos a seção “FILTERS” que diz respeito às auto-

rizações, ou seja, que tipo de pacotes podem entrar ou sair pelas interfaces do

SVFW01. No PF a última regra tem precedência sobre a primeira, ou seja, se duas

regras se contradizerem a regra que estiver por último vai prevalecer (exceto se a

primeira estiver com a opção quick, que faz com que ela regra seja comparada e se

for positiva não passa adiante).

73

Primeiro são definidos os comportamentos padrões de entrada e saída,

sendo:

• Padrão de entrada: no caso foi definido na linha 52 bloquear o que estiver en-

trando (“block in log”, a opção log faz com que sempre que esta regra seja uti -

lizada gere um log38)

• Padrão de saída: na linha 53 permiti o que estiver saindo (“pass out keep sta-

te”), a opção keep state serve para guardar o estado da conexão, é importan-

te manter o estado de uma conexão que sai pelo firewall porque, normalmen-

te, esta conexão terá um retorno e caso o firewall identifique que o pacote que

está tentando entrar veio porque foi requisitado de dentro ele deixará o pacote

entrar, isto só é possível porque o PF é um firewall stateful39.

.

Na linha 55 novamente devemos evocar a ancora do ftp-proxy para adici-

onar nesta seção de filtros as opções requeridas pelo ftp-proxy.

Entre as linhas 57 e 61 estão às liberações para que os pacotes vindos da

Internet possam chegar aos servidores da DMZ. Evidentemente, apenas as portas

que foram redirecionadas na seção TRANSLATION estão liberadas.

A linha 57 pode ser traduzida como: liberação para acesso (“pass”) de en-

trada (“in”) pela interface externa (“on $ext_if”) sendo o protocolo tcp ( “inet proto

tcp”) a partir de qualquer lugar ( “from any”) com destino ao servidor

SVWEB01(“$web_server”) pela porta 80 (“port www”). As linhas 58 a 61 utilizam o

mesmo raciocínio para os protocolos SMTP, POP3, FTP e FTP-DATA.

38 Log são eventos importantes que são guardados em arquivos ou banco de dados para posterior

análise ou evidência de modificações no sistema. Por exemplo no sistema operacional Windows é ge-

rado um Log quando o usuário ou um sistema pára ou inicia ou service, o log contém o nome do ser-

vice, hora que ocorreu a alteração e o nome do usuário que executou a ação.39 Stateful inspection é a habilidate do PF em registrar o estado, ou progresso de uma conexão de

rede. Armazenando informações sobre o estado de cada conexão numa tabela, o PF pode rapida-

mente determinar se um pacote passando pelo firewall pertence a uma conexão já estabelecida.

Caso afirmativo, ele passa direto pelo firewall sem ser avaliado pelas regras

74

Na linha 63 temos a liberação para que o servidor SVMAIL01 possa con-

sultar outros servidores de DNS, que estejam na Internet, lendo o comando temos:

permita (“pass in”) na interface interna (“on $int_if”) sendo o protocolo udp (udp) vin-

do do servidor SVMAIL01 (“from $dns_server”) para qualquer servidor (“to any”) pela

porta 53 (“port 53”).

A linha 64 permite todo o tráfego da interface interna(“$int_if”) vindos da

DMZ (“$rede_dmz”) para a rede LAN (“$rede_lan”).

As linhas 67 e 68, liberam os testes de conectividade (ping, por exemplo)

e acesso remoto (SSH) a partir da estação do administrador (é gerado um Log deste

acesso).

Na linha 71 temos a liberação para as portas listadas na macro

“$client_out” ( HTTP, HTTPS, FTP e FTP-data), isto para acessos a partir da LAN

(“$rede_lan”).

Nas linhas 72 e 73 são liberados os acessos para os protocolos POP3 e

SMTP a partir de qualquer lugar.

Por fim é liberada a saída do ftp-proxy na linha 76. A liberação do FTP foi

a parte que causou maior transtorno. O serviço de FTP não funciona de uma forma

trivial como o HTTP, o POP3 e o SMTP, estes protocolos são acessados através de

uma única porta (80 para o http, 110 para o POP3 e 25 para o SMTP), já o FTP utili -

za a 20, 21 e depois escolhe uma porta aleatoriamente, desde que acima de 1024,

para onde são enviados os arquivos durante a transferência. Abrir todas as portas

acima de 1024 pode causar problemas, pois se pode dar acesso indevido a algum

outro sistema que utilize estas portas. Para contornar esta situação utiliza-se um sis-

tema de proxy40 (no nosso caso é um software chamado ftp-proxy), ao invés do ser-

vidor mandar o arquivo para uma porta alta de um cliente ele enviará para o proxy e

este enviará para o cliente. Na linha 76 é feita à liberação da porta 21 para o endere-

40 Proxy é um tipo de servidor que atende a requisições repassando os dados a outros servidores. O

termo proxy, a propósito, vem do inglês e pode ser traduzido como "procurador". O usuário conecta-

se a um servidor proxy, requisitando algum serviço, como um arquivo, conexão, website, ou outro re-

curso disponível em outro servidor.

75

ço do proxy e este mantém as conexões (keep state) para que, caso receba uma re-

quisição a uma porta alta, ele consiga relacionar com a conexão criada anteriormen-

te.

4.4.1.3.4 Inicialização do firewall

Para que o firewall fosse ativado foi feito o seguinte procedimento:

1. Inicialização do servidor: neste ponto é carregado o arquivo /etc/rc.conf e ini-

ciado o PF.

2. Conectar a Internet: com o comando “ppp –b default”.

3. Iniciar uma segunda instância do ftp-proxy: Executado o comando

“/usr/sbin/ftp-proxy –R 192.168.0.20 –p 2121”, este faz com que um processo

do ftp-proxy fique “escutando na porta 2121 (poderia se qualquer outra porta,

mas escolhi 2121, pois lembra a porta do ftp que é a 21) e redireciona as re-

quisições para o servidor 192.168.0.20 (SVWEB01)”.

4. Recarregar regras do firewall: com o comando “pfctl –ef /etc/pf.conf”.

76

4.4.2 Firewall interno (SVFW02)

O firewall configurado no SVFW02 é o responsável por controlar o tráfego

entre a rede local (LAN) e a DMZ (as duas redes são internas), conforme destacado

na Figura 4-13. Ele não executa o serviço NAT, pois fará apenas bloqueio de portas,

não sendo necessário qualquer tipo de tradução de endereços.


4.4.2.1 Premissas (Regras)

As regras que foram criadas no firewall interno devem atender as seguin-

tes expectativas:

1. Todo tráfego de entrada é bloqueado, com exceção das regras a

seguir.

77

2. O firewall permitirá a passagem dos protocolos HTTP, HTTPS e

FTP com origem na LAN para qualquer destino.

3. As portas 80 (HTTP), 110 (POP3), 25 (SMTP) e 3306 (MySQL) se-

rão liberadas para pacotes com origem na LAN e destino aos res-

pectivos servidores da DMZ que suportam os serviços que utilizam

estas portas.

4. As portas 22 (SSH), 3389 (RDP), 5800 (VNC-WEB), 5900 (VNC) e

o protocolo ICMP serão liberados para pacotes com origem na esta-

ção do administrador com destino a servidores da DMZ.

5. O firewall terá a porta 22 (SSH) aberta para pacotes com origem na

estação do administrador.

6. O protocolo ICMP será aberto para pacotes com origem na estação

do administrador para testes de conectividade (ping).

Na Erro: Origem da referência não encontrada estão listadas as regras do

SVFW02.


Origem DestinoServidor / Rede Protocolo Porta

LAN

DMZ

INTERNET

TCP 80 (http)TCP 443 (https)TCP 21 (ftp)

SVMAIL01TCP 53 (dns)TCP 25 (smtp)TCP 110 (pop3)

SVDB01 TCP 3306 (mysql)

Estação do Admin

SVFW02TCP 22 (ssh)ICMP

DMZ

TCP 22 (ssh)TCP 3389 (rdp)TCP 5800 (vnc-web)TCP 5900 (vnc)ICMP

78

4.4.2.2 Software utilizado

O software do firewall utilizado no servidor SVFW02 é o iptables [13] que

é uma ferramenta para configuração do módulo NETFILTER [14], responsável pela

implementação do firewall no nível do kernel.

O iptables está presente em todas as distribuições modernas do Linux,

sendo necessário, conforme o caso, apenas de sua habilitação, que foi o caso.

O iptables não tem um arquivo de configuração como o PF, normalmente

o administrador cria um script41 que limpa a configuração e adiciona todas as regras.

Farei uma breve explicação sobre a sintaxe para inserção de regras:

iptables -t TABELA -A CADEIA REGRAS -j ALVO

Descrevendo cada uma das opções:

• TABELA: o iptables funciona com quatro tabelas: raw (faz alterações

de baixo nível nos pacotes), filter (filtro de pacotes), Nat (tradução de

endereços) e mangle (alterações específicas). Neste trabalho utilizei

apenas as opções de filter, pois é a única função utilizada neste fi-

rewall, isto é, filtrar pacotes. Filter é a tabela padrão, caso não for in-

formada a tabela a filter será utilizada.

• CADEIA: é o tipo de tráfego, podem ser: OUTPUT (saída com origem

no firewall), INPUT (entrada com destino o firewall), FORWARD (pas-

sa pelo firewall), PREROUTING (todo tráfego que "sai" da máquina, in-

cluindo o gerado localmente com destino local), POSTROUTING (trá-

fego que sai, inclusive o gerado localmente com destino local).

41 Scripts são arquivos do tipo texto, que contém linhas de comandos. No Unix/Linux são conhecidos

como Shell script e no Windows são conhecidos como arquivos em lote.

79

• REGRAS: são os parâmetros que serão comparados com o pacote

como IP, porta, protocolo e interface. As regras podem ser simples

como comparar apenas o IP de origem como também podem fazer di-

versas comparações, como por exemplo, o pacote tem que ser de um

determinado IP com destino a determinado IP e a determinada porta.

• ALVO: é a ação que será tomada caso o pacote se enquadre nas re-

gras, pode ser ACCEPT (aceita o pacote), DROP (descarta o pacote e

não avisa a origem), REJECT (descarta o pacote mas avisa a origem),

LOG (gravam em arquivo dados sobre o pacote).

Quando houver um impasse entre as regras, por exemplo, é inserida uma

regra que libera a porta 80 e depois outra regra que bloqueia a porta 80, valerá a

que foi incluída em primeiro lugar.

Uma listagem contendo os principais comandos do iptables pode ser en-

contrada no Anexo C.

4.4.2.3 Implantação

O firewall interno é bem mais simples que o externo, pois não é conecta-

do a Internet, evitando os passos de discagem para a Internet. A implantação do fi-

rewall interno teve os seguintes passos: habilitação do iptables, habilitação do ga-

teway e configuração do firewall. Veremos alguns detalhes de cada um dos passos.

80

4.4.2.3.1 Habilitação do iptables

Para habilitar o serviço do iptables durante a inicialização do sistema o

CentOS oferece o utilitário designado ntsysv, que contém uma lista dos serviços ins-

talados no sistema, é necessário apenas marcar a opção “iptables”.

4.4.2.3.2 Habilitação do gateway

Para habilitar o gateway foi necessário editar o arquivo /etc/sysctl.conf e

configurar a opção “net.ipv4.ip_forward” com o valor 1 [5].

4.4.2.3.3 Configuração do firewall

Para a configuração do firewall foi criado o arquivo /etc/rc.d/init.d/myfi-

rewall, cuja listagem é apresentada na Tabela 8, que inclui as regras para o seu fun-

cionamento. O conteúdo deste arquivo substitui todas as configurações do iptables

pelas nossas regras e, ao final, este conteúdo é salvo [12]. O iptables mantém suas

configurações no arquivo /etc/sysconfig/iptables, não há necessidade de executar

este script toda vez que o sistema é inicializado, pois o iptables lê as regras do seu

arquivo de configuração, sua execução só é necessária quando forem incluídas no-

vas regras, pois assim ele limpa todas as regras e adiciona as novas. A seguir farei

comentários sobre o conteúdo do arquivo myfirewall.

81

Tabela 8 - Configuração do iptables (/etc/rc.d/init.d/myfirewall)

L Código123456789

10111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970

#!/bin/bash# # /etc/rc.d/init.d/myfirewall

# Flush all current rules from iptablewiptables -F

modprobe ip_conntrackmodprobe ip_conntrack_ftp

# VARIAVEISEST_ADMIN_IP="10.0.0.10"SRV_DNS_IP="192.168.0.10"SRV_HTTP_IP="192.168.0.20"SRV_FTP_IP="192.168.0.20"SRV_SMTP_IP="192.168.0.10"SRV_POP3_IP="192.168.0.10"SRV_MYSQL_IP="192.168.0.30"LAN_IP_RANGE="10.0.0.0/8"IF_LAN="eth1"IF_DMZ="eth0"

# Set default policies for INPUT, FORWARD and OUTPUT chainsiptables -P INPUT DROPiptables -P FORWARD DROPiptables -P OUTPUT ACCEPT

# Set access for localhostiptables -A INPUT -i lo -j ACCEPT

# Aceitar pacotes com conexoes ja estabelecidasiptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTiptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# ################################################################## Liberar acessos para a estacao de Administracao # (mantendo log de acessos)## ################################################################# - Acesso Remoto ao Firewalliptables -A INPUT -p tcp -s $EST_ADMIN_IP --dport 22 -j LOG --log-prefix "ADMIN - SSH"iptables -A INPUT -p tcp ! -s $EST_ADMIN_IP --dport 22 -j LOG --log-prefix "NEGADO - SSH"iptables -A INPUT -p tcp -s $EST_ADMIN_IP --dport 22 -j ACCEPT

# - Acesso Remoto (ssh,rdp,vnc) aos Servidores da DMZiptables -A FORWARD -p tcp -s $EST_ADMIN_IP --dport 22 -j LOG --log-prefix "ADMIN - SSH "iptables -A FORWARD -p tcp ! -s $EST_ADMIN_IP --dport 22 -j LOG --log-prefix "NEGADO - SSH "iptables -A FORWARD -p tcp -s $EST_ADMIN_IP --dport 22 -j ACCEPT

iptables -A FORWARD -p tcp -s $EST_ADMIN_IP --dport 3389 -j LOG --log-prefix "ADMIN - RDP "iptables -A FORWARD -p tcp ! -s $EST_ADMIN_IP --dport 3389 -j LOG --log-prefix "NEGADO -RDP "iptables -A FORWARD -p tcp -s $EST_ADMIN_IP --dport 3389 -j ACCEPT

iptables -A FORWARD -p tcp -s $EST_ADMIN_IP --dport 5800 -j LOG --log-prefix "ADMIN-VNCWEB"iptables -A FORWARD -p tcp ! -s $EST_ADMIN_IP --dport 5800 -j LOG--log-prefix"NEGADO-VNCWEB"iptables -A FORWARD -p tcp -s $EST_ADMIN_IP --dport 5800 -j ACCEPT

iptables -A FORWARD -p tcp -s $EST_ADMIN_IP --dport 5900 -j LOG --log-prefix "ADMIN - VNC "iptables -A FORWARD -p tcp ! -s $EST_ADMIN_IP --dport 5900 -j LOG --log-prefix "NEGADO- VNC "iptables -A FORWARD -p tcp -s $EST_ADMIN_IP --dport 5900 -j ACCEPT

# - Permitir Ping ao Firewall e a Servidores da DMZ iptables -A INPUT -p icmp -s $EST_ADMIN_IP --j ACCEPTiptables -A FORWARD -p icmp -s $EST_ADMIN_IP --j ACCEPT

# #######################################################

82

7172737475767778798081828384858687888990919293

949596979899

100101102103104105106107108109

## Liberar portas Rede Interna -> DMZ## ######################################################## - DNSiptables -A FORWARD -p udp -s $LAN_IP_RANGE -d $SRV_DNS_IP --dport 53 -j ACCEPT

# - SMTP (E-mail)iptables -A FORWARD -p tcp -s $LAN_IP_RANGE -d $SRV_SMTP_IP --dport 25 -j ACCEPT

# - POP (E-mail)iptables -A FORWARD -p tcp -s $LAN_IP_RANGE -d $SRV_POP3_IP --dport 110 -j ACCEPT

# - HTTP (Paginas WEB)iptables -A FORWARD -p tcp -s $LAN_IP_RANGE -d $SRV_HTTP_IP --dport 80 -j ACCEPT

# - FTPiptables -A FORWARD -p tcp --dport 21 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPTiptables -A FORWARD -p tcp --sport 21 -m state --state ESTABLISHED,RELATED -j ACCEPTiptables -A FORWARD -p tcp --sport 20:21 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPTiptables -A FORWARD -p tcp --dport 20:21 -m state --state ESTABLISHED -j ACCEPTiptables -A FORWARD -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPTiptables -A FORWARD -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT

# - MySQLiptables -A FORWARD -p tcp -s $LAN_IP_RANGE -d $SRV_MYSQL_IP --dport 3306 -j ACCEPT

# ###################################################### Liberar Porta para acessar internet## ####################################################iptables -A FORWARD -p tcp -s $LAN_IP_RANGE --dport 80 -j ACCEPTiptables -A FORWARD -p tcp -s $LAN_IP_RANGE --dport 443 -j ACCEPT

# Save Settings/sbin/service iptables save

Na linha 6 é feito um flush nas regras, isto é, as regras são todas excluí-

das.

Nas linhas 8 e 9 são habilitados os módulos que dão suporte ao Connecti-

on Tracking42 [10].

Entre as linhas 11 e 21, são definidas variáveis que simplificam a reconfi-

guração do arquivo, por exemplo, a variável “EST_ADMIN_IP” é utilizada várias ve-

zes no arquivo, caso o IP da estação do administrador mude basta alterar somente a

variável ao invés de localizar o IP por todo o texto.

Nas linhas 24,25 e 26 são definidos os comportamentos padrão, no caso

foram negados (DROP) para os pacotes que entram (INPUT) ou que atravessam o

42 Connection Tracking é um módulo do Linux utilizado para acompanhar estas conexões "ajudando"

o IPTABLES a saber que um determinado pacote é relacionado a uma conexão já existente.

83

firewall (FORWARD) e permitidos (ACCEPT) os pacotes que estão saindo (OUT-

PUT) do firewall.

Na linha 29 é concedia permissão para pacotes gerados pelo próprio fi-

rewall, isto é, pela interface de loopback.

Nas linhas 32 e 33 é permita a passagem de pacotes que já tem uma co-

nexão estabelecida. Este tipo de regra contribui com a velocidade de processamento

do firewall, pois quanto ao processamento das regras, o iptables funciona de forma

diferente a do PF. O PF analisa todas as regras e utiliza a última, que coincida com

o pacote, já o iptables utiliza a primeira regra que ele encontra e coincide com o pa-

cote. Para exemplificar esta questão, imagine que já tenha sido estabelecida uma

conexão com a porta 80 e que esta regra é a ultima conferida pelo iptables, da próxi-

ma vez que o iptables for validar uma regra para esta mesma conexão ele não terá

que conferir todas as regras até chegar à última, ele vai utilizar as regras para a co-

nexão já estabelecida (as primeiras no nosso caso) agilizando a liberação do pacote.

Entre as linhas 36 e 58 estão as regras que permitem acesso diferenciado

para a estação do administrador, repare que para cada porta existe um bloco de 3 li-

nhas, analisemos as linhas 43 a 45 que liberam o acesso ao SSH:

• Linha 43: a linha 43 gera um Log caso seja um acesso feito a partir

da estação do administrador, o início do Log terá o texto “Admin –

SSH”.

• Linha 44: gera um Log caso o acesso não venha da estação do

administrador e insere o texto “Negado – SSH”.

• Linha 45: faz a liberação de acesso caso o acesso venha da esta-

ção do administrador.

Repare que diferente do PF o iptables não libera e gera log ao mesmo

tempo, primeiro é gerado o Log e depois feita a liberação, quando a linha com a re-

gra de Log coincide com o pacote analisado o log é gerado e depois segue para ou-

tras regras, se colocasse a regra que libera a porta antes da linha que gera o log en-

84

tão o log não seria gerado, pois quando coincide o pacote com a regra de liberação

então é feita a liberação e não continua nas próximas regras.

Uma exceção aos blocos citados acima são as linhas 66 e 67 que liberam

testes de conectividade a partir da estação do administrador, não são gerados logs

para estas regras porque são simples testes de conectividade (ping por exemplo).

Nas linhas 70 a 97 são feitas às liberações de portas que passarão da

rede LAN para a DMZ, novamente o FTP foi um pouco mais trabalhoso (linhas 87 a

93) [10]. Cada liberação permite uma porta somente para o servidor da DMZ que

possui a porta em funcionamento, assim a porta 80 (HTTP) é liberada para o servi-

dor SVWEB01, a porta 53 (DNS) para o SVMAIL01, e assim por diante, com exce-

ção do FTP que foi configurado para permitir a passagem a todos os servidores in-

clusive servidores da Internet. No caso de servidores que estejam na Internet a re-

quisição ainda terá que passar pelo crivo do firewall do SVFW01 que é a nossa porta

de saída para a Internet.

Entre as linhas 100 a 106 estão os protocolos que terão acesso a Internet

a partir da LAN, que são os protocolos HTTP, HTTPS e o FTP.

Por fim a linha 109 que salva as configurações.

85

5 EXPERIMENTOS

Neste capítulo valido e evidencio que as premissas propostas para os fi-

rewalls foram implementadas com sucesso. Dividi este capítulo em três seções sen-

do:

• 5.1) Regras do SVFW01: onde fiz avaliações das regras implemen-

tadas neste firewall, isto é, se está definido nas regras que a porta

HTTP está liberada então verifiquei se esta porta está realmente li-

berada.

• 5.2) Regras do SVFW02: avaliações das regras, como na anterior,

mas voltadas para as regras do firewall SVFW02.

• 5.3) Portscans: neste caso avalio tanto o SVFW01 como o

SVFW02. Se nos experimentos anteriores tive um alvo bem definido

neste avalio todas as portas TCP sem distinção, verificando se cada

uma está aberta ou fechada.

Para avaliação das regras utilizei ferramentas de conectividade como ping

ou clientes dos serviços avaliados como, por exemplo, o Internet Explorer para o

HTTP e o MySQL Administrator para o MySQL. No caso do portscan foi utilizada

uma ferramenta especializada o NMAP.

Todas as avaliações levaram em conta a origem do experimento, pois as

regras implementadas nos firewalls levam em conta a origem.

Para cada experimento também foram recolhidas evidências, que no caso

foram às telas das ferramentas, com informações de sucesso ou fracasso de cada

um dos experimentos. A captura das telas foi feita através da tecla Print Screen, que

captura para a memória a imagem da tela do computador, em seguida “colei” as

86

imagens capturadas na ferramenta MSPaint e as editei, com o objetivo de destacar

os pontos de interesse e sinalizar as transições entre os passos dos experimentos,

obviamente quanto isto for relevante.

Quanto à montagem física para os experimentos utilizei os seguintes

equipamentos, ilustrados na Figura 5-1:

• Modem ADSL Thomson ST510v6: através do qual nos conectamos a Internet.

Ele tem sua interface WAN conectada à linha telefônica e uma interface de

LAN conectada a placa on-board do servidor SVVM01. Esta interface é utiliza-

da pelo servidor virtual SVFW01.

• Servidor SVVM01: é principal componente do trabalho, é o servidor onde está

instalado o VMWARE e abriga as cinco máquinas virtuais. Esta máquina pos-

sui uma interface de rede on-board, conectada ao modem ADSL, e uma inter-

face off-board, conectada ao hub que suporta a LAN.

• Hub 10BASE-T 8 portas Intel: é através dele que os computadores da LAN se

conectam ao SVVM01, que neste caso o SVFW02 que é quem realmente faz

uso da interface. Sem este dispositivo só teria como ligar um computador no

SVVM01 (ponto a ponto), com ele pude ligar até oito computadores, pois ele

possui oito portas. Destas oito portas utilizei três, sendo uma para o SVVM01,

uma para a estação do administrador e uma para a estação normal.

• Estação do administrador: computador configurado com o IP 10.0.0.10, os fi-

rewalls possuem regras mais flexíveis para este computador, pois é através

dele que o administrador do ambiente monitora e configura os firewalls. Foi li-

gado à LAN através de sua interface de rede ligada ao hub.

• Estação normal: representa um micro qualquer ligado a LAN. Configurado

com o IP 10.0.0.101, foi um número escolhido aleatoriamente, poderia ser

qualquer um na faixa entre 10.0.0.1 e 10.0.0.255, exceto os números 10.0.0.1

(utilizado pelo SVFW02) e 10.0.0.10 (utilizado pela estação do administrador).

• Computador Remoto: Computador com acesso Internet localizado em outra

residência.

87

A Erro: Origem da referência não encontradaErro: Origem da referência não

encontrada nos apresenta uma visão geral da montagem física do ambiente.

Figura 5-14 - Visão geral da montagem física do experimento

5.1 REGRAS DO SVFW01

Nesta seção vamos validar as premissas propostas para o SVFW01, que

foram listadas na Tabela 9. Dividi as seções com base na origem do acesso (Inter-

net, SVMAIL01, LAN e estação do administrador) e avaliei os serviços necessários a

cada uma das origens.

88


OrigemDestino Redirecionar para

Servidor / Rede Protocolo Porta Servidor IP

INTERNET DMZ TCP

80 (HTTP) SVWEB01 192.168.0.2021 (FTP) SVWEB01 192.168.0.20

25 (SMTP) SVMAIL01 192.168.0.10110 (pop3) SVMAIL01 192.168.0.10

SVMAIL01 INTERNET UDP 53 (DNS)TCP 25 (SMTP)

LAN INTERNET TCP

80 (HTTP)443

(HTTPS)21(FTP)

Estação do Admin DMZ

TCP 22 (SSH)ICMP

5.1.1 Origem na Internet e com destino para os serviços localizados na DMZ

Primeiramente, avalio com a origem das requisições na Internet (ver Figu-

ra 5-15). A partir de um outro local, utilizando um computador com Windows XP e

com acesso a Internet via Velox, acessei os serviços de HTTP, FTP, SMTP e POP3.

A partir deste ponto utilizarei o termo “computador remoto” quando estiver me refe-

rindo a este computador.

Os experimentos consistem em tentar acessar os serviços utilizando o IP

válido, atribuído à conexão ADSL no SVFW01, com o software correspondente a tal

serviço ou fazendo apenas um teste de conectividade com a ferramenta “telnet”.

O serviço do Velox atribui o endereço IP dinamicamente aos seus usuári-

os, isso significa que cada vez que o usuário iniciar uma conexão com o Velox ele

recebe, possivelmente, um IP diferente ao da última conexão. Desta forma, para sa-

89

ber qual o IP deveríamos utilizar para acessar os serviços da nossa DMZ, executei o

comando “ifconfig” no servidor SVFW01, que é o servidor que se conecta ao Velox e

verificamos qual o IP foi atribuído à interface virtual. Durante os experimentos o IP

foi o 189.105.8.42.

Figura 5-15 Origem Internet (área verde) com destino a DMZ

Foram requeridas liberações para as portas HTTP (80) e FTP (21), que

foram redirecionandas para SVWEB01, 25 (SMTP) e 110 (POP3), que por sua vez

foram redirecionandas para SVMAIL01. Na seqüência apresento as evidências dos

experimentos realizados para cada serviço.

5.1.1.1 HTTP redirecionando para SVWEB01

A partir do computador remoto abri o browser, que no caso utilizei o Inter-

net Explorer da Microsoft, e digitei o IP válido atribuído ao ambiente. O resultado foi

abertura da página de testes do Apache, que foi instalado no servidor SVWEB01, in-

dicando que o acesso funcionou corretamente, conforme ilustrado na Figura 5-16.

90

Figura 5-16 - Evidência de acesso HTTP

5.1.1.2 FTP redirecionando para SVWEB01

Para verificar o funcionamento da regra que redireciona o tráfego de FTP,

com origem na Internet com destino ao servidor SVWEB01, executei a partir do com-

putador remoto um prompt de comandos e utilizei o programa cliente “FTP”. Na Fi-

gura 5-17 são demonstrados os comandos que foram executados para avaliar o fun-

cionamento do serviço FTP, que seguiram os passos:

1. Conectando: Início da conexão com o nosso FTP (ftp

189.105.8.42).

2. Autenticação: foram solicitados usuário e senha do qual obtivemos

como retorno a mensagem “230 Login successful”, indicando que

já estávamos conectados e devidamente autenticados.

3. Um comando para confirmar o estabelecimento da conexão: efetu-

ado o comando “ls”, que lista os arquivos do diretório atual do FTP,

este retornou apenas o arquivo cederj.txt, conforme esperado.

4. Final da conexão: foi enviado o comando “quit” para encerrar a co-

nexão.

91

Figura 5-17 - Evidência de acesso FTP

5.1.1.3 SMTP redirecionando para SVMAIL01

Com o objetivo de avaliar o funcionamento do redirecionamento da porta

de SMTP no SVFW01 para o servidor SVMAIL01, não utilizei um cliente próprio para

este serviço (que seria um Outlook, Eudora ou Thunderbird), apenas fiz uma avalia-

ção simples de conectividade, pois não implementei uma infra-estrutura de e-mail

apenas instalei o serviço.

A partir do computador remoto abri um prompt de comando e executei o

comando “telnet 189.105.8.42 25”, isto faz com que o telnet tente conexão com o IP

189.105.8.42 na porta 25 (SMTP).

Conforme apresentado na Figura 5-18, este experimento foi bem sucedi-

do na abertura da conexão com o servidor. Isto é indicado pela mensagem “220 ce-

derj.tcc ESMTP Server ready.”, então executei o comando “quit” para encerrar a co-

nexão.

92

Figura 5-18 - Evidência de acesso SMTP

5.1.1.4 POP3 redirecionando para SVMAIL01

Neste experimento avalio o redirecionamento do POP3 do tráfego a partir

da Internet para o computador SVMAIL01. Para o serviço de POP3 também não utili-

zei um cliente próprio para este serviço, pelos mesmos motivos do SMTP.

A partir computador remoto abri um prompt de comandos e executei o co-

mando “telnet 189.105.8.42 110”. Isto faz com que o telnet tente abrir uma conexão

com o IP 189.105.8.42 na porta 110 (POP3).

Como mostrado na Figura 5-19, obtive sucesso na abertura da conexão

com o servidor indicado pela mensagem "+OK ([email protected]), POP3

server ready.".

93

Figura 5-19 - Evidência de acesso POP3

5.1.1.5 Acessos bloqueados

Apenas para complementar estas avaliações, também, efetuei experimen-

tos para verificar se o que não deveria ser liberado estava realmente bloqueado.

Com este objetivo executei a ferramenta telnet com destino ao nosso IP válido para

as portas 443 (HTTPS), 20 (FTP-data), 22 (SSH) e 3306 (MySQL). O resultado foi o

esperado, ou seja, não consegui abrir conexões para estas portas evidenciando o

bloqueio (mensagem “Connect failed.”), este procedimento se encontra na Figura 5-

7.

94

Figura 5-20 - Evidências de bloqueio (Internet para DMZ)

5.1.2 Origem SVMAIL01 com destino à Internet

O servidor SVMAIL01 necessita de acesso à Internet para fazer consultas

ao DNS e para o envio dos e-mails (SMTP). A Figura 5-21 mostra, destacado em

verde, a localização da origem dos experimentos e com destino à Internet. O

SVFW01 está no meio do caminho do acesso e nele foram configuradas as regras

que permitem a passagem dos pacotes.

Figura 5-21 Origem SVMAIL01 (área verde) com destino a Internet

95

5.1.2.1 DNS

No SVMAIL01 existe o serviço de DNS instalado. Quando algum compu-

tador desta rede o consulta sobre algum nome, este serviço verifica em sua lista

para localizar o registro, caso ele exista. Neste caso ele possui o registro de todos

os servidores envolvidos neste trabalho, mas caso ele receba uma consulta sobre

um nome que ele não encontre em sua lista então ele pergunta a algum outro DNS.

Ele foi configurado para utilizar o servidor 200.184.26.3 para o ajudar nestes casos.

Este servidor está na Internet e por isso liberei a porta 53 com destino a Internet,

apenas para este servidor.

Executei dois experimentos com o objetivo de avaliar o funcionamento da

liberação da porta 53, primeiro desabilitei a regra no SVFW01, que permite a passa-

gem de pacotes DNS (“pass in on $int_if inet proto udp from $dns_server to any port

53” no arquivo /etc/pf.conf), apenas para visualizar o erro de tentativa de acesso

(destacado em vermelho na Figura 5-22). Repare que utilizei o comando “nslookup

www.cederj.edu.br”. A ferramenta “nslookup” tenta resolver o IP do endereço www.-

cederj.edu.br e recebi um erro de “request timed out.”, o tempo esgotou porque a re-

quisição não chegou ao servidor (foi bloqueado pelo SVFW01).

Depois reabilitar a regra e tentamos novamente, desta vez o servidor retor-

nou o endereço IP relativo ao www.cederj.edu.br: 200.156.70.10 (destacado em ver-

de na Figura 5-22) evidenciando o funcionamento da liberação.

96

Figura 5-22 Evidência de acesso DNS

5.1.2.2 Envio de mensagens (SMTP)

A partir do SVMAIL01 avaliei a conexão com algum servidor SMTP exter-

no ao ambiente, no caso utilizei o servidor smtp.mail.yahoo.com.br.

Com o objetivo de efetuar uma conexão a um servidor de SMTP externo

digitei o comando “telnet smtp.mail.yahoo.com.br 25” (conectar ao host smtp.mail.ya-

hoo.com.br na porta 25), como resultado recebi uma mensagem de sucesso “220

smtp128.mail.mud.yahoo.com ESMTP” (conforme pode ser visto na Figura 5-23).

Caso a conexão não fosse bem sucedida teria recebido uma mensagem de “Con-

nect Failed”. No final apenas digitei “quit” para encerrar a conexão.

97

Figura 5-23 - Evidência de acesso SMTP

5.1.3 Origem na LAN com destino à Internet

Para validar esta parte acabei também por validar parte das regras do

SVFW02, pois para chegar a Internet os pacotes oriundos da LAN tem que passar

pelos dois firewalls, como pode ser visto na Figura 5-24.

98

Conforme a Tabela 9 a LAN deve ter acesso aos protocolos HTTP (80),

HTTPS (443) e FTP (21).

Figura 5-24 Origem LAN (área verde) com destino a Internet

5.1.3.1 HTTP

Com o objetivo de avaliar conexões entre a LAN e sites HTTP, localizados

na Internet, utilizei o browser Firefox e acessei o site www.meuip.com.br. O site foi

acessado normalmente conforme a Figura 5-25. Escolhi este site porque ele nos

mostra um fato importante, o IP que utilizei para acessar a Internet. O computador

que utilizei para acessar a Internet está localizado na LAN e possui IP privado

10.0.0.101, quando tentei acessar a Internet ele tentou sair pelo servidor SVFW01,

que faz um serviço de NAT. O NAT faz um mapeamento entre os IP privados e pú-

blicos da nossa rede, para possibilitar que um computador com IP privado acesse a

rede da Internet (na qual somente trafegam os IPs públicos), ou seja, como espera-

do o SVFW01 utilizou o seu IP público (189.105.8.42) para acessar a Internet.

99

Figura 5-25 - Evidência LAN acessando HTTP

5.1.3.2 HTTPS

Para a avaliação do acesso aos sites HTTPS (443) a partir da LAN aces-

sei o site da Caixa Econômica Federal via o browser Internet Explorer. O protocolo

HTTPS é muito utilizado em sites de bancos e comércio eletrônico, pois se trata de

uma implementação segura do protocolo HTTP, repare que o endereço acessado

começa com “https://” ao invés do normal “http://”.

Digitei o endereço http://www.caixa.gov.br (este utiliza porta 80) e depois

acessei o link “Acesse a sua conta” que abriu o site seguro, conforme evidenciado

na Figura 5-26.

100

Figura 5-26 - Evidência LAN acessando HTTPS

5.1.3.3 FTP

Com o objetivo de acessar um servidor de FTP localizado na Internet, a

partir da LAN, fiz um experimento utilizando um prompt de comandos e acessei o

endereço ftp.linux.ncsu.edu, que é um FTP utilizado para fazer downloads de arqui-

vos do sistema operacional Red Hat. Na Figura 5-27 podemos visualizar os coman-

dos executados, que detalho a seguir:

101

1. Inicio da conexão: comando “ftp ftp.linux.ncsu.edu”.

2. Autenticação: Foram solicitados usuário e senha, como é um ftp

público é necessário apenas informar o usuário “anonymous” (anô-

nimo) e senha em branco.


ado o comando “ls” que lista os arquivos do diretório atual do FTP,

retornou: mirror e pub.

4. Encerrar conexão: Enviado o comando “quit” para encerrar a cone-

xão.

O sucesso dos comandos efetuados nos garante o bom funcionamento

das regras de liberação do FTP.

Figura 5-27 - Evidência LAN acessando FTP

5.1.4 Estação do administrador

Para a estação do administrador foi liberada a porta 22 (SSH), de forma

que o administrador possa acessar o servidor remotamente, e o protocolo ICMP, que

é utilizado para testes de conectividade. Estas portas também foram liberadas no

102

SVFW02, pois, como podemos ver na Figura 5-28, o SVFW02 está no caminho da

estação do administrador até o SVFW01.

Figura 5-28 - Origem estação do administrador (área verde) com destino ao SVFW01

5.1.4.1 SSH

O SSH é utilizado para controlar remotamente o servidor, tarefa que cabe

ao administrador do servidor.

Com objetivo de avaliar a conexão SSH utilizei o software Putty [16], a

partir da estação do administrador, e nele digitei o endereço do servidor de destino

(192.168.0.100) e a porta do SSH (22), o resultado foi abertura da tela solicitando a

autenticação (isto já confirma que a porta estava aberta), utilizei o usuário “root”,

após as mensagens de boas-vindas digitei o comando “uname –a”, que mostra a

versão do sistema operacional instalado, conforme pode ser verificado na Figura 5-

29.

103

Figura 5-29 - Evidência estação do administrador acessando SVFW01 via SSH

Conforme configurado no PF é gerado um log toda vez que o administra-

dor utiliza o SSH. Utilizando o comando “tcpdump -n -e -ttt -r /var/log/pflog” é possí-

vel verificar os logs gerados, no caso do acesso do administrador utilizando SSH

será gerada uma linha no arquivo /var/log/pflog com o conteúdo parecido com este:

11. 222553 rule 15/0(match): pass in on em1: 10.0.0.10.1103 > 192.168.0.100.22: S 3159589337:3159589337(0) win 64512 <mss 1460,nop,nop,sackOK>

No exemplo aparece o IP 10.0.0.10 (estação do administrador) acessando

o IP 192.168.0.100 (IP do SVFW01) via porta 22 através da interface em1.

104

5.1.4.2 ICMP

O protocolo ICMP é utilizado para avaliar a conectividade (como ping e

tracert). Este experimento teve o objetivo de avaliar a liberação do protocolo ICMP, a

partir da estação do administrador até o SVFW01, para tal, o administrador abriu um

prompt de comandos e executou o comando “ping 192.168.0.100 –n 1” (envia paco-

te para o host 192.168.0.100 apenas uma vez “-n 1”) e recebeu a resposta do servi-

dor “Reply from 192.168.0.100: bytes=32 time<1ms TTL=63”. Logo após utilizei o co-

mando “tracert 192.168.0.100”, que obtém todo o caminho que o pacote percorre até

o destino, no nosso caso ele passou por 10.0.0.1 (SVFW02) até chegar ao

192.168.0.100 (SVFW01), conforme Figura 5-30.

Figura 5-30 - Evidência estação do administrador testando conectividade com SVFW01 utilizando fer-

ramentas ICMP

Para demonstrar que o protocolo ICMP está bloqueado a partir de outras

estações, segue evidência do experimento realizado a partir de um micro qualquer

localizado na LAN. Utilizei o comando “ipconfig | find “.101” apenas para mostrar o IP

do computador de onde está sendo feito o experimento, digitei o comando “ping

192.168.0.100 –n 1” (envia pacote para o host 192.168.0.100 uma vez “-n 1”) e de-

105

pois utilizei o comando “tracert 192.168.0.100 –h 3” (experimenta o host

192.168.0.100 por no máximo três vezes “-h 3”). Repare na Figura 5-31 que ocorrem

erros de “Request timed out” na saída dos dois comandos. No caso tanto no

SVFW01 quanto no SVFW02 o ICMP está bloqueado.

Figura 5-31 - Evidência de bloqueio do protocolo ICMP

106

5.2 REGRAS DO SVFW02

Nesta seção valido as premissas propostas para o SVFW02 (ver Tabela

10) o firewall que separa a LAN da DMZ. Dividi as seções com base nas origens do

acesso, neste caso LAN e estação do administrador.


Origem DestinoServidor / Rede Protocolo Porta

LAN

DMZ

INTERNET

TCP 80 (HTTP)TCP 443 (HTTPs)TCP 21 (FTP)

SVMAIL01TCP 53 (DNS)TCP 25 (SMTP)TCP 110 (POP3)

SVDB01 TCP 3306 (MySql)

Estação do Admin

SVFW02TCP 22 (SSH)ICMP

DMZ

TCP 22 (SSH)TCP 3389 (RDP)TCP 5800 (VNC-web)TCP 5900 (VNC)ICMP

5.2.1 LAN

Os protocolos HTTP (80), HTTPS (443) e FTP (21) são protocolos de uso

comum e foram liberados no SVFW02, não importando o destino, para a Internet.

Visto que já realizei estes experimentos na seção 5.1.3, então avalio estas portas

para acessar os servidores que mantém estes serviços na DMZ (Figura 5-19).

107

Sendo o destino o servidor SVMAIL01 liberei as portas 53 (DNS), 110

(POP3) e 25 (SMTP), que são os serviços específicos deste servidor. Quando o des-

tino for o SVDB01 liberamos apenas a porta 3306, que é a porta aberta para acessar

o MySQL.

Figura 5-32 - Origem LAN (área verde) com destino a DMZ e Internet

A seguir veremos as evidências destas liberações.

5.2.1.1 DMZ - HTTP

Com o objetivo de avaliar a liberação da porta de HTTP (80) no servidor

SVFW02, fiz o seguinte experimento: a partir de uma estação qualquer na LAN, utili-

zei o Internet Explorer, digitei o endereço http://svweb01.cederj.tcc e acessei então o

site localizado no SVWEB01. O resultado, conforme esperado, foi o retorno do site

de teste do APACHE, como evidenciado na Figura 5-33.

108

Figura 5-33 - Evidência LAN acessando HTTP localizado na DMZ

5.2.1.2 DMZ - HTTPS

Esta porta foi liberada, mas não temos este serviço na DMZ, como é uma

porta segura já deixei liberada para futuras implementações. Esta liberação, por en-

quanto, só serve para o acesso a Internet (ainda passa pelo crivo do SVFW01) e foi

avaliada no item HTTPS5.1.3.2.

5.2.1.3 DMZ – FTP

Com o objetivo de avaliar a liberação do protocolo FTP no firewall do

SVFW02, para computadores localizados na LAN acessarem o FTP localizado na

DMZ, realizei o seguinte procedimento: a partir de um computador qualquer na LAN,

abri um prompt de comandos e utilizei o programa cliente “ftp” e acessei o FTP loca-

lizado no SVWEB01. Na Figura 5-34 são apresentados os comandos para avaliar a

conexão com o FTP, sendo:

1. Inicio da conexão: utilizando o comando “ftp svweb01.cederj.tcc”.

109

2. Autenticação: foram solicitados usuário e senha, que depois de in-

formados, retornou à mensagem “230 Login successful”, indicando

que já estamos conectados e autenticados


ado o comando “ls” que lista os arquivos do diretório atual do FTP,

retornou apenas o arquivo cederj.txt.

4. Encerramento da conexão: enviado o comando “quit” para encerrar

a conexão.

A ausência de mensagens de erro evidencia o sucesso do experimento.

Figura 5-34 - Evidência LAN acessando FTP localizado na DMZ

5.2.1.4 SVMAIL01 – SMTP

Para avaliar a liberação do protocolo SMTP no firewall do SVFW02, nas

conexões a partir dos computadores localizados na LAN tendo como destino o servi-

dor de SMTP, localizado na DMZ, realizei o experimento descrito na seqüência.

110

A partir de um micro localizado na LAN abri um prompt de comandos e

executei o comando “ipconfig | find “.10”” (apenas para demonstrar o IP do computa-

dor da origem dos experimentos), iniciei a conexão com o comando “telnet sv-

mail01.cederj.tcc 25” (conectar ao host svmail01.cederj.tcc na porta 25) e obtive,

como retorno, uma mensagem de sucesso “220 cederj.tcc ESMTP Server ready.,” o

que evidencia o sucesso do experimento. Caso a conexão não fosse bem sucedida

recebería uma mensagem de “Connect Failed”, depois apenas digitei quit para en-

cerrar a conexão, conforme pode ser verificado na Figura 5-35.

Figura 5-35 - Evidência LAN acessando SMTP localizado na DMZ

5.2.1.5 SVMAIL01 – POP3

O experimento a seguir tem o objetivo avaliar a liberação da porta de

POP3 no firewall do SVFW02, para conexões com origem na LAN e com destino ao

nosso servidor POP3 localizado na DMZ.

Para efetuar esta avaliação abri um prompt de comandos e executei o co-

mando “ipconfig | find “.10””, de forma a obter o IP do computador da origem dos ex-

perimentos, depois iniciei a conexão com o comando “telnet svmail01.cederj.tcc 110”

111

(conectar ao host svmail01.cederj.tcc na porta 110) e, como retorno, obtive uma

mensagem de sucesso “+OK ([email protected]), POP3 server read.”

Esta mensagem evidencia o sucesso do experimento, pois caso contrário recebería

uma mensagem de “Connect Failed”, por fim, apenas digitei “quit” para encerrar a

conexão, conforme fica evidenciado na Figura 5-36.

Figura 5-36 - Evidência LAN acessando POP3 localizado na DMZ

5.2.1.6 SVMAIL01 – DNS

O próximo experimento avaliou a liberação da porta 53 (DNS) no firewall

SVFW02, para conexões originadas na LAN e destino o servidor de DNS localizado

na DMZ.

Como requisito para este teste o computador de origem deve ter o ende-

reço do servidor de destino do experimento configurado como seu servidor de DNS,

no caso o endereço é 192.168.0.10 (SVMAIL01). No experimento vamos tentar re-

solver o nome svdb01.cederj.tcc, isto significa receber como retorno o IP do servidor,

no caso 192.168.0.30.

112

O experimento foi realizado da seguinte forma: a partir do prompt de co-

mandos executei “nslookup svdb01.cederj.tcc”, na saída do comando é retornado

qual o servidor foi utilizado para consultar (svmail01.cederj.tcc), e em seguida recebi

os dados requisitados (o endereço de svdb01 que é 192.168.0.30), conforme apre-

sentado na Figura 5-37. Caso o resultado fosse negativo recebería uma mensagem

de “request time out”.

Figura 5-37 - Evidência LAN consultando DNS localizado na DMZ

5.2.1.7 SVDB01 – MYSQL

Neste experimento avalio a liberação da porta utilizada pelo MySQL no

servidor SVFW02, porta 3306, para conexões originadas na LAN e com destino ao

servidor SVDB01 localizado na DMZ. Avalei o MySQL através do software MySQL

Administrator [11], de forma a acessar o MySQL e visualizar informações do mesmo.

Executei o MySQL Administrator que , em sua tela inicial, solicita o nome

do servidor (Server host), onde inseri o nome do servidor MySQL

(svdb01.cederj.tcc), o usuário e a senha, onde utilizei o usuário root e sua senha.

Clicando em OK foi aberta a tela do software “Server Information”, que traz informa-

ções sobre o servidor e o cliente que está acessando o servidor, evidenciando o su-

cesso da conexão (destacados na Figura 5-38).

113

Figura 5-38 - Evidência LAN acessando o MySQL localizado na DMZ

5.2.2 Estação do administrador

A estação do administrador está localizada na LAN, possui todos os aces-

sos concedidos para a LAN e alguns diferenciais necessários para a administração

dos firewalls e dos servidores localizados na DMZ. A única diferença entre a estação

do administrador e outra estação qualquer localizada na LAN é o IP 10.0.0.10, cujas

regras do firewall fazem referência quando se deseja referenciar a estação do admi-

nistrador.

Para a estação do administrador foram inseridas no firewall SVFW02 re-

gras que permitem:

114

Acesso via SSH ao servidor SVFW02: necessário para acessar remota-

mente o SVFW02, através deste acesso podemos configurar o firewall e administrar

o servidor.

Utilização do protocolo ICMP com destino ao SVFW02 e a todos os servi-

dores da DMZ: este protocolo é utilizado para verificação de conectividade.

A instalação dos protocolos de acesso remoto nos servidores da DMZ

(RDP, VNC e SSH) é necessária para que remotamente possamos administrar os

serviços instalados nos servidores.

Figura 5-39 - Origem estação do administrador (área verde) com destino a DMZ e SVFW02

5.2.2.1 SVFW02 - SSH

Efetuei um experimento com o objetivo de avaliar a liberação do protocolo

SSH no servidor SVFW02, para as conexões originadas da estação do administra-

dor e com destino o próprio SVFW02.

115

Para suportar este experimento utilizei o software Putty, no qual, a partir

da estação do administrador, inserimos o endereço do SVFW02 (10.0.0.1) e a porta

do SSH (porta: 22). Após isto, pressionando o botão “open”, foi aberta a console que

solicitou a autenticação. Caso a porta não estivesse aberta não nos seria solicitada à

autenticação e seria exibida uma janela contendo o erro “Connection time out”. Nes-

te experimento utilizei o usuário root e, também, digitei o comando “uname –a“ ape-

nas para confirmar o nome do servidor que esta acessando (svfw02.cederj.tcc), con-

forme evidenciado na Figura 5-40.

Figura 5-40 - Evidência estação do administrador acessando o SVFW02 via SSH

116

5.2.2.2 SVFW02 – ICMP

Neste experimento avalio a liberação no firewall SVFW02 do protocolo

ICMP, que é utilizado para testes de conectividade (como ping e tracert), a partir da

estação do administrador.

Na avaliação utilizei dois comandos o ping e o tracert, a partir da estação

do administrador.

No experimento abri um prompt de comandos e executei o comando “ping

10.0.0.1 –n 1” (envia pacote para o host 10.0.0.1 apenas uma vez “-n 1”) e recebi a

resposta do servidor “Reply from 10.0.0.1: bytes=32 time<1ms TTL=64”, também uti-

lizei o comando “tracert 10.0.0.1”, que obtém todo o caminho que o pacote percorre

até o destino, no meu caso não foi preciso passar por outros servidores, pois esta-

vam na mesma rede, conforme pode ser verificado através da Figura 5-41. Os dois

experimentos obtiveram sucesso, caso não fossem bem sucedidos recebería men-

sagens “request time out”.

Figura 5-41 - Evidência estação do administrador testando conectividade com SVFW02 utilizando fer-

ramentas ICMP

117

5.2.2.3 DMZ – SSH

Neste experimento avaliei a liberação do protocolo SSH no servidor

SVFW02, para conexões com origem na estação do administrador e destino aos ser-

vidores da DMZ. Para o experimento utilizei o software Putty tentando acessar o ser-

vidor SVWEB01 localizado na DMZ.

Executei o software Putty e inseri o endereço do SVWEB01

(192.168.0.20) e a porta do SSH (22) clicando em “open” foi aberta a console, que

solicitou a autenticação (isto já indica o sucesso da conexão, pois caso contrário re-

cebería uma mensagem de “Connection time out”), utilizei o usuário “fabiojr” e tam-

bém digitei o comando “uname –a“, apenas para confirmar o nome do servidor que

estava acessando (svweb01.cederj.tcc), conforme apresentado na Figura 5-42.

Figura 5-42 - Evidência estação do administrador acessando servidor na DMZ via SSH

118

5.2.2.4 RDP

O RDP é um protocolo utilizado pela Microsoft para acesso remoto aos

servidores da família Windows, este experimento avalia a liberação do RDP no fi-

rewall SVFW02, para as conexões oriundas da estação do administrador com desti-

no aos servidores da DMZ. Nesta avaliação foi utilizado o programa “mstsc.exe”, que

está incluído em toda linha de sistemas operacionais da Microsoft.

Executei o programa mstsc que solicita o nome do computador que se de-

seja conectar, inserimos SVMAIL01 e pressionei “Connect”, assim foi aberta a tela

de solicitação de autenticação do servidor remoto (neste ponto, já se evidencia o su-

cesso do experimento, pois, caso contrário, receberia uma mensagem “This compu-

ter can’t connect to the remote computer”). Neste momento, inseri o usuário “Admi-

nistrator” e sua senha, clicando em “OK” foi aberta a console do servidor, conforme

evidenciado pela Figura 5-43.

119

Figura 5-43 - Evidência estação do administrador acessando servidor na DMZ via RDP

120

5.2.2.5 DMZ – VNC

Existem versões do VNC para vários sistemas operacionais, no OpenSo-

laris é o protocolo padrão de acesso remoto, e ele utiliza duas portas: a 5800 para o

cliente e a 5900 para o acesso remoto.

Com o objetivo de avaliar as liberações para o protocolo VNC, no firewall

SVFW02, com conexões originadas na estação do administrador com destino aos

servidores da DMZ, utilizei o browser Internet Explorer e acessando o endereço do

VNC do servidor SVDB01.

Neste experimento acessei o endereço http://svdb01.cederj.tcc:5800 que

abre um cliente Web, nele digitei o endereço do servidor svdb01.cederj.tcc, então foi

solicitada uma senha (neste ponto evidenciou-se a abertura da porta 5800) e foi efe-

tuada a conexão com o servidor (evidência da abertura da porta 5900), conforme Fi-

gura 5-44. Repare que no SVDB01 é gerado um alerta informando que existe um ou-

tro usuário acessando remotamente o servidor, no caso com endereço IP 10.0.0.10

(estação do administrador).

121

Figura 5-44 - Evidência estação do administrador acessando servidor na DMZ via VNC

5.3 PORTSCAN (NMAP)

Nesta seção farei alguns experimentos para provar que não abrimos mais

portas que o necessário, segundo as premissas que definidas para os firewalls.

Utilizarei o software NMAP que é um portscan43 muito famoso, inclusive

ele aparece em cenas de vários filmes como em “O ultimato Bourne”, “Duro de matar

4.0” e em “Matrix Reloaded”, onde a personagem Trinity utiliza o NMAP para desco-

brir uma porta SSH aberta nos computadores da Matrix [15].

43 Portscan é um tipo de software geralmente utilizado por administradores de segurança de rede para

verificar portas abertas em um computador.

122

A seguir veremos os resultados dos experimentos, que foram divididos

pelas interfaces que serão testadas. Os experimentos são os seguintes:

• Portscan na interface eth1 do servidor SVFW02

• Portscan na interface eth0 do servidor SVFW02

• Portscan na interface em1 do servidor SVFW01

• Portscan na interface em0 do servidor SVFW01

5.3.1 Portscan na interface eth1 do servidor SVFW02

Realizei dois portscans, um a partir de um micro qualquer da LAN e outro

a partir da estação do administrador, porque possuem regras diferentes.

123

5.3.1.1 A partir da LAN

A partir de uma estação localizada na rede interna (qualquer uma localiza-

da na área verde da Figura 5-45) foi executado o programa NMAP. com os seguin-

tes parâmetros “nmap 10.0.0.1 -PN”. O NMAP verifica se o servidor está ativo dispa-

rando um “ping” contra o mesmo, mas como nos firewalls foram adicionadas regras

para não permitir ping, foi necessário adicionar a opção –PN, para que o NMAP fi-

zesse a avaliação mesmo que o servidor não respondesse ao ping.

Figura 5-45 - Localização da origem dos experimentos (área verde)

A Figura 5-46 representa os resultados do experimento contra o endereço

10.0.0.1 (SVFW02), que é o endereço da interface eth1 deste servidor. Repare que

não existem mensagens de portas abertas evidenciando o sucesso da configuração

firewall.

124

Figura 5-46 - Portscan na interface eth1 do SVFW02

5.3.1.2 A partir da estação do administrador

O experimento foi efetuado a partir da estação do administrador, confor-

me representado na Figura 5-47, a estação está inserida na área de LAN, então pos-

sui todos os privilégios da LAN e também alguns privilégios necessários para admi-

nistrar remotamente os servidores.

125

Figura 5-47 - Localização da origem dos experimentos (área verde) - estação do administrador

Repare que agora aparece como aberta a porta do SSH (ver Figura 5-48),

que foi liberada no firewall para a estação do administrador poder acessar remota-

mente o servidor.

Figura 5-48 - Portscan na interface eth1 do SVFW02 a partir da estação do administrador

126

5.3.2 Portscan na interface eth0 do servidor SVFW02

Neste experimento avaliei se existem portas abertas no SVFW02 com ori-

gem na DMZ em direção a LAN, para isto fiz um portscan a partir do servidor SV-

MAIL01 (IP 192.168.0.10) localizado na DMZ (ver Figura 5-49).

Figura 5-49 - Localização da origem dos experimentos DMZ (área verde)

Executando o comando “nmap 192.168.0.200 –PN”, sendo 192.168.0.200

o endereço da interface eth0 do SVFW02. O NMAP não reportou nenhuma porta

aberta conforme pode ser visto na Figura 5-50, este é o comportamento esperado.

Figura 5-50 - Portscan na interface eth0 do SVFW02 a partir da DMZ

127

5.3.3 Portscan na interface em1 do servidor SVFW01

Agora o experimento continua com origem na DMZ (ver Figura 5-51), mas

vamos focalizar a interface em1 do servidor SVFW01, que é a interface com endere-

ço 192.168.0.100 ligada a rede DMZ.

Figura 5-51 - Localização da origem dos experimentos DMZ (área verde)

Apenas a porta 21 (FTP) está aberta, conforme pode ser visto na Figura

5-52. Neste servidor não tinha o serviço de FTP instalado, mas o motivo da porta 21

estar aberta é que foi instalado neste servidor o proxy de FTP.

Figura 5-52 - Portscan na interface em1 do SVFW01 a partir da DMZ

128

5.3.4 Portscan na interface em0 do servidor SVFW01

Finalmente, neste último experimento avalio a interface externa do servi-

dor SVFW01, que serve como porta de entrada da Internet para o ambiente.

Figura 5-53 - Localização da origem dos experimentos Internet "simulada" (área verde)

O experimento tem como origem a Internet como destino a interface em0

do SVFW01 (ver Figura 5-53). Não obtive sucesso ao realizar o experimento a partir

da Internet, acredito que o motivo seja alguma proteção contra este tipo de procedi-

mento na rede da Oi. A saída foi simular a Internet da seguinte forma:

1. Na interface em0 do SVFW01 onde fica ligado o modem ADSL, li-

gamos um computador com endereço 200.200.200.3 e máscara

255.255.255.0.

2. Configuramos a interface em0 com endereço IP 200.200.200.1 e

máscara 255.255.255.0.

129

3. Alteramos a configuração do arquivo /etc/pf.conf, substituí o valor

da macro “ext_if” de tun0 (interface virtual que acessa a ADSL) por

em0 e recarreguei as regras com o comando “pfctl –ef /etc/pf.conf”.

Figura 5-54 - Internet simulada

Montado o ambiente efetuei o experimento a partir do micro de teste e ob-

servei as seguintes portas abertas: 21 (FTP, para acesso dos usuários externos ao

FTP no SVWEB01), 25 (SMTP, acesso ao SVMAIL01), 80 (HTTP, acesso ao

SVWEB01) e 110 (pop3, acesso ao SVMAIL01), conforme pode ser visto na Figura

5-55, enfim são as portas dos serviços que deveriam ser expostas ao público exter-

no, conforme premissas definidas para o firewall SVFW01 evidenciado o sucesso do

experimento.

130

Figura 5-55 - Portscan na interface em0 do SVFW01 a partir da Internet "simulada"

131

CONCLUSÕES

Neste trabalho demonstrei a utilização da tecnologia de virtualização atra-

vés da construção de um típico ambiente de uma DMZ. Apresentei suas virtudes e

defeitos, deixando a cargo do leitor decidir se a virtualização é uma tecnologia que

pode lhe oferecer alguma vantagem ou se seus defeitos o afastam dela.

Quanto a melhorias futuras, no trabalho já concluído, divido em quatro par-

tes distintas: virtualização, segurança, disponibilidade e serviços no núcleo da DMZ.

• Virtualização: a utilização de outros sistemas de virtualização, para

tal recomendamos o software VMWARE ESXi, que é uma versão

gratuita do aclamado VMWARE ESX software voltado para ambien-

tes corporativos e datacenters.

• Segurança: implementação de um serviço de IDS (Intrusion Detect

System), que é um sistema que monitora o tráfego da rede anali-

sando, por exemplo, o formato dos pacotes tentando identificar pos-

síveis tentativas de invasões ou ataques, eles podem ate mesmo

reagir automaticamente a certos tipos de eventos.

• Disponibilidade: em um ambiente virtual, no qual vários serviços fi-

cam dependendo do mesmo equipamento, é importante ter uma for-

ma de manter uma contingência para o caso de falha no equipa-

mento. Ter um servidor host adicional, contendo uma réplica de to-

dos os servidores do principal mantendo a sincronização através de

ferramentas de cluster dos sistemas operacionais guest, é uma al-

ternativa.

132

• Núcleo da DMZ: não tivemos muita preocupação com os sistemas

instalados no núcleo da DMZ, pois o foco era ter os serviços instala-

dos apenas para ajudar nos testes dos firewalls. Indicamos uma

melhor implantação dos serviços de e-mail, criação de um site insti-

tucional ou de colaboração (utilizando ferramentas como Sharepoint

e Plone).

Este trabalho me serviu para conhecer outros sistemas operacionais, hou-

ve a curiosidade no passado, mas instalar um sistema operacional e utilizá-lo, sem

compromisso, é muito diferente de instalar um sistema operacional e ter o compro-

misso de fazer as coisas funcionarem. Esta foi uma excelente oportunidade para

aprender, principalmente sobre os sistemas FreeBSD e CentOS nos quais o trabalho

foi mais árduo.

Finalmente, pretendo utilizar esta experiência e continuar meus estudos

nas áreas abordadas. Profissionalmente, vou buscar mais conhecimentos sobre a

plataforma VMWARE ESX, fazendo cursos, experimentos e depois certificações do

fabricante. No âmbito acadêmico pretendo fazer alguma pós-graduação nas áreas

de gestão e segurança de redes.

133

REFERÊNCIAS BIBLIOGRÁFICAS

1. B2B Magazine, Redação. Citrix conclui aquisição da XenSource. Disponí-

vel em <http://www.b2bmagazine.com.br/web/interna.asp?

id_canais=4&id_subcanais=10&id_noticia=20770> . Acessado em

30/09/2008..

2. COMPUTERWORLD, Redação. A VMWare contra o resto do mercado. Dis-

ponível em <http://computerworld.uol.com.br/mercado/2008/03/12/a-vmware-

contra-o-resto-do-mercado/ >. Arquivo acessado em 30/09/2008.

3. COMPUTERWORLD, Os seis passos para um data center verde. Disponí-

vel em <http://computerworld.uol.com.br/gestao/2007/04/25/idgnoticia.2007-

04-25.2332178476/paginador/pagina_2> Acessado em: 10/09/2008.

4. DITTNER, Rogier; RULE, David. The Best Damn Server Virtualization Book Period. Burlington, MA : Syngress Publishing, 2007. cap. 1, p.1-35.

5. FERREIRA, Rubens E. Linux: Guia do Administrador do Sistema. São

Paulo, SP : Novatec, 2003.

6. HANSTEEN, Peter N.M. The book of PF: a no-nonsense guide to the OpenBSD firewall. San Francisco, CA : No Starch Press, 2008.

7. HOPE, Paco; KORFF, Yanek; POTTER, Bruce. Mastering FreeBSD and OpenBSD Security. Sebastopol, CA : O'Reilly, 2005.

8. MERCURY/32 V4.62. Pegasus Mail. Disponível em <http://www.pmail.com>.

Acessado em 01/09/2008.

9. MICROSOFT, Perimeter network scenarios. Microsoft Technet. Disponível

em <http://technet.microsoft.com/en-us/library/cc767224.aspx>. Acessado em

02/10/2008.

10.MOTA, Mateus Ribeiro. FTP com Connection Tracking no IPTABLES. Di-

cas-L. (publicado em 22/03/2006). Disponível em < http://www.dicas-

l.com.br/dicas-l/20060322.php>. Acessado em 20/09/2008.

134

11.MySQL. MySQL GUI Tools Downloads. Disponível em < http://dev.mysql.-

com/downloads/gui-tools/5.0.html>. Acessado em 01/10/2008.

12.NEDSLIDER. IPTABLES HOWTO. CentoOS. Disponível em <http://wiki.cen-

tos.org/HowTos/Network/IPTables>. Acessado em 20/09/2008.

13.NETFILTER. IPTABLES. Disponível em <http://www.netfilter.org/projects/ipta-

bles/index.html>. Acessado em 01/09/2008.

14.NETFILTER. NETFILTER. Disponível em < http://www.netfilter.org/ >. Acessa-

do em 01/09/2008.

15.NMAP, Nmap Featured in The Matrix Reloaded. Disponível em <http://insecu-

re.org/>. Acessado em 05/10/2008.

16.PUTTY. PuTTY Download Page. Disponível em < http://www.chiark.green-

end.org.uk/~sgtatham/putty/download.html>. Acessado em 01/10/2008.

17.OpenBSD. PF: OpenBSD Packet Filter. Disponível em <http://www.o-

penbsd.org/faq/pf/pt/index.html>. Acessado em 01/10/2008.

18.REGGIANI, Lucia. Virtualização faz milagre?. INFO Exame. São Paulo, SP, n.

249, p. 69-73.

19.SILVA, Marcos. [FUG-BR] RES: servidor freebsd + velox ppoe. FUG-BR.

Disponível em < http://www.fug.com.br/historico/html/freebsd/2005-

11/msg00410.html> . Acessado em 20/09/2008.

20.SISOFTWARE SANDRA. SiSoftware Sandra Lite 2009. Disponível em <

http://www.sisoftware.net/> . Acessado em 06/10/2008.

21.SUPER PI. Kanada Lab. Disponível em <http://www.xtremesystems.com/pi/> .

Acessado em 06/10/2008.

22.VMWARE Converter. VMWARE Inc. Disponível em <

http://www.vmware.com/products/converter/> . Acessado em 01/08/2008.

23.VMWARE SERVER 1.0.4. VMWARE Inc. Disponível em <http://www.vmwa-

re.com> . Acessado em 01/08/2008.

24.VMWARE. Administration Guide. Disponível na Internet via URL:

http://www.vmware.com/pdf/server_admin_manual.pdf. Acessado em

30/09/2008.

25.XEN Wiki. HVM Compatible Processors. Disponível em: <http://wiki.xen-

source.com/xenwiki/HVM_Compatible_Processors>. Acessado em

03/10/2008.

135

136

ANEXOS

137

ANEXO A – COMANDOS ÚTEIS

FreeBSD:

Comandos Gerais

Comando Descrição Observação/etc/netif {start | stop } Iniciar, parar interfaces de

rede.

Útil para quando o IP do

servidor for alteradosysinstall Configurar diversos com-

ponentes do sistemadf Verifica espaço livre nos

discos/etc/rc.d/PF {start | stop } Iniciar, parar o firewall(PF)

Comandos úteis do PF

Opções do pfctl Açãopfctl -f /etc/pf.conf Carrega o arquivo pf.confpfctl -nf /etc/pf.conf Analisa o arquivo, mas não o carregapfctl -Nf /etc/pf.conf Carrega apenas as regras NAT do arquivopfctl -Rf /etc/pf.conf Carrega apenas as regras de filtragem do arquivo

138

CentOS:Comandos Gerais

Comando Descrição ObservaçãoSystem-config-network Configurar placas de rede.Service serviço {start |

stop}

Parar serviços Exemplos:

Service iptables stop

Service network startntsysv Diversas configurações do

sistema

Comandos úteis do IPTABLES

Opções do iptables AçãoIptables -L Lista as regras atuaisIptables -F Remove todas as regras existentes (não altera as

regras inseridas com –P – política)Iptables -P Define política padrão para uma cadeia. Exemplo:

Iptables –P FORWARD DROP

Significa que todos os pacotes da cadeia

FORWARD serão negados até que seja inserida

uma regra com a opção –A.

139

Ubuntu:

Comando Descrição Observaçãopost-up route add -net

192.168.0.0/16 gw

192.168.10.1

Adicionar uma rota estáti-

ca.

Editar o arquivo

etc/network/interfaces e in-

serir o comandoSudo <comando> Executar comando com

permissões do root

OpenSolaris:

Comando Descrição Observaçãosvcadm disable svc:/net-

work/physical:nwam

Desabilitar NWAM (confi-

guração automática de

rede)su Utilizar super usuário

Windows Server 2003:

Comando Descrição Observaçãoroute add <destino> mask

<mascara> <gateway> -p

Adiciona uma rota, com a

opção –p a configuração

não se perde após um rei-

nicio

Exemplo:

route add 10.0.0.0 mask

255.255.255.0

192.168.0.200 -p

140

ANEXO B – SISTEMAS OPERACIONAIS UTILIZADOS NO TRABALHO

Microsoft Windows 2003 Standard Edition (32 bits)

É o sistema operacional mais usado do mundo, sendo em grande parte

através de cópias ilegais. Apesar de ser muito lembrado pelas suas falhas críticas de

segurança, ainda é impensável o mundo atual sem o Windows, sejam versões para

servidores ou desktops.

No trabalho foi utilizada uma cópia de avaliação disponível após registro

no site http://www.microsoft.com/windowsserver2003/evaluation/trial/default.mspx

FreeBSD 7

O FreeBSD é um sistema baseado no Unix e muito utilizado por provedo-

res de Internet. É um descendente do sistema BSD, desenvolvido pela universidade

de Berkeley em 1979. Um dos mais famosos casos de sua utilização é a do gigante

da Internet Yahoo.

Pode ser baixado livremente no site www.freebsd.org .

CentOS 5

É um clone do Red Hat Enterprise (distribuição do tipo Enterprise) e é

uma das mais bem sucedidas distribuições Linux. A principal diferença entre as duas

é que a Red Hat cobra pelo suporte, enquanto a CentOS é gratuita. É mantida pelo

CentOS Project.

141

O download pode ser feito no site http://www.centos.org/ .

Ubuntu 8 (Server)

Distribuição Linux baseada no Debian, é patrocinada pela Canonical Ltd,

criada por Mark Richard Shuttleworth (programador sul-africano que se tornou milio-

nário depois de vender sua empresa de segurança de Internet, a Thawte, para a Ve-

risign, foi o segundo turista espacial da história).

O Projeto do Ubuntu tem uma filosofia baseada nestes três ideais:

1. Todo usuário de computador deve ter a liberdade de executar, co-

piar, distribuir, estudar, compartilhar, alterar e melhorar seu softwa-

re por qualquer motivo, sem ter que pagar taxas de licenças.

2. Todo usuário de computador deve poder usar seu software na lín-

gua de sua escolha.

3. Todo usuário de computador deve receber todas as oportunidades

para usar um software, mesmo que seja portador de deficiência.

Atualmente é a distribuição Linux mais popular, segundo o ranking do site

http://distrowatch.com/, e pode ser baixada no site www.ubuntu.com, onde também

pode ser encomendada gratuitamente, preenchendo um cadastro você recebe um

pacote com três CDs do Ubuntu.

OpenSolaris 2008.05

O OpenSolaris é baseado no código fonte do Solaris (Sistema Operacio-

nal Comercial). É um projeto criado pela Sun Microsystems para criar uma comuni-

dade de desenvolvedores em torno do sistema operacional Solaris.

142

No futuro a SUN espera que o OpenSolaris rivalize com o Linux e seu uso

se torne tão corriqueiro quanto o uso do Java (também da SUN).

Pode ser baixado no site: http://www.opensolaris.com/get/ .

143

ANEXO C – ARQUIVOS DE CONFIGURAÇÃO

• SVFW01

o /etc/rc.conf# Configuracoes de Redeifconfig_em0="inet 200.200.200.1 netmask 255.255.255.0"ifconfig_em1="inet 192.168.0.100 netmask 255.255.255.0"defaultrouter="200.200.200.1"hostname="svfw01.cederj.tcc"gateway_enable="YES"static_routes="rlan"route_rlan="-net 10.0.0.0/8 192.168.0.200"

# Tecladokeymap="us.iso"

# Habilitar SSHsshd_enable="YES"

# Configuracoes do PFpf_enable="YES" # Enable PF (load module if required)pf_rules="/etc/pf.conf" # rules definition file for pfpf_flags="" # additional flags for pfctl startuppflog_enable="YES" # start pflogd(8)pflog_logfile="/var/log/pflog" # where pflogd should store the logfilepflog_flags="" # additional flags for pflogd startup

ftpproxy_enable="YES"

o /etc/ppp/ppp.confdefault: set device PPPoE:em0:ISP enable lqr enable tcpmssfixup

set lqrperiod 6 set mut 1492 set mru 1492 set timeout 0 set log Phase tun

nat enable yes

add default HISADDR enable dns

144

set authname [email protected] set authkey ddnnnnnnnn

• SVWEB01

o /etc/network/interfaces

# This file describes the network interfaces available on your system# and how to activate them. For more information, see interfaces(5).

# The loopback network interfaceauto loiface lo inet loopback

# The primary network interfaceauto eth0iface eth0 inet static address 192.168.0.20 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.0.100 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 192.168.0.30 dns-search cederj.tcc post-up route add -net 10.0.0.0/8 gw 192.168.0.200

145

Documents

UNIVERSIDADE FEDERAL FLUMINENSE FÁBIO DE PAULA … · LISTA DE ABREVIATURAS E SIGLAS DMZ – Demilitarized Zone (Zona Desmilitarizada). DNS – Domain Name Service (Serviço de Nomes