>>>> >>> 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 316...@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 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd