UNIVERSIDADE FEDERAL FLUMINENSE
FÁBIO DE PAULA JUNIOR
DMZ VIRTUAL
Niterói
2008
FÁBIO DE PAULA JUNIOR
DMZ VIRTUAL
Trabalho de Conclusão de Curso submetido ao Curso de Tecnologia em Sistemas de Computação da Universidade
Federal Fluminense como requisito parcial para obtenção do Tecnólogo em Sistemas de Computação.
Orientador:
Leandro Soares de Sousa
NITERÓI
2008
FÁBIO DE PAULA JUNIOR
DMZ VIRTUAL
Trabalho de Conclusão de Curso submetido ao Curso de Tecnologia em Sistemas de Computação da Universidade
Federal Fluminense como requisito parcial para obtenção do Tecnólogo em Sistemas 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 familiares, 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 Itaperuna 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 elaboraçã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
Figura 5-43 - Evidência estação do administrador acessando servidor na DMZ via
RDP...........................................................................................................................120
Figura 5-44 - Evidência estação do administrador acessando servidor na DMZ via
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 administrador.................................................................................................................126
Figura 5-48 - Portscan na interface eth1 do SVFW02 a partir da estação do administrador.........................................................................................................................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 7 - Regras do firewall SVFW02.......................................................................78
Tabela 8 - Configuração do iptables (/etc/rc.d/init.d/myfirewall).................................82
Tabela 9 - Regras do firewall SVFW01.......................................................................89
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 desenvolvido 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 deseja 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 operacionais 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 Mensagens).
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
15
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écada de sessenta, apenas recentemente esta tecnologia tomou conta das empresas.
Imagine ter dez servidores com apenas um hardware, esta é apenas uma das possibilidades disponibilizadas por esta tecnologia. A virtualização oferece um melhor
aproveitamento do hardware e outros benefícios que introduzo no decorrer deste trabalho.
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ísicos, neste trabalho utilizo um único servidor físico e cinco virtuais, isto não é um limitador 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 Basic 2, passando por Windows 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 Microsoft
5
ISA Server (Internet Security and Acceleration) é um serviço de firewall e proxy produzido pela Mi-
crosoft
16
Este estudo introduz conceitos que podem auxiliar administradores de sistemas que queiram disponibilizar algum conteúdo na Internet e não dispõem de muitos recursos para aquisição de hardware.
O trabalho foi organizado da seguinte forma, primeiro apresento os conceitos de Virtualização e DMZ (o que são), depois introduzo as vantagens e desvantagens destas arquiteturas (o porque utilizar ou não), em seguida a montagem do ambiente (como fazer) e finalmente avalio, através de experimentos, o ambiente de forma a validar os conceitos introduzidos nas seções anteriores.
17
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 determinam quem entra ou quem sai da DMZ, no caso os pacotes. Como software de firewall, 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.
18
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 configuraçã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 ligado à Internet e o outro à rede local.
19
Figura 2-2: Diagrama da DMZ Back to Back
A configuração Back to Back foi escolhida porque acredito ser a mais segura, 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 passasse 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 firewalls e nos sistemas operacionais, possam ser utilizadas por hackers para ultrapassar 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 execução, aplicando um ou mais conceitos ou tecnologias, tais como: como partições de
20
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 investindo 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 virtualizaçã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árias 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 disponível, não discriminação entre grupos e pessoas, entre outras.
21
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 colocar uma DMZ em uma “caixa” e mostrar que podemos ter as mesmas funcionalidades 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 serviç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 virtual 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.
22
3 DMZ VIRTUAL: VANTAGENS E DESVANTAGENS
Neste capitulo coloquei algumas vantagens e desvantagens, principalmente no tocante a virtualização. Nas subseções de segurança enfatizei a DMZ. Algumas 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 custos 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 alguns:
•
Redução no tempo na instalação dos sistemas operacionais: a instalação de um servidor, por exemplo, que em alguns casos pode levar até uma hora, em ambientes virtualizados pode ser apenas uma
questão de copiar arquivos. Podemos criar máquinas virtuais mode-
23
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 levar 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 servidor 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 operacionais 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.
24
3.1.2 Consolidação de servidores
Dos casos que conheço, o primeiro passo para a virtualização é a consolidaçã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 vantagem).
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 discos, devemos lembrar que este servidor compartilhará recursos com outros servidores, 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, praticamente 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 catastrófico, fazem aumentar a responsabilidade de governos e empresas sobre o futuro 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 recursos: a virtualização.
25
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 conseqü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 empresas, 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 virtualização.
26
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 operacional 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 obsoleto.
Os softwares P2V são de grande valia no caso da consolidação de servidores, 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 consolidar 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 servidores (Fonte: www.dell.com.br em 30/10/2008) e utiliza como base o ambiente definido para este trabalho. A comparação foi efetuada a partir dos computadores
27
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 pesquisa, 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-1
, fontes de energia redundantes9 e placas de rede com suporte a Nic teaming.10
8
Tabela 1: Custo de servidores (Fonte: www.dell.com.br em 30/10/2008)
Modelo
PowerEdge T105 (5 servidores)
PowerEdge 2900 lll
Processador Intel® Xeon®
Processador AMD Opteron™ DualQuad-Core E5410 (2.33 GHz,
Processador
Core 1210 (1.80 GHz, 2X1 MB L2
2x6 MB L2 cache, 1333 MHz
cache)
FSB)
Memória
Memória de 1GB DDR2, 800MHz
4GB 667MHZ
2 x Discos Rígidos SAS de
Disco Rígido de 250GB 7.2K RPM
Discos Rígidos
400GB, 3,5 polegadas,
SATA
10K RPM, Hot Plug
RAID
Não
RAID 1 (Espelhamento)
Suporte
3 anos (5x10)
3 anos (5x10)
(Garantia)
Placa de Rede On-Board Single Gigabit
Broadcom Dual Gigabit
Fonte
Não
Sim (2 fontes)
Redundante
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 ambiente 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.
28
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 aumentou 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 componentes, 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 normalmente ficam 24 horas ligados e além do seu consumo também
necessitam de ar-condicionado, menos servidores é igual a um menor calor gerado que é igual redução no consumo de ar-condicionado.
•
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 servidor base para máquinas virtuais, o que compensaria o maior investimento inicial.
29
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 tradicional 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 virtualizaçã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 utilizar 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 induzida a “enxergar” apenas um. Alguns softwares de virtualização podem
30
até mesmo fazer com que a máquina guest “enxergue” apenas um processador mas se beneficie do processamento de todos os processadores 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 redução dos custos para aquisição de software são raramente percebidos, o que funciona de forma diferente nos ambientes de softwares proprietários, mas ainda podemos ter economia em ambientes com softwares que cobram licenças por processador 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 fatores, 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 necessá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 gratuito, 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 melhor desempenho e possibilidade de montar uma solução de alta disponibilidade.
31
3.1.6 Segurança
Uma das principais dúvidas relacionadas às máquinas virtuais é a seguinte: Se meu servidor host for invadido, as máquinas guests também serão comprometidas? No caso da máquina host, o invasor poderia ter acesso ao software de virtualizaçã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áquinas guest estão tão seguros quanto os de uma máquina física tradicional. Isto porque 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 exemplo, se uma máquina guest for contaminada por um vírus, a chance de outra máquina 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 operacional atualizado, etc.).
A virtualização favorece um aspecto de segurança, que é a divisão de serviç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 profissionais, principalmente o banco de dados (mantido por um DBA 11), no que tange o fator
humano ao dividir em três máquinas, estou ajudando a separar as responsabilidades, isto é, cada administrador cuida da sua máquina. Esta separação, no fator tecnologia, 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.
32
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 minimizar 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 delas:
•
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 disponibilidade, 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 requisições a um site até que este não consiga mais ser acessado.
33
rage NAS13 ou SAN14. Neste caso, os arquivos das máquinas virtuais 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 apenas 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 documento contendo informações de backup do ambiente e, também,
um passo a passo para a recuperação do ambiente em caso de falhas. Esta solução teria um downtime grande e que alguns negócios não suportariam por ter um prejuízo grande decorrente da parada 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 investimento.
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 fibras ópticas.
15
Downtime, tempo de indisponibilidade de um servidor.
34
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.
35
Na Tabela 2 colocamos os resultados dos testes de desempenho realizados.
Tabela 2 Comparação de desempenho (Físico vs. Virtual)
Teste
CPU
 MIPS16
 MFLOPS17
 Cálculo do PI (4Mb)
Disco
 Driver Index
 Random Access
Memória
 Latency (Random Access)
 Speed Factor
Físico
Virtual
Software
5.7
5.97
3m 35s
3.41
3.55
3m 43s
Sandra
Sandra
Super PI
66,82 Mb/s
12 ms
54,11 Mb/s
17 ms
Sandra
Sandra
138 ns
91,5
180 ns
171,5
Sandra
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.
36
Neste experimento, semelhante ao MIPS, mas focado nas instruções de
ponto flutuante, também utilizamos o Sisosftware Sandra. Novamente a máquina virtual 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 PI 18 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...).
37
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 virtual (desempenho 30% inferior).
g) Memória - Speed Factor
O Speed factor é a razão entre a velocidade do cachê da CPU e a velocidade 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 diferentes 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á.
38
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, detalho 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, també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 aplicaçõ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
39
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 suficientes. Com um total de 3328Mb chegamos à conclusão que 4 Gb (4096 Mb) seriam 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
SVFW01
SVFW02
SVDB01
SVWEB01
SVMAIL01
FreeBSD 7
CentOS 5
OpenSolaris
Ubuntu 8
Windows 2003
Windows 2003 (reserva para o servidor físico)
Total
SVVM01
Memória (em Mb)
256
256
1024
256
512
1024
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 lados da DMZ, pois já tinha uma placa de rede on-board. O nome lógico deste computador 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, Microsoft Virtual Server e XEN. As características principais que levaram a escolha do
software foram: fabricantes de renome, custo, compatibilidade de hardware e siste-
40
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 utilizando 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 empresa 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 parecida 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 recentemente lançou uma versão do Windows 2008 exclusivamente para utilização do Hyper-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 possuem versões gratuitas.
41
4.1.2.3 Compatibilidade de hardware
Quanto à compatibilidade de hardware o VMWARE ESX e o XEN perderam para as outras duas opções. O VMWARE ESX é um sistema de alto desempenho e possui uma HCL (Hardware Compatibility List – Lista de compatibilidade de
hardware) menos flexível que os demais (alguns discos SATA, comuns nos computadores 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 maior 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 perfeitamente.
4.1.2.4 Suporte aos sistemas operacionais guest
O XEN só consegue virtualizar servidores com sistema operacional Windows 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 geral 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 gerenciar os recursos do sistema computacional como um todo
42
ressalva ao XEN, que depende do processador para Windows ou do Kernel modificado 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 possui versão tanto para Windows quanto para Linux. Isto é importante, pois o conhecimento 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
Fabricante
Reconhecido
Custo
Citrix XEN
√
Gratuito
MS Virtual Server
VMWare ESXi
VMWare Server
√
√
√
Gratuito
Gratuito
Gratuito
Nome
Compatibilidade Sistema Operacional
Hard/Soft
Host
Linux e
Restrições
Sistema Próprio
√
Apenas Windows
Restrições
Sistema Próprio
√
Windows e Linux
43
Dados os fatores apresentados, minha opção foi pelo VMWARE Server,
pois atende a todas as características necessárias: fabricado pela VMWARE (número 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 registro, você receberá a chave de ativação do software por e-mail. A instalação é simples, 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/IP 20 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 servidor, 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 passasse 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 interessam 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.
44
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 Hostonly 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.
45
•
VMnet0 em modo bridge ligada à placa de rede física que é conectada a Internet;
•
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.
46
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 nomes 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 configurada 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.virtualDev = "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 linha 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 incluí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.
47
•
Sistema operacional utilizado: observe que a instalação dos sistemas operacionais seguiu uma linha padrão, isto é, sem alterar as
configurações sugeridas pelos programas de instalação dos mesmos. Em um ambiente de produção real, que normalmente não utilizam 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 servidor 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 entre o ambiente interno (DMZ e LAN) e o ambiente externo (Internet), como destacado 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.
48
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.
49
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 segundo 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.
50
•
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 sysinstall ou alterando o arquivo /etc/rc.conf (ver Anexo C).
Por padrão, o computador conhece as rotas para as redes das placas conectadas a ele, como este computador não está conectado a rede LAN então foi necessá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 interno e externo.
•
FTP-Proxy: serviço necessário para publicar o serviço de FTP.
•
SSH: serviço que disponibiliza acesso remoto ao servidor.
51
•
PPP: serviço que efetua a discagem para Internet através de um modem 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 entre a DMZ e a LAN, conforme destaquei na Figura 4-4.
Figura 4-7 Diagrama físico da rede com o SVFW02 em destaque
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.
52
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 distribuiçã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 outra conectada a LAN (Vmnet2).
•
Um processador.
•
Um drive de DVD, necessário para instalação do SO.
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).
53
•
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 systemconfig-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 configuração serão visto na seção de segurança deste capítulo, ele foi habilitado 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].
•
SSH: serviço que disponibiliza acesso remoto ao servidor.
54
4.3.3 SVMAIL01
Este contempla os serviços de e-mail e resolução de nomes. Está localizado 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.
55
4.3.3.2
SVMAIL01: Recursos virtuais
Os seguintes recursos foram disponibilizados para a máquina virtual:
•
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 pouco 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.
•
Um drive de DVD, necessário para instalação do SO.
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 SVMAIL01.
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 comando netsh.
56
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 está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 nomes em endereços IP (e vice-versa) de um determinado domínio Internet (Ferreira, Rubens, 2003). É um serviço nativo do Windows, é adicionado 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 trabalho.
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 funcionalidades mínimas requeridas para testes do ambiente. Não recomendamos para um ambiente de produção, para estes seria uma melhor 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.
57
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.
58
4.3.4.2 SVWEB01: Recursos virtuais
Os seguintes recursos foram disponibilizados para a máquina virtual:
•
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 muito espaço (100 Mb são mais que suficientes), neste caso a maior preocupação reside na quantidade de arquivos que serão colocados no
FTP, mas em nosso caso alocamos apenas o necessário para as avaliações.
•
Uma placa de rede, para se conectar a DMZ (Vmnet1).
•
Um processador.
•
Um drive de DVD, necessário para instalação do SO.
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 Vmnet1, 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/interfaces (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 estática para a LAN, isto foi feito adicionando a seguinte opção no arquivo
/etc/network/interfaces:
59
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.
•
SSH: serviço que disponibiliza acesso remoto ao servidor.
Estes serviços não tiveram suas configurações padrão alteradas, pois somente foram utilizados nas avaliações de acesso.
60
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), sistema 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.
61
4.3.5.2 SVDB01: Recursos virtuais
Os seguintes recursos foram disponibilizados para a máquina virtual:
•
1024 Mb de memória RAM, sistema utiliza interface gráfica, sem nenhum 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.
•
Uma placa de rede, para se conectar a DMZ (Vmnet1).
•
Um processador.
•
Um drive de DVD, necessário para instalação do SO.
4.3.5.3 SVDB01: Configurações de rede
Este servidor terá apenas uma placa ligada a VMNet1 (DMZ), é identificada 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.
62
4. Configurar a placa com o programa “Network” no menu “System->Administration”.
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ática 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, instalado 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”.
63
4.4
SEGURANÇA
Nesta seção veremos como foram configurados os dois firewalls do trabalho, que dividi em duas subseções (firewall externo e interno) e em cada uma explanarei sobre a função, premissas, uma breve introdução ao software do firewall e, finalmente, a implantação.
4.4.1 Firewall externo (SVFW01)
O Firewall configurado no SVFW01 é o responsável por controlar o tráfego entre a Internet (ambiente externo) e a DMZ (ambiente interno) e vice-versa, conforme destacado na Figura 4-8. Através dele são providos serviços para usuários externos (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
64
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 exceção aos serviços disponibilizados pela DMZ, através do redirecionamento 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 utilizem o protocolo ICMP (por exemplo, ping33).
5. Serão guardados, através de um arquivo, todos os acessos negados e acessos via SSH ao firewall.
33
Ping é um comando usado pelo protocolo ICMP para testar a conectividade entre equipamentos.
65
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
Destino
Origem
Servidor /
Rede
Protocolo
INTERNET
DMZ
TCP
SVMAIL01
INTERNET
UDP
TCP
LAN
INTERNET
TCP
DMZ
TCP
ICMP
Estação do
Admin
Redirecionar para
Porta
Servidor
IP
80 (HTTP)
21 (FTP)
25 (SMTP)
110 (POP3)
53 (DNS)
25 (SMTP)
80 (HTTP)
443
(HTTPS)
21(FTP)
22 (SSH)
SVWEB01
SVWEB01
SVMAIL01
SVMAIL01
192.168.0.20
192.168.0.20
192.168.0.10
192.168.0.10
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 apenas 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 informado no site do projeto [17]. Este arquivo está dividido em sete partes, listadas na
seqüência:
66
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ção 34 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 redirecionamentos 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 interrompe imediatamente o processamento do pacote fazendo valer esta última que foi processada).
Com exceção das macros e tabelas, cada seção deve aparecer nesta ordem 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
67
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 alguns 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 iniciados 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].
68
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 conexã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 Internet utilizando uma linha telefônica.
Para iniciar a conexão precisamos configurar um cliente PPP 36 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.
69
/etc/ppp/ppp.conf (ver anexo C), que contém as informações do usuário, senha e outras 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 processo 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, listado na Tabela 6, que contém todas as linhas do arquivo. A seguir comento as configurações feitas no arquivo /etc/pf.conf.
Tabela 6 - Configuração do PF (/etc/pf.conf)
L Código
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# MACROS
ext_if = "tun0"
int_if = "em1"
rede_dmz = $int_if:network
rede_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 IP
proxyport = "8021" # ftp proxy port
proxy2 = "127.0.0.1"
proxyport2 = "2121"
icmp_types = { echorep, echoreq, timex, unreach }
web_server =
dns_server =
ftp_server =
pop3_server=
smtp_server=
"192.168.0.20"
"192.168.0.10"
"192.168.0.20"
"192.168.0.10"
"192.168.0.10"
# TABLES
# OPTIONS
set loginterface $ext_if
set block-policy return
set skip on lo
70
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
# SCRUB - Mata pacotes fragmentados que chegam a interface externa
scrub in on $ext_if
# QUEUING
# TRANSLATION
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
nat on $ext_if from $rede_lan to any -> $ext_if
nat 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 www
rdr on $ext_if proto tcp from any to $ext_if port smtp -> $smtp_server port smtp
rdr on $ext_if proto tcp from any to $ext_if port pop3 -> $pop3_server port pop3
# - Proxy ftp
rdr pass on $int_if proto tcp from any to any port ftp -> $proxy port $proxyport
rdr pass on $ext_if proto tcp from any to any port ftp -> $proxy2 port $proxyport2
# FILTERS
block in log
pass out keep state
anchor "ftp-proxy/*"
pass
pass
pass
pass
pass
in
in
in
in
in
on
on
on
on
on
$ext_if
$ext_if
$ext_if
$ext_if
$ext_if
inet
inet
inet
inet
inet
proto
proto
proto
proto
proto
tcp
tcp
tcp
tcp
tcp
from
from
from
from
from
any
any
any
any
any
to
to
to
to
to
$web_server port www flags S/SA synproxy state
$smtp_server port smtp flags S/SA keep state
$pop3_server port pop3 flags S/SA keep state
$ftp_server port ftp flags S/SA keep state
$ftp_server port ftp-data flags S/SA keep state
pass in on $int_if inet proto udp from $dns_server to any port 53
pass in quick on $int_if from $rede_dmz to $rede_lan
# - Regras para a estacao do Admin
pass in quick on $int_if inet proto icmp from $est_admin to any icmp-type $icmp_types
pass in log on $int_if inet proto tcp from $est_admin to any port ssh label "SSH - Admin"
# - Regras de saidas para os clientes
pass inet proto tcp from $rede_lan to
pass inet proto tcp from $pop3_server
pass inet proto tcp from $smtp_server
da rede
any port $client_out
to any port pop3
to any port smtp
# - Saida do Proxy FTP
pass 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 ajudam a simplificar a configuração do arquivo, por exemplo, a macro “est_admin” armazena 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 alterado 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.
71
•
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 Internet 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 endereç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 macro? Utilizar macros diferentes para protocolos diferentes que estão no mesmo servidor cria flexibilidade na manutenção do firewall, caso no futuro desmembrarmos o servidor de FTP do servidor HTTP precisaríamos apenas alterar o endereço de uma das macros ao invés de conferir todo o script.
•
37
pop3_server: endereço do servidor de POP3 SVMAIL01 (192.168.0.10).
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.
72
•
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 apenas 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 loopback, isto significa que pacotes gerados pelo próprio firewall não serão avaliados.
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 configuração do ftp-proxy (linhas 36-37), o NAT (linhas 39-40) e os redirecionamentos (linhas 42 a 49), estas partes estão detalhadas na seqüência:
•
Configuração do ftp-proxy: os comandos “nat-anchor “ftp-proxy/*”” e “rdr-anchor “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
73
são utilizadas pelo ftp-proxy (que controlam estados de conexões do ftpproxy), por exemplo.
•
NAT: faz com que os computadores da LAN e DMZ possam acessar a Internet 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 descrever 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 redirecionados 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 servidores 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 segundo 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).
74
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 entrando (“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 state”), a opção keep state serve para guardar o estado da conexão, é importante manter o estado de uma conexão que sai pelo firewall porque, normalmente, 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 adicionar 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 entrada (“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 é gerado um Log quando o usuário ou um sistema pára ou inicia ou service, o log contém o nome do service, 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
75
Na linha 63 temos a liberação para que o servidor SVMAIL01 possa consultar 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) vindo 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 sistema de proxy40 (no nosso caso é um software chamado ftp-proxy), ao invés do servidor 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 conectase a um servidor proxy, requisitando algum serviço, como um arquivo, conexão, website, ou outro recurso disponível em outro servidor.
76
ço do proxy e este mantém as conexões (keep state) para que, caso receba uma requisição a uma porta alta, ele consiga relacionar com a conexão criada anteriormente.
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 iniciado 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 requisições para o servidor 192.168.0.20 (SVWEB01)”.
4. Recarregar regras do firewall: com o comando “pfctl –ef /etc/pf.conf”.
77
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.
Figura 4-13 Diagrama físico da rede com o SVFW02 em destaque
4.4.2.1 Premissas (Regras)
As regras que foram criadas no firewall interno devem atender as seguintes expectativas:
1. Todo tráfego de entrada é bloqueado, com exceção das regras a
seguir.
78
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) serão liberadas para pacotes com origem na LAN e destino aos respectivos 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.
Tabela 7 - Regras do firewall SVFW02
Origem
Servidor / Rede
DMZ
INTERNET
LAN
SVMAIL01
SVDB01
SVFW02
Estação do
Admin
DMZ
Destino
Protocolo
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
ICMP
TCP
TCP
TCP
TCP
ICMP
Porta
80 (http)
443 (https)
21 (ftp)
53 (dns)
25 (smtp)
110 (pop3)
3306 (mysql)
22 (ssh)
22 (ssh)
3389 (rdp)
5800 (vnc-web)
5900 (vnc)
79
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 firewall, isto é, filtrar pacotes. Filter é a tabela padrão, caso não for informada 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 (passa pelo firewall), PREROUTING (todo tráfego que "sai" da máquina, incluindo 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.
80
•
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 diversas 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 regras, 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 encontrada no Anexo C.
4.4.2.3 Implantação
O firewall interno é bem mais simples que o externo, pois não é conectado a Internet, evitando os passos de discagem para a Internet. A implantação do firewall interno teve os seguintes passos: habilitação do iptables, habilitação do gateway e configuração do firewall. Veremos alguns detalhes de cada um dos passos.
81
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 instalados 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/myfirewall, cuja listagem é apresentada na Tabela 8, que inclui as regras para o seu funcionamento. 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 novas regras, pois assim ele limpa todas as regras e adiciona as novas. A seguir farei
comentários sobre o conteúdo do arquivo myfirewall.
82
Tabela 8 - Configuração do iptables (/etc/rc.d/init.d/myfirewall)
L Código
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
#!/bin/bash
#
# /etc/rc.d/init.d/myfirewall
# Flush all current rules from iptablew
iptables -F
modprobe ip_conntrack
modprobe ip_conntrack_ftp
# VARIAVEIS
EST_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 chains
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Set access for localhost
iptables -A INPUT -i lo -j ACCEPT
# Aceitar pacotes com conexoes ja estabelecidas
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# ################################################################
#
# Liberar acessos para a estacao de Administracao
#
(mantendo log de acessos)
#
# ################################################################
# - Acesso Remoto ao Firewall
iptables -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 DMZ
iptables -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 ACCEPT
iptables -A FORWARD -p icmp -s $EST_ADMIN_IP --j ACCEPT
# #######################################################
83
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
#
#
Liberar portas Rede Interna -> DMZ
#
# #######################################################
# - DNS
iptables -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
# - FTP
iptables -A
iptables -A
iptables -A
iptables -A
iptables -A
iptables -A
-j ACCEPT
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
FORWARD
FORWARD
FORWARD
FORWARD
FORWARD
FORWARD
-p tcp --dport 21 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-p tcp --sport 21 -m state --state ESTABLISHED,RELATED -j ACCEPT
-p tcp --sport 20:21 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-p tcp --dport 20:21 -m state --state ESTABLISHED -j ACCEPT
-p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
-p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED
# - MySQL
iptables -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 ACCEPT
iptables -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 Connection Tracking42 [10].
Entre as linhas 11 e 21, são definidas variáveis que simplificam a reconfiguração do arquivo, por exemplo, a variável “EST_ADMIN_IP” é utilizada várias vezes 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.
84
firewall (FORWARD) e permitidos (ACCEPT) os pacotes que estão saindo (OUTPUT) do firewall.
Na linha 29 é concedia permissão para pacotes gerados pelo próprio firewall, isto é, pela interface de loopback.
Nas linhas 32 e 33 é permita a passagem de pacotes que já tem uma conexã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óxima 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 linhas, 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 regra de Log coincide com o pacote analisado o log é gerado e depois segue para outras regras, se colocasse a regra que libera a porta antes da linha que gera o log en -
85
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 servidor 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 inclusive servidores da Internet. No caso de servidores que estejam na Internet a requisiçã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.
86
5 EXPERIMENTOS
Neste capítulo valido e evidencio que as premissas propostas para os firewalls foram implementadas com sucesso. Dividi este capítulo em três seções sendo:
•
5.1) Regras do SVFW01: onde fiz avaliações das regras implementadas neste firewall, isto é, se está definido nas regras que a porta
HTTP está liberada então verifiquei se esta porta está realmente liberada.
•
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
87
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 é utilizada 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 possui uma interface de rede on-board, conectada ao modem ADSL, e uma interface 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 firewalls possuem regras mais flexíveis para este computador, pois é através
dele que o administrador do ambiente monitora e configura os firewalls. Foi ligado à 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.
88
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 (Internet, SVMAIL01, LAN e estação do administrador) e avaliei os serviços necessários a
cada uma das origens.
89
Tabela 9 - Regras do firewall SVFW01
Destino
Origem
Servidor /
Rede
Protocolo
INTERNET
DMZ
TCP
SVMAIL01
INTERNET
UDP
TCP
LAN
INTERNET
TCP
DMZ
TCP
ICMP
Estação do
Admin
Redirecionar para
Porta
Servidor
IP
80 (HTTP)
21 (FTP)
25 (SMTP)
110 (pop3)
53 (DNS)
25 (SMTP)
80 (HTTP)
443
(HTTPS)
21(FTP)
22 (SSH)
SVWEB01
SVWEB01
SVMAIL01
SVMAIL01
192.168.0.20
192.168.0.20
192.168.0.10
192.168.0.10
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 Figura 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ários, 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-
90
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 Internet 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, indicando que o acesso funcionou corretamente, conforme ilustrado na Figura 5-16.
91
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 computador remoto um prompt de comandos e utilizei o programa cliente “FTP”. Na Figura 5-17 são demonstrados os comandos que foram executados para avaliar o funcionamento 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: efetuado 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 conexão.
92
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 sucedido na abertura da conexão com o servidor. Isto é indicado pela mensagem “220 cederj.tcc ESMTP Server ready.”, então executei o comando “quit” para encerrar a conexão.
93
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 utilizei 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 comando “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.".
94
Figura 5-19 - Evidência de acesso POP3
5.1.1.5 Acessos bloqueados
Apenas para complementar estas avaliações, também, efetuei experimentos 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 57.
95
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
96
5.1.2.1 DNS
No SVMAIL01 existe o serviço de DNS instalado. Quando algum computador 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 passagem 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 requisição não chegou ao servidor (foi bloqueado pelo SVFW01).
Depois reabilitar a regra e tentamos novamente, desta vez o servidor retornou o endereço IP relativo ao www.cederj.edu.br: 200.156.70.10 (destacado em verde na Figura 5-22) evidenciando o funcionamento da liberação.
97
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 externo 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.yahoo.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 “Connect Failed”. No final apenas digitei “quit” para encerrar a conexão.
98
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.
99
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 esperado o SVFW01 utilizou o seu IP público (189.105.8.42) para acessar a Internet.
100
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 acessei 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.
101
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 arquivos do sistema operacional Red Hat. Na Figura 5-27 podemos visualizar os comandos executados, que detalho a seguir:
102
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.
3. Um comando para confirmar o estabelecimento da conexão: efetuado 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 conexã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
103
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 529.
104
Figura 5-29 - Evidência estação do administrador acessando SVFW01 via SSH
Conforme configurado no PF é gerado um log toda vez que o administrador 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.
105
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 pacote para o host 192.168.0.100 apenas uma vez “-n 1”) e recebeu a resposta do servidor “Reply from 192.168.0.100: bytes=32 time<1ms TTL=63”. Logo após utilizei o comando “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 ferramentas 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-
106
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
107
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.
Tabela 10 - Regras do firewall SVFW02
Origem
Servidor / Rede
DMZ
INTERNET
LAN
SVMAIL01
SVDB01
SVFW02
Estação do
Admin
DMZ
Destino
Protocolo
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
ICMP
TCP
TCP
TCP
TCP
ICMP
Porta
80 (HTTP)
443 (HTTPs)
21 (FTP)
53 (DNS)
25 (SMTP)
110 (POP3)
3306 (MySql)
22 (SSH)
22 (SSH)
3389 (RDP)
5800 (VNC-web)
5900 (VNC)
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).
108
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 destino 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, utilizei 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.
109
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 enquanto, 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 localizado 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”.
110
2. Autenticação: foram solicitados usuário e senha, que depois de informados, retornou à mensagem “230 Login successful”, indicando
que já estamos conectados e autenticados
3. Um comando para confirmar o estabelecimento da conexão: efetuado 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 servidor de SMTP, localizado na DMZ, realizei o experimento descrito na seqüência.
111
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 computador da origem dos experimentos), iniciei a conexão com o comando “telnet svmail01.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 encerrar 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 comando “ipconfig | find “.10””, de forma a obter o IP do computador da origem dos experimentos, depois iniciei a conexão com o comando “telnet svmail01.cederj.tcc 110”
112
(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 endereç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 resolver o nome svdb01.cederj.tcc, isto significa receber como retorno o IP do servidor,
no caso 192.168.0.30.
113
O experimento foi realizado da seguinte forma: a partir do prompt de comandos 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 apresentado 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 sucesso da conexão (destacados na Figura 5-38).
114
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 acessos 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 administrador.
Para a estação do administrador foram inseridas no firewall SVFW02 regras que permitem:
115
Acesso via SSH ao servidor SVFW02: necessário para acessar remotamente 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 servidores 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 administrador e com destino o próprio SVFW02.
116
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”. Neste experimento utilizei o usuário root e, também, digitei o comando “uname –a“ apenas para confirmar o nome do servidor que esta acessando (svfw02.cederj.tcc), conforme evidenciado na Figura 5-40.
Figura 5-40 - Evidência estação do administrador acessando o SVFW02 via SSH
117
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 utilizei 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 mensagens “request time out”.
Figura 5-41 - Evidência estação do administrador testando conectividade com SVFW02 utilizando ferramentas ICMP
118
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 servidores da DMZ. Para o experimento utilizei o software Putty tentando acessar o servidor 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 recebería uma mensagem de “Connection time out”), utilizei o usuário “fabiojr” e també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
119
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 firewall SVFW02, para as conexões oriundas da estação do administrador com destino 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 deseja 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 sucesso do experimento, pois, caso contrário, receberia uma mensagem “This computer can’t connect to the remote computer”). Neste momento, inseri o usuário “Administrator” e sua senha, clicando em “OK” foi aberta a console do servidor, conforme
evidenciado pela Figura 5-43.
120
Figura 5-43 - Evidência estação do administrador acessando servidor na DMZ via RDP
121
5.2.2.5 DMZ – VNC
Existem versões do VNC para vários sistemas operacionais, no OpenSolaris é 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 efetuada a conexão com o servidor (evidência da abertura da porta 5900), conforme Figura 5-44. Repare que no SVDB01 é gerado um alerta informando que existe um outro usuário acessando remotamente o servidor, no caso com endereço IP 10.0.0.10
(estação do administrador).
122
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 descobrir 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.
123
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.
124
5.3.1.1 A partir da LAN
A partir de uma estação localizada na rede interna (qualquer uma localizada na área verde da Figura 5-45) foi executado o programa NMAP. com os seguintes parâmetros “nmap 10.0.0.1 -PN”. O NMAP verifica se o servidor está ativo disparando 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 fizesse 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.
125
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, conforme representado na Figura 5-47, a estação está inserida na área de LAN, então possui todos os privilégios da LAN e também alguns privilégios necessários para administrar remotamente os servidores.
126
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 remotamente o servidor.
Figura 5-48 - Portscan na interface eth1 do SVFW02 a partir da estação do administrador
127
5.3.2 Portscan na interface eth0 do servidor SVFW02
Neste experimento avaliei se existem portas abertas no SVFW02 com origem na DMZ em direção a LAN, para isto fiz um portscan a partir do servidor SVMAIL01 (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
128
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
129
5.3.4 Portscan na interface em0 do servidor SVFW01
Finalmente, neste último experimento avalio a interface externa do servidor 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 procedimento 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, ligamos 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.
130
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 observei 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 externo, conforme premissas definidas para o firewall SVFW01 evidenciado o sucesso do
experimento.
131
Figura 5-55 - Portscan na interface em0 do SVFW01 a partir da Internet "simulada"
132
CONCLUSÕES
Neste trabalho demonstrei a utilização da tecnologia de virtualização atravé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 partes 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 ambientes 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 analisando, por exemplo, o formato dos pacotes tentando identificar possí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 ficam dependendo do mesmo equipamento, é importante ter uma forma de manter uma contingência para o caso de falha no equipamento. Ter um servidor host adicional, contendo uma réplica de todos os servidores do principal mantendo a sincronização através de
ferramentas de cluster dos sistemas operacionais guest, é uma alternativa.
133
•
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 instalados apenas para ajudar nos testes dos firewalls. Indicamos uma
melhor implantação dos serviços de e-mail, criação de um site institucional ou de colaboração (utilizando ferramentas como Sharepoint
e Plone).
Este trabalho me serviu para conhecer outros sistemas operacionais, houve a curiosidade no passado, mas instalar um sistema operacional e utilizá-lo, sem
compromisso, é muito diferente de instalar um sistema operacional e ter o compromisso 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.
134
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. Disponível em <http://computerworld.uol.com.br/mercado/2008/03/12/a-vmwarecontra-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.200704-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. Dicas-L. (publicado em 22/03/2006). Disponível em < http://www.dicasl.com.br/dicas-l/20060322.php>. Acessado em 20/09/2008.
135
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.centos.org/HowTos/Network/IPTables>. Acessado em 20/09/2008.
13. NETFILTER. IPTABLES. Disponível em <http://www.netfilter.org/projects/iptables/index.html>. Acessado em 01/09/2008.
14. NETFILTER. NETFILTER. Disponível em < http://www.netfilter.org/ >. Acessado em 01/09/2008.
15. NMAP, Nmap Featured in The Matrix Reloaded. Disponível em <http://insecure.org/>. Acessado em 05/10/2008.
16. PUTTY. PuTTY Download Page. Disponível em < http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html>. Acessado em 01/10/2008.
17. OpenBSD. PF: OpenBSD Packet Filter. Disponível em <http://www.openbsd.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/200511/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.vmware.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.xensource.com/xenwiki/HVM_Compatible_Processors>. Acessado em
03/10/2008.
136
137
ANEXOS
138
ANEXO A – COMANDOS ÚTEIS
FreeBSD:
Comandos Gerais
Comando
/etc/netif {start | stop }
Descrição
Observação
Iniciar, parar interfaces de Útil para quando o IP do
sysinstall
rede.
servidor for alterado
Configurar diversos com-
df
ponentes do sistema
Verifica espaço livre nos
/etc/rc.d/PF {start | stop }
discos
Iniciar, parar o firewall(PF)
Comandos úteis do PF
Opções do pfctl
pfctl -f /etc/pf.conf
pfctl -nf /etc/pf.conf
pfctl -Nf /etc/pf.conf
pfctl -Rf /etc/pf.conf
Ação
Carrega o arquivo pf.conf
Analisa o arquivo, mas não o carrega
Carrega apenas as regras NAT do arquivo
Carrega apenas as regras de filtragem do arquivo
139
CentOS:
Comandos Gerais
Comando
Descrição
System-config-network
Configurar placas de rede.
Service serviço {start | Parar serviços
Observação
stop}
Service iptables stop
Exemplos:
Service network start
ntsysv
Diversas configurações do
sistema
Comandos úteis do IPTABLES
Opções do iptables
Iptables -L
Iptables -F
Ação
Lista as regras atuais
Remove todas as regras existentes (não altera as
Iptables -P
regras inseridas com –P – política)
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.
140
Ubuntu:
Comando
post-up route
add
Descrição
Observação
-net Adicionar uma rota estáti- Editar
o
192.168.0.0/16
gw ca.
192.168.10.1
Sudo <comando>
arquivo
etc/network/interfaces e inserir o comando
Executar
comando
com
permissões do root
OpenSolaris:
Comando
svcadm disable
Descrição
Observação
svc:/net- Desabilitar NWAM (confi-
work/physical:nwam
guração
automática
su
rede)
Utilizar super usuário
de
Windows Server 2003:
Comando
Descrição
Observação
route add <destino> mask Adiciona uma rota, com a Exemplo:
<mascara> <gateway> -p
opção –p a configuração route add 10.0.0.0 mask
não se perde após um rei- 255.255.255.0
nicio
192.168.0.200 -p
141
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 provedores 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.
142
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 milioná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, copiar, distribuir, estudar, compartilhar, alterar e melhorar seu software por qualquer motivo, sem ter que pagar taxas de licenças.
2. Todo usuário de computador deve poder usar seu software na língua 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 Operacional Comercial). É um projeto criado pela Sun Microsystems para criar uma comuni dade de desenvolvedores em torno do sistema operacional Solaris.
143
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/ .
144
ANEXO C – ARQUIVOS DE CONFIGURAÇÃO
•
SVFW01
o /etc/rc.conf
# Configuracoes de Rede
ifconfig_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"
# Teclado
keymap="us.iso"
# Habilitar SSH
sshd_enable="YES"
# Configuracoes do PF
pf_enable="YES"
pf_rules="/etc/pf.conf"
pf_flags=""
pflog_enable="YES"
pflog_logfile="/var/log/pflog"
pflog_flags=""
ftpproxy_enable="YES"
o /etc/ppp/ppp.conf
default:
set device PPPoE:em0:ISP
enable lqr
enable tcpmssfixup
set
set
set
set
set
lqrperiod 6
mut 1492
mru 1492
timeout 0
log Phase tun
nat enable yes
add default HISADDR
enable dns
#
#
#
#
#
#
Enable PF (load module if required)
rules definition file for pf
additional flags for pfctl startup
start pflogd(8)
where pflogd should store the logfile
additional flags for pflogd startup
145
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 interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface 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