INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA
CATARINENSE - CAMPUS SOMBRIO
JORGE LUIZ BORGES CORRÊA JUNIOR
SHIRLEY MIRIAN SILVA DA SILVA
IMPLEMENTAÇÃO DE FIREWALL DE ALTA DISPONIBILIDADE UTILIZANDO O
SOFTWARE HEARTBEAT
Sombrio (SC)
2013
JORGE LUIZ BORGES CORRÊA JUNIOR
SHIRLEY MIRIAN SILVA DA SILVA
IMPLEMENTAÇÃO DE FIREWALL DE ALTA DISPONIBILIDADE UTILIZANDO O
SOFTWARE HEARTBEAT
Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção do título de Tecnólogo em Redes de Computadores, do Instituto Federal de Educação Ciência e Tecnologia Catarinense – Campus Sombrio.
Orientador: Prof. MsC. Jackson Mallmann
Coorientador: Prof. MsC. Jéferson Mendonça de
Limas
Sombrio (SC)
2013
JORGE LUIZ BORGES CORRÊA JUNIOR
SHIRLEY MIRIAN SILVA DA SILVA
IMPLEMENTAÇÃO DE FIREWALL DE ALTA DISPONIBILIDADE UTILIZANDO O
SOFTWARE HEARTBEAT
Esta Produção Técnica-Científica foi julgada
adequada para obtenção do título de Tecnólogos em
Redes de Computadores e aprovada pelo Curso de
Tecnologia em Redes de Computadores do Instituto
Federal de Educação, Ciência e Tecnologia
Catarinense – Campus Sombrio
Área de Concentração: Sistemas Distribuídos
Sombrio , 07 de dezembro de 2013.
Prof. MsC. Jackson Mallmann Instituto Federal Catarinense – Campus Sombrio
Orientador
Prof. MsC. Alexssandro Cardoso Antunes Instituto Federal Catarinense – Campus Sombrio
Membro
Prof. MsC. Daniel Fernando Anderle Instituto Federal Catarinense – Campus Sombrio
Membro
Eu Jorge, dedico este trabalho
especialmente em memória a avó
Bernadete, a Vó Deta, que embora meu
tempo com ela tivesse sido curto, foi o
suficiente para ela me fazer entender o
quanto é importante nunca parar de
estudar. Dedico este também a minha
esposa Mônica e minha filha Júlia,
maravilhosa família que sempre me deu
apoio, desde começo neste curso.
Eu Shirley, dedico este trabalho a minha
família, principalmente a minha mãe,
Neusa, pelo incentivo e apoio. Aos meus
amigos que me deram muita força e aos
meus professores por tudo que me
ensinaram.
AGRADECIMENTOS
Eu Jorge, agradeço a Deus pela saúde e pelas bênçãos ao longo deste caminho.
Agradeço especialmente as minhas meninas, Mônica e Júlia, pelo apoio e
compreensão nos momentos de ausência e madrugadas em claro. A todos os meus
familiares que sempre me incentivaram a completar este curso. Merecem também
serem lembrados aqui, meus colegas de profissão: Borba, Nagel, Gonzaga, Passos,
Fagner e Moro, vocês todos sem dúvida nenhuma, foram grandes parceiros nesta
minha empreitada. Muito obrigado a todos.
Eu Shirley, primeiramente gostaria de agradecer a Deus pela força e por não ter me
deixado desistir nos momentos mais difíceis. Aos meus familiares e amigos por
compreenderem a minha ausência. Também quero agradecer ao meu professor
orientador Jackson Mallmann e ao meu coorientador Jéferson Mendonça de Limas,
que me ajudaram e incentivaram na conclusão deste trabalho.
“Ciência da Computação está tão relacionada aos computadores quanto a
Astronomia aos telescópios, Biologia aos microscópios, ou Química aos tubos de
ensaio. A Ciência não estuda ferramentas. Ela estuda como nós as utilizamos, e o
que descobrimos com elas.”
―Edsger Dijkstra
RESUMO
Com o avanço tecnológico os firewalls se tornaram uma camada importante da segurança em redes de computadores, desta forma se caso o firewall, por algum motivo, deixar de funcionar, a rede por trás deste, esta sujeita a perder sua comunicação com a rede pública, ter a segurança comprometida ou parar de funcionar os serviços disponibilizados, neste contexto o objetivo do presente trabalho é implementar um firewall no ambiente de alta disponibilidade, utilizando o software Heartbeat. Para alcançar tais objetivos, o trabalho foi elaborado e desenvolvido com base na pesquisa bibliográfica, aplicada e experimental, e através do uso destes métodos de pesquisa foi possível realizar o estudo necessário e montar o respectivo cenário. Para a implementação do ambiente de alta disponibilidade, foram utilizados dois computadores, na qual um responde por firewall ativo (o primário) e o outro é determinado como firewall passivo (o backup), e em ambos foram instalados o software Heartbeat. A implementação foi realizada em computadores reais em laboratório cedido pelo IFC-Sombrio. Após a realização de testes, foi possível validar a implementação do firewall de alta disponibilidade, o qual correspondeu satisfatoriamente, cumprindo requisitos necessários para tal denominação. Palavras-chave: firewalls – alta disponibilidade - Heartbeat
ABSTRACT
With technological advancement firewalls have become an important layer of security in computer networks, so if If the firewall, for some reason, stops working, the network behind this, is subject to losing their communication with the public, have security compromised or stop functioning services available, in this context the aim of this work is to implement a firewall in high-availability environment by using the Heartbeat software. To achieve these objectives, the study was designed and developed based on literature research, experimental and applied , and through the use of these search methods it was possible to carry out the necessary study and assemble their scenario. For the implementation of high-availability environment, two computers, the accounts for which a firewall active were used and the other is given as a backup firewall, and both were installed Heartbeat software. The implementation was done on real computer lab donated by IFC - Sombrio. After testing, it was possible to validate the implementation of high-availability firewall, which corresponded satisfactorily fulfilling the requirements for such designation. Keywords : Firewalls – High-Availability – Heartbeat
LISTA DE SIGLAS
ARPA - Advanced Research Projects Agency
CAT - Categoria
EAFS - Escola Agrotécnica Federal de Sombrio
IBM - International Business Machines
IFC - Instituto Federal De Educação, Ciência E Tecnologia Catarinense
IEEE - Institute of Eletrical and Eletronic Engineers
LAN - Local Area Networks
MAN - Metropolitan Area Network
NAT - Network Address Translation
OSI - Open Systems Interconnection
PCI - Peripheral Component Interconnect
SSH - Secure Shell
TCC - Trabalho de conclusão de curso
TCP/IP - Transmission Control Protocol/Internet Protocol
TOS - Tipo de Serviço
UTP - Unshielded Twisted Pair
WAN - Wide Area Network
LISTA DE FIGURAS
Figura 01 – Modelo TCP/IP ...................................................................................... 17
Figura 02 - Modelo de Referência OSI ..................................................................... 19
Figura 03 - Disposição de um firewall numa rede. .................................................... 21
Figura 04 - Instalação do Conntrack-tools. ............................................................... 26
Figura 05 - Instalação do OpenSSH. ........................................................................ 27
Figura 06 - Instalação do Rsync. .............................................................................. 27
Figura 07 - Laboratório de testes. ............................................................................. 30
Figura 08 – Placa de rede PCI. ................................................................................ 32
Figura 09 – Placa de rede PCI-express .................................................................... 32
Figura 10 - Ordem dos pares .................................................................................... 33
Figura 11 - Topologia lógica do firewall de alta disponibilidade. ............................... 34
Figura 12 - Reprodução do script do firewall. ........................................................... 37
Figura 13 - Instalação do Heartbeat ......................................................................... 37
Figura 14 – Parâmetros de configuração do Heartbeat. ........................................... 38
Figura 15 – Arquivo authkeys. .................................................................................. 39
Figura 16 - Arquivo é o haresource. ......................................................................... 39
Figura 17 – Reinicialização do Heartbeat. ................................................................ 40
Figura 18 - Configuração do conntrackd. ................................................................. 40
Figura 19 - Log firewall ativo. ................................................................................... 43
Figura 20 - Log do firewall passivo assumindo o serviço. ....................................... 44
Figura 21 - Cache interno de conexões ativas do firewall ativo. .............................. 45
Figura 22 - Cache externo do firewall passivo de conexões provenientes do firewall
ativo. ......................................................................................................................... 45
SUMÁRIO
1 INTRODUÇÃO ....................................................................................................... 12
2 OBJETIVOS ........................................................................................................... 13
2.1 Objetivo geral .................................................................................................... 13
2.2 Objetivos específicos........................................................................................ 13
3 REFERENCIAL TEÓRICO ..................................................................................... 14
3.1 Redes de computadores ................................................................................... 14
3.1.1 LAN .................................................................................................................. 15
3.1.2 WAN ................................................................................................................. 15
3.1.3 MAN ................................................................................................................. 15
3.1.4 Modelos de referência ...................................................................................... 16
3.2 Firewall Netfilter Iptables .................................................................................. 19
3.3 Clusters .............................................................................................................. 21
3.4 Alta Disponibilidade .......................................................................................... 22
3.4.1 Camada de abstração ...................................................................................... 23
3.5 Heartbeat ............................................................................................................ 24
3.6 Conntrack-tools ................................................................................................. 25
3.7 OpenSSH ............................................................................................................ 26
3.8 Rsync.................................................................................................................. 27
4 MATERIAIS E MÉTODOS ..................................................................................... 28
4.1 Laboratório de testes ........................................................................................ 28
4.2 Equipamentos utilizados .................................................................................. 30
4.2.1 Computadores .................................................................................................. 30
4.2.2 Dispositivo de comutação ................................................................................. 31
4.2.3 Placas de Rede ................................................................................................ 31
4.2.4 Cabeamento e conectorização ......................................................................... 33
4.3 Topologia do firewall de alta disponibilidade ................................................. 33
4.4 Implementação do firewall de alta disponibilidade ........................................ 35
4.4.1 Linux Ubuntu Server 12.04 ............................................................................... 35
4.4.2 Firewall Netfilter Iptables .................................................................................. 36
4.4.3 Heartbeat .......................................................................................................... 37
4.4.4 Conntrack-tools ................................................................................................ 40
4.4.5 OpenSSH ......................................................................................................... 41
4.4.6 Rsync ............................................................................................................... 41
4.5 Testes realizados .............................................................................................. 42
5 RESULTADOS E DISCUSSÃO ............................................................................. 43
5.1 Testes simulando eventuais falhas ................................................................. 43
6 CONSIDERAÇÕES FINAIS ................................................................................... 47
REFERÊNCIAS ......................................................................................................... 49
12
1 INTRODUÇÃO
Nas primeiras décadas da existência das redes de computadores, a
segurança dos dados não era algo que necessitava de um cuidado específico, pois
as redes eram utilizadas apenas por pesquisadores e para compartilhamento de
alguns dispositivos. Porém à medida que as redes foram se desenvolvendo e
evoluindo, junto com essa evolução aumentou-se do fluxo de dados, pois passaram
a ser utilizas para inúmeras atividades (TANENBAUM, 2003).
É de fato, como afirmou Tanenbaum (2003), perceptível o crescimento das
redes de computadores e a Internet. Dados da União Internacional das
Telecomunicações apontam que no Brasil existem mais de 106,3 milhões de
computadores conectados na Internet, demonstrando, no cenário nacional, a
abrangência atual que chegou as redes de computadores (TELEBRASIL, 2013).
Esses milhões de computadores conectados à Internet estão, muitas vezes,
utilizando serviços disponibilizados por servidores como de e-mail, web sites,
repositório de arquivos ou vídeos, redes sociais, mensagens instantâneas, etc.
Oggerino (2001) afirma que os usuários desses serviços querem que eles estejam
disponíveis o tempo todo, pois muitas vezes dependem deles para trabalhar, estudar
e pesquisar. Tendo em vista todo este avanço tecnológico e a necessidade de
manter um sistema o mais disponível possível para os usuários, o presente trabalho
buscará apresentar de forma clara e objetiva os aspectos e características do
funcionamento de um firewall de alta disponibilidade, fazendo uso do software
Heartbeat do projeto Linux-HA (www.linux-ha.org).
Para melhor entendimento, este trabalho encontra-se dividido em seis
capítulos, iniciando por esta introdução que compõe o primeiro capitulo, em seguida
no segundo capítulo são apresentado os objetivos pretendidos com o presente
trabalho, posteriormente encontra–se o terceiro capítulo, o qual apresenta o
referencial teórico, em seguida no quarto capítulo são apresentados os materiais e
métodos utilizados, para então apresentar os resultados e discussão da aplicação do
objetivo do trabalho. Finalizando com considerações finais, onde os autores expõem
suas observações com base nos resultados obtidos.
13
2 OBJETIVOS
2.1 Objetivo geral
Implementar um Firewall de alta disponibilidade utilizando o software
Heartbeat.
2.2 Objetivos específicos
Para atingir o objetivo geral proposto, foram estabelecidos os seguintes
objetivos específicos:
• Realizar revisão bibliográfica sobre os assuntos envolvidos no do objetivo
geral;
• Implementar dois Firewalls Netfilter Iptables em Sistema Operacional Ubuntu
Server (versão 12.04), software Heartbeat (versão 3.0.5), responsável pelo
ambiente de alta disponibilidade e o software Rsync (versão 3.1.0) para
sincronização de arquivos de regras do Firewall;
• Demonstrar a ocorrência de falhas;
• Validar a implementação do ambiente de alta disponibilidade proposto,
através de testes.
14
3 REFERENCIAL TEÓRICO
Esta seção irá tratar dos assuntos abordados no decorrer desta pesquisa,
conceituar, com base bibliográfica, termos relacionados a redes de computadores e
área de concentração a qual este trabalho se relaciona.
3.1 Redes de computadores
As primeiras redes de computadores, de acordo com Comer (2007), foram
desenvolvidas com o intuito de realizar o compartilhamento de recursos como
impressoras e servidores de arquivos, de forma que os computadores que
estivessem presentes em uma mesma rede pudessem ter acesso a um mesmo
dispositivo ou recurso que estivesse sendo compartilhado.
As redes de computadores foram desenvolvidas visando permitir a troca de
informações entre dispositivos que pertencessem ao meio físico. Meios físicos são
todos os meios capazes de transmitir sinais de luz, elétrico ou de rádio. Para a
implementação de uma rede de computadores, existem padrões elaborados por
entidades como o Institute of Eletrical and Eletronic Engineers (IEEE), que possuem
o objetivo de padronizar a forma de realizar tais implementações (SIQUEIRA, 2010).
Entre estes padrões, estão as formas de como um dispositivo irá se
comunicar com outro; convenções que regem a comunicação num meio físico, e que
vão possibilitar aos envolvidos na transmissão (transmissor e receptor), codificarem
sua transmissão em sinais, de acordo com o meio físico, e decodificarem os sinais
para compreenderem a transmissão recebida. Estas convenções são chamadas de
protocolos de comunicação (TANENBAUM, 2003; TANENBAUM e VAN STEEN,
2007).
Kurose (2010) e Coulouris (2013) concordam que as redes de computadores
mudaram a forma com que as pessoas, empresas e instituições estão se
comunicando. A responsável por essa mudança é a rede mundial de computadores
a Internet.
Conforme Sousa (2009), as redes públicas surgiram nas décadas de 70 e 80
sendo utilizadas inicialmente por empresas para realizar comunicações comerciais.
Comer (2007), afirma que tais redes podem ser definidas como uma estrutura,
na qual é composta por diversos equipamentos que colaboram para que as
15
informações cheguem ao seu destino. A Internet é uma rede que é responsável por
realizar a interconexão de dispositivos computacionais e que possui amplitude a
nível mundial e que abrange inúmeros e diferentes assuntos (SOUSA, 2009).
Analisando o entendimento de Comer (2007) e Sousa (2009), internet pode
ser definida como uma grande rede, formada pela interconexão de diversas outras
redes, distribuídas globalmente, podendo estas ser redes locais, metropolitanas e
continentais.
3.1.1 LAN
Tanenbaum (2003) e Kurose (2010) afirmam que as Local Area Networks ou
LANs, são redes privadas que possuem um tamanho limitado, ou seja, estão
localizadas em um determinado local geográfico. Estas redes são responsáveis por
permitirem o acesso dos usuários, assim como a realização do compartilhamento de
recursos e a troca de informações.
3.1.2 WAN
Segundo Moraes (2010), as Wide Área Network (WAN) ou redes
geograficamente distribuídas são redes de computadores que abrangem um amplo
espaço geográfico, ou seja, são definidas como redes de longa distância. Moraes
(2010) ainda afirma, que tais redes possuem protocolos específicos e que os dados
trafegam a uma velocidade de transmissão menor do que nas LANs a nível de
usuário.
3.1.3 MAN
De acordo com Stallings (2005), as Metropolitan Area Network, são redes
metropolitanas que servem de intermediário entre as redes LAN e WAN. As MANs
são utilizadas em áreas metropolitanas por clientes que necessitam de maiores
capacidades de transmissão, garantindo um menor custo e melhor eficiência.
16
3.1.4 Modelos de referência
Assim como todos os componentes de uma rede de computadores devem ser
desenvolvidos de acordo com uma determinada padronização, o envio e
recebimento de dados também devem seguir um modelo de referência. O modelo de
referência padrão para interconexão e endereçamento de rede é o Transmission
Control Protocol/Internet Protocol (TCP/IP) (SOUSA, 2009).
De acordo com Sousa (2009), a arquitetura TCP/IP é consequência de um
projeto elaborado pela Advanced Research Projects Agency (ARPA), no ano de
1960, com intuito de desenvolver uma arquitetura de dados aberta, que fosse capaz
de possibilitar a interligação das redes com dispositivos, mesmo que estes
possuíssem uma arquitetura de hardware ou software diferente.
De acordo com Sousa (2009) TCP/IP é dividido em quatro camadas que são
elas:
Camada física e enlace: é formada por hardware, ou seja, possui as
características físicas dos equipamentos. Nesta camada o nível de
enlace, é onde estão os protocolos de enlace para o acesso através do
meio físico;
Camada de rede ou internet: Nesta camada ocorre a especificação do
melhor caminho para os pacotes e os endereços lógicos tanto de
origem como de destino;
Camada de transporte: Possui o objetivo de realizar a conexão
confiável, esta camada é responsável por analisar a perda de pacotes,
ou seja, determina como se dará uma sessão entre duas estações;
Camada de aplicação: É responsável pela comunicação de aplicativos,
ou seja, é nesta camada onde estão os protocolos no qual são
responsáveis pela comunicação destas aplicações.
A figura 01 ilustra como fica a divisão das quatro camadas que compõem o
modelo de referência TCP/IP.
17
Figura 01 – Modelo TCP/IP
Fonte: Adaptado de Odom.
Assim como o TCP/IP é um padrão para o envio e recebimento de dados, de
acordo com Torres (2001), o Open Systems Interconnection (OSI) é um modelo de
referência que foi desenvolvido pela International Standards Organization (ISO) com
o intuito de facilitar a interconexão das redes computadores, pelo fato de que as
tecnologias desenvolvidas na época suportavam apenas as tecnologias do mesmo
fabricante. Este modelo de referência para protocolos é composto por sete camadas,
que são elas: aplicação, apresentação, sessão, transporte, rede, enlace de dados e
física.
Segundo Torres (2001), para que ocorra a transmissão dos pacotes, cada
camada que compõe o modelo é encarregada de pegar os dados que chegarão a
ela através de uma camada anterior, adicionar suas informações e logo após os
dados devem ser repassados para a camada seguinte, abaixo serão descritas as
características das setes camadas que compõem o modelo OSI.
Camada de aplicação: esta camada encontra-se no topo da estrutura
OSI, é responsável por realizar interconexão entre um determinado
protocolo de comunicação e o aplicativo que irá receber tais dados;
Camada de apresentação: é encarregada de comprimir e converter os
dados em um formado que possibilite seu tráfego na próxima camada,
ou seja, trabalha transformando os dados, tornando mais rápida
transferência e buscando minimizar as chances de interferências;
Camada de sessão: esta camada permite o estabelecimento de
sessões responsáveis pela comunicação entre diferentes aplicações;
18
Camada de transporte: esta camada deve garantir a entrega de
pacotes sem erros, no transmissor a camada de transporte é
responsável por após o recebimento dos dados, separá-los em
diferentes pacotes para o seu envio na rede, já no receptor esta
camada é responsável pela montagem dos pacotes, para que
retornem a sua forma original e repassa-los para a camada seguinte
(camada sessão);
Camada de rede: na camada 3 é onde ocorre a mudança do
endereçamento dos pacotes, passando de lógico para físico, e é nesta
camada também, onde são definidas os caminhos para que os
pacotes cheguem ao seu destino e garante a integridade dos pacotes
na sua entrega a próxima camada;
Camada enlace de dados: é responsável por realizar a transformação
dos pacotes de dados recebidos em quadros, no qual serão
adicionadas as informações necessárias para que possam continuar
seu tráfego na rede;
Camada física: é a camada no qual será definida a forma de como os
dados deverão ser transmitidos na rede, ou seja, os dados que
chegam nesta camada deverão ser transformados em sinais que
sejam compatíveis com o meio pelo qual tais dados serão
transmitidos.
Para melhor entendimento das camadas do modelo de referência OSI, a
figura 02 ilustra a divisão das sete camadas que o compõem.
19
Figura 02 - Modelo de Referência OSI
Fonte: Adaptado Odom.
3.2 Firewall Netfilter Iptables
Como definição, Neto (2004) afirma que “firewall é um programa que detém
autonomia concedida pelo próprio sistema para pré-determinar e disciplinar todo o
tipo de tráfego existente entre o mesmo e outros hosts e redes”, agindo assim como
uma espécie de filtro, capaz de impedir que tráfego indesejado passe por ele, seja
de entrada ou saída.
Em sistemas Linux, as funções de firewall estão em anexo ao próprio Kernel,
sendo que o IPtables vem, na maioria das distribuições Linux, agregado ao sistema
operacional (SO), que dá a ele a função de controle de fluxo interno em termos de
firewall. (NETO, 2004)
De uma forma mais geral, pode-se definir o Netfilter IPtables como “um
conjunto de situações de fluxo de dados agregadas inicialmente ao kernel do Linux e
dividido em tabelas” (NETO, 2004). Este conjunto de situações de fluxo, também
pode ser definido como regras. Regras estas que irão controlar todo fluxo que entra
e sai da rede.
20
Em sua estrutura o firewall Netfilter IPtables é divido em três tabelas padrões,
nas quais são armazenadas as regras de controle de acordo com ação a se tomar
com o pacote (RUSSEL, 2001). São elas:
Tabela FILTER: esta é tabela padrão onde são tratadas as situações de
filtragem de pacotes;
Tabela NAT: esta tabela é responsável pela função de NAT (Network Address
Translation), onde endereços IP privados são a associados, ou traduzidos, a
um endereço público possibilitando acesso a internet;
Tabela MANGLE: responsável por alterações ditas mais complexas nos
pacotes. Com ela é possível alterar o Tipo de Serviço (TOS) do pacote,
alterando também assim sua prioridade na rede.
Turnbull (2005) traz o entendimento que para uma efetiva ação de um firewall,
o mesmo deve ser o único ponto de saída e entrada de fluxo de dados na rede, pois
é ele quem deve decidir pela passagem ou não do pacote, situação essa que pode
ser definida como filtragem de pacotes. A figura 03 ilustra com um diagrama lógico a
disposição do firewall numa rede.
O Netfilter IPtables é classificado como um firewall statefull, ou filtro por
estado do pacote, pois é capaz de tratar, analisar, no mínimo 40 bytes iniciais de um
pacotes nas camadas 3 e 4 do modelo de referência OSI (RUSSEL, 2001 e NETO,
2004).
Como já citado, o Netfilter vem incorporado ao Linux, sendo ele então uma
ferramenta livre. Também é um software de código aberto, disponível diretamente do
site do fabricante: http://www.netfilter.org/projects/iptables.
21
.
Figura 03- Disposição de um firewall numa rede.
Fonte: os autores, 2013.
3.3 Clusters
O termo cluster começou a ser difundido na década de 60, quando a IBM
interligou dois de seus mainframes para realizarem tarefas coordenadamente
(PITANGA, 2008). Partindo deste princípio, tem-se a ideia de sistemas distribuídos,
que conforme Jia e Zhou (2005) tratam-se do agrupamento de máquinas autônomas
conectadas por uma rede de comunicação e equipadas com software desenvolvido
com o propósito de prover um ambiente computacional integrado e consistente.
De forma concisa, Pitanga (2008) define cluster como o conjunto de dois ou
mais computadores trabalhando de forma arranjada com o objetivo de resolver um
problema. Com a ideia inicial de se obter maior poder de processamento, um cluster
pode ser formado por milhares de unidades de processamento, onde se pode
distribuir ou replicar a execução de um programa através dessas unidades de
processamento (COULOURIS et al, 2013).
Clusters, de uma forma geral, têm como objetivo central compartilhar recursos
de forma transparente, ou seja, os clientes que estiverem acessando recursos
compartilhados pelo cluster, o vêem com um único servidor e não têm a informação
de qual ou em qual componente do cluster está o recurso acessado (COULOURIS et
al, 2013).
22
Yeo et al (2006) e Pitanga (2008) afirmam haver duas divisões distintas de
clusters, os de alta desempenho, implementados para prover um alto poder de
processamento; e os de alta disponibilidade, focados em suprir, por meio de
redundância de equipamentos, eventuais falhas físicas em componentes do cluster,
visando manter recursos e serviços disponíveis sempre.
3.4 Alta Disponibilidade
O conceito de Alta Disponibilidade vem sendo difundido e aprimorado nas
últimas décadas. Oggerino (2001), de forma breve, afirma que alta disponibilidade é
ter uma rede de computadores, um serviço de rede, um recurso web, um sistema
disponível o tempo todo. Bhagwan, Savage e Voelker (2003) afirma que a alta
disponibilidade de um sistema é muito mais complexa que o conceito em si, pois
para se ter um sistema disponível o maior tempo possível é necessários um
esquema de redundância de dispositivos, equipamentos ou hardware e software,
capazes de substituir temporariamente os que apresentaram falhas.
De acordo com Ferreira, Santos e Antunes (2008), a alta disponibilidade
consiste em manter um serviço ou aplicação o maior tempo possível operacional, de
forma que as paradas (planejadas ou não planejadas) e o tempo de recuperação
não venham a implicar no funcionamento destes para os usuários finais, pois foram
desenvolvidos para diminuir o tempo de recuperação.
A disponibilidade é definida como o tempo em que um serviço esta acessível
e operante (FILHO, 2008). Conforme Sztoltz, Teixeira e Ribeiro (2003) a
disponibilidade é dividida em três categorias diferentes:
Disponibilidade básica: classificada como a disponibilidade presente nos
computadores comuns, ou seja, que não apresentam nenhuma característica
que vise mascarar possíveis falhas, ou ainda, não possui qualquer
mecanismo que possa servir de backup caso uma falha no sistema o torne
indisponível, e durante o tempo de reparo o sistema permanece indisponível;
Alta disponibilidade: que é a disponibilidade projetada para o mascaramento e
recuperação de falhas, podendo apresentar uma disponibilidade de 99,99% a
99,999%, o sistema deve possuir além de um esquema de redundância,
mecanismos que tornem a recuperação da falha automática, deixando
transparente para o usuário a ocorrência de falhas;
23
Disponibilidade Contínua: É a forma de disponibilidade mais próxima de
100%, e que além de realizar o mascaramento das falhas ocorridas, também
consegue durante o período de recuperação manter o serviço operacional.
No conceito de alta disponibilidade durante o tempo de trabalho de um
elemento ele pode ser classificado de duas maneiras: em estado funcionando,
demonstra que o componente está ativo e funcionando, e estado em reparo, que
indica que ocorreu uma falha e o elemento esta inoperante. (Sztoltz, Teixeira e
Ribeiro, 2003).
A alta disponibilidade proposta neste estudo visa, através de redundância de
recursos de hardware e software, tornar um firewall disponível o maior tempo
possível, mascarando eventuais falhas e automatizando a recuperação.
O firewall de alta disponibilidade será implementado por um cluster composto
por dois computadores com os recursos de hardware necessários e os softwares
devidamente instalados e configurados.
3.4.1 Camada de abstração
A camada de abstração, ou camada lógica, conforme Coulouris et. al. (2013),
é a forma de abstrair um sistema complexo, dividindo-o em camadas, ocultando a
complexidade de tudo que esta por trás da camada com a qual algo se relaciona.
Para ilustrar este conceito pode-se considerar a situação a seguir. Para
efetuar a comunicação com uma rede externa ou pública, é necessário que o host
tenha configurado na sua interface de rede o endereço IP do gateway,
correspondente a sua rede local, que possibilitará esta comunicação (DARPA,
1981). Num ambiente convencional, o host pode ter conhecimento exato de qual
máquina está respondendo por esta função. Caso venha a ocorrer uma eventual
falha neste gateway, implicará na suspensão do acesso a Internet, tendo assim, o
host, a conclusão de que algo possa ter acontecido com a máquina responsável por
essa função. O recurso, neste caso o gateway, tem contato direto com o cliente,
ficando visíveis a ele eventuais problemas ou faltas do recurso (NEIRA, GASCA e
LEFÈVRE, 2009).
A implementação de um ambiente de alta disponibilidade, traz a inserção de
uma camada de abstração entre o host e o gateway, neste estudo apontado como
firewall, tornando transparente todo e qualquer recurso entregue pelo cluster de alta
24
disponibilidade. Contextualizando o que trata Coulouris et al (2013), a transparência
que se tem nesse ambiente é dita como transparência de localização, pois o host
não terá mais o conhecimento da real localização do firewall fisicamente ou na rede.
Tem-se então, virtualmente, uma entidade responsável por fazer a
comunicação entre o host e o recurso; um software que implementa uma camada
para a disponibilização dos recursos e troca de mensagens entre os computadores
do cluster, papel este desenvolvido pelo o Heartbeat (Haas, 2010).
Pode-se concluir, que neste ambiente de alta disponibilidade o conjunto de
computadores que comporem o cluster, terão seus recursos acessados pelos hosts
não mais de forma direta. Conforme Neira, Gasca e Lefèvre (2009), os hosts ainda
terão que ter configurado um endereço IP do gateway, mas esse por sua vez não
identificará a real máquina que estará respondendo. Este endereço será um IP
virtual, compartilhado entre os computadores do cluster, de forma que o host não
saberá qual nó deste cluster estará lhe respondendo.
3.5 Heartbeat
O Heartbeat é um daemon responsável por monitorar a disponibilidade e
detectar falhas de comunicação entre dispositivos interligados que o utilizam. Este
daemon executa estas funções através do envio continuo de pulsos entre os
dispositivos, que indicam se estão em funcionamento e disponíveis para executar
suas funções (Haas, 2010).
Caso a comunicação entre tais dispositivos seja interrompida por eventuais
falhas, o Heartbeat executa uma função para que o dispositivo de backup entre em
funcionamento no menor tempo possível (Haas, 2010).
De acordo com a documentação The Linux-HA Project, o Heartbeat é um
software de código aberto, e tem seu código fonte disponibilizado direto do site do
projeto, e para compilação do fonte se faz necessário a instalação das seguintes
ferramentas e bibliotecas:
Um compilador C (normalmente gcc) e bibliotecas de desenvolvimento C
associadas;
Gerador de scanner Flex e o compilador interpretador Bison;
Cabeçalhos de desenvolvimento Net-SNMP, para ativar a funcionalidade
relacionada SNMP;
25
Cabeçalhos desenvolvimento OpenIPMI, para ativar a funcionalidade
relacionada com IPMI;
Python (apenas o interpretador de linguagem);
O cabeçalhos de desenvolvimento do Cluster-glue.
Como o propósito deste trabalho é a implementação do Heartbeat utilizando
recursos já disponibilizados pelo software, é necessário apenas a instalação do
Heartbeat e o Cluster-glue, este último que é um conjunto composto por bibliotecas,
ferramentas e utilitários necessários ao funcionamento do Heartbeat
3.6 Conntrack-tools
O Conntrack-tools é um conjunto de ferramentas de software livre, formado
por dois programas, conntrack e conntrackd, que permite ao administrador do
sistema interagir com o Sistema de Rastreamento de Conexões, um módulo do
kernel do Linux que habilita inspeção no estado dos pacotes para o Iptables.
(AYUSO, 2012).
Com o uso do Conntrack-tools é possível replicar as tabelas de conexões
estabelecidas em um firewall para os demais que estejam fazendo parte do cluster.
Isso possibilita ao firewall de alta disponibilidade não interromper conexões de seus
clientes durante a recuperação de falhas, ou seja, quando um firewall ativo falha por
algum motivo, e o passivo toma o seu lugar, tornando-se o ativo. (NEIRA, GASCA e
LEFÈVRE, 2009).
O Sistema de Rastreamento de Conexões do Linux tem como função básica,
armazenar na memória informações sobre o estado das conexões estabelecidas
pelo Iptables, como endereço IP de origem e destino, número das portas onde esta
ocorrendo a comunicação, tipo de protocolo, estado e o timeout. (AYUSO, 2006).
O conntrack é o programa que provê a interface, por linha de comando, para
se interagir com o Sistema de Rastreamento de Conexões. Através dele pode-se
visualizar, excluir e atualizar entradas de informações sobre conexões, ou ainda
monitorar em tempo real eventos de fluxo das conexões. Já o conntrackd é o
daemon responsável por replicar as entradas do Sistema de Rastreamento de
Conexões nos firewalls do cluster de alta disponibilidade. (AYUSO, 2012)
A instalação do Conntrack-tools em sistemas Ubuntu Server 12.04 pode ser
feita conforme demonstrado na figura 04.
26
Figura 04 - Instalação do Conntrack-tools.
Fonte: os autores, 2013.
3.7 OpenSSH
OpenSSH é um software que provê uma infraestrutura de comunicação
segura utilizando arquitetura do protocolo SSH(Secure Shell), possibilitando acesso
remoto, chamadas de procedimento remoto e transferência de arquivos para hosts
remotos mediante forte esquema de criptografia. (OpenBSD.org, 1999).
Com a utilização do protocolo SSH pode-se obter um canal de comunicação,
ou túnel, seguro para transmissão de dados ou para administração remota sobre um
meio inseguro. (YLONEN, 2006). Isso é possível devido aos algoritmos de
criptografia aplicados sobre os dados que o software cliente de shell remoto, envia
durante a comunicação, onde até mesmo as informações de login e senha, bem
como todo o fluxo de dados dentro do túnel SSH, são criptografados no processo.
(BARRET, SILVERMAN e BYRNES, 2005).
O OpenSSH traz os programas cliente e servidor de serviço SSH, ou seja, um
computador tanto pode ser cliente de um servidor SSH, acessando um computador
remotamente, como pode ser servidor de um cliente, sendo acessado por outro,
simultaneamente, desde que esteja configurado para tal. (OpenBSD.org, 2009).
Uma característica considerável do OpenSSH é o fato da autenticação de
cliente poder ser feita mediante troca de chaves públicas, podendo dispensar o uso
de usuário e senha regular. Neste tipo de autenticação, o servidor só permite que
um cliente se autentique, se puder identificá-lo através de uma chave pública,
gerada por ele e previamente instalada no servidor. Isso possibilita uma
automatização na administração remota, uma vez que scripts possam disparar
comandos remotamente sem a necessidade da presença de um usuário para digitar
login e senha. (BARRET, SILVERMAN e BYRNES, 2005 e OpenSSH.org, 2009).
O OpenSSH é um software livre e de código aberto, e sua instalação em
distribuições Linux Ubuntu pode ser feita conforme ilustra a figura 05 .
27
Figura 05 - Instalação do OpenSSH.
Fonte: os autores, 2013.
3.8 Rsync
De acordo com Samba.org (2013), o rsync é um software Open Source que
foi desenvolvido pela Samba para sistemas Unix. O rsync possui o intuito de realizar
a transferência de arquivos remotos que estejam em sincronia, sendo amplamente
utilizado para backups e espelhamento. Software Open Source ou software livre são
ferramentas na qual podem ser usadas livremente, ou seja, é possível altera-las e
compartilha-las (SAMBA.ORG, 2013).
Podendo suportar consideráveis volumes de dados em suas transferências, o
software Rsync realiza a sincronia dos dados através de uma comunicação
criptografada utilizando SSH e através de seu algoritmo faz uma comparação dos
dados, para que somente seja transferidas as diferenças entre os dois arquivos
(JURZIK, 2011).
Para realizar suas transferências, o Rsync realiza uma busca dos arquivos
que precisam ser transferidos usando um determinado algoritmo de verificação
rápida (checksums), e através deste algoritmo procura por arquivos que foram
alterados, como em tamanho ou hora de modificação, e assim executa uma nova
sincronização para obter uma atualização dos arquivos, possibilitando assim a
redução da quantidade de dados enviados pela rede, pois este algoritmo realiza o
envio das diferenças entre os arquivos de origem e os arquivos existentes no destino
(SAMBA.ORG, 2013).
Para instalação do Rsync, basta proceder conforme demonstra a figura 06.
Figura 06 - Instalação do Rsync.
Fonte: os autores, 2013.
28
4 MATERIAIS E MÉTODOS
Analisando os diferentes tipos de pesquisa apresentados por Marconi e
Lakatos (2012), a elaboração deste trabalho de conclusão de curso é caracterizada
por pesquisa bibliográfica, aplicada e experimental. Onde pesquisa bibliográfica é
toda aquela que possa ser feita pelo uso de materiais escritos (RUMMEL, 1972, p.3
apud MARCONI e LAKATOS, 2012); a pesquisa é aplicada devido a sua relevância
para uma implementação prática e voltada para resolução de problemas (ANDER-
EGG, 1978, p. 33 apud MARCONI e LAKATOS, 2012); experimental é tipo de
pesquisa que por meio de um ambiente controlado, expõe-se um elemento sob
fatores variáveis para análise dos efeitos (BEST, 1972, p. 12-13 apud MARCONI e
LAKATOS, 2012).
Para a pesquisa bibliográfica foram utilizados, fundamentalmente, livros da
área de redes de computadores e sistemas distribuídos, artigos científicos
publicados em periódicos e eventos, trabalhos científicos na área (dissertações) e
documentação dos desenvolvedores dos softwares. Todo o levantamento
bibliográfico realizado foi de grande relevância para a implementação do ambiente
de alta disponibilidade proposto, implementação esta descrita integralmente nos
tópicos a seguir.
4.1 Laboratório de testes
Para implementação prática do firewall de alta disponibilidade, o Instituto
Federal de Educação, Ciência e Tecnologia Catarinense – Campus Sombrio (IFC–
Campus Sombrio) cedeu aos autores um laboratório de testes com pontos de
acesso a Internet, dois computadores utilizados como servidores firewall,
cabeamento para interconexão dos dispositivos, placas de rede adicionais, e um
dispositivo de comutação. A empresa PontoNet Computadores e Redes, também
contribuiu para a implementação prática, cedendo duas placas de rede necessárias
para a topologia proposta.
O IFC–Campus Sombrio, localizado na comunidade Vila Nova em Santa Rosa
do Sul, e sua Unidade Urbana, situada na Avenida Prefeito Francisco Lumertz
Junior, no bairro Januária, foi inaugurado em 5 de abril de 1993, com denominação
29
inicial de Escola Agrotécnica Federal de Sombrio (EAFS), oferecendo, no princípio, o
atual Ensino Médio e o curso de Técnico Agrícola. À medida que foi crescendo,
aumentou-se a oferta de cursos, onde passou a oferecer o curso de Técnico em
Informática, voltado a manutenção de computadores. E em 29 de dezembro de
2008, através da lei 11.892, teve seu nome alterado para o atual, ficando conhecido
regionalmente por IFC– Campus Sombrio (REINKE, 2009; IFC-Sombrio, 2013).
De acordo com o IFC– Campus Sombrio (2013), em 2009 foi inaugurado o
primeiro prédio do IFC– Campus Sombrio unidade urbana, o qual era distribuído em
três pavimentos, contendo três laboratórios de informática, oito salas de aula, além
das salas destinadas a setor administrativo do instituto. Ainda conforme IFC–
Campus Sombrio (2013), 2011 foi o ano em que um novo prédio foi inaugurado, ao
lado do primeiro, fazendo assim com que o espaço, tanto administrativo como
pedagógico fosse dobrado.
Em 2010 passou a ser ofertado pelo IFC– Campus Sombrio unidade urbana,
o curso Superior de Tecnologia em Redes de Computadores, que conforme descrito
pelo IFC– Campus Sombrio (2013), essencialmente objetiva:
[...] contribuir para a formação tecnológica e humana,
preparando profissionais habilitados para atuar na elaboração,
análise, levantamento, identificação, planejamento, execução
de projeto, manutenção e gerenciamento de redes de
computadores, assim como na construção de competências
que estimulem o profissional com o comprometimento e com os
valores inspiradores da sociedade democrática.
Fazendo pertinência com o desenvolvimento pedagógico dos discentes, que
está pautado, além de outras atividades, em experimentos laboratoriais (IFC–
Campus Sombrio); o Coordenador do curso e Orientador, e o Co-orientador deste
TCC, corroboraram para que os autores desenvolvessem a aplicabilidade do
objetivo deste trabalho em ambiente acadêmico e utilizando equipamentos do
próprio instituto, disponibilizando, para tal, um laboratório de testes dentro do espaço
físico do IFC– Campus Sombrio.
A figura 07 demonstra o espaço do laboratório de testes.
30
Figura 07 - Laboratório de testes.
Fonte: os autores, 2013.
Não apenas o laboratório, mas também todos os equipamentos visualizados
nas imagens são de propriedade do IFC- Campus Sombrio. A descrição de todo
material utilizado será apresentada posteriormente.
4.2 Equipamentos utilizados
Objetivamente, serão listados todos os dispositivos utilizados, bem como suas
características mais relevantes, informados pelos seus respectivos fabricantes e
necessárias para implementação de firewall de alta disponibilidade.
4.2.1 Computadores
Foram cedidos dois computadores, utilizados como servidores firewalls,
comumente neste trabalho tratados de primário e de backup, ou ativo e passivo,
porém ambos com características idênticas.
31
Quadro 01 - Configuração dos computadores utilizados.
Configuração de hardware dos servidores
Marca/Modelo HP-Compaq 6005 Pro
MT-PC
Processador AMD Phenom™ II x4
Memória RAM 3,2Gib
Disco Rígido 379GiB
Fonte: os autores, 2013.
4.2.2 Dispositivo de comutação
Para reproduzir a topologia proposta, devido a rede possuir apenas um
cliente, e não necessitar de um dispositivo de comutação de alto desempenho, foi
utilizado um hub-switch para a rede dos clientes do firewall. O quadro a seguir
apresenta as características do hub utilizado.
Quadro 02 - Configuração do hub-switch.
Fonte: os autores, 2013.
4.2.3 Placas de Rede
Devido à topologia proposta, cada computador servidor precisará ter três
placas de rede. Sendo que ambos os servidores, o primário e o de backup, já
Hub-switch
Marca TP-Link
Modelo TL-SF1008d.
Numero de portas 8 portas
Velocidades 10/100mbps
32
possuem uma placa de rede de fábrica, foi necessário acrescentar duas placas de
rede em cada um, quatro no total adicionadas, chegando a seis placas, levando em
consideração os dois servidores.
Tais dispositivos adicionais foram fornecidos em parte pelo IFC-Campus
Sombrio, duas placas de rede com barramento do tipo PCI (peripheral component
interconnect); e outras duas cedidas pela empresa PontoNet Computadores e
Redes, estas com barramento do tipo PCI-express1, as figuras abaixo demosntram
as placas de rede utilizadas.
Figura 08 – Placa de rede PCI.
Fonte: os autores, 2013.
Figura 09 – Placa de rede PCI-express
Fonte: os autores, 2013.
1 Padrão de barramento de expansão de periféricos, sucessor do PCI.
33
4.2.4 Cabeamento e conectorização
Foram utilizados cabos de rede padrão Cat. 5e, do tipo UTP (unshielded
twisted pair), ou como a tradução literal do termo sugere par-trançado sem
blindagem. Devido ao fato da utilização dos cabos serem em ambiente interno, e
não haver próximo a eles qualquer equipamento que produzisse campo
eletromagnético capaz de prejudicar a transmissão de dados, o emprego de cabos
com blindagem não foi necessário.
Para interconexão dos cabos às interfaces de rede, foram utilizadas as
especificações descritas na norma ANSI/TIA/EIA 568-B para conectorização, sendo
aplicada a ordem dos pares de fios conforme demonstra a figura 10.
Figura 10 - Ordem dos pares trançados conforme padrão 586-B
Fonte: Adaptado de Standards ANSI/TIA/EIA 568-B, sem data.
Todos estes equipamentos e dispositivos listados anteriormente, foram
utilizados na implementação do firewall de alta disponibilidade utilizando software
Heartbeat. Os tópicos a seguir demonstram a topologia lógica do ambiente, bem
como a implementação da solução.
4.3 Topologia do firewall de alta disponibilidade
Esta intrínseco na implementação do firewall de alta disponibilidade deste
TCC, a redundância de equipamentos, mais precisamente, de todos os dispositivos
34
e recursos para implementação de um firewall, os quais foram empregados em
dobro.
Foram implementados dois firewalls, que compõem um cluster de alta
disponibilidade, e que se comportam na forma de ativo/passivo ou primário e de
backup. Ou seja, o firewall na forma de ativo ou primário, será o responsável por
executar as funções de firewall, filtragem e encaminhamento de pacotes; e o da
forma passiva ou de backup, ficará inoperante, aguardando, e monitorando – função
esta de monitoramento executado pelo deamon2 Heartbeat; uma eventual falha no
firewall ativo, fazendo assim com que o passivo passe a se tornar ativo, mantendo
disponível o firewall (NEIRA, GASCA e LEFÈVRE, 2009).
A figura 11 ilustra a topologia lógica da implementação.
Figura 11 - Topologia lógica do firewall de alta disponibilidade.
Fonte: Adaptado de NEIRA, GASCA e LEFÈVRE, 2009
2 Deamon é um programa em execução, que realiza suas funções sem a necessidade de
interação com o usuário, operando em background. Em geral, deamons são serviços em execução.
35
4.4 Implementação do firewall de alta disponibilidade
Para implementação do firewall de alta disponibilidade, foram utilizados os
seguintes softwares:
Linux Ubuntu Server versão 12.04 (sistema operacional);
Firewall Netfilter Iptables versão 1.4.20;
Heartbeat versão 3.0.5;
Conntrack-tools versão 1.4.2;
Rsync versão 3.1;
OpenSSH versão 3.1.
Detalhes da aplicação cada item acima serão descritos a seguir.
4.4.1 Linux Ubuntu Server 12.04
Embora esta não seja a última versão do Linux Ubuntu Server, que já está na
versão 13.10, foi escolhida a 12.04 devido ao tipo de licença de suporte, o qual é
garantido até abril de 2017. A versão mais atual tem suporte por apenas nove
meses. Desta forma, segue as informações sobre a instalação:
Distribuição: Ubuntu Server 12.04(64bits);
Versão do Kernel: 3.2.0-40;
Configuração das partições de disco (usado disco inteiro):
a) SWAP 512 MB;
b) ext4 378 GB (restante do disco).
Como descrito no início desta seção, para cada computador utilizado como
firewall foi necessário a utilização de três placas ou interfaces de rede. As
configurações de rede foram feitas no arquivo “/etc/network/interfaces”, as quais são
ilustradas no quadro 03.
36
Quadro 03 - Configuração das interfaces de redes.
Fonte: os autores, 2013.
Função de cada interface de rede em relação à topologia proposta:
eth0: interface de acesso a Internet, que recebe endereçamento dinâmico
(Dynamic Host Configuration Protocol) por meio de servidor do IFC- Campus
Sombrio;
eth1: interface de LAN, a qual possibilita acesso dos hosts da LAN a Internet
sendo feito o encaminhamento de pacotes pelo firewall;
eth2: interface de monitoramento, troca de informações e sincronização de
arquivo de regras entre os firewalls do cluster.
4.4.2 Firewall Netfilter Iptables
Por padrão, o Netfilter Iptables, já vem agregado ao kernel do Linux, sendo
apenas necessária a ativação do seu módulo. Ele também dispensa configuração
por meio de extensos arquivos do tipo .conf (NETO, 2004).
Como o Netfilter Iptables estabelece as condições para fluxo de pacotes por
meio de regras, que podem ser introduzidas diretamente por linha de comando, um
script contendo regras para encaminhamento de pacotes foi criado e foi feita sua
chamada no arquivo /etc/rc.local. Isto é imprescindível para que o script do firewall
seja executado sempre na inicialização do computador, pois lembrando Russel
(2001), todas a regras adicionadas através do iptables via linha de comando, ficam
na memória principal do computador, sendo perdidas toda vez que o computador é
desligado ou reinicializado.
Firewall ativo Firewall passivo
Interface Endereço interface Endereço
eth0 DHCP eth0 DHCP
eht1 192.168.0.1/24 eht1 192.168.0.2/24
eth2 10.255.255.1/30 eth2 10.255.255.2/30
37
Como o escopo deste TCC não tem foco direto em segurança, mas sim em
alta disponibilidade, as regras do firewall implementado contemplam apenas
encaminhamento de pacotes, roteamento, permitindo que hosts da LAN tenham
acesso a Internet, não sendo efetuado qualquer tipo de bloqueio. Para tal foi criado
um script com o caminho /etc/firewall contendo as exatas informações reproduzidas
na figura 12.
Figura 12 - Reprodução do script do firewall.
Fonte: os autores, 2013.
4.4.3 Heartbeat
O Linux-HA Heartbeat é o software responsável pela implementação do
ambiente de alta disponibilidade. Ele provê a camada de passagem de mensagens
do cluster; monitora através de mensagens heartbeats os componentes do cluster, e
ao detectar que o firewall ativo parou de funcionar o firewall passivo passa para
ativo, e este assume a função, realizando o encaminhamento e filtro de pacotes.
Como citado na seção 3.5, junto com o Heartbeat, a dependência Cluster-glue
também deve ser instalada. A instalação de ambos pode ser feita como na figura 13.
Figura 13 - Instalação do Heartbeat
Fonte: os autores, 2013.
A configuração do Heartbeat está atrelada a três arquivos ha.cf, authkeys e o
haresources, e todos devem ficar localizados no caminho /etc/ha.d. O primeiro,
ha.cf, é o arquivo onde são informados os parâmetros de configuração do Heartbeat,
# Script de Firewall com simples implementacao para
# fins de testes com Heartbeat
#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
38
como hosts pertencentes ao cluster, interfaces monitoradas, opções sobre
monitoramento, entre outras informações. Este arquivo deve ser idêntico em todos
os hosts, exceto a linha ucast eth2. A figura 14 demonstra o arquivo utilizado pelos
autores na implementação.
Figura 14 – Parâmetros de configuração do Heartbeat.
logfile /var/log/ha-log
keepalive 2
deadtime 20
warntime 10
initdead 120
auto_failback off
bcast eth1
ucast eth2 10.255.255.1
autojoin none
node firewall01
node firewall
Fonte: os autores, 2013.
Cada parâmetro informado, de acordo com Robertson e Haas ( 2010), tem a
seguinte função:
a) logfile: indica a localização e o arquivo onde são registrados as informações
de eventos ocorridos durante a execução do Heartbeat;
b) keepalive: indica o intervalo de tempo entre uma mensagem heartbeat e
outra, que no arquivo foi informado dois segundos;
c) deadtime: tempo para um host do cluster ser considerado inoperante;
d) warntime: tempo para uma resposta de uma mensagem heartbeat ser
considerada atrasada;
e) initdead: tempo de espera de inicialização de host antes dele ser considerado
inoperante;
f) auto_failback off: impede que o host configurado como ativo e que parou de
funcionar, ao se reestabelecer assuma novamente a função de ativo;
39
g) bcast: indica as interfaces monitoradas por meio de broadcast;
h) ucast: indica a interface e o endereço do host de destino, logicamente, essa
linha será diferente em cada host;
i) autojoin: indica se hosts poderão entrar no cluster automaticamente;
j) node: indica quais hosts irão participar do cluster, deve ser informado o nome
que resulta do comando uname -n.
O arquivo authkeys especifica o tipo de criptografia que será utilizada na
autenticação dos hosts que fazem parte do cluster. Para fins de segurança, deve-se
configurar permissões do arquivo para que somente o root possa ter acesso. A
figura 15 demostra o que foi utilizado na implementação.
Figura 15 – Arquivo authkeys.
auth 1
1 md5 chave
Fonte: Os autores, 2013.
Em consulta ao manual, Robertson e Hass (2009) descrevem as opções
nesse arquivo, onde auth indica o numero do método de autenticação que esta em
uso, pois podem ser especificadas até quinze tipos. Na linha posterior é informado o
método ou tipo de algoritmo de criptografia, antecedido pelo seu número
identificador e sucedido pela chave ou palavra secreta.
O terceiro arquivo é o haresource, e nele são informados os recursos e o
endereço de serviço do cluster. Esse endereço é o IP virtual do recurso, o qual é
compartilhado entre os hosts do firewall de alta disponibilidade, ou seja, o firewall
ativo responderá por este endereço, e numa eventual falha que faça com que o
passivo assuma a função de ativo, será ele quem responderá pelo IP virtual. A figura
16 apresenta o arquivo que foi implementado, onde é informado o nome do host
primário e o IP virtual, IP este que será o gateway da LAN.
Figura 16- Arquivo é o haresource.
Fonte: os autores, 2013.
firewall01 192.168.0.254
40
Após todos os arquivos configurados, o serviço já pode ser iniciado. Para isso
basta digitar o comando ilustrado na figura 17. A partir de agora o firewall de alta
disponibilidade já esta em funcionamento.
Figura 17 – Reinicialização do Heartbeat.
Fonte: os autores, 2013.
4.4.4 Conntrack-tools
Este é o deamon responsável por manter as tabelas de conexões do Iptables
replicadas por entre os hosts do cluster. Basicamente possibilita que uma cópia das
informações de conexões estabelecidas pelo Iptables em favor do clientes seja
repassada para os componentes do cluster. Na prática isso pode, por exemplo,
impedir que downloads sejam interrompidos quando um firewall ativo caia e o
passivo assuma sua função.
Sua instalação já foi descrita na seção 3.6, e para sua configuração foi
alterado o arquivo “/etc/conntrackd/conntrackd.conf”, sendo acrescentado ao final do
arquivo a seguinte seção demonstrada na figura 18.
Figura 18 - Configuração do conntrackd.
Sync {
Mode FTFW {
}
UDP Default {
IPv4_address 10.255.255.1
IPv4_Destination_Address 10.255.255.2
Port 3780
Interface eth2
SndSocketBuffer 24985600
RcvSocketBuffer 24985600
Checksum on
}
}
Fonte: adaptado de Ayuso, 2012.
As configurações apresentadas devem seguir rigidamente espaçamentos,
tabulações, e o uso de letras maiúsculas quando ocorrer. Entretanto, ao tentar
41
reiniciar o serviço, caso haja alguma falha, o deamon avisará qual linha esta o erro e
que tipo de erro ocorreu.
4.4.5 OpenSSH
O software OpenSSH foi implementado nos firewalls para utilizar o serviço
ssh, em conjunto com o rsync, para sincronização dos scripts de regras do Iptables
entre os hosts do cluster. Com o ssh é possível realizar autenticação remota, bem
como transferência remota de arquivos utilizando par de chaves de criptografia.
Foram utilizadas chaves públicas, de forma que não exigisse interação do usuário
durante autenticação, automatizando o processo de sincronização.
As configurações a seguir descrevem os procedimentos realizados nos
firewalls do laboratório de teste para instalação e implementação do serviço ssh:
a) instalação do serviço ssh : apt-get install openssh-server openssh-client ;
b) foram criados os pares de chave: ssh-keygen -t rsa –N ‘’;
c) após a criação dos pares de chave, o conteúdo da chave publica de um host
deve ser copiada para dentro do arquivo /etc/ssh/authorized_keys do outro
host: ssh [email protected] “umask 077; cat >> /etc/ssh/authorized_keys” <
/home/firewall01/.ssh/id_rsa.pub ;
Após executado esta sequência comandos em ambos os hosts, se concretiza
uma configuração ssh utilizando pares de chave de criptografia, sem a necessidade
de digitar a frase senha ao efetuar comandos remotamente.
Duas últimas alterações devem ser feitas no arquivo de configuração do ssh,
o sshd_config. Na linha PasswordAuthentication yes, deve ser alterado de yes para
no, e a linha AuthorizedKeysFile deve estar habilitada e sucedida do caminho do
arquivo authorized_keys. Através destes parametrôs, se automatiza totalmente
qualquer chamada de procedimento remoto.
4.4.6 Rsync
O rsync é a ferramenta que realiza a sincronização de arquivos, verificando
alterações para somente atualizar o arquivo e não precisar copia-lo integralmente.
Na implementação, ele foi utilizado para manter o scritp de regras do Iptables
sincronizado entre os firewalls do cluster.
42
Ao se montar o script do firewall, o administrador do sistema deve atentar
para manter esse arquivo igual em todos os hosts do cluster. O papel do rsync é
automatizar essa tarefa, para que o administrador não ter que editar os scripts
individualmente. Não há necessidade de configuração, apenas sua instalação.
O administrador ao acrescentar ou remover alguma regra do script do firewall
primário pode utilizar outro script para sincronizar seus firewalls. O script de nome
sync.firewall foi criado para automatizar essa tarefa, e contém os seguinte comando:
rsync –av –update /etc/firewall [email protected]:/etc/firewall.
4.5 Testes realizados
A fim de verificar a funcionalidade do firewall de alta disponibilidade, foram
aplicados testes simulando falhas e teste para verificação da sincronização do script
de regras. Para testar a alta disponibilidade foram efetuados os seguintes teste:
desativação da interface de rede eth1 do firewall ativo;
desativação da interface de rede eth2 do firewall ativo;
desativação da interface de rede eth0 do firewall ativo;
desconexão de cabo de rede de qualquer interface do firewall ativo;
interrupção do fornecimento de energia do firewall ativo;
verificação de continuidade de download na desativação do firewall ativo.
reativação do firewall primário para verificar se o parâmetro auto_failback off
do ha.cf funciona corretamente.
Para teste de sincronismo foram efetuados teste a seguir:
alteração de regra no firewall ativo e execução de script de sincronização;
observação do firewall passivo após se tornar ativo para verificar se utiliza a
regras atualizadas.
Após a realização dos testes elencados, foi possível observar uma gama de
resultados que serão discutidos na seção seguinte.
43
5 RESULTADOS E DISCUSSÃO
Após a implementação e realização dos testes citados na seção anterior, pôde-se
verificar que o software Heartbeat cumpre satisfatoriamente sua função,
consolidando um ambiente de alta disponibilidade, cumprindo o que caracteriza um
cluster desta natureza.
Os testes foram realizados de forma que um computador cliente, de
configurações ignoradas, onde apenas sua interface de rede estava configurada de
acordo com as especificações da eth1 dos firewalls e seu gateway configurado com
o endereço IP virtual do cluster (192.168.0.254), disparou o comando “ping 8.8.8.8” e
efetuou download de um recurso na Internet. O resultado de cada teste será relatado
a seguir.
5.1 Testes simulando eventuais falhas
Os testes de desativação das interfaces de rede consistiam em, através do
comando “ifconfig [interface] down”, simular a falha numa interface. Ao desativar
qualquer interface do firewall ativo, o firewall passivo era chamado a assumir a
posição de ativo, prontamente e automaticamente, sem qualquer intervenção dos
autores. As figuras 19 e 20 apresentam registros de eventos, logs, do firewall ativo e
do firewall passivo quando se torna o ativo, respectivamente, ilustrando o resultado
do teste descrito e o do teste a seguir.
Figura 19 - Log firewall ativo.
Fonte: os autores, 2013.
44
Figura 20 - Log do firewall passivo assumindo o serviço.
Fonte: os autores, 2013.
O teste de interrupção do fornecimento de energia, simulando um defeito na
fonte de alimentação do computador firewall, foi efetuado de duas formas, uma onde
o firewall ativo era desligado da fonte de energia; e a outra através do script
/usr/share/heartbeat/hb_standby all disponibilizado pelo Heartbeat e que paralisa
toda máquina, como se estivesse desligada. O resultado não foi diferente do teste
anterior, o Heartbeat manteve o firewall ativo, refletindo apenas em pequenos
atrasos no tempo de respostas dos pings.
O deamon conntrackd, em sinergia com o Heartbeat proveu uma capacidade
melhorada da alta disponibilidade, tornando as eventuais falhas ainda mais
transparentes. Com a implementação do conntrackd, todos downloads, as sessões e
conexões estabelecidas no firewall ativo, foram copiadas, continuamente para o
firewall passivo, não interrompendo qualquer interação do cliente com a Internet. Isto
contempla os testes de verificação de continuidade de download na desativação do
firewall ativo, que foi obtido resultado de 100% de aproveitamento quando
combinado com os testes simulando falhas. A figura 21 demonstra o cache de
conexões ativas no firewall ativo e a figura 22 evidencia que tais conexões estão
armazenadas no cache externo do firewall passivo.
45
Figura 21 - Cache interno de conexões ativas do firewall ativo.
Fonte: os autores, 2013.
Figura 22 - Cache externo do firewall passivo de conexões provenientes do firewall ativo.
Fonte: os autores, 2013.
Finalizando os testes relativo falhas, o parâmetro auto_failback off impede
que o firewall configurado como primário, ao sofrer alguma falha, após se recuperar
assuma novamente a função de ativo. Haas (2010), afirma que esta configuração
tem relativa importância, pois o administrador deve verificar a integridade do firewall
que sofreu com falhas antes de torna-lo ativo novamente.
A sincronização do script do firewall entre os hosts do cluster de alta
disponibilidade, também tem significativa importância, pois um firewall passivo que
não tenha seu arquivo de regras idêntico ao do ativo, ao ser promovido a ativo, este
pode deixar de ser tão efetivo, uma vez que com sua lista de regras desatualizada
pode comprometer a segurança, negligenciando possíveis bloqueios existentes na
lista de regras de seu antecessor. Respondendo positivamente ao testes, o script
sync.firewall realizou o sincronismo do arquivo de regras entre os firewalls.
O último teste consistia em verificar o comportamento de um firewall passivo,
que recebeu atualizações no seu arquivo de regras, e após falha no primário, foi
promovido a ativo. No teste o firewall teria que atuar considerando as atualizações
de forma plena e transparente, o qual foi cumprido de forma integral sem a
ocorrência de falhas.
Por fim, a implementação do firewall de alta disponibilidade utilizando o
software Heartbeat cumpriu seu objetivo geral, uma vez que manteve os recursos do
firewall, filtragem e encaminhamento de pacotes, disponível todo o tempo,
mascarando eventuais falhas, quase que imperceptíveis para os clientes. Outro
46
requisito para ser considerado altamente disponível e que também foi atingido, é o
da capacidade do firewall se manter ativo, sem a necessidade da intervenção de um
administrador, movendo o recurso para um host do cluster que esteja em pleno
funcionamento, na ocorrência de falhas no firewall primário, executando isso de
forma automática.
47
6 CONSIDERAÇÕES FINAIS
Tendo em vista o crescimento das redes de computadores, e junto com elas o
constante aumento do fluxo dos dados que passaram a trafegar em uma rede de
computadores, o presente trabalho apresenta a necessidade de se manter um
firewall o maior tempo possível disponível, sendo desta forma, expostos sua
importância, aspectos e funções. O firewall que na compreensão de Torres (2001),
é um fator importante para manter a estrutura de segurança de uma rede de
computadores, que tem a função de realizar a análise e a filtragem de todos os
pacotes que entram e saem de uma determinada rede de computadores.
Desta forma, a importância de que um firewall esteja operacional e com seus
serviços funcionando, culminou na realização do presente trabalho o levantamento
do estudo e a implementação de um firewall de alta disponibilidade utilizando o
software de monitoramento Heartbeat, e através da implementação foi possível
efetuar as devidas configurações e testes, alcançando de forma satisfatória os
objetivos do trabalho.
Entretanto, no decorrer da implementação dos objetivos deste TCC, verificou-
se uma gama de outras ferramentas necessárias para complementar o objetivo geral
apresentado no inicio deste trabalho escrito.
A alta disponibilidade em si, pode ser contemplada utilizando apenas o
software Heartbeat, porém como se buscou proporcionar um ambiente de alta
disponibilidade, que além de tornar um firewall ativo o maior tempo possível,
mascarando falhas através de redundância, foram alcançados níveis ainda maiores
de disponibilidade. Através da implementação de ferramentas como o conntrackd,
que permite transferências automáticas de conexões para o firewall de backup, foi
possível tornar as falhas quase que imperceptíveis aos clientes.
Ainda que o cluster implementado pelos autores em computadores reais, em
um laboratório de testes cedido pelo IFC-Sombrio, possua características atribuídas
aos considerados de alta disponibilidade, ao final do seu desenvolvimento, pôde-se
concluir que ainda existem outras ferramentas que possam ser estudadas e
implementadas junto ao cluster já construído, para aperfeiçoar funcionalidades de
administração do cluster.
Para tal, os autores do presente trabalho de conclusão de curso (TCC)
propõem uma continuação do trabalho até o momento concluído, visando a
48
implementação de outros softwares que possam auxiliar, por exemplo, na
administração do cluster, seus componentes e recursos. Uma ferramenta
desenvolvida especificamente para este propósito é o Pacemaker, um software de
gestão de recursos de cluster. Embora desenvolvido em projeto paralelo ao
Heartbeat, ele possui compatibilidade total com Heartbeat entre outros softwares de
alta disponibilidade.
Uma implementação do Pacemaker requer um profundo estudo sobre suas
funções, configurações e criação de recursos, mas previamente, de acordo com
Haas (2010), o objetivo do Pacemaker é fornecer uma console de gestão de
recursos de cluster, onde todos os hosts, recursos, configurações de recursos,
status do serviço e todas as informações de gerência do cluster, possam ser
realizadas pelo Pacemaker.
Ainda pensando em aprimorar a presente implementação, ferramentas de
administração podem também serem propostas para estudos futuros. Softwares que
automatizem ainda mais algumas funções dos firewalls, visando exigir cada vez
menos interação do administrador na resolução de problemas. A exemplo podemos
citar o Mon e o Crontab: o primeiro uma ferramenta de monitoramento baseada em
scripts e o segundo, um software para agendar tarefas.
Por fim, vê-se que é constante o desenvolvimento de novas tecnologias e
aprimoramento de ferramentas já com seu uso consolidado, com isso têm-se a
certeza de que nenhuma solução será definitiva, sempre poderá surgir uma melhor.
Foi possível chegar a esse entendimento, devido ao grande incentivo à
pesquisa, por parte do orientador e coorientador deste trabalho, para que os autores
do presente trabalho pudessem, ao final deste TCC, concluírem que sua pesquisa
esta apenas começando.
49
REFERÊNCIAS
ANSI/TIA/EIA. Standards 568-B: commercial building telecommunications cabling standard. Disponível em: <http://www.csd.uoc.gr/~hy435/material/Cabling%20Standard%20-%20ANSI-TIA-EIA%20568%20B%20-%20Commercial%20Building%20 Telecommunications%20Cabling%20Standard.pdf>. Acesso em: 28 nov 2013. ASSOCIAÇÃO BRASILEIRA DE TELECOMUNICAÇÕES. Banda larga chega a 106,3 milhões de acessos no 1º semestre. Rio de Janeiro, 2013. Disponivel em: <http://www.telebrasil.org.br/sala-de-imprensa/na-midia/4197-banda-larga-chega-a-106-3-milhoes-de-acessos-no-1-semestre>. Acesso em: 25 set 2013 AYUSO, Pablo Neira. Netfilter’s connection tracking system. ;login, Berkeley, vol. 31, n. 3, p.34-39, jun. 2006. Disponível em: <http://c59951.r51.cf2.rackcdn.com/5751-892-neira.pdf>. Acesso em: 28 out 2013. AYUSO, Pablo Neira. The conntrack-tools user manual. Netfilter, 2012. Disponível em: <http://conntrack-tools.netfilter.org/manual.html#sync-configure>. Acesso em: 28 out 2013. BARRET, Daniel J.; SILVERMAN, Richard E. BYRNES; Robert G. SSH, The Secure Shell: the definitive guide. Sebastopol, O’Reilly, 2005, 2 Ed. Bhagwan, Ranjita. Savage; Stefan. Voelker; Goeffrey M. Understanding Availability, International workshop on Peer-To-Peer Systems. Disponível em: <http://www.iptps.org/papers-2003/availability.pdf>. Acesso em: 22 out 2013. CASTELLS, Manuel. A galáxia da internet: reflexões sobre a internet, os negócios e a sociedade. Rio de Janeiro: Zahar, 2003. COULOURIS, George et al. Sistemas Distribuídos: conceitos e projeto. 5. ed., Rio de Janeiro: Bookman, 2013. COMER, Douglas E. Redes de computadores e a internet. 4ed.,Porto Alegre: Bookman, 2007. DEFENSE ADVANCED RESEARCH PROJECTS AGENCY. INTERNET PROTOCOL: DARPA internet program protocol specification. Arlington, 1981. Disponível em: <http://www.ietf.org/rfc/rfc791.txt>. Acesso em: 30 out 2013. FERREIRA, Filipa; SANTOS, Nélia; ANTUNES, Mário. Cluster de alta disponibilidade: uma abordagem Open Source.. Disponível em: <http://mosel.estg.ipleiria.pt/files/projectos/Artigo_0.pdf>. Acesso em: 15 out 2013. FILHO, Edmo Lopes. Arquitetura de alta disponibilidade para firewall e IPS baseada em SCTP. Dissertação (Mestrado em Ciências da computação) –UFU, Uberlandia, 2008. Disponível em: < http://repositorio.ufu.br/handle/123456789/632 >. Acesso em: 16 out 2013.
50
HAAS, Florian. The Linux-Ha User’s Guide: the Linux-HA Project. Linbit HA-Solutions GmbH, 2010. Disponível em: <http://www.linux-ha.org/doc/users-guide/users-guide.html>. Acesso em: 01 set 2013. Instituto Federal Catarinense - Campus Sombrio. Curso Superior de Tecnologia em Redes de Computadores. Sombrio, sd. Disponível em: <http://redes.ifc-sombrio.edu.br/>. Acesso em: 20 nov 2013. Instituto Federal Catarinense - Campus Sombrio. Histórico e Localização. Sombrio, 2013. Disponível em: <http://www.ifc-sombrio.edu.br/index.php?option =com_content&view=article&id=94&Itemid=37>. Acesso em: 20 nov 2013. JIA, Weijia; ZHOU, Wanlei. Network Systems: from concepts to implementations. Boston: Springer, 2005.
JURZIK, Heike. Sincronizado: uso do Rsync para sincronização de dados. Linux Magazine, São Paulo, n. 23, p.62-63, set. 2006.
KUROSE, James F.; ROSS, Keith W. Redes de computadores e a internet: uma abordagem top-down. 5. ed. São Paulo: Addison Wesley, 2010. LINUX. São Paulo: Linux New Media do Brasil, n.74, mar. 2011 MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Técnicas de Pesquisa: planejamento e execução; amostragens técnicas de pesquisa; elaboração, análise e interpretação de dados. 7 ed. São Paulo: Atlas, 2008.
MORAES, Alexandre Fernandes de. Redes de Computadores: fundamentos. 7. ed. São Paulo: Érica, 2010. MORIMOTO, Carlos. Resumo das regras Iptables. Disponível em: <http://www.hardware.com.br/dicas/resumo-iptables.html>. Acesso em: 10 jul 2013. NEIRA, Pablo. GASCA, Rafael M. LEFÈVRE, Laurent. Demystifying cluster-based fault-tolerant Firewalls. IEEE Internet Computing, Los Alamitos, n. 13(6), p.31-38, nov-dez. 2009. Disponível em: < http://1984.lsi.us.es/~pablo/docs/intcomp09.pdf>. Acesso em: 28 out 2013. NETO, Urubatan. Dominando Linux Firewall Iptables. Rio de Janeiro: Ciência Moderna, 2004. ODOM, Wendell. CCENT/CCNA ICND 1: 640-822 guia oficial de certificação do exame. 3. ed. Rio de Janeiro: Alta Books, 2013. OGGERINO, Chris. High Availability Network Fundamentals. Indianopolis: Cisco Press, 2001. Disponível em: <http://books.google.com.br/books?id=wUyDF1yWfhMC >. Acesso em: 01 nov 2013. OpenBSD.org. OpenSSH: keeping your communiqués secret. Disponível em: <http://www.openssh.org>. Acesso em: 15 out 2013.
51
OpenBSD.org. The Open project’s announcement of OpenSSH. Disponível em: <http://www.openssh.org/press.html>. Acesso em: 16 out 2013. PITANGA, Marcos. Construindo supercomputadores com Linux. 3. ed. Rio de Janeiro: Brasport, 2008.
REINKE, Adalberto. Diagnóstico e perspectivas de desenvolvimento sócio-educacional dos assentados rurais da comunidade de Vila Nova, Santa Rosa do Sul - SC e a participação do IFECTC - Campus Sombrio. Dissertação (Mestrado em Ciências) –UFRRJ, Seropédica, 2009. Disponível em: <http://www.ia.ufrrj.br/ppgea/dissertacao/Adalberto%20Reinke.pdf>. Acesso em: 20 nov 2013. RUSSEL, Rusty. Linux 2.4 Packet Filtering HOWTO. Disponível em: <http://www.netfilter.org/documentation/HOWTO/pt/packetfilteringHOWTO.html#toc>. Acesso em: 08 ago 2013. SAMBA.ORG. RSYNC. Disponível em: <http://rsync.samba.org/>. Acesso em: 20 nov. 2013.
SIQUEIRA, Luciano Antônio. Infraestrutura de Redes. 2 ed., São Paulo: Linux New Midia, 2010. SOUSA, Lindeberg Barrros de. Projetos de implementação de redes: fundamentos, soluções, arquiteturas e planejamento. 2 ed., São Paulo: Érica, 2009. STALLINGS, William. Redes e sistemas de comunicação de dados: teoria e aplicações corporativas. Rio de Janeiro: Elsevier, 2005. SZTOLTZ, Lisiane; TEIXEIRA, Selbach; RIBEIRO , Evelyne de Oliveira Ferraz. Guia do Servidor Conectiva Linux. Conectiva S.A., 2003. Disponível em: <http://conectiva.com/doc/livros/online/9.0/servidor/book.html>. Acesso em: 15 out 2013. TANENBAUM, Andrew S.; Redes de Computadores. 4. ed., Rio de Janeiro: Elsevier,2003. TANENBAUM, Andrew S.; VAN STEEN, Maarten. Sistemas distribuídos: princípios e paradigmas. 2. ed., São Paulo: Pearson, 2007. TELEBRASIL. Brasil tem 106,3 milhões de acessos de banda larga em junho. Rio de Janeiro, 2013. TORRES, Gabriel. Redes de Computadores: curso completo. Rio de Janeiro: Axcel Books, 2001. TURNBULL, James. Hardening Linux: learn how to quickly secure your Linux hosts and applications against attack. New York: Apress. 2005
52
VALLE, James Della; ULBRICH, Henrique Cesar. Universidade Hacker. 4 ed., São Paulo: Digerati Books, 2004. YEO, Chee Shin et al. Cluster Computing: high-performance, high-availability, and high-throughput processing on a network of computers. Melbourne Clouds Lab, 2006. Disponível em: <http://www.cloudbus.org/papers/ic_cluster.pdf>. Acesso em: 03 nov 2013.
YLONEN, Tatu. The Secure Shell (SSH) Transport Layer Protocol. IETF, rfc 4253, jan 2006. Disponível em: <http://tools.ietf.org/html/rfc4253>. Acesso em: 15 out 2013.