IPSEC: Evitando ataques NDP Spoofing

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.

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):

• CANTIP(Common Architecture for the Internet): protocolo de convergência para permitir a qualquer protocolo da camada de transporte ser executado sobre qualquer protocolo de camada de rede, criando um ambiente comum entre os protocolos da Internet;
• TUBA (TCP and UDP with Bigger Addresses): projeto com o objetivo de aumentar o espaço para endereçamento do IPv4 e torná-lo mais hierárquico, sem a necessidade de se alterar os protocolos da camada de transporte e aplicação. Pretendia uma migração simples e a longo prazo, baseada na atualização dos hosts e servidores DNS, entretanto, sem a necessidade de encapsulamento ou tradução de pacotes, ou mapeamento de endereços;
• SIPP(Simple Internet Protocol Plus): concebido para ser uma etapa evolutiva do IPv4, mas sem mudanças radicais e mantendo a interoperabilidade com a versão 4 do protocolo IP, fornecia uma plataforma para novas funcionalidades da Internet, aumentava o espaço para endereçamento de 32 bits para 64 bits e apresentava um nível maior de hierarquia.

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.

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.

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:

• Determinar o endereço MAC dos nós da rede;
• Encontrar roteadores vizinhos;
• Determinar prefixos e outras informações de configuração da rede;
• Detectar endereços duplicados;
• Determinar a acessibilidades dos roteadores;
• Fazer o redirecionamento de pacotes;
• Efetuar a autoconfiguração de endereços.

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

• RS (Router Solicitation): Mensagem enviada com o objetivo de descobrir a presença de um router IPv6 ativo no segmento de rede. Estas mensagens partem de uma estação de trabalho com a finalidade de receber as configurações necessárias de rede;
• RA (Router Advertisement): Mensagens deste tipo podem ser enviadas em duas situações: em resposta a uma solicitação RS, ou quando a mensagem está relacionada ao envio de anúncios de roteadores ativos. Mesmo que as solicitações RS sejam bloqueadas, o roteador pode “revelar sua existência” para as estações de trabalho por meio de RAs;
• NS (Neighbor Solicitation): Mensagem enviada por um determinado host com o objetivo de encontrar um endereço MAC correspondente a um endereço IPv6 e/ou para mapear a unicidade de um endereço, ou seja, se este endereço é único em uma rede. Mensagens deste tipo são semelhantes às trocas de mensagens ICMP do protocolo ARP do IPv4;
• NA (Neighbor Advertisement): Mensagens deste tipo são enviadas em resposta à solicitação NS, ou simplesmente para informar a mudança de endereço de determinado host;
• Redirect: Tipo das mensagens enviadas por roteadores para informar o endereço do próximo salto que deve ser usado para encaminhar pacotes.

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:

• Confiabilidade: somente o remetente e o destinatário devem entender o conteúdo da mensagem transmitida;
• Autenticação do ponto final: os pares envolvidos em uma conexão devem confirmar as suas respectivas identidades durante a comunicação;
• Integridade da mensagem: toda a informação que transita entre os pares durante uma conexão deve manter-se com todas as características originais estabelecidas pelo emissor da informação.

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.

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.

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.

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

• Próximo cabeçalho: identifica o tipo de playload transportado pelo datagrama IP. Este campo possui função semelhante à do campo “próximo cabeçalho” do cabeçalho IP;
• Tamanho da área de dados (playload): fornece o tamanho do cabeçalho AH e não o tamanho da área destinada aos dados;
• Security parameter index: desempenha o papel de identificador de uma conexão SA;
• Número da sequência: identifica de forma única cada um dos pacotes IP enviados por uma conexão SA. Caso haja uma retransmissão desse pacote, um novo número é gerado e anexado a este campo;
• Dados autenticados: campo de tamanho variável destinado ao resultado da aplicação de uma função de criptografia no datagrama IP.

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.

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

• Índice de parâmetro de segurança: desempenha o papel de identificador de uma conexão SA;
• Número de sequência: identifica de forma única cada um dos pacotes IP enviados por uma conexão SA;
• Preenchimento: campo utilizado quando algoritmos de criptografia exigem;
• Comprimento de preenchimento: define o número de bytes destinados ao campo Preenchimento;
• Próximo cabeçalho: similar ao AH, tem por finalidade identificar o tipo de playload transportado e atende ao mesmo objetivo do campo Next header do protocolo IP;
• Dados de autenticação: campo de tamanho variável destinado ao resultado da aplicação de uma função de criptografia no datagrama IP.

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.

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.

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.

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

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.

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.

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.

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.