UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA DE ENGENHARIA DEPARTAMENTO DE ENGENHARIA ELETRONICA E COMPUTAC AO

UM MECANISMO SEGURO DE AUTENTICACAO MUTUA COM DETECCAO DE DESCONEXAO E GERENCIAMENTO DINAMICO DE REGRAS DE FIREWALL

Autor: Bruno Astuto Arouche Nunes

Orientador: Luis Felipe M. de Moraes, Ph.D

Examinador: Antnio Cludio Gmez de Sousa, M.Sc. o a o

Examinador: Jorge Lopes de Souza Leo, Dr.Ing. a

DEL Junho de 2004

Agradecimentos
Aos meus pais, Miriam Cristina Astuto e Marcos Arouche Nunes, que sempre me apoiaram em tudo e me guiaram durante todas as etapas de minha vida. Seu amor, carinho e dedicaao, permitiram que eu me tornasse o homem que c sou hoje. Por tudo sou muito grato. Ao meu irmo, Rafael, simplesmente por ser o irmo que . a a e Ao meu orientador, Luis Felipe M. de Moraes, que sempre me incentivou a tentar alcanar a perfeiao e por apoiar minhas idias e permitir que elas se c c e tornassem realidade. Ao professor, Marcelo Luiz Drumond Lanza, que sempre que eu precisei, esteve ao meu lado para tirar minhas d vidas e ajudar no que eu precisasse. u Ao grande amigo Demetrio Carrion, que junto comigo elaborou a idia de um e sistema de detecao de desligamento de estaao para ser aplicado no ambiente c c do AirStrike. Hoje chamamos esse sistema de isAlive. Ao grande amigo Denilson Martins, que me ajudou quando eu no conseguia a matar os bugs do sistema. Sua colaboraao no cdigo e sua ajuda nos testes c o foram de grande ajuda para a concluso do mesmo. a Aos funcionrios e a todos os colegas do Laboratrio de Redes de Alta Vea o locidade (RAVEL), por permitirem que as horas investidas neste laboratrio o fossem sempre as mais agradveis. Agradecimento especial a Ana Elisa pela a ` ajuda com as guras presentes neste documento. Meus agradecimentos tambm para FAPERJ, pelo apoio ao projeto. e ii

Resumo
Atualmente encontra-se em funcionamento no Laboratrio de Redes de Alta o Velocidade - RAVEL um ambiente para redes sem o 802.11b denominado AirStrike [1], onde a segurana o principal foco. Neste contexto, utilizou-se o sistema operac e cional OpenBSD e ferramentas de segurana como, redes privadas virtuais - VPNs c e um sistema de controle de acesso a rede sem o, o sistema StrikeIN. Porm, um ` e grave problema foi identicado na implementaao de ambientes de rede sem o, que c utilizam VPNs e sistemas de rewal. Este problema pode permitir determinados tipos de ataque. A explicaao de tal falha simples. Uma vez que uma estaao se autentica c e c no ponto de acesso (AP), atravs do sistema StrikeIN, as regras do rewall no AP, e so editadas, permitindo que esta estaao possa usufruir as funcionalidades da rede. a c O problema est no fato de que, quando uma estaao se desliga da rede por algum a c motivo, as regras do rewall continuam inalteradas, ou seja, o IP da estaao que se c desligou continua com permisso de acesso devido as regras do rewall. Eventuais a ` t neis VPN que estivessem abertos com a referida estaao permaneceriam abertos, u c mesmo que no mais necessarios, consumindo recursos da mquina funcionando a a como AP. O objetivo deste trabalho , de forma segura, promover autenticaao m tua e c u entre estaoes sem o e AP, vericar se uma estaao se desligou de rede e alterar c c automtica e dinamicamente as regras do rewall, proibindo o acesso de qualquer a estaao com endereo IP que no tenha sido autenticado. Tendo em vista o objec c a tivo em questo, uma aplicaao cliente-servidor foi desenvolvida e implementada na a c linguagem C/C++. Esta aplicaao leva o nome de isAlive. c

iii

Palavras-Chave
Dead Peer Detection - DPD, programaao para rede, multi-plataforma, C/C++, c Active Probing, Redes Sem Fio, Segurana, Criptograa, Controle de Acesso. c

iv

Abreviaturas e Siglas
AP - Access Point BD - Banco de Dados BSS - Basic Service Set CRC - Cyclic Redundancy Check DPDP - Dead Peer Detection Protocol DSSS - Direct Sequence Spread Spectrum FHSS - Frequency Hopping Spread Spectrum IBSS - Independent Basic Service Set ICV - Integrity Check Value IPSec - IP Secure LAN - Local Area Network NAT - Network Address Translation pf - Packet Filter PRNG - Pseudo-Random Number Generator SSID - Service Set Identier STA - Estaao Sem Fio c VI - Vetor de Inicializaao c VPN - Virtual Private Networks WEP - Wired Equivalent Privacy WLAN - Wireless Local Area Network

Lista de Figuras
2.1 2.2 Exemplo de redes sem o adotando topologia ad hoc. . . . . . . . . . Exemplo de redes sem o adotando modo infraestruturado, onde um AP utilizado na comunicaao. . . . . . . . . . . . . . . . . . . . . . e c 2.3 2.4 3.1 3.2 5.1 5.2 5.3 O funcionamento do WEP (extra de [2]) . . . . . . . . . . . . . . . do 8 9 7

A autenticaao no protocolo WEP (extra de [2]) . . . . . . . . . . 11 c do Arquitetura AirStrike . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Formato do pacote IPSec (extra de [2]) . . . . . . . . . . . . . . . 20 do Pgina de autenticaao para acesso ao AirStrike. . . . . . . . . . . . . 30 a c Troca t pica de mensagens do sistema isAlive. . . . . . . . . . . . . . 31 Esquema do funcionamento do isAliveDaemon. . . . . . . . . . . . . . 39

vi

Sumrio a
Agradecimentos Resumo Palavras-Chave Abreviaturas e Siglas Sumrio a 1 Introduo ca 1.1 1.2 1.3 Motivaao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c O Que Foi Feito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Este Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii iii iv v vi 1 2 3 4 5 6 6 6 7 9 9

2 O Padro IEEE 802.11b a 2.1 Camada F sica de Redes Sem Fio 802.11b . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.2 2.3 FHSS (Frequency Hopping Spread Spectrum) . . . . . . . . . . DSSS (Direct Sequence Spread Spectrum) . . . . . . . . . . . .

Operaao de Redes Sem Fio 802.11b . . . . . . . . . . . . . . . . . . c Mecanismos de Segurana em Redes 802.11 . . . . . . . . . . . . . . . c 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 O Mecanismo WEP (Wired Equivalent Privacy) . . . . . . . .

Open System Authentication . . . . . . . . . . . . . . . . . . . 10 Pre-Shared Key Authentication . . . . . . . . . . . . . . . . . 11 Closed Network Access Control . . . . . . . . . . . . . . . . . 12

Listas de Controle de Acesso . . . . . . . . . . . . . . . . . . . 12

vii

2.3.6

Gerenciamento de Chaves . . . . . . . . . . . . . . . . . . . . 12 14

3 Ambiente Seguro Para Redes 802.11b - AirStrike 3.1 3.2

O que o AirStrike . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 e Arquitetura de segurana proposta pelo AirStrike . . . . . . . . . . . 16 c 3.2.1 3.2.2 3.2.3 3.2.4 Regras de Firewall . . . . . . . . . . . . . . . . . . . . . . . . 18 VPN (Virtual Private Network) com IPSec (IP Secure) . . . . 18 StrikeIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 isAlive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 22

4 Deteco de Desligamento de Estao - DPD ca ca 4.1 4.2

Importncia de Mecanismos de DPD . . . . . . . . . . . . . . . . . . 22 a Desligamento de uma Estaao . . . . . . . . . . . . . . . . . . . . . . 23 c 4.2.1 4.2.2 4.2.3 4.2.4 Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Sondagem Ativa (Active Probing) . . . . . . . . . . . . . . . . 24 Sondagem Passiva (Passive Probing) . . . . . . . . . . . . . . 24 Keepalives vs. Heartbeats . . . . . . . . . . . . . . . . . . . . . 25 4.2.4.1 4.2.4.2 4.2.4.3 Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 25 Heartbeats . . . . . . . . . . . . . . . . . . . . . . . . 26 Consideraoes . . . . . . . . . . . . . . . . . . . . . . 26 c 28

5 isAlive - Proposta, Implementao e Funcionamento ca 5.1 5.2 5.3

Sistema de Autenticaao StrikeIN . . . . . . . . . . . . . . . . . . . . 28 c Protocolo DPD Proposto no isAlive . . . . . . . . . . . . . . . . . . . 29 Implementaao do isAlive . . . . . . . . . . . . . . . . . . . . . . . . 32 c 5.3.1 Aplicaao Cliente Servidor . . . . . . . . . . . . . . . . . . . . 32 c 5.3.1.1 5.3.2 5.3.3 Biblioteca TCPLIB . . . . . . . . . . . . . . . . . . . 33

Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . 33 Criptograa no isAlive . . . . . . . . . . . . . . . . . . . . . . 35 5.3.3.1 Geraao de Chaves . . . . . . . . . . . . . . . . . . . 35 c

5.3.4 5.4 5.5

Acesso ao Banco de Dados . . . . . . . . . . . . . . . . . . . . 36

Funcionamento do isAliveDaemon . . . . . . . . . . . . . . . . . . . . 36 Funcionamento do isAliveStation . . . . . . . . . . . . . . . . . . . . 38 viii

6 Instalao e Congurao do isAlive ca ca 6.1

40

Instalando o Banco de Dados MySQL . . . . . . . . . . . . . . . . . . 40 6.1.1 6.1.2 Cliente MYSQL . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Servidor MYSQL . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 6.3

Instalaao do isAliveDaemon . . . . . . . . . . . . . . . . . . . . . . . 42 c Instalaao do isAliveStation . . . . . . . . . . . . . . . . . . . . . . . 43 c 45 47 75 89 92

7 Concluses e Trabalhos Futuros o A Cdigo Fonte da Biblioteca TCP para Programao para Rede o ca B Cdigo Fonte do isAliveStation o C Cdigo Fonte do isAliveDaemon o D Script para Criao do BD StrikeIN ca

ix

Cap tulo 1 Introduo ca

Empresas e organizaoes esto rapidamente implementando infraestruturas c a de redes sem o baseadas no padro IEEE 802.11 [3], que corresponde a um padro a a de redes locais sem o atuando na faixa de 2.4 Ghz. O padro 802.11 fornece suporte a limitado a condencialidade do trfego neste tipo de rede, atravs do protocolo Wired ` a e Equivalent Privacy (WEP), que por sua vez apresenta falhas signicantes em seu projeto [4] [5]. Alm disso, o comit do IEEE responsvel pelo padro 802.11, deixou e e a a diversas das questes de segurana mais dif o c ceis, tais como gerenciamento de chaves e um mecanismo de autenticaao robusto, como problemas em aberto, ainda esperando c por uma soluao. Em funao disso, diversas instituioes que adotam soluoes sem c c c c o utilizam chaves xas para criptograa, ou simplesmente no utilizam criptograa a alguma. A implementaao de uma rede local sem o infraestruturada, como no caso c de uma rede que adota o padro IEEE 802.11, requer a utilizaao de um ponto a c de acesso (Access Point - AP) que controle as comunicaoes na WLAN (Wireless c Local Area Network ) e que atue como gateway para uma rede local (Local Area Network - LAN) cabeada. As WLANs transmitem dados em meio no-connado, por a utilizarem interfaces sem o (rdio frequncia) e no-delimitada por um meio cona e a dutor. Desta forma, ataques contra a autenticidade, conabilidade e disponibilidade das transaoes so facilitados quando no so adotadas medidas de segurana. Isso c a a a c acontece pois estas redes proporcionam risco potencial alm do controle de segurana e c f sica de uma instituiao. c

Ao longo dos ultimos anos, empresas tm empregado considerveis esforos e a c para proteger sua infraestrutura interna de ameaas externas. Como resultado destes c esforos, essas organizaoes tm canalizado seu trfego externo de rede atravs de c c e a e portas de acessodistintas, protegidas por rewall. Essa medida, no entanto, pode no fazer efeito diante de uma rede que possua uma extenso sem o, onde esta a a ultima, pode ser utilizada como uma back door para a rede interna, permitindo acesso alm do per e metro de segurana f c sica da organizaao. Desta forma, um c atacante quando bem sucedido, pode acessar servidores da rede interna, sentado em seu carro no estacionamento da empresa (parking lot attack ). Este cenrio est a a descrito em [6].

1.1

Motivao ca
Em um esforo no sentido de solucionar estas questes em aberto e ainda c o

sem soluao, o Laboratrio de Redes de Alta Velocidade - RAVEL desenvolveu c o e implementou um ambiente seguro para redes sem o baseadas no padro IEEE a 802.11b, denominado AirStrike [1]. Neste contexto, utilizou-se o sistema operacional OpenBSD e algumas ferramentas de segurana como redes privadas virtuais (Virc tual Private Networks - VPNs), rewalls e um sistema de controle de acesso a rede ` sem o, o sistema StrikeIN. Este ultimo, tambm descrito em [1]. O trabalho de e scrito neste documento parte integrante deste sistema e visa solucionar alguns dos e problemas j mencionados e outros que sero abordados posteriormente neste texto. a a O AirStrike uma implementaao segura de um AP para redes sem o e c baseado no sistema operacional OpenBSD [7] em conjunto com diversas outros softwares de cdigo aberto sobre uma plataforma i386. No entanto, um grave problema o foi encontrado na implementaao deste sistema, que permitia determinados tipos de c ataque. Uma vez que uma estaao se autentica no AP atravs do sistema StrikeIN, c e as regras do rewall no AP so editadas, permitindo que esta estaao possa usufruir a c das funcionalidades da rede. O problema est no fato de que, quando uma estaao a c se desliga da rede por algum motivo, as regras do rewall continuam inalteradas, ou seja, o IP da estaao que se desligou continua com permisso de acesso, uma vez c a

que as regras de rewall no foram modicadas. a O objetivo deste trabalho , de forma segura, vericar se uma estaao se e c desligou da rede e alterar automtica e dinamicamente, as regras do rewall, proibindo a o acesso de qualquer estaao com endereo IP que no tenha sido autenticado. c c a

1.2

O Que Foi Feito

Tendo em mente o contexto e a motivaao at aqui apresentados, uma aplicaao c e c

cliente-servidor foi desenvolvida e implementada na linguagem C/C++. Esta aplicaao c leva o nome de isAlive pois verica se uma estaoes sem o (STA) est viva(ligada c a e ativa na rede) ou no (a STA no est mais conectada a rede sem o por algum a a a motivo). Assim, o isAlive executa determinadas funoes e procedimentos para cada c caso (STA ligada ou STA desligada). O cliente isAlive, denominado aqui isAliveStation, funciona como um daemon na STA e aguarda requisioes do servidor isAlive, c chamado isAliveDaemon, executado tambm como um processo daemon no AP. e Bibliotecas do OpenSSL [8] foram utilizadas na criptograa e um mecanismo de troca de chaves foi concebido de forma a garantir autenticaao m tua entre as c u STAs e o AP. Assim, a STA se autentica no AP, que por sua vez, tambm deve se e autenticar na STA de forma a garantir que, por exemplo, uma STA no transmita a dados para um AP forjado por um atacante. Alguns protocolos de detecao de desligamento de estaao (Dead Peer Detecc c tion Protocol - DPDP) foram estudados [9], mas mostraram-se inecientes para as aplicaoes desejadas. Um protocolo foi desenvolvido de forma a alcanar o objetivo c c (detectar o desligamento de estaao) e garantir segurana e ecincia ao sistema, c c e atravs de trocas de chaves, mecanismos de autenticaao m tua e alteraao dinmica e c u c a das regras do rewall. Existiu a preocupaao em escrever software multi-plataforma, uma vez que c h interesse em dar exibilidade aos clientes, permitindo que as STAs possuam a diferentes sistemas operacionais (Windows 98/Me/2k/XP, Linux, outros sistemas derivados do Unix). Uma biblioteca multi-plataforma foi escrita em C/C++ para auxiliar na programaao para rede, de forma que toda a inicializaao das conexes c c o

TCP fossem automatizadas atravs da simples chamada de uma funao. e c

1.3

Este Documento
No cap tulo 2, ser abordado de forma simples o padro IEEE 802.11b e a a

alguns fundamentos do funcionamento de redes infra-estruturadas que operam segundo esse padro. Uma viso breve dos mecanismos de segurana previstos no a a c mesmo tambm ser dada neste cap e a tulo. O cap tulo 3 visa apresentar a arquitetura de segurana onde o presente trabalho se destina a ser aplicado, o AirStrike. J o c a capitulo 4 apresenta uma rpida introduao sobre protocolos de detecao de desligaa c c mento de estaao. Em seguida, o cap c tulo 5 apresenta a soluao aqui proposta para c o problema de detecao de desligamento de estaao, bem como o funcionamento do c c sistema proposto e sua implementaao. O cap c tulo 6 apresenta uma descriao dec talhada do processo de instalaao do software desenvolvido, tanto do cliente quanto c do servidor, alm de todos os passos necessrios para sua conguraao. Por m, e a c funcionalidades que podem vir a ser agregadas ao sistema e algumas mudanas no c funcionamento do mesmo so mencionadas no cap a tulo 7. Alm disso, neste ultimo e cap tulo, concluses sobre este trabalho so apresentadas. o a

Cap tulo 2 O Padro IEEE 802.11b a

Neste cap tulo ser abordado o padro IEEE 802.11b e alguns fundamena a tos do funcionamento de redes que o utilizam. Este padro dene tambm alguns a e mecanismos de segurana que sero abordados neste texto. As falhas j identicadas c a a nestes mecanismos tambm sero estudadas. e a O padro IEEE 802.11b [3] uma das soluoes mais adotadas para redes a e c locais sem o (WLANs). Esse padro est cada vez mais presente nas empresas, a a hotis, fbricas e lugares p blicos como aeroportos, universidades, hospitais e centros e a u comerciais, oferecendo a possibilidade de acesso a rede com suporte a mobilidade. ` ` O problema desta tecnologia emergente, est na sua falta de segurana, dea c vido a particularidades do meio f ` sico de transmisso. Como os dados so transa a mitidos pelo ar, no existem limites denidos como no caso das redes cabeadas. a Dessa forma, poss interceptar informaoes mesmo que a longas distncias, sem e vel c a necessariamente estar no mesmo ambiente ou prdio da WLAN. e As redes sem o, geralmente, esto conectadas a infra-estrutura da rede a ` cabeada, tornando-se assim, mais fcil para o invasor ganhar acesso a toda base a de dados da empresa. Por isso, extremamente importante a implementaao de e c mecanismos e sistemas de segurana as WLANs. c `

