Gerenciando seus Firewalls

A primeira vista a tarefa de gerenciar uma política de firewall não deveria ser das mais complicadas. A primeira lição para quem se inicia no tema não deixa de ser inspiradora para uma vida tranquila: bloqueie tudo e libere apenas o que tem que ser liberado. E realmente a tarefa não é complicada quando a empresa tem poucos dispositivos e poucas regras para gerenciar.  Essa situação no entanto muda quando uma dessas variáveis é alterada. Uma situação típica é quando a empresa precisa aderir à alguma norma regulatória do governo ou do mercado, como o PCI-DSS da indústria de pagamentos por cartão. Basta o diretor de segurança avisar ao administrador do firewall que ele precisa adequar a política de segurança a uma determinada regra que a coisa começa a complicar.

Em geral eu recomendo que uma empresa busque um produto complementar de administração de firewall quando ao menos uma das condições abaixo existe:

• Há muitos firewalls não isolados em funcionamento. Por não isolados quero dizer dispositivos que protegem diferentes segmentos da mesma rede, e portanto um usuário ou grupo pode ter acesso via mais do que um deles. É como se a empresa tivesse uma única e grande política distribuída entre diversos equipamentos;
• Há firewalls de diferentes fabricantes em operação, situação comum em fusões ou aquisições (sem contar é claro empresas de datacenter e gerenciamento de segurança, para os quais tais sistemas é quase um requerimento);
• Quando a política de segurança implementada é muito extensa e granular, fazendo com que mudanças de regras seja sempre uma tarefa complexa. Nesses ambientes encontramos facilmente regras conflitantes e muitas já inúteis, cujo único efeito prático é aumentar a carga de processamento do equipamento.
• Existe a necessidade se aderir a normas regulatórias que implicam em adequações nas regras de acesso a sistemas ou segmentos de rede.

Dúvida existencial

Em quase vinte anos de profissão em segurança da informação não consegui ainda entender porque os orçamentos e segurança são tão pequenos. Certamente é um problema conosco, profissionais da área,  mas para mim é ainda um mistério o que deve ser feito para mudar isso. Até hoje não entendo por que a mesma empresa que responde a uma pesquisa dizendo que "segurança é prioridade" compra o firewall (ou qualquer outro sistema de segurança) mais barato enquanto faz questão de comprar os switches e roteadores que entregam tudo o que é pedido pela área de redes, sendo muitas vezes o mais caro da concorrência. 
Por que mesmo empresas de grande porte aceitam firewalls grátis de seus fornecedores de rede? Elas aceitariam um switch de backbone grátis de seu fornecedor de segurança? Certamente não. Pois é...

Centro de Defesa Cibernética

Vale registrar a estruturação no Brasil do Centro de Defesa Cibernética (CDCiber) a cargo do Exército, além da ação continua pelo Gabinete de Segurança Institucional da Presidência da República em aperfeiçoar a segurança da informação do governo em geral. Sendo a guerra cibernética mito ou não, o Brasil precisa estar preparado para lidar com uma agressão vinda de fora ou de dentro do país, sejam ações juvenis como os ataques do meio desse ano ou vindas de grupos profissionais visando a Copa do Mundo ou Olimpíadas. Ver para crer nesse caso seria uma péssima opção. 

Como sua empresa compra segurança de rede?

Olá. Fiquei um longo período sem atualizar o blog, resultado de várias viagens, correria de compromissos de trabalho, etc e tal. Mas nunca é tarde para retomar, e justamente com um tema que foi recorrente nesse ano: RFPs para compra de equipamentos de segurança de redes mal escritas. O resultado é que nesses casos ou a empresa compra errado, mais ou menos do que realmente precisa.  

O gancho é uma pesquisa divulgada pela Crossbeam Systems e disponível no site da empresa.  Bastante original, o objetivo era entender como as empresas tratam as informações de desempenho e capacidade fornecidos pelos fabricantes de sistemas de next generation firewall (firewalls que integram outras funções como prevenção de intrusos), assim como se suas aquisições foram ou não bem-sucedidas nesse quesito. O resultado não me surpreendeu: a maior parte das empresas, inclusive as grandes corporações, não sabem como interpretar os dados de desempenho informados nos datasheets e muitas vezes erram na aquisição. No outro lado, poucos fabricantes se esforçam em detalhar a capacidade de seus produtos, ou fornecem dados que permitiriam às empresas entender o que estão comprando. Mas a culpa está dividida entre ambos, vendedores e compradores. Antes vale uma olhada nos resultados da pesquisa:

• 58% dos participantes não confiam nos dados de desempenho informados pelos fabricantes. No setor de telefonia móvel, o índice foi de 78%. No entanto, mesmo entre os que confiam nos fabricantes, 80% não acreditam nos dados publicados em datasheets.
• 90% responderam que sempre ou algumas vezes tiveram que fazer concessões em sua segurança para não afetar o desempenho dos produtos, e incríveis 81% afirmaram que tiveram que desabilitar funcionalidades de segurança em seus dispositivos de proteção para não comprometer o desempenho da rede.
• 63% afirmaram que foi necessário adquirir hardware adicional após a primeira aquisição porque os produtos não tiveram o desempenho esperado, tal qual informado nos datasheets.
• 43% não realizam testes nos equipamentos em condições reais.

Há muito o que analisar nesses resultados, mas o fato é que há uma desconexão grave entre ambos fabricantes e usuários quando o assunto é performance. O primeiro passo para sair desse dilema é compreender que as informações publicadas em datasheets, salvo quando informado em contrário, referem-se ao máximo de desempenho na melhor situação possível. Ou seja, informam praticamente a capacidade de transmissão de dados sem processamento real de segurança. Mas é importante dizer que isso não caracteriza má fé. É um critério, o mais fácil porém não o ideal para comparação, porque na hora de ajustar-se ao ambiente real das empresas cada produto irá responder de uma maneira, e alguns chegam a redução de até 90% de performance. Por outro lado essa abordagem é respaldada quando uma empresa publica RFP pedindo apenas “x Gbps de throughput” sem especificar mais nada. Essa é a origem de todos os problemas de aquisição mal sucedida: confundir throughput com desempenho.

Infelizmente é preciso considerar também que alguns fabricantes exageram as “melhores condições” em seus números de performance. Alguns publicam seus números sem explicar que são dados atingidos com aceleração de tráfego, sem no entanto explicar como funciona, quando se aplica e, pior, que poucas vezes se aplica. Há casos também que o throughput é o somado em ambas as direções, quando um equipamento de 10 Gbps pode na verdade transmitir 5 Gbps em cada direção.  Outro caso é de fabricantes de IPS que publicam seus números com uma política de segurança frouxa, mínima, que na prática não server para proteger ninguém.

Throughput

O primeiro passo para comprar bem é entender que throughput, a capacidade de transmissão de dados de um equipamento, é relativa em dispositivos de segurança. Relativa porque um equipamento de segurança precisa processar os dados antes enviá-los, e todos, seja baseado em chips especializados ou em processadores normais, tem sua capacidade real medida em pacotes por segundos. Se esses pacotes forem maiores então o throughput é maior, se forem menores, então ele será menor. O desempenho depende também do tipo de tráfego, ou os protocolos que estão sendo transmitidos, porque alguns produtos processam um protocolo mais rapidamente que outro.

Então na hora de analisar e adquirir um produto de firewall ou intrusion prevention system, recomendo solicitar o seguinte: 

(a) Throughput de x Gbps com as seguintes condições: 

• Tamanho médio de pacote, ou distribuição do tráfego por tamanho de pacotes
• Distribuição do tráfego por tipo de protocolo
• Funcionalidades que serão ativadas, como NAT, IPS e outras
• Se o throughput é full duplex (x Gbps em ambas as direções)
• Tamanho da política ou das regras que serão ativadas, especificando por exemplo que o produto terá todas as regras de prevenção de ataques ativadas

Switch Fabrics

Outro elemento essencial é como o equipamento será conectado à rede. Imaginem dois equipamentos de firewall com capacidade nominal de 10 Gbps e ambos com portas de 10Gbps. O primeiro permite que uma única porta de 10 Gbps seja utilizada enquanto o segundo exige que duas portas sejam usadas porque, embora a capacidade nominal das portas seja 10Gbps, o switch fabrics por trás delas somente suporta 5 Gbps para cada uma. Diferente, não? E pior, somente será detectado na hora de instalar. A segunda recomendação então é exigir: 

(b) que o throughput solicitado seja alcançado através da utilização de x portas de tal capacidade. De preferencia incluir algum diagrama deixando claro como o equipamento deverá suportar a capacidade exigida.

Sessões Simultâneas e Novas Conexões por Segundo

Mas há outros elementos além do throughput, e até mais importantes em alguns segmentos. Para provedores de serviço como sites e empresas de celulares, é mais importante definir sessões simultâneas que throughput. Um único usuário com iPhone irá consumir durante o dia até dez sessões simultâneas, e milhares de usuários consumirão dessa forma milhões de sessões, mesmo que o throughput não seja tão alto assim. Juntamente com as sessões simultâneas temos a quantidade de novas conexões que o produto irá processar por segundo. São novos usuários conectando-se ao mesmo tempo à rede da empresa. Esse elemento é também chamado em inglês de connection rate. Dessa forma recomendo exigir:

(c) X sessões simultâneas
(d) X novas conexões por segundo (cps)

Latência

Por fim temos a latência. Em geral apenas produtos ruins terão latência tão alta que prejudique a performance geral das aplicações, porém aplicações de voz ou vídeo exigem baixa latência, medida em microssegundos (μS). Para uso geral uma latência média inferior ou igual a 150 μS atenderá a maior parte das empresas. Temos assim a recomendação:

(e) Latência média igual ou inferior a 150 μS

Quanto mais próximo da realidade for cada item, melhor será a aquisição e menos dores de cabeça aparecerão na hora de usar a solução comprada. Com exceção de novas redes, todos esses dados estão disponíveis via relatórios dos equipamentos de rede e segurança já instalados. Recomendo adicionar algum espaço para crescimento e evitar exageros. Pedir demais também significa comprar errado.  

 

Riscos para MacOS e Dispositivos Móveis

O segundo trimestre é normalmente o período quando os principais grupos de pesquisa e investigação, entre elas algumas das principais empresas globais de serviços de gerenciamento e consultoria, publicam seus relatórios sobre segurança em relação ao ano anterior. Cada empresa tece suas análises e conclusões baseada em sua amostragem, o que nos dá uma interessante visão de diferentes ângulos sobre o que passou e o que cada um espera que vá ocorrer no futuro.

Várias conclusões são comuns entre elas, como a profissionalização da atividade hacker para fins criminosos, as técnicas de malware mutante, o uso político contra países ou inimigos em geral, o continuo uso e evolução das botnets, todos temas que já fazem parte da nossa realidade, com a qual temos que lidar em nosso dia-a-dia. Duas análises me chamaram mais atenção: tendências de riscos para MacOS e dispositivos móveis. Não pelos riscos em si mas porque nós usuários nos sentimos mais seguros nesses dispositivos, até ignorando cuidados que temos em um PC comum.

Toda a questão da segurança digital evoluiu junto com a massificação da TI, e baseada praticamente no uso de um único sistema operacional: o Windows; e em um único dispositivo: o PC. Com o passar dos anos passamos a associar Windows e (falta de) segurança como parte do mesmo problema. Muitos técnicos e especialistas contribuíram e vem contribuindo com essa ideia, sugerindo que qualquer navegador ou sistema operacional que não seja da Microsoft é mais seguro que os dela. Também ajudou a eterna discussão do software proprietário (representado tão somente pela Microsoft e seu Windows) e o software livre (todos os demais), e as paixões que ela desperta. Curiosamente até o mais proprietário de todos, o MacOS, que somente roda em hardware da Apple, é mais bem visto nessa discussão que o Windows.  O resultado é que está armazenado em nossas mentes o conceito de que “Windows é vulnerável e inseguro, enquanto outros não”.  Nunca participei dessa discussão, inútil em meu ponto de vista. Os computadores da minha casa rodam Windows, hoje uso MacOS no trabalho, onde tenho também um computador rodando Ubuntu. Sinto-me confortável em dizer que não me sinto seguro com nenhum deles, muito pelo contrário.

Mas muitos usuários de computadores Mac se sentem seguros e imunes a invasões em seus computadores, inclusive dispensando o uso de antivírus. Mas o fato é que o MacOS é sim vulnerável, e é afetado por malware. Um deles, reportados em 2010, é o Weyland-Yutani BOT, um toolkit com suporte a criptografia e uma GUI intuitiva, e capaz de evadir sistemas de proteção. O sistema permite que criminosos agreguem novas funcionalidades e malware ao programa base.  Houve também o antivírus falso que pirateia o MacDefender, em versão recheada de malware.  Uma vez baixado o programa conecta-se para baixar Trojans adicionais. O principal método de propagação é por download involuntário de sites web infectados, e o Trojan pode automaticamente abrir no Safari como um instalador compactado, e pelo menos uma vítima disse que seu computador foi infectado enquanto navegava por imagens.  É fato também que há menos vulnerabilidades e ataques contra MacOS, no entanto ser menos atacado não significa ser mais seguro.

O mesmo vale para dispositivos móveis, como celulares, tablets e afins. Há poucos ataques documentados mas as análises mostram um tendência real, com a qual usuários e empresas deveriam se preocupar mais. Um estudo da Juniper Networks detectou aumento de 400% em malware escrito para Android assim como em ataques contra dispositivos conectados em Wi-Fi. É de se esperar essa tendência visto que o futuro da Internet está na mobilidade. Muitos fabricantes se animam em indicar o tablet como o computador pessoal do futuro, e o uso do celular como meio de pagamento é hoje só uma questão de tempo. A tecnologia já existe e já funciona. Assim é razoável imaginar que esses serão o alvo dos cibercriminosos já no futuro próximo. Como destaca a Kapersky Labs, o malware para dispositivos móveis vem crescendo em escopo e intensidade.

No futuro próximo é de se esperar por outros problemas em outras plataformas. Estamos cada vez mais conectados, e portanto mais suscetíveis a ataques. Agora no Brasil temos por exemplo a nova geração de televisores com conexão direta à Internet, para navegar, acessar vídeos e baixar ou passar filmes por streaming. Hoje não há nenhum Trojan documentado, mas de novo não quer dizer que não exista a possibilidade. Provavelmente é só uma questão de oportunidade e foco, já que hackers não teriam nenhuma vantagem a obter de um televisor, por enquanto. Mas e quando as pessoas começarem a acessar seu internet banking do televisor? É uma questão de tempo a convergência das TVs, cada vez mais computadores e menos televisão, assim como os telefones celulares. 

Ataque à RSA: Advanced Persistent Threat?

O instinto de preservação é de nossa natureza. Tentamos sempre nos defender de ameaças, seja contra nós mesmos ou contra a que nos pertence, como nosso trabalho. Por isso desde criança nos justificamos tentando minimizar nossa responsabilidade em nossas falhas. Ao invés de reconhecer que não estudamos nosso primeiro ímpeto é dizer que a prova estava muito difícil. "Não foi minha falha, fiz tudo direito, não pude evitar o que aconteceu". 

A RSA, que teve seus sistemas invadidos, declarou que foi vítima de um Advanced Persistent Threat (APT). Acho esse negócio de APT uma bobagem, mas respeito a opinião de especialistas com uma visão diferente. Mas, francamente, há muita gente usando o termo da maneira que eu mais temia: como uma desculpa, e esfarrapada. 

Vejamos, como foi o ataque, ilustrado pela própria RSA. O hacker enviou emails de phishing a alguns funcionários contendo um exploit dia-zero dentro de um arquivo Excel que explora uma vulnerabilidade no Adobe Flash (CVE-02011-0609).

Disseram que foi um APT porque os invasores conheciam a empresa, sua rede, funcionários e suas funções. Mas como alguém irá invadir uma empresa sem investigá-la? Desde quando um ataque direcionado é um APT? E desde quando enviar um phishing com um zero-day exploit é uma técnica avançadíssima? Por que não reconhecer o óbvio? Que o sistema anti-phishig, firewall pessoal e o treinamento dos usuários falharam? Ou que o phishing foi bem construído e burlou a segurança do email mas que um funcionário desatento não percebeu que um email com o título de "2011 Recruitment Plan" era uma armadilha? E por que o software de segurança da estação de trabalho do funcionário desatento não detectou o exploit? Por que não reconhecer que a empresa foi invadida por um método de ataque que existe há quase uma década? Pois é, a pior maneira de lidar com um problema é não reconhecê-lo. 

Segurança em IPv6 - parte 4 de 4

Caminhos para a Implementação Segura

O caminho para a implementação segura do IPv6  se inicia com o alerta de Scott Hogg e Eric Vyncke no livro IPv6 Security: “a segurança de sistemas IPv6 precisa ser avaliada antes que seja habilitado nas redes e sistemas atuais e futuros” .

O primeiro passo é conhecer e estudar o novo protocolo, já que há muitas diferenças em relação ao antigo, e portanto tentar configurar o IPv6 como um “IPv4 com endereço maior” trará sérios problemas de conectividade e segurança. Também se deve estudar e planejar com cuidado a migração e os métodos de coexistência, que como já vimos podem abrir brechas de segurança. Um bom projeto deve levar em conta algumas ações:

1. Planejar com cuidado a implementação da nova rede, em especial o roteamento e configuração automática de host. No caso de implantação de DHCP, este também terá diferenças em IPv6, e portanto é necessário estudar as mudanças evitando erros de configuração que criem brechas na segurança.
2. Avaliar o status em relação ao IPv6 de todos os equipamentos de rede e sistemas operacionais: (a) compatibilidade com o IPv6 e em que nível; (b) vulnerabilidades e (c) recomendações de cada fabricante para sua implementação.
3. Avaliar o status dos sistemas de segurança de rede; nível de compatibilidade, performance e niveis de proteção. É possível que um bom fabricante de segurança em IPv4 deixe de sê-lo para IPv6. 
4. Na configuração de políticas de firewall ou filtragem no router de perímetro, todos os cuidados observados para IPv4 deverão se repetir para IPv6, como o controle de ICMP e anti-spoofing. Além disso será necessário adicionar novas regras ou filtros para novidades do IPv6, como o sistema de roteamento. Para isto recomendo a consulta de boas práticas indicadas pelos fabricantes. Um bom exemplo é o artigo IPv6 and IPv4 Threat Comparison and Best Practice Evaluation de Sean Convery e Darrin Miller, publicado pela Cisco .
5. Planejar com cuidado que métodos de coexistência serão utilizados, como garantir a segurança do seu uso e como bloquear métodos descartados. Por exemplo: como bloquear tunelamento dinâmino, evitando que tuneis sejam configurados sem conhecimento dos administradores.
6. No IPv6 os hosts, as pontas da comunicação, tem mais responsabilidades que em IPv4. O tratamento de cabeçalhos, checksum e fragmentação são efetuados pelos hosts, o que implica em maior segurança local. Embora a instalação de personal firewalls seja já uma prática difundida, ela se torna ainda mais importante. Um antivirus simples não irá proteger seu computador!
7. Para todas as vulnerabilidades de arquitetura há soluções por configuração. Para reduzir os riscos da configuração automática stateless, recomenda-se a adoção de autenticação em nivel de rede, com IEEE 802.1X ou tecnologia similar de NAC (Network Admission Control). Dessa forma um equipamento terá que autenticar-se com a rede antes de receber um endereço IPv6 e possa comunicar-se com outros dispositivos.

Durante a migração é quase consenso algumas recomendações:

1. Adotar o método de dual-stack, onde ambos protocolos existirão nativamente, como duas redes paralelas. Computadores com suporte IPv4 se comunicarão via esse protocolo enquanto hosts compatíveis usarão apenas IPv6, sem tunelamento. Permitirá mais clareza aos administradores para lidar com cada protocolo e seus problemas em separado.
2. Em caso de uso de tunelamento, apenas utilizar o tunelamento estático. O método de tunelamento dinâmico é propenso a ser explorado por intrusos, que poderiam configurar um tunel que estaria fora da visão dos administradores de segurança e das medidas de controle e proteção.
3. Bloquear no firewall quaisquer tuneis não autorizados, ou hosts não autorizados a estabelecer túneis.

Neste artigo vimos um resumo das características de segurança do IPv6, e discutimos algumas de suas vulnerabilidades e recomendações para uma implantação segura. No entanto o tema é muito mais vasto e requer estudo e planejamento, com o benefício de ao final termos redes com melhores níveis de segurança. Felizmente há também vasto material a respeito, seja em livros ou em artigos disponíveis na Internet, o que permitirá às empresas uma implementação e migração sem surpresas.

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)

Segurança em IPv6 - parte 2 de 4

Aperfeiçoamentos em Segurança

Mas o IPv6 não é apenas um novo sistema de endereçamento e sim uma toda nova suíte de protocolos para Internet resolvendo vários dos problemas que surgiram com o crescimento da rede mundial, segurança entre eles. O IPv4 foi criado sem maiores preocupações com segurança. Inicialmente porque na época isso realmente não era um problema. O conjunto de protocolos começou a ser definido ainda no início dos anos 70 e oficializado em 1981 pela RFC 791 do IETF, quando a Internet tal qual a conhecemos hoje, acessivel literalmente de qualquer lugar, ainda estava na imaginação de alguns visionários. Outro motivo é que por definição o IPv4 foi criado com o intuito de ser um protocolo totalmente transparente. Dessa forma segurança deveria ser implementado pelas “pontas” da comunicação, o que realmente ocorreu. Já o IPv6 implementa nativamente duas características de segurança. A primeira delas é a obrigatoriedade da criptografia IPSec em toda a rede, o que aumentará significativamente a segurança dos dados em trânsito. A implementação inclui o IKE (Internet Key Exchange), protocolo encarregado da troca de chaves de criptografia entre as pontas da comunicação. No IPv4 sua implementação é opcional e ocorre apenas em alguns seguimentos de rede ou aplicações consideradas críticas. Outra funcionalidade é a de autenticação de origem e integridade. Ambas funções são implementadas através de dois cabeçalhos extendidos (extension headers): Encrypted Security Payload (ESP) e Authentication Header (AH) respectivamente.

O conceito de cabeçalho extendido é uma das inovações do novo protocolo. O objetivo dos engenheiros era simplificar o cabeçalho dos pacotes e assim foi definida uma parte fixa, de 40 octetos ou 320 bits, e uma parte variável. O primeiro contém os campos de versão (version), indicador de prioridade de entrega (traffic class),  informação de roteamento (flow label), tamanho (payload lenght), indicação do próximo cabeçalho (next header), o contador de roteamento que substituiu o time to live do IPv4 (hop limit) e endereços de origem e destino. Apesar de ser maior o novo cabeçalho possui menos informação e é processado mais rapidamente que o anterior.

Comparativo de cabeçalhos IPv4 e IPv6. Fonte: Cisco

Informações adicionais para processamento dos pacotes estão armazenadas nos cabeçalhos extendidos, que podem ser nenhum, um ou vários. Entre estes cabeçalhos estão os Encrypted Security Payload (ESP) e Authentication Header (AH). Além disso considero como aperfeiçoamento a implementação mandatória e nativa de QoS, que embora não seja totalmente relacionado à segurança, impede alguns dos problemas de tráfego indesejado que ocorrem hoje. Também a nova estrutura de endereçamento dificulta algumas práticas comuns, como o port scanning, e a distribuição automática dos worms, que teriam que atualizar seus métodos de distribuição a fim de manter o grau de eficiência. No IPv4, para que um port scanning ou worm cubra toda uma subnet típica seria necessário o envio de  256 testes de identificação de máquinas ativas, como uma simples mensagem de ping. Já no IPv6 o tamanho default de uma subnet é 264 ou mais de 18 quintilhões  de endereços possíveis. Varrer todo esse espaço passar a ser questão de anos ao invés de segundos. Entretanto isso não significa o fim dos worms ou de técnicas de mapeamento de rede, que com certeza irão evoluir.

Outra vantagem do IPv6 é a quase erradicação da fragmentação de pacotes, típico recurso usado por hackers para evadir sistemas de proteção como firewalls e sistemas de prevenção de intrusos. A RFP 2460 especifica 1280 octetos como tamanho mínimo para os pacotes que trafegam em rede, além de também especificar que os pacotes maiores que o limite especificado no MTU serão fragmentados no host de origem via um cabeçalho extendido e não mais por roteadores ao longo do caminho.

Por outro lado há mudanças que podem levar administradores de rede a cometer erros e abrir brechas. No IPv4 nos acostumamos a mascarar os hosts de nossa rede através do NAT, que embora criado como paliativo para a falta de endereços IP se tornou um recurso a mais de segurança. Pois não há nada parecido com o NAT em IPv6, que implementa o conceito de comunicação ponta a ponta no qual cada host ou elemento terá um endereço válido, não mascarado. Dessa forma o seu computador pessoal em sua casa e escritório, seu celular e seu carro  terão endereços válidos de Internet.  Isso nos leva a uma outra questão: DNS. Estamos acostumados a conhecer endereços IP de servidores e outros dispositivos conectados à rede. Assim dizemos facilmente “conecte-se ao 192.168.125.10”. Isso em IPv6 seria convertido a “conecte-se ao 3ffe:1900:4545:3:200:f8ff:fe21:67cf”! Mesmo sendo possível algumas simplificações, será na prática impossivel o uso de endereços IP para nomear computadores, o que implicará no uso extensivo de DNS, hoje utilizado normalmente apenas para servidores.

Há mudanças menores, mas que devem também ser conhecidas. O tradicional broadcast também deixou de existir, sendo substituido por um endereço multicast que se comunica com todos os hosts locais, o link-local. Outra alteração foi no ARP, substituído pelo neighbor discovery. A função é semelhante porém uma vez mais a configuração mal feita poderá comprometer a rede e permitir que um intruso possa mais facilmente mapeá-la. Seja uma mudança radical ou pequena, elas abrem brechas para a mais comum das vulnerabilidades: os erros humanos. Não é a toa que é esperado um aumento de vulnerabilidades nos primeiros anos de migração.

(continua)

Segurança em IPv6 - parte 1 de 4

Em 1 de Fevereiro de 2010 o último grupo de endereços livres disponiveis do sistema atual de endeçamento da Internet, conhecido como IPv4, foi concedido pela IANA (Internet Assigned Numbers Authority) ao APNIC, o comitê gestor dos endereços Internet para a Ásia e Pacífico. O fato é significativo mas não foi surpresa para ninguém. Há pelo vinte anos o fim do endereçamento tradicional da Internet é esperado e desde 1998 há uma solução: o IPv6. Quando criado, o IPv4 possuía uma quantidade de endereços que parecia inatingível para uma Internet ainda engatinhando e restrita: 4 bilhões. No entanto o crescimento vertiginoso da rede mundial fez com que essa quantia fosse insuficiente para todos os dispositivos de usuários, empresas e provedores de Internet, problema resolvido através do uso de NAT. Já o IPv6 possui 2128 (dois elevado a cento e vinte e oito) endereços, ou a formidável quantia de 340.282.366.920.938.463.463.374.607.431.768.211.456, suficiente para tudo e mais um pouco.

O fim dos endereços IPv4 nos leva portanto à fase seguinte do endereçamento Internet. Desde que foi lançado, há treze anos, o IPv6 foi muito pouco solicitado e implementado. Agora espera-se que o processo de adoção se inicie, liderado pelos provedores de serviço. Será uma migração lenta e gradual, onde ambos sistemas de endereços irão conviver por muitos anos, e que exigirá a atualização da infraestrutura de rede das empresas, muitas ainda utilizando equipamentos e sistemas antigos e incompatíveis. 

A adoção do IPv6 no Brasil também é incipiente, como se pode deduzir de pesquisa realizada entre os AS (Sistemas Autônomos) brasileiros pelo Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações – certpro.br – ligado ao Comitê Gestor da Internet no Brasil, em fevereiro de 2010, e que obteve 237 respostas de 217 Sistemas Autônomos:

• Apenas 33% possuiam bloco IPv6 próprio
• Dos 99% que julgam necessário treinamento em IPv6, aproximadamente apenas 37% realizaram o curso ministrado pelo NIC.br ou algum outro treinamento
• Apenas 16% anunciaram bloco IPv6 na Internet, sendo que 68% deles (ou 11% do público total) o fizeram por trânsito nativo IPv6
• Apesar dos itens anteriores, 66% responderam que seu sitio web era naquele momento acessível por IPv6 e 63% ofereciam trânsito nativo a seus clientes corporativos

A pesquisa completa pode ser consultada no site http://ipv6.br mantido pelo NIC.br e não difere muito dos resultados em outros países, como mostram dados estatísticos dos RIR - Regional Internet Registries – os órgãos regionais responsáveis por endereçamento. O ARIN – responsável pelo América do Norte – reporta que recebeu em Janeiro e Fevereiro de 2011 o total de 499 requisições de endereços IPv4 contra 147 para IPv6. 

(continua)