+ Responder ao Tópico



  1. 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

  2. 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!



  3. #48
    SysRq
    Citação Postado originalmente por PatrickBrandao
    Descobri o que é!!!! HUAHUAHUAAH!

    Quando o pacote passa pelo gateway do clientes, como dz no padrão de internet:

    "para cada novo host ou salto, ou quando o pacote passa mais de um segundo na fila, o campo ttl deve ser decrementado"

    Ou seja, o ttl do pacote IP que vem de uma conexão aberta no gateway é por padrão 127 (128 menos o primeiro salto), ja da maquina atras do gateway é 126 (primeiro salto: gateway do clientes, segundo salto: gateway do provedor)

    O comando para bloquear pelo ttl está em www.netfilter.org
    acabei de descobrir e tenho que ir pra faculdade, mais tarde eu posto os comandos completos (se alguem já nao tiver posto!!!)

    abraços,
    Patrick Brandão

    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

  4. #49
    SysRq
    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



  5. 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?






Tópicos Similares

  1. Blooquear compartilhamento de conexão via rádio.
    Por CEP no fórum Servidores de Rede
    Respostas: 2
    Último Post: 19-04-2007, 22:58
  2. Bloquear compartilhamento de internet
    Por douglassantos no fórum Redes
    Respostas: 9
    Último Post: 21-07-2006, 15:12
  3. SObre compartilhamento de conexao
    Por tiagoalgodas no fórum Servidores de Rede
    Respostas: 14
    Último Post: 08-03-2006, 12:15
  4. compartilhamento de conexão
    Por mabarros no fórum Servidores de Rede
    Respostas: 6
    Último Post: 31-10-2004, 19:43
  5. Compartilhamento de conexão discada com VMWARE
    Por Gustavo Pontes no fórum Servidores de Rede
    Respostas: 6
    Último Post: 31-10-2004, 18:59

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L