2.1

Camada F sica de Redes Sem Fio 802.11b

O padro 802.11b lanado em 1997 pelo IEEE representa um conjunto de a c

especicaoes para implementaao de redes locais sem o que prev trs tcnicas de c c e e e transmisso: a 1. Infra-vermelho. 2. DSSS (Direct Sequence Spread Spectrum) 3. FHSS (Frequency Hopping Spread Spectrum) Os dois ultimos mtodos utilizam transmisso de ondas curtas de rdio com e a a preendidas pela banda ISM de 2.4GHz. Dentre os mtodos mencionados, o DSSS e e o mais utilizado na implantaao de 802.11b. c

2.1.1

FHSS (Frequency Hopping Spread Spectrum)

O FHSS utiliza 79 canais com largura de 1 MHz cada. Um gerador de n meros u

pseudo-aleatrios utilizado para gerar a seqncia de saltos nos 79 canais. Desta o e ue forma, todas as estaoes que tenham utilizado a mesma semente em seu gerador e c que se mantenham sincronizadas, saltaro para os mesmos canais simultaneamente. a Cada estaao de uma mesma rede, que utiliza a mesma seqncia de saltos, car em c ue a cada canal por um per odo denominado dwell time, que ajustvel. Com o FHSS e a tem-se um sistema robusto contra ru de banda estreita que prov um n de do e vel segurana j na camada f c a sica, pois somente as estaoes que conhecem a seqncia c ue de saltos e o dwell time podero escutaro meio de maneira adequada e organizada. a No entanto o FHSS possui a desvantagem de oferecer uma baixa largura de banda.

2.1.2

DSSS (Direct Sequence Spread Spectrum)

J o DSSS espalhao espectro de freqncia de um sinal de banda estreita a ue

atravs de sua modulaao com uma seqncia de bits denominada de chip sequence. e c ue Obtem-se, desta forma, um sistema robusto contra ru de banda estreita ao preo do c de se necessitar de um controle de potncia para transmisso. Com o DSSS foi e a poss estender a taxa de transmisso do 802.11b de 1 Mb/s para 11 Mb/s. vel a 6

Figura 2.1: Exemplo de redes sem o adotando topologia ad hoc.

2.2

Operao de Redes Sem Fio 802.11b ca

Redes deste tipo operam em um dos dois modos dispon veis - ad hoc (sem

infraestrutura) ou infraestruturado. O padro IEEE dene o modo ad hoc como a Independent Basic Service Set (IBSS), e o modo infraestruturado como Basic Service Set (BSS). No modo ad hoc, cada estaao pode se comunicar diretamente com outras c estaoes na rede, como exemplicado na gura 2.1. O modo ad hoc foi projetado c de forma que apenas as estaoes que se encontrem dentro do alcance de transmisso c a (mesma clula) umas das outras podem se comunicar. Se uma das estaoes (STA e c A) quiser se comunicar com outra fora de seu alcance (STA B), uma terceira estaao c (STA C) dentro do alcance de STA A e STA B, deve ser utilizada como gateway e e fazer o roteamento. J no modo infraestruturado, cada cliente envia todas as suas mensagens a para uma estaao central, o AP. Esta estaao central fonciona como uma ethernet c c bridge e repassa as mensagens para a rede apropriada, tanto para uma rede cabeada, quanto para a prpria rede sem o, como pode ser visto na gura 2.2. o Antes de trocarem dados, STAs e APs devem estabalecer um relacionamento, ou uma associaao. Apenas depois que a associaao for estabelecida, as duas estaoes c c c podem trocar dados. No caso de uma rede com infraestrutura, as STA se associam com o AP. O processo de associaao possui dois passos, envolvendo trs dos seguintes c e 7

Figura 2.2: Exemplo de redes sem o adotando modo infraestruturado, onde um AP utilizado na comunicaao. e c

estados: 1. No autenticado e no associado, a a 2. Autenticado e no associado, e a 3. Autenticado e associado. Para mudar de estados, as partes interessadas na comunicaao trocam menc sagens denominadas quadros de gerenciamento ou management frames. No entanto, uma STA precisa saber se existe algum AP dentro do alcance de seu rdio e a qual AP ela deve se associar. Assim, todos os APs transmitem a um quadro de gerenciamento chamado beacon em intervalos de tempo xos. Para se associar a um AP e se unir a uma BSS, uma estaao procura escutar beacons c para identicar APs dentro do alcance de seu rdio. Ento, a STA seleciona a BSS a a a qual ela deseja se unir. Em seguida, AP e STA trocam diversas mensagens de ` gerenciamento com o objetivo de realizar autenticaao m tua. Os dois mecanismos c u de autenticaao previstos no padro sero comentados nas seoes 2.3.2 e 2.3.3. c a a c Aps uma autenticaao bem sucedida, a STA passa para o segundo estado, o c autenticado e no associado. Passar do segundo estado para o terceiro, autena ticado e associado, envolve a STA enviando um pedido de associaao e o AP, em c seguida, um quadro de resposta a esse pedido. Uma vez que esse processo ocorre, a 8

Figura 2.3: O funcionamento do WEP (extra de [2]) do

STA passa a ser um ponto (peer ) da rede sem o e pode, ento, transmitir quadros a atravs da mesma. e

2.3

Mecanismos de Segurana em Redes 802.11 c

O padro 802.11 dene diversos mecanismos propostos para tornar seguro a

um ambiente de comunicaao sem o. Esta seao apresenta a descriao de cada c c c mecanismo.

2.3.1

O Mecanismo WEP (Wired Equivalent Privacy )

O protocolo WEP est denido no padro 802.11b [3] como protocolo de sea a

gurana para as transaoes eletrnicas no ambiente de redes sem o e foi projetado c c o para garantir condencialidade do trfego nestas redes. Diversas falhas de segurana a c foram encontradas no protocolo WEP. No entanto, trabalhos como [4] e mais recentemente [5] e [10], demosntram que o WEP prov, na verdade, condencialidade e limitada. O padro IEEE 802.11 utiliza o protocolo WEP na camada de enlace para a autenticar e criptografar os dados que sero transmitidos na rede sem o. A gura a 2.3 mostra como o WEP funciona: O Vetor de Inicializaao (VI) de 24 bits concatenado com a chave secreta, c e 9

que pode ser de 40 ou 104 bits, resultando em uma chave composta de 64 ou 128 bits. Esta, por sua vez, serve de entrada para um gerador de n meros pseudo-aleatrios u o (PRNG) que baseado no algoritmo RC4 [11]. e A sa do PRNG uma seqncia pseudo-aleatria de bits baseada na chave da e ue o composta e com o mesmo tamanho do texto a ser criptografado. Esse texto obtido e atravs da concatenaao do texto puro com o resultado do processo para checagem e c de integridade (Integrity Check Value - ICV) que utiliza o algoritmo de checagem de redundncia CRC-32 (Cyclic Redundancy Check). A seqncia de bits pseudoa ue aleatria utilizada para criptografar o texto atravs de uma operaao binria XOR. o e e c a O resultado do XOR concatenado com o VI e enviado pelo emissor atravs do meio e e de transmisso. a O receptor usa o VI que vem no in do pacote e a chave secreta comparcio tilhada para gerar a mesma seqncia criada pelo PRNG e decriptografar o texto ue cifrado. Ento, aplica-se o CRC-32 e compara-o com o ICV concatenado ao texto a puro para checar a integridade da mensagem recebida.

2.3.2

Open System Authentication

No mecanismo de autenticaao com sistema aberto (Open System Authentic

cation), a estaao pode associar-se com qualquer ponto de acesso e escutar todos os c dados que so transmitidos sem criptograa. Este mtodo basea-se na transmisso a e a da identidade da estaao que quer ser autenticada para a estaao que realizar a c c a autenticaao; c E o protocolo de autenticaao padro para 802.11. Como o prprio nome c a o sugere, este sistema autentica qualquer estaao que a esteja requisitando. Ou seja, c no um processo muito eciente, do ponto de vista de quem se preocupa com a e segurana. Experimentos mostram [6] que estas requisioes (os quadros de gerencic c amento) so enviadas abertamente (sem criptograa), mesmo quando o WEP est a a habilitado.

10

Figura 2.4: A autenticaao no protocolo WEP (extra de [2]) c do

2.3.3

Pre-Shared Key Authentication

Autenticaao com chave pr-compartilhada (Pre-Shared Key Authentication) c e

utiliza um processo desao-resposta em conjunto com uma chave secreta compartilhada, de forma a realizar o processo de autenticaao. A STA que deseja se autenticar, c quem inicia o processo, envia um quadro de gerenciamento contendo o pedido de autenticaao, indicando que se deseja usar shared key authentication. O AP, quem c responde, envia um quadro de gerenciamento contendo a resposta ao pedido de autenticaao, formada por 128 octetos de texto, como desao para a STA. O texto do c desao criado pelo gerador de n meros pesudo-aleatrios (pseudo-random number e u o generator - PRNG) do WEP, junto com o shared secret e o vetor de inicializaao c (VI). Uma vez que a STA recebe o quadro de gerenciamento contendo o desao, ela copia o conte do do texto deste desao para o novo quadro de gerenciamento. Este u novo quadro encriptado com WEP utitlizando a chave compartilhada, juntamente e com um novo VI selecionado pela STA. O quadro de gerenciamento encriptado e ento, enviado para o AP, que decripta este quadro recebido e o submete ao ICV a usando 32-bit CRC. Se o ICV for vlido e o texto do desao for o mesmo enviado a na primeira mensegem, a autenticaao ser bem sucedida. Caso a autenticaao seja c a c bem sucedida, AP e STA trocam de papeis e repetem todo o processo para garantir autenticaao m tua. c u A gura 2.4 ilustra este processo de autenticaao. A estaao A envia uma c c 11

requisiao e a sua identicaao (Auth Req; Sta ID) para a estaao B. B responde c c c com uma mensagem contendo um desao de 128 bits (Challenge). A estaao A copia c o desao em uma nova mensagem, criptografa com a chave WEP pr-compartilhada e e reenvia para B (Response). A estaao B checa a resposta de A e responde com o c resultado do procedimento de autenticaao (Result). c

2.3.4

Closed Network Access Control

A Lucent deniu um mecanismo de controle de acesso proprietrio chamado a

Closed Network [12]. Com esse mecanismo, poss e vel usar tanto redes abertas quanto fechadas. Em uma rede aberta, qualquer um tem permisso de se associar a a rede. Em uma rede fechada, apenas os usurios cientes do nome e SSID da rede ` a podem se associar a mesma. Na verdade, pode se dizer que o nome da rede funciona ` como uma chave pr-compartilhada. e

2.3.5

Listas de Controle de Acesso

Outro mecanismo utilizado por vendedores (mas no denido no padro) a a

para promover segurana no acesso a rede o uso de listas de acesso baseadas nos c e endereos MAC dos clientes (Access Control Lists). Cada AP pode limitar o acesso c de clientes sem o a rede, aos que possuirem seus endereos MAC na lista. Caso o ` c endereo MAC de um cliente no esteja na lista, seu acesso negado. c a e Este tipo de restriao no garante que apenas mquinas autorizadas (cujos c a a endereos MAC das interfaces estejam cadastrados na lista) possam acessar a rede, c uma vez que tcnicas de MAC spoong so amplamente conhecidas. e a

2.3.6

Gerenciamento de Chaves
Gerenciamento de chaves no padro 802.11 um outro aspecto deixado a a e

cargo de desenvolvedores e fabricantes. Por esse motivo, apenas alguns dos grandes fabricantes implementaram, em seus produtos, alguma forma de gerenciamento de chave. No entanto, em alguns casos, os detalhes dispon veis no equipamento indicam um problema ainda maior pois eles revelam a utilizaao de protocolos que possuem c

12

vulnerabilidades amplamente conhecidas. O 802.11, no entanto, fornece dois mtodos para utilizaao de chaves WEP. e c O primeiro oferece uma janela de quatro chaves registradas de forma manual. A estaao ou AP pode decriptar pacotes emcriptados com qualquer uma das quatro c chaves. A transmisso, no entanto, est limitada a chave padro, que nada mais a a ` a e do que uma das quatro chaves j mencionadas. O segundo mtodo chamado de a e e tabela de mapeamento de chaves. Neste mtodo, cada endereo MAC pode possuir e c sua prpria chave separada. O tamanho desta tabela deve ser de, no m o nimo, dez (10) entradas de endereos de acordo com as especicaoes do 802.11. O tamanho c c mximo, por sua vez, depende do chip-set utilizado pelo fabricante. A utilizaao a c de chaves separadas para cada usurio, ameniza problemas relacionados a ataques a criptogracos, facilitados por outros mtodos. O problema deste tipo de mecane ismo reside em encontrar um per odo de chave razovel, uma vez que as chaves so a a trocadas manualmente.

13

Cap tulo 3 Ambiente Seguro Para Redes 802.11b - AirStrike

A implementaao de uma WLAN infraestruturada requer a utilizaao de um c c ponto de acesso (AP) que controle as comunicaoes na WLAN e que atue como c gateway para uma LAN cabeada ou a Internet. Juntamente com a disseminaao ` c e utilizaao deste padro surgiram diversas questes relacionadas a segurana das c a o ` c transaoes eletrnicas que notoriamente encontram novos desaos em uma interface c o area e no-delimitada por um meio condutor. e a A arquitetura da WLAN outro aspecto fundamental para a garantia de e segurana dos usurios mveis, do AP e da prpria infraestrutura da rede local c a o o cabeada de uma entidade, que tem na WLAN uma extenso de sua abrangncia. a e A utilizaao de rewalls, endereos IPs no roteveis, por exemplo, permitem que c c a a o trfego da rede sem o seja contido e controlado. A entidade central na implea mentaao de uma WLAN o AP, portanto oferecer meios que permitam implementar c e um AP com baixo custo e com total controle sobre as caracter sticas de segurana c dos servios e softwares congurados no mesmo um dos objetivos do AirStrike. c e Desta forma, tanto na instalaao do AP quanto na implementaao do isAlive, c c optou-se pela utilizaao de softwares de cdigo aberto e gratuitos, contando assim c o com uma ampla documentaao e suporte de diversos desenvolvedores na comunidade c de cdigo aberto. Esta seao descreve a implementaao de uma soluao de segurana o c c c c para WLAN baseada no sistema operacional OpenBSD [7]. Para tal, utilizou-se

um microcomputador como AP onde realiza-se autenticaao m tua, autorizando a c u comunicaao entre as estaoes da rede sem o e o AP atravs do fornecimento de c c e credenciais como login, senha e certicados digitais. Alm disso, criptografandoe se toda a comunicaao entre as estaoes da WLAN e o AP de forma a garantir a c c condencialidade.

3.1

O que o AirStrike e
O AirStrike uma distribuiao do sistema operacional OpenBSD que pere c

mite a conguraao de um AP a partir de um microcomputador, de forma que sejam c instalados por padro um conjunto de ferramentas de segurana que garantam a auta c enticaao dos usurios mveis da WLAN e o sigilo de todas as transaoes eletrnicas c a o c o entre as estaoes da WLAN e o AP. c O OpenBSD um sistema operacional UNIX gratuito, baseado no BSD 4.4, e cujos principais esforos enfatizam a portabilidade, padronizaao, correao, seguc c c rana proativa e criptograa integrada. c O AirStrike estabelece tambm uma arquitetura de segurana para utilizaao e c c de uma WLAN como extenso da abrangncia de uma LAN cabeada, permitindo o a e controle e gerncia de vrios APs a partir de uma estaao de gerncia. Os objetivos e a c e do AirStrike so: a 1. Desenvolver uma distribuiao do sistema operacional OpenBSD, denominada c AirStrike, que capacite um usurio a congurar de forma simples e rpida um a a computador como AP. 2. Gerar um conjunto de sugestes e prticas que contemple a segurana da ino a c terconexo de WLANs em ambientes com infraestrutura cabeada prexistente. a e 3. Implementar um sistema de autenticaao de usurios baseado em certicados c a digitais e credenciais fornecidas por login e senha. 4. Congurar uma VPN entre as estaoes WLAN e o AP. c

15

Figura 3.1: Arquitetura AirStrike

3.2

Arquitetura de segurana proposta pelo AirStrike c

Diversas medidas de segurana so adotadas na conguraao do AP AirStrike. c a c

Algumas consideraoes de segurana so relativas a prpria conguraao segura c c a ` o c de um sistema operacional e outras so relativas aos mecanismos de autenticaao, a c autorizaao, condencialidade e integridade do uxo de informaoes presentes na c c WLAN gerenciada pelo AP. Uma arquitetura proposta para a integraao de uma c WLAN a uma LAN cabeada est representado na gura 3.1. a Est descrito abaixo o processo pelo qual uma STA passa desde o momento a em que deseja se associar ao AP at o fechamento da conexo. E importante entender e a tal procedimento para que que claro o papel do sistema isAlive, foco deste trabalho, onde ele atua e que problemas o mesmo se prope a resolver. o 16

1. STA procura uma rede no dom nio denido pela SSID 2. STA e AP se sincronizam e a associaao estabelecida c e 3. STA requisita um IP (cliente DHCP) 4. AP fornece um IP a STA (servidor DHCP) ` 5. STA envia mensagens UDP para formaao do t nel VPN c u 6. AP verica credenciais do usurio mvel, formando o t nel VPN a o u 7. Usurio da STA acessa pgina web a m de se autenticar a a 8. O AP requisita o certicado digital do usurio da STA a 9. O usurio da STA apresenta o seu certicado digital a 10. O AP apresenta o seu certicado digital a STA ` 11. O AP acrescenta o IP da STA no banco de dados de IPs autorizadas 12. O AP recongura as regras de rewall 13. A STA est pronta para utilizar os recursos de rede, oferecidos atravs do AP a e 14. Durante o per odo de conexo, o AP verica se a STA continua ativa, a m a de que possa controlar de forma adequada as regras do rewall. Esta e outras tarefas cam a cargo dos sistema isAlive, descrito no cap tulo 5 A segurana do ambiente AirStrike est dividida em quatro partes fundac a mentais. Cada uma destas quatro partes ser descrita nas seoes subsequentes. So a c a elas: 1. Regras de Firewall, seao 3.2.1 c 2. VPN, seao 3.2.2 c 3. StrikeIN, seao 3.2.3 c 4. isAlive, seao 3.2.4 c 17

3.2.1

Regras de Firewall
O OpenBSD possui um ltro de pacotes denominado pf (packet lter ) que

permite a conguraao de um rewall no AP, assim como a utilizaao de endereos c c c no-roteveis atravs da aplicaao de NAT (Network Address Translation) [13]. a a e c Desta forma pode-se controlar o trfego presente na WLAN atravs da construao a e c de regras de rewall espec cas e diculta-se, atravs do uso do NAT, o descobrie mento das mquinas existentes em uma WLAN para um inimigo que se encontre a fora do ambiente denido pela WLAN. O uso do pf vital para o funcionamento e controle de todo o ambiente e AirStrike pois, a mudana dinmica destas regras permite que um usurio mvel c a a o tenha acesso seletivo aos recursos da rede na medida em que ele fornea as credenciais c necessrias para passar para o prximo n de acesso aos mesmos. a o vel Inicialmente as regras de rewall s permitem que o trfego destinado ao o a estabelecimento de uma VPN seja transmitido entre a STA e o AP. Aps o estabo elecimento da VPN permite-se que deste trfego criptografado, pelo protocolo ESP, a somente uma pgina web de autenticaao presente no AP possa ser acessada, onde a c credenciais como certicados digitais (autenticaao m tua) e o par login/senha (auc u torizaao) so exigidos. Aps a vericaao e validaao do par login e senha em um c a o c c banco de dados MySQL, implementado e hospedado em uma mquina espec a ca da LAN cabeada, modicam-se mais uma vez as regras do rewall, permitindo que este usurio da WLAN acesse todos os recursos de rede oferecidos pelo AP atravs da a e VPN. E fundamental vericar se a estaao da WLAN continua ativa ao longo da c utilizaao dos recursos do AP de forma a se previnir roubo de sesso e garantir a c a eccia das regras do rewall. Isto garantido pelo isAlive que sonda ativamente a a e presena de uma estaao na rede, como ser visto mais a frente. c c a

3.2.2

VPN (Virtual Private Network) com IPSec (IP Secure)

O sigilo das transaoes eletrnicas no ambiente AirStrike garantido pela c o e

implementaao de uma VPN entre o AP e as estaoes WLAN, sendo assim, todo o c c trfego encontra-se critptografo no meio de transmisso. a a 18

Dentre vrias propriedades desejveis em comunicaao de dados segura, podea a c se citar: a condencialidade, a integridade e a autencidade, como as mais comuns. Mecanismos ecientes para garantir condencialidade dos dados em redes sem o so as VPNs. Aqui ser abordado rapidamente o protocolo IPSec para estabelecer a a a VPN entre o ponto de acesso e as estaoes sem o. O IPSec prov segurana atravs c e c e de criptograa e/ou autenticaao na camada IP. c O IPSec fornece estas caracter sticas na utilizaao de dois protocolos: Cabealho c c de Autenticaao (Authentication Header - AH) [14] e o Encapsulamento Seguro do c Campo de Dados (Encapsulating Security Payload - ESP) [15]. O AH e o ESP suportam dois modos de operaao: transporte e t nel. c u Modo Transporte: O modo transporte prov proteao para os protocolos e c

da camada superior (TCP e UDP, por exemplo). E usado, geralmente, em comunicaoes m-a-m entre estaoes. Neste modo o ESP criptografa e, opc c

cionalmente, autentica o campo de dados do pacote IP. O AH autentica o campo de dados IP e campos do cabealho IP. A Figura 3.2(b) ilustra o ESP c e o AH no modo transporte. Modo Tnel: Tipicamente utilizado para estabelecer VPNs, prov proteao u e c ao pacote IP completo. Os campos do AH e ESP so adicionados ao pacote a IP e tudo passa a ser tratado como o campo de dados do pacote IP de um novo pacote, inclusive com um novo cabealho IP. A Figura 3.2(c) mostra o c funcinamento do IPSec em modo t nel. O ESP criptografa e, opcionalmente, u autentica todo o pacote IP interno. O AH autentica o pacote IP interno e partes do cabealho externo. c

3.2.3

StrikeIN
O processo de autenticaao est intimemente ligado com o funcionamento do c a

isAlive. Assim, o sistema StrikeIN ser abordado mais adiante no texto na seao a c 5.1.

19

Figura 3.2: Formato do pacote IPSec (extra de [2]) do

20

3.2.4

isAlive
A implementaao e o funcionamento do isAlive e seu protocolo DPD, sero c a

descritos em seoes subsequentes no cap c tulo 5.

21

Cap tulo 4 Deteco de Desligamento de ca Estao - DPD ca

Este cap tulo se dedica a introduao do tema envolvendo mecanismos de Dead c Peer Detection - DPD, sua importncia e relevncia neste trabalho, bem como a a a apresentaao de alguns destes mecanismos propostos na literatura. Tais mecanismos c foram estudados e analisados ao longo deste trabalho e algumas concluses e cr o ticas a tais mecanismos tambm podem ser encontradas nas seoes deste cap e c tulo.

4.1

Importncia de Mecanismos de DPD a

Quando existe comunicaao entre dois pontos de rede (mais especicamente c

no caso em estudo, entre o AP e a STA), poder existir uma situaao onde a conexo a c a entre eles ser desfeita de forma inesperada. Esta situaao pode ocorrer devido a a c problemas de roteamento, reinicializaao de uma das partes comunicantes, a STA sai c da area de cobertura do AP, a bateria da STA acaba, entre outros fatores. Em casos como estes dicilmente existe um meio do AP identicar esta perda de conectividade. Em situaoes assim, as regras de rewall permaneceriam inalteradas e as perc misses de acesso dadas ao IP da STA recm desconectada ainda estariam garano e tidas. Alm disso, no caso em que se utiliza t neis IPSec entre STA e AP, o t nel e u u destinado a STA que se desconectou continuaria ativo e consumindo recursos do AP. Problemas de detecao de desconexo tm sido endereados por propostas que c a e c

necessitam o envio de mensagens peridicas de HELLO/ACK como conrmaao de o c que a estaao est ainda viva. Esses esquemas tendem a ser unidirecionais (apenas c a envia de mensagens de HELLO) ou bidirecionais (envio do par HELLO/ACK). Segundo [9] o problema com este tipo de esquemas com envio peridico de o mensagens est, justamente, no fato de existir a necessidade de se enviar as mesa mas em intervalos regulares de tempo. Na implementaao, isto se traduziria no c gerenciamento de um relgio responsvel por contar o tempo entre mensagens. o a

4.2

Desligamento de uma Estao ca

A autenticaao e autorizaao de uma estaao implica em mudanas nas regras c c c c

do rewall, desta forma deve-se prover um mecanismo para mudana das regras c quando a mesma estaao se desliga da rede. c No prudente contar com uma mensagem de requerimento de dissociaao a e c da rede por parte de uma STA, pois os motivos de sua sa podem ser os mais da diversos (perda de sinal, interferncia, falta de energia, etc), motivos estes que a e impediriam o envio de uma mensagem deste tipo.

4.2.1

Timeout
Uma proposta de fcil implementaao seria a de se adotar um tempo de a c

conexo limitado para as estaoes, requisitando uma reautenticaao aps este tempo a c c o ter decorrido. Isto implica em um grande inconveniente para os usurios, que devero a a se reautenticar diversas vezes ao longo de uma conexo. A escolha deste intervalo a de conexo estaria limitada pela falta de funcionalidade e praticidade, que um curto a per odo de tempo traria ao usurio e a diminuiao na segurana da rede para usurios a c c a que se desconectassem antes deste tempo chegar ao m, uma vez que as regras do rewall estariam abertas para aquele IP. Fica claro, portanto que propostas mais avanadas devem ser empregadas. c Algumas delas esto descritas em seguida. a

23

4.2.2

Sondagem Ativa (Active Probing )

O procedimento de sondagem ativa envolve algum tipo de mensagem enviada

a estaao sem o, assim como nos mecanismos uni e bidirecionais mencionados ` c anteriormente e descritos em maiores detalhes na seao 4.2.4. Um processo como c o envio de um ping para o cliente, por exemplo, uma forma de se vericar se e uma estaao cliente continua ativa na rede, porm algumas consideraoes devem ser c e c feitas. O envio de um ping no previne que um cliente vlido se desligue da rede e que a a em um instante subseq ente uma estaao, controlada por um atacante e utilizado o u c mesmo IP, entre na rede. Desta forma a estaao inimiga roubaria a seao da estaao c c c vlida, se fazendo passar pela mesma. a Uma proposta intr nseca a construao do projeto AirStrike se baseia no fato ` c de que aps o processo de autenticaao, descrito ao longo da seao 5.1 ser compleo c c tado, assume-se que toda a comunicaao entre o AP e a estaao passa por uma VPN c c e portanto uma estaao inimiga que roubasse a seao da estaao vlida no teria c c c a a meios de decriptar o probe representado pelo ping e no teria como respond-lo de a e forma adequada. Uma terceira proposta, independente da conguraao de uma VPN, seria a c instalaao de uma espcie de plugin no cliente que responde a uma requisiao de um c e c daemon presente no AP. Este mecanismo seria semelhante a um ping, mas neste caso, informaoes adicionais seriam trocadas de forma a garantir a autenticidade da c estaao. c

4.2.3

Sondagem Passiva (Passive Probing )

O rewall contido no AP possui uma tabela de estados das conexes que um o

cliente mantm ativas. Um mecanismo poderia ser implementado, para que fosse e vericado se um determinado cliente est ou no registrado na tabela de estados do a a rewall. Caso ele no estivesse, isto serviria como indicativo de que a conexo foi a a desligada. Algumas observaoes podem ser feitas a este respeito. Primeiramente, c recairia-se no caso do ping trafegando em uma rede sem criptograa, ou seja, um cliente vlido que se desligasse, seguido da entrada de um inimigo, indicariam a a 24

este mecanismo proposto que o cliente continua ativo. Esta caso caracterizaria falha de segurana, onde as regras do rewall no seriam capazes de impedir a aao do c a c atacante. O uso da sondagem ativa requer cuidados com relaao a utilizaao da banda c c da rede e na deniao do per c odo entre vericaoes de cada cliente e para cada c cliente. O uso de sondagem passiva conta somente com o processamento no AP e no consome banda, no entanto sofre da falha do roubo de uma sesso por um a a inimigo.

4.2.4

Keepalives vs. Heartbeats

Nesta seao, ser feita uma anlise dos mecanismos Keepalive e Heartbeat, c a a

descritos em [9]. Nesta referncia tais mecanismos so descritos atravs de exemplos e a e de comunicaao entre dois pontos em uma rede sem o, peer A e peer B. Neste c texto, tal anlise ser realizada do ponto de vista da arquitetura aqui estudada, ou a a seja, a arquitetura de redes sem o infraestruturada utilizada no sistema AirStrike (como visto nas guras 2.2 e 3.1). 4.2.4.1 Keepalives

Considere um sistema de keepalive onde um AP requer, regularmente, indicaoes de que uma determinada STA est conectada a rede e vice-versa. Os dois c a ` lados da conexo (AP e STA) entrariam em um acordo sobre o intervalo entre as a mensagens de keepalive, o que signica que deve existir algum tipo de negociaao c durante a fase inicial de comunicaao. Para que a detecao de desconexo seja c c a poss vel, as mensagens de keepalive devem ser enviadas freq entemente, por exemu plo, a cada intervalo de tempo T segundos. Essencialmente, a cada T segundos, um deve enviar uma mensagem de HELLO para o outro. Esta mensagem serve, para quem a envia, como uma prova de que o outro ponto de comunicaao (quem c a recebe) est vivo. Em troca, o outro ponto deve admitir recebimento de cada a HELLO com uma mensagem de ACK. Deve existir em cada estaao comunicante c (AP e STA), um contador de tempo. Se T segundos se passaram, e um dos lados (o AP por exemplo) no recebeu o HELLO, este ir enviar uma mensagem de HELLO a a 25

para a STA. A decorrente mensagem de ACK gerada pela STA serve como prova de vida da mesma para o AP. O recebimento tanto de mensagens HELLO quanto de ACKs fazem com que o contador recomece a contagem do tempo decorrido entre mensagens. Falha no recebimento de um ACK durante um determinado per odo de tempo, caracteriza um erro. Aps um determinado n mero de erros considera-se o u que a estaao no est mais conectada a rede. c a a ` Neste tipo de esquema, a parte interessada (AP) em detectar se o outro ponto de rede (STA) est conectado quem inicia a troca de mensagens. E conceb a e vel, em tal esquema, que a STA nunca esteja interessada em saber se o AP esta vivo ou no. Nesse caso, o onus cairia sempre sobre o AP em iniciar a comunicaao. a c 4.2.4.2 Heartbeats

Nesta seao, ser considerado um esquema de DPD envolvendo mensagens c a unidirecionais. A entidade interessada na situaao de uma outra estaao, dependeria c c do envio de mensagens peridicas por parte desta, de forma que, tais mensagens o demonstrem que esta determinada estaao est viva. Assim, se o AP quiser saber c a se uma STA est conectada, a mesma dever enviar a cada intervalo de tempo T , a a uma mensagem HELLO para o AP. Caso este no receba a mensagem de HELLO a esperada, proveniente da STA, ser computado um erro. Mais uma vez, aps um a o determinado n mero de erros, considera-se que a estaao no est mais conectada a u c a a ` rede. Uma das desvantagens neste tipo de esquema de DPD conar na STA para e enviar as mensagens que demonstram uma conexo ativa. Apesar disso, se o AP a quiser saber se a STA est viva, a estaao deve estar ciente disso. Fica claro que, a c tambm neste cenrio, um per e a odo de negociaao necessrio antes do in c e a cio da sondagem. 4.2.4.3 Consideraoes c

Essencialmente heartbeats e keepalives baseiam-se em trocas de mensagens de HELLO em intervalos regulares. Em [9], os autores armam que, em um esquema de DPD, o estado de uma estaao no pode estar dependente do estado de outra c a 26

e que a prova de vida de um ponto de rede para outro s deve ser enviada quando o necessrio e no determinada por intervalos de tempo. Arma-se ainda que estas a a mensagens devem ser apenas trocadas quando o canal estiver ocioso, pois o prprio o trfego entre as estaoes serviria como prova de vida de uma para a outra. a c Considere agora, novamente, um cenrio onde existe um rewal em um AP, a cujas regras necessitam ser editadas dinamicamente e com urgncia (no momento em e que um evento ocorre a regra do rewall deve ser alterada o mais rpido poss a vel) e uma STA que conecta-se a rede atravs deste AP. O AP precisa receber informaoes ` e c periodicamente a respeito do estado desta estaao. Existe um problema, no entanto, c caso as mensagens de HELLO sejam enviadas apenas em momentos de silncio (no e a existe trfego proveniente de STA). Se este trfego for forjado por um atacante, a a quando a STA se desconectar da rede, a STA inimiga continuar enviando pacotes a para o AP em nome da STA e o AP, em momento algum ir requisitar prova de vida a desta estaao, uma vez que a STA (do ponto de vista do AP) ainda est enviando c a trfego. As regras de rewall permaneceriam inalteradas para que o atacante pudesse a usufruir das funcionalidades da rede. Em [9], o protocolo DPD proposto executa requisioes de prova de vida apec nas quando no existe comunicaao entre as estaoes e somente quando uma das a c c estaoes est interessada no estado (conectado ou no) da outra. No cenrio esc a a a tudado neste trabalho (gura 3.1), o AP sempre estar interessado no estado da a STA. Este cenrio e a proposta de implementaao de um protocolo DPD aplicado a c ao mesmo sero apresentadas nas seoes posteriores. a c

27

Cap tulo 5 isAlive - Proposta, Implementao ca e Funcionamento

Neste cap tulo, ser apresentada a proposta de um protocolo DPD implemena tado pelo isAlive e utilizado no sistema AirStrike dentro de um ambiente infraestruturado de rede sem o, como pode ser visto na gura 3.1. Neste cap tulo, detalhes da implementaao sero abordados, onde todo o funcionamento do sistema isAlive c a ser apresentado. a

5.1

Sistema de Autenticao StrikeIN ca

Uma STA que queira fazer parte de uma rede sem o local deve possuir um

IP para poder se comunicar com os demais membros da rede. Na implementaao c de redes WLAN, que tem como caracter stica um certo n vel de mobilidade das estaoes, torna-se mais interessante prover estes IPs de forma dinmica, utilizandoc a se do DHCP. Portanto, uma STA que j tenha se associado a uma BSS1 ir requisitar a a um IP do AP de forma a poder enviar e receber informaoes atravs do mesmo. Este c e IP fornecido a estaao, mas alguns procedimentos a mais devem ser completados e ` c antes da estaao poder enviar e receber informaoes atravs da rede. c c e Existe, no AP, um rewall que bloqueia ou permite acesso aos recursos da
1

Basic Service Set ou Unidade Bsica de Servio se assemlha a uma clula de comunicaao a c ` e c

formada ao redor de uma Estaao Base existente na telefonia celular. c

rede de acordo com procedimentos de autenticaao, detalhados a seguir nesta seao. c c Algumas ferramentas OpenSource foram desenvolvidas por terceiros com este objetivo, mas nenhuma delas mostrou-se adequada para este projeto. Podem ser citadas: 1. Oasis - Ferramenta de autenticaao desenvolvida por um grupo Stockholc mOpen.net, cujo principal empecilho em sua utilizaao o fato de se destinar c e a plataformas Linux e FreeBSD e no suportado no OpenBSD [16]. a e 2. NoCAT - Projeto desenvolvido por uma comunidade de usurios de redes a 802.11. Esta ferramenta roda em plataforma Linux e s verica a sa de um o da cliente da rede atravs de timeout [17]. e 3. NetLogon - Roda em plataforma Linux e no faz autenticaao em banco de a c dados [18]. No StrikeIN, o usurio, aps ter se associado ao AP (ver passo-a-passo na a o seao 3.2), deve acessar uma pgina de autenticaao (gura 5.1) e entrar com seu c a c login e sua senha. Uma vez autenticado, o endereo IP utilizado por aquele usurio e c a sua senha, so armazenados em uma tabela no banco de dados chamada IPsValidos. a Esta tabela ser utilizada pelo isAlive para a detecao segura de desligamento da a c STA. E importante que antes que o usurio faa o login no sistema ele inicie o a c isAliveStation (ver seao 5.5). c

5.2

Protocolo DPD Proposto no isAlive

Foi proposto um mecanismo de detecao de desligamento de estaao baseado c c

em sodagem ativa das mesmas. Este tipo de sondagem de estaoes foi descrito na c seao 4.2.2. Detalhes do protocolo proposto e das trocas de mensagens entre STAs c e o AP podem ser vistos na gura 5.2. Para iniciar o processo de detecao de desligamento de estaao, o AP gera c c uma seqncia de bytes aleatrios (PKT-KEY1) e a encripta utilizando a senha ue o (PWD) do usurio cadastrado como chave. A seqncia encriptada enviada a a ue e ` STA que a decifra utilizando a chave pr-compartilhada (a senha do usurio, PWD). e a 29

Figura 5.1: Pgina de autenticaao para acesso ao AirStrike. a c

30

Figura 5.2: Troca t pica de mensagens do sistema isAlive.

31

Neste ponto, a STA utiliza o conte do decifrado da mensagem recebida como a nova u chave para encriptar uma mensagem de ACK e envia-la ao AP. Uma vez que o AP recebe esta mensagem, ele ir decripta-la. Caso esta seja decifrada com sucesso, ca a provado que e STA em questo ainda est ativa na rede. Este processo se repete a a periodicamente at que a STA no mais responda as requisioes do AP ou responda e a c de forma incorreta (onde o AP no ser capaz de decifrar a mensagem de ACK). a a Caso o AP no consiga estabelecer conexo com a STA ou no consiga decifrar a a a corretamente a mensagem de ACK, a STA considerada inativa. Uma vez que uma e STA considerada inativa, as regras do rewall no AP so editadas, de forma a e a retirar as permisses de acesso do IP que a STA em questo utilizara. o a Estes procedimentos garantem a autenticidade da estaao e evitam ataques c replay e roubo de sesso, garantindo tambm, que o usurio da estaao sem o esteja a e a c enviando dados para o AP correto, evitando que um inimigo se passe pelo ponto de acesso.

5.3

Implementao do isAlive ca
Nesta seao, detalhes da implementaao sero abordados, onde o ambiente c c a

de desenvolvimento do sistema isAlive ser apresentado. a

5.3.1

Aplicao Cliente Servidor ca

A proposta do isAlive a instalaao de um software (cliente da aplicaao) na e c c

STA que responda a uma requisiao de um daemon2 (servidor da aplicaao), instalc c ado no AP (onde est presente o rewall ). Este processo seria semelhante ao sistema a de keepalive, descrito na seao 4.2.4. No entanto neste caso, informaoes adicionais c c seriam trocadas de forma segura entre clientes e servidor, com o objetivo de garantir tanto a autenticidade da estaao, quanto a do AP. Isso evitaria que uma STA se c associasse a um AP forjado por um atacante e no ao AP de produao, ao mesmo a c tempo que permitiria determinar que a STA requisitando conexo realmente quem a e diz ser. Chamamos este procedimento de autenticaao m tua. c u
2

Um daemon um programa que executado em segundo plano e no possui terminal associado. e e a

32

Nesta proposta o servidor da aplicaao, chamado aqui de isAliveDaemon, esc taria instalado no AP, de onde enviaria requisioes de prova de vida periodicamente c ao cliente da aplicaao, chamado de isAliveStation, presente nas estaoes que esc c tivessem autenticadas. O isAliveStation deve responder corretamente as requisioes ` c do isAliveDaemon para que seja feita a manutenao das respectivas conexes. A c o troca de mensagens realizada entre os clientes nas STAs e o servidor no AP est a descrita em detalhes na seao 5.2. c 5.3.1.1 Biblioteca TCPLIB

Um sub-produto deste projeto foi a criaao e implementaao de uma bibc c lioteca, escrita em C++, cujo objetivo facilitar o trabalho de programaao para e c rede e criaao de aplicaoes cliente-servidor. c c Esta biblioteca, chamada TCPLIB, foi escrita sob o paradigma da orientaaoc a-objeto. Tal paradigma foi adotado, pois com ele poss executar as tarefas de e vel criaao e inicializaao de um servidor, assim como a conexo entre cliente-servidor, c c a apenas com a instncia de um objeto e chamando-se dois mtodos do mesmo. O a e cdigo fonte da biblioteca est em anexo a este documento. o a

5.3.2

Ambiente de Desenvolvimento
O isAlive uma implementaao em C/C++ do mtodo de sondagem ativa e c e

descrito na seao 5.2, para vericar o desligamento de uma STA do AP. O livro [19] c e uma das melhores referncias quando se deseja escrever aplicaoes cliente-servidor. e c Esta linguagem de programaao foi escolhida devido a sua portabilidade. Esta c caracter stica foi uma grande preocupaao durante a implementaao, uma vez que o c c programa cliente da aplicaao isAlive, o isAliveStation, deveria ser capaz de executar c da mesma forma em SOs (sistemas operacionais) diferentes. Os SOs alvos desta implementaao do isAlive so Linux e Windows. Os SOs relacionados a seguir foram c a testados e so suportados pela atual implementaao do isAlive. No entanto, qualquer a c outra verso dos sistemas Linux e Unix devem suportar adequadamente a aplicaao a c cliente do isAlive, desde que instalados os devidos softwares, pr-requisitos para o e funcionamento da mesma. Estes softwares e suas funcionalidades esto descritas a a 33

seguir nesta seao. c isAliveDaemon OpenBSD 3.3 OpenBSD 3.4 isAliveStation Windows XP/2000/ME/98. Slackware Linux 8.0 e superior. Red Hat Linux 7.0 ou superior. Conectiva Linux 6.0 ou superior. Aurora Linux 6.0 ou superior. Para garantir esta caracter stica de portabilidade a aplicaao, foi utiliza a ` c biblioteca Cygwin [20]. Este software emula um ambiente Linux dentro do Windows e constituido de duas partes: e Uma DLL (cygwin1.dll) que atua como uma camada que emula um sistema Linux, dando ao ambiente de desenvolvimento funcionalidades substanciais de uma API Linux. Uma coleao de ferramentas que fornecem aparncia e funcionalidades Linux. c e Com este software possivel garantir a portabilidade do cdigo em C/C++. e o Tanto em ambiente Cygwin sob Windows, quanto no prprio Linux, alguns softo wares e bibliotecas so necessrios e foram utilizados nesta implementaao. Um a a c desses softwares o compilador gcc/g++ utilizado em ambos os ambientes. As prine cipais bibliotecas e APIs utilizadas na implementaao do isAlive foram a OpenSSL, c citada na seao 5.3.3, e MYSQL++ citada na seao 5.3.4. A instalaao de todas c c c as bibliotecas e programas necessrios ao funcionamento do isAlive sero vistos no a a cap tulo 6.

34

5.3.3

Criptograa no isAlive
A biblioteca OpenSSL [8] foi utilizada para suporte ao desenvolvimento do

sistema de criptograa das mensagens transmitidas entre clientes e servidor e para a troca de chaves entre STAs e AP. O projeto OpenSSL um esforo colaborativo para desenvolver um conjunto e c robusto de ferramentas, completo e de cdigo aberto para implementaao dos protoo c colos Secure Sockets Layer (SSL v2/v3) e Transport Layer Security (TLS v1), alm e de possuir uma biblioteca criptogrca de propsito geral. O projeto gerenciado a o e por uma comunidade de voluntrios de todo o mundo que utilizam a Internet para a se comunicar, planejar e desenvolver as ferramentas OpenSSL e sua documentaao. c Dentro deste conjunto de ferramentas de criptograa oferecidas pelo OpenSSL, est a biblioteca EVP. Esta biblioteca fornece uma interface de alto n a vel para veis funoes de criptograa. Foram utilizadas funoes do tipo EV P Encrypt..., dispon c c dentro da EVP, para criptograa simtrica. e O algoritmo de criptograa Blowsh foi utilizado nesta implementaao da c verso 1.0 do isAlive, em modo Cipher Block Chaining (CBC). Para isso foi utilizada a a funao EV P bf cbc(void). A escolha do algoritmo desejado pode ser facilmente c alterada em outras implementaoes. Para isso, basta apenas utilizar outra funao c c EVP de criptograa simtrica. e 5.3.3.1 Gerao de Chaves ca

Atualmente, segurana de sistemas baseia-se em algoritmos de criptograa c cada vez mais ecientes de forma a evitar ataques do tipo de identicaao de padres. c o No entanto, a segurana destes sistemas est intimamente relacionada a qualidade c a ` da geraao de quantidades secretas de informaao na constituiao de senhas e chaves c c c para criptograa. A utilizaao de processos pseudo-aleatrios na geraao destas quantidades c o c secretas pode signicar um risco para o sistema, uma vez que um atacante dispondo de tempo e recursos, pode reproduzir o ambiente onde as informaoes aleatrias c o secretas foram geradas. Isso proporcionaria uma reduao do n mero de possibilic u dades a serem testadas, tornando o trabalho do atacante mais eciente no sentido 35

de descobrir informaoes secretas. c Um verdadeiro gerador de n meros aleatrios requer uma fonte natural de u o aleatoriedade. Desenvolver dispositivos de hardware ou programas de software capazes de explorar fontes de aleatoriedade para gerar seqncias randmicas, no ue o a tendenciosas e livres de correlaao uma tarefa dif c e cil. Segundo [21], pgina 5,Rana dom numbers should not be generated with a method chosen at random. Alem disso, para aplicaoes de criptograa, o gerador em questo no pode ser facilmente subc a a metido a observaoes ou manipulaoes por parte de um adversrio. A RFC1750 [22] c c a traz uma srie de recomendaoes pertinentes a escolha de geradores de seqncias e c ue aleatrias. Em um trabalho sobre este tema [23], o autor realiza um estudo sobre a o natureza dos diferentes tipos de geradores conhecidos e realiza ainda, uma avaliaao c dos mesmos, baseados em mtodos descritos na literatura. e Assim, baseado nas referncias citadas at agora e no que foi exposto, foi e e escolhida uma funao de geraao de seqncias aleatrias da biblioteca OpenSSL. A c c ue o c funao utilizada a RAN D byte(). Algum tratamento com relaao ao sucesso na c e geraao da aleatoriedade foi feito, de forma que se a funao do OpenSSL no fosse c c a capaz de gerar seqncias satizfatrias, novas seqncias deveriam ser geradas at ue o ue e que este objetivo fosse alcanado. c

5.3.4

Acesso ao Banco de Dados

O servidor da aplicaao necessita conectar-se ao banco de dados de autenc

ticaao e vericar que estaoes esto autenticadas e utilizando a rede. O acesso c c a ao banco de dados MYSQL, pelo isAliveDaemon, feito atravs da biblioteca e e MYSQL++ [24], que uma API prpria para acesso a este BD. O uso de tal e o interface de programaao facilitou muito o trabalho de conectar, gravar e extrair c informaoes do danco de dados. c

5.4

Funcionamento do isAliveDaemon
Quando iniciado, o isAliveDaemon l o arquivo isAliveDaemon.conf para e

obter os seguintes parametros: 36

 DB_NAME Nome do banco de dados. DB_HOST Endereo IP da mquina onde o banco de dados esta instalado. c a DB_USER Login para o banco de dados. DB_PASSWD Senha do banco de dados. DB_TABLE_NAME Nome da tabela do banco de dados dos estar a lista de ips das STAs que a fazem parte do sistema. A seguir pode ser visto um exemplo de um arquivo de conguraao do c isAliveDaemon.
**** Conteudo do Arquivo isAliveDaemon.conf **** DB_NAME:strikein DB_HOST:10.10.0.84 DB_USER:root DB_PASSWD:super123 DB_TABLE_NAME:ipsValidos

Aps o procedimento de inicializaao, onde o programa l o arquivo de cono c e guraao, ele executa uma srie de procedimentos pr-estabelecidos de forma a verc e e icar o estado de conexo de STAs clientes utilizando o servio de rede sem o. O a c programa instalado no AP, permanece rodando em segundo plano e acessa o banco de dados MYSQL (que pode estar no prprio AP ou em outra mquina) em busca o a de uma lista dos endereos IP das mquinas autenticadas atravs do StrikeIN. Alm c a e e dos endereos, o programa procura pelas senhas dos usurios que se autenticaram c a em suas respectivas STAs. De posse dos endereos das STAs e das senhas dos usurios, o daemon da c a aplicaao isAlive segue tal lista e tenta se conectar aos clientes isAlive instalados c 37

nas STAs. Quando o daemon se conecta a um dos clientes ele executa a operaao c descrita na seao 5.2. Este procedimento feito para todas as estaoes na lista c e c adquirida do banco de dados. Em algum momento, a STA sendo sondada pode ser desligada ou sair do alcance do rdio do AP, fazendo com que o isAliveDaemon no consiga se conectar a a ao isAliveStation na STA. Isso ir fazer com que o isAliveDaemon, aps N tentativas a o de conexo, retire o IP da STA considerada desativada do banco de dados e das a permisses do rewall. A gura 5.3 ilustra o funcionamento do programa descrito o acima para n estaoes registradas no banco de dados. c Mensagens de erro e mensagens importantes como a sa de estaoes (quando da c uma estaao considerada fora da rede e ento eliminada da lista de ips validos), c e e a so registradas nos arquivos de log do sistema. Isso feito utilizando-se a funao a e c syslog() com seus devidos parametros. Em [19] possivel achar a documentaao da e c funcao syslog() e de outras funao e system calls utilizadas nesta implementaao. c c

5.5

Funcionamento do isAliveStation
O isAliveStation um programa que deve ser inicializado antes da realizaao e c

do login, na pgina de autenticaao. Quando iniciado, o programa requisita a senha a c do usurio. Uma vez que o mesmo entra com sua senha correta, o isAliveStation a torna-se um daemon e passa a ser executado em background. Foi escrita uma funao c chamada daemonize(), que realiza este procedimento de transformar o programa em daemon. Uma vez que isso acontece, o programa se associaa uma porta no sistema (atualmente a porta utilizada 56789 e s pode ser alterada modicando-se e o o cdigo fonte e recompilando-se o programa) e ca ouvindoessa porta, esperando o uma conexo do isAliveDaemon no AP. Uma vez que o isAliveDaemon se conecta a ao isAliveStation, a troca de mensagens descrita na gura 5.2 ocorre. Quando essa troca de mensagens termina, a conexo tambm nalizada e o programa volta a a e e esperar futuras conexes na mesma porta. o

38

ISALIVEDAEMON
1> n , i = 0

Gerao de chave para a i-sima estao

1< i <n

i ++ ;

Consulta ao BD. Lista de n IPs e suas chaves

n>0

Probe i-sima STA

Editar regras do firewall

falha no probe (falha de conexo)

Probe bem sucedido

Espera resposta da STA

Acesso ao BD para apagar registro do IP da i-sima STA

Resposta invlida

Resposta correta

Acesso ao BD para registro da chave

Figura 5.3: Esquema do funcionamento do isAliveDaemon.

39

Cap tulo 6 Instalao e Congurao do ca ca isAlive

Neste capitulo, todo o processo de instalaao e conguraao do isAlive ser c c a apresentado.

6.1

Instalando o Banco de Dados MySQL

Nesta seao ser descrita a instalaao dos softwares cliente e servidor do banco c a c

de dados MYSQL.

6.1.1

Cliente MYSQL

O AP deve ter instalado o cliente mySQL atravs dos seguintes passos: e # Fazer o download do mySQL para o diretrio /usr/src e descompactar. o $ cd /usr/src/mysql-version $ ./congure without-server $ gmake $ gmake install API C++ para mySQL Baixar e instalar a API para C++ para o mySQL (www.mysql.com/downloads/api-mysql++.html )

# Fazer o download do mySQL++ para o diretrio /usr/src e descomo pactar. $ automake $ autoconf $ ./cong $ gmake $ gmake install

6.1.2

Servidor MYSQL
A primeira etapa do processo corresponderia a baixar o arquivo mysql-VERSION.tar.gz

para o diretrio /usr/src e executar a srie de comandos descrita a seguir. o e

$ groupadd mysql $ useradd -g mysql mysql $ tar -xvzf mysql-VERSION.tar.gz $ cd mysql-VERSION $ ./congure prex=/usr/local/mysql $ gmake $ gmake install $ scripts/mysql install db $ chown -R root /usr/local/mysql $ chown -R mysql /usr/local/mysql/var $ chgrp -R mysql /usr/local/mysql $ cp support-les/my-medium.cnf /etc/my.cnf $ /usr/local/mysql/bin/safe mysqlduser=mysql

Deve-se congurar o MySQL de forma que ele seja invocado toda vez que o sistema for inicializado, para tanto devem-se acrescentar as seguintes linhas de comando no arquivo /etc/rc.local :
if [ -x /usr/local/mysql/share/mysql/mysql.server ]; then

41

echo -n mysqld; /usr/local/mysql/share/mysql/mysql.server start fi

O MySQL permite que se incluam permisses de acessos utilizando-se de trs o e restrioes: c Usurio a Mquina (host) a Banco de Dados Desta forma estabelece-se que um usurio a partir de uma mquina tem a a acesso a um determinado banco de dados. Para tanto, foi criado um usurio dea nominado strikein com permisso de acesso da mquina AirStrike (AP) ao banco a a de dados strikein. Este banco de dados ir conter as informaoes pertinentes ao a c processo de autorizaao e autenticaao dos usurios da rede sem o local. Para criar c c a este usurio, foram seguidos os seguintes passos: a
$ mysql h localhost u root p {Observe que a senha de root est em branco} a mysql > use mysql; mysql > insert into user values(wstrike,wstrike, PASSWORD(wstrike),Y,Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y,Y); mysql > insert into db values(wstrike,strikein, wstrike, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y); mysql > flush privileges;

Em anexo a este texto encontra-se o script utilizado para a criaao do BD c StrikeIN.

6.2

Instalao do isAliveDaemon ca
Os softwares necessrios para o funcionamento do daemon so os seguintes: a a

Banco de Dados MYSQL API C++ para MYSQL - MSQL++ 42

 OpenSSL Cdigo fonte do isAliveDaemon o Para instalar o isAlive no servidor, basta copiar o arquivo fonte do isAliveDaemon para uma pasta e executar o seguinte comando no Shell: $ ./isAliveDaemon.sh O arquivo isAliveDaemon.sh possui o seguinte conte do: u
----------------------- Incio do arquivo isAliveDaemon.sh --------------------------------- echo "Compilando..." g++ -I/usr/local/include/ -I/usr/local/include/mysql -O2 -c isAliveDaemon.cpp tcp_lib.cpp

echo "Linkando..." g++ -g -O2 -L/usr/local/lib/mysql -o isAliveDaemon isAliveDaemon.o -L/usr/local/lib/ -lsqlplus -lz -lmysqlclient -lz -lmysqlclient tcp_lib.cpp -lmcrypt -lltdl libcrypto.a

echo "Terminando..." rm *.o ------------------------ Fim do arquivo isAliveDaemon.sh --------------------------------------

Para congurar o AP para iniciar o daemon isAlive no boot a seguinte linha deve ser incluida no arquivo /etc/rc.local. Neste exemplo o executvel do isAliveDaea mon est localizado no diretrio /usr/local/bin/. a o echo -n isAliveDaemon; /usr/local/bin/isAliveDaemon /dev/null E necessario tambm fazer as mudanas necessrias no arquivo de conguraao e c a c do isaliveDaemon, isAliveDaemon.conf. Este arquivo deve estar no mesmo diretrio o do arquivo executavel do programa.

6.3

Instalao do isAliveStation ca
Para instalar o isAliveStation nos clientes que utilizo o sistema operacional a

Windows, os seguintes arquivos devem ser copiados para uma mesma pasta na mquina cliente (STA): a isAliveStation.exe cygcrypto-0.9.7.dll 43

 Cygwin1.dll Para instalar o isAliveStation em clientes Linux, basta copiar os arquivos fonte do isAliveStation para uma pasta e executar o seguinte comando no Shell: $ ./isAliveStation.sh O arquivo isAliveStation.sh possui o seguinte conte do: u
--------------------- Incio do arquivo isAliveStation.sh ---------------------------------- echo "Compilando e linkando..." g++ isAliveStation.cpp tcp_lib.cpp -o isAliveStation -lcrypto -Wno-deprecated

echo "Terminando..." rm *.o ---------------------- Fim do arquivo isAliveStation.sh -------------------------------------

44

Cap tulo 7 Concluses e Trabalhos Futuros o

Com este trabalho, foi dado um passo importante na direao de resolver um c problema de segurana bem espec c co em redes sem o, envolvendo desligamento de estaoes. Um protocolo de detecao de desligamento de estaao DPD (Dead c c c Peer Detection) foi idealizado um aplicativo cliente-servidor que implementa este protocolo foi escrito. O protocolo e a aplicaao recebem o nome de isAlive. Este c aplicativo capaz de identicar quando uma estaao sem o se desliga da rede e c por qualquer motivo e pode alterar conguraoes e regras de rewall do sistema. c Este software detecta e fecha portas abertas em rewalls baseado no estado das conexes das estaoes sem o que fazem partes da rede evitando ataques de replay o c e ipspoong. O ambiente de desenvolvimento de aplicativo para redes de computadores foi elaborado de forma a ser ampliado de modo simples e efetivo, caso novas funcionalidades sejam requeridas. Estas podem ser facilmente inclu das, devido ao alto grau de encapsulamento do cdigo, permitindo assim a constante evoluao deste trao c balho. Trata-se de um subproduto deste trabalho chamado aqui de TCPLIB, uma biblioteca, escrita em C++, cujo objetivo facilitar o trabalho de programaao para e c rede e criaao de aplicaoes cliente-servidor. Esta linguagem de programaao foi esc c c colhida devido a sua portabilidade. Esta caracter stica foi uma grande preocupaao c durante a implementaao, uma vez que o programa cliente da aplicaao, o isAliveSc c tation, deveria ser capaz de executar da mesma forma em sistemas operacionais diferentes.

Por m, vlido dizer que este trabalho no deve ser visto como algo isoe a a lado, acabado. Da mesma forma que a tecnologia est sempre em desenvolvimento, a cabe aos futuros desenvolvedores interessados em dar continuidade a este trabalho, implementar as novas tecnologias oferecidas, de forma a manter este sistema sempre atualizado e permitindo seu uso cont nuo por um longo tempo. Algumas propostas de trabalhos futuros podem ser citadas: O mtodo de sondagem ativa das estaoes pode ser feito em paralelo e no e c a em sistema de polling. Uma avaliaao comparativa deve ser feita das implec mentaoes com sondagem em srie e em paralelo. Apenas a sondagem em srie c e e foi implementada. O mecanismo de chave pr-compartilhada, utilizando-se a princ e pio a senha do usurio, foi uma alternativa simples e ecaz para realizar a criptograa e a a autenticaao do protocolo proposto. Alternativas a este mtodo podem ser c e implementadas, como por exemplo o uso de certicados digitais. Isso poderia minimizar os problemas relacionados a possiveis ataques, como ataques de dicionrio, por exemplo. a

46

Apndice A e Cdigo Fonte da Biblioteca TCP o para Programao para Rede ca

// tcp_lib.cpp (v1.0) // Bruno Astuto Arouche Nunes // 2002/2 // 28-11-2002 //---------------------------------------------------------------------#include <sys/types.h> #include <sys/time.h> #include <fcntl.h> #include <unistd.h> #include <errno.h> #include "tcp_lib.h"

#define DEBUG 0 #define BACKLOG 5 // max number of clients // max number of clients

#define BACKLOGSINGLE 1

char *tcpipErrorMsg[] = { "OK", "TCP/IP "TCP/IP "TCP/IP : ERROR IN gethostbyname FUNCTION ...\n", : ERROR IN socket FUNCTION ...\n", : ERROR IN connect FUNCTION ...\n",

"TCP/IP "TCP/IP "TCP/IP "TCP/IP "TCP/IP "TCP/IP "TCP/IP "TCP/IP "TCP/IP };

: ERROR IN close FUNCTION ...\n", : ERROR IN recv FUNCTION ...\n", : ERROR IN send FUNCTION ...\n", : ERROR IN bind FUNCTION ...\n", : ERROR IN listen FUNCTION ...\n", : ERROR IN setsockopt FUNCTION ...\n", : ERROR IN accept FUNCTION ...\n", : ERROR IN gethostname FUNCTION ...\n", : ERROR IN getpeername FUNCTION ...\n"

/****************************************************/ /* tcpIp class functions */ /****************************************************/

// constructor of the tcpIp class tcpIp::tcpIp() { #if DEBUG cout << "DEBUG: IN THE CONSTRUCTOR OF tcpIp::tcpIp()!" << endl; #endif DEBUG constructorError = OK; nameOfTheHost = 0; ipOfTheHost = 0; }

// destructor of the tcpIp class tcpIp::~tcpIp() { #if DEBUG cout << "DEBUG: IN THE DESTRUCTOR OF tcpIp::tcpIp()!" << endl; #endif DEBUG

if (nameOfTheHost) delete (nameOfTheHost); if (ipOfTheHost) delete (ipOfTheHost); }

void tcpIp::setNameOfTheHost(struct hostent *h)

48

{ // initialize the nameOfTheHost atribute nameOfTheHost = new char[strlen(h->h_name) + 1]; strcpy(nameOfTheHost, h->h_name); }

char *tcpIp::getNameOfTheHost(int print = 0) { // return the nameOfTheHost atribute if (print) { cout << nameOfTheHost << endl; } return(nameOfTheHost); }

void tcpIp::setIpOfTheHost(struct hostent *h) { // initialize the ipOfTheHost atribute ipOfTheHost = new char[strlen( inet_ntoa(*((struct in_addr *)h->h_addr)) ) + 1]; strcpy(ipOfTheHost, inet_ntoa(*((struct in_addr *)h->h_addr)) ); }

char *tcpIp::getIpOfTheHost(int print = 0) { // return the ipOfTheHost atribute if (print) { cout << ipOfTheHost << endl; } return(ipOfTheHost); }

ulong tcpIp::simpleSendData(char *buffer) { ulong retcode = OK; retcode = simpleSendData((byte*)buffer);

49

return(retcode); } ulong tcpIp::sendData(char *buffer , int buflen) { ulong retcode = OK; retcode = sendData((byte*)buffer, buflen); return(retcode); }

ulong tcpIp::simpleSendData(byte *buffer) { int bytes_sent = 0; // how many bytes weve sent at that moment ulong buffer_length = 0;

buffer_length = strlen((char*)buffer)+1;

#if DEBUG cout << "DEBUG: IN simpleSendData FUNCTION 0 \n" << endl; #endif

// txmsg = 0; /* if(txmsg) //safe delete { delete(txmsg); txmsg = 0; }

txmsg = new byte[buffer_length]; */ #if DEBUG cout << "DEBUG: IN simpleSendData FUNCTION 1 \n" << endl; #endif

#ifdef WIN32 /*ulong i = 0; while( i < strlen(buffer) ) {

50

txmsg[i] = \0; i++; }*/ memset(txmsg, \0, 2048); #else bzero(txmsg, 2048); #endif

//bcopy(txmsg, buffer, buffer_length); memcpy(txmsg, buffer, buffer_length); //memccpy(txmsg, buffer, \0, buffer_length); //strcpy(txmsg, buffer);

#if DEBUG cout << "DEBUG: txmsg = " << txmsg << endl; #endif

#if DEBUG cout << "DEBUG: IN simpleSendData FUNCTION 2 \n" << endl; //cout << "DEBUG: total_length = "<< total_length << " \n" << endl; #endif

#ifdef WIN32 bytes_sent = send(socketDescriptor, (char*)txmsg, strlen((char*)txmsg), 0); if (bytes_sent < 0) { return(ERROR_SEND); } #else bytes_sent = send(socketDescriptor, txmsg, strlen((char*)txmsg), 0); if (bytes_sent < 0) { return(ERROR_SEND); } #endif

#if DEBUG cout << "txmsg ->" << txmsg << "<-" << endl; #endif

return(OK); }

ulong tcpIp::sendData(byte *buffer, int buflen)

51

{ ulong total = 0; // how many bytes weve sent ulong bytes_left = 0; // how many we have left to send ulong total_length = 0; int bytes_sent = 0; // how many bytes weve sent at that moment ulong buffer_length = 0;

buffer_length = buflen;

#if DEBUG cout << "DEBUG: IN sendData FUNCTION 0 \n" << endl; #endif

#if DEBUG cout << "DEBUG: IN sendData FUNCTION 1 \n" << endl; #endif

#ifdef WIN32 memset(txmsg, \0, DATA_SIZE); #else bzero(txmsg, DATA_SIZE); #endif

memcpy(txmsg, buffer, buffer_length);

#if DEBUG cout << "DEBUG: txmsg = " << txmsg << endl; #endif

bytes_left = buflen; total_length = buflen;//strlen((char*)txmsg);

#if DEBUG cout << "DEBUG: IN sendData FUNCTION 2 \n" << endl; cout << "DEBUG: total_length = "<< total_length << " \n" << endl; #endif

while(total < total_length)

52

{ bytes_sent = send(socketDescriptor, (char*)(txmsg+total), bytes_left, 0); if (bytes_sent < 0) { return(ERROR_SEND); } total += bytes_sent; bytes_left -= bytes_sent; }

#if DEBUG cout << "txmsg ->" << txmsg << "<-" << endl; #endif

return(OK); }

ulong tcpIp::receiveData(ulong maxlength, int *bytes_recved) { #if DEBUG cout << "DEBUG: IN reciveTcpData FUNCTION \n" << endl ; #endif DEBUG

bytes_recved = 0;

#ifdef WIN32 memset(rxmsg, \0, DATA_SIZE); #else bzero(rxmsg, DATA_SIZE); #endif

#if DEBUG cout << "DEBUG: IN recv FUNCTION \n" << endl; cout << &rxmsg << endl; #endif

#ifdef WIN32 if( ( *bytes_recved = recv(socketDescriptor, (char*)rxmsg, DATA_SIZE, 0) ) < 0 ) return(ERROR_REVC); #else if( ( *bytes_recved = recv(socketDescriptor, rxmsg, DATA_SIZE, 0) ) < 0 )

53

return(ERROR_REVC); #endif #if DEBUG cout << "DEBUG: IN recv FUNCTION 2 \n" << endl; cout << "DEBUG: bytes_recved = "<< bytes_recved << " \n" << endl; #endif

#if DEBUG cout << "rxmsg ->" << rxmsg << "<-" << endl; #endif DEBUG

return(OK); }

byte *tcpIp::getRXmsg(int print = 0) { // return the rxmsg atribute if (print) { cout << rxmsg << endl; } return(rxmsg); }

byte *tcpIp::getTXmsg(int print = 0) { // return the txmsg atribute if (print) { cout << txmsg << endl; } return(txmsg); }

ulong tcpIp::getConstructorError() { return(constructorError); }

54

#ifdef WIN32 void tcpIp::callWSAStartup() { // WSAStartup call -- Needed for windows sockets WORD wVersionRequested; WSADATA wsaData; int err;

wVersionRequested = MAKEWORD( 2, 2 );

err = WSAStartup( wVersionRequested, &wsaData ); if ( err != 0 ) { /* Tell the user that we could not find a usable */ /* WinSock DLL. return; } */

/* Confirm that the WinSock DLL supports 2.2.

*/ */

/* Note that if the DLL supports versions greater

/* than 2.2 in addition to 2.2, it will still return */ /* 2.2 in wVersion since that is the version we /* requested. */ */

if ( LOBYTE( wsaData.wVersion ) != 2 || HIBYTE( wsaData.wVersion ) != 2 ) { /* Tell the user that we could not find a usable */ /* WinSock DLL. WSACleanup( ); return; } /* The WinSock DLL is acceptable. Proceed. */ } #endif */

// END OF tcp_client class functions =================================

55

/**********************************************************************/ /* tcpClient class functions */

/**********************************************************************/

// constructor tcpClient::tcpClient(char *serverAddr, char *p, int v = 0) { int myport = atoi(p); int retcode = OK;

if( (retcode = setTcpClient(serverAddr, myport, v)) ) { constructorError = retcode; } }

// constructor tcpClient::tcpClient(char *serverAddr, ushort p, int v = 0) { int retcode = OK;

if( (retcode = setTcpClient(serverAddr, p, v)) ) { constructorError = retcode; } }

// Called by the constructor to initialize parameters for the client. ulong tcpClient::setTcpClient(char *serverAddr, ushort p, int v) {

#ifdef WIN32 callWSAStartup(); #endif

#if DEBUG cout << "DEBUG: IN tcpClient CONSTRUCTOR \n" << endl;

56

#endif

struct hostent *h; //Hold the server information. constructorError = OK; serverAddress = 0;

// initialize the serverAddress atribute serverAddress = new char[strlen(serverAddr) + 1]; strcpy(serverAddress, serverAddr); // initialize the port atribute port = p; // initialize the verbose atribute verbose = v;

#if DEBUG cout << "DEBUG: serverAddress = "<< serverAddress << " \n" << endl; #endif

if( ( h = gethostbyname(serverAddress) ) == NULL ) // get the host info { if (verbose) { cout << "DEBUG: constructorError = " << constructorError << endl; } return(ERROR_GETHOSTBYNAME); } else { // initialize the nameOfTheHost atribute setNameOfTheHost(h); // initialize the ipOfTheHost atribute setIpOfTheHost(h);

// Setting structure parameters ************************ dest_addr.sin_family = SOCK_FAMILY; dest_addr.sin_port dest_addr.sin_addr = htons(port); = *((struct in_addr *)h->h_addr);

memset(&(dest_addr.sin_zero), \0, 8); // zero to the rest of the structure

57

// Setting structure parameters *******END************** }

#if DEBUG cout << "DEBUG: LEAVING tcpClient CONSTRUCTOR! \n" << endl; #endif

return(OK); }

ulong tcpClient::initializeClientConnection() { fd_set fds; int n, timeout = 5; struct timeval tv;

#if DEBUG cout << "DEBUG: IN initializeClientConnection FUNCTION \n" << endl; #endif

// Opening socket ************************ if ( ( socketDescriptor = socket(SOCK_FAMILY, SOCK_TYPE, SOCK_PROTOCOL) ) < 0 ) return(ERROR_OPEN_SOCKET); if (fcntl (socketDescriptor, F_SETFL, O_NONBLOCK) < 0) { printf("erro no fcntl\n"); exit(1); } if (verbose) { cout << "TCP/IP client } : Socket Opened ... " << endl;

// set up the struct timevalfor the timeout tv.tv_sec = timeout; tv.tv_usec = 0;

// Connecting to server ******************** if (verbose)

58

{ cout << "Trying to connect...." << endl; }

while(1) {

if ( (connect(socketDescriptor, (struct sockaddr *) &dest_addr, sizeof(sockaddr_in)) < 0) && (err if ((errno != EINTR) && (errno != EINPROGRESS)) {

if ((errno == ECONNREFUSED)||(errno == EINVAL)) { if (verbose) fprintf(stderr, "Connection Refused!\n"); return (ERROR_OPEN_SOCKET); }

if (errno == EALREADY) { if (verbose) fprintf(stderr, "Connection timed out!\n"); return (ERROR_OPEN_SOCKET); } perror("connect"); return(ERROR_OPEN_SOCKET); } } else { if (verbose) { cout << "TCP/IP client cout << "Host Name (IP) } if (fcntl (socketDescriptor, F_SETFL, O_SYNC) < 0) { if (verbose) printf("erro no fcntl\n"); exit(1); } : Connected ...\n"; : " << nameOfTheHost << " (" << ipOfTheHost <<

if (verbose) printf ("Connected succesfully!\n");

return (OK); }

FD_ZERO(&fds);

59

FD_SET(socketDescriptor,&fds);

while (select (getdtablesize (), NULL, &fds, NULL, &tv) < 0) { if (errno != EINTR) { perror ("select"); return(1); } } } return(OK); }

ulong tcpClient::endClient() { int i = 0;

#if DEBUG cout << "DEBUG: IN endClient FUNCTION \n" << endl; #endif

#ifdef WIN32 // close socket for Win32 WSACleanup(); return(OK); #else // close socket for unix if( (i = close(socketDescriptor)) ) { return(ERROR_CLOSE); } #endif

return(OK); }

// destructor tcpClient::~tcpClient() {

60

#if DEBUG cout << "DEBUG: IN DESTRUCTOR ~tcpClient() \n" << endl; #endif

if(serverAddress) delete(serverAddress);

// END tcp client if ( (retCode = endClient()) ) { cout << tcpipErrorMsg [retCode] << endl; } } // END OF tcp_client class functions =================================

/****************************************************/ /* tcpServer class functions */ /****************************************************/

// constructor tcpServer::tcpServer(char *p, int v = 0) { int myport = atoi(p); int retcode = OK;

if( (retcode = setTcpServer(myport, v)) ) { constructorError = retcode; } }

// constructor tcpServer::tcpServer(ushort p, int v) { int retcode = OK;

if( (retcode = setTcpServer(p, v)) ) {

61

constructorError = retcode; } }

ulong tcpServer::setTcpServer(ushort p, int v) { #ifdef WIN32 callWSAStartup(); #endif

#if DEBUG cout << "DEBUG: IN tcpServer CONSTRUCTOR \n" << endl; #endif

struct hostent *h; //Hold the server information. constructorError = OK; ipOfThePeer = 0; //Hold connectors IP address nameOfThePeer = 0; //Hold connectors name portOfThePeer = 0; //Hold connectors connection port

// initialize the serverAddress atribute char serverAddress[DATA_SIZE]; if( ( gethostname(serverAddress, sizeof(serverAddress)) ) < 0 ) // get the host name { if (verbose) { constructorError = ERROR_GETHOSTNAME; cout << "1: tcpServer Constructor Error = " << constructorError << endl; } return(ERROR_GETHOSTNAME); }

// initialize the port atribute port = p;

// initialize the verbose atribute verbose = v;

62

if( ( h = gethostbyname(serverAddress) ) == NULL ) // get the host info { if (verbose) { constructorError = ERROR_GETHOSTBYNAME; cout << "2: tcpServer Constructor Error = " << constructorError << endl; } return(ERROR_GETHOSTBYNAME); } else { // initialize the nameOfTheHost atribute setNameOfTheHost(h); // initialize the ipOfTheHost atribute setIpOfTheHost(h);

// Setting structure parameters ************************ server_addr.sin_family = SOCK_FAMILY; server_addr.sin_port server_addr.sin_addr = htons(port); = *((struct in_addr *)h->h_addr);

memset(&(server_addr.sin_zero), \0, 8); // zero to the rest of the structure // Setting structure parameters *******END************** }

#if DEBUG cout << "DEBUG: LEAVING tcpServer CONSTRUCTOR! \n" << endl; #endif

return(OK); }

ulong tcpServer::initializeSingleServer() { #ifdef WIN32 int sin_size; #else socklen_t sin_size; #endif

63

retCode = initializeServer();

sin_size = sizeof(struct sockaddr_in); if ( ( socketDescriptor = accept(sock_fd, (struct sockaddr *) &client_addr, &sin_size) ) < 0 ) { #ifdef WIN32 // close socket for Win32 WSACleanup(); return(ERROR_ACCEPT); #else // close socket for unix close(sock_fd); return(ERROR_ACCEPT); #endif }

if (verbose) { cout << "TCP/IP server } : Connection accepted from " << inet_ntoa(client_addr.sin_addr) << endl;

#ifdef WIN32 #else if ( close(sock_fd) ) { return(ERROR_CLOSE); } #endif

return(retCode); }

ulong tcpServer::initializeServer() { #ifdef WIN32 char yes = 1; #else

64

int

yes = 1;

#endif

// Opening socket ************************ if ((sock_fd = socket(SOCK_FAMILY, SOCK_TYPE, SOCK_PROTOCOL)) < 0) return(ERROR_OPEN_SOCKET);

if (verbose) { cout << "TCP/IP server } : Socket Opened ..." << endl;

// Forcing the port to be released ******** // Lose the pesky "Address alredy in use" error message ********* setsockopt(sock_fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int));

// Binding to port ******************** if ( ( bind( sock_fd, (struct sockaddr *) &server_addr, sizeof(server_addr) ) ) < 0 ) { #ifdef WIN32 // close socket for Win32 WSACleanup(); return(ERROR_BIND); #else // close socket for unix close(sock_fd); return(ERROR_BIND); #endif }

if (verbose) { cout << "TCP/IP server } : Bind to port " << port << " ..." << endl;

// Listenig to port **************************************************** // this server accept one single connection. (BACKLOGSINGLE = 1) if ((listen(sock_fd, BACKLOGSINGLE)) < 0)

65

{ #ifdef WIN32 // close socket for Win32 WSACleanup(); return(ERROR_LISTEN); #else // close socket for unix close(sock_fd); return(ERROR_LISTEN); #endif }

if (verbose) { cout << "TCP/IP server cout << "Server Name (IP) } : Listening port " << port << " ..." << endl; : " << nameOfTheHost << " (" << ipOfTheHost << ")" << endl;

return(OK); }

ulong tcpServer::setPeerInfo() { #if DEBUG cout << "DEBUG: IN setPeerInfo() METHOD!!!" << endl; #endif

int retcode = OK; struct sockaddr_in peer_addr; //Hold connectors addr

#ifdef WIN32 int peer_addr_len; #else socklen_t peer_addr_len; #endif

if( ( getpeername(socketDescriptor, (struct sockaddr *) &peer_addr, &peer_addr_len) ) < 0 ) {

66

return(ERROR_GETPEERNAME); }

if ( (retcode = setPeerInfo(peer_addr)) ) { return(retcode); }

return(OK); }

ulong tcpServer::setPeerInfo(struct sockaddr_in peer_addr) { struct hostent *h;

if( ( h = gethostbyname( inet_ntoa(peer_addr.sin_addr) ) ) == NULL ) // get the conectors info { return(ERROR_GETHOSTBYNAME); }

#if DEBUG cout << "ipOfThePeer::::::" << endl; #endif // initialize the ipOfThePeer atribute ipOfThePeer = new char[strlen( inet_ntoa(*((struct in_addr *)h->h_addr)) ) + 1]; strcpy(ipOfThePeer, inet_ntoa(*((struct in_addr *)h->h_addr)) );

#if DEBUG cout << "nameOfThePeer::::::" << endl; #endif // initialize the nameOfThePeer atribute nameOfThePeer = new char[strlen(h->h_name) + 1]; strcpy(nameOfThePeer, h->h_name);

#if DEBUG cout << "portOfThePeer::::::" << endl; #endif // initialize the portOfThePeer atribute

67

portOfThePeer = ntohs(peer_addr.sin_port);

return(OK); }

char *tcpServer::getPeerAddr(int print = 0) { // return the ipOfThePeer atribute if (print) { cout << ipOfThePeer << endl; } return(ipOfThePeer); }

char *tcpServer::getPeerName(int print = 0) { // return the nameOfThePeer atribute if (print) { cout << nameOfThePeer << endl; } return(nameOfThePeer); }

int tcpServer::getPeerPort(int print = 0) { // return the portOfThePeer atribute if (print) { cout << portOfThePeer << endl; } return(portOfThePeer); }

ulong tcpServer::disconectClient() { int i = 0;

68

#if DEBUG cout << "DEBUG: IN endServer FUNCTION \n" << endl; #endif

#ifdef WIN32 // close socket for Win32 WSACleanup(); return(OK); #else // close socket for unix if( (i = close(socketDescriptor)) ) { return(ERROR_CLOSE); } #endif

return(OK); }

// destructor tcpServer::~tcpServer() { #if DEBUG cout << "DEBUG: IN DESTRUCTOR ~tcpServer() \n" << endl; #endif

if (nameOfThePeer) delete(nameOfThePeer); if (ipOfThePeer) delete(ipOfThePeer);

#ifdef WIN32 // close socket for Win32 WSACleanup(); #endif } // END OF tcp_server class functions =================================

69

// tcp_lib.h (v7.3) // Bruno Astuto Arouche Nunes // 2002/2 // 24-10-2002 //----------------------------------------------------------------------

#ifndef _TCPLIB_H_ #define _TCPLIB_H_

#include <iostream.h> #include <string.h> #include <stdlib.h> #include <stdio.h> #ifdef WIN32 // includes for windows #include <winsock2.h> #else // includes for unix #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <unistd.h> #include <netdb.h> #endif

#define OK 0 #define ERROR_GETHOSTBYNAME 1 #define ERROR_OPEN_SOCKET 2 #define ERROR_CONNECT 3 #define ERROR_CLOSE 4 #define ERROR_REVC 5 #define ERROR_SEND 6 #define ERROR_BIND 7 #define ERROR_LISTEN 8 #define ERROR_SETSOCKOPT 9 #define ERROR_ACCEPT 10 // not used

70

#define ERROR_GETHOSTNAME 11 #define ERROR_GETPEERNAME 12

#define SIZE_DATA 1024 #define DATA_SIZE 10240

#define SOCK_FAMILY AF_INET // socket family #define SOCK_TYPE SOCK_STREAM // socket type #define SOCK_PROTOCOL IPPROTO_TCP // used protocol

#ifdef WIN32 #define False false #define True true #else #define FALSE false #define False false #define TRUE true #define True true #endif

#ifndef byte #define byte unsigned char #endif #ifndef ulong #define ulong unsigned long #endif #ifndef ushort #define ushort unsigned short #endif

extern char *tcpipErrorMsg[];

/* -------------- PROTOTYPES --------------- */

////////////////////////////////////// // tcpIp //

//////////////////////////////////////

71

class tcpIp { protected: // atributes char *nameOfTheHost; char *ipOfTheHost; byte rxmsg[DATA_SIZE]; byte txmsg[DATA_SIZE]; int retCode; int verbose; // flag to dispay messages on screen. int constructorError; ushort port;

#ifdef WIN32 protected: void callWSAStartup(); // method necessary to the use of WinSocks #endif

public: // methods tcpIp(); // constructor ~tcpIp(); // destructor void setNameOfTheHost(struct hostent *h); void setIpOfTheHost(struct hostent *h); char *getNameOfTheHost(int print); char *getIpOfTheHost(int print); byte *getRXmsg(int print); byte *getTXmsg(int print); ulong simpleSendData(byte *buffer); ulong sendData(byte *buffer, int buflen); ulong simpleSendData(char *buffer); ulong sendData(char *buffer, int buflen); ulong receiveData(ulong maxlength, int *bytes_recved); ulong getConstructorError();

int socketDescriptor; };// end of tcpIp class

//////////////////////////////////////////

72

// tcpClient // ////////////////////////////////////////// class tcpClient : public tcpIp { private: // atributes char *serverAddress; struct sockaddr_in dest_addr; //Hold the destination addr.

private: // methods ulong setTcpClient(char *serverAddr, ushort p, int v = 0);

public: // methods tcpClient(char *serverAddr, ushort p, int v); // constructor tcpClient(char *serverAddr, char *p, int v); // constructor ~tcpClient(); // destructor ulong initializeClientConnection(); ulong endClient();

};// end of tcp_client class

////////////////////////////////////// // tcpServer //

////////////////////////////////////// class tcpServer : public tcpIp { private: // atributes char *ipOfThePeer; //Hold connectors IP address char *nameOfThePeer; //Hold connectors name int portOfThePeer; //Hold connectors connection port

private: // methods ulong setTcpServer(ushort p, int v = 0);

public: // methods tcpServer(ushort p, int v); // constructor tcpServer(char *p, int v); // constructor ~tcpServer(); // destructor

73

ulong initializeSingleServer(); ulong initializeServer(); ulong disconectClient(); ulong setPeerInfo(); ulong setPeerInfo(struct sockaddr_in peer_addr); char *getPeerAddr(int print); char *getPeerName(int print); int getPeerPort(int print);

struct sockaddr_in server_addr; //Hold servers addr (my addr) struct sockaddr_in client_addr; //Hold connectors information int sock_fd;

};// end of tcp_server class

/* ----------- END OF PROTOTYPES ------------ */

#endif

74

Apndice B e Cdigo Fonte do isAliveStation o

// isAliveStation.h (v1.0) *** For LINUX/UNIX and Windows98/2k/XP(with CYGWIN) *** // Author: Bruno Astuto Arouche Nunes // Date: 22-12-2003 // 2003/2 // // g++ isAliveStation.cpp tcp_lib.cpp -o isAliveStation -lcrypto -Wno-deprecated //---------------------------------------------------------------------------------------

#include <stdlib.h> #include <fstream.h> #include <openssl/evp.h> #include <sys/wait.h> #include <sys/stat.h> #include <sys/types.h> #include <syslog.h> #include <signal.h> #include <pwd.h> #include <unistd.h> #include <stdio.h> #include "tcp_lib.h"

#define DEBUG_STA 0 #define VERBOSE 1 #define KEY_SIZE 17 #define PORTNUMBER 56789 #define ACK_MSG "200 ACK"

#define MAX_FD 64

// ****** PROTOTYPES ****** // ulong answerProbe(unsigned char *firstKey, int new_fd); ulong initializeSingleTcpServer(ushort port, int *socketDescriptor, int verbose); void daemonize(const char *pname, int facility); void writeLog(char *log_msg);

static unsigned char key[KEY_SIZE];

// isAliveStation.cpp (v1.0) *** For LINUX/UNIX and Windows98/2k/XP (with CYGWIN) *** // Author: Bruno Astuto Arouche Nunes // Date: 22-12-2003 // 2003/2 // // g++ isAliveStation.cpp tcp_lib.cpp -o isAliveStation -lcrypto -Wno-deprecated //---------------------------------------------------------------------------------------

#include "isAliveStation.h"

#define LOG_FILE "isAliveStation.log"

int main(int argc, char **argv) { ulong retCode = OK; int socketDescriptor = 0; socklen_t sin_size; // int sin_size = 0; //mudei aqui

int new_fd = 0, validPasswd; struct sigaction sa; struct sockaddr_in client_addr; //Hold the destination addr char *p; char buf[DATA_SIZE]; memset(buf, \0, DATA_SIZE); char configParamName[DATA_SIZE] = "\0"; memset(configParamName, \0, DATA_SIZE); char configLine[DATA_SIZE] = "\0"; memset(configLine, \0, DATA_SIZE); char type[KEY_SIZE] = "\0"; memset(type, \0, KEY_SIZE);

76

char retype[KEY_SIZE] = "\0"; memset(retype, \0, KEY_SIZE);

memset(key, \0, KEY_SIZE);

//****************************************************************************************

// Set the variable DEBUG_STA in isAliveStation.h to 0 to disable DEBUG MODE, // or to 1 to se the debug messages. #if DEBUG_STA cout << "*** DEBUG MODE ********************************* isAliveStation Started..." << endl; #endif

#if !DEBUG_STA cout << "************************************************ isAliveStation Started..." << endl; #endif

validPasswd=0; while ( ! validPasswd ) { strncpy( type, getpass("TYPE PASSWORD :"), sizeof(type)-1 );

strncpy( retype, getpass("RETYPE PASSWORD:"), sizeof(retype)-1);

if ( strncmp(type, retype, sizeof(type) ) == 0) { validPasswd=1; } else { cout << "Invalid Password! Try again!" << endl; writeLog("Invalid Password! Try again!"); } }

strncat(retype, "0000000000000000", KEY_SIZE-strlen(retype)-1); retype[sizeof(retype)-1]=\0;

strncpy((char*)key, retype, sizeof(key) );

77

#if DEBUG_STA cout << "YOUR complete PASSWORD IS: (" << key << ")" << endl; #endif writeLog("isAliveStation Started..."); //****************************************************************************************

//Make the process a daemon.// daemonize(argv[0], 0); //syslog(LOG_NOTICE|LOG_USER, "ISALIVE!!!!!!!!!!! bruno");

if( (retCode = initializeSingleTcpServer(PORTNUMBER, &socketDescriptor, 1)) < 0) { writeLog(tcpipErrorMsg[retCode]); return(retCode); } #if DEBUG_STA int count = 0; //just a DEBUG_STA VAR #endif

while(1) { #if DEBUG_STA cout << ":::::::::::::::::::::::::::::::::::::: (" << count++ << ")" << endl; #endif fflush(stdout); sin_size = sizeof(client_addr); if ((new_fd = accept(socketDescriptor, (struct sockaddr *) &client_addr, &sin_size)) < 0) { printf("Erro no new_fd\n"); continue; } #if DEBUG_STA printf("TCP/IP server #endif : Connection accepted from %s\n", inet_ntoa(client_addr.sin_addr));

/* memset(buf, \0, DATA_SIZE); strncat(buf, "TCP/IP server : Connection accepted from ", strlen("TCP/IP server

: Connectio

78

strncat(buf, inet_ntoa(client_addr.sin_addr), strlen(inet_ntoa(client_addr.sin_addr))); writeLog(buf); */

retCode = answerProbe(key, new_fd); if(retCode) { memset(buf, \0, DATA_SIZE); strncat(buf, "Prober closed with error:", strlen("Prober closed with error:")); strncat(buf, (const char*)retCode, 1); writeLog(buf);

close(new_fd); exit(-1); } #if DEBUG_STA cout << ":::::::::::::::::::::::::::::::: close(new_fd)" << endl; #endif close(new_fd);

}// END OF WHILE(1)...

writeLog("*** THE IS_ALIVE_STATION IS NOW DEAD!!! ***"); writeLog("*** HAVE A NICE DAY!!! ***");

#if DEBUG_STA cout << "\n\n *** THE IS_ALIVE_STATION IS NOW DEAD!!! *** \n" << endl; cout << "\n\n *** HAVE A NICE DAY!!! *** \n" << endl; #endif

return (retCode);

}// END OF main() //====================================================================================

//==================================================================================== // This function writes log_msg in the log file.

79

void writeLog(char *log_msg) { FILE *out; struct tm *ptr; time_t lt; char buf[DATA_SIZE]; memset(buf, \0, DATA_SIZE);

lt = time(NULL); ptr = localtime(&lt); strncat(buf, asctime(ptr), 24); strncat(buf, ": ", 2); strncat(buf, log_msg, strlen(log_msg));

out = fopen(LOG_FILE, "a"); fwrite(buf, 1, 26+strlen(log_msg), out); fwrite("\n", 1, 1, out); fclose(out);

}// END OF writeLog() //====================================================================================

//==================================================================================== // Initializes the current program as a daemon, by changing working // directory, umask, and eliminating control terminal, // setting signal handlers. void { pid_t pid; int k; daemonize(const char *pname, int facility)

/* put server in background (with init as parent) */ if ( ( pid = fork() ) < 0 ) { perror(">>> cannot fork2"); exit(1); } else if (pid > 0) /* The parent */ exit(0);

80

/* Detach controlling terminal by becoming sesion leader */ setsid();

signal(SIGHUP, SIG_IGN); /* put server in background (with init as parent) */ if ( ( pid = fork() ) < 0 ) { perror(">>> cannot fork2"); exit(1); } else if (pid > 0) /* The parent */ exit(0);

fclose(stdin); fclose(stderr); fclose(stdout);

/* Close all file descriptors that are open */ for (k = MAX_FD; k>0; k--) close(k);

/* Change directory to specified directory */ // chdir("/");

/* Set umask to mask (usually 0) */ umask(0);

openlog(pname, LOG_PID, facility);

}// END OF daemonize() //====================================================================================

//==================================================================================== // This function probes the station ulong answerProbe(unsigned char *firstKey, int new_fd) { /* CRYPT ---------------------------------------------------*/

int outlen = 0;

81

int tmplen = 0; unsigned char iv[] = {1,2,3,4,5,6,7,8}; EVP_CIPHER_CTX ctx; /* CRYPT ---------------------------------------------------*/

ulong retCode = OK; int bytes_recved = 0; int bytes_sent = 0; // how many bytes weve sent at that moment

byte *txmsg = 0; txmsg = new byte[DATA_SIZE]; memset(txmsg, \0, DATA_SIZE);

byte *rxmsgDecrypted = 0; rxmsgDecrypted = new byte[DATA_SIZE]; memset(rxmsgDecrypted, \0, DATA_SIZE);

byte *txmsgCrypted = 0; txmsgCrypted = new byte[DATA_SIZE]; memset(txmsgCrypted, \0, DATA_SIZE);

byte *rxmsgCrypted = 0; rxmsgCrypted = new byte[DATA_SIZE]; memset(rxmsgCrypted, \0, DATA_SIZE);

#if DEBUG_STA cout << "FirstKey ->:" << firstKey << ":<-" << endl; cout << "NEW_FD ->:" << new_fd << ":<-" << endl;

cout << "==============================================================" << endl; #endif

// Recive first msg from the isAliveDaemon if( ( bytes_recved = recv(new_fd, rxmsgCrypted, DATA_SIZE, 0) ) < 0 ) return(ERROR_REVC);

// Decrypt message recived from isAliveDaemon ------------------------------------------------#if DEBUG_STA cout << "==>bytes_recved:" << bytes_recved << endl; #endif

82

EVP_CIPHER_CTX_init(&ctx); EVP_DecryptInit_ex(&ctx, (EVP_CIPHER*)EVP_bf_cbc(), NULL, firstKey, iv); if( !EVP_DecryptUpdate(&ctx, rxmsgDecrypted, &outlen, rxmsgCrypted, 24) ) { /* Error */ cout << "Error in EVP_DecryptUpdate()!" << endl; return 1; } /* Buffer passed to EVP_EncryptFinal() must be after data just * encrypted to avoid overwriting it.*/ EVP_CIPHER_CTX_set_padding(&ctx, 0); if(!EVP_DecryptFinal_ex(&ctx, rxmsgDecrypted + outlen, &tmplen)) { /* Error */ cout << "Error in EVP_DecryptFinal_ex()!" << endl; return 1; } outlen += tmplen; EVP_CIPHER_CTX_cleanup(&ctx); /* Need binary mode for fopen because encrypted data is * binary data. Also cannot use strlen() on it because * it wont be null terminated and may contain embedded * nulls. */ // END OF Decrypt message recived from isAliveDaemon -------------------------#if DEBUG_STA fflush(stdout); cout << "strlen(rxmsgDecrypted): " << strlen((char*)rxmsgDecrypted) << endl; fflush(stdout); cout << "outlen fflush(stdout); cout << "\nrxmsgCrypted fflush(stdout); cout << "rxmsgDecrypted fflush(stdout); cout << "Decrypted message fflush(stdout); :" << rxmsgDecrypted << endl; :" << rxmsgDecrypted << ":" << endl; :" << rxmsgCrypted << ":" << endl; : " << outlen << endl;

83

cout << "OLD KEY fflush(stdout); #endif

:" << key << endl;

memmove(key, rxmsgDecrypted, KEY_SIZE);

#if DEBUG_STA cout << "rxmsgDecrypted fflush(stdout); cout << "NEW KEY #endif :" << key << endl; :" << rxmsgDecrypted << endl;

memset(txmsg, \0, DATA_SIZE); memset(txmsgCrypted, \0, DATA_SIZE); strcpy((char*)txmsg, ACK_MSG); strcat((char*)txmsg, "\0"); //0x00; //EOS

// Encrypt message to be sent to isAliveDaemon -------------------------------------------------EVP_CIPHER_CTX_init(&ctx); EVP_CIPHER_CTX_set_padding(&ctx, 1); EVP_EncryptInit_ex(&ctx, (EVP_CIPHER*)EVP_bf_cbc(), NULL, key, iv); if(!EVP_EncryptUpdate(&ctx, txmsgCrypted, &outlen, (unsigned char*)txmsg, strlen((char*)txmsg))) { /* Error */ return 1; } /* Buffer passed to EVP_EncryptFinal() must be after data just * encrypted to avoid overwriting it. */ if(!EVP_EncryptFinal_ex(&ctx, txmsgCrypted + outlen, &tmplen)) { /* Error */ return 1; } outlen += tmplen; EVP_CIPHER_CTX_cleanup(&ctx); /* Need binary mode for fopen because encrypted data is * binary data. Also cannot use strlen() on it because

84

* it wont be null terminated and may contain embedded * nulls. */ // END OF Encrypt message to be sent to isAliveDaemon ------------------#if DEBUG_STA cout << "==>txmsg=ACK_MSG:" << txmsg << ":" << endl; cout << "==>txmsgCrypted:" << txmsgCrypted << ":" << endl; #endif

// sending encrypted ACK message to the client bytes_sent = send(new_fd, txmsgCrypted, outlen, 0); if (bytes_sent < 0) { cout << tcpipErrorMsg [retCode] << endl; return(ERROR_SEND); }

#if DEBUG_STA // printing message sent to isAliveDaemon cout << "Message sent to prober:" << txmsgCrypted << endl; //myServer.getTXmsg(0) << endl; cout << "==================================================================" << endl; #endif

fflush(stdout); delete [] txmsg; delete [] rxmsgDecrypted; delete [] txmsgCrypted; delete [] rxmsgCrypted;

#if DEBUG_STA cout << "End of answerProbe()! Returning OK! " << endl; #endif return(OK);

}// END OF answerProbe() //====================================================================================

85

//==================================================================================== // This function initializes a tcp server calling socket, bind, listen ulong initializeSingleTcpServer(ushort port, int *socketDescriptor, int verbose) { struct struct char int int sockaddr_in server_addr; //Hold the destination addr hostent *h; //Hold the server information serverAddress[SIZE_DATA]; sock_fd; yes = 1;

char buf[DATA_SIZE]; memset(buf, \0, DATA_SIZE); char convert[10];

#if DEBUG_STA printf("DEBUG_STA: IN initializeSingleTcpServer FUNCTION \n"); #endif

if((gethostname(serverAddress, sizeof(serverAddress))) < 0) // get the host name return(ERROR_GETHOSTNAME);

if((h = gethostbyname(serverAddress)) == NULL) // get the host info return(ERROR_GETHOSTBYNAME);

// Setting structure parameters ************************ server_addr.sin_family = SOCK_FAMILY; server_addr.sin_port //server_addr.sin_addr = htons(port); = *((struct in_addr *)h->h_addr);

server_addr.sin_addr.s_addr = htonl(INADDR_ANY); memset(&(server_addr.sin_zero), \0, 8); // zero to the rest of the structure // Setting structure parameters *******END**************

// Opening socket ************************ if ((sock_fd = socket(SOCK_FAMILY, SOCK_TYPE, SOCK_PROTOCOL)) < 0) return(ERROR_OPEN_SOCKET);

if(verbose) printf("TCP/IP server : Socket Opened ... \n");

86

// Forcing the port to be released ******** // Lose the pesky "Address alredy in use" error message ********* setsockopt(sock_fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int));

// Binding to port ******************** if ((bind(sock_fd, (struct sockaddr *) &server_addr, sizeof(server_addr))) < 0) { close(sock_fd); return(ERROR_BIND); }

if(verbose) printf("TCP/IP server : Bind to port %d ...\n", port);

// Listenig to port ******************** if ((listen(sock_fd, BACKLOGSINGLE)) < 0) { close(sock_fd); return(ERROR_LISTEN); }

if(verbose) { printf("TCP/IP server printf("Server Name (IP) } : Listening port %d ...\n", port);

: %s (%s)\n\n", h->h_name, inet_ntoa(*((struct in_addr *)h->h_add

memset(buf, \0, DATA_SIZE); strncat(buf, "TCP/IP server sprintf(convert, "%d", port); strncat(buf, convert, strlen(convert)); writeLog(buf); : Listening port ", strlen("TCP/IP server

: Listening port "));

memset(buf, \0, DATA_SIZE); strncat(buf, "Server Name (IP) : ", strlen("Server Name (IP) : "));

strncat(buf, h->h_name, strlen(h->h_name)); strncat(buf, "(", 1);

87

strncat(buf, inet_ntoa(*((struct in_addr *)h->h_addr_list[0])), strlen(inet_ntoa(*((struct in_addr *) strncat(buf, ")", 1); writeLog(buf);

*socketDescriptor = sock_fd;

return(OK); }// END OF initializeSingleTcpServer //====================================================================================

88

Apndice C e Cdigo Fonte do isAliveDaemon o

// isAliveDeamon.h (v1.0) *** Apenas para SOs UNIXlike *** // Desenvolvido sobre plataforma OpenBSD 3.3 // Author: Bruno Astuto Arouche Nunes // Date: 17-01-2004 // 2004/1 // // Compilando // g++ -I/usr/local/include/ -I/usr/local/include/mysql -O2 -c isAliveDaemon.cpp tcp_lib.cpp // // Linkando // g++ -g -O2 -L/usr/local/lib/mysql -o isAliveDaemon isAliveDaemon.o -L/usr/local/lib/ // -lsqlplus -lz -lmysqlclient -lcrypto tcp_lib.cpp //-------------------------------------------------------------------------------------------

#ifndef _ISALIVEDAEMON_H_ #define _ISALIVEDAEMON_H_

#include <stdlib.h> #include <stdio.h> #include <time.h> #include <fstream.h> #include <iostream.h> #include <sys/wait.h> #include <signal.h> #include <syslog.h> #include <iomanip.h>

#include <openssl/evp.h> #include "sqlplus.hh" #include "tcp_lib.h"

#define VERBOSE 0 #define PROBE_ERROR 13 #define UPDATE_ERROR 17 #define TIME_TO_WAIT 1 #define PORTNUMBER 56789 #define KEY_SIZE 16 // 16 char = 128 bits #define LINE_SIZE 4096 #define MAX_TTL 2 // max number of times the daemon wil try to probe the station #define ACK_MSG_SIZE 7 #define ACK_MSG "200 ACK" #define TOKEN ":" #define CONF_FILE_NAME "isAliveDaemon.conf" #define DB_NAME "DB_NAME" #define DB_HOST "DB_HOST" #define DB_USER "DB_USER" #define DB_PASSWD "DB_PASSWD" #define DB_TABLE_NAME "DB_TABLE_NAME"

/* -------------- PROTOTYPES --------------- */ // This function is responsable for the connection with the STAs. Its called by queryandprobe(con); ulong probeStation(char *serverAddr, int port, unsigned char *key, char *tableName);

// Reload Packet Filters rules *** OpenBSD 3.3 ONLY!!! *** ulong reloadPf(char *staAddr, char *tableName);

// Read parameters from the conf file. void readConfFile();

// Key generator : this is not the best way to do this. // it would be nice to find another way of generating keys. //--------------------------------------------------------void seedGen(); char* getKey();

90

//---------------------------------------------------------

// This function connects to the batabase and gets the info needed // to probe the STAs with the probeStation(...) function. int queryandprobe(Connection *con); /* ----------- END OF PROTOTYPES ------------ */

#endif

91

Apndice D e Script para Criao do BD ca StrikeIN

Script para criaao do BD StrikeIN c~ CREATE TABLE ipsValidos ( senhaAtual VARCHAR(20) NOT NULL, login VARCHAR(20) NOT NULL, enderecoIP VARCHAR(16) NOT NULL, TTL int(2) NOT NULL ); ALTER TABLE ipsValidos ADD PRIMARY KEY (login, enderecoIP); CREATE TABLE passwd ( senha VARCHAR(20) NOT NULL, login VARCHAR(20) NOT NULL, nome VARCHAR(20) NOT NULL ); ALTER TABLE passwd ADD PRIMARY KEY (login); ALTER TABLE ipsValidos ADD FOREIGN KEY (login) REFERENCES passwd (login) ON DELETE RESTRICT ON UPDATE RESTRICT;

Referncias Bibliogrcas e a
[1] Demetrio S. D. Carrin, Implementaao de um ponto de acesso seguro para o c redes 802.11b baseado no sistema operacional OpenBSD, Projeto Final de Curso, Departamento de Engenharia Eletrnica e Computaao - DEL/UFRJ, o c 2003. [2] P. D. M. J nior, B. A. A. Nunes, C. A. V. Campos, and L. F. M. de Moraes, u Avaliando a Sobrecarga Introduzida nas Redes 802.11 pelos Mecanismos de Segurana WEP e VPN/IPSec, WSEG2003/SBRC2003, Natal/RN, maio 2003. c [3] 802.11b, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specication: Higher-Speed Physical Layer Extension in the 2.4 GHz Band. IEEE Std 802.11b, 1999. [4] J. Walker, Unsafe at any key size: an analysis of the WEP encapsulation, tech. rep., IEEE 802.11 committee, March 2000. [5] N. Borisov, I. Goldberg, and D. Wagner, Intercepting Mobile Communications: The Insecurity of 802.11, http://www.isaac.cs.berkeley.edu/isaac/wepfaq.html. [6] W. A. Arbaugh, N. Shankar, and Y. C. J. Wan, Your 802.11 Wireless Network has No Clothes, Tech. Rep. 03628E, University of Maryland, March 30 2001. [7] OpenBSD, Sistema operacional de cdigo aberto e gratuito baseado no BSD o 4.4. http://www.openbsd.org, Pgina visitada em 2003. a [8] OpenSSL, Projeto OpenSSL que implementa o SSL e o TSL.

http://www.openssl.org, Pgina visitada em 2003. a

[9] G. Huang, S. Beaulieu, D. Rochefort, and IPSec Working Group, A TracBased Method of Detecting Dead IKE Peers, IETF Internet Draft: draft-ietfipsec-dpd-00.txt, July 2001. [10] S. Fluhrer, I. Mantin, and A. Shamir, Weaknesses in the key scheduling algorithm of RC4, Eighth Annual Workshop on Selected Areas in Cryptography, 2001. [11] RC4: Encrypty Algoritm of RSA Security, 2003. http://www.rsasecurity.com. [12] Lucent Orinoco - Users Guide for the ORiNOCO Managers Suite, 2000. Lucent Orinoco. [13] P. Srisuresh and K. Egevang, Traditional IP Network Address Translator (Traditional NAT), IETF RFC 3002, 2001. [14] S. Kent and R. Atkinson, IP Authentication Header, IETF RFC 2402, nov 1998. [15] S. Kent and R. Atkinson, IP Encapsulating Security Payload (ESP), IETF RFC 2406, nov 1998. [16] Oasis ferramenta de autenticaao c centralizada., 2002.

http://software.stockholmopen.net. [17] Nocat ferramenta de autenticaao c centralizada., 2002.

http://www.nocat.org. [18] Netlogon ferramenta de autenticaao c centralizada., 2002.

http://unit.liu.se/dokument/natverk/netlogon.html. [19] R. Stevens, Network Programming for Unix. PH PTR, 2nd ed., 1996. [20] Cygwin, Linux-like environment for windows. http://www.cygwin.com, Pgina visitada em 2003. a [21] D. Knuth, The Art of Computer Programming. Addison-Wesley, 2nd ed., 1981.

94

[22] S. J. S. D. Eastlake 3rd, Randomness Recommendations for Security. RFC1750, dec 1994. [23] G. V. L. F. M. d. M. Alexandre Mendes, Bruno Astuto Arouche Nunes, Estudo da Implementaao e Avaliaao de Algoritmos de Geraao de Seqncias c c c ue Aleatrias e suas Aplicaoes, 2003. o c [24] MYSQL++, Api c++ para acesso ao banco de dados mysql.

http://www.mysql.com/products/mysql++/, Pgina visitada em 2004. a

95