[GTER] QOS em P2P

[Thiago Zaninotti]

Rubens,

A idéia é boa, porém, no fundo existem muitos protocolos específicos que
usam inerentemente OpenSSL para prover segurança (PK + symmetric encryption
ou Pre-shared secret + symmetric encryption). Talvez liberar apenas 22, 80,
443, 25 (o Google usa SMTPTLS na 465/587-TCP), sem contar IMAPS, POP3S e
outros...

A coisa pode ficar ainda mais complexa se pensarmos em VPNs baseadas em SSL
que acabam utilizando o protocolo para prover serviços adicionais
(out-of-band) como PPP over SSL, etc (em portas diferenciadas)..

Existem muitos webmails que tbm permitem acesso em portas TCP não comuns --
especialmente configurações que evitam o problema de compartilhar múltiplos
"virtual hosts" em um mesmo IP (para prover certificados diferentes por
virtual host).

Enfim, a coisa é complexa -- apesar de gostar da sua idéia de pegar o agente
justamente no processo de "decryptor" (único payload estático -- "approach"
parecido a qualquer bom IPS)...

Abraços,
Thiago

-- 
Thiago Zaninotti,Security+,CISSP-ISSAP,CISM
Sr. InfoSec Professional

2008/5/20 Rubens Kuhl Jr. <rubensk at gmail.com>:

> Então liberar a assinatura de SSL nas portas como 22, 443 e as de
> e-mail e bloquear nas outras teria um efeito de poucas reclamações em
> acesso residencial, e grande efeito sobre uso de banda.
>
>
> Rubens
>
>
> 2008/5/19 Thiago Zaninotti <thiago at zaninotti.net>:
> > A característica de criptografia de alguns dos principais P2P são
> > fundamentadas no protocolo SSL (OpenSSL) e provavelmente não vai ser
> > recomendado bloquear nenhum das fases tradicionais do handshake (sob pena
> de
> > bloquear outros protocolos fundados na mesma tecnologia -- OpenSSH,
> HTTPS,
> > etc). Uma vez trocado o segredo compartilhado para criptografia
> simétrica, a
> > coisa acontece no "covert channel".
> >
> > []s
> > Thiago
> >
> > --
> > Thiago Zaninotti,Security+,CISSP-ISSAP,CISM
> > Sr. InfoSec Professional
> >
> > 2008/5/19 Rubens Kuhl Jr. <rubensk at gmail.com>:
> >>
> >> Uma teoria que eu nunca testei foi a de bloquear totalmente os
> >> torrents criptografados travando a negociação da criptografia, e
> >> sugerir aos usuários que reclamarem de problemas com torrents
> >> desabilitarem a criptografia, trazendo-os de volta ao controle por
> >> detecção de tráfego. Se alguém que tiver implementado esse controle
> >> quiser compartilhar essa experiência...
> >>
> >> Eu sou pessoalmente mais adepto da filosofia de priorizar os outros
> >> protocolos como sugerido abaixo.
> >>
> >>
> >> Rubens
> >>
> >>
> >> 2008/5/19 Tukso Antartiko <tukso.antartiko at gmail.com>:
> >> > Isso não segura torrent criptografado, pelo contrário, premia quem
> >> > utiliza por retirar banda dos demais. Não use estes filtros
> >> > agressivamente ou seus usuários se darão conta disso e quando precisar
> >> > realmente usar não haverá o que filtrar.
> >> >
> >> > Você pode inversamente dar maior preferência a outros protocolos:
> >> >  match protocol http
> >> >  match protocol dns
> >> >  match protocol ssh
> >> >  match protocol https
> >> >  match protocol imap
> >> >  match protocol pop3
> >> > (... os outros que esqueci)
> >> >
> >> > On 5/19/08, Alexandre Gorges <algorges at gmail.com> wrote:
> >> >> e assim melhorou?
> >> >>
> >> >> class-map match-any P2P
> >> >>  match protocol edonkey
> >> >>  match protocol kazaa2
> >> >>  match protocol bittorrent
> >> >>  match protocol fasttrack
> >> >>  match protocol gnutella
> >> >>  match protocol novadigm
> >> >>  match protocol winmx
> >> >> !
> >> >> !
> >> >> policy-map QoS_Limita_P2P
> >> >>  class P2P
> >> >>     police 5223500 conform-action transmit  exceed-action drop
> >> >>
> >> >>
> >> >> está funcionando a principio. irei acompanhar essa semana como se
> >> >> comporta.
> >> >>
> >> >>
> >> >> []´s
> >> >> Alexandre Gorges
> >> >>
> >> >> http://algorges.blogspot.com
> >> >>
> >> >> ----- Original Message -----
> >> >> From: "Eduardo Schoedler" <eschoedler at viavale.com.br>
> >> >> To: "Grupo de Trabalho de Engenharia e Operacao de Redes"
> >> >> <gter at eng.registro.br>
> >> >> Sent: Monday, May 19, 2008 5:32 PM
> >> >> Subject: Re: [GTER] QOS em P2P
> >> >>
> >> >>
> >> >> Tráfego torrent você já não pegaria por essas regras...
> >> >>
> >> >> Abraços.
> >> >>
> >> >>
> >> >> --------------------------------------------------
> >> >> From: "Alexandre Gorges" <algorges at gmail.com>
> >> >> Subject: [GTER] QOS em P2P
> >> >>
> >> >> Boa tarde,
> >> >>
> >> >> estou precisando limitar, uma fatia do meu link para o trâfego P2P.
> >> >> a ideia é limitar em 25% o trâfego P2P.
> >> >>
> >> >> Estive procurando na Cisco e encontrei o seguinte para ser feito no
> >> >> roteador.
> >> >>
> >> >> !
> >> >> class-map match-any P2P
> >> >>  match protocol edonkey
> >> >>  match protocol gnutella
> >> >>  match protocol fasttrack
> >> >>  match protocol kazaa2
> >> >>  match protocol napster
> >> >>  match protocol winmx
> >> >> !
> >> >> !
> >> >> policy-map QoS
> >> >>  class P2P
> >> >>   bandwidth percent 25
> >> >>
> >> >> Algúem utiliza essa forma de limite? Existe outro tipo de solução
> >> >> usando
> >> >> roteador Cisco ou Cisco ASA?
> >> >>
> >> >>
> >> >>
> >> >> []´s
> >> >> Alexandre Gorges
> >> >>
> >> >> --
> >> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >> >>
> >> >> --
> >> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >> >>
> >> > --
> >> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >> >
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> >
> >
> >
> >
>