comentarios interesantes no ano 2.003
http://www.dslreports.com/shownews/27754
Internet Header Format
pagina 10 (September 1981)
http://www.faqs.org/rfcs/rfc791.html
Lee
comentarios interesantes no ano 2.003
http://www.dslreports.com/shownews/27754
Internet Header Format
pagina 10 (September 1981)
http://www.faqs.org/rfcs/rfc791.html
Lee
Estava pesquisando sobre o assunto e não encontrei nada que faça o bloqueio do compartilhamento, a unica coisa que achei que da para quebrar o galho e limitar as conexões simutaneas. limitando assim o numero de programas e conexoes abertas.
Se funcionar mesmo e vai ter muita gente interessada.
Eis o comando:
IPCLIENTE=192.168.20.35
iptables -A FORWARD -s $IPCLIENTE -m ttl --ttl-eq 126 -j LOG --log-prefix 'CLIENTE COMPARTILHANDO: '
iptables -A FORWARD -s $IPCLIENTE -m ttl --ttl-eq 126 -j DROP
Uma ideia interessante também é colocar as conexões compartilhadas em links virtuais no tc de baixa velocidade, tipo, se o cliente tem 128kits, as conexao de compartilhamento podem ser limitadas a 10% da banda contratada!
Outra coisa é concientizar!
Redirecionar pelo PREROUTING os pacotes com ttl suspeito para uma pagina de aviso:
E PROIBIDO COMPARTILHAR CONEXAO
Fontes:
http://www.netfilter.org/documentati...-3.html#ss3.20
http://www.linuxfan.pl/dyskusje/pcol...2003/8328.php3
Sinceramente não consigo entender! Antes quando utilizavamos o modem 56K éra tudo uma maravilha, sem problemas de restrição de compartilhamento. Pô, afinal estamos contratando um acesso a Internet ou uma change de navegar numa estrada congestionada com pedagios e rodisios?? Se é uma conexão de 300 kbps contrata, é ela que devemos ter, se á pra todo mundo dividir essa conexao, então que a cobrança seja feita pela velocidade de navegaçao momentanea. Por que pagar por 300 kbps se nunca vai têla? Isso sim é roubar e iludir o consumidor.Postado originalmente por nataniel
Se contrato uma um fornecimento de energia, eu pago pelo que uso, isso sim é justo, e sempre vou ter a energia que preciso quando preciso.
Agora, se o provedor não tem condiçoes de fornecer a banda que foi contratada, é sujeira mesmo, a não ser que conste no contrato ( que no meu não tem).
Se é muito caro fornecer serviço de provedor, então não forneça. Para que se preocupar? Deixe o captalismo enrrustido das grandes companhias correrem atrás, e vão.
Me desculpe, mas se eu contratei um acesso a Internet, não interessa ao fornecedor o que vou fazer com ele, se acessar paginas pornograficas, acessar banco, baixar arquivos, usar VOIP, ou ligar outro computador.
É um acesso e pronto.
O que me deixa P da vida, é que sempre a gente leva a pior.
:kiss:
Pessoal,
respeito a opnião do consumidor. Minha posição aqui nesse tópico e discutir e descobrir técnicas de redes e oferecer, como prestador de serviço, aos provedores de internet.
Quero sugerir aos consumidores e provedores que iniciem um topico para discutir politica de contrato, etica de consumo e fornecimento de acesso a internet.
Gostaria de discutir nesse topico apenas assuntos técnicos que envolvem camada 2 a camada 5 de redes de computadores. Creio que vai dar boas ideias!
Concordo com vc patrick, já que eu tb nem tenho provedor gostei desse topico para conhecimento da coisa, pois alem do ttl pode ter outras formas de controle, que alem de podermos oferecer serviços diferentes também podemos aumentar a segurança de nosso servidores e melhorar nossos serviços.
falows
Pessoal,
o bloqueio por ttl realmente funciona. As caracteristicas do bloqueio são os mesmos do apresentado pelo amigo que criou esse tópico: ping funciona mas não resolve dns nem conecta.
Fiz os teste compartilhando com um windows xp e também fiz testes com o linux. Cheguei as conclusões:
Definição:
web(4)
|
|
gateway provedor(3) <---------> pc cliente(2) <------- pc interno(1)
1 - os valores de ttl originais usados pelos sistemas operacionais são:
windows - a maioria usa 128
linux - por padrao, 64 mas pode ser alterado em /proc/sys/net/ipv4/ip_default_ttl
2 - conexão vindas diretas do pc do cliente apresentam ttl padrão menos um, ou seja, 127 (windows) ou 63 (linux). Permitir esses ttl é garantir com 90% de precisão que não haverá conexões compartilhadas. A técnica para garantir o bloqueio será listado mais abaixo.
3 - quando a maquina da rede interna (pc interno) usa proxy na maquina do pc cliente que compartilha a internet, o ttl não é decrementado duas vezes como no caso do nat. Como há uma conexão do pc interno com o pc cliente, e outra conexão do pc cliente com a internet, não é possível identificar pelo conteudo dos cabeçalhos ip. A técnica para inibir o proxy no pc cliente será listada abaixo.
4 - Inibindo o uso do proxy: Como o proxy se faz passar por um browser na visão do servidor remoto na web(4), ele é obrigado a enviar o campo User-Agent (leia: http://en.wikipedia.org/wiki/User_agent ). Utilizando o path-o-matic é possível bloquear os pacotes contendo essa string, assim não haverá conexão pelo proxy do pc cliente(2) (hauhauah!!!). Exemplo de bloquear o proxy no pc cliente(2):
IPCLIENTE="192.168.10.24"
# squid (www.squid-cache.org):
iptables -I FORWARD -s $IPCLIENTE -m string --string 'User-Agent: Squid' -j DROP
5 - o cliente pode manipular a ttl em qualquer sistema operacional para descobrir um valor de ttl que burle a regra, a solução para isso é garantir acesso apenas a ttl 127. Como o valor maximo de ttl é 128, o cliente não vai conseguir colocar 129 para se safar dos dois decrescimos que sofrerá! Em compensação, o provedor deve ficar atendo em corrigir esse fator em clientes com linux que por padrão tem ttl 64.
Use:
# bloquear todas os pacotes com ttl menor que 127
iptables -I FORWARD -m ttl --ttl-lt 127 -j DROP
#ou, permitir apenas a 127
iptables -I FORWARD -m ttl --ttl-eq 127 -j ACCEPT
iptables -P FORWARD DROP
Relativamente, apenas essas duas técnicas foram funcionais até o momento para determinar um compartilhamento: TTL e String User-Agent
Quem aprender mais alguma posta aqui!
Postado originalmente por PatrickBrandao
No proprio gateway e sem NAT o ttl é o default, ou seja, 128 para os Windows e 64 para a maioria dos Linux e se não me engano Win95. A partir dai se decrementa 1 por roteador lembrando-se qu bridges não decrementam o ttl. Assim no próximo hop atras do gateway o ttl normal é 127. Se houver NAT ai sim seria 126.
Para os sysadmin que quiserem detectar NAT com a técnica do ttl basta instalar o tcpdump no gateway e fazer:
tcpdump -v -c 1000 src net 192.168 > tcpdump.log
cat tcpdump.log | grep "ttl 127"
No output estarão os cabeçalhos dos pacotes de maquinas windows atrás de NAT.
Para detectar linux atras de NAT portanto se usa "ttl 63".
Use o man do tcpdump para entender e modificar os parametros.
Se o tcpdump rodar em outra maquina que não o gateway decremente o numero de hops de acordo.
Para bloquear basta usar o match ttl, mas melhor do que simplesmente bloquear é detectar e primeiro entrar em contato para educar o seu cliente.
Na verdade o ttl pode ser facilmente manipulado, mas existem outras técnicas de detecção baseadas em sequencias SYN/ACK/RST que são muito precisas e quase impossiveis de se evadir.
Neste caso não é trivial fazer um bloqueio usando extensões do iptables como acima, mas a detecção tambem é simples pois existem algumas ferramentas de codigo livre disponiveis.
Impedir a detecção por estas ferramentas é muto mais dificil pois seria preciso alterar a pilha TCP/IP do gateway NAT com este objetivo.
Seguem links p/ duas ferramentas de detecção de NAT que usam mas não dependem do ttl do pacote. Para compilar o natdet dependendo da distro usada pode ser preciso mover ou copiar alguns headers, mas existe um pacote com os binarios p/ o slack 10.1.
http://lcamtuf.coredump.cx/p0f.shtml
http://elceef.itsec.pl/natdet/natdet-1.0.5.tgz
[]'s
Prezado Patrick,
Alguns probleams nas técnicas que vc citou:
Sobre inibir o uso do proxy não é possivel usar o string match para inibir o uso de um proxy como o squid pois com as diretivas anonymize_headers e fake_user_agent vc pode driblar isto facilmente.
Sobre a manipulação de ttl, basta fazer o gateway NAT setar o ttl dos pacotes internos para o default do SO e a partir dai este pacote, do ponto de vista de ttl, é absolutamente identico aos pacotes originados no proprio gateway e portanto não podem mais ser filtrados pelo ttl.
[]'s
Ta bom! As técnicas podem ser burladas mas vai exigir um conhecimento técnico intermediário-avançado e muito tempo, onde o primeiro não é pra qualquer um.
Agora, alguem pode expor novas técnicas com comandos do iptables, ebtables ou qualquer outra coisa especifica que incremente verificação nos pacotes a fim de atingirmos nosso objetivo: bloquear o compartilhamento de internet?
Acho que podemos ter um objetivo maior, alem de bloquear entender mais o funcionamento dos pacotes e como controla-los melhor.
falows
QoS na veia...Postado originalmente por ruyneto
Sou dessa mesma opinião... Estou estudando layers a pelo menos 6 meses para tentar entender como trabalhar de forma mais eficaz com P2P, VoIP e outros serviços/protocolos que dependem diretamente de mais banda para funcionarem perfeitamente.
Parabens PatrickBrandao pelo seu desempenho, para complementar a eliminação do compartilhamento do Windows que mata 99% dos supostos tecnicos em informatica, poderiamos ainda ver a LIMITAÇÃO de SESSÃO restringindo no maximo 10 por cliente que é suficiente para ter Email, MSN e IE aberto simultaneamente e puchar o Freio de mao no Emule e P2P semelhantes
Bom pessoal desculpem tanto tanto sem responder, mas voltei para dar minha resposta sobre o compartilhamento em linux........ ele não funciona tambem, já li as respostas do topico e já vi que muita coisa rolou, já irei testar as soluções do patrick........
Minha opinião sobre o compartilhamento:
Se vc comprou um link de por exemplo 100k, eu acho q vc pode fazer compartilhar ele como quiser, só q pelo ao menos no provedor que trabalho tem gente que é muito safada, vejam o pq: o cara compra um link de 64k, dai fala com amigo vizinho e diz que pode "vender" internet pro cara ai puxa um cabo de rede pro carinha e compartilha ganhando dinheiro em cima daquela conexão e eu sei que muitos fazem isso por aqui, é isso que eu acho errado.... o cara compra, revende e se der algum problema de lentidão ainda reclama, mesmo a gente sabendo que ele revende (coisa que o cliente faz questão de omitir), essa é minha opinião.
Flw.
ola patrick se sua ideia funciona entao vc foi fantastico pq faz muito tempo q andava atras disso q nao conseguia e a questao do ttl realmente eh muito boa principamente na questao do iptables a forma de bloqueio pq fica praticamente muito dinamico pra bloquear 99.9% dos clientes q sao windows e eles com certeza nao tem conhecimento tecnico... adorei parabens....
Ja que ele estao usando subnet com mascara .252 para o cliente. *Eu nunca testei isso* mas pode ser o iptables com L7 filtrando netbios...
Fiz um teste aqui no meu servidor colocando apenas a regra que monitora os pacotes com ttl abaixo de 127 e realmente todos os meus clientes que eu sei q tem rede apareceu lá a ttl=126, vou fazer testes de bloqueio de compartilhamento hj ainda, pois só isso ai já bloqueia 99% dos clientes q fazem compartilhamento indevidamente.
Flw.
Amigo recomendo que antes de fazer o bloqueio coloque isso em contrato e divulge a todos seus clientes para não ter problemas com a justiça, e com processos.Postado originalmente por TheHawk
falows
Já existe isso em contrato, quem quiser rede tem que pagar uma taxa extra para o provedor, só que tem os espertos que compartilham por fora e ainda vendem a conexão, é isso que quero acabar.Postado originalmente por ruyneto
Flw.
Não estou conseguindo alterar o valor padrão no linux coloquei no rc.local o seguinte comando:Postado originalmente por PatrickBrandao
echo "128" > /proc/sys/net/ipv4/ip_default_ttl
e apesar de ter sido alterado o tcpdump demonstra ainda a ttl 64
O que pode ser?
Que regras devemos usar para libera nos seguintes casos.Postado originalmente por PatrickBrandao
1)- Rede atrás de um servidor linux
2)- Um determinado ip para que possa fazer compartilhamento e os demais não.
** Quem se habilita para fazer um script ????
Grato,
Thon