[FUG-BR] RES: IPFW, protocolos obscuros, protocolos criptografados etc.
Trober
trober em trober.com
Domingo Abril 19 00:56:10 BRT 2009
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
>
>
> -------------------------
>
Mais detalhes sobre a lista de discussão freebsd