Instituto de Pesquisas Tecnolgicas do Estado de So Paulo

Fabricio de Almeida Rodrigues Gonalves

Anlise de Implementaes de Gerenciamento de Atribuio de Endereos IPv4 Baseado na Monitorao de Mensagens DHCP

So Paulo 2011

Fabricio de Almeida Rodrigues Gonalves

Anlise de Implementaes de Gerenciamento de Atribuio de Endereos IPv4 Baseado na Monitorao de Mensagens DHCP
Dissertao de Mestrado apresentada ao Instituto de Pesquisas Tecnolgicas do Estado de So Paulo IPT, como parte dos requisitos para a obteno do ttulo de Mestre em Engenharia de Computao

Data da Aprovao: ____/_____/_______

Prof. Dr. Volnys Borges Bernal (Orientador) IPT Instituto de Pesquisas Tecnolgicas do Estado de So Paulo

Membros da Banca Examinadora:

Prof. Dr. Volnys Borges Bernal (Orientador) IPT Instituto de Pesquisas Tecnolgicas do Estado de So Paulo

Prof. Dr. Sergio Takeo Kofuji (Membro) USP Universidade So Paulo

Prof. Dr. Alexandre Jos Barbieri de Sousa (Membro) IPT Instituto de Pesquisas Tecnolgicas do Estado de So Paulo

Fabricio de Almeida Rodrigues Gonalves

Anlise de Implementaes de Gerenciamento de Atribuio de Endereos IPv4 Baseado na Monitorao de Mensagens DHCP

Dissertao de Mestrado apresentada ao Instituto de Pesquisas Tecnolgicas do Estado de So Paulo - IPT, como parte dos requisitos para obteno do Ttulo de Mestre em Engenharia de Computao rea de Concentrao: Redes de Computadores

Orientador: Prof. Dr. Volnys Borges Bernal

So Paulo Abril/2011

Ficha Catalogrfica Elaborada pelo Departamento de Acervo e Informao Tecnolgica DAIT do Instituto de Pesquisas Tecnolgicas do Estado de So Paulo - IPT G635a Gonalves, Fabricio de Almeida Rodrigues Anlise de implementaes de gerenciamento de atribuio de endereos IPv4 baseado na monitorao de mensagens DHCP. / Fabricio de Almeida Rodrigues Gonalves. So Paulo, 2011. 109 p. Dissertao (Mestrado em Engenharia de Computao) - Instituto de Pesquisas Tecnolgicas do Estado de So Paulo. rea de concentrao: Redes de Computadores. Orientador: Prof. Dr. Volnys Borges Bernal

1. GAEIP (Gerenciamento de Atribuio de Endereo IP) 2. DHCP (Dynamic Host Configuration Protocol) 3. Endereo IP 4. Controle de acesso 5. Conflito de IP 6. Tese I. Instituto de Pesquisas Tecnolgicas do Estado de So Paulo. Coordenadoria de Ensino Tecnolgico II.Ttulo 11-63 CDU 004.738.5.057.4(043)

RESUMO

Com o crescimento da importncia das redes IP aumenta a preocupao com segurana e controle do acesso ao ambiente de redes locais. Entre os problemas, incluem-se a configurao no autorizada de endereos IP estticos por parte dos usurios, o que pode causar conflitos de IP, o uso indevido de recursos computacionais e a falta de rastreabilidade em casos de execuo ou tentativa de ataques. Para redes IPv4 uma das alternativas a utilizao de alguns mtodos de controle de gerenciamento da atribuio de endereos IP (GAEIP) baseado na monitorao de mensagens DHCP em switches ethernet. O trfego de uma estao autorizado somente se estiver utilizando endereo IP dinmico atribudo por um servidor DHCP. Este trabalho avaliou trs implementaes, sendo duas comerciais e uma prpria, com procedimentos de teste em quatro diferentes cenrios tpicos de organizao topolgica. A avaliao mostrou que a utilizao de GAEIP baseado na monitorao de mensagens DHCP eficaz quando todos os equipamentos da rede possuem a funcionalidade ativa.

Palavras Chave: Conflito de IP, Switch, Endereo IP fixo, Controle do acesso, DHCP.

ABSTRACT

Analysis of Implementation Management IPv4 Address Allocation Based Monitoring DHCP Messages

With the growing importance of IP networks is growing concern with security and access control to the environment of local networks. Among the problems include the configuration of unauthorized static IP addresses for users, which can cause IP conflicts, misuse of computer resources and lack of traceability in cases of execution or attempted attacks. For IPv4 networks some control methods of IP address assigned management (GAEIP) based on DHCP messages in Ethernet switches is one alternative. Traffic from a station is authorized only if it is using a dynamic IP address assigned by a DHCP server. This study evaluated three deployments, two commercial and one of its own with testing procedures in four different scenarios of typical topological organization. The results were evaluated and presented advantages and disadvantages of each of the implementations examined. The evaluate showed that GAEIP based on DHCP messages is effective if all network equipaments have this feature active.

Key words IP conflict, Switch, Static IP Address, Access control, DHCP

Lista de Ilustraes

Figura 2.1: Diagrama de estado do cliente DHCP.......................................................... 19 Figura 2.2: Formato da mensagem DHCP ..................................................................... 20 Figura 2.3: Detalhe DHCP DISCOVER .......................................................................... 21 Figura 2.4: Detalhe DHCP OFFER................................................................................. 21 Figura 2.5: Detalhe DHCP REQUEST ........................................................................... 22 Figura 2.6: Detalhe DHCP ACK ..................................................................................... 22 Figura 2.7: Detalhe DHCP RELEASE ............................................................................ 25 Figura 2.8: Detalhe DHCP lease time ............................................................................ 27 Figura 4.1 : Configurao usada na implementao de mercado M1 ............................ 44 Figura 4.2 : Definies Trfegos e Portas ...................................................................... 46 Figura 4.3: Diagrama de estado para porta de acesso .................................................. 48 Figura 4.4: Diagrama conexo porta acesso .................................................................. 49 Figura 4.5: Diagrama de estado para porta uplink ......................................................... 50 Figura 4.6: Diagrama conexo uplink ............................................................................. 52 Figura 4.7: Restrio de topologia do Address Guard Cenrio 1 ................................ 55 Figura 4.8: Restrio de topologia do Address Guard Cenrio 2 ................................ 56 Figura 5.1: Script bridge portas Address Guard ............................................................. 57 Figura 5.2: Script captura mensagens DHCP................................................................. 59 Figura 5.3: Script bloqueio trfego ................................................................................. 61 Figura 5.4: Script liberao trfego ................................................................................ 61 Figura 6.1: Topologia do Cenrio A................................................................................ 63 Figura 6.2: Topologia do Cenrio B................................................................................ 64 Figura 6.3: Topologia do Cenrio C ............................................................................... 66 Figura 6.4: Topologia do Cenrio D ............................................................................... 68 Figura 6.5: Topologia do Cenrio 1 Teste de Carga ................................................... 75 Figura 8.1: Comparativo Implementaes ...................................................................... 92 Figura A.1: Comportamento do comando ping na estao 1 ....................................... 100 Figura A.2: Comportamento da estao 2 usando DHCP e usando o mesmo IP fixo da estao 1 ...................................................................................................................... 101 Figura A.3: Coleta do trfego pelo sniffer ..................................................................... 101 Figura A.4: Comportamento da funcionalidade e estado da porta durante a desconexo e reconexo.................................................................................................................. 101 Figura A.5: Comportamento do comando ping na estao .......................................... 102 Figura A.6: Tela da mensagem DHCP ACK gerada pelo servidor DHCP no autorizado ..................................................................................................................................... 103 Figura A.7: Tela com o envio das mensagens DHCP no autorizadas ........................ 103 Figura A.8: Comportamento do comando ping na alterao dos endereos IP ........... 104 Figura A.9: Comportamento da funcionalidade no switch da implementao de mercado M1 ................................................................................................................................ 104 Figura A.10: Comportamento da funcionalidade no switch da implementao de mercado M2 ................................................................................................................. 105 Figura A.11: Configurao do cliente na alterao para IP fixo .................................... 105 Figura A.12: Captura de trfego pelo sniffer ................................................................ 106

Figura A.13: Comportamento do comando ping para uma estao que est no switch sem GAEIP e para o servidor DHCP ........................................................................... 107 Figura A.14: Comportamento do comando ping para uma estao que est no switch sem GAEIP e para o servidor DHCP, nas implementaes de mercado M1 e M2. .... 108 Figura A.15: Captura de trfego pelo sniffer no switch com GAEIP ............................. 108 Quadro 2.1: Campos mensagem DHCP. ....................................................................... 23 Quadro 2.2: Campo tipo das mensagens DHCP. ........................................................... 24 Quadro 6.1: Teste conexo de um novo cliente via DHCP. ........................................... 69 Quadro 6.2: Teste conexo de um novo cliente utilizando IP fixo. ................................. 70 Quadro 6.3: Teste alterao do IP de dinmico para fixo. ............................................. 70 Quadro 6.4: Teste alterao do IP de dinmico para fixo com filtragem da mensagem DHCP. ............................................................................................................................ 70 Quadro 6.5: Teste renovao do aluguel do endereo IP. ............................................. 71 Quadro 6.6: Teste alterao do IP de dinmico para fixo com filtragem da mensagem DHCP Release e com o tempo de alugle expirado. ....................................................... 71 Quadro 6.7: Teste desconexo e reconexo do ponto de rede mesma mquina. ...... 72 Quadro 6.8: Teste substituio da estao por outra na mesma porta. ......................... 72 Quadro 6.9: Teste reinicializao do cliente. .................................................................. 73 Quadro 6.10: Teste reinicializao do switch. ................................................................ 73 Quadro 6.11: Teste de carga.......................................................................................... 74 Quadro 6.12: Teste impacto na funcionalidade de lista de controle de acesso. ............. 75 Quadro 6.13: Teste conexo de um novo cliente Cenrio B. ...................................... 76 Quadro 6.14: Teste resistncia contra servidor DHCP no autorizado Cenrio B. ..... 76 Quadro 6.15: Teste conexo de um cliente no switch sem GAEIP. .............................. 78 Quadro 6.16: Teste alterao da configurao do IP de dinmico para fixo Cenrio C. ....................................................................................................................................... 78 Quadro 6.17: Teste reinicializao da porta (desconexo e conexo) do cliente. ......... 79 Quadro 6.18: Teste reinicializao da porta de uplink.................................................... 79 Quadro 6.19: Teste reinicializao do switch com GAEIP. ............................................ 80 Quadro 6.20: Teste reinicializao do switch sem GAEIP. ............................................ 80 Quadro 6.21: Teste impacto em outros protocolos. ........................................................ 81 Quadro 6.22: Teste resistncia contra servidor DHCP no autorizado para clientes conectados no switch A. ................................................................................................. 81 Quadro 6.23: Teste resistncia contra servidor DHCP no autorizado para clientes conectados no switch B. ................................................................................................. 82 Quadro 6.24: Teste resistncia contra servidor DHCP no autorizado para clientes conectados no switch A. ................................................................................................. 82 Quadro 6.24: Teste resistncia contra servidor DHCP no autorizado para clientes conectados no switch B. ................................................................................................. 83 Quadro 7.1: Comparativo dos testes realizados. ............................................................ 85 Quadro 8.1: Comparativo das implementaes. ............................................................ 91

Lista de Abreviaturas e Siglas

ARP BPDU CRC DDOS DHCP DSAP FCS GAEIP IEEE IP IANA LLC MAC MANET NAC Mbps PACL RFC SNMP SNAP SSAP TCP TTL UDLD UDP WLAN

Address Resolution Protocol Bridge Protocol Data Unit Cyclic Redundancy Checks Distributed Deny of Service Dynamic Host Configuration Protocol Destination Service Access Point Frame Check Sequence Gerenciamento de atribuio de endereos IP Institute of Electrical and Eletronic Engineers Internet Protocol Internet Assigned Numbers Authority Logical Link Control Medium Access Control Mobile ad hoc Network Network Admission Control Megabits per second Port Access List Control Request for Comments Simple Network Management Protocol Secure Network Access Protocol Source Service Access Point Transport Control Protocol Time to Live Unidirectional Link Detection User Datagram Protocol Wireless Local Area Network

Sumrio 1 INTRODUO ........................................................................................................ 12 1.1 Motivao .......................................................................................................... 13 1.2 Objetivo ............................................................................................................. 15 1.3 Escopo .............................................................................................................. 15 1.4 Organizao do trabalho ................................................................................... 16 CONCEITOS ........................................................................................................... 18 2.1 Protocolo DHCP ................................................................................................ 18 2.2 Cliente DHCP em algumas situaes tpicas .................................................... 24 2.3 Funcionalidades relacionadas ao controle de atribuio de endereo pelo DHCP.......................................................................................................................... 27 TRABALHOS RELACIONADOS ............................................................................ 29 3.1 Shahri et al ........................................................................................................ 29 3.2 Grochla et al ...................................................................................................... 30 3.3 Joshi et al .......................................................................................................... 31 3.4 Li et al................................................................................................................ 32 3.5 Sue et al ............................................................................................................ 33 3.6 Dai et Chiang .................................................................................................... 34 3.7 Wang et Lee ...................................................................................................... 35 3.8 Boudjit et al ....................................................................................................... 36 3.9 Yang et Mi ......................................................................................................... 36 3.10 Zuquete .......................................................................................................... 37 3.11 Brik et al ......................................................................................................... 38 3.12 Concluso ...................................................................................................... 38 IMPLEMENTAES RELACIONADAS ................................................................. 40 4.1 Descrio da implementao de mercado M1 .................................................. 40 4.2 Descrio da implementao de mercado M2 .................................................. 44 4.3 Proposta Address Guard ................................................................................... 45 IMPLEMENTAO DO ADDRESS GUARD .......................................................... 57 5.1 Componentes de hardware e software utilizados .............................................. 57 5.2 Implementao .................................................................................................. 58 METODOLOGIA E CENRIOS DE TESTES .......................................................... 62 6.1 Descrio dos cenrios ..................................................................................... 62 6.2 Metodologia dos testes ..................................................................................... 68 REALIZAO DOS TESTES E RESULTADOS ..................................................... 84 7.1 Equipamentos utilizados ................................................................................... 84 7.2 Execuo dos testes ......................................................................................... 84 7.3 Resultados relevantes ....................................................................................... 85 AVALIAO E COMPARAO DOS RESULTADOS .......................................... 88 8.1 Testes do cenrio A .......................................................................................... 88 8.2 Testes do cenrio B .......................................................................................... 88 8.3 Testes do cenrio C .......................................................................................... 89 8.4 Testes do cenrio D .......................................................................................... 89 8.5 Vantagens e desvantagens das implementaes ............................................. 90 CONCLUSO .......................................................................................................... 93

9.1 Contribuies .................................................................................................... 94 9.2 Trabalhos futuros .............................................................................................. 95 REFERNCIAS .............................................................................................................. 96 REFERNCIAS COMPLEMENTARES ......................................................................... 99 APNDICE A ............................................................................................................... 100 APNDICE B ............................................................................................................... 109

12

INTRODUO

Com o aumento da importncia das redes TCP/IP, usadas cada vez mais, por aplicaes crticas, aumenta tambm a preocupao com a monitorao e controle destes ambientes para evitar problemas de disponibilidade, rastreabilidade, controle de acesso e desempenho.

Um dos desafios atualmente so as sub-redes corporativas voltadas aos equipamentos dos usurios: desktops e notebooks.

A administrao da configurao do endereamento de rede um dos problemas destas redes, principalmente para evitar o conflito de endereos IP e, tambm, para viabilizar o rastreamento dos acessos.

Existem duas alternativas principais: configurao esttica ou configurao dinmica do endereamento utilizando o protocolo DHCP (Dynamic Host Configuration Protocol). A configurao esttica, alm de ser mais custosa e complexa operacionalmente, no impede que um usurio com um notebook com privilgio de administrador, configure por conta prpria o endereamento do seu equipamento.

A melhor alternativa a configurao dinmica utilizando o protocolo DHCP, porm ainda existe a possibilidade de usurios configurarem endereos IP de forma esttica, embora exista um servidor DHCP no ambiente de rede. Alm disso, um usurio pode tambm receber um endereo IP de um servidor DHCP e alterar o endereo trazendo o problema citado a qualquer momento. Isso pode levar a alguns problemas como:

Perda de rastreabilidade em possveis ataques e fraudes, pois sem a atribuio de endereos pelo servidor DHCP, no existem registros de qual hardware utilizou um endereo IP que pode ter sido envolvido em algum incidente de segurana;

13

Aumento nos custos de servios de suporte, gerados pelos atendimentos desnecessrios ocasionados por conflitos de endereo IP; Indisponibilidade de sistemas devido a possveis conflitos de IP; Indisponibilidade de segmentos de rede devido a uma configurao errada feita intencionalmente ou no, tendo o usurio digitado como IP da sua estao o mesmo do default gateway do segmento de rede;

Contorno de restries de controle de acesso por meio do IP, pois ao se alterar o endereo IP um usurio pode ter acesso no autorizado a sistemas, que tem como controle de acesso o endereo IP de origem.

Dai e Chiang (2007) citam o problema causado pela falta de controle, onde usurios chamados de ilegais alteram seus endereos IP para fixos, e causam interferncias na rede, que dependendo do tamanho da rede, a correo pode ser muito difcil.

Conforme Li et al (2008) a falta de controle dos endereos IP de origem, causa perda de desempenho, porque recursos so alocados para pacotes que no so vlidos, deixando os vlidos na fila para serem encaminhados. Esta invalidade de pacotes pode ser causada por um usurio, que alterando o seu endereo IP, tem acesso a recursos que normalmente no estariam disponveis para o seu perfil.

1.1

Motivao

As alternativas para controle do problema de gerenciamento da atribuio de endereos IP em redes de usurios so baseadas em funcionalidades existentes nos switches (equipamentos tipo bridge).

Com a descentralizao da responsabilidade pela segurana e pelo controle de acesso, os switches nos quais as estaes clientes so conectadas, so tambm exigidos cada vez mais para realizar funes que antes no eram de sua responsabilidade.

14

Uma maneira para se controlar o endereo IP da estao cliente, a proibio desta alterao no sistema operacional. Esta ao no pode ser realizada em todos os casos, devido diversidade dos ambientes e tambm dos respectivos clientes, tendo como exemplo uma grande corporao que possui, entre seus colaboradores, consultores de diversas empresas. Estes podem ter esta restrio inviabilizada pela poltica de segurana dos respectivos ambientes de rede. Outra razo para a impossibilidade de se bloquear a permisso de alterao do IP a necessidade deste recurso para diversos tcnicos que tem seus computadores portteis conectados em diversas redes locais, e algumas sem um servidor DHCP para fornecer o endereo IP.

Controles, como o NAC (Network Admission Control) (2009), so implantados no nvel de acesso dos ambientes, com a finalidade de aumentar o nvel de segurana e de controle. Um destes mecanismos protocolo IEEE 802.1x, que consiste na autenticao do usurio para permitir o seu acesso rede, usando a mesma conta e senha para acesso aos recursos computacionais da corporao. Outra funcionalidade usada pelo NAC a verificao das atualizaes de antivrus. Estes controles podem ser tambm instalados separadamente, dependendo da necessidade do ambiente e da infraestrutura disponvel. Para se implementar o NAC, devem ser atendidos vrios prrequisitos, como servidores de antivrus, servidores de autenticao e switches de rede com as funcionalidades requeridas para a aplicao do controle, entre outros.

Existem algumas implementaes para controle de configurao de endereamento IP para terminais (desktop, PDA, telefone celular, telefone IP) de usurios, baseadas no protocolo DHCP. Quando esta funcionalidade de controle de acesso DHCP aplicada a uma determinada porta de um switch, o uso desta permitido somente aps a finalizao do processo de obteno ou renovao de um endereo IP dinmico, via o protocolo DHCP, por parte do equipamento conectado respectiva interface.

15

1.2

Objetivo

O objetivo deste trabalho avaliar as diferentes implementaes de GAEIP (gerenciamento de atribuio de endereo IP) baseado na monitorao de mensagens DHCP e filtragem de pacotes pelo switch de acesso, com a finalidade de propiciar um controle maior do uso de endereos IP pelas estaes de usurios. Esta funcionalidade de controle de acesso usando o protocolo DHCP pode estar presente nos switches ethernet, em Access Points, equipamentos tipo Node B (Equipamentos de agregao nas redes mveis 3G) e ainda para outras tecnologias como Wi Max e 4G (LTE).

Para avaliao da funcionalidade GAEIP foram escolhidas trs implementaes, so duas implementaes de mercado, aqui relacionadas como implementao M1 e M2, e uma implementao tipo prova de conceito.

Como parte do trabalho foi realizada uma implementao de GAEIP com monitorao de mensagens DHCP, tipo prova de conceito, para permitir explorar possveis problemas nas implementaes de mercado, levando em considerao a segurana, desempenho, impacto na disponibilidade e em outras funcionalidades ou protocolos.

Para realizao da avaliao foram definidos quatro cenrios tpicos de uso.

1.3

Escopo

O escopo do trabalho limita-se a redes locais TCP/IP, baseadas nos protocolos Ethernet (IETF, 1984), e IP verso 4 (IETF, 1981). As implementaes de mercado avaliadas foram identificadas como M1 e M2 para referncia. Uma implementao de teste foi implantada baseada no sistema aberto Linux.

16

1.4

Organizao do trabalho

Os prximos captulos esto organizados da seguinte forma:

O captulo 2, Reviso Bibliogrfica, apresenta o protocolo DHCPv4 utilizado nos mtodos de controle de atribuio de endereos IP avaliados. Alm disso, so apresentados outros controles implementados pelos switches relevantes ao trabalho. A seo funcionamento de um cliente DHCP analisa o comportamento do cliente DHCP em diversas situaes ocorridas no ambiente de rede local, solicitando um novo endereo IP, renovando o mesmo endereo, alterando a configurao do IP para esttica, e as alteraes realizadas na porta, como a conexo e desconexo de uma estao em uma porta do switch.

No captulo 3, Trabalhos Relacionados, so citados trabalhos relacionados ao controle de endereamento de atribuio de endereos IP, aumentar o controle do acesso e a segurana das redes locais.

No captulo 4, Implementaes Relacionadas, so analisadas as funcionalidades aplicadas pelos fornecedores de switches no mercado. Nesta anlise so descritas as implementaes, os mtodos e as respectivas restries para o GAEIP. A proposta do Address Guard apresentada, incluindo a diferena para as implementaes de mercado e tambm suas restries.

No captulo 5, Implementao do Address Guard, uma alternativa de implementao desenvolvida e aplicada para que se possa estudar o comportamento da funcionalidade e possibilitar a aplicao deste controle de acesso em equipamentos de rede como, por exemplo, agregadores de redes mveis 3G, 4G e agregadores de redes sem fio.

No captulo 6, Metodologia e Cenrios de Teste, apresentada toda metodologia para teste das implementaes, incluindo o caderno de testes detalhado com as instrues e procedimentos para realizao de cada teste.

17

O captulo 7 apresenta os resultados de todos os testes realizados conforme metodologia apresentada no captulo 6.

No captulo 8, Avaliao e Comparao dos Resultados, so comparados todos os resultados coletados a partir dos captulos 5, com as anlises realizadas no captulo 6.

O captulo 9, Concluso, apresenta os resultados do trabalho, contribuies e sugestes para pesquisas futuras.

18

CONCEITOS

Neste captulo so abordados os conceitos sobre redes locais, tendo foco os protocolos de alocao dinmica de endereos IP (ITEF, 1981), com a finalidade de prover os fundamentos necessrios para o desenvolvimento de uma prova de conceito e, tambm a anlise de alternativas de GAEIP (gerenciamento de atribuio de endereo IP) baseado na monitorao das mensagens DHCP.

2.1

Protocolo DHCP

O protocolo DHCP (Dynamic Host Configuration Protocol) (IETF, 1997) foi desenvolvido para possibilitar a atribuio automtica de endereos IP. Este tem melhorias em relao ao seu antecessor o BOOTP (IETF, 1997). Uma melhoria a possibilidade de o n receber todas as configuraes necessrias, como por exemplo endereo IP, mscara e gateway, para a sua interoperabilidade com a rede na qual est conectado.

O servio DHCP permite que sejam utilizadas trs tipos de atribuio: manual, automtica permanente e automtica. Na configurao manual permitido ao administrador a configurao de um endereo especfico para um n. O DHCP tambm permite configurao automtica, atribuindo um endereo IP permanente para um n. A terceira maneira seria atribuindo de forma automtica, endereos IP temporrios. Para a atribuio dinmica, o DHCP utiliza como identificador da atribuio o endereo MAC do n solicitante. O modo mais aplicado aquele que a atribuio dinmica e o endereo IP emprestado para o n solicitante, por um tempo finito.

Mensagens DHCP so usadas para transportar todas as informaes necessrias para o funcionamento do protocolo. No quadro 2.1 so explicadas a funo de cada campo da mensagem DHCP, que ilustrada na figura 2.2.

19

INICIO

Initialize
Recebe DHCPOFFER Envia DHCPDISCOVER

Recebe DHCPNACK

Select

Recebe DHCPNACK

Envia DHCPREQUEST

Rebind

Envia DHCPREQUEST

Renew

Recebe DHCPACK

Recebe DHCPACK

Request
Envia DHCPREQUEST Recebe DHCPACK

Bound

Envia DHCRELEASE

Figura 2.1: Diagrama de estado do cliente DHCP Fonte: Soares, Lemos e Colcher (2000)

20

OP

HTYPE Segundos

HLEN Flags

HOPS

ID de Transaes Endereo IP do Cliente Seu Endereo IP Endereo IP do Servidor Endereo IP do Roteador Endereo de Hardware do Cliente (16 octetos) Nome do Host do Servidor (64octetos) Nome do Arquivo de Partida (128 octetos) Opes (varavel)
Figura 2.2: Formato da mensagem DHCP Fonte: Soares, Lemos e Colcher (2000)

A atribuio de um endereo IP segue seis etapas que so observadas no diagrama de estado do protocolo, apresentada na figura 2.1. No estado de INITIALIZE, o cliente envia uma requisio de solicitao de endereo IP, usando a mensagem DHCPDISCOVER que encapsulada em um datagrama UDP na porta 67 com destino um endereo de broadcast (IETF, 1984), conforme figura 2.3. Depois deste envio, a estao passa para o estado SELECT. Todos os elementos do segmento de rede recebem esta mensagem, que enviada usando o endereo de origem da prpria estao e endereo de destino o de broadcast. Somente o servidor DHCP responder a esta solicitao usando a mensagem de DHCPOFFER. A figura 2.4 apresenta os campos de uma mensagem DHCPOFFER capturada.

21

Figura 2.3: Detalhe DHCP DISCOVER Fonte: Elaborado pelo autor (2010)

Figura 2.4: Detalhe DHCP OFFER Fonte: Elaborado pelo autor (2010)

O cliente receber uma ou mais mensagens de DHCPOFFER, que tem a oferta do endereo IP do servidor DHCP para o cliente, dependendo da quantidade de servidores DHCP na rede. Ao selecionar a primeira mensagem recebida, o cliente responde ao servidor DHCP usando a mensagem de DHCPREQUEST, figura 2.5, e entra no estado de REQUEST. O cliente s poder usar o endereo IP oferecido pelo servidor DHCP aps receber a mensagem DHCPACK, na figura 2.6, que assim entrar no estado de BOUND.

22

Figura 2.5: Detalhe DHCP REQUEST Fonte: Elaborado pelo autor (2010)

Figura 2.6: Detalhe DHCP ACK Fonte: Elaborado pelo autor (2010)

O cliente permanece neste estado enquanto estiver usando o endereo IP. Caso no haja mais interesse em usar este endereo, o cliente pode cancelar o uso deste usando a mensagem DHCPRELEASE, apresentada na figura 2.7. Quando esta mensagem encaminhada o cliente sai do estado de BOUND e volta para o INITIALIZE.

Para a renovao do endereo IP, o cliente ao receber a atribuio, configura trs temporizadores que controlaro a primeira tentativa de renovao, uma segunda tentativa e o fim da alocao. Os valores padres so a metade do tempo do aluguel, um quarto da outra metade do tempo e no final do aluguel. Para tentar renovar o endereo, o cliente envia uma mensagem de DHCPREQUEST, e em seguida entra para o estado de RENEW. Se autorizada a renovao, o servidor enviar um DHCPACK e o cliente voltar para o estado de BOUND. Caso contrrio o cliente receber um DHCPNACK e no utilizar mais o endereo IP. Se o cliente no conseguir renovar no primeiro temporizador, tentar novamente no segundo. Este expirando, o cliente entrar no estado de REBIND, que indica a falha de conectividade

23

com o servidor DHCP atual. Com isso o cliente voltar a enviar um DHCPREQUEST para toda a rede, procurando qualquer servidor DHCP que possa renovar o endereo IP j em uso. Recebendo uma mensagem DHCPACK volta para o estado de BOUND. O ltimo temporizador atua no estado de vincula novamente REBIND e far com que o cliente no use mais o endereo IP caso no receba nenhuma resposta, levando para o estado de INITIALIZE forando o cliente a reiniciar todo o processo.

O quadro 2.1 apresenta os campos de uma mensagem DHCP.

Quadro 2.1: Campos mensagem DHCP.

Campo OP HTYPE HLEN HOPS ID de Transaes Segundos Flags Endereo IP do Cliente Seu Endereo IP Endereo IP do Servidor Endereo IP do Roteador Endereo de Hardware do Cliente Nome do Host do Servidor Nome do Arquivo de Partida Opes

Descrio Indica se a mensagem uma solicitao ou resposta Tipo de endereo da camada de enlace Tamanho do endereo do hardware Contagem de passos da rota Usado para mquinas sem disco para solicitaes e respostas Tempo desde que o cliente fez a solicitao Usado para solicitaes broadcast Endereo do cliente em caso de renovao Resposta do endereo IP ao cliente em novas alocaes Endereo IP do servidor Usado para servidores que esto em redes diferentes dos clientes

Endereo fsico da interface de rede do cliente Nome do Servidor usado pelo BOOTP Usado pelo BOOTP para indicar o arquivo inicial das configuraes de uma mquina sem disco Diversos parmetros so configurados neste campo, que por exemplo indica o tipo de mensagem DHCP, que com o cdigo 53 e tipos de 1 a 7, indica se um DHCPREQUEST, OFFER e todas as outras mensagens DHCP.

Todas as mensagens DHCP so diferenciadas no campo de opes, conforme a RFC 2132. A diferenciao entre elas est no campo tipo, todas sob o cdigo 53. Em uma

24

mesma mensagem DHCP, pode conter mais de uma opo de cdigos diferentes. Os tipos de mensagem so mostrados no quadro 2.2.
Quadro 2.2: Campo tipo das mensagens DHCP.

Tipo 1 2 3 4 5 6 7 8

Mensagem DHCPDISCOVER DHCPOFFER DHCPREQUEST DHCPDECLINE DHCPACK DHCPNAK DHCPRELEASE DHCPINFORM

2.2

Cliente DHCP em algumas situaes tpicas

O funcionamento do cliente DHCP varia de acordo com a situao na qual se encontra. So descritas algumas situaes que podem acontecer em uma operao normal de um ambiente de rede local.

Nova atribuio de endereo IP dinmico; Alterao de endereo dinmico para fixo; Reinicializao da conexo entre o switch e o cliente; Renovao do endereo IP.

2.2.1 Atribuio de endereo IP dinmico O cliente, quando no possui nenhum endereo IP atribudo anteriormente, envia a mensagem DHCP DISCOVER. Aps isto recebe o DHCPOFFER, enviando em seguida o DHCPREQUEST e aguarda a resposta do servidor. Assim a troca de mensagens DHCP nesta situao segue a ordem: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK.

25

2.2.2 Alterao de endereo dinmico para fixo Nos sistemas operacionais, na alterao do endereo IP de dinmico para fixo, envia da a mensagem DHCP RELEASE, conforme figura 2.7. De acordo com a RFC 2131, o cliente DHCP quando no necessita mais do endereo IP atribudo pelo servidor DHCP, envia a mensagem de DHCPRELEASE para o servidor DHCP liberando o endereo IP.

Este comportamento pde ser confirmado pela observao das mensagens DHCP trocadas pelo sistema operacional Windows Vista, que quando o endereo IP foi alterado, a estao envia para o servidor DHCP uma mensagem de DHCPRELEASE.

No DHCP RELEASE, o cliente envia ao servidor DHCP a solicitao para a liberao do endereo IP, identificando qual endereo IP deve ser liberado, pelo endereo fsico da respectiva interface.

Figura 2.7: Detalhe DHCP RELEASE Fonte: Elaborado pelo autor (2010)

2.2.3 Reinicializao da conexo entre switch e o cliente

Ao desconectar e reconectar o cabo de rede, o cliente DHCP envia uma mensagem DHCP REQUEST, contendo no campo de opes o endereo IP atribudo pelo servidor anteriormente, na tentativa de reutiliz-lo. O servidor responde ainda tendo como

26

destino o endereo de broadcast, pois o cliente ainda no tem autorizao para usar qualquer endereo IP. Esta resposta um DHCP ACK liberando o endereo para o cliente, que a partir deste momento j pode enviar e receber datagramas IP usando o endereo IP em questo.

A mesma desconexo e reconexo pode acontecer caso o switch seja reiniciado.

Em ambas as situaes descritas, se o servidor negar o uso do endereo IP com a mensagem DHCPNACK, obriga o cliente a reiniciar todo o processo de obteno de endereo IP. Assim, a ordem de mensagens : DHCPREQUEST e DHCPACK caso o servidor autorize a utilizao do endereo IP. Do contrrio as seguintes mensagens sero trocadas entre cliente e servidor: DHCPRQUEST, DHCPNACK, DHCPDISCOVER, DHCPOFFER, DHCPREQUEST e DHCPACK.

2.2.4 Renovao do endereo IP A renovao do endereo IP solicitada do cliente para o servidor, quando o aluguel do endereo IP alcanar a metade do tempo estabelecido pelo servidor. Caso esta renovao no tenha sucesso por qualquer motivo, o cliente tenta novamente em 75 % do tempo e ainda quando o tempo de aluguel expirar.

O cliente envia a mensagem DHCPREQUEST e aguarda a mensagem DHCPACK. Caso no receba o DHCPACK na ltima tentativa, toda obteno do endereo IP inicia como se o cliente no tivesse nenhum endereo IP, j descrito no item 2.2.1. O tempo de lease enviado na mensagem DHCP ACK. A unidade de tempo usada, seguindo a RFC, em segundos e tem tamanho de 32 bits.

27

Na figura 2.8, uma mensagem DHCP ACK, que tem cdigo 53 e tipo 5, tem atrs desta opo diversas outras como a opo 54, que identifica o servidor DHCP, e aps esta o tempo de lease.

Figura 2.8: Detalhe DHCP lease time Fonte: Elaborado pelo autor (2010)

2.3

Funcionalidades relacionadas ao controle de atribuio de endereo pelo DHCP

2.3.1 IP Source Guard Esta funcionalidade implementada em alguns switches como os switches das implementaes de mercado, usada para impedir que uma estao envie datagramas IP com um endereo IP de origem diferente do que ela comeou a usar, ao se conectar ao switch. Isto impede que um usurio mal intencionado realize qualquer tentativa de ataque ou negao de servio, sem que seja identificado. Isto , somente o endereo IP atribudo estao conectada a respectiva interface do switch, poder ser origem dos pacotes encaminhados por esta mesma porta.

2.3.2 Trusted DHCP Server Com este recurso o switch pode, quando habilitada esta funcionalidade, identificar quais as portas podem ser usadas por servidores DHCP, classificando-as como confiveis. J

28

nas portas que no so confiveis, os switches bloqueiam as mensagem de DHCPOFFER, usada pelo servidor DHCP para oferecer um endereo IP um cliente. Isto garante que ao se instalar um servidor DHCP em um segmento, e este no seja vlido, no conseguir fornecer endereos IP e causar indisponibilidade no ambiente, que a finalidade desta funcionalidade, tambm chamada de DHCP snooping.

Apesar de tambm usar mensagens DHCP para manter em uma tabela de estado o IP atribudo para uma estao, a porta e o endereo MAC, no consegue impedir que um cliente tenha acesso a rede sem usar endereos dinmicos. Alm disto, ainda tem prrequisitos como s funcionar com um hardware especfico, com determinadas verses de sistema operacional, sem usar esquemas para alta disponibilidade do switch.

29

TRABALHOS RELACIONADOS

Este captulo apresenta alguns trabalhos relacionados ao tema de gerenciamento da atribuio de endereos IPv4.

O gerenciamento da atribuio de endereos IP representa a monitorao e controle dos endereos IP atribudos aos equipamentos de uma rede TCP/IP e tem como objetivo evitar que um mesmo endereo IP seja utilizado por mais de um cliente de uma rede TCP/IP, e tambm garantir que somente clientes tenham acesso ao ambiente de rede caso usem endereo IP dinmico.

3.1

Shahri et al

O trabalho de Shahri et al (2003) cita que o rpido crescimento das redes de dados e a necessidade por estas interconexes so os dois principais fatores do aumento da preocupao com a segurana destas redes. Os autores defendem o uso de autenticao de usurio para controlar o acesso s redes locais. A mudana de uma arquitetura centralizada para uma descentralizada seria uma alternativa. Para isto proposto um novo protocolo para autenticao no acesso as redes locais. A mudana para uma arquitetura distribuda seria para aumentar a segurana, confiabilidade e disponibilidade na autenticao dos usurios.

O SNAP (Secure Network Access Protocol) o protocolo sugerido para que a autenticao de usurios na rede local seja feita de forma distribuda. Faz parte deste mecanismo de autenticao um nmero de servidores que dividem a responsabilidade pela autenticao do usurio, tendo para cada um dos servidores uma parte do cdigo de acesso. Este cdigo de acesso o que permite ou no o usurio de ter acesso aos recursos de rede. Os servidores de autenticao denominados no SNAP podem ser servidores, roteadores, gateways ou qualquer outro componente da rede local.

30

O usurio solicita autenticao para um servidor de autenticao, que neste caso denominado n local. Este n local, caso o usurio ainda no seja um usurio vlido, envia para o usurio a quantidade de partes da chave de autenticao que devem ser obtidas e os respectivos servidores de autenticao. Aps isto o usurio inicia comunicao com todos os servidores de autenticao para buscar as partes do cdigo de acesso. Em cada servidor, a autorizao do usurio verificada em sua base local. Ao conseguir todas as partes do cdigo de acesso, o cliente apresenta ao n local. Com isto o n local valida o cdigo, concedendo ou no acesso aos recursos de rede.

A anlise do trabalho de Shahri et al (2003) demonstra a preocupao com os acessos dos usurios nas redes locais, e com isto a disponibilidade fundamental para o bom funcionamento das redes locais. Mas um usurio mesmo autenticado pode causar indisponibilidade de alguma comunicao com uma simples mudana de endereo IP.

3.2

Grochla et al

Conforme Grocha et al (2009), um rpido crescimento do interesse de trfego entre redes sem fio vem sendo observado. Estas redes podem ser de interfaces fsicas diferentes como por exemplo 802.11b e 802.11a. Para simplificar o acesso a estas redes, um procedimento de autoconfigurao que prov as configuraes mnimas para acesso dos usurios muito importante.

Uma grande preocupao com esta interoperabilidade entre os ambientes o uso de um nico endereo IP por clientes diferentes, causando um conflito de endereo IP.

Os autores propem a autoconfigurao dos terminais das redes sem fio, com o uso do protocolo DHCP. Para isto so sugeridas algumas alteraes no protocolo, como o uso de algumas opes nas mensagens DHCP para informar o SSID por exemplo. Outra alterao a na possibilidade de uso de mais de um servidor DHCP para atender a mesma rede. Neste caso os servidores DHCP devem enviar periodicamente mensagens DHCP DISCOVER com a informao de servidor DHCP dentro das opes

31

da mensagem DHCP. Ao receber esta mensagem o servidor DHCP responde com um DHCP OFFER mantendo a informao de servidor. O mtodo para a eleio do servidor ativo o maior endereo MAC. Assim quando o servidor DHCP recebe uma mensagem DHCP OFFER com um endereo MAC menor que o seu prprio endereo MAC, este servidor deve enviar uma mensagem de DHCP REQUEST. Ao detectar outro servidor DHCP, o atual, caso perca a eleio, dever enviar a mensagem de DHCP NACK para todos os clientes com endereos IP em uso para que os mesmos possam solicitar novos endereos IP do servidor vencedor da eleio. A finalidade deste mecanismo evitar que mais de um servidor DHCP atribua endereo IP para clientes de uma mesma rede, garantindo assim que no ocorra conflito de endereo IP.

A anlise do trabalho de Grochla et al (2009) mostra a importncia do correto funcionamento do protocolo DHCP, sendo muito crtico para o correto funcionamento das redes TCP/IP. Um conflito de endereo IP pode inviabilizar o correto funcionamento da proposta. Este conflito pode acontecer com uma simples alterao de configurao de um cliente. Nesta proposta, mesmo com as alteraes no protocolo DHCP, o problema no consegue ser evitado. O controle para evitar o conflito feito somente na atribuio do endereo IP.

3.3

Joshi et al

O trabalho de Joshi et al (2009) ressalta a importncia da mitigao de problemas com o IP spoofing o mais prximo da origem, no caso de redes de banda larga nos concentradores de acesso.

O IP spoofing usado nos ataques mais comuns chamados DoS (deny of service), dificultando a identificao da origem, porque a fonte do ataque altera o seu endereo IP.

Como proposta, os autores sugerem algumas melhorias no protocolo DHCP, para que sejam usados nos equipamentos concentradores de acesso de redes de banda larga.

32

Estas melhorias so algumas mensagens novas no protocolo. Assim o concentrador faria a interceptao da mensagem do cliente, que por sua vez faria a solicitao ao servidor DHCP. O concentrador intercepta as mensagens DHCP ACK, que contm as informaes necessrias para um controle mnimo como endereo IP, endereo MAC e o tempo de aluguel do endereo IP. A nova mensagem sugerida a DHCP LEASEQUERY, que permite ao concentrador consultar os tempos de lease em uso por identificador, caso ocorra alguma perda de informaes no prprio concentrador. E como resposta da mensagem de DHCP LEASEQUERY, so sugeridas novas mensagens como DHCP LEASEQUERYACTIVE, DHCP LEASEQUERYUNASSIGNED e DHCP LEASEQUERYUNKNOWN. A mensagem DHCP LEASEQUERYACTIVE uma resposta ao DHCP LEASEQUERY que enviada pelo servidor DHCP informando que um endereo IP considerado ativo e vlido. O DHCP

LEASEQUERYUNASSIGNED para responder se um identificador no mais vlido. J o DHCP LEASEQUERYUNKNOWN informa que o identificador no existe.

A anlise do trabalho de Joshi et al (2008), mostra que estas novas mensagens DHCP permitem uma maior eficincia do controle do uso de endereos IP vlidos de uma rede TCP/IP.

3.4

Li et al

Li et al (2008) tratam sobre a verificao do endereo IP de origem com a finalidade de rotear apenas IPs vlidos na rede usando um protocolo de autenticao do endereo IP para ser aplicado nos roteadores.

O protocolo SAVE (Source Address Valid Enforcement) proposto para ser usado em roteadores permitindo que aprendam os endereos vlidos de cada direo do fluxo de dados, construindo tabelas de entrada de trfego que so constitudas pelos endereos IP de origem de cada interface do roteador. Com estas tabelas so aplicados filtros nas interfaces encaminhando apenas pacotes que tenham seus endereos citados nas

33

tabelas. O protocolo SAVE independente podendo operar com qualquer protocolo de roteamento dinmico.

Na anlise do trabalho de Li et al (2008), o uso de um protocolo que permita verificar e filtrar os pacotes vlidos, tendo como base para deciso o endereo IP de origem subsdio para um bom nvel de controle, mas alguns aspectos devem ser observados, como a sua utilizao em redes grandes ou AS (Autonomous Systems) de trnsito1, que exigiria uma alta utilizao de recursos dos elementos de rede para verificar os novos fluxos que passariam a trafegar pelos elementos de cada AS, como tambm em caso de convergncias de rede. Na internet, alm da preocupao com divulgaes de redes erradas, que geram a necessidade de filtros e listas de acesso, os administradores devero se preocupar tambm com a convergncia do protocolo sugerido pelos autores. Assim a aplicabilidade seria para pequenas redes, nunca para redes grandes e backbones com uma grande quantidade de elementos de rede.

Esta verificao, para se ter um melhor ganho, deve ser feita no ponto mais prximo da extremidade da rede, visando menor sobrecarga na utilizao da infraestrutura, como tambm uma diviso de carga nos controles de segurana. Ao aplicar controle no switch que os clientes so conectados, o trfego desnecessrio ignorado logo no acesso, no necessitando chegar at o roteador para a deciso de rote-lo ou no.

3.5

Sue et al

Os autores Shue et al (2009) descrevem a necessidade de proteo das informaes nas redes IPv4. Para isto sugerem uma melhoria no protocolo DHCP, atravs da utilizao de certificados para clientes e servidores DHCP. Com isto evitam-se problemas causados por servidores DHCP no oficiais, porque o certificado possibilita realizar a autenticao dos parceiros de comunicao. Assim os clientes sempre

AS de transito a conexo entre um outro AS e os demais da internet. Geralmente esta funo de transito feita por grandes operadores nacionais e internacionais.

34

enviam a mensagem DHCPDISCOVER com algumas informaes a mais, como por exemplo a chave do domnio que todas as estaes tem pr-configuradas.

