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-boun...@fug.com.br [mailto:freebsd-boun...@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-boun...@fug.com.br [mailto:freebsd-boun...@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 <tro...@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 > > welk...@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