18.11.2014 Views

Anais - Engenharia de Redes de Comunicação - UnB

Anais - Engenharia de Redes de Comunicação - UnB

Anais - Engenharia de Redes de Comunicação - UnB

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

4.2. Ataque contra ARP<br />

O objetivo do ataque contra ARP é sobrecarregar o tráfego na re<strong>de</strong>. Para isso, toma-se<br />

como referência o fato <strong>de</strong> que se um cliente acusa não possuir o en<strong>de</strong>reço MAC do cliente<br />

ao qual <strong>de</strong>seja enviar pacotes, a obtenção do mesmo ocorre com o envio <strong>de</strong> requisições<br />

ARP, que, por sua vez, são propagadas por todo o backbone da re<strong>de</strong>. O tráfego ARP é<br />

naturalmente elevado nesse protocolo, e, <strong>de</strong>pen<strong>de</strong>ndo da quantida<strong>de</strong> <strong>de</strong> nós no backbone,<br />

po<strong>de</strong> vir a ser um problema, uma vez que mesmo com apenas um roteador respon<strong>de</strong>ndo à<br />

requisição, todos os roteadores tomam conhecimento da mesma e promovem seu reencaminhamento.<br />

Devido ao fato <strong>de</strong> requisições ARP se propagarem por toda a re<strong>de</strong>, o ataque<br />

contra ARP se aproveita <strong>de</strong>sta característica para elevar o tráfego na re<strong>de</strong>.<br />

Neste tipo <strong>de</strong> ataque, o atacante <strong>de</strong>ve manter uma conexão com um cliente qualquer<br />

na re<strong>de</strong>, sendo este responsável por gerar o tráfego malicioso. A estratégia adotada<br />

pelo atacante para realizar este ataque é restaurar constantemente sua tabela ARP ao estado<br />

inicial, fazendo com que faltas do en<strong>de</strong>reço MAC do <strong>de</strong>stino sejam acusadas. Vale<br />

notar que o sobrecarregamento do tráfego não é causado por pacotes sem fundamento; as<br />

requisições são necessárias, porém, a ação maliciosa está em torná-las frequentes, comprometendo<br />

o tráfego da re<strong>de</strong> em geral.<br />

5. Avaliação<br />

Nesta seção, é apresentada a avaliação do protocolo PGMID sob ataques contra RM e<br />

ARP. O objetivo da análise consiste em medir o impacto <strong>de</strong>stes ataques em uma re<strong>de</strong> em<br />

malha utilizando o protocolo PGMID. A seção 5.1 <strong>de</strong>screve em <strong>de</strong>talhes o ambiente <strong>de</strong><br />

simulação, e a seção 5.2, por sua vez, apresenta os resultados das simulações.<br />

5.1. Ambiente <strong>de</strong> Simulação<br />

Para avaliar o <strong>de</strong>sempenho do protocolo PGMID, foi utilizado o simulador NS-2.34. A<br />

implementação do PGMID consi<strong>de</strong>ra que mensagens <strong>de</strong> sondagem são enviadas a cada<br />

2 s, o atraso máximo <strong>de</strong> resposta é <strong>de</strong> 10 ms e o número máximo <strong>de</strong> saltos das mensagens<br />

ARP é equivalente a 7. Como protocolo <strong>de</strong> roteamento híbrido adotou-se o protocolo<br />

Hybrid Routing Mesh Protocol (HWMP) [Boukerche and Zhang 2008] em modo reativo.<br />

A topologia da re<strong>de</strong> consiste <strong>de</strong> vinte roteadores mesh com raio <strong>de</strong> alcance <strong>de</strong><br />

250m, os quais são distribuídos uniformemente em gra<strong>de</strong> ao longo <strong>de</strong> uma área <strong>de</strong><br />

1300x1100m. O mo<strong>de</strong>lo <strong>de</strong> mobilida<strong>de</strong> Random Waypoint foi o adotado para promover<br />

a movimentação dos clientes mesh, os quais se movimentam com velocida<strong>de</strong> <strong>de</strong> até<br />

5m/s. O tráfego na re<strong>de</strong> é <strong>de</strong>finido com o auxílio do gerador <strong>de</strong> tráfego cbrgen, e consiste<br />

em fluxos <strong>de</strong> pacotes CBR <strong>de</strong> 521 bytes enviados a cada 20ms, sendo o número<br />

máximo <strong>de</strong> conexões correspon<strong>de</strong>nte ao número <strong>de</strong> clientes na simulação. Para todas<br />

as simulações foram garantidas pelo menos uma comunicação entre um cliente atacante<br />

e um não-atacante, e para cada comunicação <strong>de</strong>ssas, uma entre clientes não-atacantes é<br />

estabelecida. Para as simulações com ataque, a quantida<strong>de</strong> <strong>de</strong> atacantes <strong>de</strong>finida correspon<strong>de</strong><br />

a 10% do total <strong>de</strong> clientes da simulação, e suas ações maliciosas são <strong>de</strong>senca<strong>de</strong>adas<br />

a cada 10ms. Grupos <strong>de</strong> 4, 6 e 12 clientes foram consi<strong>de</strong>rados na avaliação.<br />

Três tipos <strong>de</strong> cenários foram analisados para cada grupo <strong>de</strong> 4, 6 e 12 clientes, os<br />

cenários com ataque contra ARP, os com ataque contra RM e os sem ataque. Para<br />

cada tipo <strong>de</strong> cenário foram realizadas 33 simulações, a fim <strong>de</strong> possibilitar o cálculo do<br />

335

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!