A anlise do trabalho de Sue et al (2009) mostra a criticidade do protocolo DHCP e a preocupao com o correto funcionamento, que garante o bom funcionamento das redes locais TCP/IP. Alguns pontos a serem observados so a necessidade de alteraes nos protocolos atuais, uma carga maior nas estaes de trabalho na obteno de endereos IP e, ainda, a dificuldade na utilizao de novos clientes de rede, pois precisariam da instalao do certificado. Mas para o correto funcionamento, o cliente deve estar usando o protocolo DHCP. Esta proposta no elimina o problema de conflito de IP causado por uma configurao errada.

3.6

Dai et Chiang

Dai e Chiang (2007) cita que uma das funes do servidor DHCP evitar a utilizao de endereos IP duplicados. Porm, o usurio pode no utilizar o servidor DHCP e configurar o endereo IP de forma manual. Para garantir um controle maior do ambiente de rede, todos os pacotes destes usurios, chamados pelos autores de ilegais, deveriam ser bloqueados garantindo o desempenho do ambiente e tambm seu controle. O mtodo sugerido pelos autores usa a tabela ARP do gateway da sub-rede2 e o banco de dados do servidor DHCP. O servidor DHCP deve comparar ambas informaes e assim gerar as inconsistncias que so notificadas aos elementos de rede, roteador ou switch, pelo prprio servidor DHCP. O bloqueio de trfego dos usurios ilegais realizado pelo roteador ou switch usando regras de filtragem.

A anlise do trabalho de Da e Chiang mostra a preocupao com o uso de endereos IP fixos. Alguns pontos devem ser observados como a comunicao entre o servidor
2

Neste trabalho o termo sub-rede refere-se unidade de rede, que aplicada a uma nica rede local virtual, possibilitando a separao dos domnios de broadcast.

35

DHCP e os roteadores que so gateways de cada sub-rede, sendo necessrio um protocolo para esta comunicao. Outro item importante o bloqueio poder ser feito no roteador, permitindo o uso de um endereo IP fixo podendo causar indisponibilidade com algum cliente se acontecer um conflito de endereo IP. Sendo o servidor DHCP o responsvel por atualizar todas as listas de acesso, dependendo do tamanho da rede, o servidor poder ficar sobrecarregado ao fazer tantas verificaes entre tabelas ARP e a sua prpria tabela, alm de ter a responsabilidade de notificar os switches e roteadores para realizar os devidos filtros. Desta maneira o tempo entre a deteco de uma alterao e o efetivo bloqueio pode permitir que acontea um conflito de endereo IP no ambiente de rede.

3.7

Wang et Lee

Wang e Lee (2002) citam que a segurana continua um dos maiores problemas das redes. Diversos problemas externos, como ataques DDOS (Distributed Deny of Service) e problemas internos como conflitos de endereo IP podem trazer indisponibilidade para o ambiente de rede. Quando o protocolo DHCP usado por estas redes para configurao automtica do endereamento das estaes, traz como fragilidade a falta de exigncia de que os clientes da rede devam utilizar o protocolo DHCP para ter acesso a rede. Assim um cliente pode acidentalmente ou propositalmente configurar um endereo IP que j esteja em uso por outro cliente DHCP.

A sugesto dos autores o uso da base de dados do servidor DHCP, que contm todos os leases de endereos IP atribudos, para a gerao de regras de filtragem a serem aplicadas nos switches de rede local. Somente endereos MAC e IP que constem na tabela de lease do servidor DHCP, tero o trfego liberado nos switches. Esta traduo feita com um programa que executado junto ao servidor DHCP.

A anlise do trabalho de Wang e Lee (2002) evidencia um ponto central de processamento. Em ambientes de rede com uma grande quantidade de switches, pode trazer problemas ao servidor DHCP, pois dependendo da quantidade de leases gerados

36

em um determinado perodo de tempo, este servidor poder sofrer problemas de disponibilidade ou ainda atrasando as atualizaes nos switches, permitindo assim indisponibilidades para outros clientes.

3.8

Boudjit et al

Nas redes sem fio, chamadas MANET (Mobile ad hoc network), os autores Boudjit et al (2007) citam as dificuldades de atribuio automtica de IPs nestas redes, se comparadas s redes locais cabeadas. So indicados como problema a dificuldade de se usar mecanismos que atribuam automaticamente endereos IP neste tipo de rede, e a inviabilidade de se ter um nico servidor DHCP para atendimento de todo o ambiente de rede. Todas estas dificuldades esto relacionadas ao tamanho das redes e a instabilidade dos enlaces, instabilidade das conexes e mobilidade. Para resolver as dificuldades apontadas descrita uma soluo para se detectar conflitos de endereos IP, usando um algoritmo de deteco de endereos duplicados. Mas esta deteco ocorre somente no momento da atribuio de qualquer endereo IP por qualquer servidor DHCP.

A anlise do trabalho de Boudjit et al (2007) aponta como maior problema o conflito de endereo IP, trazendo indisponibilidade de acesso do cliente rede. Caso clientes alterem seus endereos IP aps estes serem atribudos por um servidor DHCP, o problema persistir e no ser detectado pelo mecanismo proposto, porque a verificao de duplicidade de endereo IP ocorre somente na atribuio do endereo IP.

3.9

Yang et Mi

Segundo Yang et Mi (2010), o uso do protocolo DHCP traz benefcios para o administrador de rede, mas tambm problemas de segurana.

37

So relatadas falhas do protocolo DHCP como a permisso de qualquer servidor poder prover endereos IP. O ponto importante do trabalho a indicao de que a maior causa dos ataques ao protocolo DHCP a falta de autenticao dos clientes e servidores. Os autores prope a utilizao de autenticao dos usurios atravs de uma senha com o endereo de hardware.

Na anlise do trabalho de Yang et Mi (2010), em nenhum momento exigido o uso do protocolo DHCP para se ter acesso a rede, garantindo que o acesso a rede esteja seguro. Toda preocupao com a autenticao dos usurios feita, mas aps esta autenticao um usurio pode de forma proposital ou acidental mudar o endereo IP e causar uma indisponibilidade no ambiente de rede.

3.10 Zuquete Zuquete (2009) apresenta a necessidade de segurana nas redes locais e comunicaes ponto a ponto. Mas de nada adianta isto, se um conflito de endereo IP no permitir que esta conectividade ou transferncia seja estabelecida.

A proposta do autor uma arquitetura de segurana para redes locais, usando o protocolo 802.1x e chaves criando uma poltica de identificao de novos usurios e um servidor DHCP modificado, forando assim autenticao das mensagens DHCP. Esta autenticao acontece quando o cliente usa o servidor DHCP, recebe uma chave que trocada com o ambiente de rede e usada para autenticar a troca das mensagens do protocolo ARP.

Na anlise do trabalho de Zuqete (2009), o esquema garante o momento inicial da conexo de usurios na rede, mas aps este instante, um cliente poder alterar seu endereo IP e ocasionar assim indisponibilidade na conectividade deste e outros clientes da rede IP.

38

3.11 Brik et al Brik et al (2004) citam que pouco eficiente o conhecimento que os servidores DHCP tem dos endereos IP disponveis, e dizem que seria melhor que os servidores realizassem uma verificao com o envio de pacotes ICMP para realmente constatar se um endereo IP est disponvel antes da sua atribuio. Outro problema apontado a no deteco de problemas de conflitos de IP pelo baixo controle que existe.

Os autores sugerem o desenvolvimento de uma ferramenta para monitorar o uso dos endereos IP baseados em ICMP, ARP e DHCP, gerando um alarme em uma interface para o administrador, em situaes de violao das condies configuradas na ferramenta, e ainda sugerindo possveis correes.

A anlise do trabalho de Brik et al (2004) traz uma ferramenta que completamente passiva, a sugesto dos autores reativa, com apenas uma recomendao para a soluo de um possvel problema de conflito de endereo IP. Um conflito pode causar uma indisponibilidade no ambiente de rede sendo muito prejudicial para as mais diversas aplicaes.

3.12 Concluso

Foram analisados diversos trabalhos que tratam da gesto da atribuio de endereos IPv4, quanto de aspectos de segurana, desempenho e disponibilidade. Todos deixam clara a preocupao com a segurana nos ambientes de rede local, principalmente na conexo dos usurios s redes.

As propostas dos autores Wang et Lee (2002) e Dai et Chiang (2007) realizam o gerenciamento de atribuio de endereos IP baseados no servio DHCP. Ambos

39

trabalhos sugerem que o servidor DHCP seja responsvel pela gerao de regras de filtragem, comparando com os endereos em uso na rede ou somente na base de dados do servio DHCP e enviem estas informaes aos equipamentos de rede (switches e roteadores) para que sejam aplicados filtros que permitam apenas o trfego destes endereos IP ou MAC.

Mas estas solues oneram o servidor DHCP que o responsvel por todas as alteraes, atuando na tomada de deciso de quais regras de filtragem devem ser aplicadas nos roteadores e switches. Alm disto, o tempo de resposta em caso de violao no gerenciamento de atribuio de endereos IP pode no atender aos objetivos propostos que manter a segurana e disponibilidade dos ambientes de rede IP.

Ainda no trabalho de Dai et Chiang um ponto a ser observado o local da aplicao das regras de filtragem. Os autores escolhem os roteadores para esta finalidade. Com isto todo o ambiente de rede local fica desprotegido com relao ao gerenciamento da atribuio de endereos IP. Permitindo que um endereo IP seja duplicado, podendo at indisponibilizar toda a rede se o endereo IP configurado por um usurio seja o endereo IP do default gateway da rede.

Outros trabalhos, como Li et al, Shari et al e Zuquete, relatam a preocupao com a disponibilidade dos ambientes de rede, propondo melhorias na autenticao entre clientes e servidores DHCP. Estas solues podem ser usadas em conjunto com o gerenciamento da atribuio de endereos IP para melhor garantir a disponibilidade dos ambientes de rede.

Em nenhum destes trabalhos o ponto de tomada de deciso e o ponto de execuo das regras de filtragem esto nos elementos de rede, evitando pontos de gargalo no processamento das alteraes, quando uma quantidade excessiva de interaes entre clientes e o servidor DHCP necessria.

40

IMPLEMENTAES RELACIONADAS

Este captulo descreve algumas implementaes que no possuem representao na literatura acadmica. So analisadas as implementaes de mercado aqui nomeadas como implementao de mercado M1 e implementao de mercado M2. Alm disso, tambm descrita uma implementao prpria denominada Address Guard.

4.1

Descrio da implementao de mercado M1

A implementao de mercado M1, usada para garantir que clientes usem de forma obrigatria endereos fornecidos por um servidor DHCP, composta pela soma de outras duas funcionalidades, que so o DHCP snooping e o IP source guard. No existe uma funcionalidade especifica para gerenciamento da atribuio de endereos IP baseado nas mensagens DHCP.

O DHCP snooping inspeciona as portas clientes e permite apenas nas configuradas como confiveis, o envio de mensagens DHCP OFFER. Isto impede que um servidor DHCP clandestino possa atribuir endereos IP a um cliente. Alm deste filtro, tambm constri uma tabela com todas as atribuies feitas pelo servidor DHCP usando as mensagens DHCP trocadas entre cliente e servidor.

O IP source guard atua como uma ferramenta para evitar um problema de segurana chamado de IP spoofing, quando o cliente altera o endereo IP de origem dos pacotes para impedir ou dificultar o rastreamento da origem de acessos e outros incidentes de segurana. Com o uso de filtros, o IP source guard permite apenas que pacotes, com um determinado endereo IP, sejam encaminhados.

Com a soma das duas funcionalidades citadas (DHCP snooping e IP source guard), um switch consegue impedir que clientes de uma rede local TCP/IP usem endereos IP que no tenham sido atribudos por um servidor DHCP.

41

4.1.1 Resumo do mtodo O mtodo usado pela implementao de mercado M1 utiliza duas outras

funcionalidades com finalidades distintas: DHCP snooping e IP source guard.

No DHCP snooping, o switch mantm uma tabela com todos os IPs que foram atribudos pelo servidor DHCP para as estaes que esto conectadas ao switch. As mensagens usadas para montar a tabela do DHCP snooping so o DHCP ACK, NAK, RELEASE e DECLINE. As tabelas so geradas dependendo da configurao das portas, pois o DHCP snooping permite configurar como confivel e no confivel. As portas cuja configurao est como confivel tem permitido o trfego de mensagens DHCP que seriam enviadas por servidores, por exemplo, DHCP OFFER e DHCP ACK. J as portas configuradas como no confiveis tem o trfego das mensagens DHCP OFFER e DHCP ACK bloqueado. Assim os servidores DHCP devem ser conectados em portas configuradas como confiveis.

J o IP source guard faz uso da tabela do DHCP snooping para a aplicao das regras de filtragem de pacotes em cada porta do switch.

A proteo ocorre da seguinte forma: inicialmente todo o trfego bloqueado na porta, exceto as mensagens DHCP que so autorizadas pelo DHCP snooping. Quando um cliente recebe um endereo IP atribudo por um servidor DHCP, algumas informaes da mensagem DHCP ACK so utilizadas para configurar a tabela do DHCP snooping. Em seguida criada uma PACL (Port Access Control List) permitindo apenas o encaminhamento de pacotes cujo endereo IP de origem seja igual ao atribudo pelo servidor DHCP.

Ao ser alterado o endereo IP do cliente pelo servidor DHCP, a PACL alterada e ento reaplicada na porta em questo. Ao ser alterado o endereo IP, pelo usurio de forma manual, uma mensagem de DHCP RELEASE enviada por este cliente. Esta mensagem detectada pelo DHCP snooping que ento remove o endereo IP da

42

tabela do DHCP snooping. Essa remoo da tabela causa a execuo de uma PACL padro para bloquear todo o trfego IP da respectiva porta, exceto para mensagens DHCP.

Uma forma de burlar o controle seria a utilizao de um equipamento na prpria rede executando um servidor DHCP no oficial, liberando endereos, com mensagens DHCP ACK, no autorizados para estaes clientes. Estas mensagens seriam detectadas pelo DHCP snooping e teriam o trfego permitido na respectiva porta. Para impedir isso possvel definir para as portas que no so usadas por servidores DHCP uma configurao de no confivel.

4.1.2 Restries do mtodo A maior restrio do mtodo o fato de usar apenas a mensagem DHCP ACK para considerar como vlido um endereo IP teoricamente atribudo para um cliente.

Considerando uma topologia que tem o servidor DHCP conectado em um switch que no suporta GAEIP e as estaes ligadas em outros switches que implementem GAEIP, o controle no pode ser executado na porta de uplink, porque a configurao nesta tipo de porta deve ser do modo confivel. O DHCP snooping usa duas classificaes de porta: confivel e no confivel. No modo no confivel so bloqueadas todas as mensagens DHCP que seriam enviadas por um servidor como (DHCP OFFER e DHCP ACK). J o modo confivel no filtra qualquer tipo de mensagem DHCP.

Assim toda mensagem DHCP permitida na porta de uplink, no fazendo distino entre mensagens de um servidor DHCP oficial e mensagens de um possvel servidor DHCP clandestino. O fato do mtodo considerar somente a mensagem DHCP ACK, faz com que o contedo das mensagens DHCP ACK alimente a tabela do DHCP snooping, que responsvel pela liberao do trfego. Assim endereos IP fornecidos pelo servidor DHCP clandestino podem permitir que estaes contornem o controle do GAEIP.

43

4.1.3 Restries da implementao As restries da implementao de mercado M1 so :

No possvel usar com outras funcionalidades como PACL; No recomendado usar em portas trunk; No recomendado usar em portas com agregao de interfaces fsicas; Necessidade de manuteno de uma tabela contendo os endereos atribudos a cada porta, e o tempo para cada atribuio. Em caso de problema com esta tabela, ocasionar indisponibilidade no ambiente;

Suporta ate 48 IPs por porta, em sistemas operacionais novos. Anteriormente este limite era de 10; Se em um ambiente o tempo de lease for muito baixo, pode gerar uma carga maior no switch pois a tabela estar em constante alterao. Este aumento do uso dos recursos pode trazer impactos no desempenho do ambiente;

No caso de uma possvel implementao do servio DHCP para servidores, com lease muito alto, e em interfaces que sejam conectadas servidores usando virtualizao, este mecanismo pode no funcionar corretamente;

Nos switches L2 no existe a funcionalidade de IP source guard.

Os testes realizados com um switch desta implementao de mercado M1 mostraram que o objetivo de no permitir o acesso de clientes com IPs que no foram atribudos pelo servidor DHCP atingido com algumas restries, como o switch atuar na camada 3.

Isto obriga que, para aplicar esta funcionalidade, devero ser adquiridos switches mais caros e maiores, sem a utilizao plena das funcionalidades disponveis. Mesmo nos switches L3, ainda existem algumas restries de hardware e software.

As configuraes usadas no laboratrio para o teste do funcionamento o DHCP snooping com o IP source guard, como pode-se observar na figura 4.1

44

Figura 4.1 : Configurao usada na implementao de mercado M1 Fonte: Elaborado pelo autor (2010)

4.2

Descrio da implementao de mercado M2

A implementao de mercado M2 tambm composta por duas funcionalidades distintas: DHCP snooping e o IP source guard. O DHCP snooping armazena em uma tabela as informaes recebidas do servidor DHCP como o endereo MAC, a porta cujo cliente est conectado e a VLAN desta porta.

O IP source guard, que aplica filtros para restringir o trfego tendo como base os endereos IP e MAC relacionados na tabela do DHCP snooping.

4.2.1 Resumo do mtodo O mtodo usado pela implementao de mercado M2 similar ao mtodo usado pela implementao de mercado M1, que soma duas funcionalidades com funes distintas para evitar o uso de endereos falsos, mais conhecido como IP spoofing, e para evitar falsos servidores DHCP no ambiente de rede.

O mtodo conta com a busca e identificao das mensagens DHCP para alimentar a tabela da funcionalidade DHCP snooping. Esta tabela contm os endereos MAC, IP e

45

o tempo de lease em segundos. Com as informaes desta tabela a funcionalidade complementar, chamada IP source guard aplica filtros de regras de filtragem.

Somente a mensagem DHCP ACK utilizada para popular a tabela do DHCP snooping.

4.2.2 Restries do mtodo A restrio do mtodo o uso de somente a mensagem DHCP ACK para verificar se um cliente est usando um endereo IP fornecido pelo servidor DHCP. O problema da liberao do trfego causado pelo uso de mensagens DHCP oriundas de servidor DHCP clandestino, conforme descrito no captulo 4.1.2.

4.2.3 Restries da implementao A funcionalidade apresentada pela implementao de mercado M2 possui as seguintes restries de implementao:

No recomendada a aplicao desta funcionalidade em portas agregadas, como por exemplo o uso do IEEE 802.3ad ( Ethernet Channel); A criao de entradas estticas requer cuidados e traz problemas como a indisponibilidade do trfego de um ou mais clientes; No deve ser utilizada em portas de uplink.

4.3

Proposta Address Guard

Este trabalho apresenta uma proposta alternativa para gerenciamento da atribuio dos endereos IP baseados nas mensagens DHCP. A partir da proposta foi realizada uma implementao tipo prova de conceito que ser includa na anlise das implementaes realizadas neste trabalho.

46

4.3.1 Descrio tcnica A funcionalidade Address Guard, nome usado para a prova de conceito, voltada para switches (equipamentos tipo bridge) (IETF, 2004) para permitir somente o uso de endereos IP dinmicos nas portas cuja configurao estiver aplicada. Ao habilitar a funcionalidade em uma porta de acesso, o switch de rede local permitir o trfego de quadros somente aps a atribuio e uso de um endereo IP dinmico designado por um servidor DHCP.

Ao habilitar a funcionalidade em uma porta de uplink (conexo entre switch e outro elemento de rede que tenha mais de uma porta, como por exemplo outro switch ou um hub) ilustrada na figura 4.2, o trfego restrito somente aos destinatrios com endereos IP atribudos dinamicamente.

Figura 4.2 : Definies Trfegos e Portas Fonte: Elaborado pelo autor (2011)

47

Conforme a RFC 2131 (IETF, 1997), todos os clientes DHCP que sofrerem qualquer alterao nos parmetros de rede local, como uma reinicializao ou desconexo com a rede, devero revalidar ou solicitar novamente sua configurao ao servidor DHCP.

Ao fazer a verificao das mensagens DHCP REQUEST e ACK, o tempo de lease extrado da mensagem DHCP e usado para a determinao do tempo que este vlido e quando o filtro dever ser aplicado para bloquear o trfego, caso no ocorra nenhuma renovao.

O Address Guard tambm permite o uso de endereos IP fixos que podem ser usados em impressoras e outros equipamentos como scanners. Quando existir esta necessidade o endereo deste elemento ser inserido manualmente na regra de filtragem que permitir todo o trfego oriundo deste determinado endereo MAC e endereo IP.

4.3.2 Escopo O escopo da implementao restrito pilha TCP/IP e o protocolo IPv4.

4.3.3 Controle nas portas de acesso Nas portas de acesso, figura 4.4, ocorre a filtragem somente do trfego de entrada (no sentido de host para o switch), quando este trfego for autorizado.

A monitorao de mensagens DHCP ocorre sempre que a porta estiver encaminhando trfego. O mapa de estado da proposta, conforme figura 4.3, ilustra o funcionamento proposto para a porta de acesso.

48

Figura 4.3: Diagrama de estado para porta de acesso Fonte: Elaborado pelo autor (2010)

O mecanismo do Address Guard monitora a passagem das mensagens DHCP e, quando receber uma sequncia com as mensagens de DHCPREQUEST e DHCPACK, estando relacionadas a uma mesma estao, o trfego de pacotes ser liberado para esta porta. Caso o mecanismo no identifique esta comunicao, o filtro de quadros continuar aplicado, permitindo apenas o trfego de mensagens DHCP alm das mensagens para o endereo de broadcast.

Mesmo com o trfego liberado so permitidos apenas quadros na entrada da porta do switch que tenham o mesmo endereo fsico e endereo IP do solicitante do endereo IP ao servidor DHCP, alm do trfego de broadcast e multicast. Isto acontece com o uso de regras de filtragem. Mesmo com o trfego liberado, todas as mensagens DHCP so coletadas e analisadas. Na deteco das mensagens DHCP RELEASE e DHCP NACK, o filtro aplicado para bloquear trfego do endereo fsico.

49

O Address Guard bloqueia o trfego na porta em caso do lease expirado ou ainda na deteco da mensagem de DHCP RELEASE ou DHCP NACK. Este bloqueio impede que qualquer quadro ou pacote seja encaminhado se tiver respectivamente um determinado endereo MAC e um determinado endereo IP.

Figura 4.4: Diagrama conexo porta acesso Fonte: Elaborado pelo autor (2009)

Se uma interface permanecer ativa e com o trfego liberado, o Address Guard continuar em operao para o caso do usurio alterar a modalidade de configurao do endereamento para IP fixo, e garantir que ao trmino do tempo de lease do IP, o cliente faa uma nova requisio ao servidor DHCP. Nesta situao inspecionar outras mensagens como DHCPREQUEST, DHCP ACK e DHCPRELEASE que so utilizadas na renovao do endereo IP e quando encerrado o modo de operao DHCP na estao cliente, ou seja, quando configurado um IP fixo manualmente.

Para evitar que uma estao altere seu endereo IP de forma manual sem que ocorra o envio da mensagem DHCP RELEASE, o Address Guard usa uma tabela que contm os endereos IP, MAC e tambm o tempo de lease do endereo IP. Com a tabela o Address Guard sabe qual o tempo mximo de validade do endereo IP atribudo, o endereo IP atribudo estao conectada na porta em questo e tambm o endereo MAC da estao para o qual o endereo IP foi atribudo. Como o servidor DHCP atribuiu o endereo IP com um tempo de lease, este endereo no ser atribudo para outro cliente at que este tempo esteja encerrado. Assim h a garantia que no acontecer qualquer conflito de endereo IP.

50

Outra caracterstica do funcionamento da porta de acesso a remoo da permisso do trfego na regra de filtragem aplicada na porta. Este comportamento no interfere no funcionamento da rede porque quando um cliente restabelece sua conexo fsica com o switch, precisa fazer uma nova validao do endereo IP recebido previamente, usando para isto a mensagem DHCP REQUEST. Assim o servidor DHCP responde com a mensagem DHCP ACK.

4.3.4 Controle nas portas de uplink Na porta de uplink ilustrada na figura 4.6, ocorre a liberao de trfego dos quadros que tenham seus endereos atribudos por um servidor DHCP. O bloqueio do trfego tambm feito por endereo MAC e IP, da mesma forma das portas de acesso, descrito no captulo 4.3.3. O comportamento do Address Guard em portas de uplink mostrado na figura 4.5.

Figura 4.5: Diagrama de estado para porta uplink Fonte: Elaborado pelo autor (2010)

51

O Address Guard mantm o estado MAC bloqueado desde quando a porta comea a funcionar. Na deteco das mensagens DHCP REQUEST e DHCP ACK, estando estas mensagens relacionadas a um mesmo endereo MAC, o estado do endereo MAC e IP vai para o estado de MAC Autorizado. Neste estado o trfego liberado. O trfego voltar ao estado de MAC Bloqueado quando na monitorao das mensagens DHCP forem detectadas uma das mensagens DHCP NACK ou DHCP RELEASE; ou tambm quando o tempo de lease expirar.

Endereos IP fixos para elementos como servidores so suportados pelo Address Guard, que nestes casos, tem os respectivos endereos IP e endereos MAC inseridos na tabela da porta de uplink de forma manual.

A questo mais relevante nas portas de uplink est nas situaes de reiniciao dos switches, quando as tabelas usadas pelo Address Guard so perdidas, bloqueando todo o trfego. Outra preocupao na reiniciao das portas de uplink (que pode acontecer devido a uma falha no cabo de conexo ou na reiniciao do switch que est conectado na outra ponta da porta de uplink) no devendo descartar o contedo das tabelas de controle.

Estas preocupaes existem porque a atuao do Address Guard em portas de uplink deve ser habilitada quando o switch ou hub da outra ponta no suportar GAEIP. Assim, problemas nas permisses para encaminhamento do trfego podem impactar completamente no acesso dos usurios conectados nos equipamentos sem o Address Guard ou similar.

52

Figura 4.6: Diagrama conexo uplink Fonte: Elaborado pelo autor (2009)

Na tentativa de evitar o bloqueio dos pacotes nestas situaes, foram avaliadas duas possveis solues:

Novas mensagens DHCP; Armazenar em um arquivo a tabela do Address Guard.

O uso de novas mensagens, conforme proposto por Joshi et al (2009), para viabilizar uma consulta para saber se um endereo vlido ou no, gera uma complexidade muito grande pois alm de necessitar todo o desenvolvimento no protocolo DHCP, gera uma necessidade de desenvolvimento nos switches para o envio e recebimento de novas mensagens DHCP. Outro ponto importante dependncia da troca de mensagens entre o servidor DHCP para que o trfego de uma determinada estao seja liberado.

Para resolver os problemas apontados neste captulo, o Address Guard mantm a tabela com os endereos MAC, IP e tempo de lease de cada estao que est usando

53

um endereo IP fornecido pelo servidor DHCP. Isto feito armazenando todas estas informaes em um arquivo que por sua vez salvo na memria no voltil.

Este armazenamento na memria no impacta na operao do switch, porque seu tamanho no precisa ser muito grande, e tambm porque a escrita neste arquivo no precisa ser condicionada a nenhum outro processo do switch. O Address Guard salva as informaes dos endereos MAC, IP e tempo de lease periodicamente.

Com isso nas situaes de reiniciao do switch, a primeira tarefa do Address Guard carregar seu respectivo arquivo da memria no voltil.

Uma entrada s ser removida da tabela, quando o Address Guard detectar a passagem da mensagem DHCP RELEASE, ou quando o tempo de lease expirar.

4.3.5 Diferenas para outras implementaes O Address Guard tem algumas mudanas em relao as implementaes de mercado M1 e M2. A primeira mudana o uso de uma mensagem DHCP a mais para que um endereo possa ser considerado atribudo pelo servidor DHCP e consequentemente este trfego seja liberado. Este mensagem adicional o DHCP REQUEST. As implementaes de mercado M1 e M2 usam apenas o DHCP ACK, j o Address Guard usa as mensagens DHCP REQUEST e o DHCP ACK, existindo uma dependncia entre ambas para que o trfego de um determinado endereo IP seja liberado.

Outra alterao a realizao do controle nas portas de uplink, para atender outros elementos que no suportam GAEIP. As implementaes de mercado M1 e M2 armazenam as informaes dos endereos atribudos pelo servidor DHCP em uma memria voltil, independente se a porta de acesso ou de uplink. A implementao de mercado M2 informa que a funcionalidade para GAEIP no suportada em portas de uplink. O Address Guard salva as informaes em uma memria no voltil que permite seu funcionamento para portas de uplink. Esta restrio devida a uma possbilidade de

54

problema caso o switch com GAEIP seja reiniciado sem que o switch sem GAEIP seja reiniciado tambm. Nesta situao as estaes de clientes conectados no switch sem GAEIP teriam seu trfego e funcionamento interrompidos.

4.3.6 Restries da Implementao As restries da implementao do Address Guard esto relacionadas ao

funcionamento em determinadas topologias com equipamentos que suportam e no GAEIP.

Com uma topologia onde existem equipamentos que suportam e que no suportam GAEIP, a verificao para as estaes conectadas nos switches sem GAEIP feita na porta de uplink no switch com GAEIP.

O primeiro cenrio que demonstra uma restrio do Address Guard est na figura 4.7. Neste topologia so encontrados dois problemas. O primeiro problema est na conexo do servidor DHCP a um switch sem suporte a GAEIP. O segundo problema est na conexo entre dois switches sem GAEIP. O primeiro problema est relacionado a incapacidade do Address Guard proteger o ambiente contra servidores DHCP no autorizados, porque as conexes dos outros switches a este no podem ter o Address Guard habilitado. Assim no h qualquer controle de mensagens DHCP nestas conexes. O outro problema est na conexo entre dois switches sem GAEIP, que aumenta a abrangncia de um possvel problema de conflito de endereo IP, podendo afetar uma quantidade maior de clientes.

55

Figura 4.7: Restrio de topologia do Address Guard Cenrio 1 Fonte: Elaborado pelo autor (2011)

No segundo cenrio representado pela figura 4.8 o problema da conexo do servidor DHCP foi resolvido, mas ainda existem dois switches sem GAEIP conectados, que pode causar um impacto maior em um caso de conflito de IP. Quanto maior a quantidade de switches sem GAEIP conectados diretamente, maior pode ser o impacto em situaes de problema.

56

Figura 4.8: Restrio de topologia do Address Guard Cenrio 2 Fonte: Elaborado pelo autor (2011)

As restries de topologia do Address Guard so:

Servidor DHCP deve ser conectado em um switch com GAEIP Dois ou mais switches sem GAEIP nunca podem estar conectados diretamente. Entre eles deve haver um switch com GAEIP.

57

IMPLEMENTAO DO ADDRESS GUARD

Este captulo apresenta a implementao tipo prova de conceito com nome de Address Guard. Os componentes utilizados como hardware, software e scripts de configurao so citados e demonstrados.

5.1

Componentes de hardware e software utilizados

Para a implementao do Address Guard foi usado o sistema operacional Linux Ubuntu por ser um software aberto com grande quantidade de aplicativos e a facilidade de se criar scripts. Como o intuito da prova de conceito mostrar o conceito em funcionamento, os pontos citados foram fundamentais para a deciso de qual sistema operacional usar. Na estao que simula o funcionamento do switch, o Linux na distribuio Ubuntu foi instalado em uma estao com duas interfaces de rede. Estas duas interfaces foram colocadas em modo bridge, usando comandos apresentados na figura 5.1.

Figura 5.1: Script bridge portas Address Guard Fonte: Elaborado pelo autor (2010)

Para servidor DHCP foi usado um roteador Linksys, atribuindo apenas o range de 192.168.1.101 at o 192.168.1.139

58

A rede configurada foi 192.168.1.0, com a mscara 255.255.255.0, sendo o servidor DHCP com o 192.168.1.1

Para as estaes foi usado o sistema operacional Windows. Para a simulao da porta de uplink foi usado um hub permitindo o uso de mais de uma estao pela mesma porta.

Os pacotes usados na instalao foram:

Dhcp3-server: Servidor DHCP; Bridge-util: Bridge entre 2 ou mais interfaces de rede; Ebtables: Filtro de quadros; PHP: Linguagem de Programao.

5.2

Implementao

Com a finalidade de realizar uma prova de conceito sobre a funcionalidade proposta, nomeada de Address Guard, foi usado o PHP para a implementao, com dois mdulos principais: o mdulo de deteco e o mdulo de bloqueio.

5.2.1 Mecanismo de deteco O mecanismo de deteco foi divido na captura das mensagens e procura das mensagens desejadas nos pacotes capturados.

5.2.1.1 Captura das mensagens Para deteco das mensagens DHCP foi usado o tcpdump, conforme parmetros na figura 5.2, que uma ferramenta que permite a captura de pacotes de uma interface de rede. Sua aplicao acontece nas portas da estao que simula o funcionamento do switch, inspecionando todos os quadros recebidos e enviados nas interfaces, filtrando

59

apenas as mensagens UDP nas portas 67 e 68. Estas mensagens so ento encaminhadas para o arquivo de nome captura.

Figura 5.2: Script captura mensagens DHCP Fonte: Elaborado pelo autor (2010)

5.2.1.2 Procura das mensagens desejadas nos pacotes capturados Em paralelo executado o monit.php. Este script composto por um lao principal e suas funes. O lao principal executado a cada dez segundos, buscando o arquivo captura e verificando a quantidade de linhas. Se existir uma quantidade de linhas maior que o contador atual, realiza uma busca nestas linhas aplicando as funes request(), reply(), release() e nack().

Cada funo tem por objetivo verificar se as mensagens que interessam ao Address Guard, como DHCP REQUEST, ACK, RELEASE e NACK. Se alguma funo encontrar a respectiva mensagem, executar o mecanismo de bloqueio ou liberao do trfego.

Para garantir que o cliente est usando um endereo IP atribudo por um servidor DHCP, a liberao do trfego s acontece com a identificao das mensagens DHCP REQUEST e DHCP ACK, quando os endereos MAC de origem da mensagem DHCP REQUEST e endereo MAC de destino do DHCP ACK so os mesmos.

No momento da liberao o tempo de lease extrado das mensagens DHCP. Com esta informao o Address Guard soma o valor com o tempo do sistema, no caso do sistema operacional. Quando o valor deste contador for menor que do sistema, o mecanismo de bloqueio acionado.

60

Todos os valores so armazenados em um vetor, contendo o endereo MAC e o tempo de lease. Sendo criado um vetor para cada endereo IP detectado e atribudo pelo servidor DHCP.

O tempo de validade de um endereo IP calculado com a soma do tempo de lease extrado da mensagem DHCP em segundos com o tempo do sistema, chegando assim no tempo do sistema final, que caso no seja renovado, o respectivo endereo MAC e IP devem ser retirados da tabela que permite o trfego destes endereos. O nico prrequisito para o correto funcionamento o switch ter o horrio atualizado por um servidor de tempo.

A gerao do script seguiu todos os pontos citados no item 5.2.1.2, e apresentado no Apndice B contendo todas as linhas usadas no Address Guard para o GAEIP.

5.2.2 Mecanismo de bloqueio O bloqueio feito com o pacote ebtables. Este pacote possibilita a filtragem de quadros na camada 2 e tambm na camada 3. Alguns recursos desta ferramenta so usados como a possibilidade de filtrar quadros que no tenham um determinado endereo MAC e/ou endereo IP e no permitir seu encaminhamento.

So criados dois scripts em shell, chamados de libera_eth1 e bloqueia_eth1. Todas as interfaces ao serem ligadas, comeam com o bloqueia_eth1. Este permite apenas o encaminhamento de mensagens DHCP, nas portas UDP 67 e 68.

Caso as mensagens DHCP sejam identificadas, executado imediatamente o libera_eth1. Esta regra permite o trfego dos quadros que tenham como endereo de origem, o endereo MAC do cliente que solicitou e recebeu o endereo IP do servidor DHCP.

61

O contedo do script libera_eth1 foi inserido na funo reply, porque caso esta mensagem seja encontrada e associada com o request, o trfego deve ser liberado, mas somente para os endereos MAC e IP contidos dentro destas mensagens, e para isto devem ser coletadas algumas variveis para permitir a aplicao da regra de filtragem.

Se alguma mensagem DHCP RELEASE ou DHCP NACK for detectada na porta, o bloqueio executado imediatamente, executando novamente o bloqueia_eth1. O script para bloqueio do trfego demonstrado na figura 5.3 e para a liberao do trfego demonstrado na figura 5.4

Figura 5.3: Script bloqueio trfego Fonte: Elaborado pelo autor (2011)

Figura 5.4: Script liberao trfego Fonte: Elaborado pelo autor (2011)

Antes da aplicao de qualquer filtro o comando ebtables F, para que qualquer outra configurao que exista seja removida, evitando assim uma sobreposio de comandos que possa comprometer o funcionamento do Address Guard.

62

METODOLOGIA E CENRIOS DE TESTES

Este captulo descreve a metodologia utilizada nos testes de avaliao das implementaes para gerenciamento de atribuio de endereamento IPv4.

Para a realizao dos testes de avaliao, foram definidos quatro cenrios, cada um suportando escopos de operao distintos.

6.1

Descrio dos cenrios

Para realizar todos os experimentos necessrios, a metodologia dos testes utiliza quatros cenrios, cada um representando uma topologia tpica. O primeiro um cenrio simples onde uma estao conectada a um switch. No segundo cenrio um outro switch conectado para verificao do comportamento entre os elementos de rede, sendo que ambos switches suportam GAEIP. No terceiro cenrio os dois switches so mantidos, mas agora o switch onde o servidor DHCP no est conectado, no suporta GAEIP. O quarto e ltimo cenrio similar ao terceiro, mas agora o switch que no suporta GAEIP onde o servidor DHCP est conectado.

6.1.1 Cenrio A

6.1.1.1 Objetivo O objetivo do cenrio A testar o funcionamento bsico do sistema do GAEIP baseado na monitorao de mensagens DHCP. Este cenrio compreende a situao mais simples no qual existe somente um switch.

So usados para cada teste os switches das implementaes de mercado M1, M2, e a implementao tipo prova de conceito.

63

6.1.1.2 Descrio O cenrio A compreende a configurao apresentada na figura 6.1, com um switch, um servidor DHCP, uma estao cliente e um tap para duplicar o trfego da estao cliente para o sniffer. O servidor DHCP est configurado para atribuir endereos IP para clientes na faixa de 192.168.1.100/24 at 192.168.1.130/24.

Figura 6.1: Topologia do Cenrio A Fonte: Elaborado pelo autor (2011)

Este cenrio representa a situao mais simples de conectividade, que permite a realizao dos testes funcionais.

6.1.2 Cenrio B

6.1.2.1 Objetivo O objetivo deste cenrio verificar o funcionamento do GAEIP em sub-redes com mais de um switch, e todos suportando GAEIP.

6.1.2.2 Descrio

64

Neste cenrio todos os switches suportam a funcionalidade GAEIP. As configuraes de controle de endereo IP sero feitas somente nas portas de acesso. Como todos os switches suportam a funcionalidade GAEIP no necessrio habilitar configurao GAEIP na porta de uplink, como ilustrado na figura 6.2. Um teste para avaliar a resistncia contra servidor DHCP no autorizado tambm feito, sendo este servidor conectado no switch A. O problema do servidor DHCP no autorizado este enviar endereos IP sem que o cliente tenha solicitado, usando as mensagens ACK, causando problemas para o GAEIP baseado na monitorao de mensagens DHCP. Isto pode acontecer para que um cliente possa realizar um acesso indevido a um sistema, sem que possa ser rastreado, ou ainda podendo causar um conflito de IP.

Figura 6.2: Topologia do Cenrio B Fonte: Elaborado pelo autor (2011)

65

6.1.3 Cenrio C

6.1.3.1 Objetivo O objetivo deste cenrio testar o funcionamento do GAEIP em sub-redes com topologia de equipamentos de rede de camada 2 (hubs e switches) com e sem funcionalidade GAEIP.

Este cenrio representa uma possvel situao de ambiente de rede onde nem todos os switches so gerenciados, e tambm um ou mais switches podem no suportar o GAEIP.

6.1.3.2 Descrio Similar ao cenrio B, mas com a alterao no switch B que agora no suporta GAEIP. Alm disto, uma outra estao cliente conectada no switch A, conforme figura 6.3.

Assim a verificao dever ser feita na porta de conexo entre os switches, ou switch e hub. O escopo do servidor DHCP continua configurado como no cenrio A, que atribui IPs para clientes na faixa de 192.168.1.100/24 at 192.168.1.130/24.

A resistncia contra servidor DHCP no autorizado testada com este servidor conectado no switch B.

66

Figura 6.3: Topologia do Cenrio C Fonte: Elaborado pelo autor (2011)

O cenrio C contempla uma possvel topologia real onde existam switches heterogneos, sendo que alguns suportem GAEIP e outros no suportem GAEIP. Esta situao pode acontecer em diversos ambientes onde equipamentos novos so conectados a equipamentos mais antigos. Neste caso o controle deve ser feito na porta de uplink.

6.1.4 Cenrio D Este cenrio representa, da mesma forma que o cenrio C no item 6.1.3, uma possvel situao de ambiente de rede onde nem todos os switches so gerenciados, e tambm um ou mais switches podem no suportar o GAEIP. 6.1.4.1 Objetivo O objetivo do cenrio D verificar a resistncia contra servidor DHCP no autorizado em um ambiente onde o servidor DHCP est conectado em um switch que no suporta GAEIP baseado nas mensagens DHCP.

67

Na tentativa de burlar ou contornar a funcionalidade, uma mquina de forma no autorizada gera mensagens DHCP no verdadeiras.

Uma outra estao, diferente da estao cliente, fazendo uso de uma ferramenta de gerao de pacotes, simula a atribuio via DHCP de endereo IP para uma determinada porta. Com isto ser alterado o IP na estao para fixo, usando qualquer outro IP que fora enviado pelo trfego DHCP no oficial. A verificao do funcionamento feita com o envio de ICMP Request para o servidor DHCP.

6.1.4.2 Descrio Similar ao cenrio 2, mantendo uma estao que simula o funcionamento do cliente e um servidor DHCP.

Com a mesma quantidade de elementos do cenrio C, trocando apenas a posio fsica entre os dois switches, de acordo com a figura 6.4. O switch que suporta a funcionalidade agora usado para a conexo das estaes. O switch que no suporta a funcionalidade de gerenciamento da atribuio de endereos IP baseado nas mensagens DHCP, agora usado para conectar o servidor DHCP.

O escopo do servidor DHCP continua configurado como no cenrio A, que atribui IPs para clientes na faixa de 192.168.1.100/24 at 192.168.1.130/24.

68

Figura 6.4: Topologia do Cenrio D Fonte: Elaborado pelo autor (2011)

6.2

Metodologia dos testes

Os procedimentos de todos os testes necessitam de alguns passos prvios que sero apresentados em todos os testes como a conectividade entre todos os elementos. Os passos contemplados na conectividade entre todos os elementos so: Ligar todos os elementos, incluindo switches e servidor DHCP; Conectar o tap device e o sniffer; Realizar as conexes fsicas, desde que esta deva ser feita no andamento do teste. 6.2.1 Cenrio A O cenrio A possui os seguintes testes funcionais:

Conexo de um novo cliente via DHCP (quadro 6.1);

69

Conexo de um novo cliente utilizando IP fixo (quadro 6.2); Alterao do IP de dinmico para fixo (alterando e mantendo o mesmo IP) (quadro 6.3); Alterao do IP de dinmico para fixo com filtragem da mensagem DHCP Release (quadro 6.4); Renovao do aluguel do endereo IP (quadro 6.5); Alterao do IP de dinmico para fixo com filtragem da mensagem DHCP e com o tempo de aluguel do endereo IP expirado (quadro 6.6); Desconexo e reconexo do ponto de rede mesma mquina (quadro 6.7); Substituio da estao por outra na mesma porta (quadro 6.8); Reinicializao do cliente (quadro 6.9); Reinicializao do switch (quadro 6.10).

Quadro 6.1: Teste conexo de um novo cliente via DHCP.

70

Quadro 6.2: Teste conexo de um novo cliente utilizando IP fixo.

Quadro 6.3: Teste alterao do IP de dinmico para fixo.

Quadro 6.4: Teste alterao do IP de dinmico para fixo com filtragem da mensagem DHCP.

71

Quadro 6.5: Teste renovao do aluguel do endereo IP.

Quadro 6.6: Teste alterao do IP de dinmico para fixo com filtragem da mensagem DHCP Release e com o tempo de alugle expirado.

72

Quadro 6.7: Teste desconexo e reconexo do ponto de rede mesma mquina.

Quadro 6.8: Teste substituio da estao por outra na mesma porta.

73

Quadro 6.9: Teste reinicializao do cliente.

Quadro 6.10: Teste reinicializao do switch.

74

O cenrio A tambm apresenta o teste de carga, conforme quadro 6.11 e o teste de impacto na funcionalidade de lista de controle de acesso (quadro 6.12).
Quadro 6.11: Teste de carga.

75

Servidor DHCP 192.168.1.1 Sniffer

Gerador de trfego 192.168.1.102

Switch 192.168.1.200 Tap Device

Cliente e Gerador de trfego 192.168.1.101

Gerador Mensagens DHCP 192.168.1.103

Figura 6.5: Topologia do Cenrio 1 Teste de Carga Fonte: Elaborado pelo autor (2011)

Quadro 6.12: Teste impacto na funcionalidade de lista de controle de acesso.

76

6.2.2 Cenrio B O cenrio B traz dois testes sendo o primeiro da conexo de um novo cliente, conforme quadro 6.13 e um segundo teste para verificar a resistncia contra servidor DHCP no autorizado, no quadro 6.14.
Quadro 6.13: Teste conexo de um novo cliente Cenrio B.

Quadro 6.14: Teste resistncia contra servidor DHCP no autorizado Cenrio B.

