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

Sexta Setembro 16 12:17:49 BRT 2011

NAT é algo **terrível** para o usuário final e para o provedor...

Se alguém aqui tem provedor e ainda usa NAT, solicite já seu as + CIDR para o nic.br(aproveitem enquanto tem IPv4 hehehe) e conforme os colegas já comentaram,  também o bloco IPv6 e comece desde **já** a fornecer IPv4 e IPv6 nativo aos end users. Isto vai facilitar muito a transição para IPv6 em breve e discussões como esta virarão história para contar pros netos, já que tudo e todos terá seu IPv6 nativo.

Se o provedor não  atende aos requisitos mínimos para a solicitação do /22, pode pedir mais blocos IPv4 para a operadora atual e trabalhar junto com o PPPoE, fornecendo o pool de ips com base na média ponderada de acesso simultâneo.

Feito isto, basta salvar os logs do PPPoE ou DHCP, que são pequenos e não geram muito custo de processamento e entrega-los para a justiça, colaborando com a investigação. Vai que seu Provedor ajuda a capturar um marginal, a sociedade agradece.

Porém não acredito que um criminoso "barra pesada" seja tão ingênuo de assinar um acesso ADSL e de lá fazer suas ações, com certeza ele vai utilizar dezenas/centenas de proxies ao redor do mundo para encobrir suas ações e dificultar o rastreamento, principalmente se usar uma criptografia.

Dos casos que já participei, maior parte dos  IP´s envolvidos eram de PC´s Zombies de usuários domésticos, ou então casos menores do tipo  difamação em Orkut, etc... 

[]s

> -----Original Message-----
> From: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br]
> On Behalf Of Patrick Tracanelli
> Sent: sexta-feira, 16 de setembro de 2011 11:57
> To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Subject: Re: [FUG-BR] sobre a captura logs e arquivamento.
> 
> >>>>
> >>> 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!"
> 
> 
> 
> 
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd