Servidor de logs CGNAT

Introdução

Com a escassez do recurso IPv4 no mundo, a resistência de muitas organizações que ainda não tem seus sistemas e conteúdos disponibilizados em IPv6, de muitos Provedores de Internet que ainda não entregam IPv6 nos seus clientes, tudo isso torna lenta a mudança de uma Internet antiga e legada, para uma Internet melhor e mais moderna. Mas por que toquei nesse assunto? Porque enquanto usarmos o IPv4 nessa situação, todos nós Operadoras ISP teremos que utilizar um recurso para continuarmos crescendo chamado de CGNAT (Carrier Grade Network Address Translation), que não trás nenhuma qualidade para nossos assinantes ou benefício para o crescimento da Internet. Para mim, CGNAT ou também conhecido como CGN, é uma muleta para a Internet continuar funcionando enquanto o IPv6 não se prevalece no mundo.

O CGNAT tem o objetivo principal de compartilhar IPv4 público e existem diversas soluções comerciais e não comerciais no mercado, mas que não vem ao caso aqui. O que importa para o nosso artigo, é a maneira como ele é implementado e que precisaremos armazenar os logs de conexão por pelo menos 1 ano, segundo o Marco Civil da Internet. Sempre que precisarmos identificar um cliente atrás de um CGNAT para uma Quebra de Sigilo Tecnológico, faremos uso dos logs armazenados.

Nesse artigo trataremos da montagem de um servidor de logs de CGNAT utilizando um Debian GNU/Linux e programas livres, de forma organizada para facilitar as consultas e abordaremos o recebimento de logs tanto via syslog quanto via netflow.

Tipos de implementação do CGNAT

Determinístico: onde usamos uma tabela de associação estática entre os IPv4 públicos, suas portas lógicas de origem e os IPs privados usados pelos clientes. Podemos encontrar por exemplo configurações de compartilhamento de 1/16, 1/32, etc, onde por exemplo: 1/32 seria compartilhar 1 IPv4 público com 32 clientes. Essa relação está associada à quantidade de portas lógicas alocadas para o cliente e que no caso de 1/32 seriam algo em torno de 2000 portas para cada cliente. Existe uma ideia errada de que se estamos usando Determinístico, então não precisamos armazenar logs. Em certo ponto está certo porque existe uma associação estática que não deveria mudar, mas se em algum momento você precisar reorganizar sua tabela de associação estática, você precisará ter um controle de quando isso foi alterado, de como era a tabela antes e de como ficou, porque senão você acabará identificando o cliente errado. Minha humilde sugestão: sempre armazene os logs, não importando se é Determinístico ou não.

BPA (Bulk Port Allocation): nessa modalidade podemos economizar mais os recursos IPv4 públicos, porque as portas são alocadas dinamicamente e conforme a necessidade de uso do cliente. Se você parar para analisar o perfil dos seus clientes descobrirá que a grande maioria utiliza poucas portas durante o acesso à Internet e por isso, no modelo BPA, você consegue colocar mais clientes utilizando o mesmo IP público. Existe um certo medo nesse modelo de CGNAT, porque muitos acreditam que será necessário gastar rios de dinheiro comprando ou contratando espaço em disco de servidores, para armazenar todos os logs por 1 ano. O que posso dizer é: dependendo da implementação do BPA, sim isso irá acontecer. Um exemplo que vi isso ocorrer foi com um BPA que enviava logs a cada vez que um cliente utilizava uma porta, ou seja, um log por porta. Realmente essa seria a pior configuração ao meu ver, porque embora esteja fazendo a alocação dinâmica das portas, está coletando dados de forma excessiva e sem necessidade. Procure configurar seu BPA para trabalhar com blocos de portas alocadas e aí sim terá logs bem pequenos. Um exemplo real que tenho para dar: uma caixa CGNAT que atende uns 20.000 assinantes, gerando um log diário menor que 10Mb compactado.

Formatos de envio de logs

Os formatos que trabalharemos neste artigo, são os mais utilizados nos equipamentos de Redes:

• Syslog: é um serviço muito utilizado para armazenar logs sejam eles quais forem; mensagens de outros serviços, erros de sistema, um acesso indevido ou tentativas de se burlar um sistema, enfim, qualquer coisa que possa dar uma informação útil para uma análise da situação. Além de tudo isso podemos utilizar esse recurso para armazenar logs de CGNAT. O problema é que o syslog não é tão robusto e não lida muito bem com muitas requisições simultâneas, aumentando em muito o uso do processamento e dependendo da situação pode ocorrer alguma falha no registro do dado. O que vemos é que para registrar logs de sistemas e processos de um servidor, ele se sai muito bem mas quando temos diversos BNGs enviando logs de CGNAT, ele não seria a melhor opção.
• Netflow: o envio de flow é utilizado em muitos ambientes para análise por amostragem e com diversas aplicações como por exemplo: sistemas de detecção e mitigação DDoS, sistemas que geram estatísticas úteis para análise de tráfego de Redes, dando informações valiosíssimas para o pessoal da Engenharia de Redes, consumos de determinados conteúdos para avaliar se pode ser solicitado algum Cache de CDN para a sua Operação, detecção de Botnets, enfim, muita coisa pode ser feita usando Netflow inclusive tem uma função especialmente elaborada para logs de CGNAT. Sem falar que ao contrário do nosso amigo syslog, esse sistema se mostra muito mais robusto, preparado para receber muitas requisições simultâneas e com menor consumo de CPU.

Neste artigo configuraremos o nosso servidor para receber ambos os formatos mas por experiência própria, quando falarmos de logs de CGNAT, procure sempre que puder, utilizar o Netflow em detrimento ao Syslog.

Diagrama

Como base para a nossa configuração usaremos o diagrama ao lado e para poder visualizar o que ocorre em um ambiente com CGNAT. Nesse exemplo temos um cliente, que ao se conectar no Provedor de Internet, recebeu um IPv4 100.64.10.50 (RFC6598) e um Prefix Delegation IPv6 2001:0db8:b010:c000::/56. Todos os acessos a conteúdos em IPv6 não passarão pelo CGNAT, seguindo diretamente para a Internet e sendo registrado o log da conexão no seu servidor Radius, por exemplo. Já para o cliente acessar os conteúdos em IPv4, será necessário que os pacotes passem pela Caixa CGNAT, seja feita uma tradução do IP 100.64.10.50 para um IPv4 público, que no nosso exemplo é o 198.51.100.230.

Sempre que eu tiver que passar pela Caixa CGNAT e for feita uma tradução, será necessário armazenar esses dados através de logs que serão enviados para o nosso servidor de logs CGNAT em 2001:db8:c0ca:c01a::2.