[FUG-BR] sobre a captura logs e arquivamento.

Sexta Setembro 16 11:56:55 BRT 2011

>>>> 
>>> Oi Enio,
>>> 
>>> Aqui no provedor somos muitas vezes citados para problemas de justiça e
>>> normalmente o que nos é pedido é para identificar o assinante que estava
>>> utilizando aquele determinado IP na data e hora. O documento da justiça
>>> sempre nos passa a informação:
>>> 
>>> - IP
>>> - Data
>>> - Hora
>>> 
>>> Com esses dados conseguimos identificar o indivíduo. Com relação ao
>>> tempo que deve se manter os logs, nós aqui guardamos por 5 anos porque
>>> nossa justiça é muiiiiiiito lenta. Já recebi aqui intimações para
>>> identificar clientes que conectaram, por exemplo, à 2 anos atrás.
>>> Um grande problema é relacionado quando a empresa possui acesso por NAT
>>> N:1 nesse caso apenas 1 IP fica constando para a justiça e se o
>>> administrador não tiver log de acesso dos IPs internos aí fica bem
>>> complicado. Não é nosso caso aqui porque temos AS mas já vi muitos casos
>>> assim.
>>> Cuidado com logs do tipo do squid, porque as pessoas tem que saber que
>>> estão sendo monitoradas, salvo se você for autorizado pela Justiça à
>>> fazer esse tipo de coisa. Porque pode caracterizar uma invasão de
>>> privacidade. Melhor consultar um advogado antes de fazer qualquer coisa
>>> nesse sentido. Normalmente nas grandes empresas são feitos termos para
>>> os funcionários lerem, ficarem cientes e assinarem que estarão sendo
>>> monitorados quanto à e-mails(da empresa) e acessos. Termos de
>>> Confidencialidade e outros que a empresa julgar necessários. Trabalhei
>>> em uma empresa de Segurança da Informação onde tive que assinar um Termo
>>> de Confidencialidade de 3 anos, onde nesses 3 anos não poderia nem falar
>>> quais eram os nomes dos clientes que tínhamos. rsrsrsr
>>> 
>>> Agora se a justiça mandar e autorizar então faça. Porque manda quem pode
>>> e obedece quem tem juízo. hahahah
>>> 
>>> Uma vez fomos processados por um advogado pois o mesmo deu uma bobeada
>>> com a sua conta no gmail e entram e fizeram a festa. Ele conseguiu o IP
>>> de quem acessou a conta veio aqui no provedor e exigiu que disséssemos
>>> quem foi o cliente responsável. Bem sem uma intimação formal nada feito.
>>> Aí ele nos processou porque não passamos uma informação sigilosa para
>>> ele só porque ele era um advogado. Bem não precisa dizer que ele perdeu
>>> na justiça. No final das contas o IP de onde partiu o acesso era da
>>> própria OAB aqui da Cidade. Ou seja ele provavelmente acessou e-mail
>>> dele de lá, não fez logoff e aí alguém entrou e fez a festa. Só queria
>>> ver agora ele processar a OAB por isso.

Muito bom.

Concordo plenamente com os pontos do Gondim. Gerar logs com detalhes como URL acessada, Subject de e-mail (nem precisa do conteúdo) e qualquer outra informação que não seja técnica impressoal e não seja informação de comunicação fim-a-fim é um imenso risco jurídico pro provedor, é contra o 5 da constituição além de leis a rodo no codigo civil e penal.

Na prática hoje, o provedor não tem que ter log algum nem armazenar log algum por tempo que for. Essa decisão é do provedor para seu uso, seu diagnóstico, e não deve invadir a privacidade do usuário.

Mesmo que o Juiz, a PF peça a informação você não é obrigado a tê-la. Graças a Deus não passou a lei Azeredo e a Convenção de Budapeste se não me engano, Brasil não aderiu (ainda?).

Mediante mandato o provedor passa a monitorar e registrar o solicitado.

Claro que como medida pro-ativa, afinal pra não se enquadrado no 187/186 da civil pode gerar alguns logs, mas mantendo a impessoalidade.

É válido obvio manter o registro de quem estava usando qual IP. Fundamental alias, não juridicamente mas pro negócio.

É também legal e aceitável gerar logs da comunicação fim-a-fim sem informações pessoais. Ou seja:

- Endereço IP e porta, nada de URL, nada de conteúdo, de preferência nem resolução DNS.
- Envelope SMTP não pode (mail from, rcpt to, el), nada de headers, nem subject, pior ainda conteúdo; qualquer coisa desse tipo tem que ser prevista contratualmente (seja contrato de prestação do serviço ou contrato de trabalho, PSI corporativa, etc)

Minha sugestão pra quem faz NAT:

add count log tcp from any 80,21,22,443,25,110,143 to $minha_rede setup out via $if_interna

Note o fluxo: retorno, apenas portas conhecidas, suficiente pra saber qual IP falso falou com qual IP real nos serviços que potencialmente gerarão demanda indentificável. Além disso saindo pela interna, pra garantir que o NAT não foi feito nem desfeito e o principal, "setup" pra só gerar log do 3-way-handshake.

Se você não usa ipfw mas usa Linux, gere logs das flags syn+ack (que é o segundo passo do 3-way-handshake, ou seja a sessão na outra ponta foi aceita e está de fato estabelecida) e coloca um RELATED.

Se usa PF bailou, PF não co-relaciona 3-way-handshake como ipfw nem tem um related como Linux então o jeito é logar

flags SA/SA

E torcer pra ninguém gerar um flood aritifical de SA/SA sem S/SA antes pois você no pf simplesmente não conseguirá distinguir. Mas ok isso juridicamente não vem ao caso, log de "flags SA/SA" no pf resolve. 

Com isso teremos logs impessoais, fim-a-fim, e apenas 1 linha de log por sessão. Ninguém vai reclamar de invasão de privacidade e a empresa vai conseguir identificar o que precisar.

Aqui num provedor de 150Mbit/s de link essa regra gera cerca de 40 mil registros por minuto, cada log line tem cerca de 95 bytes por linha de log.

Vamos calcular a pior hipótese, do syslog duplicar todos os logs sem buffer "repeated X times":

95*40000
3800000
3800000*60
228000000
228000000*24
5472000000
5472000000*365
1997280000000
1997280000000/1024/1024/1024
1860

Ta ai, 1860GB por ano só pra manter esses logs, sem compactar. Como é texto isso vai cair pra 1.3TB pelo menos, com um bzip2 (sem -9 hehe).

Não é barato nem trivial manter esses logs, mas não é também uma dificuldade absurda nem um investimento que vá inviabilizar qualquer coisa, são 10TB pra 5 anos no máximo, nem precisa de performance nos discos, da pra fazer com pouco $$$.

Agora insisto: não passem da comunicação fim-a-fim.

Mais que isso é risco jurídico certo.

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

>>> 
>>> É isso e grande abraço
>>> -------------------------
>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>> 
>> 
>> 
>> 
>> Gondim, obrigado pelos esclarecimentos enriquecedores, tenho assunto para
>> uma boa discussão com o amigo delegado.
>> 
>> No caso do log do squid é fácil eu conseguir uma autorização. Quanto ao
>> email institucional, bem, penso eu que, se eu for gravar tudo que os
>> usuários enviam e recebe, vou pŕecisar de muito espaço, ou tem como eu
>> capturar apenas um log que registre por exemplo, de onde e para onde com a
>> data acho que já ajudaria. Mas eu penso no caso dos que usam email externo
>> do tipo hotmail, não teria como capturar muita coisa, a não ser a data e
>> hora que ele acessou o email.
>> 
>> Agora, no meu caso como não tenho AS o jeito é natear as conexões dos
>> usuários, e neste caso, como eu vou capturar tais informações? Penso eu que
>> bastaria setar a regra do nat para ser logado, e armazenar estes logs, estou
>> certo?
>> 
>> abraços
>> 
>> -- 
>> *ENIO RODRIGO MARCONCINI*
>> @eniomarconcini <http://twitter.com/eniomarconcini>
>> skype: eniorm
>> facebook.com/eniomarconcini <http://www.facebook.com/eniomarconcini>
>> 
>> *"UNIX was not designed to stop its users from doing stupid things,
>> as that would also stop them from doing clever things."
>> *
>> -------------------------
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"