INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA...

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




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




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.


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.


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.


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.


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


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.


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.


Figura 09 – Placa de rede PCI-express


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.


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.


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


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


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.


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.


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;



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.


44

Figura 20 - Log do firewall passivo assumindo o serviço.


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.


Figura 22 - Cache externo do firewall passivo de conexões provenientes do firewall ativo.


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.

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA...

Documents

Transcript of INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA...