[FUG-BR] RES: IPFW, protocolos obscuros, protocolos criptografados etc.
Welkson Renny de Medeiros
welkson em focusautomacao.com.br
Sábado Abril 18 18:40:36 BRT 2009
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.
>>> -------------------------
>>>
>>>
>> -------------------------
>> 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
>
>
>
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