Cotidiano em Linux

Ano Novo, Casa Nova - www.linuxadm.com.br

2009-01-28T10:45:00.004-02:00

Prezados leitores e visitantes.

Infelizmente o blogger (blogspot) tem deixado a desejar, pois recebo muitos comentários e não é possível responder porque o mesmo não fornece um campo de comentários decente. (com email e etc..)
Além do que, procurando mais flexibilidade estou migrando o blog para Wordpress em domínio próprio, que por acaso estava registrado mas não estava sendo utilizado.
Espero também poder manter um nível mais frequente de postagem, portanto se desejar acessar a versão mais atual do blog queira utilizar o atual endereço.

http://www.linuxadm.com.br/

Um Abraço a todos, e obrigado pelos comentários.

RTL8139D (Chipset RTL Falso)

2008-08-21T20:30:00.004-03:00

Ao configurar um servidor, pedi ao cliente, que comprasse 2 placas de rede, preferencialmente com chipset Realtek por ser facilmente reconhecido, o que foi feito prontamente. Infelizmente o linux não detectou a placa, fui então até o site da Realtek para pegar o driver mais atualizado.
Como não obtive sucesso, apelei para o lspci e obtive a seguinte resposta:

01:00.0 Ethernet controller: Hangzhou Silan Microelectronics Co., Ltd. RTL8139D [Realtek] PCI 10/100BaseTX ethernet adaptor (rev 01)

Visto que o Linux não reconheceu a placa como Realtek, procurei por Hangzhou Silan, no google, e encontrei a verdade sobre a placa. O chipset em questão é falso, e para ser instalado deve ser compilado o driver correto (SC92031) já disponível nos ultimos kernels.

Resposta ao leitor

2008-08-19T21:45:00.004-03:00

Um usuário anônimo fez o seguinte comentario.

"Otimas materias, venho pedir uma ajuda, sei que essa não é local para perguntas, nas não achei como enviar um emael, hj trablho com slack no meu servidor e o meu cache é full para os clientes, gostaria de saber quanto seria a performace do cache em relação ao meu link tipo, na placa para o link o comsumo é de 4 mb e na placa de saida para os clientes esta consumindo 4.7 mb a 5.2 mb variando então estou tendo em média um ganho por conta do cache de 20% mais ou menos do meu link contratado, teria alguma forma de melhorar essa performace ou estou no limete de um ganho de um cache."

O proxy otimiza o trafego WEB (HTTP) portanto, primeiro vc precisa mensurar qual é o seu trafego WEB, e depois calcular qual o seu real ganho de banda. Para isso pode-se utilizar programas como o Bandwidthd (http://bandwidthd.sourceforge.net/) ou o NTOP (http://www.ntop.org)

A performance a ser obtida pelo cache pode varia entre 20 e 60% (não existe limite real), entretanto, a taxa de acerto (HIT) varia conforme o cenário. Entenda-se por cenário o ambiente do qual o proxy é condicionado.
Exemplo, uma empresa teoricamente tem seu acesso WEB frequente ao seu fornecedores, e colaboradores, ao que se difere de uma Lan House, onde o perfil de acesso é diversificado. Essa diversividade de acesso diminui a taxa de acerto do proxy.

Outros fatores, são descritos em um artigo da Rede Nacional de Pesquisa, conforme trecho abaixo:

"A porcentagem das requisicoes que conseguem ser resolvidas pelo servidor cache apenas com os dados armazenados localmente (taxa de acerto, ou "hit ratio") varia de acordo com varios fatores, tais como: a capacidade de armazenamento de objetos, o ambiente e grupo de trabalho onde estamos. Fonte: http://www.rnp.br/newsgen/9706/n2-3.html

Pessoalmente meus proxies tem obtido uma economia de banda em torno de 25% mas em alguns dias essa taxa sobe para 40%. E conforme o seu relato acredito que seu proxy está bastante eficiente.
Uma forma simples de mensurar o hit ratio, o tcp hit e a latencia do proxy é através do squid-graph, que foi demonstrado num post anterior, e tem seu fonte no endereço: http://squid-graph.sourceforge.net/

Abraços.

Retirando o Firmware UOL do Modem ADSL Speedtouch

2008-08-11T22:26:00.004-03:00

Infelizmente não apenas com os telefones celulares estamos sujeitos ao conhecido bloqueio, os modems ADSL também fazem parte disso.

Os modems fornecidos pelo UOL possuem um firmware editado para funcionar apenas em sua rede. Em funcionamento padrão, até mesmo o reconhecimento do modem pelo software de upgrade é desativado.

Obtive um desses modems, e para conseguir utilizá-lo, tive que pesquisar um pouco como retirar o firmware. A primeira busca foi no site nacional do fabricante, http://www.speedtouch.com.br/ que sabiamente (ou não), não recomenda a atualização de firmware.

Então acabei me deparando no site http://speedtouch.republicavirtual.com.br/ que possui um bom artigo para a atualização.

Para atualizar o modem, primeiro vamos baixar o programa de atualização, e a imagem binária do SO do modem.

Software para Update: http://www.linuxadm.com.br/ST5x0v6-UpgradeSW.zip
Imagem Binária do SO: http://www.linuxadm.com.br/UK_510v6_61I5_firmware.zip (Data do Firmware 07/07/2008)

Se deseja obter a ultima versão do firmware, acesse: http://www.thomson.net/GlobalEnglish/SelfService/dsl-modems-download/Pages/default.aspx

- Depois de baixar os softwares, extraia-os para uma pasta qualquer.
- Desligue o modem, mantenha a tecla reset pressionada, e ligue o modem. Mantenha a tecla pressionada por aproximadamente 10s (até o led de Power Piscar)
- Solte o botão reset, e execute o arquivo upgradeST.exe
- Clique em próximo e o programa devera encontrar seu modem, clique em proximo novamente e selecione o arquivo de imagem (510v6_61I5_UK.bin) que será enviado ao modem.

Feito os procedimentos, o modem será reiniciado e voltará com seu ip padrao 192.168.1.254.

Utilizando-se o firmware Britanico, só existem 3 configurações de VC/VCI disponíveis, e para configurá-lo para qualquer operadora, é necessário utilizar o software de configuração feito pelo fabricante.

Configurador: http://www.linuxadm.com.br/ST5x0v6_Configurator.zip

Pronto, seu modem já está roteado, e livre para qualquer operadora.

Instalando o Debian via rede com boot remoto

2008-06-27T00:44:00.005-03:00

Artigo escrito por Alisson Baracho - alisson@usinet.com.br
*O sofreu pequenas modificações permitidas pelo autor.

A fim de resolver o problema de instalação do linux através de medias removíveis, ou mesmo agilizar a instalação em múltiplas máquinas, surge necessidade de instalação por meios alternativos, e a instalação via rede com boot remoto se torna uma excelente solução.

O artigo foi feito baseado na distribuição Debian, mas com as modificações apropriadas se aplica a qualquer distribuição.

Alguns conceitos antes de iniciar o artigo.

PXE (Ambiente de execução Pré-Boot)
Permite o boot usando a interface de rede independente de dispositivo de armazenamento disponível (como por exemplo, disco rígido) ou sistemas operacionais instalados.

DHCPd (Protocolo de configuração dinamica de host)
Daemon para o Protocolo de serviço TCP/IP que oferece configuração dinâmica de terminais, com concessão de endereços IP de host e outros parâmetros de configuração para clientes de rede.

TFTP (Protocolo Trival de Transferencia de Arquivos)
Protocolo simples para transferencia de arquivos, com funcionalidades básicas de FTP.

Para começar, instala-se os daemons requeridos.

#apt-get install pxe atftpd dhcp3-server

Edite o /etc/dhcp3/dhcpd.conf alterando os endereços ips para os da sua rede

#----------------BOF---------------------
allow booting;
allow bootp;
ddns-update-style none;
#Seu dominio
option domain-name "linuxadm.com.br";
# Mascara da Rede
option subnet-mask 255.255.255.0;
# Endereço de broadcast da rede
option broadcast-address 192.168.0.255;
# Endereço do gateway padrao para os hosts
option routers 192.168.0.1;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 12.168.0.100 192.168.0.150;
}
group {
filename "pxelinux.0";
host pxemachine {
#Endereço MAC da maquina cliente
hardware ethernet 00:e0:4c:92:fd:51;
#Endereço do servior tftpd e diretório de boot)
option root-path "192.168.0.1:/tftpboot/";
}
}
#----------------EOF---------------------

