Redes P2P > Sistemas > eMule >> Segurança em redes P2P

eMule

I - Histórico

            A idéia do projeto eMule surgiu no dia 13 de maio de 2002 quando um garoto chamado Merkur se reuniu com outros desenvolvedores para criar um aplicativo que utilizasse a rede eDonkey de maneira mais eficiente e mais agradável para o usuário. O eDonkey já era um sistema de distribuição de arquivos ponto-a-ponto popular mas que necessitava de alguns ajustes para ser um sucesso. Foi por essa necessidade que surgiu o eMule.

            O eMule é um aplicativo ponto-a-ponto (peer-to-peer) de compartilhamento de arquivos baseado no protocolo eDonkey. Ele também trabalha com a rede eDonkey2000, a qual possui cerca de 11,5 a 12,5 milhões de usuários conectados simultaneamente compartilhando cerca de 700 a 900 milhões de arquivos. É um programa de código aberto lançado sobre a GNU General Public License e roda no sistema operacional Windows possuindo uma versão para Linux denominada aMule. Além de utilizar a rede eDonkey, o eMule tem uma rede ainda experimental própria denominada Kademlia que adota uma política descentralizada - diferente da rede eDonkey.

            A rede do eMule possui centenas de servidores e milhões de clientes. Estes devem se conectar ao servidor para ter acesso à rede. Tal conexão se estabelecerá até que o cliente saia do sistema. Os servidores realizam um serviço de indexação centralizado (assim como era no Napster) e não se comunicam com outros servidores.

II – Conexão

            A conexão com a rede eMule é feita, inicialmente, com uma conexão única entre cliente-servidor. Em seguida, o cliente irá se conectar a outros servidores e a outros diversos clientes expandindo sua ligação na rede por via tanto de conexões TCP como UDP. Como explicaremos abaixo.

                II.a) Conexão Cliente-Servidor

            Ao iniciar o aplicativo eMule, o cliente tentará se conectar a diversos servidores em paralelo, mas estabelecerá a conexão TCP apenas com um. O eMule não permite que um cliente se conecte a vários servidores ao mesmo tempo ou mude de servidor dinamicamente sem a intervenção do usuário. No aperto de mãos (ou handshake) entre o cliente e o servidor, este último envia uma identificação de quatro bytes ao cliente que é denominada Client ID. Esta ID será válida enquanto durar a conexão, a qual somente será encerrada caso o cliente se desconecte daquele servidor, feche o eMule ou perca o acesso à internet.

            O cliente poderá receber uma ID alta (High ID) ou baixa (Low ID). Ele terá uma ID baixa se ele não aceitar receber conexões, o que ocorrerá caso ele esteja usando algum tipo de firewall não configurado adequadamente para o eMule, estiver conectado através de uma NAT, por um servidor proxy ou se o servidor estiver muito ocupado. Do contrário, ele receberá uma ID alta. Ter uma ID baixa significa ter um acesso restrito a rede e ser possivelmente rejeitado por servidores, que dão preferência a clientes com ID alta. Esta última, garante ao usuário total proveito da rede e será a mesma quando ele se conectar a outros servidores. A ID alta de um cliente só será alterada quando este mudar seu endereço IP, pois elas são calculadas da seguinte forma:

“Assumindo que o IP do cliente seja X.Y.Z.W , a ID alta será (X + 28)*(Y + 216)*(Z+224)*W (‘representação big endian’). A ID baixa é sempre inferior a 16777216 (0x1000000), mas não sabemos como é calculada, só é valido lembrar que a ID baixa difere entre servidores.”

[Adaptado de: Yoram Kulbak and Danny Bickson, The eMule Protocol Specification, 2005]

            Estabelecida a conexão, o cliente envia ao servidor sua lista de arquivos compartilhados. O servidor armazena essa lista na sua base de dados junto com outras milhões de informações de outros usuários também conectados. A seguir, o cliente envia sua lista de downloads, com os arquivos que ele deseja baixar. O servidor retorna uma lista de outros clientes que possuem tais arquivos – ou ao menos parte deles. O cliente também enviará frequentemente ao servidor buscas por determinados arquivos. O servidor, então, retornará os resultados encontrados, o cliente selecionará os arquivos que deseja e pedirá ao servidor a lista de fontes – outros clientes que possuem o arquivo desejado. O servidor retorna ao cliente os endereços de IP e as portas de comunicação TCP (a porta padrão é a 4662) de cada fonte de forma que usuário possa realizar uma conexão com outro cliente para realizar o download.

            O servidor também pode rejeitar um cliente pelo fato dele ter uma ID baixa ou por ter esgotado sua capacidade física.

            O cliente se conectará a outros servidores somente para obter mais fontes para um dado arquivo que deseja baixar. Tais conexões serão feitas através de protocolo UDP e não TCP.

            O UDP também será utilizado entre cliente e servidor para verificar periodicamente o status e descrição dos servidores da lista do cliente para manter o chamado Keep-Alive, sua lista de servidores atualizada. O Keep-Alive irá gerar cerca de uma dúzia de pacotes por hora. Quando o cliente requisitar o status do servidor, a resposta será o número de usuários conectados a ele e o número de arquivos listados nele. Em seguida o usuário envia um pedido de descrição ao servidor que responderá o seu nome e uma pequena string de descrição.

                II.b) Conexão Cliente-Cliente

            Com as informações vindas do servidor, o cliente irá realizar uma conexão TCP com outros clientes para realizar o download de um arquivo. Um mesmo arquivo poderá ser baixado de várias fontes simultaneamente, pois cada arquivo é dividido em partes e cada uma dessas partes é fragmentada de forma que você pode obter um fragmento de cada fonte. Dessa forma você não só aumenta a velocidade em que um arquivo é baixado como também a disponibilidade dele na rede para download, pois poder-se-á baixar o fragmento de uma fonte mesmo que ela não tenha o arquivo completo ainda – basta se ter um fragmento completo de um arquivo para que você já possa se tornar uma fonte dele e outras pessoas possam baixá-lo de você.

               Ao realizar a conexão com uma fonte para adquirir determinado arquivo, o cliente deverá entrar numa fila. Se a fila da fonte estiver vazia, o download poderá começar de imediato. Do contrário, o cliente terá que esperar até que os outros usuários na sua frente na fila realizem o download da parte desejada. Quando o cliente atinge o início da fila, a fonte inicia uma conexão para enviar o arquivo para ele. Caso ele já tenha obtido o fragmento do arquivo que a fonte está para enviar de algum outro cliente, ele apenas recusará o upload – quando o eMule obtém determinada parte do arquivo, ele não notifica as fontes conectadas.

            Se um cliente possuir uma ID baixa significa que ele não possui um endereço IP público. Dessa forma, outros clientes (fontes) não conseguem se conectar a ele diretamente e toda a comunicação deverá ser feita através do servidor. Isso aumenta o gasto computacional no servidor o que caba gerando uma relutância destes em aceitar usuários com ID baixa. Além disso, um cliente com ID baixa não poderá se conectar a outro cliente também com ID baixa de outro servidor, pois o eMule não permite esse tipo de tunelamento de requisição de arquivo entre servidores

            Para dar suporte a clientes com ID baixa, o eMule utiliza um sistema de callback (rechamada) onde uma fonte com ID alta pode pedir através do servidor que o cliente com ID baixa se conecte a ele para que possam trocar arquivos. Se um cliente A, que possui uma ID alta, deseja baixar um arquivo do cliente B, que possui uma ID baixa, estando ambos conectados a um mesmo servidor, A envia a este último um pedido de callback solicitando que B se conecte a ele. Em seguida, o servidor envia a B através da conexão TCP – já existente entre eles – o pedido de callback enviando o enderço IP e a porta de A de forma que o B possa se conectar ao cliente A e enviar o arquivo sem sobrecarregar o servidor. Apenas um cliente com ID alta pode fazer um pedido de callback ao servidor para um cliente de ID baixa. Um cliente de ID baixa não pode fazer o mesmo pedido para se conectar a outro cliente de ID baixa, pois não haverá como conectar ambos os pontos diretamente sem o intermédio do servidor.

            O eMule possui um sistema de créditos para incentivar o compartilhamento de arquivos. Quanto mais arquivos um cliente envia para outros clientes, mais créditos ele ganha e mais rápido ele irá avançar nas suas filas de espera. Para implementar esse sistema de créditos, adotou-se o conceito de identificador do usuário (User ID), que é um índex global e único (GUID - Globally Unique Identifier) de 128 bits. Esse User ID identifica o usuário mesmo através de seções pois identifica o computador em si.

            Para não permitir que alguma pessoa se passe por outra, o eMule assegura o sistema de créditos usando criptografia de chave pública RSA. Este sistema de créditos, assim como a troca de informações gerais (atualizações de listas e fontes) e melhoria de desempenho são realizados utilizando uma extensão do protocolo do eDonkey.

            O cliente usará protocolo UDP para se comunicar com outros clientes, essencialmente para obter o seu posicionamento nas filas. Ao enviar o pedido de posicionamento na fila, o cliente poderá receber três tipos de respostas vindas da fonte. Ele poderá receber um ack contendo a posição dele na fila de espera da fonte, uma mensagem de que a fila está cheia ou uma mensagem que a fonte não possui o item especificado em sua lista de arquivos.

III – Tratamento de Dados

            O eMule identifica um arquivo não pelo seu nome, obviamente, mas por um identificador de arquivo ou File ID. Esse ID serve tanto para identificar um arquivo de forma única na rede como também para detectar um eventual erro e, normalmente, é uma GUID computada através de um hash do conteúdo arquivo. Existem dois tipos de ID de arquivo: o hash do arquivo (file hash) e o hash de raiz do arquivo (root hash).

                III.a) File hash

            O File Hash é um GUID (Globally Unique Identifier) de 128 bits calculado através de um hash do conteúdo do arquivo. O eMule divide o arquivo em partes de 9,28MB e calcula o GUID de cada parte aplicando o algoritmo MD4 (gera o hash). Em seguida, os hashes são combinados em um único GUID que será o identificador do arquivo. O link do arquivo dentro da rede eD2k (eDonkey2000) contém o identificador do arquivo como é mostrado a seguir.

ed2k://|file|name|12043984|6744FC42EDA527B27F0B2F2538728B3E|/

- O arquivo descrito no link acima possui 12043984 bytes e seu identificador é 6744FC42EDA527B27F0B2F2538728B3E

            Para garantir que o hash será enviado corretamente, o link para o arquivo poderá conter o hash de cada uma das partes do arquivo, além do GUID o arquivo como mostra o exemplo abaixo:

ed2k://|file|name|12043984|6744FC42EDA527B27F0B2F2538728B3E| p=264E6F6B587985D87EB0157A2A7BAF40:17B9A4D1DCE0E4C2B672DF257145E98A|/

- O arquivo acima possui 12043984 bytes, logo possui duas partes e, consequentemente, o que denominamos hashset contém dois hashes. O identificador do arquivo continua sendo ‘6744FC42EDA527B27F0B2F2538728B3E’ e ‘p’ é o hashset, onde o hash de cada parte é mostrado separado por ‘:’. Logo, temos que o hash da primeira parte do arquivo é ‘264E6F6B587985D87EB0157A2A7BAF40’ e o da segunda parte é ‘17B9A4D1DCE0E4C2B672DF257145E98A’.

[Exemplos retirados do site http://www.emule-project.net/home/perl/help.cgi?l=1&rm=show_topic&topic_id=589]

            Ao fazer o download do arquivo, conforme cada parte é completa, calcula-se o hash dela e compara-se com o vindo do ponto de origem (do cliente fonte). Se o hash recebido e o hash calculado forem idênticos, a parte recebida do arquivo está íntegra, do contrário, está corrompida e precisa ser reenviada. Para não ter que reenviar os 9,28MB, o eMule faz com que sejam enviados blocos de 180 KB e então seja recalculado o hash no destino até que os dois hashes se igualem. No melhor caso, apenas 180 KB serão reenviados, ou 9,28 MB no pior caso. Esse sistema é chamado de Tratamento inteligente de Corrompimento (ICH - Intelligent Corruption Handling)

                III.b) Root Hash

            O Root Hash incorpora o sistema Avançado de Tratamento inteligente de Corrompimento (AICH - Advanced Intelligent Corruption Handling) do eMule. Alega-se que o ICH só é capaz de validar apenas a parte inteira dos 9,28MB da parte do arquivo e nenhum bloco menor. Clientes maliciosos podem difundir dados corrompidos na rede ou blocos inteiros falsos de arquivos que não seriam identificados pelo IHC. No AICH, cada parte do arquivo é dividida em blocos de 180 KB, gerando 53 blocos por parte. Para cada um desses blocos gera-se um hash através do algoritmo SHA1. Esses valores formarão o nível mais baixo da árvore de hashes que chamaremos de AICH Hashset. A partir destes hashes de cada bloco de 180 KB, poderá se criar um identificador para a parte do arquivo de 9,28MB que ficará a alguns níveis acima no AICH Hashset e, partindo do hash de cada parte do arquivo, poderá se criar também o Root Hash do arquivo como raiz do AICH Hashset. O link de um arquivo pode conter o Root Hash como mostrado abaixo:

ed2k://|file|name|12043984|6744FC42EDA527B27F0B2F2538728B3E| h=A2NWOTYURUU3P3GCUB6KCNW3FTYYELQB|/

- Onde o arquivo possui 12043984 bytes, seu ID é 6744FC42EDA527B27F0B2F2538728B3E e ‘h’ é o seu Root Hash. Vale lembrar que arquivos que contenham o Root Hash no link do arquivo são mais confiáveis. Caso não haja, ele obterá o Root Hash de outros clientes, só aceitando como verdadeiro se obtiver o mesmo Root Hash vindo de 10 pontos diferentes.

            Quando o eMule detecta um corrompimento em uma parte do arquivo ele pede o Pacote de Recuperação da parte corrompida para algum cliente aleatório que possua o AICH hashset completo. Esse pacote contém os hashes dos 53 blocos da parte corrompida e um número ‘x’ de hashes de verificação tal que 2^(x) é maior ou igual ao número de contagem da parte corrompida.  A ilustração que segue ajuda a compreender o funcionamento do Pacote de Recuperação da parte do arquivo.

O nó 2 pode ser obtido a partir dos 53 Hashes de Bloco (folhas verdes da árvore).Para obter o Nó amarelo do nível 2 da árvore, entretanto será preciso o hash da parte 1 (que está em verde), e para obter o root hash será preciso o nó verde (na direita) no nível 1 da árvore.

IV – Mecanismos de Busca

            Uma busca por arquivo é sempre iniciada pelo usuário e é razoavelmente simples. O cliente requisita a busca e recebe uma resposta com o resultado da busca pelo servidor. Caso o resultado seja muito grande, ele virá comprimido. Em seguida, o cliente escolhe os arquivos que deseja fazer o donwload e pede ao servidor a lista de fontes que serão enviadas a ele em seguida. O servidor pode enviar uma mensagem de status antes de enviar a lista de fontes ao cliente informando o número de usuários conectados àquele servidor e os tipos de arquivos suportados por ele. Depois de verificar que as fontes são novas, o cliente inicia uma tentativa de conexão e as adiciona em sua lista de fontes.

            O eMule usa conexões UDP para melhorar os resultados da busca. O cliente, ao realizar a busca, além de requisitar a busca no servidor em que está conectado via TCP, pode enviar requisito de busca aos outros servidores de sua lista via UDP e obter mais resultados para a busca. Após receber as respostas e selecionar os arquivos para realizar o download, o cliente também buscará nos outros servidores via UDP novas fontes para o arquivo desejado para aumentar as  possibilidades de recepção de partes do arquivo.

V - A Rede Kad

            A rede Kad é baseada no protocolo Kademlia e ainda está em fase experimental. Não há ainda muitas informações definitivas sobre ela. Sabe-se que, diferente da rede eDonkey2000 ela não utiliza servidores para autenticar nem retornar resultado de buscas ao usuário. Toda operação da rede é feita entre os nós. Ao entrar na rede, você encontra um nó inicial e, a partir dele, se conecta a outros diversos nós, inserindo-se assim, na rede, podendo obter arquivos e realizar buscas através dos nós que você está conectado. As conexões para transferência de arquivos são feitas através de TCP, mas todas as informações de busca e troca de informações entre usuários é feita utilizando protocolo UDP. O interessante é que um cliente, quando conectado a Kad rede, também está conectado à rede eDonkey2000 e utiliza uma fonte desta última como nó inicial para se interligar na rede Kad.

Redes P2P > Sistemas > eMule >> Segurança em redes P2P