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

[Douglas Fischer]

Estes 100 bytes creio que decorram de uma modelagem de dados que preveja
uso de string para  campos como portas e endereçamento.

Esse volume de dados seria bastante reduzido usando armazenamento em hexa.

Mas deixo essa questão para os arquitetos....

/*Android told-me that this text should be at bottom.*/
Em 10/03/2014 20:04, "Paulo Henrique - BSDs Brasil" <paulo.rddck at bsd.com.br>
escreveu:

> Estou tentando imaginar a quantidade de espaço em disco requerida só para
> manter esses logs por 5 anos.
> Uma rede com 1000 usuarios, cada um com 100 sessões/por dia, cada sessão
> gerando 100bytes de log teremos:
> 1 dia = 10Mbytes
> 30 dias = 300Mbytes
> 365 dias = 3.65Gigabytes
> 5 anos = 18.25Gigabytes.
>
> A mais 18Gbytes não é nada, ok, mais estou limitando apenas em 100 sessões
> ( se for um usuário como eu creio que ultrapasso facilmente as 4000 sessões
> ) e 1000 usuários não é o suficiente para manter um provedor funcionando.
> Se levarmos em consideração uma empresa de pequeno porte ou um escritório
> com 40 a 50 pessoas usando e-mail e outros recursos 15000 sessões é o
> mínimo de se esperar, extrapolando significativamente os cálculos.
> E se analisarmos teremos também o aumento de processamento dos roteadores,
> aumento de trafego de gerencia !!
> Se um provedor tem capacidade para arcar com esses custo, creio que é mais
> barato tirar um ASN e usar um radius, tiraria 100 logs para apenas 1 log.
>
> Att. Paulo Henrique.
>
>
> Em 10/03/2014 18:18, Rubens Kuhl escreveu:
>
>> 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
>>>
>>>  --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>
> --
> Paulo Henrique.
> BSDs Brasil / UnixBSD.
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>