IPSEC: Evitando ataques NDP Spoofing

Veja nesse artigo como interceptar e neutralizar os ataques NDP Spoofing em redes IPv6

Fique por dentro
Este artigo é útil porque irá demonstrar uma das soluções disponíveis para melhorar a proteção de redes IPv6 contra ataques de interceptação de dados, em específico o NDP Spoofing, através da implementação do módulo de segurança IPSEC em modo transporte. Para isso, criaremos um cenário de teste com o auxílio da virtualização e utilizarmos a ferramenta Wireshark para analisar os dados trafegados entre as máquinas virtuais.

A popularização da informática e a necessidade de comunicação em uma escala global promoveu o crescimento das requisições por endereços IPv4 levando, assim, ao término do mesmo. Em contrapartida, cria-se o protocolo IPv6 como alternativa para a falta de endereços e, também, para acompanhar o crescimento da Internet.

A rede mundial de computadores no mundo contemporâneo é multifuncional. Através dela é possível realizar transações bancárias, compras, entre outros serviços que exigem que os usuários disponibilizem suas informações pessoais e sigilosas. Em muitos casos estas informações tendem a serem alvos de inúmeros ataques, visando o comprometimento da privacidade, autenticidade e a integridade de um determinado serviço e das informações manipuladas por ele.

Como medida de proteção para estas informações o protocolo IPv6 traz o módulo de segurança IPSEC nativo em sua implementação. Este módulo fornece segurança à camada de rede e às camadas superiores, além de garantir a proteção dos pacotes IPs durante uma conexão e/ou transmissão de dados.

Dito isso, o objetivo deste artigo será a implementação desse módulo de segurança em modo transporte em uma LAN IPv6, visando promover a segurança necessária para a neutralização do ataque NDP Spoofing.

Protocolo IPv4 e seu esgotamento

O endereçamento IP é utilizado para “identificar” um determinado host conectado a uma rede de computadores. Essa identificação pode ser análoga ao endereço de uma residência, onde as ruas são representadas pelos cabos e as casas, representadas pelos computadores, possuem um número identificador próprio. Este número, por sua vez, tem por objetivo identificar qual a posição exata desta casa, em uma determinada rua. Caso seu endereço esteja incompleto ou incorreto não será possível efetuar a entrega de uma determinada correspondência. Portanto, no contexto da tecnologia da informação, este número identificador faz referência ao protocolo de endereçamento IP, cuja finalidade é identificar um determinado dispositivo conectado a uma rede.

O protocolo de endereçamento vigente, IPv4, possui seu cabeçalho de tamanho igual a 32 bits, o que permite cerca de 4 bilhões (2³²) de combinações de endereços disponíveis. A partir da década de 90 o estoque de endereços IPv4 disponíveis da IANA (ver BOX 1) veio em decréscimo até o ano de 2011, quando o montante chegou a zero, como demonstra a Figura 1.

BOX 1. IANA

Internet Assigned Numbers Authority (IANA), é a autoridade mundial responsável por ditar as regras utilizadas para a atribuição de endereços na Internet.

Figura 1. Gráfico que apresenta o estoque de endereços IPv4 da IANA – Fonte: Florentino, 2012, p.21.

Uma das causas para o esgotamento total dos endereços IPv4 disponíveis é dada em função da má distribuição dos blocos de endereços entre os países. Mais da metade destes blocos foram destinados aos EUA, onde o backbone da Internet foi criado e, a outra metade, dividido entre os demais. Além disto, entre os anos de 2005 e 2009 a Internet obteve um crescimento igual a 112%, segundo pesquisa divulgada pelo IBGE (Instituto Brasileiro de Geografia Estatística) e realizada pelo PNAD (Pesquisa Nacional por Amostra de Domicílio). Se analisarmos o crescimento da Internet sob o aspecto global, a Internet cresceu mais de 400% nos últimos anos.

Protocolo IPv6

Como solução para o problema já descrito, surge o protocolo de endereçamento IPv6. Este novo protocolo foi criado a partir de três projetos base, de acordo com o site IPv6 Brasil (2012):

Segundo o site IPv6 Brasil, as três propostas apresentavam problemas significativos. Portanto, a formação final para o novo protocolo baseou-se em uma versão revisada do SIPP, que passou a incorporar endereços de 128 bits, juntamente com os elementos de transição e autoconfiguração do TUBA, o endereçamento baseado no CIDR e os cabeçalhos de extensão. O CANTIP, por ser considerado muito incompleto, foi descartado.

Cabeçalho IPv6

Um datagrama IPv6 é formado por um cabeçalho de comprimento igual a 128 bits, o que possibilita cerca de 340 undecilhões (2128) de combinações de endereços disponíveis. Embora possua um comprimento de cabeçalho quatro vezes maior, o protocolo IPv6 é considerado mais “enxuto” e apresenta uma maior performance em relação ao protocolo IPv4. Na Figura 2 pode-se observar as alterações realizadas no cabeçalho IPv4 para a formação do cabeçalho IPv6.

Figura 2. Criação do Cabeçalho IPv6 a partir da remoção/alteração dos campos em destaque – Fonte: IPv6 Brasil, 2012.

De acordo com o site IPv6 Brasil (2012), a primeira remoção foi a do campo “Tamanho do Cabeçalho”, que tornou-se desnecessário uma vez que seu valor foi fixado. Por sua vez, os campos “Identificação”, “Flags”, “Deslocamento do Fragmento” e “Opções e Complementos” passaram a ter suas informações indicadas em cabeçalhos de extensão apropriados. Por fim, o campo “Soma de Verificação” foi descartado com o objetivo de deixar o protocolo mais eficiente, já que outras validações são realizadas pelos protocolos das camadas superiores da rede. Além disso, o campo “Identificador de Fluxo” foi adicionado para possibilitar o funcionamento de um mecanismo extra de suporte a QoS (Quality of Service). Mais detalhes sobre este campo e mecanismo serão apresentados nas próximas seções. Por fim, os campos “Versão”, “Endereço de Origem” e “Endereço de Destino” foram mantidos e apenas tiveram seus tamanhos alterados.

A Figura 3 ilustra o novo cabeçalho IPv6, formado a partir do cabeçalho do protocolo de endereçamento IPv4.

Figura 3. Cabeçalho IPv6 – Fonte: Florentino, 2012, p.27.

O protocolo Neighbor Discovery Protocol

O protocolo NDP consiste em um conjunto de mensagens ICMPv6 e processos que irão determinar a forma como os nós da rede irão se intercomunicar em uma vizinhança IPv6. O NDP é utilizado para:

Para que seja possível realizar estas operações, o NDP tem seu funcionamento embasado em cinco tipos de mensagens do ICMP, a saber:

Segurança de redes

No contexto da Tecnologia da Informação, a segurança da informação é definida pelo conjunto de ações e recursos utilizados para diminuir as vulnerabilidades em uma determinada rede e/ou sistemas computacionais.

O CGI.br (Comitê Gestor da Internet no Brasil) afirma que um computador e/ou sistema computacional é seguro quando o mesmo apresentar confiabilidade, integridade e disponibilidade aos usuários. Kurose e Ross (2010, p. 493) também defendem que para uma aplicação ser considerada segura, ela deve respeitar esses conceitos. Além disto, os autores complementam com os seguintes pontos:

Módulo de segurança IPSEC

Um dos principais problemas encontrados no protocolo IP está relacionado com a sua segurança. Devido a isto, os pacotes IPs podem ser facilmente capturados, interceptados, modificados e retransmitidos de forma transparente, ou seja, sem que o usuário perceba a ocorrência destes eventos. Na prática, os campos dos endereços IP de origem e destino podem ser alterados facilmente por qualquer programa malicioso, comprometendo a confiabilidade, integridade e/ou disponibilidade.

Como medida de proteção contra estes e outros problemas, o módulo de segurança IPSEC tem por objetivo promover a segurança à camada de rede e às camadas superiores da arquitetura de protocolos TCP/IP, fornecendo uma maior segurança aos pacotes IP durante a transmissão dos dados. O IPSEC faz uso de uma Security Association (AS – vide BOX 2) unidirecional para “negociar” as trocas de mensagens entre os pares envolvidos em uma conexão.

BOX 2. Security Association (SA)
Uma SA é uma “conexão” que viabiliza o tráfego de serviços seguros. A segurança dos serviços é garantida pela utilização dos protocolos de segurança AH e/ou ESP.

Para prover a segurança aos pacotes IP o módulo de segurança IPSEC pode ser implementado de duas formas distintas: transporte ou túnel, conforme ilustrado na Figura 4.

Figura 4. Representação dos modos de atuação do IPSEC – Fonte: CARISSIMI, ROCHOL

Pode-se perceber que na modalidade transporte, o cabeçalho IPSEC é inserido logo após o cabeçalho IP do pacote original. Já no modo túnel, todos os campos do datagrama IP são encapsulados, dando origem a um novo datagrama IP e, assim, fixados a um cabeçalho IPSEC.

O funcionamento básico do IPSEC é embasado na utilização de dois protocolos: AH (Authentication Header) e ESP (Encapsulating Security Payload). O protocolo AH fornece a integridade e autenticação necessárias aos dados. Já o protocolo ESP fornece os recursos para autenticação, integridade e privacidade.

Note que o ESP faz tudo o que o protocolo AH faz, com algumas funcionalidades a mais. Deste modo, porque ainda precisamos do AH? A resposta é simples: não precisamos. A implementação do módulo de segurança IPSEC com a utilização de ambos os protocolos é dada em função de que muitos serviços e produtos comerciais possuem a implementação do AH inclusa em seu código fonte, o que indica que ele permanecerá como parte da Internet até que esses produtos saiam de linha.

Authentication Header (AH)

O protocolo AH possui um cabeçalho composto por seis campos e, ao ser implementado, este cabeçalho é anexado entre o cabeçalho IP e a área de dados do pacote IP original, conforme ilustra a Figura 5.

Figura 5. Representação do Cabeçalho do protocolo AH – Fonte: CARISSIMI, ROCHOL e GRANVILLE, p.369, 2009.

Cada campo do cabeçalho AH possui as seguintes funções:

O protocolo AH fornece a integridade necessária aos datagramas IP transmitidos fazendo uso de uma assinatura digital. Para que seja garantida a integridade dos pacotes após a transmissão, o host de destino calcula o tamanho da assinatura digital recebida e compara o resultado deste cálculo com o tamanho da assinatura digital enviada. Caso o resultado deste cálculo seja igual ao resultado enviado, tem-se a comprovação de que o pacote não foi alterado durante a transmissão.

Encapsulating Security Playload (ESP)

Uma das características do protocolo AH é que ele não oferece a privacidade ao datagrama IP transportado. Em vista disto, o ESP foi criado para fornecer a privacidade necessária aos dados transmitidos, além de oferecer também os recursos de autenticação e integridade.

O ESP insere seu cabeçalho ao cabeçalho IP conforme ilustra a Figura 6.

Figura 6. Cabeçalho ESP – Fonte: Forouzan, p.1000, 2008

Os campos referentes ao cabeçalho do protocolo ESP possuem as seguintes funções:

Ataque NDP Spoofing

O NDP Spoofing é um ataque em redes IPv6 semelhante ao ARP Spoofing. O foco principal deste é a interceptação de informações confidenciais, posicionando-se no meio de uma conexão entre duas ou mais máquinas, caracterizando um ataque Man in the Middle. Para que isto ocorra o NDP Spoofing explora as falhas encontradas nas resoluções de endereços IPv6, realizadas pelo protocolo NDP, através do envio de mensagens Neighbor Advertisement (NA) falsas.

Referenciando o IPv4, o ARP Spoofing atua no nível da camada de enlace da arquitetura de protocolos TCP/IP, explorando as trocas de mensagens ARP Request e ARP Replay. Já em redes IPv6 o NDP Spoofing também age na camada de enlace da arquitetura de protocolos TCP/IP, mas explorando as falhas existentes nas mensagens ICMPv6 do protocolo NDP, Neighbor Solicitation (NS) e Neighbor Advertisement (NA), responsáveis pela tradução dos endereços IP.

O funcionamento do ataque NDP Spoofing é bastante simples. Através do envio de um bloco de consultas e/ou respostas falsas o atacante “envenena” a NDP Cache (ver BOX 3). Caso esta etapa seja concluída com êxito, o atacante conseguirá realizar a interceptação dos dados e/ou executar ataques de negação de serviço.

BOX 3. NDP Cache
Cada host em uma rede IPv6 possui uma tabela de endereços resolvidos, a NDP Cache. Esta tabela é utilizada para armazenar as traduções que são realizadas pelas trocas de mensagens NS e NA enviadas aos hosts integrantes de uma LAN a fim de “descobrir” um MAC a partir de um IPv6 qualquer.

A Figura 7 ilustra a ocorrência deste ataque em uma LAN, onde um atacante, representado pelo computador C, responde a uma NS emitida pelo host A com uma NS falsa. Caso este “envenenamento” seja bem sucedido, o atacante poderá capturar todo o tráfego entre as estações representadas pelas letras A e B.

Figura 7. Representação da ocorrência de um ataque NDP Spoofing em uma LAN - Fonte: Pilihanto, 2011, p.56

Mão na massa

Após a análise dos conceitos, está na hora de pô-los em prática. Assim, a partir de agora serão abordados o cenário para testes, as configurações e as ferramentas utilizadas para a execução e neutralização do ataque NDP Spoofing.

Cenário de teste

Para a realização dos testes utilizou-se a arquitetura cliente/servidor em um ambiente virtualizado. A arquitetura escolhida provê uma estrutura de aplicação distribuída de modo que, a partir de um nó central, ocorra a distribuição dos serviços para os demais nós pertencentes à rede. Já a utilização da virtualização tem por finalidade simular um ambiente de teste real composto por diversas máquinas com sistemas operacionais diferentes, o que promove uma maior viabilidade e praticidade para a realização dos testes.

Na Tabela 1 está representado o ambiente virtualizado composto por quatro máquinas, bem como seus respectivos endereços lógicos/físicos e suas configurações.

Máquina SO Memória ETH0 ETH1
debianSRV Debian 7 1024 MB * 2001:888:db8:1::a
debianCliente Debian 7 1024 MB 2001:888:db8:1::2000 *
debianAtacante Debian 7 1024 MB 2001:888:db8:1::1fc3 *
ubuntuCliente Ubuntu 13.10 1024 MB 2001:888:db8:1::1228 *
Tabela 1. Cenário do teste.

Já a Tabela 2 traz as relações de endereços físicos (MAC) das máquinas integrantes do ambiente virtual.

Máquina MAC ETH0 MAC ETH1
debianSRV 08:00:27:7f:7b:46 08:00:27:58:8b:39
debianAtacante 08:00:27:8e:49:87 *
debianCliente 08:00:27:bc:e8:9a *
ubuntuCliente 08:00:27:51:1c:3d *
Tabela 2. Relação de endereços MAC do ambiente de teste

Ferramentas utilizadas

Para a execução do ataque NDP Spoofing foi utilizada a ferramenta Parasite6, integrante do toolkit THC-IPv6, desenvolvida pela The Hacker Choice e instalada na máquina debianAtacante. Além desta, a ferramenta Wireshark, um sniffer de rede, foi utilizada para interceptar e registrar o tráfego dos dados obtidos pelo ataque, facilitando, assim, a análise de seu conteúdo.

Na máquina debianSRV foi instalado o serviço de FTP em sua configuração default, com a finalidade de teste para a captura de informações referentes à conexão entre os clientes e o servidor.

Para obter informações sobre a instalação e configuração da ferramenta de ataque, veja o endereço indicado na seção Links. Para mais informações sobre o Wireshark, leia o artigo “Wireshark: Analisando o tráfego de redes”, publicado na Infra Magazine 14.

Execução do ataque

Após a instalação e configuração da ferramenta de ataque, primeiramente é necessário a ativação do roteamento de pacotes na máquina debianAtacante e, posteriormente, dar início ao ataque, conforme a Listagem 1.

Listagem 1. Execução do ataque NDP Spoofing.

01 root@debianAtacante:~# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding 02 root@debianAtacante:~# parasite6 –RF eth0

De acordo com essa listagem, a linha 01 está relacionada à ativação do roteamento de pacotes na máquina debianAtacante, fazendo com que ela se torne, no momento do ataque, o nó central da rede, interceptando e redirecionando o tráfego local da rede de forma transparente. Na linha 02 damos início ao ataque. Paralelamente a esses comandos executou-se a ferramenta Wireshark na máquina debianAtacante, para auxiliar na interpretação dos pacotes interceptados pelo ataque, como mostra as Figuras 8 e 9.

Figura 8. Ataque parasite6 em execução
Figura 9. Pacote interceptado pelo ataque

A Figura 8 apresenta os resultados obtidos do ataque efetuado pela máquina debianAtacante, de endereço IP 2001:888:db8:1::1fc3.

