Impedindo o compartilhamento de conexão

Um provedor wireless me pediu uma solução para impedir que seus clientes compartilhassem suas conexões. E é muito mais simples que se possa supor, até pensei em postar como dica, mas dado o enorme interesse sobre o tema optei por postar como um artigo.

[ Hits: 23.636 ]

Por: Carlos Affonso Henriques. em 07/02/2008


Entendendo o conceito



A princípio ocorreu-me limitar o número máximo de conexões por IP, mas já havia feito isso para uma empresa e achei que a solução além de ser uma gambiarra deteriorava bastante o desempenho da rede.

Lembrei-me então de algo que havia passado os olhos na documentação do Iptables que costumo acompanhar com freqüência. Um módulo chamado ipt_ttl.

Este módulo é o pivô de nossa solução. Vamos entender como ele funciona.

De forma resumida podemos entender o TTL (Time to Live) de um pacote não como uma unidade de "tempo" propriamente dita, mas como um valor que especifica quantos saltos ou hops como são chamados um pacote pode perdurar na rede. Isso é necessário para impedir que um pacote fica vagando ad eternum pela internet sendo enviado de um roteador a outro. O seu valor máximo é de 255.

Cada vez que um pacote atravessa um roteador da internet ele perde "um ponto" por assim dizer. Suponha que um pacote saiu de sua estação com um TTL de 127, que é o valor típico default da maioria dos sistemas operacionais, com destino a um determinado site e no caminho ele atravesse 6 roteadores, por cada um que ele passar ele "perderá" um ponto em seu TTL, então ele chegará a seu destinho com um TTL de 119.

    Próxima página

Páginas do artigo
   1. Entendendo o conceito
   2. Entendendo o módulo ipt_ttl na prática com o Iptables
   3. Algumas considerações
Outros artigos deste autor

Gateway autenticado com Apache, Iptables e CGI em shell

SSHFS no CentOS, Slackware e Windows - Simples e rápido

Administrando usuários no GNU/Linux e Samba via web com PHP

Filtro de conteúdo autenticado com níveis de privilégio

Enviando e-mail pelo shell com smtp remoto

Leitura recomendada

Verificação de integridade de arquivos - Ferramenta OSSEC

Monitoramento de redes com o Zenoss

Sudo 1.8.12 - Parte I - Manual

Consegue guardar um segredo?

PacketFence em Debian 6

  
Comentários
[1] Comentário enviado por cvs em 07/02/2008 - 16:31h

Pow, isso é paia... hehehe
Mas é interessante a solução. Vou precisar testar aqui...

Valeu :D

[2] Comentário enviado por fravo em 07/02/2008 - 17:07h

Trabalho em um provedor de internet wireless... no começo nós não deixávamos compartilhar a conexão.
Não há nenhuma lei que restrinja isso (me corrijam se estiver errado), mas não é uma prática amigável, então a solução que encontramos foi alugar roteadores wi-fi para nossos clientes assim ganhamos com o compartilhamento da conexão.

[3] Comentário enviado por cilmar_oliveira em 07/02/2008 - 21:54h

Nao tive oportunidade de testar a regra....
Mas muito boa sua soluçao....
valew mesmo

[4] Comentário enviado por wilberto em 07/02/2008 - 23:06h

Olá, Carlos... Parabéns pelo artigo!

Mas... Não entendo o que relaciona um TTL maior que 127 ao fato de o cliente estar compartilhando a conexão...

Compartilhei a conexão aqui na minha casa (meu acesso é via provedor wireless e as máquinas aqui são Windows) e todos os pacotes saem com TTL igual a 127, inclusive os originados da "rede interna"... Usando sua técnica o provedor não conseguiria impedir o meu compartilhamento.

Por favor, me explique... Acho que não entendi a sua idéia!

[5] Comentário enviado por engos em 08/02/2008 - 08:47h

Como estou trabalhando com segurança da informação estou me empenhando bem sobre esse tipo de assunto e até parei com as contribuições aqui no site por esse motivo e quando vi seu artigo achei que teria uma leitura bem interessante.

Claro que sua técnica tem seus méritos, mas tem um grande problema, ela não resolve absolutamente nada! Conseguir "driblar" isso é muito simples e possui mais de uma forma.

Alem disso, sobre o que o provedor solicitou é um CRIME!

Há muito tempo que é debatido sobre isso com relação a TV a Cabo, Internet etc, sendo que a lei fala (resumidamente) que se você contrata um serviço para ser disponibilizado, o cliente pode utiliza-lo como preferir.

Mas deixando tudo isso de lado, sobre o artigo em si faltou muita coisa, pois você definiu técnicamente o que é a técnica, algo que seria facilmente encontrado na documentação, mas faltou explicar como ela funciona exatamente, qual a relação dela com a restrição supostamente tentada e o principal, os prós e contras dela, pois pelo que estou vendo sobre ela, quando você tentar trafegar dados via encode type multipart/form-data pode-se ter o serviço erroneamente barrado dependendo de como isso é tratado.

Apesar das observações gostei do artigo pelo fato de ser algo bem diferente dos outros, pois há muito tempo que deixei de ler artigos do VOL devido a maioria serem plágios, ou simplesmente assuntos já abordados sem nada a acrescentar, por isso fico muito grato por ver um artigo de verdade depois de tanto tempo (apesar que não leio artigos voltados a artes gráficas os quais aparentemente são sempre novos, nem de configurações especifica de hardware).

[6] Comentário enviado por removido em 08/02/2008 - 09:28h

engos...

Ótimos argumentos, mostra aí pra galera alguns métodos para driblar o esquema do capitainkurn, assim poderíamos além de aprimorar a técnica do nosso amigo, támbem saberíamos como inibir o usuário a driblar a "barreira".

Ainda que seja Crime, ou politicamente incorreto, acho que é legal nós sabermos essas coisinhas...

[]`s

[7] Comentário enviado por janio.barros em 08/02/2008 - 09:40h

Gostei do artigo, é um boa idéia sim, e como toda idéia é passível de ser aprimorada, mas somente depois de alguem ter colocado o "ovo em pé".

Parabéns

[8] Comentário enviado por capitainkurn em 08/02/2008 - 09:50h

Rodrigo, sabia que o artigo iria dar polêmica! Já até recebí uns e-mails malcriados! rsssss.

Inclusive mencionei que o método seria facilmente "driblável" nas considerações finais como você afirma. E e apesar de concordar em parte com você sobre a postura do provedor. Mas se é CRIME, por que as operadoras de ADSL e cabo mencionam esta restrição em seus contratos?
Inclusive eu os advertí que seria uma política antipática e pouco amigável e que muitos clientes poderiam migrar para a concorrência em face disso, e ainda que não era uma solução perfeita. Mas que fazer? Dizer ao dono do provedor que isso não teria como ser feito mesmo sabendo que havia uma forma?

[9] Comentário enviado por fmpfmp em 08/02/2008 - 10:38h

Nossa, muito interessante. Parabéns!

É preciso apenas um conhecimento básico do protocolo IP pra entender como funciona. A confusão é que ele pôs uma regra que não bloqueia nada, só fez como exemplo. A regra que bloqueia tem que ser pra TTL menor ou igual a 127, e não maior que 127, como ele mostrou. E mesmo assim só funciona com máquinas que tenham o TTL igual ou maior que 128, como máquinas Windows. Se for Linux, bloqueia o acesso. Como o TTL no Windows é 128, quando o pacote passa pelo roteador proibido ele é decrementado para 127.

Acho que devido a natureza do artigo, o autor não quis ser muito direto. :-)

[10] Comentário enviado por capitainkurn em 08/02/2008 - 11:06h

Fausto, Quando mencionei o TTL de 127, eu já considerei que o pacote já havia passado pelo roteador, realmente o TTL default do windows é 128 como você disse.

[11] Comentário enviado por percival em 08/02/2008 - 18:11h

Fala aí, capitainkurn !!

Por uma garrafa de Jack Daniel's mais o dinheiro do busão eu compro esta briga sua.

8^P

Artigo bem legal, parabéns.

[12] Comentário enviado por cytron em 08/02/2008 - 18:47h

ehehe! Tá meio polêmica a coisa aqui!

Mas é assim mesmo, no final de tudo sempre surge a solução definitiva.

Quanto se é crime ou não... Depende da política do provedor.

Há três tipos de serviços:

Residencial: podendo ser utilizado apenas na residência do cliente (Ex.: ADSL resicencial), onde neste caso a "relocação" do serviço contratado é crime. Pois o serviço se caracteriza para uso do contratante. Em outras palavras, o cabo não pode saltar o muro. rs rs rs.

Comercial 1: destinado a uso em empresas (Ex.: ADSL empresarial), a relocação também é crime. Pois é para uso unicamente na empresa. A diferênça entre o residencial, é que este custa mais caro. E "dizem" ter um upload e a garantia de banda maiores.

Comercial 2: Para fins de locação (Ex.: backbone), este é o serviço o qual as teles permitem a relocação, onde a comunicação é síncrona (up e down iguais) e a garantia de banda geralmente é de 99%. Mais conhecidos para uns como: "link bruto" rs rs rs!!! Mas custa os olhos da cara! No caso da Embratel ainda te cobram o nariz também! kkkkkk!

Resimindo... se você tiver uma cópia do contrato da sua banda-larga de empresas telefônicas (o que é muito raro de possuir), pode procurar que você vai ver uma cláusula falando da relocação de serviço. Mas se não tiver... Ah meu amigo! Manda brasa! Se não colocaram... a culpa não é sua! kkkkkkkkkk!!!!

A final... só é crime se tiver uma lei (ou cláusula) afirmando.

Igual aquela coisa de monitorar MSN dentro da empresa, é totalmente legal pois se trata de assuntos internos (uso de equipamentos de trabalho em local de trabalho). Mas vai fazer isso no provedor pra você ver!!! Dá até cadeia!!!

[13] Comentário enviado por capitainkurn em 08/02/2008 - 18:53h

Obrigado Percival! sabia que o artigo seria um tanto polêmico mas não pensava que um artigo de tão poucas linhas fosse render tantos elogios, quanto apedrejamentos!
Imagino o que não fizeram com o autor do módulo ipt_ttl! Rssssss.

[14] Comentário enviado por marquinhos1875 em 09/02/2008 - 20:59h

bla bla bla
pra evitar abuso de clientes e só marcar o pacote e por uma velocidade bem baixa
assim o servidor fica com velocidade massa e os compartilhamentos uma velocidade de bosta
isso com escessoes de compartilhamentos lícitos
obrigado capitainkurn por ter nos abrido os olhos pra esse detalhe
abraço a todos
pro resto, ao invés de fazer criticas besta, apresente soluções sabias

[15] Comentário enviado por engos em 11/02/2008 - 11:27h

Gosto de polêmica, faz com que passamos a expandir a visão durante os debates, se nos permitirmos aprender com ela! :)

Alem disso, devo estar entre os top 20 dos mais amados e no top 5 dos mais odiados, mas não me abato, pois acredito que o importante é compartilhar esse tipo de conhecimento, por isso dos e-mail's malcriados descarto a palhaçada e tento extrair o ponto de vista para saber se é relevante, procure fazer algo do tipo e siga em frente, pois muitos também irão gostar do que você escreve, mesmo que não se pronunciem nos artigos.


O que realmente continua me preocupando é como essa técnica é tratada quando se sobe multiplos arquivos ou stream de dados. Alguem sabe como fica o contador nessas horas?


Sobre o como driblar isso deixo para cada um montar um laboratório e pesquisar, pois seria muito anti-ético de minha parte fazer isso enquanto trabalho numa empresa de segurança da informação (já que o pessoal ganha por ter esse, tão pouco difundido, conhecimento). Quando eu sair de onde trabalho quem sabe monto um artigo alertando sobre métodos de "driblar" a segurança...


Sobre ser crime, apesar de não ser especialista, pelo que sei através de experiência própria é que você pode compartilhar o serviço via wireless, mesmo para "outro muro" quando residencial, pois o serviço é sem fio, claro que se fosse passar o cabo isso seria proibido dependendo do contrato, mas dentro do local contratado, pode-se criar quantos pontos você bem entender, seja cabeado ou não. Lembrando que apesar de você ter o direito de passar o serviço via wireless, dependendo da distância você é obrigado a ter autorização da ANATEL, claro que para os roteadores "caseiros" é desnecessário.

Mesmo em caso de no contrato assinado existir cláusula de restrição/proibição, ela pode ser desconsiderada alegando ser inconstitucional. Quando se trata de lei nada melhor do que um especialista no assunto (que NÃO é meu caso), mas essas cláusulas entrariam como no caso de multa de transito, onde você foi pego pelo radar, lhe enviaram uma carta comprovando isso para você ter tempo de recorrer e só lhe mando um boleto para pagar depois de 60 dias, mesmo estando todo errado, a obrigação é você pagar em até 60 (ou 90, não me recordo agora) dias, depois disso você está liberado a não pagar... Por isso eu digo, com relação a isso é melhor um especialista, pois contratos a parte, sempre há uma lei para a lei.

O que acho importante e gostaria de alerta é que nesses casos sempre faça um contrato se responsabilizando apenas pelo funcionamento do serviço, mas se isentando de sua legalidade ou qualquer responsabilidade perante a lei sobre a utilização dele.

[16] Comentário enviado por elgio em 22/02/2008 - 15:08h

fmpfmp: "A regra que bloqueia tem que ser pra TTL menor ou igual a 127, e não maior que 127"

E mais, a regra não deveria estar no OUTPUT mas sim no FORWARD, supondo que ela estaria no roteador do provedor.

Claro que isto mudaria se este provedor fizer nat!

Burlar é realmente muito fácil desde que:
1) o usuário use Linux como roteador
2) o usuário tenha conhecimentos avançados em Linux.

Na tabela mangle é possível configurar o TTL que se quiser em um pacote. Isto é muito útil para CEGAR ferramentas como traceroute, por exemplo (faziamos isto em uma Universidade. TTL menor que 15 = TTL igual 0. E um traceroute não enxergava além de nosso roteador principal).

Mas veja que é muito difícil usuários assinantes de provedor usando Windows terem este conhecimento.

Ainda, é uma solução arriscada pois aposta que toda a máquina LEGÍTIMA de cliente gera pacotes com TTL 128. E se um novo service Pack mudar isto para 115?

Para finalizar achei a solução muito criativa. É um problema praticamente SEM SOLUÇÃO e esta me surpreendeu pela genialidade. O fato de poder ser burlada não desmerece a criatividade da solução, afinal, quase tudo pode ser!!

Acredito que uma solução mais elegante que depende de decisões políticas é vender para o usuário uma certa largura de banda e ele faz o que quiser com ela.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts