[GTER] CGNAT, Logs de Conexão e Portas Lógicas

Wed Nov 21 16:13:34 -02 2018

Existe um princípio no direito, que não me lembro o nome afrescalhado em
latin, que é mais ou menos assim:
"Não complica se não precisa!" ou "Só complica o que realmente precisa ser
complicado!"
hahaha

Digamos que o Juiz te mande uma lista solicitando os contratantes(ver obs.)
de 3 endereços IPs com os horários certinho como manda o figurino, e que
esse IPs sejam do seus blocos de IP.
Digamos que 2 desses IPs sejam do pool de endereço Válido entregue ao
provedor, e 1 deles seja do Pool de CGNAT.
Faz sentido você não informar os nomes dos endereços de todos os 3 IPs, se
pelo menos 2 você já tem como informar?

Nesse caso, como já aconteceu com cliente meu, eu recomendo responder algo
mais ou menos assim:

---
Respondendo a ordem judicial/mandato/intimação expedida pelo excelentíssimo
Sr Juiz Gilmar Mendes informamos que verificamos que em nosso sistemas de
gestão está registrado que:
 - O endereço IPv4 X.Y.Z.(A) na data tal entre as horas tal e tal está
atribuído ao cliente "Fernadinho Beira Mar" registrado com o CPF
XXX.YYY.ZZZ-WW.
 - O endereço IPv4 X.Y.Z.(B) na data tal entre as horas tal e tal está
atribuído ao cliente "Escadinha" registrado com o CPF XXX.YYY.ZZZ-WW.

Informamos também que necessitaremos de mais informações técnicas para
poder determinar exatamente de qual cliente partiram as conexões originadas
do endereço de IP X.Y.Z.(C).
Isso se deve ao fato de que, devido a exaustão de endereços IPv4, este
endereço está sendo utilizado em uma técnica de CGNAT, o que significa que
para determinar exatamente de qual cliente partiram as conexões
necessitaremos de:
 - Endereço de IP de Origem(Já informado)
 - Data e hora da conexão (Já informado)
 - Protocolo, mais comumente sendo TCP/UDP mas podendo se uma grande gama
de protocolos.
 - No caso de ser TCP/UDP, a porta de origem da conexão.
---

Em qua, 21 de nov de 2018 às 14:54, Braian <pbraian at tcheturbo.com.br>
escreveu:

> Acho que é isso mesmo,
>
> Mas minha dúvida é a seguinte, na solicitação de identificação do
> usuário deve constar o protocolo? O que vemos hoje (aqui na nossa
> região) são solicitações muito básicas, constando apenas IP de origem.
> Nada de portas, se já é difícil explicar para o delegado que a
> solicitação deve conter as portas de origem, imagina explicar que
> precisa também do protocolo?
>
> Eu concordo com o que você citou como atenuante Douglas, porém,
> dificilmente nas solicitações que recebemos para identificação de
> usuário consta qual foi o protocolo de camada 7, então, possivelmente
> caímos na situação de 2:1.
>
> Braian Jacomelli
> Analista de Redes
>
> Em 21/11/2018 10:24, Douglas Fischer escreveu:
> > Sim, mas isso é intrínseco ao conceito!
> > Necessariamente quando se fala em Porta, é necessário falar em Protocolo.
> > Ou... como se faria um PAT sem definir protocolo?
> >
> > Mas entendo sua colocação.
> > Para um leigo, as palavras "portas", "protocolo", "endereço", são
> > "tudo a mesma coisa". hehe...
> >
> >
> > Um atenuante para a não explicitação dessa informação são:
> >   - Existem(atualmente) basicamente 2 protocolos que usam portas.
> >     - Mesmo que não especifiquem e o BAP atribua o mesmo range UDP e TCP
> >       para usuários diferentes, isso restringiria a apenas 2 assinantes.
> >       Muito mais razoável que os 1:64 que ando vendo por aí.
> >   - Pelo protocolo de camada 7 é possível inferir qual foi o protocolo de
> >     camada 4 que foi utilizado:
> >     SSH -> TCP
> >     HTTP/HTTPS -> TCP
> >     QUIC -> UDP
> >     DNS -> cumpricô
> >
> >
> >
> >
> >
> > Em qua, 21 de nov de 2018 às 09:33, Braian <pbraian at tcheturbo.com.br>
> > escreveu:
> >
> >> Sobre o assunto CGNAT, estou testando o Bulk em roteadores Cisco ASR e
> >> percebi que eles muitas vezes entregam o mesmo bloco de portas para
> >> endereços diferentes, desde que o protocolo não seja o mesmo. Por
> >> exemplo, um cliente pode receber o bloco 48128-48639 TCP e outro receber
> >> esse mesmo bloco UDP, ambos saindo para a internet com o mesmo IP
> publico.
> >>
> >> Nesse caso, a identificação dependeria de saber, além da porta de
> >> origem, o protocolo, correto?
> >>
> >>
> >> Att. Braian Jacomelli
> >> Analista de Redes
> >>
> >> Em 19/11/2018 01:06, Fernando Frediani escreveu:
> >>> Olá.
> >>>
> >>> Complementando a mensagem anterior e respondendo algumas questões
> >>> colocadas.
> >>>
> >>> De fato em alguns dos casos que pude verificar a solicitação acaba
> >>> vindo sem a informação da porta de origem. Isso pode ser dar tanto
> >>> pela falta de informação sobre esta necessidade por parte da pessoa ou
> >>> autoridade que solicita, quanto da recusa por parte do Provedor de
> >>> Conteúdo em fornecer ou sequer possuir a informação. Em um dos casos
> >>> aconteceu do juiz não acreditar na necessidade da porta de origem para
> >>> identificação do usuário e insistir que a identificação deveria ser
> >>> feita sem conseguir compreender ser materialmente impossível no caso
> >>> de uso de CGNAT sem o fornecimento da porta de origem pelo provedor de
> >>> conteúdo.
> >>> Isso é muito grave e acaba gerando uma grande desinformação que
> >>> precisa ser desfeita em algum momento sob pena do juiz continuar
> >>> acreditando que o provedor de acesso esta se recusando a cumprir a
> >>> ordem e aplicar algum tipo de punição.
> >>>
> >>> Quando se deparar com esse tipo de situação e caso não for possível
> >>> identificar o usuário por se tratar de CGNAT é necessário explicar ao
> >>> juiz em detalhes as razões técnicas da impossibilidade do cumprimento
> >>> daquela determinação. Além da sua própria explicação considero também
> >>> bastante importante citar o Relatório do Grupo de Trabalho para
> >>> Implantação do IPv6 composto por NIC.br, ANATEL e prestadoras que diz
> >>> de maneira bastante clara que a guarda da porta de origem é "requisito
> >>> necessário" para que se viabilize a quebra do sigilo nos casos
> >>> previsos legalmente, tanto para provedores de conteúdo quanto para de
> >>> acesso e em último caso, se necessário, envolver perícia técnica.
> >>> O conteúdo desta informação no relatório pode ser encontrado às
> >>> páginas 7, 8, 9 e principalmente na 14 que contém uma excelente
> >>> explicação mais detalhada sobre a necessidade da porta de origem para
> >>> identificação do usuário no caso de CGNAT.
> >>>
> >>> Por isso é importante no caso dos Provedores de Acesso possuírem toda
> >>> a sistemática necessária para registro das portas de origem utilizadas
> >>> pelos usuários, seja através de CGNAT Bulk ou Determinístico sendo
> >>> assim possível demonstrar de maneira inconteste que a empresa cumpre
> >>> integralmente o determinado pelo Marco Civil da Internet e está apta a
> >>> realizar qualquer identificação que seja requisitada desde que de
> >>> posse das informações mínimas necessárias para isso.
> >>>
> >>> Fernando Frediani
> >>>
> >>>
> >>> On 14/11/2018 17:26, Fernando Frediani wrote:
> >>>> Olá a todos.
> >>>>
> >>>> É crescente o número de Provedores de Internet que têm recorrido à
> >>>> técnica do CGNAT como forma de continuar oferecendo acesso em IPv4.
> >>>>
> >>>> Desde que comecei a estudar este assunto assim como as implicações do
> >>>> Marco Civil da Internet, tenho acompanhado de perto discussões e
> >>>> debates a respeito de detalhes, tanto técnicos quanto legais que
> >>>> devem ser levados em conta quando se adota esta estratégia. Quero
> >>>> compartilhar com vocês um dos pontos que é bastante importante notar
> >>>> desde o início de qualquer implantação de CGNAT. Existem vários
> >>>> outros que são igualmente importantes mas neste texto vou me ater a
> >>>> apenas um, os Logs Conexão.
> >>>>
> >>>> Já é ponto passivo que há a necessidade legal para qualquer Sistema
> >>>> Autônomo, imposta principalmente pelo Marco Civil da Internet, de se
> >>>> guardar o registro de conexão dos usuários, independente da
> >>>> utilização de CGNAT ou IPv4/IPv6 Público. Isto é, o registro de qual
> >>>> endereço IP foi entregue a um determinado cliente no momento que ele
> >>>> se autenticou permitindo assim a sua identificação. Algumas pessoas
> >>>> confundem isso com registrar todas conexões abertas pelo usuário no
> >>>> decorrer do uso da Internet. Não se trata disso e inclusive é vedado
> >>>> sob pena de se violar a privacidade do usuário dependendo de como
> >>>> feito. Via de regra você precisa apenas ter registrado o endereço IP
> >>>> utilizado por ele para posterior identificação, caso haja uma demanda
> >>>> legal para tal.
> >>>>
> >>>> O problema, como a maioria aqui sabe, é que quando se utiliza CGNAT
> >>>> somente o registro de 1 endereço de IP Público não é suficiente para
> >>>> identificar o usuário. É necessário guardar também a porta de ORIGEM
> >>>> por ele utilizada.
> >>>> O pessoal da área jurídica costuma se referir à isso como "Portas
> >>>> Lógicas", talvez você já tenha ouvido falar.
> >>>>
> >>>> E é nesse ponto que ainda existem divergências à respeito desta
> >>>> obrigatoriedade. Alguns dizem que a interpretação literal da Lei não
> >>>> fala nada sobre as "Portas Lógicas", outros no entanto dizem que é
> >>>> necessário também interpretar a Lei e se perguntar: "Qual é a
> >>>> essência da Lei ?". E uma das essências da Lei para muitos é
> >>>> justamente a identificação do usuário, portanto neste ponto de vista
> >>>> ela obriga sim a guarda também das portas de origem.
> >>>>
> >>>> Lendo a lei de maneira fria de fato ela não cita nada específico
> >>>> sobre portas lógicas, porém ela dá uma série de indicações sobre isso
> >>>> como por exemplo quando cita termos como "código atribuído a um
> >>>> terminal da uma rede para permitir a sua identificação".
> >>>> Ademais uma Lei, sobretudo regulando questões que envolvem
> >>>> tecnologia, não pode em deve ser tão específica que a engesse frente
> >>>> às rápidas evoluções tecnológicas. O CGNAT é apenas uma solução
> >>>> técnica para um problema que ainda não era tão latente à época da
> >>>> escrita da Lei. Ainda sim não tira o mérito dela de exigir a
> >>>> identificação do usuário para aqueles que a interpretam dessa
> >>>> maneira, em que pese a evolução tecnológica ocorrida desde a sua
> >>>> entrada em vigor.
> >>>>
> >>>> Tenho percebido que em determinas situações há ainda certa
> >>>> resistência por parte de alguns Provedores de Conteúdo de registrar a
> >>>> porta de origem e é ai que existe um número razoável de contestações
> >>>> sobre essa necessidade. Particularmente não creio que isso se deva à
> >>>> falta de vontade de colaborar com uma investigação mas apenas com o
> >>>> trabalho necessário envolvido para se adaptar um determinado sistema
> >>>> ou plataforma para incluir aquele registro nos logs.
> >>>> No entanto fácil ou difícil de se realizar essa adaptação, uma Lei
> >>>> uma vez aprovada e sancionada não se importa com isso, ela apenas
> >>>> exige que se cumpra.
> >>>>
> >>>> Outra situação que tem se mostrado comum, desta vez para Provedores
> >>>> de Acesso, é não haver o registro da porta de origem e acabar se
> >>>> entregando à autoridade solicitante a identificação de todos os
> >>>> usuários que estavam compartilhando aquele endereço de IPv4 Público
> >>>> em determinado momento, sejam eles 16, 32, 64 clientes. Infelizmente
> >>>> isso não atende à solicitação por completo, não ajuda muito à
> >>>> solucionar um crime eventualmente já cometido e ainda acaba
> >>>> suscitando dúvidas à respeito da violação da privacidade de outros 31
> >>>> usuários que não tinham nada à ver com aquela investigação, no caso
> >>>> do CGNAT ser 1:32 por exemplo.
> >>>>
> >>>> Lembrando que caso a interpretação da Lei feita pelo juiz for de que
> >>>> a essência dela é a identificação do usuário, entregar uma lista de
> >>>> 16, 32 ou 64 clientes não faz o provedor estar em acordo com a Lei e
> >>>> ainda deixa em aberto a possibilidade de se aplicar sanções desde
> >>>> advertência, multa e até outras mais graves.
> >>>>
> >>>> Em recente decisão o STJ (Superior Tribunal de Justiça) determinou
> >>>> que deve haver o armazenamento da porta lógica (porta de origem) sob
> >>>> pena de violação da identificação do usuário. Também já é possível
> >>>> encontrar diversas decisões de Tribunais de Justiça dos Estados neste
> >>>> mesmo sentido. É possível encontrar também em alguma decisões
> >>>> judiciais citações ao relatório do Grupo de Trabalho para Implantação
> >>>> do IPv6 composto por NIC.br, ANATEL e prestadoras que diz que a
> >>>> guarda da porta de origem é "requisito necessário" para que se
> >>>> viabilize a quebra do sigilo nos casos previsos legalmente, tanto
> >>>> para provedores de conteúdo quanto para de acesso.
> >>>>
> >>>> Independente da sua interpretação eu gostaria de convidá-lo à fazer
> >>>> um raciocínio lógico e rápido: será que vale a pena não ter o
> >>>> registro das portas de origem e continuar com a possibilidade de ter
> >>>> que lidar com possíveis demandas legais que cedo ou tarde virão e ter
> >>>> que se explicar para a autoridade que você não considera necessário
> >>>> guardá-las ?
> >>>> Lembre-se que dentre essas pessoas que farão a demanda (delegados,
> >>>> promotores, defensores, advogados de defesa da uma vítima de um crime
> >>>> e até mesmo o juiz) pode haver quem não aceite bem a interpretação
> >>>> que não é necessário guardar a porta de origem.
> >>>> Ou será que é muito mais produtivo ter este detalhe extra nos seus
> >>>> logs, entregá-los a quem solicitar sempre sob determinação do juiz e
> >>>> terminar a sua parte por ali ?
> >>>>
> >>>> Lembre-se que colaborando com a investigação de um crime não
> >>>> significa apenas estar de acordo com uma Lei, mas principalmente
> >>>> estar cumprindo uma função social de auxiliar a trazer justiça para
> >>>> aquela situação.
> >>>>
> >>>> Saudações
> >>>> Fernando Frediani
> >>>>
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >> ---
> >> Este email foi escaneado pelo Avast antivírus.
> >> https://www.avast.com/antivirus
> >>
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação