Relato de uso do Controle de Conexões Simultâneas (CONNLIMIT)

Aê pessoal, muito se tem discutido aqui no fórum do Underlinux sobre esse tipo de implementação, suas implicações e uso, etc...Tanto aqui na seção Proxy/NAT/Firewal, quanto nas seções Wireless/Mikrotik há ainda muitas dúvidas quanto sua aplicabilidade. Bom, resolvi então escrever meu relato de como estou usando o connlimit aqui, tanto no aspecto de como tenho implementado, como tenho feito para solucionar problemas e também sobre como não gerar problemas com seu uso.

Bom, a minha necessidade de fazer essa implementação foi pelo fato de simplesmente não conseguir oferecer acesso à redes p2p (emule, kazaa, etc..) para meus clientes (sou um provedor de internet), visto que um único cliente, com o emule funcionando, por exemplo, abre mais de 250 conexões simultâneas, isso baixando apenas um único arquivo...imagina então um tarado com uma fila de uns 50~100 arquivos...ai já era. Os rádios nas minhas repetidoras simplesmente não aguentavam tantas requisições simultâneas...Dava latência alta, desconexões...

Então, analisando o tráfego desse tipo de software, eu percebi que tinha que atacar diretamente o fato deles abrirem muitas conexões simultâneas. Então corri atrás de recompilar meu kernel e o meu iptables com o pom (patch-o-matic) e adicionar o módulo CONNLIMIT.

Aqui eu uso um servidor CentOS como gateway de acesso, controle de banda e firewall.

A implementação, basicamente no firewall (vou postar aqui somente o que se refere ao connlimit), foi essa:

1) Crio uma cadeia chamada CONNLIMIT:

iptables -N CONNLIMIT

2) Redireciono todos os acessos (portas) que gostaria de limitar para a cadeia CONNLIMIT (no caso, as portas acima de 1024, basicamente, visto que esses softwares tarado usam portas altas, porém, tomando cuidado de deixar fora do controle as portas de serviços conhecidos, como MSN e afins, jogos on-line, vnc, proxy, etc...vou dar alguns exemplos):

iptables -A FORWARD -p TCP -d 0/0 --dport 1024:1862 -j CONNLIMIT (excluindo o MSN = 1863)
iptables -A FORWARD -p TCP -d 0/0 --dport 1864:3127 -j CONNLIMIT (excluindo a porta do proxy = 3128)
iptables -A FORWARD -p TCP -d 0/0 --dport 3129:5599 -j CONNLIMIT (excluindo a porta do VNC = 5600)
iptables -A FORWARD -p TCP -d 0/0 --dport 5601:5899 -j CONNLIMIT (excluindo outra porta do VNC = 5900)
iptables -A FORWARD -p TCP -d 0/0 --dport 5901:7776 -j CONNLIMIT (excluindo o jogo on-line Lineage = 7777)

e assim por diante, eu faço "ranges" de IP que excluam as portas de serviços "saudáveis". Ah, e eu também uso o "-p TCP" ou seja, trabalhando apenas com o protocolo TCP, pois o CONNLIMIT só funciona com TCP. Existia um tempo atrás um módulo UDPLIMIT, mas ele é antigo, não sei se dá pra aplicar ele no kernel e no iptables mais recentes...

3) Agora como todo esse acesso tá passando pela cadeia CONNLIMIT, eu aplico nela a limitação:

iptables -A CONNLIMIT -p TCP -m state ! --state RELATED -m connlimit --connlimit-above 12 --connlimit-mask 32 -j DROP

Aqui é que tá o segredo do negócio...hehehe...seguinte:

obs1: "-m state ! --state RELATED" = usando isso, eu não incluo no DROP os pacotes que forem de retorno, ou seja, se você acessa um site (na porta 80), quando ele mandar uma resposta pra você, ele vai responder nas portas altas (acima de 1024), então, como essa conexão é uma conexão de retorno, excluindo o RELATED não aplica o connlimit, evitando problemas na navegação (principalmente de clientes com rede cheia de computador e com muita requisição - frisando que pra mim, esse cliente é um único IP, porém seus computadores estão todos por trás de NAT.

obs2: "--connlimit-above 12" = diz que o máximo é 12 conexões simultâneas.

obs3: "--connlimit-mask 32" = diz que ele vai tratar todos os IPs que passarem pela regra serão tratados isoladamente (ou seja, com a máscara /32, ou, 255.255.255.255), o que significa que serão 12 conexões simultâneas por IP -> 12 por cliente.

Bom é isso. Agora rola p2p na rede, sem prejudicar a qualidade, sem derrubar repetidora, etc, etc...Mesmo quem insista que os software p2p usem portas UDP, e o connlimit não limita UDP, o tráfego UDP é sempre muito menor que o tráfego TCP, da ordem de 1/4 + ou - , ou seja, limitando o número de conexões simultâneas TCP, o número de conexões UDP ficam limitadas aqui.

Vou mostrar também agora alguns dados.

Usando o aplicativo IPTSTATE, eu posso listar todas as conexões ativas por IP, todas as conexões ativas no geral (de todos os clientes), etc..então, com ele, eu posso analisar aqui as conexões simultâneas. Então ai vão alguns dados (obs1: eu sempre vou analisar somente as conexões ESTABLISHED - estabelecidas - as demais - CLOSED, TIME WAIT, etc. - eu vou deixar de fora, já que não interessam):

1) Quantidade conexões simultâneas (num cliente que tá com p2p ligado agora):

# iptstate -s | grep 10.0.0.6 | grep ESTAB

10.0.0.6,1040 207.46.110.87,1863 tcp ESTABLISHED (porta excluida) - msn
10.0.0.6,4172 201.72.219.110,4662 tcp ESTABLISHED (1) - emule
10.0.0.6,4173 200.233.133.1,4662 tcp ESTABLISHED (2) - emule
10.0.0.6,4183 201.69.97.126,4662 tcp ESTABLISHED (3) - emule
10.0.0.6,1046 207.46.111.69,1863 tcp ESTABLISHED (porta excluida) - msn
10.0.0.6,3626 201.50.84.53,4662 tcp ESTABLISHED (4) - emule
10.0.0.6,3948 201.215.155.80,4662 tcp ESTABLISHED (5) - emule
10.0.0.6,4170 62.10.87.177,5806 tcp ESTABLISHED (6) - emule
10.0.0.6,2337 207.46.27.79,1863 tcp ESTABLISHED (porta excluida) - msn
10.0.0.6,3387 81.169.143.167,7777 tcp ESTABLISHED (7) - emule
200.211.148.33,3028 10.0.0.6,1353 tcp ESTABLISHED (porta excluida) - proxy
10.0.0.6,4291 82.158.203.9,28043 tcp ESTABLISHED (8) - não sei o que é
10.0.0.6,3387 81.169.143.167,7777 tcp ESTABLISHED (porta excluida) - jogo on-line
10.0.0.6,4266 201.20.241.170,22493 tcp ESTABLISHED (9) - nao sei o que é
10.0.0.6,4340 201.221.26.22,82 tcp ESTABLISHED (porta excluida)

Então, são 16 conexões simultâneas, porém apenas 9 entram no bloqueio/limite...ainda tem espaço pra mais 3 de p2p por exemplo...as portas excluidas são aquelas que não passam pelo CONNLIMIT.

2) Quantidade de conexões simultâneas no geral de uma repetidora (com 176 clientes):

# iptstate -s | grep ESTAB | wc -l = 2610

então: Qtde. de clientes * 12 = 176 * 12 = 2112

Qtde. de conex. na porta 80 (navegação):

# iptstate -s | grep ESTAB | grep ",80 " = 934

Qtde. de conex. na porta 1863 (MSN - o mais usado hehehehe):

# iptstate -s | grep ESTAB | grep ",1863 " = 605

Qtde. de conex. na porta 443 (páginas com SSL)

# iptstate -s | grep ESTAB | grep ",443 " = 176

Bom, a maioria dos acessos, como dá pra ver, são de portas saudáveis...o resto eu ainda nem contabilizei, e ainda tô fazendo isso num horário de folga, sem muito uso!

