[GTER] Iminência da Votação do Marco Civil

[Rubens Kuhl]

Não se você já não guardar IP destino / porta destino. Zere isso nos flows
armazenados.

Rubens



2014-03-10 18:09 GMT-03:00 Douglas Fischer <fischerdouglas at gmail.com>:

> Exato Rubens!
>
> Mas e no caso 2, aonde se estará fazendo o log de conexões para precaver-se
> de futuras demandas judiciais. Não vou estar desrespeitando a questão da
> privacidade do usuário?
>
>
> Em 10 de março de 2014 18:05, Rubens Kuhl <rubensk at gmail.com> escreveu:
>
> > >
> > > De acordo com o último texto proposto, pelo que entendi o registro de
> > > conexão não será permitido a não ser que seja necessário por algum
> outro
> > > serviço. E deve ser autorizado pelo usuário ou então purgado pelo
> > provedor
> > > de serviço.
> > >
> > > Mas aí eu pergunto, e o iminente fim do IPv4 e inevitável utilização de
> > > NAT?
> > > Só o CG-NAT vai garantir a rastreabilidade das conexões em demandas
> > > judiciais?
> > >
> >
> > O que se precisa logar com NAT (CG ou não)  além do IP origem é a porta
> > origem.
> > E tem dois jeitos de fazer isso:
> > 1) Garantir por construção que determinada porta origem sempre venha do
> IP
> > privado X. Por exemplo, IP 1 portas 1000-1999, IP 2 2000-2999 e assim por
> > diante.
> > 2) Logar a tabela de translações, por exemplo com Netflow como já citado,
> > mas descartando IP destino e porta destino. Manter registro de qualquer
> dos
> > atributos destino é não estar de acordo com o dispositivo sobre registro
> de
> > conexão.
> >
> > No começo vai haver muita requisição de informações sem porta origem, até
> > que os provedores de serviço se habituem a logar porta origem além do IP
> > origem, mas isso deve se difundir com o tempo.
> >
> >
> > Rubens
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>