Script Gerador CGNAT Mikrotik 2021-05-27T21:06:54-03:00

Script Gerador CGNAT Mikrotik

O grupo RadiusNet & VianaTel cuida, literalmente, de milhares de provedores, tanto dos aspectos técnicos como dos administrativos e fiscais.

Temos uma alta demanda de procura por provedores que recebem ofícios de diversos entes governamentais solicitando dados de clientes com base em lista de IPs e horas de acesso. São ofícios da Polícia Federal, Polícia Civil, Tribunais Eleitorais, Receita Federal, etc.

Já é de amplo conhecimento da maioria que os provedores de acesso devem guardar os logs de conexão. Focaremos nesse artigo nos aspectos TÉCNICOS da guarda de logs. Os aspectos legais, como por exemplo, se uma requisição de dados de um IP sem autorização judicial é válida, podem ser tratados diretamente com nossa equipe VianaTel!

Notamos que muitos não configuram certo suas redes e quando chega a notificação que percebem isso.

Pensando nisso criamos um script para ajudar o provedor a configurar seu Mikrotik com o CGNAT, que é uma forma de configuração própria para atender requisições de dados de IP.

.

As requisições de dados tem, basicamente, a seguinte forma:

Data: 02/05/2021

Hora: 15:55:22 UTC

IP: 200.200.200.55

Porta Origem: 45627

.

O campo hora pode vir também nos seguintes formatos:

Hora: 15:55:22 GMT

Hora: 15:55:22 GMT -3

Hora: 15:55:22 UTC -3

.
Hora UTC

Imagine a seguinte situação: um usuário de Manaus acessa um servidor do Facebook em São Paulo que por sua vez guarda seus logs em Atlanta, nos Estados Unidos. Esse usuário comete o crime de injúria contra uma pessoa em Cuiabá. Qual horário vamos guardar no log? Dos usuários? Do servidor de acesso ou log?

 

Para evitar esse tipo de confusão, todos os provedores guardam a hora UTC, que é a hora “zero”. O RadiusNet, por exemplo, guarda o horário em UTC. Assim não importa a localização do servidor, do cliente, se está ou não em horário de verão, etc, o horário guardado é sempre em UTC, pois quase a totalidade das requisições de autoridades solicitam o horário UTC, para poder cruzar com dados passados pelo FaceBook, Google, etc.

 

As horas podem ser medidas no formato GMT também. Esse formato leva em conta aspectos astronômicos, como o sol e rotação da terra. Já o UTC é o chamado “tempo atômico”, medidos por “relógios atômicos”. Como a diferença entre ambos é de poucos segundos, via de regra GMT é a mesma coisa que UTC.

 

O horário de Brasília é UTC-3 (ou GMT-3). Assim, ofícios que chegam solicitando 15:00 UTC-3, é o mesmo que solicitar 15:00 horário de Brasília. Ofícios que chegam com 15:00 UTC é o mesmo que 12:00 UTC-3. É muito importante ficar atento para olhar de forma correta para seu log!

.
Hora do Equipamento – Uma bomba relógio

Sabe aquele Mikrotik que alguém configurou “rapidinho”, na hora de um problema sério na rede? Será que o horário foi configurado corretamente? Será que os servidores NTP foram configurados? Será que o timezone está correto?

Isso pode causar um problema seríssimo, pois a maioria dos softwares de gestão salvam no banco de dados o horário que o roteador informa, que pode estar errado!!

 

Assim, algo que ocorreu por exemplo, no dia 05/05/2021 às 19:00 pode ser gravado no banco de dados como 01/01/2021 14:00, ou seja, sua empresa pode mandar para as autoridades uma informação FALSA!! Imagina alguém INOCENTE ser condenado com base no log ERRADO do provedor????

 

ISSO É GRAVÍSSIMO!

 

Por isso o RadiusNet não guarda o horário enviado pelo roteador, mas sim o horário UTC da requisição! Com isso você sempre tem CERTEZA de que, INDEPENDENTE DO HORÁRIO QUE ESTÁ NO SEU CONCENTRADOR, o seu banco de dados estará com o horário CORRETO!

 

Para evitar esse tipo de confusão, todos os provedores guardam a hora UTC, que é a hora “zero”. O RadiusNet, por exemplo, guarda o horário em UTC. Assim não importa a localização do servidor, do cliente, se está ou não em horário de verão, etc, o horário guardado é sempre em UTC, pois quase a totalidade das requisições de autoridades solicitam o horário UTC, para poder cruzar com dados passados pelo FaceBook, Google, etc.

 

As horas podem ser medidas no formato GMT também. Esse formato leva em conta aspectos astronômicos, como o sol e rotação da terra. Já o UTC é o chamado “tempo atômico”, medidos por “relógios atômicos”. Como a diferença entre ambos é de poucos segundos, via de regra GMT é a mesma coisa que UTC.

 

