Marco Civil

[diegonaster]

Quem já está adequado ao Marco |Civil e registra conexões! Cuidado pode-se receber alguém na porta a procura de informações sobre delitos cibernéticos de dentro de sua rede!

[BimLinkse]

Acompanhando...

[fhayashi]

Registro no sistema de gestão as conexões e nat usando intervalo de portas.

[andrecarlim]

Cara, cometer um crime para fugir de outro não é a resolução do problema. É só usar cgnat com pilha dupla, e boa!

[diegonaster]

poderia explicar melhor...mais informações...('quem não tem AS e procura solução rápida para se Proteger ')

[andrecarlim]

então @diegonaster, o CGNAT ou LSN é uma técnica que consiste em fazer um NAT "deterministico", saliento que todas as formas de NAT em ISP, quebram os conceitos de isonomia, requerido pelo marco cívil, todavia, como o pessoal tem feito (e alguns bestas até defendido) o modo de log de conexões, é o modo mais imbecil de resolver esse problema, e eu afirmo isso categoricamente, até acho que quem faz isso é um criminoso de tão baixo nível quanto um traficante de drogas que leve menores ao uso! Se existe um modo, diga-se de passagem até fácil, porque sofrer e gastar uma grana lascada em equipamentos para armazenar log de conexões...

Mas falando tecnicamente, o CGNAT, diferentemente do NAT mais simples, significa dividir de modo estático um IP Público em dois ou mais clientes (acredito que a divisão mas adequada seja a razão de N * 2 = [ R [ * 2 ] * 2 ] ... ), por exemplo, a camada 4 do modelo OSI, nos protocolos TCP e UDP (maioria massiva dos serviços na internet usam eles), nos dá a possibilidade do uso de exatamente 65536 portas (sim, se você entender o conceito de unidades, de 0 a 65535 temos precisamente 65536 unidades, e zero tem valor sim!). No exemplo citado, você faria o cliente 1 usar, para os protocolos TCP e UDP, o intervalo de 0 até a 32767 (claro que as portas 0 e 1 não podem ser usadas, mas existem), e seguindo o raciocínio, o cliente 2 usaria o intervalo de portas compreendido entre 32768 até 65535, desse modo, cada um fica "preso" ao seu intervalo, e sempre que algum site for acessado por um deles, o IPv4 público usado será o mesmo, porém a porta de origem usada será a correspondente ao seu intervalo. Desse modo se for necessário identificar um abuso partindo da sua rede, precisamos além de saber o horário e o IPv4 Público utilizado, também precisaremos saber qual a porta de origem foi usada no citado acesso, Já protocolos como ICMP, GRE e alguns outros, terão que receber um NAT mais "genérico" (esse é o grande problema do NAT/CGNAT/NAT44/NAT444/LSN, quebra o modelo fim a fim estabelecido pelo IETF). Sendo assim, não se precisa de log, log é coisa de preguiçoso (ou sovina, que não quer gastar com um bom profissional para fazer isso funcionar).

Como em tempos de escassez de IPv4, geralmente se utiliza um intervalo de portas menor para dividir entre os assinantes, por exemplo, se você usar um intervalo de 2048 por assinante, poderá dividir até 32 assinantes por IPv4, se almejar um intervalo de 1024 portas, chegará ao número de 64 assinantes por IPv4 público, eu já fiz até com 512 portas e funcionou de boas. Para o pequenino provedor que tem até 500 assinates pode-se chegar a bons resultados com um bloco /28, por exemplo, que divindo-se por 2048 portas por assinante, poderiamos atender até 512 clientes, se diminuir para 1024 portas, chegará ao número 1024 assinantes com apenas um bloco /28 e tendo a possibilidade de identificação em caso de abuso (claro, se precisa de um histórico de autenticações, que não é log de acesso e sim autenticação, conhecido como Radius Accounting).

Devemos lembrar que o CGNAT veio como medida a prolongar o "natimorto" IPv4, e que em hipótese alguma deve ser encarado como solução de um problema, e sim como ajuda na transição para o IPv6, tanto se diz isso, que o CGI.br já fez um vídeo explicando isso e recomendou de maneira pontual o uso de Dual-Stack (ou pilha dupla, nome da técnica que refere-se ao uso simultâneo de IPv4 e IPv6 na rede de acesso). Então amigos não vamos piorar mais uma situação que nós mesmo causamos pela nossa falta de responsabilidade, vamos nos esforçar para fazer da internet um lugar melhor, e mais digno de uso!

Vou deixar dois links de uma boa leitura:
https://pt.wikipedia.org/wiki/Carrier_Grade_NAT
http://labcisco.blogspot.com/2014/09...-ou-vilao.html

Vídeo que trata de modo objetivo o assunto:

[fhayashi]

Ué, cgnat precisa do log de conexões. Como saber qual nat ele fez sem saber qual conexão PPPoE ele esta?

[andrecarlim]

Cara, não vou nem falar nada... Se depois de tudo que eu falei, ainda não foi possível entender, não tenho mais o que dizer.

Se você usar cgnat você não tem necessidade de log de conexões (não confundir com log de autenticação). Você pode usar, mas não precisa, e estará cometendo um crime.

E se você quiser usar log de conexões (algum tipo de flow), não precisa de cgnat.

[fhayashi]

Bom, acho que tem uma confusao semântica aqui. Afinal, 99% dos docs chama este log de autenticação como registro de acesso.

Ninguém deve ser louco de fazer log dos hits

[diegonaster]

humm..entendi, mas no caso do provedor tem apenas 1 ip valido...no caso do cgnat, como iria e onde iria consultar a porta que o cliente usou, na topologia borda e vários concentradores, acho que ainda precisara de um servidor centralizado de logs.

tenho montado aqui no seguinte esquema, a borda registra tudo..e encaminha para servidor de logs...só que ainda não é possível determinar da onde partiu a "tal conexão" pois pppoe dinâmico distribuindo ip em faixa local e o MAC que chega ate a Borda é do concentrador. com o horário e o ip que acessou a "tal conexão" registrado no log dai só olhar no histórico de autenticação do radius determino o cliente de onde partiu a conexão..

[andrecarlim]

Bom, acho que tem uma confusao semântica aqui. Afinal, 99% dos docs chama este log de autenticação como registro de acesso.

Ninguém deve ser louco de fazer log dos hits

Cara, é precisamente isso que fazem, registrando toda a conntrack. Por isso é um crime. E não existe log acesso, o que existe é log de autenticação. Nem sei de onde veio esse tal log de acesso...

[andrecarlim]

humm..entendi, mas no caso do provedor tem apenas 1 ip valido...no caso do cgnat, como iria e onde iria consultar a porta que o cliente usou, na topologia borda e vários concentradores, acho que ainda precisara de um servidor centralizado de logs.

tenho montado aqui no seguinte esquema, a borda registra tudo..e encaminha para servidor de logs...só que ainda não é possível determinar da onde partiu a "tal conexão" pois pppoe dinâmico distribuindo ip em faixa local e o MAC que chega ate a Borda é do concentrador. com o horário e o ip que acessou a "tal conexão" registrado no log dai só olhar no histórico de autenticação do radius determino o cliente de onde partiu a conexão..

1 IP válido não serve pra cgnat, rsrs, na verdade, não serve pra nada.