[FUG-BR] RES: RES: IPFW, protocolos obscuros, protocolos criptografados etc.
Trober
trober em trober.com
Domingo Abril 19 19:00:43 BRT 2009
Olá a todos.
Resolvido o problema! Atribuí máscara e funcionou lindamente :D
O meu sistema de controle de banda tem bases no WARTA Project, e funcionou
muito bem por muito tempo, até apresentar o comportamento adverso /
anômalo / inadequado / (qualquer outro adjetivo) em relação aos P2P.
Pela madrugada fiz testes com BitTorrent, uTorrent, FDM, eMule, Kazaa,
Limewire e funcionou 100% o controle de banda ;)
A dúvida que ficou é a razão de alguns criarem a regra para depois criarem
o pipe. Se John Venn e eu não estivermos errados, a precedência e a
pertinência deveriam ser obedecidas.
Vejo, por aí, muitos exemplos (estranhos), assim:
#Download
ipfw add 1001 pipe 1 all from any to $varIP
ipfw pipe 1 config bw 256Kbit/s mask dst-ip 0xffffffff
Na minha lógica, se vou criar um regra associada a um pipe, este deve
existir ANTES da atribuição, conforme abaixo:
#Download
ipfw pipe 1 config bw 256Kbit/s mask dst-ip 0xffffffff
ipfw add 1001 pipe 1 all from any to $varIP
Então, John Venn revirou-se no caixão ou não? hehe
Para finalizar, meus agradecimentos a todos aqueles que diretamente ou
indiretamente ajudaram na resolução.
Grande abraço a todos.
Saudações,
Trober
-
-
-
-
-
> 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
>
> -------------------------
> 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