No momento da conexão FTP entre as máquinas debianCliente (endereço IP 2001:888:db8:1::1d6e) e debianSRV (endereço IP 2001:888:db9:1::a), pode-se observar que o host debianAtacante torna-se o gateway da rede. A ocorrência deste evento está em destaque na Figura 8, onde podemos observar que, dentre as trocas de mensagens interceptadas, foi possível obter as informações referentes ao usuário e senha utilizados para conexão.

Já na Figura 9 observa-se a ocorrência do ataque NDP Spoofing com mais detalhes. É visto que os campos destination e source, representados pelos números 2 e 3, fazem referência ao endereço MAC da máquina debianAtacante. Já nos campos representados pelo número 4 tem-se os endereços IP das máquinas debianCliente e debianSRV, envolvidas na conexão FTP. No momento em que se inicia o ataque, a ferramenta Parasite6 anexa o endereço MAC da máquina debianAtacante ao campo destination. Desta forma a máquina debianAtacante torna-se o servidor da rede, fazendo com que todos os pacotes sejam redirecionados para si e, posteriormente, entregues ao seu real destino. Para a máquina ubuntuCliente, o ataque foi reexecutado e os mesmos resultados foram obtidos.

Neutralização do ataque

Para a neutralização do ataque será implementado o IPSEC em modo transporte. As configurações deste módulo de segurança se iniciam a partir da instalação do pacote IPsec Tools, um utilitário desenvolvido pela KAME Projects, e a criação das chaves de autenticação, que serão utilizadas pelos protocolos AH e ESP nas máquinas debianSRV, debianCliente e ubuntuCliente.

Para inserir o utilitário IPSEC o comando aptitude install ipsec-tools deve ser executado no terminal Linux de cada uma das máquinas. Para a criação das chaves de autenticação empregadas pelos protocolos AH e ESP, devemos executar o comando da Listagem 2, que irá retornar uma chave hexadecimal com 16 bytes de tamanho, utilizada pelo protocolo AH, e o comando da Listagem 3, que irá retornar uma chave hexadecimal com 24 bytes, utilizada pelo protocolo ESP. Assim como realizado com o comando para instalação do IPSEC, os comandos das Listagens 2 e 3 devem ser executados no terminal Linux de cada uma das máquinas de nosso cenário de teste.

Listagem 2. Criação da chave de autenticação AH.

root@debianSRV:~# dd if=/dev/random count=16 bs=1 | xxd –ps

Listagem 3. Criação da chave de autenticação ESP.

root@debianSRV:~# dd if=/dev/random count=24 bs=1 | xxd –ps

Com as chaves de autenticação geradas, elas devem ser incluídas no arquivo de configuração do IPSEC, o ipsec-tools.conf, localizado no diretório /etc das máquinas em que este aplicativo foi instalado. A Listagem 4 traz as diretivas de configuração do ipsec-tools.conf para a máquina debianSRV.

Listagem 4. Arquivo de configuração ipsec-tools.conf da máquina debianSRV.

01 ## Flush the SAD and SPD 02 flush; 03 spdflush; 04 05 ##IPSEC-TOLLS SERVIDOR## 06 07 ##CHAVE SERVIDOR## 08 add 2001:888:db8:1::a 2001:888:db8:1::2000 ah –x200 –A hmac-md5 09 0x927357fd1cf4941bs3742931bs374296d955bdd26; 10 add 2001:888:db8:1::a 2001:888:db8:1::2000 esp –x201 -E 3des-cbc 11 0xa53b9d6f14983585977dac92ed4131895a8a24db39334cee; 12 13 add 2001:888:db8:1::a 2001:888:db8:1::1228 ah –x400 -A hmac-md5 14 0x123ccb0145529690735e4459206afbac1; 15 add 2001:888:db8:1::a 2001:888:db8:1::1228 esp –x401 -E 3des-cbc 16 0x6c5ad3d6092c347b73ad3bbdffa5568c9d14345a8a501a23; 17 18 ##CHAVE CLIENTE DEBIAN## 19 add 2001:888:db8:1::2000 2001:888:db8:1::a ah 0x300 –A hmac-md5 20 0x2fcb44080e8d7f777491fa13c36f4544; 21 add 2001:888:db8:1::2000 2001:888:db8:1::a esp 0x301 –E 3des-cbc 22 0x55685548cdd7c0dc7d5d8279dcde60510234ff8fcd6006bc; 23 24 ##CHAVE CLIENTE UBUNTU## 25 add 2001:888:db8:1::1228 2001:888:db8:1::a ah 0x500 –A hmac-md5 26 0xb563a94f5654e73aaf753c9fbed70536; 27 add 2001:888:db8:1::a 2001:888:db8:1::1228 esp 0x501 –E 3des-cbc 28 0x689626051ea84897478dff22fc5eb82db943f60ce5672ff3; 29 30 ##POLITICAS DE SEGURANÇA DE SAIDA## 31 spdadd 2001:888:db8:1::a 2001:888:db8:1:2000 any –P out ipsec 32 esp/transport//require 33 ah/transport//require; 34 spdadd 2001:888:db8:1::a 2001:888:db8:1:1228 any –P out ipsec 35 esp/transport//require 36 ah/transport//require; 37 38 ##POLITICAS DE SEGURANÇA DE ENTRADA## 39 spdadd 2001:888:db8:1::2000 2001:888:db8:1:a any –P in ipsec 40 esp/transport//require 41 ah/transport//require; 42 spdadd 2001:888:db8:1::1228 2001:888:db8:1:a any –P in ipsec 43 esp/transport//require 44 ah/transport//require;

Os comandos flush e spdflush das linhas 2 e 3 são responsáveis pela remoção de todas e quaisquer entradas criadas e armazenadas anteriormente na base de dados SDP (Security Parameter Database) e utilizadas pelo IPSEC.

Nas linhas 8 e 10 são adicionados os endereços IPs das máquinas debianSRV e debianCliente, respectivamente, para que seja possível a conexão entre as mesmas. Já nas linhas 9 e 11 encontram-se as chaves AH e ESP. Ambas as chaves retornadas pelos comandos das Listagens 2 e 3 foram aqui anexadas e serão utilizadas para a conexão IPSEC entre as máquinas debianSRV e debianCliente. O caractere 0x presente no início de cada chave indica que as mesmas utilizam caracteres hexadecimais.

Nas linhas 13 e 15 ocorre a adição dos endereços IPs das máquinas debianSRV e ubuntuCliente. De modo semelhante ao parágrafo anterior, nas linhas 14 e 16 encontram-se as chaves AH e ESP. Vale ressaltar que para cada máquina adicionada pelo parâmetro add, é necessário a criação de uma nova chave.

A partir da linha 28 estão as regras de conexão para as conexões para entrada e saída de dados entre as máquinas envolvidas. Nas linhas 31, 34, 39 e 42 tem-se o comando spdadd que, primeiramente, irá liberar as conexões de saída (out) e entrada (in) de qualquer protocolo (any) entre os endereços IP de origem e destino. Nas linhas 32, 33, 35, 36, 40, 41, 43 e 44 esse mesmo comando aplica a utilização dos protocolos ESP e AH, respectivamente, para garantir a integridade e autenticidade da conexão host a host. Nas mesmas linhas, o parâmetro require determina que o uso da segurança IPSEC seja obrigatória nas trocas de pacotes.

Para simplificar o nosso exemplo, todos os arquivos de configurações (ipsec-tools.conf) das máquinas clientes possuem as mesmas diretivas de segurança, devendo-se apenas alterar a ordem dos endereços IPs referente às linhas 31, 34, 39 e 42.

Por fim, para que essas configurações surtam efeito, é necessário que elas sejam carregadas no SPD das máquinas debianSRV, debianCliente e ubuntuCliente através do comando setkey –f /etc/ipsec-tools.conf. Caso queira verificar se as configurações foram carregadas no SPD, o comando setkey –DP listará no terminal todas as diretivas de segurança armazenadas neste, como demonstra a Listagem 5.

Listagem 5. Lista de diretivas de segurança debianSRV carregadas no SPD.

01 root@debianSRV:~# setkey –DP 02 2001:888:db8:1::1d6e[any] 2001:888:db8:1::a[any] 255 03 fwd prio def ipsec 04 esp/transport//require 05 ah/transport//require 06 created: Nov 8 02:08:37 2013 lastused: 07 lifetime: 0(s) validtime: 0(s) 08 spid=450 seq=1 pid=3667 09 refcnt=1 10 2001:888:db8:1::1d6e[any] 2001:888:db8::1::a [any] 255 11 in prio def ipse 12 esp/transport//require 13 ah/transport//require 14 created: Nov 8 02:08:37 2013 lastused: Nov 8 02:14:09 2013 15 lifetime: 0(s) validtime: 0(s) 16 spid=440 seq=2 pid=3667 17 refcnt=1 18 2001:888:db8:1::a [any] 2001:888:db8::1::1d6e [any] 255 19 out prio def ipse 20 esp/transport//require 21 ah/transport//require 22 created: Nov 8 02:08:37 2013 lastused: Nov 8 02:14:35 2013 23 lifetime: 0(s) validtime: 0(s) 24 spid=433 seq=0 pid=3667 25 refcnt=1

Feito isso, com o intuito de verificar se a conexão IPSEC em modo transporte entre as máquinas debianSRV e debianCliente foi estabelecida, o teste de conectividade Ping6 foi executado, conforme ilustra a Figura 10.

Após a execução desse teste, pode-se constatar com o auxílio da ferramenta Wireshark a adição dos protocolos AH e ESP (em destaque na Figura 10) ao datagrama IP transmitido, o que comprova a implementação do módulo de segurança IPSEC.

Figura 10. Teste de conectividade após a implementação do módulo de segurança IPSEC

Reexecutando o ataque e os novos resultados

Após a implementação do módulo de segurança IPSEC em modo túnel, a ferramenta Wireshark foi reexecutada em paralelo ao ataque NDP Spoofing, assim como a conexão FTP das máquinas clientes com a servidora. Na Figura 11 pode-se observar que nenhuma mensagem referente às requisições FTP foi obtida pelo ataque NDP Spoofing, indicando que o módulo de segurança IPSEC correspondeu às expectativas.

Figura 11. Resultado da nova execução do ataque

Deste modo conclui-se que através de uma configuração simples e objetiva conseguiu-se atingir o objetivo proposto: a neutralização do ataque NPD Spoofing.

No decorrer da realização deste trabalho percebeu-se que uma das principais mudanças do protocolo IPv6 está no uso nativo do IPSEC. A adoção deste módulo visou prover a segurança necessária para neutralizar os ataques de interceptação de dados, como o NDP Spoofing, empregado no ambiente de teste, trazendo resultados satisfatórios.

Durante a realização dos testes verificou-se que o tráfego de dados em uma rede sem segurança é um grande risco, pois os mesmos podem ser interceptados por um invasor de forma transparente, o que compromete sua privacidade, integridade e autenticidade.

No entanto, através da utilização do IPSEC foi possível promover um aumento na segurança das conexões entre as máquinas integrantes no cenário, bloqueando qualquer tentativa de interceptação das informações por parte do atacante. Além disso, os testes mostraram que, ao ativar a segurança IPSEC, os hosts apenas respondem aos hosts que estão na sua lista de confiança, descartando automaticamente os desconhecidos. Com isso, o ataque MITM, em específico, o NDP Spoofing, não terá efeito.

Em suma, o método proposto para neutralização do ataque NDP Spoofing através do IPSEC em modo transporte mostrou-se viável. Com isso, a partir de uma configuração simples, é possível fornecer segurança à camada de rede e a todas as outras superiores, garantindo a autenticidade, integridade e privacidade necessárias aos datagramas IPs transmitidos.

Links
Livros
  • CARISSIMI, Alexandre da Silva; ROCHOL, Juergem; GRANVILLE, Lisandro Zambenedetti. Redes de computadores. Porto Alegre. Bookman, 2009.
  • KUROSE, James F; ROSS, Keith W. Redes de computadores e a Internet: uma abordagem top-down. 5. ed. São Paulo: Addison-Wesley, 2010.
  • MORIMOTO, Carlos Eduardo. Redes Guia Prático. Porto Alegre: Sul Editores, 2008.
  • SCRIMGER, Rob; LASALLE, Paul; PARIHAR, Mridula; GUPTA, Meeta. TCP/IP, a Bíblia. Rio de Janeiro: Elsevier, 2002.
  • FLORENTINO, Adilson Aparecido. IPv6 na Prática. São Paulo: Linux New Media Editora Ltda, 2012.
  • STALLINGS, William. Criptografia e segurança de redes. 4. ed. São Paulo: Pearson Prentice Hall, 2008.

Artigos relacionados