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: [email protected] [mailto:[email protected]] > 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 > [email protected] > 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 > [email protected] > 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 ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
