[FUG-BR] RES: IPFW, protocolos obscuros, protocolos criptografados etc.

Renato Frederick frederick em dahype.org
Sábado Abril 18 18:27:21 BRT 2009


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



Mais detalhes sobre a lista de discussão freebsd