NAT Transversal ou Encapsulamento UDP

Fala Galera blz?

Estudando IPSec, para desempenhar minhas novas atividades, conheci uma forma de NAT em que a tradução do endereço IP não é realizada através das portas de comunicação, o NAT-T é uma técnica onde os dois equipamentos que estão configurados para se conectar utilizando IPSec verificam inicialmente se são compatíveis com a tecnologia, em seguida os dois equipamentos devem detectar se existe ou não a tradução de endereços e em que parte do caminho a tradução ocorre. Por fim, deve-se negociar os parâmetros do protocolo (portas utilizadas para encapsulamento, utilização de cookies, etc) e em seguida iniciar a transmissão de dados utilizando pacotes encapsulados.

Toda essa negociação e troca de cookies (arquivos de texto contendo informações sobre a transmissão) se deve porque o ESP (Encapsulating Security Payload) que é o protocolo responsável por transmitir o payload do pacote IPSec não utiliza o mesmo conceito de portas utilizado nos protocolos TCP e UDP e, portanto, não é possível fazer a tradução de endereço através do NAT Tradicional.
No NAT Transversal cada conexão é enviada com os respectivos dados de tradução (porta de origem: porta de destino) e a resposta só é enviada após a recepção da primeira conexão. Desta forma é configurado um novo NAT a cada conexão entre cliente e servidor IPSec. Neste conceito existem três tipos de NAT-T:

No Full Cone NAT também conhecido como NAT 1 para 1, nele  o cliente utiliza um endereço IP1:Porta1 para se comunicar com um servidor pelo IP2:porta2 sendo a resposta deste servidor enviada para a porta IP2:Porta2 e assim por diante, nesta forma de NAT o cliente pode contactar mais de um servidor em paralelo (1 para muitos).

No Restricted Cone NAT vemos que a comunicação se dá por duas portas mas apenas entre cliente e servidor (1 para 1). Caso um segundo servidor tentar responder o pacote será dropado pelo dispositivo que está fazendo o NAT-T.

No Port Restricted Cone NAT vemos que a restrição agora é por porta, onde apenas uma é utilizada para a comunicação entre cliente e servidor, no caso acima o servidor deve utilizar a porta que recebeu a comunicação para responder ao cliente e o Server 2 deve aguardar a conexão do cliente para então poder se comunicar.

Este terceiro caso é muito semelhante ao restricted cone, sendo a única diferença que o vinculo 1 para 1 é vinculado a porta, enquanto no restricted cone o vínculo é cliente servidor.

Além do ESP protocolos não vinculados a conexão como SIP e P2P também utilizam o NAT-T como uma forma de fazer NAT sem manter preso o número de porta a aplicação

A nível de sistemas operacionais, Windows a partir da versão 200 e XP (Artigo Microsoft Article ID: 818043) suportam nativamente o NAT-T para conexões VPN, como o applience que estou estudando também suporta nativamente este protocolo todos os sistemas Linux também suportam esta tecnologia.

O NAT-T está definido na RFC3947 que está na sessão de links abaixo.

Este conceito de NAT é muito semelhante ao modelo tradicional, eu compreendi claramente a diferença ao considera-lo orientado a pacotes, até por isso é chamado de encapsulamento UDP por alguns fabricantes.

Grande abraaaaço!

Fonte:
RFC 3947: http://www.ietf.org/rfc/rfc3947.txt
Artigo Microsoft ID818043: http://support.microsoft.com/kb/818043/en-us
Wikipedia EN: http://en.wikipedia.org/wiki/Network_address_translation
Wikipedia PT: http://pt.wikipedia.org/wiki/NAT_transversal
Materiais eLearning Sonicwall disponíveis em https://www.mysonicwall.com/Login.asp
(É necessário se registrar para ter acesso ao conteúdo).

NIC.br e ICANN anunciam resolução DNS ainda mais segura e rápida no Brasil

O Núcleo de Informação e Coordenação do Ponto BR (NIC.br), emcooperação com a Internet Corporation for Assigned Names and Numbers(ICANN) instalaram, nos últimos dois meses, 14 novas cópias anycast doservidor L da ICANN, originalmente instalado na Califórnia - EUA.

A partir de hoje, as cópias de l.root-servers.net operam juntamente com servidores do .br nos Pontos de Troca de Tráfego no Brasil (PTTMetro). Das atuais 20 localidades que contam com Pontos de Troca de Tráfego do PTTMetro, as 14 que serão atendidas por essa melhoria são Belo Horizonte, Brasília, Campinas, Curitiba, Florianópolis, Fortaleza, Londrina, Porto Alegre, Rio de Janeiro, Salvador, São Paulo, São José dos Campos, Belém e Natal. Com isso, as cinco regiões do país serão beneficiadas pela nova infra estrutura de resolução de nomes.

Somados aos servidores que já existiam em operação, essa infra estrutura amplia substancialmente, e de forma distribuída, a capacidade de resolução de nomes e consequentemente a resiliência para suportar possíveis abusos ou ataques ao serviços DNS. Ela propicia também a continuidade operacional de regiões do país que estejam temporariamente segregadas tanto dos canais internacionais quanto da comunicação com outras regiões, por exemplo em função de múltiplos rompimentos na rede de longa distância das operadoras.

Anycast

Anycast é um serviço em que duas ou mais máquinas respondem pelo mesmo endereço IP,o servidor físico que responderá a solicitação é determinado de acordo com a rota IP a ser percorrida pelo cliente até o servidor, o servidor mais próximo responderá a solicitação.

O endereço IP do nó mais próximo configurado no Anycast é difundido pelo protocolo de roteamento BGP, e pode ser atualizado a cada atualização de roteamento deste protocolo, como o endereço do nó pode mudar conforme a disponibilidade de rota até ele, o anycast funciona melhor com protocolos não orientados a conexão (utilizam o UDP na camada de transporte).

Maiores detalhes, mapa com a localização dos servidores DNS da antigae nova estrutura dos servidores root-servers.net e .br neste LINK.

Fonte:
Registro.br

BHack Conference

Para minha felicidade ontem, lendo o blog do SegInfo [1] tomei conhecimento do BHack Conference, por ter as iniciais da minha cidade logo me empolguei, trata-se de uma conferência de segurança da informação organizada pelo DcLabs [2] que irá contar com palestrantes de peso da área técnica,gestão de segurança e direito digital.
Dentre os palestrantes confirmados estão:
Nelson Brito, Anchises Moraes, Tony Rodrigues Thiago Bordini e Rafael Soares com quem tive o prazer de aprender muita coisa sobre Forense Digital baseado em software livre em um curso da Clávis.
Agora é convidar nossos amigos de SI para prestigiar o evento para que este seja o primeiro de muitos, e para que Minas Gerais seja cada vez mais bem representada a nível de Brasil na área de Segurança da Informação.

 Forte abraço até lá

Mais informações sobre o BHack Conference nos links abaixo:
Site
Facebook
Twitter 

Fonte:
[1] Blog SegInfo
[2] DcLabs

Domain-based Message Authentication, Reporting and Conformance DMARC

O DMARC traduzindo, Autenticação resposta e conformidade baseada em domínios é um documento (tratado), que têm por objetivo minimizar o envio de mensagens indesejadas (SPAM) pela internet, este documento está em desenvolvimento e tem apoio dos grandes provedores de e-mail gratuito da internet, dentre eles estão Google, Yahoo, Microsoft, Facebook, LinkedIn, entre outros [1].

Este documento consiste na combinação do SPF (Send Policy Framework) e DKIM (Domain Key Identify Mail) além de técnicas que permitem o rastreamento de informações de tentativas de autenticação sem sucesso, então além de prevenir o envio de SPAMS há um esforço para identificar os responsáveis pela mensagem barrada pelos servidores configurados sob o DMARC, vamos conhecer um pouco mais do SPF e do DKIM, que são a base do DMARC?

 SPF traduzindo, plataforma de políticas de envio

O SPF é um padrão aberto que permite através do registro TXT de um domínio DNS identificar quais servidores (Endereços IP's) podem enviar mensagem utilizando o nome de domínio em que o registro está configurado.
A Sintaxe do SPF é simples e pode agrupar um grande número de endereços IP's pois ele suporta a inclusão de CIDR's além de endereços IP's separados, maiores detalhes sobre o SPF podem ser encontrados no site do padrão [2].


DKIM traduzindo, Chave Identificadora de Domínio de E-mail

O DKIM anexa um novo identificador de nome de domínio nas mensagens usando técnicas de criptografia para validar que aquela mensagem foi enviada com autorização do provedor de e-mail, este identificador é independente de qualquer outro identificador do e-mail (Campo De:, Assunto: SMTP-ID e etc.). O resumo do DKIM é definido pela RFC 5585, e mais informações podem ser obtidas no site do projeto [3].

Ambas técnicas são conhecidas no mercado, eu conheci o SPF pela primeira vez em meados de 2009 quando estava reforçando as configurações do sistema de e-mails da minha atual empresa, já o DKIM é foi desenvolvido por um longo tempo e teve sua primeira utilização em 2005 pelo Yahoo! e pela Cisco Inc. Somadas as duas técnicas são poderosas, e podem tornar um protocolo tão importante para a internet mais seguro.

Fonte:

Links:
[1] DMARC - Specifications
[2] Open SPF Project
[3] Domain Keys Identified Mail (DKIM)

Forte abraço, feliz 2012 e até a próxima!!!