Limitando o Kazaa

Introdução

Como já foi vimos, identificar um fluxo de dados do Kazaa não é uma das tarefas mais fáceis. O Bloqueio do Kazaa, por exemplo, foi feito apenas descartando-se pacotes que continham uma determinada string, no entanto a mesma estratégia não funciona quando se deseja limitar ("shapear") um fluxo Kazaa, porque apenas alguns pacotes no inicio do fluxo possuem a string. Nos roteadores Cisco mais "potentes" é possível habilitar uma feature chamada NBAR, que através dos primeiros pacotes de um fluxo, consegue reconhecer e "marcar" esse fluxo. Mas como não é todo mundo que tem um Cisco capaz de fazer isso, essa solução não pode ser amplamente aplicada. Recentemente um projeto chamado L7-filter trouxe pro Linux a capacidade de fazer algo bastante semelhante ao NBAR. E é essa solução que será apresentada aqui.

L7-filter

O projeto L7-filter visa criar um filtro nivel 7 (do modelo OSI) permitindo assim a identificação de aplicações baseando-se em padrões e não apenas na porta de origem/destino. Esse filtro complementa os recursos de QoS do linux. Basicamente o filtro procura reconhecer padrões dentro dos oito primeiros pacotes de um fluxo (Lembrando: o linux faz o acompanhamento de um fluxo através das tabelas de conntracking). Uma vez reconhecido os padrões, o fluxo é "marcado" e não há mais necessidade de se inspecionar os pacotes individualmente e esse fluxo pode ser submitido a uma política/disciplina de QoS suportada pelo Linux, como por exemplo CBQ ou HTB.

Pré-requisitos

Para implementar essa solução será necessário:

kernel > 2.5.68 (testei com o 2.6.0-test2)
l7-filter patch http://l7-filter.sourceforge.net
l7-filter patterns
iproute com patch do l7-filter (disponível no site do L7-filter )

Instalação

Descompacte o kernel e em seguida aplique o patch do l7-filter. Configure o kernel com suporte a connection tracking (Networking Support-->Networking Options-->IP: Netfilter Configuration-->Connection tracking (and FTP, IRC, etc)), mas atenção, isso tem que ser compilado "built-int" e não como módulo! Habilite também o suporte a QoS ? (Networking Support-->Networking Options-->QoS and/or Fair Queueing) e dentro dele o suporte ao l7-filter (claro...). Compile e instale o seu kernel.

Descompacte e compile/instale o iproute com patch do l7-filter. Sem isso você não será capaz de criar os filtros l7.

Descompacte os padrões de filtro l7 (sugestão: /etc/l7-filter/patterns).

Bridge ou roteado?

A máquina que vai fazer o shaping vai precisar ser colocada na saída da sua rede (óbvio...). E isso pode ser feito de duas maneiras: ela pode ser configurada como um roteador (uma interface com um ip da rede interna e outra com a da rede externa), ou pode ser configurada como uma bridge! Pode parecer um pouco estranho, afinal nós sempre aprendemos que uma bridge é nível 2, mas no Linux o código de firewall QoS também funciona com bridge!

Eu optei por configurar minha máquina de teste como uma bridge porque assim basta eu espetar ela em qualquer rede, sem ter que modificar em nada a topologia da rede. Infelizmente o código atual de bridge to Linux tem um bug que não permite que você coloque um ip na bridge, logo a sua máquina ficará sem gerenciamento remoto (a não ser é claro que vc coloque mais uma placa de rede somente pare esse propósito!).

Para configurar a máquina como bridge será necessário ter instalado o pacote bridge-utils. Para configurar basta fazer:

 
  # brctl addbr my
  # brctl addif my eth0
  # brctl addif my eth1
  # ifconfig eth0 up
  # ifconfig eth1 up

Configuração

Vamos então a parte que interessa: shapear o kazaa! A primeira coisa a fazer é carregar os padrões de reconhecimento. Isso é feito de maneira bastante simples, bastanto apenas fazer um "cat" dos padrões para /proc/net/layer7_protocols, como no exemplo abaixo:

  # cat /etc/l7-filter/patterns/*.pat > /proc/net/layer7_protocols

Em seguida crie suas classe/disciplinas de QoS. Para saber mais sobre isso consulte o Linux Advanced Routing & Traffic Control. Segue um exemplo:

 
  # tc qdisc add dev eth0 root handle 1: htb default 30
  # tc qdisc add dev eth1 root handle 1: htb default 30
  # tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
  # tc class add dev eth1 parent 1: classid 1:1 htb rate 100mbit
  # tc class add dev eth0 parent 1:1 classid 1:20 rate XXmbit
  # tc class add dev eth1 parent 1:1 classid 1:21 rate XXmbit
  # tc class add dev eth0 parent 1:30 classid 1:30 htb rate 100mbit
  # tc class add dev eth1 parent 1:30 classid 1:30 htb rate 100mbit

  # tc filter add dev eth0 protocol ip parent 1:0 prio 1 layer7 protocol kazaa classid 1:21
  # tc filter add dev eth1 protocol ip parent 1:0 prio 1 layer7 protocol kazaa classid 1:20

Alguns detalhes: 100mbit é a velocidade da interface. Na classe 1:30 o correto seria usar a velocidade do seu link, e essa é classe default, ou seja tudo que não for kazaa vai nela. XXmbit é a velocidade que se deseja limitar o kazaa.

Obs: o leitor atento irá perceber que conceitualmente está errado aplicar um filtro numa interface, mas apontar para uma classe em outra interface. Eu concordo... mas assim funcionou.. e do outro jeito não!

Considerações finais

Embora eu tenha gasto um tempo considerável nessa solução, ainda faltam mais testes em condições "reais". O meu cenário de teste era bastante simples apenas a bridge e uma máquina com o kazaa. Se você testar essa solução em uma rede maior, por favor deixe um comentário nessa página contando a sua experiência! Embora o foco aqui tenha sido o kazaa, é possível aplicar o l7-filter para filtrar muitas outras coisas, bastando para isso escrever o padrão de casamento adequado. Olhe os padrões já existentes para ter uma idéia de como eles funcionam.

Seções: