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

[Braian]

Boa a dica Douglas,

Já pegamos casos similares aqui. Não sei exatamente a resposta que foi 
dada porque quem cuida disso é o pessoal jurídico, mas acredito que foi 
nesses mesmos moldes.

Braian Jacomelli
Analista de Redes

Em 21/11/2018 16:13, Douglas Fischer escreveu:
> 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
>>
>