77

6.2.3 Cenrio C Todos os testes citados devero ser realizados novamente, pois agora o cliente est conectado em um switch que no suporta GAEIP, conforme diagrama do item 6.1.3. Agora o comportamento da funcionalidade ser observado na porta de uplink, que faz a conexo entre os switches.

Conexo de um novo cliente em switch sem GAEIP (quadro 6.15); Alterao do IP de dinmico para fixo (alterando ou mantendo o mesmo IP) (quadro 6.16); Reinicializao da porta (desconexo e conexo) do cliente (quadro 6.17); Reinicializao da porta de conexo entre switches (quadro 6.18); Reinicializao do switch com GAEIP (quadro 6.19); Reinicializao do switch sem GAEIP (quadro 6.20); Impacto em outros protocolos (quadro 6.21); Resistncia contra servidor DHCP no autorizado para clientes no switch A (quadro 6.22); Resistncia contra servidor DHCP no autorizado para clientes no switch B (quadro 6.23)

78

Quadro 6.15: Teste conexo de um cliente no switch sem GAEIP.

Quadro 6.16: Teste alterao da configurao do IP de dinmico para fixo Cenrio C.

79

Quadro 6.17: Teste reinicializao da porta (desconexo e conexo) do cliente.

Quadro 6.18: Teste reinicializao da porta de uplink.

80

Quadro 6.19: Teste reinicializao do switch com GAEIP.

Quadro 6.20: Teste reinicializao do switch sem GAEIP.

81

Quadro 6.21: Teste impacto em outros protocolos.

Quadro 6.22: Teste resistncia contra servidor DHCP no autorizado para clientes conectados no switch A.

82

Quadro 6.23: Teste resistncia contra servidor DHCP no autorizado para clientes conectados no switch B.

6.2.4 Cenrio D O cenrio D mostra dois testes de resistncia contra servidor DHCP no autorizado, nos quadros 6.24 e 6.25, sendo respectivamente para clientes conectados no switch A e clientes conectados no switch B.
Quadro 6.24: Teste resistncia contra servidor DHCP no autorizado para clientes conectados no switch A.

83

Quadro 6.25: Teste resistncia contra servidor DHCP no autorizado para clientes conectados no switch B.

84

REALIZAO DOS TESTES E RESULTADOS

Neste captulo so apresentados os ambientes dos testes e resultados apresentados, seguindo a metodologia do captulo 5.

7.1

Equipamentos utilizados

Para os testes foram usados os seguintes equipamentos: Switch Cisco Catalyst 2950; Switch Cisco Catalyst 3750; Switch 3Com/HP 4210 verso 3.10; Hub Encore ESH-708; Tap Device NetOptics 10/100 CU Teeny Tap; Laptop Acer Extensa 4420; Laptop Lenovo R61; Laptop Acer Aspire One.

7.2

Execuo dos testes

Todos os testes seguiram a mesma metodologia para todos os fabricantes testados, e tambm para a prova de conceito.

O resultado dos testes est apresentado no quadro 7.1. Neste quadro o resultado sim indica que o comportamento esperado foi atingido e no quando o resultado esperado no foi atingido.

85

Quadro 7.1: Comparativo dos testes realizados.

7.3

Resultados relevantes

So apresentados e detalhados os resultados que se destacaram por no atender ao objetivo de garantir o gerenciamento da atribuio dos endereos IP baseados nas mensagens DHCP, e tambm os resultados que apesar de alcanar o objetivo se destacam pelo funcionamento.

86

7.3.1 Substituio da estao por outra na mesma porta No teste de substituio da estao por outra na mesma porta, a implementao de mercado M1 liberou o trfego normalmente aps a obteno do endereo IP de um servidor DHCP pela estao 1. Em seguida com a desconexo da estao 1 e conexo da estao 2, com o mesmo endereo IP da estao 1 configurado previamente, o trfego foi encaminhado, o que no era esperado.

Com o Address Guard e a implementao de mercado M2, a estao 2 no teve o trfego encaminhado.

7.3.2 Reinicializao do switch com GAEIP No teste de reinicializao do switch com GAEIP as implementaes de mercado M1 e M2, ao terem o switch reiniciado, no mantiveram a tabela de controle do DHCP snooping que impediu o encaminhamento do trfego aps o switch voltar ao funcionamento.

No teste com o Address Guard no ocorreu a interrupo do trfego entre as estaes e a rede, aps a reinicializao.

7.3.3 Resistncia contra servidor DHCP no autorizado O teste de resistncia contra servidor DHCP no autorizado foi feito nos cenrios B, C e D, conforme captulo 6. Esta repetio foi feita para analisar no detalhe a eficcia das implementaes de mercado e do Address Guard em algumas possveis topologias de rede. Sendo este um problema importante a ser avaliado.

87

Nos testes do cenrio C para clientes conectados no switch B e do cenrio D para clientes conectados no switch A, todas as implementaes testadas no obtiveram sucesso no controle porque as estaes e o servidor DHCP no autorizado esto conectados no switch sem GAEIP. Desta forma estas estaes clientes puderam usar qualquer endereo IP.

No teste do cenrio C para clientes conectados no switch A, todas as implementaes de mercado e o Address Guard obtiveram sucesso no controle, pois o servidor DHCP est conectado no switch com GAEIP e o servidor DHCP no autorizado est conectado no switch sem GAEIP. Como a porta de uplink no tem autorizao para encaminhar as mensagens DHCP OFFER e DHCP ACK, os endereos no conseguem ser atribudos pelo GAEIP executado nas implementaes de mercado e no Address Guard. Para as portas no confiveis, a porta UDP 68 (usada por servidores DHCP) bloqueada como porta de origem, permitindo que somente a porta UDP 67 (usada por clientes DHCP).

J no teste do cenrio D para clientes conectados no switch B, o servidor envia uma mensagem forjada DHCP ACK estao cliente, sem esta ter solicitado um endereo IP. Neste cenrio o servidor DHCP no autorizado est conectado em um switch sem GAEIP e todo o controle feito na porta de uplink do outro switch que suporta GAEIP. Nesse momento as implementaes de mercado M1 e M2 aceitaram esta resposta como de um servidor autorizado ou vlido habilitando a porta do switch para receber trfego com este endereo IP.

A prova de conceito Address Guard no cadastrou este endereo IP como vlido para uma estao ou porta, porque no detectou a mensagem DHCP REQUEST da estao solicitando ao servidor DHCP.

88

AVALIAO E COMPARAO DOS RESULTADOS

Neste captulo so avaliados e comparados os resultados dos testes realizados nas implementaes de mercado M1 e M2, e no Address Guard.

8.1

Testes do cenrio A

No cenrio A, somente um teste apresentou uma no conformidade: a substituio de uma estao por outra na mesma porta. Neste teste a implementao de mercado M1 alcanou parcialmente o controle necessrio, pois quando uma nova estao j com o endereo IP, obtido pela estao anterior, configurado de forma manual conectada ao switch tem seu trfego encaminhado normalmente, o que no era esperado, pois o switch deveria impedir o trfego desta estao nesta porta. No teste com a implementao de mercado M2 e com o Address Guard, o filtro feito pelo endereo IP e pelo endereo MAC, que assim no permitiu o funcionamento da nova estao cliente.

Todos os outros testes apresentaram resultado satisfatrio com o comportamento similar ao esperado, relacionados no captulo 6. Somente as estaes que obtiveram o endereo IP do servidor DHCP, tiveram acesso aos recursos da rede.

No cenrio A que contempla apenas um switch, sem conexes de uplink e outros elementos de rede, os resultados foram satisfatrios atendendo ao GAEIP ( gerenciamento de atribuio de endereos IP).

8.2

Testes do cenrio B

Os resultados obtidos no cenrio B, mostram que no necessrio aplicar o GAEIP em portas de uplink entre dois switches com GAEIP ativo em todas as portas de acesso. O uso do GAEIP em portas de uplink pode servir como um mecanismo adicional para

89

garantir o gerenciamento da atribuio dos endereos IP, que ser usado em caso de falha deste mecanismo j em execuo em outros switches.

No teste de resistncia contra servidor DHCP no autorizado, o controle realizado pois o servidor DHCP no autorizado est conectado no switch que suporta GAEIP. Assim as mensagens de servidor DHCP so filtradas na porta de acesso, impedindo que este envie mensagens que podem ser usadas pela funcionalidade GAEIP.

8.3

Testes do cenrio C

Apenas um teste deste cenrio no apresentou conformidade com o resultado esperado nas implementaes de mercado M1 e M2: a reinicializao do switch com GAEIP. Aps a reiniciao do switch, suas tabelas de controle do GAEIP foram perdidas, fazendo com que todo o trfego das estaes que estavam conectadas no switch sem GAEIP fossem bloqueados

Na implementao Address Guard a tabela associada s portas de uplink mantida em memria persistente.

Os testes de resistncia contra servidor DHCP no autorizado mostraram que, conforme exposto no captulo 4.3.6, os servidores DHCP devem ser conectados sempre em switches com GAEIP. Os resultados dos testes onde esta condio foi atendida apresentaram resposta satisfatria, mas quando o servidor DHCP no autorizado foi conectado a um switch sem GAEIP, nenhuma das implementaes incluindo a prova de conceito, o resultado no foi satisfatrio.

8.4

Testes do cenrio D

No cenrio D, o servidor DHCP estava conectado em um switch que no suportava o Address Guard, que por sua vez estava conectado a outro switch com o Address Guard

90

configurado. Ainda neste switch do servidor DHCP e sem o Address Guard, uma outra estao foi conectada simulando um DHCP no autorizado que enviou para diversos endereos MAC diversos endereos IP da mesma rede que estava em produo.

Nas implementaes de mercado M1 e M2, os endereos IP atribudos de forma ilegal foram cadastrados nos filtros aplicados nas portas dos clientes, permitindo que estas estaes pudessem alterar seus endereos IP e continuar tendo acesso a rede.

No Address Guard isto no aconteceu porque como a estao cliente no solicitou o endereo IP, este no foi permitido para o trfego.

Esta diferena de comportamento deve-se ao fato do Address Guard usar as mensagens DHCP ACK e REQUEST para inserir o endereo IP no filtro aplicado a porta, porque um endereo s pode ser recebido em uma estao cliente se o mesmo tiver sido solicitado a um servidor DHCP. J nas outras implementaes usada somente a mensagem DHCP ACK.

8.5

Vantagens e desvantagens das implementaes

Os assuntos relacionados preciso do controle, disponibilidade em situao de problema, armazenamento e impacto em outros protocolos, podem ser avaliados com a comparao dos resultados dos testes de todos os cenrios.

Em relao eficcia do GAEIP, a implementao de mercado M1 tem como pontos negativos a no verificao do endereo MAC e a utilizao de uma nica mensagem DHCP para fazer a verificao se uma estao usa ou no endereo IP fornecido por um servidor DHCP. A implementao de mercado M2 faz a verificao do MAC, mas ainda usa uma nica mensagem DHCP. J o Address Guard verifica tambm o MAC e usa alm da mensagem DHCP ACK, tambm a DHCP REQUEST, garantindo que uma estao s pode receber um IP se a mesma fez esta solicitao.

91

Considerando um problema de uma reiniciao do switch que suporte a funcionalidade, sendo o cenrio 3 como no captulo 6.1.3, somente o Address Guard consegue manter o ambiente funcionando. As implementaes de mercado M1 e M2 tem problemas de manter os estados de liberao de trfego realizados antes da reiniciao.

Em relao ao armazenamento, o Address Guard necessita que a tabela do controle GAEIP da porta de uplink seja armazenada em memria persistente.

Nenhuma das implementaes apresentaram impacto no protocolo Spanning-tree e na filtragem de pacotes, que foram usados como exemplo para verificar se haveria algum problema em outros protocolos e funcionalidades.

O quadro 8.1 compara as vantagens e desvantagens das implementaes de mercado M1, M2, e Address Guard. As vantagens so indicadas com uma seta para cima e as desvantagens com uma seta para baixo.
Quadro 8.1: Comparativo das implementaes.

Embora o Address Guard tenha a desvantagem de depender de uma memria persistente, esta desvantagem causada para mitigar um problema existente nas implementaes de mercado M1 e M2. Na comparao as vantagens do Address Guard superam as implementaes de mercado M1e M2. O tamanho das tabelas do Address Guard e da implementao de mercado M2 o mesmo, e maiores que o

92

tamanho da tabela da implementao de mercado M1. A principal diferena que no Address Guard o armazenamento deve ser feito em memria persistente.

A quantidade mxima de entradas na tabela GAEIP igual a quantidade de pontos existentes da sub-rede (levando em considerao switches e hubs), incluindo neste clculo switches virtuais de sistemas virtualizados.

A figura 8.1 ilustra a comparao das trs implementaes avaliadas nos critrios de eficcia do controle de GAEIP e no tamanho da tabela de controle para GAEIP. A implementao M1 tem um tamanho menor porque no armazena o endereo MAC. J as implementaes M2 e Address Guard tem o mesmo pois armazenam as mesmas informaes. A diferena est no tipo de armazenamento, que na implementao M2 feito em memria no persistente e no Address Guard em memria persistente, garantindo para o Address Guard uma maior eficcia no controle.

Figura 8.1: Comparativo Implementaes Fonte: Elaborado pelo autor (2011)

93

CONCLUSO

O gerenciamento de atribuio de endereos IP (GAEIP) baseado na monitorao das mensagens DHCP uma das alternativas para se manter a disponibilidade dos ambientes de rede de acesso de usurios , pois evita o conflito de IP, alm de oferecer rastreabilidade de endereos IP.

O objetivo deste trabalho foi de avaliar algumas implementaes de GAEIP. O escopo do trabalho foram as redes locais TCP/IP, baseadas nos protocolos Ethernet e IP verso 4.

Foram selecionadas duas implementaes de mercado para avaliao do GAEIP atravs da monitorao das mensagens DHCP. Embora estas implementaes usem a juno de duas funcionalidades para suportar o GAEIP (DHCP snooping e IP source guard), este resultado alcanado com algumas restries de implementao e do mtodo usado. Como no existe uma funcionalidade especificamente para monitorar as mensagens DHCP e gerenciar os IPs atribudos, algumas situaes propositais ou no, podem trazer problemas de disponibilidade ou ainda de perda de rastreabilidade.

Para auxiliar nas analises, foi realizada uma implementao tipo prova de conceito. O Address Guard foi proposto no somente para facilitar a configurao nos switches, como tambm para testar outras alternativas de implementao do GAEIP.

As anlises foram realizadas sobre 4 cenrios, seguindo uma metodologia de testes.

Os resultados mostram que o GAEIP eficaz quando todos os equipamentos de nvel 2 suprtam GAEIP. Porm quando existem equipamentos de rede de nvel 2 com e sem GAEIP, dependendo da topologia, da localizao do servidor DHCP e da estao cliente o controle do GAEIP limitado, possibilitando a configurao manual de

94

endereo IP, a insero de servidor DHCP no autorizado entre outros problemas, infelizmente comprometendo toda a sub-rede, pois possibilita a ocorrncia de conflito de IP. A implementao Address Guard atravs da monitorao de mais uma mensagem DHCP, mitiga o problema em uma determinada situao, mas no elimina o problema.

Os testes com as duas implementaes de mercado apresentaram um problema quando o switch com GAEIP renicializado. O trfego das estaes clientes, que estavam conectadas pela porta de uplink do switch com GAEIP, no foi restabelecido aps o switch voltar ao funcionamento normal. J com a implementao Address Guard isto no ocorreu pois mesmo com a reinicializao do switch, todas as informaes da tabela com endereos IP e tempos de aluguel armazenada em uma memria no voltil, que quando o switch volta ao funcionamento normal, estas informaes so recuperadas e implementadas pelo switch. Com isto o trfego das estaes cliente restabelecido aps a reinicializao. Todavia este armazenamento gera uma maior necessidade de memria para armazenamento das informaes.

9.1

Contribuies

O trabalho contribui com a apresentao de alguns possveis problemas das implementaes de mercado M1 e M2, sendo teis para que administradores de rede tenham cincia que em algumas situaes o gerenciamento da atribuio de endereos IP baseado na monitorao de mensagens DHCP pode no ser completamente eficaz. Outra contribuio do trabalho a proposta de implementao que usa um mtodo diferente, chamada Address Guard. O Address Guard mostrou que pode resolver problemas de implementao e de mtodo apontados nas outras implementaes.

95

9.2

Trabalhos futuros

Com base nos estudos realizados no trabalho e os resultados coletados, tem-se como sugesto de novos trabalhos:

Adaptao

dos

Address

Guard

para

redes

wireless,

que

usam

roteamento/Nat/redes internas para acesso externo. Esta situao acontece com roteadores/APs wireless, que fazem NAT para permitir o acesso de diversos clientes, usando apenas um nico endereo IP. Talvez monitorando ao invs de mensagens DHCP algum outro tipo de mensagem que consiga distinguir que diversos acessos esto sendo feitos com o uso de um nico endereo IP;

Adequao do Address Guard para o IPv6, estuando o comportamento dos protocolos IPv6 e DHCPv6.

96

REFERNCIAS BOUDJIT, S.; ADJIH, C.; MUHLETHALER, P.; LAOUITI, A. Duplicate Address Detection and Autoconfiguration in OLSR. Journal of Universal Computer Science [S.I.], v.13, n.1, p.4-31, 2007.

BRIK, V.; STROIK, J.; BENERJEE, S. Debugging DHCP Performance, Sigcom Internet Measurement Conference.Itlia, out. 2004.

COMER, D. E. Interligao em Rede com TCP/IP. 5 ed. Rio de Janeiro: Editora Campus, 2006. 468p.

DAI, J.; CHIANG, L.; A New Method to Detect Abnormal IP Address on DHCP. TENCON 2007 2007 IEEE Region 10 Conference. Taiwan, nov. 2007.

DROMS, R.; LEMON, T. The DHCP Handbook. 2 ed. [S.l.]:Sams, 2002. 624p.

LI, J.; MIRKOVIC, J.; EHRENKRANZ, T.; WANG, M.; REIHER, P.; ZHANG, L.; Learning the valid incoming direction of IP packets. The International Journal of Computer and Telecommunications Networking [S.l.], v.52, n.2, p.399-417, 2008.

GROCHLA, K.; BUGA, W.; DZIERSEGA, J.; PACYNA, P.; SEMAN, A. Autoconfiguration procedures for multiradio wireless mesh networks based on DHCP protocol. World of Wireless, Mobile and Multimedia Networks & Workshops, 2009. WoWMoM 2009. IEEE International Symposium, ISBN 978-1-4244-4440-3 , 2009.

JOSHI, B.; KURAPATI, P.; RAO, D.T.V.R. Spoofing Challenges Faced by Broadband Access Concentrators. Communication Systems and Networks and Workshops, 2009. COMSNETS 2009. First International, ISBN 978-1-4244-2912-7 , 2009.

97

SEIFERT, R. The Switch Book: The Complete Guide to LAN Switching Technology. 1ed. [S.l.]: Wiley, 2000. 720p.

SHAHRI, A.F.; SMITH D.G.; IRVINE J.M. A Secure Network Access Protocol (SNAP). Frana: Proceedings of the Eighth IEEE International Symposium on Computers and Communication (ISCC03), ISBN 978-3-540-25338-9, 2003.

SHUE, C.A.; KALAFUT, A.J.; GUPTA, M. A Unified Approach to Intra-Domain Security. Computational Science and Engineering, 2009. CSE '09. International Conference, ISBN: 978-1-4244-5334-4 , 2009.

THE INTERNACIONAL ENGINEERING TASK FORCE. Dynamic Host Configuration Protocol, 1997 [S.l.] . Disponvel em <http://www.ietf.org/rfc/rfc2131.txt>. Acesso em 17 fev. 2008.

THE INTERNACIONAL ENGINEERING TASK FORCE. Internet Protocol, 1981 [S.l.] . Disponvel em <http://www.ietf.org/rfc/rfc791.txt>. Acesso em 05 abr.2010.

THE INTERNACIONAL ENGINEERING TASK FORCE. A Standard for Transmission of IP Datagrams over Ethernet Networks, 1984 [S.I.]. Disponvel em < http://tools.ietf.org/html/rfc894>. Acesso em 04 abr.2010.

THE INSTITUTE OF ELECTRICAL AND ELETRONIC ENGINEERS. Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges, 2004 [S.l.] . Disponvel em < http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&isnumber=29062&arnumber=1309630 &punumber=9155>. Acesso em 23 mar. 2008.

98

YANG,Y.; MI,J. Design of DHCP protocol based on access control and SAKA encryption algorithm. 2010 2nd International Conference on Computer Engineering and Technology , ISDN 978-1-4244-6347-3 , 2010.

WANG, J.; LEE, T. Enhanced Intranet Management in a DHCP-Enabled Environment. 26th Annual International Computer Software and Applications Conference. Estados Unidos, 2002.

ZUQUETE, A. Protection of LAN-wide, PSP interactions: a holistic approach. International Journal of Communication Networks and Distributed Systems Sicience [S.I.], v.3, n.4, 2009.

99

REFERNCIAS COMPLEMENTARES

CISCO SYSTEMS. How LAN Switches Works, 2007 [S.l.]. Disponvel em < http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a00800a7af 3.shtml>. Acesso em 16 fev. 2008.

CISCO SYSTEMS. Configuring DHCP Snooping and IP Sourge Guard, 2009 [S.I.]. Disponvel em < http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/8.x/configuration/guid e/dhcp.html>. Acesso em 04 abr. 2010.

CISCO SYSTEMS. Cisco Network Admission Control (NAC) Executive Overview, 2009 [S.I.]. Disponvel em < http://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns171/ns466/net_impleme ntation_white_paper0900aecd80557152.html>. Acesso em 10 abr 2011

HP NETWORKS. How to configure DHCP Snooping on ProCurve switches, 2008 [S.I.]. Disponvel em <http://h40060.www4.hp.com/procurve/uk/en/pdfs/application-notes/ANS12_ProCurve-DHCP-snooping-final.pdf>. Acesso em 06 mar. 2011.

HUCABY, D. CCNP BCMSN Official Exam Certification Guide. 4 ed. Indianapolis: Cisco Press. 631p. SOARES, L.F.G.; LEMOS G.; COLCHER, S. Redes de Computadores das LANs, MANs e WANs s Redes ATM. 2 ed. Rio de Janeiro: Editora Campus. 740p.

100

APNDICE A O apndice A apresenta os resultados mais relevantes dos testes realizados:

Desconexo e reconexo do ponto de rede mquinas diferentes Resistncia contra servidor DHCP no autorizado Reinicializao do switch com GAEIP

A.1 - Teste de substituio da estao por outra na mesma porta

No teste de substituio da estao por outra na mesma porta, captulo 6.2.1 , a figura A.1 mostra o momento da desconexo do cabo da estao cliente 1, que com isto o comando ping parou de funcionar. Na implementao de mercado M1 a estao cliente 2, usando o mesmo endereo IP da estao 1 teve seu trfego permitido na porta, ilustrado na figura A.2. A figura A.3 mostra a troca de mensagens DHCP da estao 1 quando recebeu o endereo IP do servidor DHCP. A figura A.4 traz o comportamento do DHCP snooping e tambm a situao da porta quando a estao 1 foi desconectada.

Figura 0.1: Comportamento do comando ping na estao 1 Fonte: Elaborado pelo autor (2011)

101

Figura 0.2: Comportamento da estao 2 usando DHCP e usando o mesmo IP fixo da estao 1 Fonte: Elaborado pelo autor (2011)

Figura 0.3: Coleta do trfego pelo sniffer Fonte: Elaborado pelo autor (2011)

Figura 0.4: Comportamento da funcionalidade e estado da porta durante a desconexo e reconexo Fonte: Elaborado pelo autor (2011)

102

A.2 Resistncia contra servidor DHCP no autorizado

No teste de resistncia contra servidor DHCP no autorizado para o cenrio D, captulo 6.2.4, algumas etapas so ilustradas conforme figuras abaixo, relacionadas as implementao de mercado M1 e M2

Comportamento do comando ping na estao cliente (figura A.5); Programa para gerar mensagens DHCP no autorizadas (figura A.6); Envio das mensagens DHCP no autorizadas (figura A.7); Comportamento do ping na alterao do IP para o fixo liberado pelo servidor DHCP no autorizado (figura A.8); Comportamento da funcionalidade GAEIP na implementao de mercado M1 (figura A.9); Comportamento da funcionalidade GAEIP na implementao de mercado M2 (figura A.10); Alterao do IP de dinmico para fixo na estao cliente (figura A.11); Captura do trfego pelo sniffer, no recebimento das mensagens do servidor DHCP no autorizado (figura A.12).

Figura 0.5: Comportamento do comando ping na estao Fonte: Elaborado pelo autor (2011)

103

Figura 0.6: Tela da mensagem DHCP ACK gerada pelo servidor DHCP no autorizado Fonte: Elaborado pelo autor (2011)

Figura 0.7: Tela com o envio das mensagens DHCP no autorizadas Fonte: Elaborado pelo autor (2011)

104

Figura 0.8: Comportamento do comando ping na alterao dos endereos IP Fonte: Elaborado pelo autor (2011)

Figura 0.9: Comportamento da funcionalidade no switch da implementao de mercado M1 Fonte: Elaborado pelo autor (2011)

105

Figura 0.10: Comportamento da funcionalidade no switch da implementao de mercado M2 Fonte: Elaborado pelo autor (2011)

Figura 0.11: Configurao do cliente na alterao para IP fixo Fonte: Elaborado pelo autor (2011)

106

Figura 0.12: Captura de trfego pelo sniffer Fonte: Elaborado pelo autor (2011)

A.3 Reinicializao do switch com GAEIP No teste de reinicializao do switch com GAEIP, captulo 6.2.3, a figura A.13 mostra o funcionamento do comando ping com o Address Guard. J a figura A.14 ilustra o funcionamento do comando ping com as implementaes de mercado M1 e M2. A captura das mensagens DHCP no switch com a funcionalidade ilustrada na figura A.15.

107

Figura 0.13: Comportamento do comando ping para uma estao que est no switch sem GAEIP e para o servidor DHCP Fonte: Elaborado pelo autor (2011)

108

Figura 0.14: Comportamento do comando ping para uma estao que est no switch sem GAEIP e para o servidor DHCP, nas implementaes de mercado M1 e M2. Fonte: Elaborado pelo autor (2011)

Figura 0.15: Captura de trfego pelo sniffer no switch com GAEIP Fonte: Elaborado pelo autor (2011)

109

APNDICE B No apndice B apresentado o script usado pelo Address Guard em PHP.

<? error_reporting(E_ALL); ini_set('display_errors', '1'); $pol=10; $file='captura'; $novas_linhas=0; $linhas_processadas=0; $dhcp_req=null; function verifica_lease() { global $dhcp_reply; foreach ($dhcp_reply as $val1) foreach ($val1 as $val2) foreach ($val2 as $val3) { $agora=time(); echo "Valor arr $val3\r\n"; echo "Agora $agora\r\n"; //echo "n"; if ($val3 < $agora) echo "REMOVER DO IPTABLES MAC!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"; } reset ($dhcp_reply); } function verifica_request($linha) { global $dhcp_req; $msg1='Request from'; $pos = strstr($linha, $msg1); if ($pos === false) { //echo "n"; } else { $pos=substr($pos, 13, 17); $dhcp_req[]=$pos; //echo"\\r\\n Request from: $pos \\r\\n";\ } } function verifica_reply($linha) { global $dhcp_req; global $dhcp_reply; global $conteudo_processar;

110

global $j; $msg1='BOOTP/DHCP, Reply'; $pos = strstr($linha, $msg1); if ($pos === false) { //echo "n";\ } else { $pos = strstr($conteudo_processar[$j-1], ">"); $pos=substr($pos, 2, 17); if (in_array($pos, $dhcp_req)) { $ip = strstr($conteudo_processar[$j+1], "IP"); $ip = substr($ip, 3); $lease = strstr($conteudo_processar[$j+9], ":"); $lease = substr($lease, 2); $dhcp_reply[$pos][$ip][$lease]=time() + ($lease); echo "\r\n IP $ip com MAC $pos permitido!\r\n"; shell_exec('ebtables -F FORWARD'); shell_exec("ebtables -A FORWARD -j CONTINUE -s $pos"); shell_exec("ebtables -A FORWARD -j ACCEPT -p ipv4 --ip-source $ip"); shell_exec('ebtables -A FORWARD -i eth1 -j DROP'); print_r($pos); } } } function verifica_release ($linha) { global $dhcp_release; $msg1='Release'; $pos= strstr($linha, $msg1); if ($pos === false) { } else { //shell_exec ( 'ebtables -A FORWARD -i eth1 -j DROP'); shell_exec('./bloqueia_eth1.c'); } } function verifica_nack ($linha) { global $dhcp_nack; $msg1='Nack'; $pos= strstr($linha, $msg1); if ($pos === false) { } else { shell_exec('./bloqueia_eth1.c'); } } shell_exec('./bloqueia_eth1.c'); for($i=1; ;$i++) {

111

$total_linhas=shell_exec("wc -l $file | cut -d \" \" -f1"); $total_linhas=trim($total_linhas); // Entra aqui se novas linhas forem detectadas\ if ($total_linhas>$linhas_processadas) { $novas_linhas= ($total_linhas - $linhas_processadas); $conteudo_processar=shell_exec("tail -$novas_linhas $file"); $conteudo_processar=explode("\n", $conteudo_processar); //print_r($conteudo_processar);\ //Processar o conteudo aqui!!\ for($j=0; $j < $novas_linhas; $j++) { verifica_request($conteudo_processar[$j]); verifica_reply($conteudo_processar[$j]); verifica_release($conteudo_processar[$j]); verifica_nack($conteudo_processar[$j]); } } if (count($dhcp_reply) >=1) verifica_lease(); echo "---------------------------------------------------\r\n"; echo "Iteracao Numero: $i \r\n"; echo "Total de linhas do arquivo: $total_linhas \r\n"; echo "Quantidade de linhas ja processadas: $linhas_processadas \r\n"; echo "Quantidade de linhas novas: $novas_linhas \r\n"; //echo "$pos \r\n"; //echo "Conteudo das novas linhas: \\r\\n $conteudo_processar\\r\\n";\ print_r($dhcp_req); print_r($dhcp_reply); echo "---------------------------------------------------\r\n"; //Update de variaveis\ //Limpar pois o conteudo j\'e1 foi processado\ $conteudo_processar=''; //update das linhas j\'e1 processadas\ $linhas_processadas=$total_linhas; //novas linhas volta a ser zero\ $novas_linhas=0; //Espera $pol segundos a cada iteracao do laco\ sleep($pol); } ?>