Os artigos refletem a opinião pessoal do autor, e não de seus empregadores.

quarta-feira, 18 de maio de 2011

Segurança em IPv6 - parte 3 de 4

Mas a implementação de segurança no IPv6 não significa que o problema da segurança de rede estará resolvido, ou que o nivel de risco na web irá baixar sensivelmente. Primeiro porque todo software possui vulnerabilidades, e o IPv6 não está excluido. Em segundo lugar não há uma única implementação e sim centenas ou milhares. Todos os equipamentos e sistemas operacionais que se conectam em rede deverão  implementá-lo e cada fabricante realizou ou está realizando seu próprio desenvolvimento. Mesmo que sejam a partir dos mesmos padrões publicados pelos RFCs cada software é único e sujeito a erros. Um bom exemplo foram as vulnerabilidades encontradas em implementações do ICMPv6, a nova versão do Internet Control Message Protocol, tanto em Windows como em Linux e Mac OS. A vulnerabilidade no Windows permite que um intruso obtenha controle total do alvo  enquanto no FreeBSD  e Mac OS  permite um ataque de denial of service. Outro ponto de preocupação é o suporte de um sistema ao IPv6 não significar que todo o conjunto de especificações do protocolo foram implementadas. A RFC 4191, por exemplo, especifica aperfeiçoamentos no sistema de roateamento que impedem que intrusos desorganizem o esquema de roteamento. Porém sua implementação é opcional. Em geral muitos fabricantes estão lançando seu suporte à IPv6 em fases, aproveitando-se do fato dos clientes somente exigirem as funcionalidades mais elementares. O planejamento terá que ir além de apenas considerar o frágil selo “IPv6 suportado”, e verificar se as funcionalidades necessárias estão ou não implementadas no dispositivo.

Há também problemas com a própria especificação do IPv6, que vem sofrendo atualizações e correções desde a primeira publicação. O caso mais notório é o chamado RH0, ou a funcionalidade de  Routing Header Type 0, desenhada para possibilitar que se especifique no cabeçalho multiplos endereços de nós de rede intermediários. A vulnerabilidade surge ao permitir que um mesmo endereço seja indicado diversas vezes, possibilitando a um hacker sobrecarregar roteadores até a completa exaustão de seus recursos, o que significa um denial of service. A vulnerabilidade é séria a ponto do IETF eliminar por completo a funcionalidade da especificação via a RFC 5095: Deprecation of Type 0 Routing Headers in IPv6 (Desaprovação dos Cabeçalhos de Roteamento Tipo 0).

Outro problema potencial advém de uma funcionalidade criada para facilitar consideravelmente a obtenção de credenciais de rede pelos hosts. Conforme especificado na RFC 4862, os hosts em uma rede IPv6 podem obter sua configuração automaticamente a partir de roteadores por conexão stateless, sem controle de estado da sessão, através do protocolo ICMPv6. A nova funcionalidade não requer configuração no host, servidores e configuração mínima no roteador, o responsável em fornecer o endereço de rede. Para redes que requerem maior controle está disponível a especificação de DHCPv6, entretanto este não exclui a configuração stateless, e ambos podem conviver em uma mesma rede. As implicações de segurança são imediatas, embora perfeitamente controláveis. No entanto uma rede mal configurada (e são muitas) estaria aberta para que um intruso, sem necessidade alguma de autenticação, obtivesse credenciais e se comunicasse. O risco existe também em redes IPv4 com DHCP, porém há mais capacidade de gerenciamento e controle. Há ainda a possibilidade de um ataque denial of service, previsto e documentado na RFC 3756.

Também não podemos esquecer que muitas das ameaças de hoje independem do meio de transporte da Internet e ocorrem no sistema operacional ou na aplicação. É o caso dos novos ataques que surgiram com a Web 2.0, mensagens de phishing e as redes bot, ameaça comum nos últimos anos.  Como essas redes são criadas a partir da infecção de milhares ou milhões de computadores por phising ou downloads involuntários, o meio de transporte não fará diferença. Além disso as vulnerabilidades atuais de rede, mesmo relacionadas ao IPv4, não deixarão de existir, pois não haverá uma migração imediata de um padrão para outro. Por muitos anos ambos irão conviver, com todas as vulnerabilidades que surgem de implementações complexas e novas, cujos riscos ainda não estão totalmente mapeados. Equipamentos de rede, servidores e estações de trabalho irão conviver com ambos por muito tempo via métodos de coexistência. Portanto em um momento inicial é até esperado o aumento de vulnerabilidades como resultado de erros de configuração.

Além das questões de vulnerabilidades e ameaças, há outro impacto imediato para administradores de segurança: a compatibilidade de seus dispositivos de proteção de rede, entre firewalls, sistemas de prevenção de intrusos, controle de conteúdo e outros. O perigo não é o de quebra da rede, já que como dissemos as empresas conviverão por muito tempo com ambos os protocolos, mas o de invasões através dos túneis que poderão ser criados para passar tráfego IPVv6 encapsulado em IPv4. O tunelamento é um método que permite que dois dispositivos ou redes IPv6 se conectam via uma rede IPv4 através de um tunel onde o IPv6 é encapsulado em pacotes IPv4. Um sistema de segurança de rede que não reconheça o tunelamento nem os protocolos IPv6 nele encapsulados não poderá detectar ataques ou conteúdo indesejado. Certamente esse será um problema menor já que os administradores de segurança poderão controlar facilmente a situação, porém é possivel que em redes mal configuradas usuários ou mesmo invasores possam habilitar serviços de tunelamento sem conhecimento dos gerentes de rede, e poderão trafegar conteúdo não autorizado ou ataques facilmente.

(continua)

Nenhum comentário:

Postar um comentário