Agora edite o /etc/pxe.conf

#----------------BOF---------------------
#Interface a ser usada no servidor
interface=eth0
#Endereço do servidor
default_address=192.168.0.1
#Endereço de multicast a escutar
multicast_address=192.168.0.255

# mtftp info
mtftp_address=192.168.0.1
mtftp_client_port=1758
mtftp_server_port=1759

#Porta de escuta
listen_port=4011
#Habiliar Multicast
use_multicast=1
#Habilitar Broadcast
use_broadcast=1
#Mensagem de boot
prompt=Press F8 to view menu.
#Tempo de espera da mensagem
prompt_timeout=10

# Quais serviços serão disponibilizados, e ordem de prioridade
service=X86PC,0,0,local,Local boot
service=X86PC,0,0,pxelinux,PXELinux

#Diretório Base do tftpd
tftpdbase=/tftpboot
#Nome do domínio
domain=linuxadm.com.br
#----------------EOF---------------------

Lembre-se que o diretório /tftpboot deve ter permissao de leitura e execucao.

Por fim, edite o arquivo /etc/default/atftpd

#----------------BOF---------------------
USE_INETD=false
OPTIONS="--daemon --port 69 --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 192.168.0.0-255 --mcast-ttl 1 --maxthread 100 -- verbose=5 /tftpboot"
#----------------EOF---------------------

obs. Verifique se a linha não está quebrada, o parametro options deve estar em uma única linha.

A configuração dos daemons terminou, baixe os arquivos da distribuição (No nosso caso, Debian Etch)

# mkdir -p /tftpboot
# cd /tftpboot
# wget http.us.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/mini.iso
# wget http.us.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/netboot.tar.gz
# wget http.us.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/pxelinux.0

Descompacte o boot do Debian Netinstall na pasta /tftpboot

# tar zxvf netboot.tar.gz
# chmod 755 /tftpboot -R

Pronto, agora reiniciando os daemons.

# invoke-rc.d atftpd restart
# invoke-rc.d dhcp3-server restart
# invoke-rc.d pxe restart

Agora, basta entrar no setup da maquina que será instalada e definir o boot pela lan, reinicie o computador e a tela da instalação do debian aparecerá.

Agradeço ao Alisson que gentilmente ofereceu esse excelente tutorial para ser publicado em nosso blog.

Fonte: http://en.wikipedia.org/wiki/Preboot_Execution_Environment
Fonte: http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol
Fonte: http://pt.wikipedia.org/wiki/DHCP
*Outras fontes foram consultadas mas não foram referenciadas pelo autor.

DNS Robusto e fácil com PowerDNS e MySQL

2008-06-16T19:24:00.012-03:00

O PowerDNS é um dos muitos softwares de DNS, ele é muito poderoso, pode fazer milhares de resoluções por segundo, e o que mais me chamou atenção, pode-se comunicar com vários backends, includindo MySQL, PostgreSQL, LDAP, Oracle e outros.

Para se ter uma idéia, existem grandes implementações feitas com ele, incluindo register.com e tucows.com, e, segundo o site oficial, existem aproximadamente 4000 servidores em serviços secundários ativos na internet, que servem aproximadamente 10 milhões de zonas e um imenso núumero de domínios. Testes no primeiro nível do domínios .EU demonstraram que o PowerDNs pode prover 50.000 resoluções por segundo num único servidor, com um hardware simples. No GOOGLE encontrei relatos de testes feitos inclusive pelo registro.br para utilização do mesmo.

A única desvantagem evidente é que o PowerDNS ainda não prevê uma implementação completa do DNSSEC. (O que pra muitos é irrelevante, visto que poucos são aqueles que implementaram DNSSEC em seus servidores)

Utilizar o PowerDNS inclusive como cache de DNS é uma ótima pedida devido a sua excelente performance.

Já tenho usado o PowerDNS há pelo menos 2 anos como servidor secundário e a pouco menos de 1 ano como servidor primário. Utilizo-o bastante também como caching de DNS, ele é extremamente rápido.

Estarei descrevendo abaixo os passos para instalação do PowerDNS no Debian, mas com um pouco de conhecimento pode ser instalado em qualquer distribuição através do código fonte.

---------------------------------------------------------------------------

1º Ambiente - Somente recursão de nomes (DNS cache, caching)

#apt-get install pdns-recursor

Edite o arquivo /etc/powerdns/recursor.conf:

Descomente a linha allow-from e insira os endereços ou classes ips autorizadas a fazer a recursão de nomes.

allow-from=127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10

Para evitar que vejam a exibição da versão do PowerDNS.

version-string=DENIED

Edite o arquivo /etc/resolv.conf e altere a linha nameserver para 127.0.0.1 (Isso fará com que a pesquisa de DNS seja feita no servidor local)

Pronto, você já está apto a fazer consultas de dns através do seu dns caching.

---------------------------------------------------------------------------

2º Ambiente - Servidor de nomes e recursão

Considerando que o mysql já está instalado no servidor.

Instale o PowerDNS com suporte a Mysql

#apt-get install pdns-backend-mysql

Entre no MySQL e execute os comandos abaixo para criar o usuário, senha, banco e setar as permissões pertinentes.

#mysql

#------- Recortar Aqui
CREATE USER 'pdns'@ '%' IDENTIFIED BY 'sua-senha';
GRANT USAGE ON * . * TO 'pdns'@ '%' IDENTIFIED BY 'sua-senha' WITH \
MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 \ MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
CREATE DATABASE `pdns` ;
GRANT ALL PRIVILEGES ON `pdns` . * TO 'pdns'@ '%';
#-------

Agora vamos criar as tabelas conforme o modelo do PowerDNS.

#mysql -u pdns -psua-senha -D pdns < /usr/share/doc/pdns-backend-mysql/mysql.sql
Então vamos copiar o arquivo padrão de configurações do backend para o diretório de configuração.

#cp /usr/share/doc/pdns-backend-mysql/examples/pdns.local.gmysql /etc/powerdns/pdns.d/

Edite o arquivo /etc/powerdns/pdns.d/pdns.local.gmysql

Altere o arquivo conforme suas preferencias.

gmysql-host=localhost
gmysql-port=3306
gmysql-dbname=pdns
gmysql-user=pdns
gmysql-password=sua-senha

Como seu servidor de DNS também fará a recursão de nomes, é importante limitar a recursividade do seu servidor de nomes aos IP's de sua(s) rede(s), isso impede o conhecido OPEN DNS.

Edite o arquivo /etc/powerdns/pdns.conf.

Descomente a linha allow-recursion e insira os endereços dos quais os servidor de nomes vai servir.

allow-recursion=127.0.0.0/8, 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, ::1/128, fe80::/10

Descomente a linha launch e insira os backends a serem carregados

launch=bind,gmysql

Se você irá replicar as Zonas, precisa inserir os endereços ips dos servidores dos quais irá fazer transferência de Zonas.

allow-axfr-ips=200.200.200.200
(onde 200.200.200.200 é o endereço ip do seu servidor de dns que será replicado)

Precisa também permitir as transferências de zonas.

disable-axfr=no

Altere a porta do recursor para uma porta diferente do servidor de nomes, para isso edite o arquivo /etc/powerdns/recursor.conf

local-port=2525

Agora vamos inserir o recursor no servidor de nomes, para quem ele faça recursão caso não encontre no servidor de nomes local. Para isso edite o arquivo edite o arquivo /etc/powerdns/pdns.conf.

recursor=127.0.0.1:2525

É isso, seu servidor de nomes já está ativo e com suporte a recursão.
Para testar o servidor de nomes local, vamos inserir um registro de exemplo.

# mysql

#------- Recortar Aqui
insert into domains (name,type) values ('teste.com.br','NATIVE');
insert into records (content,type,domain_id,name) values ('127.0.0.1','A','1','www.teste.com.br')
#-------

Teste o a resolução de seu domínio.
Lembre-se que para fazer o teste, vc deve ter o endereço local de seu servidor no arquivo /etc/resolv.conf

Aproveite! =)

---------------------------------------------------------------------------

3º Ambiente - Servidor de nomes e sem recursão

Repita o procedimento do ambiente 2, apenas não instalando o Recursor.

---------------------------------------------------------------------------

Abaixo três interfaces gráficas para gerenciamento do PowerDNS

PowerAdmin - http://www.poweradmin.org/ (O Mais completo)
proFTPd Administrator - proftpd-adm.sourceforge.net
ZoneAdmin - http://open.megabit.net/index.php?section=pro_home&project=ZoneAdmin

Fonte: http://www.powerdns.com/

Squid Tuning - Mais dicas, aumentando a performance de disco.

2008-06-14T11:51:00.018-03:00

Procurando mais informações a respeito do Squid, me deparei na seguinte página. http://wiki.squid-cache.org/BestOsForSquid e descobri duas dicas a mais para melhorar o acesso a disco e consequentemente a resposta dos arquivos em cache.

Esse artigo deve ser considerado uma continuação do anterior "Otimizando o Squid - Versão 2008", disponível em http://linuxadm.blogspot.com/2008/02/otimizando-o-squid-verso-2008.html

1ª Dica - noatime option

O Linux salva em cada arquivo a informação de data e hora de ultimo acesso além de ultima modificação, e como o Squid utiliza seu timestamp próprio, é inutil contar com o timestamp do filesystem. Para melhorar o acesso aos arquivos de cache setamos então o diretório de cache com o parâmetro "noatime".

Como fazer? Simples.
Se o seu diretório de cache está numa partição em separado (o que a propósito é uma excelente idéia) basta adicionar o parâmetro noatime no seu fstab.

Exemplo:
/dev/sda3 /var/spool/squid reiserfs defaults,noatime 0 2

obs.. Recomendo adicionar o noatime somente nas partições do cache, não em partiçoes do sistema, tal como /

Se você já possui um particionamento, e não deseja reparticionar seu disco, pode fazer através do comando chattr (change attribute)

Exemplo:
#chattr -R +A /var/spool/squid
(Onde o -R é para recursividade, e o +A para especificar o noatime)

Para usar o chattr com ReiserFS é necessário ativar o suporte no Kernel.

[*] ReiserFS extended attributes
[*] ReiserFS POSIX Access Control Lists
[*] ReiserFS Security Labels

Para visualizar os atributos do arquivo utilize o lsattr.

Exemplo:
#lsattr
------------- ./radius.sql (Arquivo sem nenhum atributo ativo)

2ª Dica - Espaço Livre (free space)
Sempre deixe acima de 20% de espaço livre no filesystem contendo seu cache dir, geralmente a performance do filesystem degrada dramaticamente se o espaço usado excede 80%.

3º Dica - Desativar o Store.log (Enviada por YellowBR)
Como dito anteriormente, quanto melhor otimizarmos o acesso a disco mais rapido será nosso proxy, uma forma de melhorar a performance de disco é reduzir a escrita desnecessária.
O store.log exibe quais arquivos foram removidos do cache, quais objetos estão salvos, e o tempo que estão no cache, entretanto, não existe uma utilidade real para esses dados, portanto é recomendável desativar essa flag.
Exemplo:
cache_store_log none

Fonte: http://www.visolve.com/squid/squid24s1/logfiles.php

Dica Extra (E extremamente útil) - notail option
Se você usa ReiserFs (o que é indicado para cache do squid) é interessante o uso da opção notail ao montar o sistema de arquivos. O "tail packing" é uma característica do ReiserFS para melhor uso de espaço, que permite 5% a menos de perda de espaço em disco se comparado ao ext2 ou ext3, a grosso modo ele faz um agrupamento de arquivos menores que um bloco do filesystem (4k), por isso a excelente performance do ReiserFS com arquivos menores.

Fonte: http://www.funtoo.org/en/articles/linux/ffg/2/

Portanto se você está disposto a sacrificar 5% do estaço em disco para um incremento de performance, ative a opção notail no seu fstab.

/dev/sda3 /var/spool/squid reiserfs defaults,noatime,notail 0 2

Se você não quiser reiniciar seu linux, basta apenas remontar a partição com o parâmetro notail.

#mount -o remount /var/spool/squid

As últimas duas dicas não referem-se apenas ao Squid, mas ao uso do sistema operacional em sí, procure manter o mesmo procedimento para sua partição primária.

Outras dica óbvia, e não menos importante, é procurar disco com velocidades maiores, por exemplo discos de 15k RPM.

Estarei adicionando essas dicas no arquivo original, mas manterei esse post em separado para que os antigos leitores vejam que houveram incremento de informações no tutorial.

Abraços.

Aviso aos Visitantes

2008-06-13T15:58:00.005-03:00

Caro Visitante.

O formulário do blogger infelizmente não fornece campo de email, por isso peço que coloque seu email junto ao comentário caso queira resposta.

Respondendo a pergunta do visitante Standart, o porque o seu proxy não apresenta muitos HIT.

Somente a política LRU apresenta uma resposta rápida, pois ela armazena os arquivos acessados recentemente. As outras políticas GDSF e LFUDA, utilizam lógicas de armazenamento baseadas em popularidade e tamanho, e precisam de tempo ter uma boa base de dados (arquivos armazenados no squid).

Portanto, é necessário que o seu cache esteja com bastante registros afim de obter melhor HIT ratio.

Veja os resultados do meu proxy depois de 1 mês de utilização.

Agradeço a todos que comentam.

VLANs em Roteadores Cisco e em Linux

2008-04-18T15:03:00.005-03:00

Para criar um vlan em um roteador cisco é mais simples do que se imagina.

Após logar no roteador digitemos:

config t
int f0.1
encapsulation dot1q vlanID*
ip address 10.0.0.1 255.255.255.252
end
wr

No linux

vconfig add ethX vlanID*
ifconfig ethX.vlanID* 10.0.0.2 netmask 255.255.255.252

*vlanID é o número (id) que vai atribuir ao vlan para se comunicarem.

Abraços!

Controlando a banda do tráfego P2P com Layer7 - Versão 2008

2008-03-18T11:05:00.008-03:00

Como sempre, o principal vilão hoje de qualquer Administrador de Redes, Provedores e outros são os programas P2P, e clientes que reclamam que não tem a banda total garantida devido aos medidores de tráfego do tipo RJNET entre outros.

Aqui então vamos nós para uma aventura de marcação de pacotes e priorização dos mesmos, juntamente com a integração da marcação destes pacotes com o TC ( Traffic Control ) do GNU/Linux.

O sistema foi testado em um Debian GNU/Linux, com kernel 2.6.22.15, iptables versão 1.3.8, patch-o-matic, layer7 versão 2.17, protocolos versão 2008-02-10, imq para o kernel.

Não vou entrar nos detalhes de como compilar kernel, iptables entre outros, vamos por a mão na massa.

Primeiro, redirecionamos o trafego de download e upload para as interfaces virtuais:

iptables -v -t mangle -A PREROUTING -m comment --comment "Trafego Upload" -i eth+ -j IMQ --todev 0
iptables -v -t mangle -A POSTROUTING -m comment --comment "Trafego Download" -o eth+ -j IMQ --todev 1

usamos o eth+ por termos várias interfaces de rede.

Logo após, criamos a CHAIN chamada P2P e adicionamos o que queremos

iptables -t mangle -N P2P
iptables -t mangle -A P2P -m layer7 --l7proto ares -j MARK --set-mark 0x7
iptables -t mangle -A P2P -m layer7 --l7proto ares -j CLASSIFY --set-class 1:7
iptables -t mangle -A P2P -m layer7 --l7proto ares -j RETURN

iptables -t mangle -A P2P -m layer7 --l7proto edonkey -j MARK --set-mark 0x7
iptables -t mangle -A P2P -m layer7 --l7proto edonkey -j CLASSIFY --set-class 1:7
iptables -t mangle -A P2P -m layer7 --l7proto edonkey -j RETURN

iptables -t mangle -A P2P -m layer7 --l7proto bittorrent -j MARK --set-mark 0x7
iptables -t mangle -A P2P -m layer7 --l7proto bittorrent -j CLASSIFY --set-class 1:7
iptables -t mangle -A P2P -m layer7 --l7proto bittorrent -j RETURN

iptables -t mangle -A FORWARD -j P2P
iptables -t mangle -A POSTROUTING -j P2P

Criamos a chain P2P e adicionamos nela a marcação de pacotes e setando a classe para o qual vai ser direcionado o P2P ares, edonkey e bittorrent. O Return funciona para caso ele encontre algo antes, tipo, alguem usando ares, ele nao desça ate o final da chain procurando mais coisas.

Após marcar e setar a classe, vamos criar as classes usando o TC

ip link set dev imq0 up
ip link set dev imq1 up

tc qdisc add dev imq0 root handle 1: htb default 1
tc qdisc add dev imq1 root handle 1: htb default 1

tc class add dev imq0 parent 1: classid 1:1 htb rate 100Mbit
tc class add dev imq1 parent 1: classid 1:1 htb rate 100Mbit

#P2P
tc class add dev imq0 parent 1:1 classid 1:7 htb rate 512kbit prio 7
tc class add dev imq1 parent 1:1 classid 1:7 htb rate 512kbit prio 7

# Aqui setamos a classe do P2P 1:7 para 512kbit com a prioridade 7

Logo após, adicionamos o filtro à classe

tc filter add dev imq0 parent 1: prio 7 protocol ip handle 7 fw flowid 1:7
tc filter add dev imq1 parent 1: prio 7 protocol ip handle 7 fw flowid 1:7

Ou seja, estamos agora controlando a banda de trafego P2P.

Vamos agora adicionar um "feature" a essas regras. Marcando por ex.: tudo que vai para rjnet.com.br sair com a banda de 2mbit.

iptables -t mangle -N WEB
iptables -t mangle -A WEB -m string --algo bm --string "rjnet.com.br" -j MARK --set-mark 0x6
iptables -t mangle -A WEB -m string --algo bm --string "rjnet.com.br" -j CLASSIFY --set-class 1:6
iptables -t mangle -A WEB -j CONNMARK --save-mark

iptables -t mangle -A FORWARD -j WEB
iptables -t mangle -A POSTROUTING -j WEB

tc class add dev imq0 parent 1:1 classid 1:6 htb rate 2048kbit prio 0
tc class add dev imq1 parent 1:1 classid 1:6 htb rate 2048kbit prio 0

tc filter add dev imq0 parent 1: prio 0 protocol ip handle 6 fw flowid 1:6
tc filter add dev imq1 parent 1: prio 0 protocol ip handle 6 fw flowid 1:6
tc filter add dev imq1 parent 1: protocol ip match ip dst 200.159.128.189 flowid 1:6

Sendo assim, teremos marcado tudo que conter rjnet.com.br com uma banda de 2mbit.

Esse cenário foi montado em testes e esta funcionando normalmente.

Abraços!

Bloqueando NETBIOS no Mikrotik Bridge

2008-02-15T20:25:00.006-02:00

Para bloquear o NETBIOS (Compartilhamento de arquivos) no Mikrotik Bridge, é necessário utilizar o filtro no menu BRIDGE do Mikrotik. Muitos tutoriais informam fazer isso no menu IP->Firewall, mas se o Mikrotik estiver configurado como Bridge, esse filtro não funciona.

Primeiro, após logado no Mikrotik, acesse o menu BRIDGE.

A chain forward já vem selecionada pro padrao.

Em seguida clique na seta ao lado esquerdo de MAC Protocol, selecione o protocolo 800 (ip), mais embaixo selecione o protocolo 6 (tcp) e para finalizar essa guia, digite o range (intervalo) das portas a bloquear, no caso 135-139.

A imagem abaixo mostra as configurações a serem feitas.

Feito isso selecione a guia Action, e mude o action de accept para drop.

Após clicar em Apply, as configurações já entram em vigor, se clicar na guia estatísticas veremos o que está sendo bloqueado por nossa regra.

Para que o bloqueio seja feito por completo, repita os procedimentos para as portas 135-139 no protocolo UDP e para a porta 445 no protocolo TCP.

Se tiver o interesse em bloquear o acesso entre clientes na mesma porta do AP, desative a função default forward do Mikrotik.

Fonte: http://www.microsoft.com/brasil/security/guidance/smb/ref_net_ports_ms_prod.mspx

Solucionado: NETDEV WATCHDOG

2008-02-09T04:37:00.001-02:00

Resumo:
Resolvi o problema do servidor relacionado ao NETDEV WATCHDOG, desmarcando
a opção ENABLE IRQ BALANCING do Kernel SMP.

A algum tempo atrás um problema novo apareceu no servidor. De tempos em tempos a placa de rede começava a apresentar os seguintes erros:

Feb 1 20:34:11 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:34:26 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:34:41 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:34:56 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:35:11 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:35:26 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:35:41 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out

Esses erros não duravam muito tempo, porque muito rapidamente a placa de rede simplesmente parava de responder.

Para ativar a placa novamente, era necessário descarregar e carregar novamente o seu módulo.

Primeiro recompilei o driver da placa de rede alterando o MMIO para PIO.

* Usa as Portas de I/O programadas ao invés da Memória PCI Compartilhada, pode resolver alguns problemas em placas mãe com inconsistência de memória. (Segundo info do kernel)

Por felicidade ou não, o servidor permaneceu dois dias sem apresentar erro, mas no terceiro dia, a mesma história.

Pensei então na opção de RX-Reset (imagem acima), que, segundo info do kernel, contém uma mais rápida sequencia de reset, e se apresentar problema pode ser optado o método antigo.

Recompilado o módulo, modulo descarregado e carregado. Horas depois o mesmo erro, entretanto numa placa de rede diferente, e que utilizava outro driver. Então, pensei, já que o erro mudou de interface, vamos ver as configurações do módulo da maldita placa.

Encontrei então a opção NAPI API, que é um novo driver desenvolvido para reduzir a carga e interrupção do CPU quando recebendo muitos pacotes da placa de rede. Opção recomendada para Carga de RX acima de 10kpps (pacotes por segundo)

Solução também insuficiente, pois a placa apresentava os mesmos erros, agora em interfaces alternadas (o servidor possui 4 placas de rede)

Pesquisando na internet, encontrei o parâmetro pci=noacpi afim de resolver o erro, insiro no append do lilo (append="pci=noacpi") e reinicio o servidor.

Novamente o servidor começa a apresentar erros, começo então a esmiuçar o kernel com a linha de raciocínio que era problemas no barramento PCI ou IRQ, algo do tipo, até que então, encontro na parte "Processor type and features" a opção "Enable kernel irq balancing"

obs. Essa opção só aparece se o servidor estiver sendo compilado para multiprocessadores (SMP)

Desmarco a opção, recompilo o kernel, e reinicio o servidor.

Bom, hoje é dia 9 de fevereiro, desde o último dia 1, o erro não acontece mais.

Pode não estar relacionado, mas após essa alteração até o processamento da máquina diminuiu consideravelmente, agora o servidor fica idle acima de 96%, e antes estava por volta de 84%.

Pesquisando no google, encontrei um tópico em inglês de um usuário que após recompilar o kernel desativando essa opção sentiu uma considerável diferença no seu desktop linux, segundo o mesmo os vídeos que antes travava de tempos em tempos, agora é executado perfeitamente, mesmo ele usando outros aplicativos em background.

Devido ao leitor que solicitou mais detalhes do procedimento adotado, farei aqui resumidademen te.

obs.. Ao estilo Debian(Ubuntu) mas com poucas modificações, funciona em qualquer distribuição.

Preparando os compiladores necessários.

#apt-get install build-essential kernel-package libncurses5-dev

Instalando o kernel (Faça de acordo com seu próprio kernel)

#apt-get install linux-tree-2.6.26-1

Crie o link simbólico para o souce do kernel

# ln -s /usr/src/linux-2.6.26.1 /usr/src/linux

Entre no diretorio do linux

#cd /usr/src/linux

Configure o kernel conforme imagens inseridas nesse artigo, para isso acessamos a configuração via terminal

#make menuconfig

Salve o arquivo de configuração e faça a compilação do kernel conforme:

#make-kpkg --initrd kernel_image

Uma vez compilado, basta instalar o novo kernel

#dpkg -i linux-image-2.6.26.1*

Agora reinicie a máquina para que o novo kernel seja ativado.

Squid fazendo cache de vídeos do Youtube e outros

2008-02-07T23:57:00.002-02:00

Squid fazendo cache de vídeos do Youtube

Para que seu squid possa fazer cache dos vídeos do YouTube, adicione as linhas abaixo ao seu squid.conf, essa alteração não só faz cache do youtube, mas qualquer site que utilize a mesma tecnologia flash com extensão .flv

########### Cache Videos ###########
refresh_pattern -i \.flv$ 10080 90% 999999 ignore-no-cache override-expire ignore-private

acl youtube dstdomain .youtube.com

cache allow youtube
################################

Como os arquivos de vídeo são grandes, é necessário também aumentar o maximum_object_size

maximum_object_size 102400 KB (100MB)

O FAQ do squid orienta a alterar o seguinte parâmetro quick_abort_min, e é explicado que ele irá fazer com que o primeiro carregamento do vídeo seja mais lento, eu preferi não mexer, e funciona pra mim.

quick_abort_min -1 KB

Fonte: http://wiki.squid-cache.org/ConfigExamples/DynamicContent/YouTube

Squid fazendo Cache do Windows Update

2008-02-07T23:38:00.003-02:00

Squid fazendo Cache do Windows Update

Para fazer cache do windows update para seu squid cache, adicione as seguintes linhas ao seu squid.conf.

##### Cache do Windows Update #####

refresh_pattern au.download.windowsupdate.com/.*\.(cab|exe|msi) 10080 100% 43200 reload-into-ims

refresh_pattern download.microsoft.com/.*\.(cab|exe|msi) 10080 100% 43200 reload-into-ims

refresh_pattern msgruser.dlservice.microsoft.com/.*\.(cab|exe|msi) 10080 100% 43200 reload-into-ims

refresh_pattern windowsupdate.com/.*\.(cab|exe|msi) 10080 100% 43200 reload-into-ims

refresh_pattern www.microsoft.com/.*\.(cab|exe|msi) 10080 100% 43200 reload-into-ims

################################

Abaixo, os TCP_HIT's após a implementação das regras.

1202419417.424 281272 192.168.49.45 TCP_HIT/200 8701382 GET http://www.download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/ie7-windowsxp-kb942615-x86-ptb_5854e25703d2f575c52ebfee511a65d8794abf2f.exe - NONE/- application/octet-stream

1202423194.037 24 192.168.49.115 TCP_MEM_HIT/206 10804 GET http://au.download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/windowsxp-kb905414-x86-express-ptb_18b1ac39ee9e3560d3bc9d24694a99e885bc38ed.cab - NONE/- application/octet-stream

Otimizando o Squid - Versão 2008

2008-02-07T22:25:00.003-02:00

Otimizando seu Squid (Squid Tunning) - Versão 2008

A muito tempo, utilizo o squid para fazer cache em um provedor de internet a qual presto consultoria, e nesse carnaval de 2008, o servidor estava travando constantemente. Como o servidor, faz QOS, Controle de Banda e Firewall, pensei que um dos problemas pudesse ser o squid, além do que seu tempo de resposta estava alto. Em alguns instantes o uso de memória saía do habitual 1GB para 2GB, e nesse momento uma ou outra interface de rede parava de responder, e algumas vezes o syn era tao alto na porta 3128 e o syn cookie era ativado. Então minha primeira missão era minimizar e otimizar o uso de memória no servidor, sem muito penalizar o cache. Em todo momento a idéia era de aumentar o HIT Ratio, e ao mesmo tempo diminuir o consumo de banda, sem claro aumentar o tempo de resposta, que para o usuário final é a demora na abertura de páginas.

Procurando no site oficial do squid, procurei na parte de memória (Fonte: http://wiki.squid-cache.org/SquidFaq/SquidMemory ) O squid usa aproximadamente 10MB de memória RAM para cada Giga do Total encontrado no parâmetro cache_dir, mais a quantidade definida no cache_mem e um adicional de 10 a 20MB. Levando-se em consideração os serviços que roda no servidor, é aconselhavel o dobro da memória disponível para o squid no servidor. Portanto, se você possui um servidor com disco grande, mas uma quantidade limitada de memória RAM, NÃO se use todo o espaço em disco, e sim uma quantidade razoável levando as ponderações ditas acima. No meu caso, o servidor possui 2GB de RAM, e um disco rígido de 320GB, aloco 512 MB RAM no cache_mem, e 50GB para o cache_dir

Fazendo as contas do uso de memória:

cache_dir = 50GB -> 500MB de RAM usada

cache_mem = 512MB

Adicional de 20MB

O resultado: 500 + 512 + 20 = 1032MB RAM usada pelo squid.

Nesse caso, sobra aproximadamente 1GB para o Sistema, como possuo outros serviços no servidor, é um valor razoável.

Vejo nos em muitos artigos o parametro " memory_pools off " que de acordo com o FAQ do squid, não é uma boa pois induz a fragmentação de HEAP, nesse caso o mais indicado é o uso do memory_pools_limit

O parâmetro cache_mem por sí só, não limita a quantidade de memória usada pelo squid, e sim o tamanho do cache dos arquivos populares, entretanto, quanto maior o valor do cache_mem maior será o uso de memória do processo do squid, e se o squid está consumindo muita memória pense em diminuir a quantidade de memória usada no cache_mem. Como no meu caso a minha idéia é aumentar o HIT Ratio e ao mesmo tempo diminuir o consumo de banda, comecei a pesquisar também sobre o assunto. Encontrei no proprio arquivo do squid.conf os seguintes estudos, incluindo benchmarks (Fonte: http://fog.hpl.external.hp.com/techreports/98/HPL-98-173.html e http://www.hpl.hp.com/techreports/1999/HPL-1999-69.html)

Feita a leitura, encontrei as políticas de troca de cache (cache_replacement_policy) com as 4 regras listadas.

lru : Squid's original list based LRU policy

Mantém em cache os arquivos abertos recentemente.

heap GDSF : Greedy-Dual Size Frequency

Otimiza o HIT Ratio de objetos mantendo os arquivos menores e populares no cache, para obter uma melhor chance de acontecer um HIT.

heap LFUDA: Least Frequently Used with Dynamic Aging

Procura manter no cache arquivos populares, independente do tamanho otimizando assim o Byte HIT em detrimento do HIT

heap LRU : LRU policy implemented using a heap

Mantém em cache os arquivos abertos recentemente utilizando-se a política heap

Nota: Para usar LFUDA deve-se aumentar o parâmetro "maximum_object_size" acima dos 4096KB padrão do squid para maximizar o Byte HIT, que é a prioridade da política.

Como eu tenho um cache com muitos usuários, e pensando na menos utilização de disco possível, tendo em vista que o seek time de um disco é muitas vezes mais lento que da memória RAM, preferi utilizar a política heap GDSF para a memória RAM disponível no cache_mem. Sendo assim meu arquivo de configuração ficou com o parâmetro "memory_replacement_policy" da seguinte forma

memory_replacement_policy heap GDSF

Prover internet com qualidade e preço competitivo é muito difícil para os pequenos, ou mesmo pra quem está dentro de uma empresa, minimizar o custo do link é importante, por isso, diminuir o consumo de banda é outra prerrogativa de um bom adminstrador. Por isso, tem-se que equilibrar a velocidade de acesso e o uso de banda, e para isso aumentamos o Byte HIT. Como a política LFUDA otimiza o Byte HIT, é ela que será usada no cache_replacement_policy. Dito isso o parâmetro ficará:

cache_replacement_policy heap LFUDA

O maximum_object_size, deve ser aumentado, e como vão ser cacheados arquivos grandes, tipo as atualizações do windows, o parâmetro foi definido como:

maximum_object_size 102400 KB ( 100MB )

A idéia das regras GDSF e LFUDA para as diferentes políticas é a seguinte, mantendo arquivos populares e pequenos no cache_mem (GDSF) eu aumento o HIT do servidor e diminuo o tempo de resposta do squid, pois evito que o disco rígido fique procurando arquivos pequenos. E com o LFUDA eu mantenho os arquivos populares e maiores no servidor e aumento o Byte HIT, adicionalmente, como é sabido, a transferência de arquivos maiores é mais rápida, indiretamente há uma otimização do uso do disco.

Abaixo, um benchmark feito com todas as políticas descritas acima.

Dica Importante: Mesmo que você não queira usar as políticas de popularidade GDSF e LFUDA, considere utilizar pelo menos no cache_replacement_policy o heap com LRU. Utilizando-se do heap a LRU tem uma melhora significantemente o tempo de resposta e transferência dos arquivos em cache se comparado a LRU tradicional.

Grafico do tempo de transferencia das políticas.

Como pode ser visto acima, a regra LRU presente na configuração padrão do squid possui um tempo de resposta muito inferior as políticas que usam HEAP, portanto a dica acima deve ser levada em consideração.

Ainda com objetivo de melhorar o acesso ao proxy e ao disco, uso o diskd que segundo o FAQ do squid, obtém aproximadamente 160 Req/s ao contrário dos outros dois tipos, (UFS e AUFS), que conforme o mesmo benchmark, possibilita 40 Req/s (Requisições por segundo)

cache_dir diskd /var/spool/squid 50000 64 256 Q1=64 Q2=72

Nota, os parametros Q1 e Q2 afetam diretamente a performance do cache, se Q1 > Q2 o diskd otimiza o diretório de cache para um menor tempo de resposta e, ao contrario, se Q1 < Q2 o diskd otimiza o diretório de cache para um aumento do HIT RATIO.

Para aumentar a quantidade de arquivos que o squid pode abrir, é interessante aumentar o número de file descriptors do squid. O kernel atual série 2.6+ já não precisam mais de patch para aumentar o número de file descriptors ( cat /proc/sys/fs/file-max ) e aumente para um número razoável. Uma forma elegante é usar o sysctl (exemplo: sysctl -w fs.file-max=100000) Já o squid, precisa de compilar com o parametro SQUID_MAXFD, mas o debian, vem com um patch onde vc pode editar o arquivo /etc/defaults/squid onde o valor máximo é 4096, depois basta reiniciar o squid.

Para minimizar o uso do squid, o parâmetro "half_closed_clients" deve ser setado em off, a alteração se deve porque muitas vezes o squid não diferencia um cliente que encerrou a conexão, e uma conexão travada, ou meio encerrada. ( Fonte: http://www.squid-cache.org/Versions/v2/2.6/cfgman/half_closed_clients.html tuning)

Artigo de Wagner Assis em 07/02/2008

Segue abaixo 2 artigos feitos posteriormentes relacionados ao Squid e suas otimizações.

Errata: Otimizando o Squid Versão 2008
http://www.linuxadm.com.br/2009/02/03/errata-otimizando-squid-versao-2008/

Squid Tuning - Mais dicas, aumentando a performance de disco
http://www.linuxadm.com.br/2008/06/14/squid-tuning-mais-dicas-aumentando-a-performance-de-disco/

Bloqueando Broadcast e Multicast e limitando o tamanho máximo do pacote ICMP com Iptables

2007-05-02T18:12:00.000-03:00

Analisando gráficos de meus Access Point e do Gateway de Rede, constatei que o numéro de pacotes de broadcast que trafegavam na ethernet dos equipamentos era demasiado e desnecessário.

Além das proteções inseridas no rádio, quis fazer com que o broadcast e multicast nem mesmo chegasse na ethernet do AP.

Segue ae a dica.

#iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP
#iptables -A INPUT -m pkttype --pkt-type multicast -j DROP

Também limito o tamanho máximo dos pacotes ICMP que trafegam na rede a 300bytes, usando-se da extensão Match (lenght)

#iptables -A INPUT -p icmp -m length --length 300: -j DROP

obs...Os tipos de pacote além de broadcast e multicast, também inclui o unicast mas não vem ao meu caso.

Abraços.
Wagner Assis

Limitando o tráfego P2P com Layer7 e Connlimit

2007-05-02T18:09:00.005-03:00

Data de criação: 20/04/2007
Artigo pode sofrer alterações devido novas funcionalidades encontradas.

Trabalho em um provedor de internet, e como todo administrador de redes, controlar efetivamente o tráfego de P2P é um desafio.
Mais do que o tráfego por ele gerado, o número de conexões ativas, assim como o número de pacotes por segundo, pode gerar muitos transtornos devido uma sobrecarga no Access Point.

Pesquisando na internet, encontrei um artigo interessante, sobre o uso de "connlimit no controle de portas¹", mas, em alguns casos não é interessante limitar todas as portas, principalmente se parte de seus clientes são empresas e precisam de acesso full, o que é necessário então é limitar somente o P2P.
A idéia então seria usar um classificador de protocolos, então pensei então em combinar essa idéia com o filtro de protocolo (Layer7)
Existe também o IPP2P, entretanto, como os clientes P2P estão usando técnicas de criptografia, e o IPP2P não é atualizado a quase um ano, prefiro manter no Layer7 que tem atualizações constantes de sua base de protocolos e no core do software.

Referência.
¹- http://under-linux.org/wiki/index.php/Tutoriais/Seguranca/Usando_o_Connlimit

Mãos a obra,
(Levando em consideração que sabe o que faz e tem conhecimento de compilar programas e do próprio kernel)

Requerimentos

Patch Connlimit - ftp://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20070414.tar.bz2
Patch Layer7 - http://ufpr.dl.sourceforge.net/sourceforge/l7-filter/netfilter-layer7-v2.9.tar.gz
Protocolos Layer7 - http://ufpr.dl.sourceforge.net/sourceforge/l7-filter/l7-protocols-2007-01-14.tar.gz
Kernel 2.6.19.7 - http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.7.tar.gz
Iptables 1.3.37 - ftp://ftp.netfilter.org/pub/iptables/iptables-1.3.7.tar.bz2

Decompacte o Kernel
#tar xzpvf linux-2.6.19.7.tar.gz

Descompacte o patch do Layer7
#tar xzpvf netfilter-layer7-v2.9.tar.gz

Descompacte o Connlimit
#tar xjpvf patch-o-matic-ng-20070414.tar.bz2

Descompacte o Iptables 1.3.37
#tar xjpvf iptables-1.3.7.tar.bz2

Aplique o patch do Layer7 ao Kernel
#patch -p1 < ../netfilter-layer7-v2.9/kernel-2.6.18-2.6.19-layer7-2.9.patch

Aplique o Patch do Connlimit
#cd patch-o-matic-ng-20070414
#KERNEL_DIR=../linux-2.6.19.7 IPTABLES_DIR=../iptables-1.3.7 ./runme connlimit -download (a opção -download é porque o connlimit não vem no snapshot padrao do patch-o-matic)

Agora que o kernel já está patcheado, vamos ativar os patch's

#cd linux-2.6.19.7
#make menuconfig
Ativar a opção - Connection tracking flow accounting (Requerido pelo Layer7) Networking->network options->network patcket filtering->IP: Netfilter Configuration->Connection tracking->Connection tracking flow accounting

Ativar a opção - Layer 7 match support
Networking->network options->network patcket filtering->IP: Netfilter Configuration->Layer 7 match support

Ativar a opção de Connlimit
networking->network options->network patcket filtering->IP: Netfilter Configuration->Connections/IP limit match support

Agora, configure o kernel a seu gosto, e compile-o.

Em Slackware
#make all
#make install
#lilo

Em Debian
#make-kpkg --initrd kernel_image
#dpkg -i ../linux-image-2.6.19.7_2.6.19.7-10.00.Custom_i386.deb

Agora, ainda falta compilar o iptables com suporte a layer7 e connlimit

Primeiro aplicamos os patch's

#cd iptables-1.3.7

Aplique o patch do filtro Layer7 ao iptables
#patch -p1 < ../netfilter-layer7-v2.9/iptables-layer7-2.9.patch

(O patch-o-matic já aplicou o patch ao iptables, visto que definimos o caminho do source do iptables)

Dê permissões para o iptables compilar suas extensões

#chmod +x extensions/.*

Compile o iptables
#KERNEL_DIR=../linux-2.6.19.7 PREFIX=/usr make

Instale o iptables
#make install

Atualize o cache de bibliotecas
#ldconfig

Reinicie o kernel, para ativar as compilações feitas
# shutdown -r now

Agora, insira em seu arquivo de firewall as seguintes linhas.

Crio uma nova chain na tabela mangle para o limite de conexões (CONNLIMIT)
#iptables -v -t mangle -N CONNLIMIT

Classifico cada protocolo de P2P nessa nova chain
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto edonkey -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto ares -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto gnutella -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto fasttrack -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto imesh -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto directconnect -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto napster -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto soulseek -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto bittorrent -j CONNLIMIT

Aplico o limite de conexões 15 conexões de P2P por IP (O connlimit só é aplicável em pacotes tcp)
#iptables -v -t mangle -A CONNLIMIT -p tcp -m connlimit --connlimit-above 15 --connlimit-mask 32 -j DROP

Como o connlimit só limita as conexões TCP, as regras acima só se aplicam a esse protocolo, se desejar fazer o controle também de UDP terá q ser feito com cbq,htb,hfsq + layer7 ou então dropando qualquer pacote p2p em UDP, conforma abaixo.

#iptables -v -t mangle -A PREROUTING -p UDP -m layer7 --l7proto edonkey -j DROP

Se você deseja um filtro ainda mais competente e ache que o controle de portas pode ser combinado sem complicações, sugiro as seguintes regras.

#iptables -v -t mangle -N CONNLIMIT
#iptables -v -A FORWARD -p TCP -d 0/0 --dport 4300:4672 -j CONNLIMIT
#iptables -v -A FORWARD -p TCP -d 0/0 --sport 4660:4672 -j CONNLIMIT
#iptables -v -A FORWARD -p TCP -d 0/0 --dport 6881:65000 -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto edonkey -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto ares -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto gnutella -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto bittorrent -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto fasttrack -j CONNLIMIT
#iptables -v -t mangle -A CONNLIMIT -p tcp -m connlimit --connlimit-above 15 --connlimit-mask 32 -j DROP

Então o iptables aplica o connlimit nas portas conhecidas do emule (source e destination), e nas portas altas de destino, e qualquer P2P que esteja fora desse range de portas, se identificado com o layer7 também entra no connlimit.
Ultimamente nos servidores que possuem controle de banda essas regras estão ativas no controle de p2p em meus servidores, as regras anteriores só com layer7 só as aplico em servidores onde não posso fazer o limite de portas (roteadores por exemplo).

Esteja ciente que alguns protocolos do layer7 são lentos, portanto se o tempo de resposta de sua rede subir, ou apresentar perda de pacotes, tente evitar protocolos lentos como o bittorrent, prefira manter os mais ativos e mais rapidos, como emule e ares.

Espero que seja de alguma ajuda, abraços.
Wagner Assis