[GTER] Controle de banda - Trafego Bittorrent Criptografado

[Gilberto Almeida]

Valeu, Rubens.

Eu tinha pensado em fazer isso que você me falou de priorizar o trafego mais
importantes. Porém, o meu meu medo era não conseguir indentifcar os
protocolos HTTPS, SSH pelo L7-Filter. Mas, se você está  me dizendo que ele
consegue indentificar esse tipo de protocolo, então a solução vai ser essa
mesma.

Realmente, não trabalho com portas, porque vários programas P2P utilizam
portas reservadas para HTTP, FTP e etc, para conseguirem burlar velhos
limitadores de trafegos baseados em portas.

A idéia de identificar blocos designados aos bancos é boa. Porém, no meu
caso um pouco complicado porque possuímos vários servidores administrados.
Mas, posso desenvolver um solução em banco de dados que distribuiria as
informações para os servidores e atualizaria as regras do iptables
automaticamente.

Agradeço muito pela sua ajuda.

On 9/29/06, Rubens Kuhl Jr. <rubensk at gmail.com> wrote:
>
> > Pessoal, atuamente utilizamos o IPP2P para "segurarmos" o trafego p2p.
> > Porém, à partir do momento que os desenvolvedores de software bittorrent
> > (azureus,utorrent) e emule/edonkey começaram a criptografar o trafego
> p2p,
> > justamente para impedir essa indentificação pelo ipp2p e similares.
> Segundo
> > o desenvolvedor do ipp2p, no momento não é possível identificar esse
> > protocolos com o iptables.
> >
> > Alguém conhece alguma outra solução free semelhante ao ipp2p que possa
> > resolver este problema?
>
> Que tal "soltar" o tráfego não-P2P ao invés de "segurar" o tráfego P2P
> ? Use o IPP2P (e/ou o L7-Filter, http://l7-filter.sourceforge.net/)
> para identificar os protocolos que você quer dar boa performance
> interativa para seus clientes (http, smtp, pop3, telnet etc.), e
> coloque todo o resto numa vala comum.
>
> Para os tráfegos por natureza criptografados como SSH e SSL, a
> negociação os identifica também (tanto que há modulos de L7-Filter
> para eles), mas há de se verificar se os P2P não estão usando os
> mesmos parâmetros de negociação (por sorte me parece que não estão).
> Se isso acontecer, pode ser necessário usar o IP destino como
> parâmetro; por exemplo, tráfego SSL para os blocos IPs dos grandes
> bancos nacionais é algo para que o cliente espera boa performance.
>
> E em *nenhuma* hipotése use o número da porta como parâmetro. Isso não
> é representativo para tráfego entre computadores fora do seu controle
> (o do assinante, o do tracker, os dos leecher, os dos seeders...).
>
>
>
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>