Bloquear kazaa

[sergio]

....
Sérgio, está controlando sim!!! tenta colocar essas mesmas regras de mangle na chain " POSTROUTING " com crtza vai dar certo!!! :good: :good:

Blz Michael, vou rever as regras aqui para o POSTROUTING (pois jah tem um POSTROUNTIG no codigo ae em cima..) e depois posto o resultado aqui. :good:

[Jim]

Pelo que pude verificar, no postrouting nao adiantaria marcar os pacotes pela roda a ser usada já estar definida... vale à pena verificar a veracidade da informação...

[Avenger]

Jim,

Vai ver tem alguma outra regra antes da regra que você tá colocando prá marcar, que esteja absorvendo o pacote, então não esteja por isso marcando os pacotes. Tenta o seguinte, ao invés do iptables -A, usa iptables -I prá inserir a regra no início da corrente PREROUTING da tabela mangle. iptables -nvL PREROUTING -t mangle e vê se finalmente incrementa. Se não, vai simplificando com um -j LOG, de repente o layer7 não detecta pacotes ao-serem-criados como http, daí a regra talvez tenha que estar na corrente FORWARD (se é que a forward da mangle aceita MARK).

De qualquer forma, pode ser que a 'pattern' http seja diferente, quando passa na prerouting, e quando passaria em outra corrente. O que você faz, como disse, prá ver se o pacote tá mesmo 'chegando' até a regra que você fez, é, ao invés de colocar ela, colocar um -j LOG -s 192.168.7.100 ... e talvez até colocar a regra do l7 após a log. (LOG não absorve o pacote, ela loga e deixa o pacote continuar passando pelo restante das regras da corrente.

Daí se você ver que o -j LOG incrementa (ou fica aparecendo no 'dmesg') mas a do layer7 não pega, o problema pode tar no pattern que vc tá usando. Eu não sei direito como é, mas parece que determinada conexão TCP passa na PREROUTING só enquanto está começando a conexão, e a maioria dos pacotes http iriam passar pelo forward (a vantagem de barrar no prerouting é porque ia cortar o mal pela raiz).

Espero que ajude! :P

Agora expressando minha idéia sobre o que o pessoal aí falou sobre barrar, bloquear, e mandar clientes prá aquele lugar, minha iniciativa foi, sendo nós provedores de acesso, fazer como a Telemar no Velox. Oferecemos a banda: o cliente faz o que quiser com ela. Pode entrar ne IRC, msn, abrir 65536 conexões nos mais diversos kazaa's da vida... (só espero que nossos switches aguentem a quantidade de pacotes por segundo!..). Mas eles não passam da banda. Como eu não confio em qdiscs, eu uso regras baseadas no iproute2 e o módulo shaper, que só faz limitações de 1bps a 1Mbps, em geral fornecendo 128k de download e 96 ou 64k de upload. E o link é dedicado: 128k a cada usuário, e não 128k para um prédio inteiro. E não tem nada de empréstimo de banda. é os 128k e pronto hehe.

Meu único problema com essa limitação pelo shaper, é que o único jeito que achei de limitar o upload dos clientes é bastante limitado, eu só posso fazer no máximo 255 canais limitados -- geralmente suficiente em cada local em que temos firewall linux segurando -- implementei esse sistema de limitação até em LRP (fiz um pacotinho pro bering).

Aproveitando a mão: alguém aqui já ouviu dizer que, fazendo limitação de banda com o HTB/CBQ, há uma margem de falha na limitação na qual, um usuário com muitas conexões abertas, pode prejudicar o dos outros ou exceder o próprio link delegado a ele?

[mauzao]

Aí... eu concordo com o Brenno...

aqui na empresa, uso squid com regras de iptables...

perfeito... não conecta MSN, kazaa, e outros do gênero...

bloqueio também, todos sites de proxy que consigo ter acesso, assim o usuário não tem como conectar...

[ ]´s
Mauzão

[Michael]

Pelo que pude verificar, no postrouting nao adiantaria marcar os pacotes pela roda a ser usada já estar definida... vale à pena verificar a veracidade da informação...

:clap: :clap:
É isso ai!!! vc tem toda razão " vale à pena verificar a veracidade da informação... "
:toim: :toim: :toim: :toim: :toim: ufffff!!!!!!

" Prove-nos o contrário da informação que eu dei JIM"
da pra perceber que desde o inicio o seu l7 não ta funfando corretamente,
não ta aplicando as regras em todas as chains, como lhe falei antes pode ser a versão Default do Kernel do seu Debian que não tem patch do l7 desenvolvido pra ela, e isso pode ta causando o funcionamento inadequado do seu l7...

Da uma checada nesse end. http://sourceforge.net/project/showf...kage_id=109674

Não existe nenhuma versão do l7 com patch na versão do kernel default que acopanha o Debian 3.1 que vc ta usando, baixe essa versão http://prdownloads.sourceforge.net/l...ar.gz?download
depois o Kernel - 2.6.11.8, complile com os devidos módulos ativados, remova o iptables default que acompanha o debian #aptitude remove iptables; Depois instale o iptables 1.3.1 que vai funfar perfeitamente em todas as chains que vc precisar! falow!!!

Se ter alguma dúvida a respeito, quiser ver alguma saida do meu iptables com l7 fique a vontade estou a disposição!!!!!

:twisted: :twisted: :twisted:

[Jim]

Jim,

Vai ver tem alguma outra regra antes da regra que você tá colocando prá marcar, que esteja absorvendo o pacote, então não esteja por isso marcando os pacotes.

A única regra que estou usando é essa... vou tentar atualizar o kernel conforme o Michael recomendou, grato mesmo.

[Jim]

Pelo que pude verificar, no postrouting nao adiantaria marcar os pacotes pela roda a ser usada já estar definida... vale à pena verificar a veracidade da informação...

:clap: :clap:
É isso ai!!! vc tem toda razão " vale à pena verificar a veracidade da informação... "
:toim: :toim: :toim: :toim: :toim: ufffff!!!!!!

" Prove-nos o contrário da informação que eu dei JIM"
da pra perceber que desde o inicio o seu l7 não ta funfando corretamente,
não ta aplicando as regras em todas as chains, como lhe falei antes pode ser a versão Default do Kernel do seu Debian que não tem patch do l7 desenvolvido pra ela, e isso pode ta causando o funcionamento inadequado do seu l7...

Da uma checada nesse end. http://sourceforge.net/project/showf...kage_id=109674

Não existe nenhuma versão do l7 com patch na versão do kernel default que acopanha o Debian 3.1 que vc ta usando, baixe essa versão http://prdownloads.sourceforge.net/l...ar.gz?download
depois o Kernel - 2.6.11.8, complile com os devidos módulos ativados, remova o iptables default que acompanha o debian #aptitude remove iptables; Depois instale o iptables 1.3.1 que vai funfar perfeitamente em todas as chains que vc precisar! falow!!!

Se ter alguma dúvida a respeito, quiser ver alguma saida do meu iptables com l7 fique a vontade estou a disposição!!!!!

:twisted: :twisted: :twisted:

Acho que vc nao entendeu Michael... não estou me referindo ao meu caso qdo falei isso. O que acontece é que pelo que eu li, não adianta marcar pacotes para o iproute na tabela postrouting pq a decisão de qual rota será usada, já foi tomada ANTES do postrouting, é a isso que me refiro. Estou tentando colaborar, não preciso provar nada...

[sergio]

....
Sérgio, está controlando sim!!! tenta colocar essas mesmas regras de mangle na chain " POSTROUTING " com crtza vai dar certo!!! :good: :good:

Blz Michael, vou rever as regras aqui para o POSTROUTING (pois jah tem um POSTROUNTIG no codigo ae em cima..) e depois posto o resultado aqui. :good:

Bom... acrescentei o POSTROUTING às regras e ateh agora estah ok... abaixo a saida do TC:

class htb 1:7 parent 1:1 leaf 7: prio 0 rate 64Kbit ceil 64Kbit burst 1023b cburst 1679b
Sent 417856130 bytes 1865254 pkts (dropped 392929, overlimits 0 requeues 0)
rate 7319bit 26pps backlog 111p
lended: 1862498 borrowed: 2645 giants: 0
tokens: -91383 ctokens: -179035

class htb 1:8 parent 1:1 leaf 8: prio 0 rate 64Kbit ceil 64Kbit burst 1023b cburst 1679b
Sent 396654820 bytes 412520 pkts (dropped 54439, overlimits 0 requeues 0)
rate 8008bit 8pps backlog 52p
lended: 412427 borrowed: 41 giants: 0
tokens: -209444 ctokens: -297096

Pelo que pude verificar, no postrouting nao adiantaria marcar os pacotes pela roda a ser usada já estar definida... vale à pena verificar a veracidade da informação...

:clap: :clap:
É isso ai!!! vc tem toda razão " vale à pena verificar a veracidade da informação... "
:toim: :toim: :toim: :toim: :toim: ufffff!!!!!!

" Prove-nos o contrário da informação que eu dei JIM"
da pra perceber que desde o inicio o seu l7 não ta funfando corretamente,
não ta aplicando as regras em todas as chains, como lhe falei antes pode ser a versão Default do Kernel do seu Debian que não tem patch do l7 desenvolvido pra ela, e isso pode ta causando o funcionamento inadequado do seu l7...

Da uma checada nesse end. http://sourceforge.net/project/showf...kage_id=109674

Não existe nenhuma versão do l7 com patch na versão do kernel default que acopanha o Debian 3.1 que vc ta usando, baixe essa versão http://prdownloads.sourceforge.net/l...ar.gz?download
depois o Kernel - 2.6.11.8, complile com os devidos módulos ativados, remova o iptables default que acompanha o debian #aptitude remove iptables; Depois instale o iptables 1.3.1 que vai funfar perfeitamente em todas as chains que vc precisar! falow!!!

Se ter alguma dúvida a respeito, quiser ver alguma saida do meu iptables com l7 fique a vontade estou a disposição!!!!!

:twisted: :twisted: :twisted:

Acho que vc nao entendeu Michael... não estou me referindo ao meu caso qdo falei isso. O que acontece é que pelo que eu li, não adianta marcar pacotes para o iproute na tabela postrouting pq a decisão de qual rota será usada, já foi tomada ANTES do postrouting, é a isso que me refiro. Estou tentando colaborar, não preciso provar nada...

Não quis falar nesse sentido de ofensa, só quis deixar clara a informação que passei, detalhando mais sobre a mesma!! Quando eu disse " prove " na realidade queria dizer " Como obteve essa conclusão, algo assim "
:good: mas blza!!! recompila esse kernel e passe aqui pra gente ver como ficou...

[Michael]

Pelo que pude verificar, no postrouting nao adiantaria marcar os pacotes pela roda a ser usada já estar definida... vale à pena verificar a veracidade da informação...

:clap: :clap:
É isso ai!!! vc tem toda razão " vale à pena verificar a veracidade da informação... "
:toim: :toim: :toim: :toim: :toim: ufffff!!!!!!

" Prove-nos o contrário da informação que eu dei JIM"
da pra perceber que desde o inicio o seu l7 não ta funfando corretamente,
não ta aplicando as regras em todas as chains, como lhe falei antes pode ser a versão Default do Kernel do seu Debian que não tem patch do l7 desenvolvido pra ela, e isso pode ta causando o funcionamento inadequado do seu l7...

Da uma checada nesse end. http://sourceforge.net/project/showf...kage_id=109674

Não existe nenhuma versão do l7 com patch na versão do kernel default que acopanha o Debian 3.1 que vc ta usando, baixe essa versão http://prdownloads.sourceforge.net/l...ar.gz?download
depois o Kernel - 2.6.11.8, complile com os devidos módulos ativados, remova o iptables default que acompanha o debian #aptitude remove iptables; Depois instale o iptables 1.3.1 que vai funfar perfeitamente em todas as chains que vc precisar! falow!!!

Se ter alguma dúvida a respeito, quiser ver alguma saida do meu iptables com l7 fique a vontade estou a disposição!!!!!

:twisted: :twisted: :twisted:

Acho que vc nao entendeu Michael... não estou me referindo ao meu caso qdo falei isso. O que acontece é que pelo que eu li, não adianta marcar pacotes para o iproute na tabela postrouting pq a decisão de qual rota será usada, já foi tomada ANTES do postrouting, é a isso que me refiro. Estou tentando colaborar, não preciso provar nada...

Não quis falar nesse sentido de ofensa, só quis deixar clara a informação que passei, detalhando mais sobre a mesma!! Quando eu disse " prove " na realidade queria dizer " Como obteve essa conclusão, algo assim "
:good: mas blza!!! recompila esse kernel e passe aqui pra gente ver como ficou...

ops: Esqueci de logar!!!!!

[vonlinkerstain]

Pra redirecionar a banda destes malditos p2p tenho que compilar o l7?

Não precisa, desde que ele esteja ja corretamente instalado e configurado não tem problema, funciona tranquilamente, sem precisar fazer recompilação! :good: :good:

No caso aqui, o L7 n~ao está instalado nao...
Eu queria saber é se o controle de banda só funcionava com estes l7, e é o que acontece (pelo visto).

[Jim]

blz Michael.. não falei no sentido de provocação não, apenas pra constar... hehe :P

[Avenger]

Jim,

Mas o comentário que fiz foi em âmbito de não estar nem incrementando a leitura no iptables -nvL. Se não tá incrementando os 'hits' na regra, significa que ela não tá pegando o pacote mesmo, então nem se o l7 tiver habilitado direito, vai funcionar. Mesmo que desse erro e tudo por kernel não estar compilado ou coisa do tipo, a regra deveria estar sendo 'contada' toda vez que algum pacote pertinente passasse por ela. Se não está sendo contado, provavelmente a regra não está absorvendo pacote nenhum que passa pela PREROUTING (algo como in-interface, ip não está batendo com a realidade) -- por isso testar com o -j LOG para ver se a regra que você está colocando está pegando o IP e porta que você quer. Enquanto o pacote não for 'catado' pela regra, ele não vai nem 'tentar' fazer a interpretação do layer7, o que só então, pode resultar em erro ou não devido ao layer7 estar ou não implementado corretamente... Aliás, acho que só do iptables aceitar a regra, já significa que o kernel e iptables está compilado com o suporte ao layer7.
Além do mais, com o -j LOG, você pode verificar (uma vez pêgo o pacote que você quer) se pode afinar a regra ou se deve deixá-la um pouco mais ampla... E se o -j LOG não pegar, significar que a regra do layer7 também não irá pegar. Note que é bom você -trocar- a regra do layer7 para a regra do LOG enquanto depurando, depois você pode deixar só a do layer7 quando souber que ele vai implementar direitinho no contador do iptables -nvL.
Uma observação que acho importante também, você deve saber, mas alguém de fora que possa estar acompanhando o tópico pode não esperar, é que na corrente prerouting só batem pacotes 'de abertura' de conexão. Então para um pacote 'bater' ali, não basta estar fazendo um download de um site, mas sim, enquanto monitora a regra no PREROUTING, -iniciar- o download de um arquivo (de site http por ser porta 80 a de seu interesse), ou abrir/reabrir alguma página web que se esteja usando como teste. Ou, simplesmente, abrir um 'telnet site 80' só para constar a 'abertura de conexao'.

Espero que compreenda a parte que estou tentando explicar: não tou considerando falhas do layer7, mas algo que pode estar prevenindo o pacote de ser absorvido pela regra que você criou, algo -antes- de precisar saber se o l7 funciona ou não. Por isso a sujestão de depurar a regra com uma outra mais simples afim de eliminar qualquer motivo que possa estar significando o 'nao marcamento' do pacote.

Já levando em conta o l7, pode ser que o 'pattern' http que esteja usando não esteja 'batendo' com o pacote que passa pela regra e talvez -isso- tenha a ver com o lance de POSTROUTING que o pessoal falou, e que o pacote que inicia a conexão seja sensivelmente diferente dos pacotes para a conexão já estabelecida... Pelo fato do filtro seguir o tal 'pattern' que é como um 'estilo ou característica do pacote', pode ser que em determinadas situações o http seja diferente e não bate aquele padrão do http que vc escolheu.

[Jim]

Pois Avenger... a regra nao está incrementando no iptables -nvL, e não aparece nada no -j LOG não... estou recompilando o kernel aqui (demora mais, hardware maldito) O mais estranho é que se eu usaro iptables pra BLOQUEAR funciona perfeitamente, lembrando que as únicas regras que possuo são os masquerade dos dois links e essa MARK com layer7... vou aguardar ele recompilar tudo aqui e depois dou um retorno aqui...

[Michael]

Pra redirecionar a banda destes malditos p2p tenho que compilar o l7?

Não precisa, desde que ele esteja ja corretamente instalado e configurado não tem problema, funciona tranquilamente, sem precisar fazer recompilação! :good: :good:

No caso aqui, o L7 n~ao está instalado nao...
Eu queria saber é se o controle de banda só funcionava com estes l7, e é o que acontece (pelo visto).

Eu não entendi bem a sua perguta...
ops: ops:

[Avenger]

Faz o -j LOG sem o --layer7 --pattern http,
Faz tipo algo mais básico:
iptables -t mangle -I PREROUTING -j LOG -s 192.168.7.100 -p tcp -dport 80

Se desse jeito pegar, aí você arranca essa regra e coloca a com o --layer7. Se só de colocar o --layer7 ele não catar mais, aí sim pode ser que o kernel tava precisando ser compilado mesmo.

[Jim]

Foi o que eu disse desde o início.. se eu redireciono com regras simples, funciona tudo perfeito, só nao funciona com as regras do layer7...

[Avenger]

Hehe... Então, se não foi o kernel sem compilar nem iptables sem recompilar também, vai ser o tal padrão a se casar do pacote que não tá 'casando'. Talvez dependendo da corrente que o pacote teja (se é o que inicia a conexão por exemplo) ele seja sensivelmente diferente ou, ainda, o arquivo .pat lá não está certo ou nem está instalado... ou ainda pode ser que foi substituido por outro acidentalmente.

[Jim]

Hehe... Então, se não foi o kernel sem compilar nem iptables sem recompilar também, vai ser o tal padrão a se casar do pacote que não tá 'casando'. Talvez dependendo da corrente que o pacote teja (se é o que inicia a conexão por exemplo) ele seja sensivelmente diferente ou, ainda, o arquivo .pat lá não está certo ou nem está instalado... ou ainda pode ser que foi substituido por outro acidentalmente.

hehehe... se ele tá bloqueando, como eu poderia nao ter recompilado o kernel ou o iptables? Como eu disse... assim que tiver um tempo aqui faço os testes...

[Jim]

Olhae gente:

teste:/# uname -r
2.6.12.1

teste:/# iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 12660 packets, 4564K bytes)
pkts bytes target prot opt in out source destination
9 9416 MARK all -- * * 192.168.7.0/24 0.0.0.0/0 LAYER7 l7proto http MARK set 0x2

Chain INPUT (policy ACCEPT 4399 packets, 470K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 7763 packets, 4032K bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 2943 packets, 356K bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 10700 packets, 4388K bytes)
pkts bytes target prot opt in out source destination
9 9416 MARK all -- * * 192.168.7.0/24 0.0.0.0/0 LAYER7 l7proto http MARK set 0x2

Porémmm.... continua saindo pelo PPP e não pelo adsl :@:

Minhas regras com layer7:

iptables -t mangle -A PREROUTING -s 192.168.7.0/24 -m layer7 --l7proto http -j MARK --set-mark 2

iptables -t mangle -A POSTROUTING -s 192.168.7.0/24 -m layer7 --l7proto http -j MARK --set-mark 2

Se eu marco com as regras seguintes funciona:

iptables -t mangle -A PREROUTING -p tcp --dport 80 -s 192.168.7.0/24 -j MARK --set-mark 2