Bom, a intenção desse mini-artigo é dar uma idéia de como é implementar o connlimit (visto que há muita discussão por aqui sobre isso) e também de mostrar como fazer pra analisar essa questão das conexões simultâneas e como fazer pra atacar essa situação, deixando sua rede mais saudável, porém, sem prejudicar alguns serviços essenciais.

T+ galera, qualquer coisa tô na área. Por favor, façam seus testes e postem os resultado!

Muita bacana roneyeduardo ficou bem explicado.
So me responde uma coisa, aonde colocou o JUMP jogando os pracotes de quais chains para a CONNLIMIT ?
FORWORD apenas?

Isso, tô fazendo esse JUMP apenas na cadeia FORWARD e tá rolando beleza...o interessante tbm fica por conta da ferramenta IPTSTATE associado ao GREP, assim você pode analisar todos os aspectos e ter visão bacana de como tudo está acontecendo!! Como eu sei que você usa Mikrotik, acho que dá pra você levar pra lá os conceitos, de criar uma nova cadeia no firewall, fazer o Jump, e usar o connlimit nas portas desejadas, fazendo as devidas exclusões!

o cabra...

interessante isso..

vc podia criar um wiki para essa matéria..

valeu

Vou tentar botar no Wiki...

Cara, seguinte, eu entreo no Wiki do underlinux, mas não sei como postar um artigo ou tutorial...sei lá, não é intuitivo pra mim achar como fazer pra criar um wiki....alguém pode dar uma dica?

cara..

pra vc criar um wiki basta colocar o nome depois do endereço do wiki.. :) entendeu???

vamos lá.. vc vai criar um tutorial do iptables pra uso do CONNLIMIT

então será em segurança..

o endereço ficará:
https://under-linux.org/wiki/index.p...nome_wiki_novo

vc troca nome_wiki_novo pelo nome que vc quiser dar...

valeu

Agora meu patrão!!! Show, vou fazer!!!

Pronto, já tá no Wiki:

https://under-linux.org/wiki/index.p...do_o_Connlimit

Um outro tutorial novo, que um amigo nosso daqui do fórum, o Tianguapontocom elaborou, e que pode ser muito interessante à todos, é sobre Controle de Banda (HTB) + Squid Cache à toda velocidade (ou seja, o que tá no cache do squid não passa pelo controle de banda):

https://under-linux.org/wiki/index.p...R_CACHE_GRANDE

roneyeduardo ja tinha isso no mikrotik ja, mas com seu post ai tive uma visao fora do quadrado bem legal.
agora vamos la roney, tu conhece de handshake?

Handshake ou aperto de mão é o processo pelo qual duas máquinas afirmam uma a outra que a reconheceu e está pronta para iniciar a comunicação. O handshake é utilizado em protocolos de comunicação, tais como: UDP, FTP, TCP, HTTP, e em cima das FLAG's TCP/IP. etc.

Assim você consegue fazer uma conexão entre duas máquinas só esperando o serviço a ser disponibilizado.

Fiz aqui um QoS no mikrotik bem interessante em cima do que voce tinha analisado CONNLIMIT e comecei a entender bem mais como que funciona.

FIz QoS em cima de conexoes ESTABELECIDAS, que usam as FLAGS "ACK"
Deu um resultado bem interessante aqui.
Mas mesmo assim vou dar mais uma estudada em cima disso que quero tirar umas duvidas se 'e melhor fazer QoS em cima FLAG'S "SYN" ou "ACK"
SYN = 'e inicio de conexao.
ACK = 'e quando a conexao esta estabelecida por uma das partres

Se alguem que estiver lendo esse post enternder bem de FLAGS TCP/IP e quiser discutir algo, poste ai.

Abracos.

blz cara...

depois vou dar uma olhada com mais calma... mas fico bom!!

valeu

Muito interessante seu artigo!! Tive que fazer umas modificacoes para funcionar. Vamos la (vou tentar ser didatico como voce! eheh)

Fiz as seguintes regras:
iptables -N CONNLIMIT
iptables -A FORWARD -p TCP -d 0/0 --dport 21 -j CONNLIMIT
iptables -A CONNLIMIT -p TCP -m state ! --state RELATED -m connlimit --connlimit-above 1 --connlimit-mask 32 -j DROP

Ou seja, nao deixa ninguem fazer mais do que uma conexao de FTP. Ocorre que abri 3 conexoes com o ftp da Unicamp (ftp.unicamp.br) e baixei 3 arquivos diferentes.. Nao funcionou...

Ai tentei da seguinte forma:

iptables -t mangle -N CONNLIMIT
iptables -t mangle -A FORWARD -p TCP -d 0/0 --dport 21 -j CONNLIMIT
iptables -t mangle -A CONNLIMIT -p TCP -m state ! --state RELATED -m connlimit --connlimit-above 1 --connlimit-mask 32 -j DROP

Ou seja, comecei a trabalhar na tabela mangle. Ai deu tudo certo. Abri a 1a conexao com o ftp e deixei baixando um arquivo. Fui tentar abrir a segunda e nada....

Se alguem tiver algum conhecimento para explicar pq somente da forma que fiz funcionou, manda ai!
Abraco!
Fabricio

roney qual kernle vc usou e qual ver. do POM vc usou?

Aê galera, seguinte, eu não postei no artigo como recompilar, aplicar patch e etc...pq eu não precisei fazer isso...mas sobre esses assuntos tem muito ai pelo google. Como eu uso CentOS, o iptables dele já vem com este suporte, porém o kernel não, mas eu consegui achar um repositório de pacotes RPM onde um cara fez um pacote pré-compilado só com o módulo do connlimit, bastando apenas instalar esse pacote RPM e dar um modprobe no módulo (isso pq o Kernel do RH Enterprise / CentOS não aceitam o patch do connlimit direto do pom, dá erro....mas esse cara desse repositório fez umas alterações no código pra poder funcionar)

Mas minha vontade era realmente apenas de criar um artigo conceitual, pois acho que o maior problema da galera era realmente fazer uma implementação bacana do Connlimit.

Quanto à questão de usar a tabela mangle, eu vou fazer uns testes aqui (Referente ao que o Fabricio Viana falou).

Quanto à isso do handshake, sobre fazer QOS em cima das Flags TCP do pacote, acho que realmente seria interessante elaborarmos um estudo quanto a isso. Preliminarmente, acho bem interessanto fazer os pacotes SYN passarem com prioridade maior, e com maior banda reservada, e deixar os pacotes ACK passando por uma regra com menor prioridade e banda mais limitada...Bom, seria uma boa.

Mas na minha opinião, acho que excelente mesmo seria fazer uma integração ULTRA entre Squid, Iptables e HTB (que é o QOS que eu uso aqui). Eu já tô estudando essa possibilidade, com alguns patches que existem pro squid, como o ZPH e o TPROXY...e tbm na minha cabeça, seria preciso tbm botar o IMQ pra funcionar...Mas isso aí é coisa pra depois, pois eu tô sem máquina aqui pra fazer testes, recompilação, etc...

A minha idéia seria assim, com o iptables + IMQ, agente conseguiria colocar os serviços que passam por fora do proxy (tipo, FTP, MSN, jogos On-line, SMTP, POP3, etc..) em queues (filas) com prioridades definidas...E pra trabalhar em cima dos acessos HTTP, com o Squid + TPROXY + ZPH, dava pra gente fazer acls com arquivos do tipo exe, iso, wmv, zip, rar, etc...e definir um valor de TOS (que é o que os patches ZPH fazem), ai no controle de banda (HTB) fazer com que os pacotes com determinado TOS tivessem menos prioridades...e por ai vai....Mas isso por enquanto eu tô só na VIAGEM, pois como falei, ainda não pude fazer as implementações na prática...t+

Roney quando estiver livre aqui vou pegar para ler mais a fundo sobres os FLAGS, estamos montando umas repetidoras na cidade aqui que esta me tomando muito tempo. Mas assim que estiver livre vou ver isso e posto aqui.

Abracos.

qual o limite teorico que vcs deixaram em seus provedores? para não prejudicar os clientes?

Será que você poderia passar todas as ranges de portas que você usa, ou seja, quais as portas altas que você exclui do controle de conexões?

Como posso aplicar este patch-matich no iptables, uso o debian.