[FUG-BR] RES: RES: IPFW, protocolos obscuros, protocolos criptografados etc.
Renato Frederick
frederick em dahype.org
Domingo Abril 19 01:29:44 BRT 2009
Trober,
Você não pode colocar o emule dentro da limitação do cliente?
Ex, limitá-lo a 100k, indiferente se ele usa WEB,FTP ou P2P?
Se puder, um 'ipfw add pipe X all from IP_CLIENTE to any'(e a volta)
funciona.
Se não puder, creio que a única solução seria:
Ipfw add pipe X all from IP_CLIENTE 1024-65535 to any 1024-65535... mas isto
pegaria outros programas "legítimos" que usam porta alta, MSN, TSCLIENT,
CITRIX, OPENVPN.
> -----Mensagem original-----
> De: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br] Em
> nome de Trober
> Enviada em: domingo, 19 de abril de 2009 00:56
> Para: FUG-BR
> Assunto: Re: [FUG-BR] RES: IPFW, protocolos obscuros, protocolos
> criptografados etc.
>
>
> Olá Welkson.
>
> Isso mesmo! Tudo perfeitamente controlado em 256kbps, mas BitTorrent,
> eMule, uTorrent estourando em quase 3mbps.
>
> Li seu tópico sobre o Orbit, e tem bastante similaridade com a anomalia
> que apresentei. Farei testes agora durante a madrugada, e reportarei o
> resultado assim que solucionado.
>
> A idéia também é de não bloquear P2P, mas colocar "rédeas na mulinha"
> do
> eMule e seus amigos vorazes :)
>
> Olá Renato.
>
> Em relação ao ipfw-classifyd, até onde sei (talvez por engano), ainda
> há
> limitações com tratamento de obfuscações e encriptações.
>
> Supondo que o RC4 ou qualquer outro algoritmo criptográfico usado em
> P2P
> seja quebrado, mesmo que somente em cada início de sessão ao invés de
> cada
> pacote trafegado, seria, computacionalmente falando, muito oneroso,
> principalmente se considerados fatores como limitações dos computadores
> contemporâneos e realidade financeira.
>
> Aos demais.
>
> Espero tão logo escrever no título da mensagem o tal do "resolvido" :P
>
> Grande abraço a todos.
>
> Saudações,
>
> Trober
> -
> -
> -
> -
> -
>
>
> > Renato Frederick escreveu:
> >> Na regra IPFW você usa como?
> >>
> >> Eu uso assim:
> >> pipe 111 ip from 172.16.20.6 to any in
> >> pipe 112 ip from any to 172.16.20.7 out
> >>
> >> isto funciona indiferente de obfuscacao ou não, já que ele continua
> usar
> >> datagrama IP. :)
> >>
> >> a obfuscacao vai deixar de funcionar se você utilizar algo L7 para
> fazer
> >> shapping ou usar range de portas. Neste caso, tem que partir para
> >> solução
> >> comercial mesmo, snort e afins não estão a par do tipo de protocolo
> >> usado
> >> pela obfuscacao ainda.
> >>
> >>
> >>
> >>> -----Mensagem original-----
> >>> De: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br]
> Em
> >>> nome de Trober
> >>> Enviada em: sábado, 18 de abril de 2009 14:55
> >>> Para: FUG-BR
> >>> Assunto: Re: [FUG-BR] IPFW, protocolos obscuros, protocolos
> >>> criptografados etc.
> >>>
> >>>
> >>> Olá Lauro :)
> >>>
> >>> Grato pelo retorno.
> >>>
> >>> Muito boa sua sugestão, mas, por enquanto, o objetivo é manter o
> >>> FreeBSD,
> >>> adotando uma solução não-comercial.
> >>>
> >>> Caso o IPFW se mostre incapaz de cumprir o propósito de controlar
> banda
> >>> de
> >>> protocolos obscuros e criptografados, partirei para algo comercial.
> >>>
> >>> Novamente agradeço sua sugestão.
> >>>
> >>> Grande abraço,
> >>>
> >>> Trober
> >>> -
> >>> -
> >>> -
> >>> -
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> www.hostcert.com.br
> >>>> Esse sistema faz o controle de trafego diferente, não utiliza
> ipfw.
> >>>>
> >>>> Ele segura 100% esses casos.
> >>>>
> >>>>
> >>>> 2009/4/18 Trober <trober em trober.com>
> >>>>
> >>>>
> >>>>> Prezados,
> >>>>>
> >>>>> Exponho um cenário anômalo, e serei grato pela opinião de vocês.
> >>>>>
> >>>>> Atendo um condomínio residencial que fornece internet
> gratuitamente
> >>>>>
> >>> aos
> >>>
> >>>>> moradores. Cada morador, ao assinar o contrato com o condomínio,
> >>>>>
> >>> opta
> >>>
> >>>>> por
> >>>>> informar o endereço físico (MAC) do computador, caso queira
> >>>>>
> >>> internet.
> >>>
> >>>>> As concessões, negações e limitações dos recursos de rede são
> >>>>> gerenciadas
> >>>>> por um servidor FreeBSD 6.4 (Stable), atuando como proxy
> >>>>>
> >>> transparente
> >>>
> >>>>> (Squid), roteador e controle e banda (IPFW).
> >>>>>
> >>>>> Tudo funcionava perfeitamente, principalmente na questão de
> controle
> >>>>>
> >>> de
> >>>
> >>>>> banda. Porém, conforme descreve Okamoto e seus colegas[1], há
> >>>>> bibliotecas
> >>>>> de aplicações P2P mais eficazes em TCP do que UDP (inclusive 7x
> mais
> >>>>> rápidas!). Os desenvolvedores de aplicações P2P perceberam isso
> e,
> >>>>>
> >>> aos
> >>>
> >>>>> poucos, estão abandonando o UDP, principalmente, devido ao fato
> de
> >>>>> muitos
> >>>>> administratores fecharem todas as portas UDP, exceto 53,67,68 e
> 123.
> >>>>>
> >>>>> Somado a isso, o eMule[2], há algum tempo, dispõe de um recurso
> >>>>>
> >>> chamado
> >>>
> >>>>> Obfuscation Protocol[3], que não era habilitado por padrão,
> ficando
> >>>>>
> >>> a
> >>>
> >>>>> critério do usuário habilitá-lo. Para completar o estrago, agora
> >>>>>
> >>> essa
> >>>
> >>>>> opção é padrão, e o BitTorrent[4] também entrou na onda da
> >>>>> obfuscação[5].
> >>>>>
> >>>>> Aqui começa a anomalia: Neste condomínio tem um morador com
> >>>>>
> >>> 256/128kbps
> >>>
> >>>>> de
> >>>>> banda (download e upload, respectivamente). Para todas as
> aplicações
> >>>>>
> >>> que
> >>>
> >>>>> ele usa, o controle de banda é obedecido perfeitamente, exceto
> para
> >>>>> eMule[2] e BitTorrent[4], aplicações que transferem dados em
> taxas
> >>>>>
> >>> quase
> >>>
> >>>>> 10 vezes maiores.
> >>>>>
> >>>>> O controle de banda está declarado/numerado no começo das regras,
> >>>>>
> >>> com
> >>>
> >>>>> one_pass desabilitado, tendo abaixo o desvio (fwd) do proxy
> >>>>> transparente,
> >>>>> desvio (skipto) do PrivateWire (Conectividade Social), divert de
> >>>>> entrada,
> >>>>> regras statefull e divert de saída.
> >>>>>
> >>>>> Sendo assim, agradeço novamente a opinião de vocês sobre quais as
> >>>>>
> >>> regras
> >>>
> >>>>> mais adequada para controlar essas aplicações e seus protocolos
> >>>>> obscuros.
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>>
> >>>>>
> >>>
> http://www2.lifl.fr/MAP/negst/secondWorkshop/slidesSecondWorkshopNegst/
> >>> TakayukiOkamoto.ppt
> >>>
> >>>>> [2] http://www.emule-project.net
> >>>>> [3] http://wiki.emule-web.de/index.php/Protocol_obfuscation
> >>>>> [4] http://www.bittorrent.com
> >>>>> [5] http://torrentfreak.com/how-to-encrypt-bittorrent-traffic/
> >>>>>
> >>>>> Grande abraço a todos,
> >>>>>
> >>>>> Trober
> >>>>>
> >>>>> -
> >>>>> -
> >>>>> -
> >>>>> -
> >>>>> -
> >>>>>
> >>>>>
> >>>>> -------------------------
> >>>>>
> >>>>
> >>>> --
> >>>> Lauro Cesar de Oliveira
> >>>> http://www.gurulinux.blog.br
> >>>> Hack to learn not learn to hack.
> >>>> -------------------------
> >>>>
> >>>>
> >>> -------------------------
> >>>
> >>
> >> -------------------------
> >>
> >>
> >>
> > Renato,
> >
> > Achei estranho quando ele fala que a aplicação consome 10x mais
> banda...
> > como se ele tivesse liberado 256 para o cara e o p2p estivesse usando
> > quase 2 MB... eh isso mesmo?
> >
> > Se for pode ser a regra do dummynet errada... dar uma olhada em um
> > tópico que abri esses dias sobre dummynet... eu havia errado a
> netmask
> > do pipe, os testes de velocidade mostravam a velocidade correta...
> mas
> > um orbit da vida baixava a uma velocidade ENORME... após a correção
> > ficou tudo ok.
> >
> > Não vai bloquear o p2p.. mas se tu limitar a 256 ele só vai baixar a
> > 256...
> >
> > Uma outra coisa que ele pode testar é aquele projeto de L7 para ipfw
> que
> > estava em testes outro dia... para um tráfego pequeno como o dele
> > provavelmente resolve. (ou fica igual ao linux com patch L7)
> >
> > --
> > Welkson Renny de Medeiros
> > Focus Automação Comercial
> > Desenvolvimento / Gerência de Redes
> > welkson em focusautomacao.com.br
> >
> >
> >
> > Powered by ....
> >
> > (__)
> > \\\'',)
> > \/ \ ^
> > .\._/_)
> >
> > www.FreeBSD.org
> >
> >
> > -------------------------
> >
>
>
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Mais detalhes sobre a lista de discussão freebsd