O horário de Brasília é UTC-3 (ou GMT-3). Assim, ofícios que chegam solicitando 15:00 UTC-3, é o mesmo que solicitar 15:00 horário de Brasília. Ofícios que chegam com 15:00 UTC é o mesmo que 12:00 UTC-3. É muito importante ficar atento para olhar de forma correta para seu log!

O que fazer então? Você tem duas saídas:

1) Usar o RadiusNet e esquecer essa dor de cabeça!

2) Lembrar de ajustar o horário, timezone, serviço NTP de todos seus concentradores e lembrar de verificar, de tempos em tempos, se o horário está certo!

.
Possibilidades de Respostas para as Requisições

São várias repostas que podemos dar, de acordo com a rede do provedor. Vamos analisar as mais comuns:

 

1) Provedor tem 100% da rede com IPs públicos: basta então pegar o horário (converter UTC se for necessário) e devolver o resultado para a autoridade. Porém esse caso é raro. A maioria dos provedores sempre tem mais usuários que IPv4 públicos, pois esse recurso se esgotou.

 

2) Provedor tem NAT simples: Aquele NAT básico que provavelmente foi o primeiro comando que todo dono de provedor aprendeu a fazer no Mikrotik! Infelizmente esse é o pior caso: temos visto provedores de 30 até 5.000 clientes com NAT, ou seja, todos os seus clientes saem por um único IP, sem nenhum tipo de organização. Com esse tipo de NAT é possível apenas passar quem estava online na hora solicitada. Imagina dar uma lista de 1.500 pessoas online para um policial federal? Tudo bem, é o que o provedor pode fazer nesses casos… Mas temos notado que as autoridades tem cada vez menos paciência com esse tipo de reposta. Por isso, não recomendamos que o provedor tenha esse tipo de NAT.

 

3) CGNAT com portas de origem dinâmicas e um servidor syslog em paralelo guardando os dados de cada conexão feita (alerta de outra BOMBA!): A porta de origem, por exemplo, 45.000 do IP 200.200.200.10 pode ser usada por qualquer cliente do provedor. Então o roteador é configurado para enviar a um servidor de syslog informações sobre cada conexão feita. Cria-se uma situação tão complexa, tão sujeita a falhas, que é melhor não ter nada, veja só: às 19:05:10 (dezenove horas, cinco minutos e dez segundos) a porta 45.000 foi usada pelo IP 10.0.0.1. Alguns segundos depois ela já estará disponível para outro cliente usar. Em questão de segundos você tem várias pessoas usando a mesma porta! E se chegar um ofício pedindo a porta 45.000 às 19:05:17 ?? Você vai confiar a INOCÊNCIA de uma pessoa no servidor de syslog? Quem monitora esse servidor? Ele tem backup? Ele está com o horário correto?

 

Imagine uma página simples do Facebook tem 30 fotos. São 30 conexões ao servidor de syslog!! Multiplica isso por todos seus clientes!

 

Calma, ainda tem mais: muitos syslogs são UDP, ou seja, não tem confirmação de entrega do pacote. Imagine a seguinte situação:

Porta 45.000 às 19:01:10 – Maria da Silva

Porta 45.000 às 19:01:20 – Carlos Souza

Porta 45.000 às 19:01:30 – José da Silva

O pacote do Carlos Souza se perdeu. Tem só o registro da Maria e do José. Aí chega o ofício e pede a porta 45.000 às 19:01:20. Quem você vai dizer que foi?? Pelos horários, claro que foi  Maria da Silva! Porém o investigado deveria ser o Carlos Souza!!

 

Há formas de melhorar alguns dos problemas relatados, mas o que o processo em si tem muitos pontos que podem dar errado. Por isso não o recomendamos.

 

No final das contas, a informação não é precisa: como a porta pode ser utilizada por todos, um mísero minuto de diferença entre os relógios dos servidores pode mudar completamente a resposta!

4) CGNAT com range fixa de portas de origem para cada IP privado: Solução profissional! Você divide, por exemplo, 32 IPs privados para cada IP público. O IP 10.0.0.50, por exemplo, vai sempre usar as portas 40.000 até 42.000. Assim que chegar o ofício pedindo quem estava navegando no IP público 200.200.200.10 às 19:01:10 do dia 15/05/2021 com a porta de origem 41.500, basta você olhar quem era o cliente com o IP 10.0.0.50 nesse mesmo horário! Simples, rápido e confiável!

Disponibilizamos um gerador de CGNAT com range fixa! Basta completar os dados do formulário que será feito um script para seu Mikrotik!

.
Resumindo:

  • Guarde seus logs em horário UTC

  • Só use o horário do seu roteador se tiver certeza de que ele está SEMPRE correto!

  • Se não quiser dor de cabeça, use o RadiusNet – já temos a solução pronta!

  • Se não tem IPs públicos para todos os clientes, faça CGNAT com range fixa de portas por IP privado!

icone facebook icone instagram icone linkedin icone whatsapp