BRPI0506963A2 - método, sistema e programa para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão - Google Patents

método, sistema e programa para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão Download PDF

Info

Publication number
BRPI0506963A2
BRPI0506963A2 BRPI0506963-7A BRPI0506963A BRPI0506963A2 BR PI0506963 A2 BRPI0506963 A2 BR PI0506963A2 BR PI0506963 A BRPI0506963 A BR PI0506963A BR PI0506963 A2 BRPI0506963 A2 BR PI0506963A2
Authority
BR
Brazil
Prior art keywords
relay device
potential
potential relay
determining whether
information
Prior art date
Application number
BRPI0506963-7A
Other languages
English (en)
Inventor
Saar Wilf
Shvat Shaked
Original Assignee
Npx Technologies Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Npx Technologies Ltd filed Critical Npx Technologies Ltd
Publication of BRPI0506963A2 publication Critical patent/BRPI0506963A2/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/256NAT traversal
    • H04L61/2589NAT traversal over a relay server, e.g. traversal using relay for network address translation [TURN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281Proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/563Data redirection of data network streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)

Abstract

MéTODO, SISTEMA E PROGRAMA PARA DETERMINAR SE UM POTENCIAL DISPOSITIVO DE RETRANSMISSãO E UM DISPOSITIVO DE RETRANSMISSãO. Em algumas concretizações, primeiro e segundo elementos de informação são recebidos de um potencial dispositivo de retransmissão, o qual é uma fonte original do segundo elemento de informação. A fim de determinar se o potencial dispositivo de retransmissão é um dispositivo de retransmissão é determinado se uma característica de uma fonte original do primeiro elemento de informação e uma característica do potencial dispositivo de retransmissão são características improváveis de se relacionar a um único dispositivo, onde um resultado positivo da determinação é indicativo que o potencial dispositivo de retransmissão é um dispositivo de retransmissão. Em uma concretização exemplar, um sistema revelado inclui um receptor de elemento de informação e um analisador de incompatibilidade de característica. Opcionalmente, o sistema revelado inclui um módulo de descoberta de característica, um obtenedor de parâmetro e uma database de características.

Description

MÉTODO, SISTEMA E PROGRAMA PARA DETERMINAR SE UM POTENCIAL DISPOSITIVO DE RETRANSMISSÃO É UM DISPOSITIVO DE RETRANSMISSÃO.
Setor tecnológico da invenção
A presente invenção se refere a métodos, aparatos e código legível por computador para detectar comunicações de retransmissão.
Estado da técnica conhecido
Dispositivos de retransmissão são comumente usados em muitos meios e ambientes de comunicação, e especialmente na Internet. Um dispositivo de retransmissão é um dispositivo de comunicação que recebe comunicações de um remetente e as encaminha a um destinatário.
Um dispositivo de retransmissão pode ser usado em casos onde a comunicação direta entre remetente e destinatário não é possível, ou para aumentar a performance e segurança de variadas aplicações.
Por exemplo, usuários em um ambiente seguro (por exemplo, uma rede de dados corporativos privados) podem ser proibidos de se conectar diretamente a servidores http (veja RFC 2616; para informações sobre as séries de documentos RFC veja o Editor de Website RFC em http://www.rfc-editor.orq) na Internet pública. Em tais casos, um servidor de proxy http pode ser instalado na rede segura, e será permitido a se conectar com servidores http externos. Os usuários podem então usar o proxy para retransmitir requisições de http e respostas para e de servidores http externos. Neste exemplo, o servidor de proxy http é um dispositivo de retransmissão. Em outro exemplo, usuários em uma pequena rede (por exemplo, uma rede caseira) podem usar um proxy SOCKS (veja RFC 1928) para conectar a Internet de múltiplos computadores pessoais usando uma conexão de Internet com um único endereço de IP (veja RFC 791). Neste exemplo, o proxy SOCKS é um dispositivo de retransmissão. Em outro exemplo, alguns proxys de http servem como proxys de cachê, por armazenarem cópias locais do conteúdo recebido e então servindo requisições para o mesmo conteúdo do armazenamento local. Ao fazer isso, proxys de cachê reduzem o número de requisições enviadas a servidores remoto. Em outro exemplo, proxys de http servem como proxys de filtragem de conteúdo, pela negação do acesso de usuários a materiais objetáveis.
Além desses usos normais, dispositivos de retransmissão são freqüentemente explorados para propósitos malignos.
Por exemplo, um usuário malicioso (atacante) irá usar um dispositivo de retransmissão para esconder seu endereço de IP real. Endereços de IP são freqüentemente usados para expor a identidade de um atacante pelo exame dos registros de um provedor de serviços de internet (ISP) para revelar quem usou o endereço de IP no momento do ataque. Como a parte atacada vê a comunicação como originária de um endereço de IP de dispositivo de retransmissão, o atacante permanece anônimo e tem menores chances de sofrer conseqüências (por exemplo, perder sua conta ISP ou ser preso). Esta técnica é freqüentemente usada por hackers, fraudadores e golpistas (scammers). Um atacante pode também usar diversos dispositivos de retransmissão de uma só vez pela instrução a um dispositivo de retransmissão para se conectar a outro dispositivo de retransmissão e assim por diante, e instruindo o último dispositivo de retransmissão a se conectar ao alvo. Isto protege o atacante em caso do operador do último dispositivo de retransmissão ser requisitado a fornecer o endereço de IP usado no ataque.
Em outro exemplo, um atacante irá usar um grande número de dispositivos de retransmissão para criar a ilusão que comunicações estão originando de vários usuários diferentes. Atacantes usam esta técnica para evitar sistemas anti-abuso que bloqueiam endereços de IP baseado na taxa de ações potencialmente abusivas exercidas por eles (por exemplo, número de ações feitas em um período de tempo). Por exemplo, muitos serviços online que utilizam senhas para autenticar seus usuários irão bloquear um endereço de IP após algumas tentativas falhas de login, com o objetivo de prevenir ataques de força bruta. Em ataques de força bruta, um atacante tenta reaver uma senha através da tentativa de várias senhas diferentes até obter um sucesso no login. Em outro exemplo, muitos serviços online que fornecem acesso a um diretório de informações pessoais irão bloquear um endereço de IP se a taxa de requisições enviadas por ele exceder um certo limite, com o objetivo de prevenir que os atacantes recolham grandes quantidades de informações pessoais, que podem ser usadas para outras ações abusivas como o envio de spams (mensagens eletrônicas não solicitadas). Em outro exemplo, sistemas anti-spams irão bloquear endereços de IP que enviam um alto volume de mensagens. Em outro exemplo, como os websites podem ser pagos por cada vez que um usuário verificar um anúncio online (ou clicar nele), empresas de anúncio online irão ignorar grande número de verificações do anúncio (ou clique nos anúncios) que originarem de um mesmo endereço de IP, para prevenir que golpistas (scammers) façam uma falsa verificação (ou cliques) dos anúncios.
Pelo uso de múltiplos dispositivos de retransmissão, scammers evitam estas defesas.
Em outro exemplo, um atacante irá usar um dispositivo de retransmissão para criar a ilusão de que ele está em uma localização geográfica diferente. Como muitas tentativas de fraudes de cartão de crédito online são originárias de fora dos Estados Unidos da América, muitos comerciantes americanos online não irão aceitar cartões de crédito estrangeiros ou remessas de produtos para fora do país. Fraudadores podem superar estas barreiras pelo uso de cartões de crédito americanos e remessas a cúmplices nos Estados Unidos. Comerciantes responderam rejeitando pedidos nos quais a localização geográfica do endereço de IP (como reportado por serviços de localização geográfica de IP como o GeoPoint oferecido por Quova, Inc. de Mountain View, Califórnia, EUA; Veja Patentes Americanas 6,684,250 e 6,757,740) não combinar com o endereço ou endereços fornecidos no pedido (por exemplo, o endereço de cobrança do cartão de crédito é nos EUA, enquanto o endereço de IP é na Indonésia). Fraudadores superam esta barreira através do uso de dispositivos de retransmissão em localizações aceitáveis.
Enquanto dispositivos de retransmissão propriamente configurados usualmente implementam mecanismos de controle de acesso para permitir o acesso apenas a usuários autorizados, muitos dispositivos de retransmissão são globalmente acessíveis (conhecidos como 'proxys abertos') e são abusados pelos atacantes. Em alguns casos, proxys abertos existem porque eles são enviados como parte de um dispositivo de hardware ou software e foram instalados sem conhecimento por seus proprietários, ou porque administradores configuraram erroneamente ou descuidadamente os dispositivos de retransmissão para retransmitir comunicações de fontes não autorizadas. Em outros casos, o proxy aberto é instalado maliciosamente sem a permissão do proprietário do computador, como pelo envio de um 'cavalo de tróia' para o proprietário do computador, por um vírus de computador, ou pela invasão manual do computador (invasão é o ato de explorar um mal funcionamento ou má configuração para ganhar o controle sobre o computador).
Como os dispositivos de retransmissão, em especial os dispositivos de retransmissão globalmente acessíveis são freqüentemente usados para propósitos malignos, muitos provedores e comerciantes de serviços online tratam qualquer comunicação recebida através de um dispositivo de retransmissão como maligna. Por exemplo, muitos servidores SMTP (veja RFC 821) não irão aceitar e-mails recebidos através de dispositivos de retransmissão, muitos servidores IRC (veja RFC 2810) não irão aceitar usuários conectados através de dispositivos de retransmissão, e alguns comerciantes de da Internet não irão aceitar pedidos recebidos através de dispositivos de retransmissão.
Os métodos atuais para determinar se uma comunicação está sendo retransmitida através de um dispositivo de retransmissão são baseados em examinar se comunicações do endereço de IP de origem da comunicação são tipicamente de um dispositivo de retransmissão (supondo que o dispositivo de retransmissão reporta seu próprio endereço de IP de origem na comunicação transmitida).
Um método semelhante é examinar se uma comunicação http contém encabeçamentos http originais aos dispositivos de retransmissão. Exemplos de tais encabeçamentos incluem 'X- Forwarded-For', 'X-Originating-IP', 'Via', 'X-Cache' e 'CIiente-IP'. Este método é limitado por não poder ser usado quando o protocolo transmitido não é http. Ele é adicionalmente limitado pelo fato de nem todos dispositivos de retransmissão reportarem tais encabeçamentos, especialmente se a transmissão é realizada em um nível abaixo de http, como no caso com proxys SOCKS ou quando é usado o método http CONNECT (veja RFC 2817).
Outro método é a tentativa de conectar de volta ao endereço de IP de origem (criar uma 'conexão inversa') usando um protocolo concordado, o qual não é provável de ser implementado por dispositivos de retransmissão. Por exemplo, muitos servidores IRC irão tentar se conectar de volta ao endereço de IP de origem usando o Protocolo de Identificação (veja RFC 1413), o qual a maioria dos clientes IRC implementa. Como os dispositivos de retransmissão não são prováveis de implementar o Protocolo de Identificação, receber uma indicação do endereço de IP de origem de que a tentativa de conexão foi bem-sucedida (por exemplo, um segmento de TCP contendo os indicadores de controle SYN e ACK; para uma explicação sobre o TCP, veja RFC 793) indicaria que a comunicação é mais provável de não estar sendo retransmitida. Este método é limitado no fato de os provedores de serviço e usuários precisarem concordar em um protocolo que poderia ser usado para conexões inversas, nisto os provedores de serviço precisam originar uma conexão com todos os usuários usando um protocolo concordado, e nisto todos os usuários precisam operar um servidor para aceitar tais conexões.
Outro método envolve criar uma conexão inversa para o endereço de IP de origem usando protocolos e números de portas comumente usadas para dispositivos de retransmissão (por exemplo, SOCKS em porta TCP 1080 ou http em porta TCP 8080) e então tentar retransmitir uma comunicação. Como a maioria dos usuários não operam retransmissões de comunicações globalmente acessíveis, uma tentativa bem-sucedida indicaria que o usuário está mais provavelmente usando um dispositivo de retransmissão. Este método é limitado por os provedores de serviço terem que originar conexões inversas a todos usuários, e por uma multidão de conexões inversas serem requeridas para cobrir uma porção significante das configurações de dispositivos de retransmissão possíveis. Este método é adicionalmente limitado pelo fato de que criar múltiplas conexões inversas é uma operação consumidora de recursos, e pode ser considerada antiética, abusiva ou, de outra forma, problemática.
Em um esforço para suavizar as limitações dos métodos atuais, provedores de serviços online cooperam entre si pelo compartilhamento de informações sobre dispositivos de retransmissão. Por exemplo, provedores de serviços freqüentemente questionam bancos de dados (conhecidas como 'listas negras') que listam vários parâmetros de comunicação de retransmissões de comunicações globalmente acessíveis, como descoberto por outros provedores de serviços ou pelos operadores do banco de dados, por exemplo para checar se um dado endereço de IP de origem está listado. Um banco de dados semelhante é o MAPS Open Proxy Stopper mantido por Mail Abuse Prevention System LLC de San Jose, Califórnia, EUA. Estes bancos de dados são tão limitados quanto os métodos usados para populá-los, e são ainda limitados por não estarem sempre atualizados.
Existe uma necessidade evidente de um método efetivo para determinar se uma comunicação está sendo retransmitida por um dispositivo de retransmissão.
Novidade e objetivos da invenção
É apresentado neste momento, pela primeira vez, um método para determinar se elementos de informação recebidos de um potencial dispositivo de retransmissão foram transmitidos através de um dispositivo de retransmissão. O método apresentado para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão inclui receber primeiro e segundo elementos de informação de um potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do segundo elemento de informação.
Em algumas concretizações, o método apresentado ainda inclui determinar se uma característica de uma fonte original do primeiro elemento de informação e uma característica do potencial dispositivo de retransmissão são características improváveis de se relacionar a um único dispositivo. Em algumas concretizações, o método apresentado ainda inclui determinar se uma característica de uma fonte original do primeiro elemento de informação e uma característica do potencial dispositivo de retransmissão são características improváveis de descrever a um único dispositivo.
Aqui são apresentadas diversas características de transmissores e fontes originais de elementos de informação que são surpreendentemente úteis para determinar se um elemento de informação recebido foi retransmitido. Características de transmissores e fontes originais de elementos de informação que são úteis para determinar se um elemento de informação recebido foi retransmitido incluem, mas não se limitam, a um status de configuração de um dispositivo, performance de comunicações de um dispositivo, uma característica de uma requisição de DNS relacionada, e um parâmetro de latência tal como o tempo de circulação para um transmissor e/ou fonte original de elementos de informação.
De acordo com algumas concretizações, o segundo elemento de informação é de um tipo que um dispositivo de retransmissão de uma classe de dispositivos de retransmissão é improvável de transmitir.
De acordo com algumas concretizações, o primeiro elemento de informação é de um tipo que um dispositivo de retransmissão de uma classe de dispositivos de retransmissão é provável de transmitir.
Classes exemplares de dispositivos de retransmissão relevantes às concretizações da presente invenção incluem, mas não se limitam a, proxys SOCKS, proxys http incluindo proxys http com uso do método GET e/ou método CONNECT, IP routers e dispositivos de Tradução de Endereços de Rede. De acordo com algumas concretizações, o primeiro elemento de informação e/ou segundo elemento de informação são parte de uma comunicação de um tipo selecionado do grupo consistindo em IP, TCP, ICMP, DNS1 http, SMTP, TLS, e SSL. De acordo com algumas concretizações, o primeiro e segundo elementos de informação são parte de uma única comunicação.
De acordo com algumas concretizações, o primeiro e segundo elementos de informação são enviados em duas camadas diferentes de um protocolo stack.
De acordo com algumas concretizações, o estágio de determinação inclui descobrir a característica de uma fonte original do primeiro elemento de informação e, descobrir a característica do potencial dispositivo de retransmissão.
De acordo com algumas concretizações, o estágio de determinação ainda inclui comparar a característica de uma fonte original do primeiro elemento de informação com a característica do potencial dispositivo de retransmissão.
Deste modo, em um exemplo ilustrativo, um parâmetro de status de configuração tal como um sistema de operação é determinado por ambas fonte original do primeiro elemento de informação, e potencial dispositivo de retransmissão. Se for descoberto uma discrepância entre os parâmetros de status de configuração entre o pacote da fonte original do primeiro elemento de informação e o potencial dispositivo de retransmissão, é improvável indicar um único dispositivo, e é desta forma deduzido que o potencial dispositivo de retransmissão não é o mesmo dispositivo que o dispositivo da fonte original, mas preferencialmente um dispositivo de retransmissão separado.
Em algumas concretizações, o método compreende obter um parâmetro indicativo da característica da fonte original do primeiro elemento de informação, e obter um parâmetro indicativo da característica do potencial dispositivo de retransmissão.
Deste modo, é notável que não há necessidade de explicitamente obter conhecimento das características da fonte do primeiro elemento de informação e da fonte do potencial dispositivo de retransmissão. Em um exemplo específico, uma latência diferencial entre o potencial dispositivo de retransmissão e a fonte do primeiro elemento de informação é obtida, sem necessariamente obter as latências individuais.
Em algumas concretizações, o método inclui obter um parâmetro indicativo de uma relação entre a característica da fonte original do primeiro elemento de informação e a característica do potencial dispositivo de retransmissão.
Em algumas concretizações, o estágio de determinação ainda inclui analisar o parâmetro indicativo de uma relação entre a característica da fonte original do primeiro elemento de informação e a característica do potencial dispositivo de retransmissão.
Em algumas concretizações, o parâmetro é obtido de ao menos um do primeiro elemento de informação e segundo elemento de informação.
De acordo com algumas concretizações, o método ainda compreende enviar uma comunicação de saída para ao menos um entre a fonte original do primeiro elemento de informação e o potencial dispositivo de retransmissão, e receber um terceiro elemento de informação de ao menos um entre a fonte original do primeiro elemento de informação e o potencial dispositivo de retransmissão.
De acordo com algumas concretizações, o método ainda inclui derivar do terceiro elemento de informação relacionado a uma característica de ao menos um entre a fonte original do primeiro elemento de informação e o potencial dispositivo de retransmissão.
De acordo com algumas concretizações, o método ainda inclui verificar que uma fonte original do terceiro elemento de informação é a fonte original do primeiro elemento de informação.
De acordo com algumas concretizações, o método ainda inclui verificar que uma fonte original do terceiro elemento de informação é o potencial dispositivo de retransmissão.
Em uma concretização exemplar, após receber primeiro e segundo elementos de informação que podem ter sido retransmitidos, uma resposta http e um ping são retornados a fonte de comunicação pretendida. Não respectivo à presença de um dispositivo de retransmissão intermediário, a resposta http é retransmitida pelo dispositivo de retransmissão para a fonte original das comunicações, a qual por sua vez, retorna um terceiro elemento de informação. Em contraste, o dispositivo de retransmissão responde ao ping sem encaminhar o ping à fonte original do primeiro elemento de informação. Deste modo, amplo diferencial em latências é indicativo da presença de um dispositivo de retransmissão.
De acordo com algumas concretizações, o método ainda inclui receber um terceiro elemento de informação do potencial dispositivo de retransmissão, e derivar informação relacionada a uma característica do potencial dispositivo de retransmissão do terceiro elemento de informação.
De acordo com algumas concretizações, o método ainda inclui receber um terceiro elemento de informação da fonte do primeiro elemento de informação, e derivar informação relacionada a uma característica da fonte do primeiro elemento de informação do terceiro elemento de informação.
De acordo com algumas concretizações, ao menos uma entre a característica da fonte da primeira comunicação e a característica do potencial dispositivo de retransmissão é uma característica relacionada a um status de configuração.
Características exemplares relacionadas a um status de configuração incluem, mas não se limitam a, um tipo de sistema de operação, uma versão de sistema de operação, um tipo de software, um tipo de cliente http, um tipo de servidor http, tipo de cliente SMTP, um tipo de servidor SMTP, um time setting, um clock setting e um time zone setting.
De acordo com algumas concretizações, o estágio de determinação inclui examinar o parâmetro indicativo da característica relacionada a um status de configuração.
Parâmetros indicativos exemplares da característica relacionada a um status de configuração incluem, mas não se limitam a, um http 'User-Agent' header, um RFC 822 'X-Mailer' header, um RFC 822 'Received' header, um RFC 822 'date' header, um protocol implementation manner, um TCP/IP stack fingerprint, um endereço de IP1 uma porta TCP, uma seqüência numérica inicial TCP, uma janela inicial de TCP, um WHOIS Record, um reverse DNS Record1 e uma taxa de informação conhecida.
De acordo com algumas concretizações, ao menos uma entre a característica da fonte da primeira comunicação e a característica do potencial dispositivo de retransmissão é uma característica relacionada à performance de comunicação.
De acordo com algumas concretizações, a característica relacionada à performance de comunicação é selecionada do grupo consistindo em uma performance de comunicação medida, uma relativa performance de comunicação medida e uma performance de comunicação estimada.
De acordo com algumas concretizações, a característica relacionada à performance de comunicação é selecionada do grupo consistindo em uma latência de comunicação, latência de uma comunicação de entrada, uma latência de uma comunicação de saída, uma taxa de comunicação, uma taxa de comunicação de entrada, uma taxa de comunicação de saída, uma taxa máxima de comunicação de entrada e uma taxa máxima de comunicação de saída.
De acordo com algumas concretizações, o estágio de determinação inclui examinar o parâmetro indicativo da característica relacionada à performance de comunicação.
De acordo com algumas concretizações, o parâmetro é selecionado de um grupo consistindo de tempo de recebimento de um elemento de informação, tempo de envio de um elemento de informação, tempo de envio e recebimento, espaço de tempo de envio e recebimento, um endereço de IP1 um Whois Record1 um reverse DNS Record, e uma taxa de informação conhecida.
De acordo com algumas concretizações, um espaço maior de tempo de envio e recebimento é indicativo de uma grande probabilidade de que um dispositivo de retransmissão está sendo usado para propósitos maliciosos.
De acordo com algumas concretizações, ao menos uma entre a característica da fonte do primeiro elemento de informação e a característica do potencial dispositivo de retransmissão é selecionada do grupo consistindo em uma sub-rede, um administrador de rede, e uma localização geográfica.
De acordo com algumas concretizações, a determinação inclui examinar um parâmetro indicativo de ao menos uma entre a característica de uma fonte da primeira comunicação e a característica de uma fonte da segunda comunicação, e o parâmetro é selecionado do grupo consistindo de um http "User-Agent" header, um RFC 822 'X-Mailer' header, um RFC 822 'Received' header, um RFC 822 'date' header, um endereço de IP, um Whois Record e um reverse DNS Record.
É apresentado neste momento, pela primeira vez, um método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão. O método apresentado compreende receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do segundo elemento de informação, e analisar um status de configuração de uma fonte original de ao menos um entre o primeiro e segundo elementos de informação, em que o status de configuração é selecionado do grupo consistindo de um tipo de sistema de operação, uma versão de sistema de operação, um tipo de software, um tipo de cliente http, um tipo de servidor http, tipo de cliente SMTP, um tipo de servidor SMTP, um time setting, um clock setting e um time zone setting.
É apresentado neste momento, pela primeira vez, um método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão. O método apresentado compreende receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do segundo elemento de informação, e analisar uma característica relacionada á performance de comunicação de uma fonte original de ao menos um entre o primeiro e segundo elementos de informação.
De acordo com algumas concretizações, a característica relacionada à performance de comunicação é selecionada do grupo consistindo em uma latência de comunicação, latência de uma comunicação de entrada, uma latência de uma comunicação de saída, um tempo de circulação da comunicação, uma taxa de comunicação, uma taxa de comunicação de entrada, uma taxa de comunicação de saída, uma taxa máxima de comunicação de entrada e uma taxa máxima de comunicação de saída.
É apresentado neste momento, pela primeira vez, um método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão. O método apresentado compreende enviar uma mensagem ao potencial dispositivo de retransmissão induzindo um recipiente final da mensagem a enviar uma requisição de DNS de saída, e determinando a partir da requisição de DNS de saída se o potencial dispositivo de retransmissão é um dispositivo de retransmissão.
É apresentado neste momento, pela primeira vez, um método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão. O método apresentado compreende receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do segundo elemento de informação; e checar se o tempo de envio e recebimento para o potencial dispositivo de retransmissão é significantemente diferente que o tempo de envio e recebimento para uma fonte original do primeiro elemento de informação.
É apresentado neste momento, pela primeira vez, um método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão. O método apresentado compreende receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do segundo elemento de informação; e checar se um sistema de operação do potencial dispositivo de retransmissão é diferente de um sistema de operação de uma fonte original do primeiro elemento de informação.
É apresentado neste momento, pela primeira vez, um método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão. O método apresentado compreende receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do segundo elemento de informação; e checar se uma localização do potencial dispositivo de retransmissão é diferente de uma localização de uma fonte original do primeiro elemento de informação.
É apresentado neste momento, pela primeira vez, um método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão. O método apresentado compreende receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do segundo elemento de informação; e checar se um administrador do potencial dispositivo de retransmissão é diferente de um administrador de uma fonte original do primeiro elemento de informação.
É apresentado neste momento, pela primeira vez, um método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão. O método apresentado compreende determinar se uma característica de uma fonte original do primeiro elemento de informação e uma característica do potencial dispositivo de retransmissão são características improváveis para relacionar a um único dispositivo, em que o potencial dispositivo de retransmissão é um transmissor do primeiro elemento de informação e do segundo elemento de informação, em que o potencial dispositivo de retransmissão é uma fonte original do segundo elemento de informação, e em que um resultado positivo da determinação é indicativo de que o potencial dispositivo de retransmissão é um dispositivo de retransmissão. É apresentado neste momento, pela primeira vez, um método para determinar se uma informação recebida foi retransmitida por um dispositivo de retransmissão. O método apresentado compreende determinar a partir do elemento de informação recebido uma medição performance de comunicação, e gerar a partir dos resultados da determinação, indicativo de saída para se a informação recebida foi retransmitida por um dispositivo de retransmissão.
É apresentado neste momento, pela primeira vez, um método para determinar se uma informação recebida foi retransmitida por um dispositivo de retransmissão. O método apresentado compreende determinar a partir do elemento de informação recebido um parâmetro indicativo de performance de comunicação, e gerar a partir dos resultados da determinação, indicativo de saída para se a informação recebida foi retransmitida por um dispositivo de retransmissão.
Medições determinadas de performance de comunicações exemplares incluem, mas não se limitam a, uma latência de comunicação com um host monitorado, latência de uma comunicação de entrada com um host monitorado, uma latência de uma comunicação de saída com um host monitorado, uma taxa de comunicação, uma taxa de comunicação de entrada, uma taxa de comunicação de saída, uma taxa máxima de comunicação de entrada e uma taxa máxima de comunicação de saída.
É apresentado neste momento, pela primeira vez, um sistema para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão. De acordo com algumas concretizações, o sistema apresentado inclui um receptor de elemento de informação, para receber elementos de informação de uma pluralidade de dispositivos incluindo um dispositivo de fonte de informações e o potencial dispositivo de retransmissão, e um analisador de incompatibilidade de características, para determinar se uma característica do dispositivo de fonte de informações e uma característica do potencial dispositivo de retransmissão são características improváveis de relacionar a um único dispositivo.
De acordo com algumas concretizações, o sistema ainda inclui um módulo de descoberta de características, para descobrir ao menos uma característica selecionada do grupo consistindo de uma característica do dispositivo de fonte de informações e uma característica do potencial dispositivo de retransmissão.
Opcionalmente, o receptor de elemento de informação é ainda configurado para receber elementos de informação de um host monitorado.
Opcionalmente, o sistema inclui um remetente de elemento de informação de saída.
De acordo com algumas concretizações, o sistema ainda inclui um obtenedor de parâmetros, para obter ao menos um parâmetro selecionado do grupo consistindo de um parâmetro indicativo de uma característica de um dispositivo de fonte de informação, um parâmetro indicativo de uma característica do potencial dispositivo de retransmissão, e um parâmetro indicativo de se uma característica do dispositivo de fonte de informação e uma característica do potencial dispositivo de retransmissão são características improváveis de relacionar a um único dispositivo.
De acordo com algumas concretizações, o sistema ainda inclui um banco de dados de características para armazenar um mapa entre pares de características e dados indicativos de se os pares de características são características incompatíveis.
Estas e adicionais concretizações ficarão evidentes a partir da descrição detalhada e exemplos que seguem.
Descrição dos desenhos anexos
Com o objetivo de entender a invenção e verificar como ela deve ser conduzida na prática, uma concretização preferencial será agora descrita, apenas como um exemplo não limitante, com referência aos desenhos acompanhantes, nos quais:
Fig. 1 fornece uma ilustração de um ambiente no qual um Sistema de Detecção de Retransmissão opera de acordo com algumas concretizações da presente invenção.
Fig. 2A fornece um diagrama de um Potencial Dispositivo de Retransmissão enviando Elementos de Informação a um Sistema de Detecção de Retransmissão.
Fig. 2B fornece um diagrama das fontes originais dos elementos de informação recebidos por um Sistema de Detecção de Retransmissão de acordo com algumas concretizações da presente invenção.
Fig. 2C fornece um diagrama do caso em que o Potencial Dispositivo de Retransmissão é um Dispositivo de Fonte de Informação.
Fig. 2D fornece um diagrama do caso em que o Potencial Dispositivo de Retransmissão e o Dispositivo de Fonte de Informação são dispositivos distintos.
Fig. 3 fornece uma descrição de um sistema de acordo com diversas concretizações da presente invenção. Fig. 4Α descreve as latências de comunicações entre o Dispositivo de Fonte de Informação e o Host Monitorado no caso em que o Dispositivo de Retransmissão esteja sendo usado.
Fig. 4B descreve as latências de comunicações entre o Dispositivo de Fonte de Informação e o Host Monitorado no caso em que o Dispositivo de Retransmissão não esteja sendo usado.
Fig. 5A fornece um diagrama do caso no qual o Dispositivo de Fonte de Informação envia dois elementos de informação, Elemento de Informação Potencialmente Retransmitido 1 e Elemento de Informação Potencialmente Retransmitido 2, diretamente ao Host Monitorado, sem usar o Dispositivo de Retransmissão.
Fig. 5B fornece um diagrama do caso no qual dois dispositivos diferentes, Dispositivo de Fonte de Informação e Dispositivo de Fonte de Informação 2, enviam um elemento de informação cada para um Host Monitorado, em que ambos elementos de informação são retransmitidos por um Dispositivo de Retransmissão.
Descrição detalhada da invenção
Antes de determinar a invenção, pode ser útil para um entendimento da mesma, primeiro determinar definições de certos termos que serão usados daqui por diante.
Como usado na presente invenção, o termo "comunicação" se refere à transferência de ao menos um elemento de informação entre dois dispositivos. Por exemplo, um pacote de IP transferido pela Internet de um dispositivo para outro dispositivo é uma comunicação. Em outro exemplo, uma requisição de http transferida de um cliente http para um servidor http pela Internet é uma comunicação. Deveria ser notado que uma ou mais comunicações podem ser transferidas em uma ou mais comunicações. Um grupo de comunicações no qual uma comunicação contem a outra é chamado "Protocolo Stack". Por exemplo, uma comunicação no protocolo http (por exemplo, uma requisição ou resposta de http) é normalmente contida em uma comunicação no protocolo TCP (por exemplo, uma conexão TCP), a qual por sua vez é contida em uma comunicação no protocolo IP (por exemplo, um ou mais datagramas IP).
Como usado na presente invenção, o termo "fonte original de um elemento de informação" se refere ao dispositivo que enviou tal elemento de informação, mas não retransmitira tal elemento de informação de outro dispositivo.
Como usado na presente invenção, o termo "transmissor" se refere a um dispositivo que enviou um elemento de informação, incluindo nos casos onde o elemento de informação foi previamente retransmitido de outro dispositivo. Quando um elemento de informação é recebido de um dispositivo, tal dispositivo é um transmissor de tal elemento de informação.
Como usado na presente invenção, o termo "característica" se refere a qualquer informação sobre um dispositivo que pode ser diferente entre dois dispositivos diferentes.
Concretizações da presente invenção relatam o recebimento e/ou o envio de "elementos de informação" através de uma rede de dados. Em algumas concretizações, elementos de informação são comunicados usando um protocolo de comunicação. Protocolos de comunicação exemplares para elementos de informação comunicados através de uma rede de dados incluem, mas não se limitam a, http, SMTP, DNS (veja RFC 1034), SSL/TLS (veja RFC 2246), TCP, UDP (veja RFC 768), IP, e ICMP (veja RFC 792).
A Fig. 1 fornece uma ilustração de um ambiente no qual um Sistema de Detecção de Retransmissão 102 opera de acordo com algumas concretizações da presente invenção. Em algumas concretizações, Sistema de Detecção de Retransmissão 102 (SDR) recebe elementos de informação comunicados de um Dispositivo de Fonte de Informação 104 (DFI) através da Internet 100.
Em alguns casos, com o objetivo de enviar elementos de informação a um Host Monitorado 110 (HM), um DFI 104 primeiro envia elementos de informação a um Dispositivo de Retransmissão 108 (DR), o qual recebe os elementos de informação e subseqüentemente retransmite os elementos de informação recebidos para o HM 110. Para estes casos, os elementos de informação retransmitidos viajam do Dispositivo de Fonte de Informação 104 ao Host Monitorado como indicado pelo caminho 122.
Alternativamente, o DFI 104 não utiliza o Dispositivo de Retransmissão 108, e envia os elementos de informação ao Host Monitorado 110 sem passar pelo DR 108, como indicado no caminho 120.
É desejado apurar se os elementos de informação enviados para o HM 110 foram enviados através de um DR 108.
Os presentes inventores projetaram métodos, aparatos e software legível por computador para determinar se elementos de informação enviados para o HM 110 foram enviados através de um DR 108. Em algumas concretizações, a determinação é realizada por SDR 102, o qual monitora ao menos uma comunicação recebida pelo HM 110 e tenta determinar se a comunicação é enviada para o HM 110 usando um DR 108. Como usado na presente invenção, o termo "monitorar" se refere ao ato de receber comunicações, incluindo em casos onde as comunicações foram enviadas de ou para o dispositivo que está realizando o monitoramento.
Qualquer classe de dispositivo de retransmissão é apropriada para a presente invenção. Exemplos de classes de dispositivos de retransmissão incluem, mas não se limitam a, Proxys SOCKS (veja RFC 1928), Proxys http usados com o método GET (veja RFC 2616), Proxys http usados com o método CONNECT (veja RFC 2817), IP routers (veja RFC 1812), e dispositivos NAT (veja RFC 2663).
DFI 104 é um dispositivo configurado para comunicar com outros dispositivos através de qualquer rede de dados, tal como a Internet 100. Em algumas concretizações, DFI 104 é um dispositivo operado por uma pessoa ou grupo de pessoas. Em algumas concretizações, DFI 104 é um dispositivo operando automaticamente. Em algumas concretizações, DFI 104 é um dispositivo operando automaticamente de uma forma que simula as ações de uma pessoa. DFIs exemplares incluem, mas não se limitam a, um computador rodando um browser HTML tal como o Microsoft Internet Explorer (para uma explicação sobre HTML veja a Especificação de HTML no website W3C em http://www.w3.org/TR/html), um computador rodando um cliente IRC, um computador rodando um cliente SMTP, e um telefone celular rodando um browser XHTML. HM 110 é um dispositivo configurado para comunicar com outros dispositivos através de qualquer rede de dados, tal como a Internet 100. Em uma concretização exemplar, Host Monitorado 110 é um servidor. Exemplos de Hosts Monitorados 110 apropriados incluem, mas não se limitam a, um servidor http, um servidor SSL/TLS, um servidor SMTP, um servidor de arquivo, um servidor telnet, um servidor FTP, um servidor SSH, um servidor DNS, e um servidor IRC. Exemplos de usos do HM 110 incluem, mas não se limitam a, hospedar um comerciante online, rodar um serviço de anúncio online, e receber e-mail.
Em algumas concretizações, SDR 102 monitora elementos de informação enviados de e/ou para o HM 110. Opcionalmente, SDR 102 é ainda configurado para comunicar com o DR 108 e/ou o DFI 104. Opcionalmente, SDR 102 é ainda configurado para monitorar elementos de informação enviados de e/ou para o SDR 102.
Cada um dos SDR 102, DFI 104, DR 108, e HM 110 podem ser hardware, software ou uma combinação destes, podem residir na mesma ou em diferente localização geográfica, ou podem ser componentes do mesmo dispositivo.
Por motivo de simplificação, o ambiente apresentado contém um dispositivo de fonte de informação, e um dispositivo de retransmissão. Na prática, existem muitos dispositivos de fonte de informação conectados à Internet 100, e cada um deles pode ou não usar um de diversos dispositivos de retransmissão que também estão conectados à Internet 100. O objetivo da presente invenção é diferenciar entre o caso geral de um dispositivo de fonte de informação que não usa um dispositivo de retransmissão e o caso geral de um dispositivo de fonte de informação que usa um dispositivo de retransmissão. Será apreciado que a extrapolação do ambiente apresentado para ambientes da vida real como a Internet ou outras redes está bem dentro do campo de um técnico hábil.
Em referência à Fig. 2A, é notado que, de acordo com algumas concretizações da presente invenção, o SDR 102 recebe elementos de informação enviados ao HM 110, em que um Potencial Dispositivo de Retransmissão 150 (PDR) é um transmissor dos elementos de informação, mas não é necessariamente a fonte original de cada ou qualquer elemento de informação. De acordo com algumas concretizações, identidade do Potencial Dispositivo de Retransmissão 150 (PDR) é desconhecida e pode ser tanto o DR 108, ou o DFI 104.
Algumas concretizações da presente invenção fornecem métodos, aparatos e software legível por computador para determinar se o PDR 150 é um DR 108 ou DFI 104.
A Fig. 2B fornece um diagrama das fontes originais dos elementos de informação recebidos por um SDR 102 de acordo com algumas concretizações da presente invenção. Um primeiro elemento de informação e um segundo elemento de informação são recebidos pelo SDR 102. De acordo com algumas concretizações, PDR 150 é a fonte original do segundo elemento de informação, e desta forma o segundo elemento de informação pode ser referido também como um Elemento de Informação Não-Retransmitido (EINR). Em contraste, DFI 104 é a fonte original do primeiro elemento de informação, e desta forma o primeiro elemento de informação pode ser referido também como um Elemento de Informação Potencialmente Retransmitido (EIPR). Portanto, no caso onde PDR 150 é um DFI 104, então PDR 150 é a fonte original do EIPR1 e no caso onde PDR 150 é um DR 108, então PDR 150 não é a fonte original do EIPR.
Em concretizações particulares, o EINR é de um tipo não retransmitido por uma classe específica de dispositivos de retransmissão, desta forma garantindo que o segundo elemento de informação realmente não é retransmitido por um dispositivo de retransmissão de tal classe. Por exemplo, um Proxy http standard (tanto usando o método GET ou CONNECT) não retransmite mensagens ICMP. Portanto, se o DR 108 é um proxy de um tipo e o DR 108 é um transmissor de uma mensagem ICMP, então a mensagem ICMP pode ser deduzida como um EINR.
De acordo com algumas concretizações da presente invenção, é determinado se uma característica do DFI 104 e uma característica do PDR 150 são características improváveis de se relacionar ao mesmo dispositivo (Características Incompatíveis). Uma característica é tida como relacionada a um dispositivo se a característica for informação sobre aquele dispositivo específico.
Em algumas concretizações, a característica do DFI 104 é derivada do conteúdo do EIPR. Em concretizações alternativas, a característica do DFI 104 é derivada de outras características descritas abaixo. Em algumas concretizações, a característica do PDR 150 é derivada do conteúdo do EINR. Em concretizações alternativas, a característica do PDR 150 é derivada de outras características descritas abaixo.
É ainda notado que não é um requerimento da presente invenção obter de fato tanto uma característica do PDR 150 quanto uma característica do DFI 104. Em algumas concretizações detalhadas abaixo, o SDR 102 pode determinar se as características são ou não Características Incompatíveis, sem descobrir cada ou qualquer característica. A presença de Características Incompatíveis aumenta a probabilidade de que o DFI 104 e o PDR 150 são dispositivos distintos (por exemplo, PDR 150 é DR 108), enquanto a ausência de Características Incompatíveis aumenta a probabilidade de que o PDR 150 e o DFI 104 são o mesmo dispositivo (por exemplo, PDR 150 não é DR 108).
A Fig. 2C fornece um diagrama do caso em que o PDR 150 é o DFI 104. Neste caso, é detectado que a fonte original do primeiro elemento de informação (DFI 104) é o mesmo dispositivo que a fonte original do segundo elemento de informação (PDR 150), e pode desse modo ser concluído que o Potencial Dispositivo de Retransmissão 150 é o Dispositivo de Fonte de Informação 104 e não um Dispositivo de Retransmissão 108, e pode também ser concluído que o EIPR não foi retransmitido pelo Dispositivo de Retransmissão 108.
A Fig. 2D fornece um diagrama de um caso alternativo em que o PDR 150 e o DFI 104 são dispositivos distintos. Neste caso, é detectado que a fonte original do primeiro elemento de informação (DFI 104) é um dispositivo diferente da fonte original do segundo elemento de informação (PDR 150). Desta forma, como o EIPR tem uma fonte original que não é o PDR 150, é concluído que o EIPR foi retransmitido pelo PDR 150, e que portanto o PDR 150 é um Dispositivo de Retransmissão 108.
Como usado na presente invenção, o termo "característica" se refere à ao menos uma característica. Desta forma, é exposto que uma combinação de mais de uma característica é definido como uma característica em si.
Como usado na presente invenção, uma "característica do DFI" é uma característica da fonte original do primeiro elemento de informação (por exemplo, a fonte do EIPR, a qual é o DFI 104), enquanto uma "característica do PDR" é uma característica da fonte do segundo elemento de informação (por exemplo, a fonte do EINR, a qual é o PDR 150). Exemplos de Características do DFI, Características do PDR, métodos para descobrir tais características, e o modo que tais características podem ser usadas para determinar se o DFI 104 é um dispositivo diferente do PDR 150 são dados abaixo.
Como exposto acima, uma opção para garantir que o EINR não foi retransmitido pelo DR 108 é selecionar o EINR para ser de um tipo de elemento de informação conhecido por não ser retransmitido por dispositivo de retransmissão de uma classe específica de dispositivos de retransmissão a qual o DR 108 pertence. Por exemplo, é conhecido que certos proxys SOCKS retransmitem comunicações http mas não retransmitem comunicações TCP. Se o DR 108 é um proxy SOCKS, ele irá manter uma conexão TCP com o DFI 104 e outra conexão TCP separada com o HM 110, e irá retransmitir comunicações http de uma conexão TCP para a outra. Deste modo, em algumas concretizações, o EIPR é parte de uma comunicação http possivelmente retransmitida, e o EINR é parte de uma comunicação TCP não-retransmitida.
Em algumas concretizações, o primeiro e segundo elementos de informação (EINR e EIPR) são parte de duas camadas diferentes em um Protocolo Stack de uma única comunicação. Desta forma, em um caso particular, um único http sobre comunicação TCP é enviado, e o primeiro elemento de informação não-retransmitido é parte da camada TCP da comunicação, enquanto o segundo elemento de informação possivelmente retransmitido é parte da camada http da comunicação. Alternativamente, o primeiro e segundo elementos são partes de duas comunicações separadas.
Algumas vezes, entretanto, a classe do Dispositivo de Retransmissão 108 não é necessariamente conhecida para o Sistema de Detecção de Retransmissão 102. Em algumas concretizações, o método apresentado explicitamente requere um passo opcional de estimar ou objetivar uma classe especifica de dispositivos de retransmissão, e realizar o método sob a suposição de que uma potencial classe de dispositivos de retransmissão é da classe objetivada de dispositivos de retransmissão.
Em algumas concretizações, métodos da presente invenção são repetidos para diferentes pares de EINR e EIPR, em que cada par é instrumental em detectar ao menos uma classe de dispositivos de retransmissão.
Em geral, é exposto que em algumas concretizações, um método apresentado pode ser repetido seqüencialmente ou em paralelo um número de vezes, em que uma probabilidade final de que um potencial dispositivo de retransmissão é um dispositivo de retransmissão é derivado de algum tipo de resultados agregados dos métodos repetidos. Em algumas concretizações, obter um agregado inclui obter uma média, uma média ponderada, um mínimo, máximo ou qualquer outro método de caracterizar resultados agregados conhecido na técnica. Usando Latência de Comunicação
Em uma concretização particular da presente invenção, a Característica do DFI é escolhida para ser a latência das comunicações entre o DFI 104 e o HM 110, e a Característica do PDR é a latência das comunicações entre o PDR 150 e o HM 110. Como a latência de um dispositivo para outro dispositivo é usualmente relativamente estável, então o mesmo dispositivo não tem probabilidade de exibir duas latências significantemente diferentes. Portanto, se a latência do DFI 104 e a latência do PDR 150 são significantemente diferentes, então é relativamente mais provável que o DFI 104 e o PDR 150 sejam dispositivos distintos (por exemplo, PDR 150 é um Dispositivo de Retransmissão 108, e EIPR estava sendo retransmitido). Similarmente, se a latência do DFI 104 e a latência do PDR 150 são similares, então é relativamente mais provável que o DFI 104 e o PDR 150 sejam o mesmo dispositivo (por exemplo, EIPR não estava sendo retransmitido).
Como usado na presente invenção, o termo "latência" se refere ao atraso de tempo entre o envio de uma comunicação e o seu recebimento.
A latência ocorre por causa de razões variadas. Uma razão é o tempo requerido para que sinais eletrônicos ou ondas eletromagnéticas percorram a distância entre dois pontos no caminho da comunicação (por exemplo, sinais elétricos em um cabo elétrico, luz em uma fibra ótica, ou microondas em um link de microondas). Outra razão é o tempo requerido para uma informação ser transferida através de uma linha de comunicação (por exemplo, levariam 25 milisegundos (ms) para 1500 Bytes serem completamente transferidos através de uma linha de comunicação de 480 kilobits-por- segundo (kbps)). Outra razão é o método armazena-e-encaminha usado em muitas redes de dados, em que porções de comunicação (por exemplo, pacotes ou células) são encaminhadas de um elemento de rede intermediária para o próximo, apenas após terem recebido em totalidade. Outra razão é o atraso de comunicações em buffers de elementos de troca na rede (por exemplo, quando uma linha de comunicação está no processo de transferência de uma comunicação, novas comunicações são salvas em uma unidade de buffer até que a linha seja liberada). Outra razão é o tempo de processamento de certas comunicações, tais como para fazer decisões de roteamento, codificação, decodificação, compressão e descompressão.
Como uma comunicação é enviada de um dispositivo e recebida em um dispositivo diferente, é normalmente mais fácil medir o Tempo de Envio e Recebimento (TER) do que a latência. O TER é o tempo passado entre o envio de uma comunicação de saída (CS) de um HM 110 e o recebimento de uma comunicação de entrada (CE) pelo HM 110, a qual foi enviada imediatamente ao recebimento da CS. O TER é portanto a soma da latência da CS e a latência da CE. Por exemplo, quando usando o mecanismo ICPM echo (veja RFC 792), o TER é o tempo passado entre o envio da mensagem de Echo e o recebimento da mensagem de resposta de Echo.
A Fig. 4A descreve as latências de comunicações entre o DFI 104 e o HM 110 no caso onde o DR 108 está sendo usado.
T1 é a latência de comunicações do HM 110 para o DR 108.
T2 é a latência de comunicações do DR 108 para o DFI 104. Τ3 é a latência de comunicações do DFI 104 para o DR 108.
T4 é a latência de comunicações do DR 108 para o HM 110.
A Fig. 4B descreve as latências de comunicações entre o DFI 104 e o HM 110 no caso onde o DR 108 não está sendo usado.
T5 é a latência de comunicações do HM 110 para o DFI 104.
T6 é a latência de comunicações do DFI 104 para o HM 110.
Como usado na presente invenção, o termo "TER de DFI" se refere ao tempo de envio e recebimento de comunicações entre o HM HOeoDFI 104.
Como usado na presente invenção, o termo "TER de PDR" se refere ao tempo de envio e recebimento de comunicações entre o HM 110eoPDR 150.
Como usado na presente invenção, o termo "espaço de TER" se refere à diferença entre o TER do DFI e o TER do PDR.
No caso onde o PDR 150 é DR 108 (por exemplo, EIPR é retransmitido) o tempo de envio e recebimento do TER de DFI deveria ser mais longo do que o TER de PDR. Especificamente, o TER de PDR é igual ao T1 + T4 (o TER entre o HM 110 e o DR 108), e o TER de DFI é igual a T1 + T2 + T3 + T4 (o TER entre o HM 110 e o DR 108 mais o TER entre o DR 108 e o DFI 104). O espaço de TER iguala ao TER entre o PDR 150 (o qual o DR 108) e o DFI 104, o qual é igual a T2 + T3.
Entretanto, no caso onde o PDR 150 é o DFI 104 (por exemplo, EIPR não é retransmitido) então o TER de DFI e o TER de PDR são ambos iguais a T5 + T6 (o TER entre o HM 110 e o DFI 104). O espaço de TER portanto deveria ser próximo a zero. Por exemplo, se o TER de DFI é 640 milisegundos e o TER de PDR é 130 milisegundos, é mais provável que o PDR 150 é Dispositivo de Retransmissão 108 e que o EIPR está sendo retransmitido do que se o TER de DFI fosse 133 milisegundos e o TER de PDR fosse 130 milisegundos.
Deveria ser notado que mesmo no caso onde o PDR 150 é o DFI 104 algumas diferenças entre o TER de DFI e o TER de PDR podem ser encontradas, devido a atrasos de redes diferentes dos quais cada comunicação está sujeita. Entretanto, na maioria dos casos práticos o espaço de TER quando é utilizado um dispositivo de retransmissão é notadamente maior que o espaço de TER quando não é utilizado um dispositivo de retransmissão.
Quando é medido o espaço de TER, o SDR 102 está efetivamente realizando comparações em duas características. A primeira é a comparação da latência de uma comunicação do DFI 104 para o HM 110 comparada a latência de uma comunicação do PDR 150 para o HM 110. A segunda é a comparação da latência de uma comunicação do HM 110 para o DFI 104 comparada a latência de uma comunicação do HM 110 para o PDR 150. Ambas latências deveriam ser maiores em comunicações retransmitidas comparado a comunicações não-retransmitidas, significando que o espaço de TER, o qual é a some de duas latências diferentes, deveria também ser maior em comunicações retransmitidas comparado a comunicações não-retransmitidas.
Em concretizações exemplares o DR 108 é um proxy SOCKS, o DFI 104 é um cliente http e o HM 110 é um servidor http. Neste caso, o SDR 102 obtém o TER de DFI pela medição do TER de uma comunicação http (um EIPR), e obtém o TER de PDR pela medição do TER de uma comunicação TCP (um EINR).
Em outra concretização exemplar, o DR 108 é um proxy http com uso do método CONNECT, o DFI 104 é um cliente SMTP, e o HM 110 é um servidor SMTP. Neste caso, o SDR 102 obtém o TER de DFI pela medição do TER de uma comunicação SMTP (um EIPR). O SDR 102 então envia uma mensagem Echo ICMP para a endereço de IP fonte da conexão TCP (um EINR) no qual a comunicação SMTP foi recebida. O SDR 102 então recebe uma mensagem de resposta Echo ICMP. O TER de PDR é o tempo entre as duas mensagens ICMP (como explicado abaixo, a fonte original da mensagem de resposta Echo ICMP é o PDR 150).
Métodos para medir o TER de variados tipos de comunicações são descritos abaixo.
O espaço de TER é ainda útil na diferenciação entre diversos usos de dispositivos de retransmissão. Por motivos de performance e segurança, usuários legítimos normalmente usam um dispositivo de retransmissão próximo (por exemplo, na mesma rede corporativa), resultando em um curto espaço de TER. Por outro lado, usuários maliciosos freqüentemente usam um dispositivo de retransmissão remoto (por exemplo, em outro país), resultando em um longo espaço de TER. Um longo espaço de TER é portanto indicativo de um dispositivo de retransmissão usado para propósitos malignos. Este método é especificamente eficiente em casos onde usuários maliciosos não podem evitar o uso de um dispositivo de retransmissão remoto. Por exemplo, um fraudador da Indonésia, que deseja parecer como residente nos EUA, precisa usar um dispositivo de retransmissão remoto. Em outro exemplo, seria significantemente mais difícil para um spammer usar um grande número de retransmissores se todos eles precisam ter espaços de TER curtos.
Medição de TER
Medições de TER precisos requerem a CE seja imediatamente enviada ao ser recebida a CS. Isto pode ser obtido de diversas formas.
Algumas implementações de protocolo fornecem resposta imediata em algumas comunicações. Por exemplo, em um intercâmbio de sinais predeterminados de três-vias TCP, um segmento contendo os indicadores de controle SYN e ACK (segmento SYN-ACK) deveria ser enviado imediatamente ao recebimento do segmento relacionado contendo o indicador de controle SYN (segmento SYN). O TER em tal caso é o tempo entre o envio de um segmento SYN (CS) e o recebimento de um segmento SYN-ACK (CE).
Em outros casos, o protocolo de implementação pode não fornecer uma resposta imediata, mas um aplicativo manejando as comunicações pode ser esperado para gerar-la. Por exemplo, um cliente http geraria normalmente uma requisição http imediatamente ao recebimento de uma resposta http '302'. Em outro exemplo, um browser HTML geraria normalmente uma requisição http imediatamente ao recebimento da primeira imagem embutida em uma página HTML (por exemplo, usando o símbolo <img> de HTML). Em outro exemplo, uma camada SSL/TLS enviará uma mensagem CIientHeIIo imediatamente ao recebimento do segmento TCP SYN- ACK indicando que a conexão TCP foi estabelecida. Em outro exemplo, um cliente SMTP normalmente enviaria um comando 'RCTP' imediatamente ao recebimento de uma resposta '250' para um comando 'MAIL' anterior (veja RFC 821). Em outro exemplo, um cliente IRC iria normalmente enviar uma mensagem 'PONG' imediatamente ao recebimento de uma mensagem 'PING' de um servidor IRC.
Em outros casos,interação humana poderia ser usada para gerar respostas imediatas. Por exemplo, o usuário é apresentado a um jogo no qual ele deve pressionar uma tecla do teclado imediatamente ao ver um sinal na tela. O sinal é apresentado quando a CS é recebida, e a CE é enviada quando o usuário responde.
Diversas medições de TER feitas por um curto período de tempo podem produzir resultados diferentes. Isto se deve a variações nas congestões de rede e outros parâmetros. É recomendável, entretanto, fazer diversas medições de TER, se possível. Além disso, como o TER não pode cair abaixo do tempo se tomadas para o sinal elétrico ou eletromagnético viajar a rota completa, usar a mais baixa de diversas medições de TER irá normalmente produzir resultados mais precisos e confiáveis.
Deveria ser notado que um usuário malevolente pode enviar uma CE anteriormente ao recebimento de uma CS. Isto irá iludir o SDR 102 a calcular um TER menor. É recomendado, entretanto, colocar alguma informação secreta na CS (informação secreta é uma informação que não pode ser facilmente obtida por uma pessoa ou dispositivo que ainda não sabe o segredo), e requerer que a CE contenha a informação secreta (ou uma derivação da mesma). Isto previne o envio de uma CE antes do recebimento da informação secreta na CS. Por exemplo, a resposta de http '302' descrita acima pode redirecionar o cliente http a um URL que contenha um segredo. O cliente http iria então gerar uma requisição de http para tal URL, desta forma enviando o mesmo segredo de volta. Em outro exemplo, um segmento TCP SYN-ACK (uma CS) contém um número inicial de seqüência secreto, e um segmento TCP contendo o indicador de controle ACK (segmento TCP ACK; uma CE) contém um Número de Confirmação, o qual é uma derivação do número inicial de seqüência. Em outro exemplo, uma mensagem ICMP Echo (uma CS) contém um Identificador, um número de seqüência ou um dado secreto, e uma mensagem de resposta ICMP Echo (uma CE) contém o mesmo segredo.
Deveria ser notado que ao calcular o TER, o SDR 102 precisa também monitorar comunicações enviadas pelo HM 110 (e não apenas comunicações recebidas pelo HM 110), com o objetivo de detectar o tempo no qual cada CS é enviada. Entretanto, este requerimento pode ser desviado se uma CS para o DFI 104 e uma CS para o PDR 150 são conhecidas por serem enviadas ao mesmo tempo. Em tais casos, os TER são desconhecidos, mas o espaço de TER pode ainda ser calculado, e é igual à diferença entre os tempos de chegada das respectivas CE. Por exemplo, se o Elemento de Informação Potencialmente Retransmitido é SSL/TLS e o Elemento de Informação Não-Retransmitido é TCP, o segmento TCP SYN-ACK enviado pelo HM 110 é assim uma CS, e o espaço de TER é o tempo entre o recebimento do segmento TCP ACK correspondente e o recebimento da mensagem CIientHeIIo SSL/TLS. Se ο HM 110 não envia uma CS, a qual pode ser usada pelo SDR 102, o SDR 102 pode precisar enviar tal CS por si mesmo. Por exemplo, o SDR 102 monitora comunicações http para e de um website (HM 110). Com o objetivo de medir o TER do EIPR1 o SDR 102 fornece uma resposta http '302' para algumas das requisições http recebidas pelo HM 110, como descrito acima. Neste exemplo, o SDR 102 pode precisar ser um módulo de software instalado no HM 110, para que ele possa responder as comunicações http enviadas ao HM 110.
Nas concretizações que envolvem medições de latências ou TER é recomendável checar que o TER do DFI é 'significantemente diferente' que o TER do PDR. Os Tempos de Envio e Recebimento são significantemente diferentes quando a diferença entre eles é uma que raramente ocorra quando são feitas medições de TER em comunicações com o mesmo dispositivo. No momento em que este texto foi escrito, o TER entre dois dispositivos em um ambiente de Internet razoavelmente estável não varia por mais de 50 milisegundos dentro de um quadro de tempo de poucos segundos. Em contraste, o espaço de TER em comunicações retransmitidas usualmente excede 100 milisegundos. Desta forma, em algumas concretizações, 'significantemente diferente' pode ser interpretado com o significado de 'mais de 60 milisegundos'. Em algumas concretizações, 'significantemente diferente' pode ser interpretado com o significado de 'mais de 80 milisegundos'. Em algumas concretizações, 'significantemente diferente' pode ser interpretado com o significado de 'mais de 100 milisegundos', e assim por diante. Em algumas concretizações, o TER para um dispositivo não é diretamente medido, mas preferencialmente estimado baseado em outras informações conhecidas sobre o dispositivo, tais como sua localização geográfica, seu registro de reverse DNS do endereço de IP (por exemplo, endereço de host para a tradução do nome do host), e/ou seu registro de WHOIS do endereço de IP (para informações sobre o serviço WHOIS veja o website de Registro Americano para Números de Internet em http://www.arin.net). Por exemplo, se o HM 110 está localizado na cidade de Nova York, Nova York, EUA, e um serviço de geo-localização de IP indica que o PDR 150 está localizado em Los Angeles, Califórnia, EUA, e o texto 'dsl' é encontrado no registro de reverse DNS do endereço de IP do PDR 150 indicando que é provavelmente um Digital Subscriber Line (DSL; para informações sobre DSL veja o website do Fórum sobre DSL em http://dslforum.org)· então o SDR 102 pode estimar que o TER entre o HM 110 e o PDR 150 está na área de 65-85 milisegundos. Isto ocorre porque é conhecido que o TER na Internet entre a cidade de Nova York e Los Angeles é usualmente aproximadamente 55 milisegundos, e porque é conhecido que uma DSL usualmente adiciona 10-30 milisegundos ao TER.
Usando Status de Configuração de Dispositivo
Em outra concretização particular da presente invenção, a Característica do DFI e a Característica do PDR são o status de configuração do DFI 104 e do PDR 150, respectivamente. Como usado na presente invenção, o termo 'status de configuração' se refere ao hardware e software de um dispositivo e o modo como eles estão customizados. Se a Característica do DFI e a Característica do PDR são status de configuração que são improváveis de se relacionar ao mesmo dispositivo, então é relativamente mais provável que o PDR 150 e o DFI 104 sejam dispositivos distintos (por exemplo, PDR 150 é um Dispositivo de Retransmissão 108, e EIPR estava sendo retransmitido).
Similarmente, se a Característica do DFI e a Característica do PDR são status de configuração que são prováveis de se relacionar a um mesmo dispositivo, então é relativamente mais provável que ρ PDR 150 e o DFI 104 sejam o mesmo dispositivo (por exemplo, EIPR não estava sendo retransmitido).
Existem diversos métodos conhecidos para detectar o status de configuração de um dispositivo das comunicações. Um método é usar informação explícita sobre a configuração fornecida pelo dispositivo na comunicação. Por exemplo, clientes http normalmente incluem em cada requisição o header "User-Agent", o qual fornece informação sobre o tipo e versão do sistema de operação, o tipo e versão de cliente http, e adicionais softwares instalados no dispositivo. Aplicativos de e-mail podem fornecer informação similar no RFC 822 'X-Mailer' header, servidores de e-mail podem fornecer tal informação no RFV 822 'Received' header, e o servidor http normalmente inclui em uma resposta http o header 'Server', o qual fornece informação sobre o tipo e versão do servidor http.
Outro método é deduzir o status de configuração do dispositivo pela maneiro como ele implementa variados protocolos de comunicação. A popular ferramenta de administração de rede 'Nmap' inclui muitas implementações deste método, como descrito detalhadamente no artigo 'Remote OS detection via TCP/IP Stack Fingerprint' escrito pelo responsável pelo desenvolvimento do Nmap (disponível em http://www.insecure.org/nmap/nmap-finqerprint- article.html). Por exemplo, o artigo sugere examinar a Janela Inicial escolhida por uma implementação TCP1 já que diferentes sistemas de operação escolhem diferentes números. Deveria ser notado que enquanto o artigo assume que o dispositivo investigado está respondendo a uma comunicação, este método é também aplicável à comunicações iniciadas por um dispositivo (apesar das indicações específicas poderem variar).
Em um exemplo desta concretização, onde o DR 108 é um proxy SOCKS1 o SDR 102 monitora a requisição http (EIPR) que inclui o header 'User-Agent: Mozilla/4.0 (compatíveis; MSIE 6.0; Windows NT 5.0)' - Este header indica que o sistema operacional é o Microsoft Windows 2000. A requisição http é enviada através de uma conexão (EINR) que tinha uma Janela Inicial de 5840 - Isto é típico de outros sistemas operacionais (especificamente o Red Hat Enterprise Linux). Como um dispositivo não poderia rodar concorrentemente dois sistemas operacionais, o SDR 102 determina que o DFI 104 e o PDR são dispositivos distintos (por exemplo, PDR 150 é um Dispositivo de Retransmissão 108, e a requisição http estava sendo retransmitida). Neste exemplo, a Característica do DFI é a informação de que o DFI 104 está rodando o sistema operacional Microsoft Windows 2000, e a Característica do PDR é a informação de que o PDR 150 está rodando o sistema operacional Red Hat Enterprise Linux.
Em outro exemplo desta concretização, onde o DR 108 é um proxy http com uso do método CONNECT, o SDR 102 monitora uma requisição http (EIPR) que inclui o header 'Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/124 (KHTML, como Gecko) Safári/125' - Este header indica que o sistema operacional é Apple Mac OS X. A requisição http é enviada através de uma conexão TCP (EINR). O SDR 102 conecta a porta 80 do endereço de IP fonte da conexão TCP e envia uma requisição http. O SDR 102 então recebe uma resposta http contendo um header 'Server: Microsoft -IIS/5.0' (como explicado abaixo, a fonte original desta resposta http é o PDR 150). Como é conhecido que servidores Microsoft IIS não rodam em sistemas operacionais Apple Mac OS X, então o SDR 102 determina que o DFI 104 e o PDR 150 são dispositivos distintos (por exemplo, o PDR 150 é um Dispositivo de Retransmissão 108, e a requisição http do DFI 104 estava sendo retransmitida). Neste exemplo, a Característica do DFI é a informação de que o DFI 104 está rodando o sistema operacional Apple Mac OS X, e a Característica do PDR é a informação de que o PDR 150 está rodando um servidor Microsoft IIS.
Em alguns casos é necessário enviar á fonte original de um elemento de informação uma CS que fará com que a fonte original envie de volta uma CE que poderia ser usada para determinar sua configuração. No exemplo dado acima, onde o http 'Server' header é usado, a requisição http enviada do SDR 102 para o PDR 150 é uma Comunicação de Saída e a resposta http é uma Comunicação de Entrada. Métodos para garantir que uma CS seja enviada à fonte original de um elemento de informação, e métodos para garantir que uma CE seja recebida da fonte original de um elemento de informação são apresentados abaixo. Usando Informação de Localização, Sub-rede ou Administrador
Em outra concretização particular da presente invenção, a Característica do DFI e a Característica do PDR são a localização, sub-rede e/ou administrador do DFI 104 e do PDR 150, respectivamente. Como usado na presente invenção, o termo 'localização' se refere à localização geográfica do dispositivo, o termo 'sub-rede' se refere ao grupo de dispositivos que está próximo a um dispositivo na topologia da rede, e o termo 'administrador'se refere à organização que conecta o dispositivo à rede (por exemplo, à Internet). Exemplos de localização de um dispositivo poderiam ser 'Cidade de Nova York, Nova York, Estados Unidos da América' ou 'Longitude 32 graus 5 minutos ao Norte, Latitude 34 graus 46 minutos ao Leste'. Exemplos de sub-rede de um dispositivo poderiam ser 'todos dispositivos no mesmo segmento de rede de área local como o dispositivo os quais endereços de IP são 1.2.3.4'. Exemplos de administrador de um dispositivo poderiam ser iEarthIink, Inc. of Atlanta, Geórgia, EUA', o qual é um Provedor de Serviços na Internet que conecta usuários à Internet por uma taxa, ou 'General Electric Company of Princeton, New Jersey, EUA', a qual é uma companhia que conecta alguns de seus empregados à Internet, como requerido para o seu trabalho.
Não é provável que um único dispositivo tenha concorrentemente duas localizações, sub-redes ou administradores diferentes. Desta forma, se for verificado que o DFI 104 está em uma localização diferente e/ou em uma sub-rede diferente e/ou possui um administrador diferente que PDR 150, então é relativamente mais provável que o DFI 104 e o PDR 150 sejam dispositivos distintos (por exemplo, EIPR estava sendo retransmitido). Similarmente, se for verificado que o DFI 104 está em uma mesma localização e/ou em uma mesma sub-rede e/ou possui um mesmo administrador que PDR 150, então é relativamente mais provável que o DFI 104 e o PDR 150 sejam um mesmo dispositivo (por exemplo, EIPR não estava sendo retransmitido).
Em uma concretização exemplar, o DR 108 é um proxy SOCKS, o DFI 104 é um cliente SMTP e o HM 110 é um servidor SMTP. Neste caso, o SDR 102 usa o endereço de IP fonte da sessão TCP (um EINR) e um serviço de geo-localização de IP para estimar a localização do PDR 150. O SDR 102 usa então um RFC 822 'Date' header relatado na comunicação SMTP (um EIPR) para estimar a localização do DFI 104. O 'Date' header indica o tempo ('relógio de parede') e a configuração de fuso horário do DFI 104, e é, desta forma, um indicador de sua localização (visto que dispositivos são normalmente configurados a hora e fuso horário local). Se as duas localizações não combinarem (por exemplo, o serviço de geo- localização indica que o PDR 150 está localizado na cidade de Nova York, enquanto o fuso horário do DFI 104 é GMT+7), então o SDR 102 determina que o PDR 150 e o DFI 104 são dispositivos distintos (por exemplo, o PDR 150 é um Dispositivo de Retransmissão 108, e a comunicação SMTP estava sendo retransmitida).
Métodos alternativos para estimar a localização do PDR 150 (outro que não usar um serviço de geo-localização de IP) inclui, mas não se limitam a,: (a) checar o registro WHOIS do endereço de IP. O endereço dado no registro WHOIS é provavelmente relativamente próximo à localização do PDR 150; e (b) checar o registro DNS reverse do endereço de IP (por exemplo, se o registro termina com '.fr' então o PDR 150 está provavelmente na França).
Métodos alternativos para estimar a localização do DFI 104 (outro que não seja usar o 'Date' header em uma comunicação SMTP) inclui, mas não se limitam a,: (a) (no caso de o EIPR ser SMTP) checar o último RFC 822 'Received' header relatado na comunicação SMTP, o qual deveria conter a configuração de fuso horário do servidor SMTP usado pelo DFI 104, o qual é freqüentemente o mesmo fuso horário do próprio DFI 104; (b) (no caso de o EIPR ser http) checar o header 'Accept-Language' http, o qual indica as línguas suportadas pelo DFI 104 (por exemplo, o header 'Accept-Language:ru' significa que o DFI 104 suporta conteúdos na língua russa, e é, dessa forma, mais provável que o DFI 104 esteja localizado na Rússia); e (c) checar a localização da fonte de outra comunicação a qual foi disparada por um evento no DFI 104 (uma Comunicação Disparada DFI), como descrito detalhadamente abaixo, usando qualquer um dos métodos descritos acima para estimar a localização de um PDR 150.
Em outra concretização exemplar, o DR 108 pertence a uma classe de dispositivos de retransmissão que não retransmitem TCP (por exemplo, TCP é um EINR) e o SDR 102 usa o endereço de IP fonte de uma sessão TCP para estimar a sub-rede do PDR 150. Isto pode ser feito através da recuperação do registro WHOIS, registro DNS reverse ou registro do banco de dados de roteamento associado com aquele endereço de IP (para informações sobre banco de dados de roteamento veja o RADb website em http://www.radb. net). Isto pode também ser feito através da descoberta de roteadores adjacentes ao PDR 150 usando as mensagens de 'Tempo Excedido' ICMP enviadas em resposta para pacotes IP com pequenos valores Time-to-Live, como feito pelo Unix utility traceroute (ou o equivalente Microsoft Windows utility tracert), já que dispositivos na mesma sub- rede normalmente se conectam a Internet 100 através dos mesmos roteadores. O SDR 102 então estima a sub-rede do DFI 104. Isto pode ser feito através da checagem da sub-rede da fonte de uma Comunicação Disparada do DFI, como descrito em detalhes abaixo, usando qualquer um dos métodos descritos acima para estimar a sub- rede do PDR 150. Se as duas sub-redes não combinam (por exemplo, os nomes das sub-redes nos registros WHOIS dos dispositivos são diferentes ou os dispositivos não tem um roteador adjacente comum), então o SDR 102 determina que o PDR 150 e DFI 104 são dispositivos distintos (por exemplo, o PDR 150 é um Dispositivo de Retransmissão 108, e o EIPR estava sendo retransmitido).
Em outra concretização exemplar, o DR 108 pertence a uma classe de dispositivos de retransmissão que não retransmitem TCP (por exemplo, TCP é um EINR) e o SDR 102 usa o endereço de IP fonte de uma sessão TCP para estimar o administrador do PDR 150. Métodos exemplares para estimar o administrador incluem, mas não se limitam a,: (a) recuperar o registro WHOIS associado com aquele endereço de IP (o nome da organização dado no registro é provavelmente o administrador); (b) recuperar o registro DNS reverse associado com aquele endereço de IP (por exemplo, se o registro termina com 'cox.net' então o administrador é provavelmente 'Cox Communications de Atlanta, Geórgia, EUA'); (c) recuperar o registro WHOIS associado com o domínio de segundo nível no registro do DNS reverse associado com aquele endereço de IP; e (d) recuperar o registro do banco de dados de roteamento associado com aquele endereço de IP. O SDR 102 então estima o administrador do DFI 104. Métodos para estimar o administrador do DFI 104 incluem, mas não se limitam a,: (a) (no caso em que o EIPR é http) checar o http header 'User-Agent' o qual algumas vezes contém informações sobre o administrador. Por exemplo, um 'User-Agent' header contendo o texto 'AOL 9.0' indica que o browser HTML instalado no DFI 104 foi provido por America Online, Inc. de Dulles, Virgínia, EUA (AOL). Como muitos usuários de Internet recebem seu browser HTML da mesma organização pela qual eles se conectam à Internet, isto aumenta a probabilidade de que o DFI 104 se conecta à Internet através do AOL (por exemplo, AOL é o administrador). Em outro exemplo, o texto 'Cox High Speed Internet Customer' indica que o browser for provido por Cox Communications de Atlanta, Geórgia, EUA; (b) (no caso em que o EIPR é SMRP) checar o RFC 822 'Organização' header, o qual algumas vezes contém informações sobre o administrador; e (c) checar o administrador do endereço de IP fonte de uma Comunicação Disparada do DFI, como descrito em detalhes abaixo, usando qualquer um dos métodos descritos acima para estimar o administrador do PDR 150.
Comunicações Disparadas do DFI
Informações sobre o DFI 104 podem ser descobertas através do disparo do DFI 104 para enviar comunicações. Tam comunicação é uma 'Comunicação Disparada do DFI'.
Comunicações Disparadas do DFI exemplares que expõem o endereço de IP do DFI 104 são apresentadas no pedido de PCT W002/08853, a totalidade da qual é incorporada a esta por referência. Após receber o endereço de IP do DFI 104, o SDR 102 pode usar os métodos descritos acima para encontrar sua localização, sub-rede ou administrador. Ele pode então compará-los à localização, sub-rede ou administrador do PDR 150, e determinar se eles são dispositivos diferentes. Alternativamente, o SDR 102 pode comparar o endereço de IP do DFI 104 e o endereço de IP do PDR 150 diretamente. Se eles forem diferentes, é relativamente mais provável que o DFI 104 seja um dispositivo diferente do PDR 150 (por exemplo, o PDR 150 é um Dispositivo de Retransmissão 108, e o EIPR estava sendo retransmitido).
Outra comunicação disparada exemplar é uma requisição DNS. Em alguns casos, o DFI 104 irá enviar uma requisição DNS associada com um EIPR, com o objetivo de traduzir um hostname em endereço de IP. O DFI 104 irá enviar a requisição DNS ao servidor(es) DNS que está configurado a usar. O servidor DNS do DFI 104 irá então enviar uma requisição DNS ao servidor DNS autorizado para o dado hostname. O SDR 102 monitora a requisição DNS enviada a este servidor DNS autorizado. Deveria ser notado que, apesar da requisição DNS monitorada pelo SDR 102 poder ser recebida de um servidor DNS que o DFI está configurado a usar, o DFI 104 é a fonte original de ao menos um elemento de informação contido na requisição DNS. O pedido de Patente Americana No. US2002016831, a totalidade da qual é incorporada a esta por referência descreve o método de fazer com que um dispositivo gere requisições DNS, assim como os métodos de associar a requisição DNS com a indentidade do dispositivo que as originou. Um método para associar uma requisição DNS com o EIPR relevante é configurar o servidor DNS autorizado para responder com um endereço de IP diferente para cada requisição de tradução de um hostname, a manter um registro de qual requisição DNS recebeu qual endereço de IP como resposta. Quando o EIPR é recebido em um dos endereços de IP, a requisição DNS associada pode ser recuperada dos registros.
Após receber a Requisição DNS do servidor DNS do DFI 104, o SDR 102 pode usar os métodos descritos acima para encontrar sua localização, sub-rede ou administrador. Por motivos de performance e econômicos, muitos dispositivos conectados à Internet são configurados para usar um servidor DNS que está em uma localização similar, na mesma sub-rede, ou administrado pelo mesmo administrador. O SDR 102 pode, desta forma, comparar a localização, sub-rede ou administrador do PDR 150, com a localização, sub-rede ou administrador do servidor DNS do DFI 104, respectivamente. Se eles não combinarem , é relativamente mais provável que o DFI 104 seja um dispositivo diferente do PDR 150 (por exemplo, EIPR está sendo retransmitido).
Usando Taxa de Comunicação Máxima
Em outra concretização particular da presente invenção, a Taxa Máxima de Comunicação (TMC) do PDR 150 e do DFI 104 são usadas para determinar se estes são o mesmo dispositivo. O termo Taxa Máxima de Comunicação (TMC) se refere a quantidade máxima de informação que um dispositivo pode receber (TMC de entrada) ou enviar (TMC de saída) durante um intervalo de tempo. 'Bits por Segundo' (bps) é uma medida comum de TMC. Por exemplo, algumas linhas DSL tem uma TMC de entrada de 1.5 Milhões bps (Mbps), e uma TMC de saída de 96 mil bps (kbps).
Se a TMC do PDR 150 é diferente da TMC do DFI 104, então é mais provável que o DFI 104 seja um dispositivo diferente do PDR 150 (por exemplo, EIPR está sendo retransmitido).
Em um exemplo desta concretização, DR 108 é conectado à Internet 100 em uma linha DSL com uma TMC de entrada de 1.5 Mbps e uma TMC de saída de 96 kbps. Como as comunicações retransmitidas do HM 110 para o DFI 104 são transferidas através da interface de entrada do DR 108 e então através de sua interface de saída, então a TMC de entrada do DFI 104 não poderia exceder a TMC de saída do DR 108 (96kbps). Desta forma, a TMC de entrada do PDR 150 é 1.5 Mbps enquanto a TMC de entrada do DFI 104 é 96 kbps ou menos.
Em outro exemplo desta concretização, o DR 108 é conectado à Internet 100 a uma TMC de 20 Mbps em ambas direções, e o DFI 104 é conectado à Internet em uma linha DSL com uma TMC de entrada de 1.5 Mbps e uma TMC de saída de 96 kbps. Desta forma, a TMC de entrada do PDR 150 é 20 Mbps enquanto a TMC de entrada do DFI 104 é 1.5 kbps, e a TMC de saída do PDR 150 é 20 Mbps enquanto a TMC de saída do DFI 104 é 96 kbps.
Detecção da Taxa de Comunicação Máxima De acordo com algumas concretizações da presente invenção, a checagem para saber se a TMC do DFI 104 é diferente da TMC do PDR 150 é feita através da detecção da TMC de cada e comparação das mesmas. Um método para detectar uma TMC é enviar iformação para, ou receber informação de, um dispositivo, usando um protocolo que automaticamente se ajusta à taxa máxima de comunicação possível, tal como TCP, e observar a taxa de comunicação. Para uma explicação de alguns mecanismos usados em TCP para ajustar-se à TMC1 veja o artigo 'JACOBSON, V. Congestion avoidance e control. In Proceedings of SIGCOMM '88 (Stanford, CA, Agosto 1988), ACM' e os artigos por ele referidos.
Outro método para observar a taxa de comunicação de entrada de um dispositivo envolve monitorar confirmações de recebimento recebidas do dispositivo. Por exemplo, um dispositivo que recebe informações em uma conexão TCP, envia de tempos em tempos a quantidade de informação recebida com sucesso. Receber uma confirmação de byte número 3,000,000 em um momento e uma confirmação de byte número 3,250,000 vinte segundos depois indicaria que o dispositivo está recebendo informações à uma taxa de 12,500 Bytes por Segundo, a qual iguala 100,00 Bits por Segundo (por exemplo, sua TMC de entrada é 100 kbps). Em outro exemplo, como descrito acima, um browser HTML iria normalmente gerar uma requisição http imediatamente ao recebimento da primeira imagem embutida em uma página HTML (por exemplo, usando o símbolo <img> HTML). Receber a requisição http quarenta segundos após começar a enviar uma página HTML, na qual o símbolo imagem embutido está localizado a 1,000,000 bytes, indicaria que o dispositivo está recebendo informações a uma taxa de 25,000 Bytes por Segundo, o que iguala a 200,00 Bits por Segundo (por exemplo, sua TMC de entrada é 200 kbps). Deveria ser notado que esta medição poderia ser imprecisa já que compara o envio do início de uma página HTML para o recibo da requisição http, conseqüentemente adicionando ao menos um tempo de envio e recebimento a medição. Medir o tempo de envio e recebimento e subtraí-lo desta medição de tempo pode produzir resultados mais precisos.
O DR 108 normalmente salva comunicações retransmitidas entre o HM 110 e o DFI 104. Buffers são temporariamente armazenados, dentro dos quais o DR 108 escreve as comunicações recebidas, e dos quais o DR 108 lê as comunicações enviadas. Quando os buffers não estão cheios, o DR 108 pode receber comunicação em sua TMC de entrada. Quando os buffers estão cheios, o DR 108 pode receber comunicações à taxa que pode esvaziar os buffers (por exemplo, à taxa que pode enviar comunicações dos buffers). Isto significa que uma medição da taxa de comunicação do HM 110 para o DR 108 poderia ser uma indicação da TMC de entrada do DR 108 quando os buffers não estão cheios, e uma indicação da TMC de entrada do DFI 104 quando os buffers ficam cheios. Os buffers ficariam cheios se a TMC de entrada do DFI 104 fosse menor que a TMC de entrada do DR 108. Por exemplo, se o DR 108 tem buffers do tamanho de 100,000 bytes, e sua TMC de entrada é 1.5 Mbps, e a TMC de entrada do DFI 104 é 96 kbps, então os buffers seriam preenchidos a uma taxa de 1.404 Mbps. Isso faria com que os buffers levassem aproximadamente 0.57 segundos para ficarem cheios. Neste exemplo, uma medição da taxa de comunicação durante os primeiros 0.57 segundos seria 1.5 Mbps, e isto poderia ser uma indicação da TMC de entrada do DR 108, e uma medição da taxa de comunicação a qualquer momento após os primeiros 0.57 segundos seria 96 kbps, e isto poderia ser uma indicação da TMC de entrada do DFI 104. Desta forma, no caso em que o PDR 150 é o DR 108, a TMC de entrada do PDR 150 é indicada pela taxa de comunicação de entrada do PDR 150 antes do buffer ficar cheio, e a TMC de entrada do DFI 104 é indicada pela taxa de comunicação de entrada do PDR 150 após o buffer ficar cheio.
No caso onde o PDR 150 é o DFI 104, este buffer não existe e a taxa de comunicação de entrada do PDR 150 não muda, e permanece igual a TMC de entrada do DFI 104.
Desta forma, a TMC de entrada do PDR 150 é igual à taxa de comunicação de entrada do PDR 150 durante o tempo que o DR 108 levaria pra encher-se, e a TMC de entrada do DFI 104 é igual taxa de comunicação de entrada do PDR 150 após o ele ficar cheio.
O SDR 102 pode desta maneira determinar se o PDR 150 é um Dispositivo de Retransmissão 108 pela comparação da taxa de comunicação de entrada do PDR 150 nestes dois momentos.
Em muitos casos, a taxa de comunicação do DR 108 para o HM 110 não excede a TMC de saída do DFI 104, porque o DR 108 enviaria para o HM 110 apenas as informações recebidas do DF1104, e não iria gerar normalmente quantidades significantes de informação por si só. Entretanto, como descrito acima, já que o DR 108 salva as comunicações entre o DFI 104 e o HM 110, é possível medir a TMC de saída do DR 108 como segue. Alguns protocolos contêm um mecanismo de 'controle de fluxo', o qual permite que um dispositivo que recebe informações sinalize para um dispositivo que envia informações quando este deve parar de enviar novas informações e quando retomar o envio. Por exemplo, em TCP se um dispositivo de recebimento envia um segmento ACK com um valor 'Window' de zero, um dispositivo de envio iria normalmente parar de enviar novas informações, até que ele receba um segmento ACK com um valor 'Window' positivo. Um mecanismo de 'controle de fluxo' pode ser usado pelo HM 110 ou SDR 102 para sinalizar ao DR 108 para que ele pare de enviar informações novas. Isto faria com que os buffers do DR 108 se enchessem de informações, as quais o DR 108 irá continuar recebendo do DFI 104, e não iria enviar ao HM 110. O HM 110 ou SDR 102 iriam então usar o mecanismo de 'controle de fluxo' para sinalizar ao DR 108 para retomar o envio de informações novas.
Como agora o DR 108 iria enviar informações de seus buffers locais, até que os buffers se esvaziem , uma medição da taxa de comunicação seria uma indicação da TMC de saída do DR 108.
De acordo com algumas concretizações da presente invenção, a checagem para saber se a TMC do DFI 104 é diferente da TMC do PDR 150 é feita através da detecção de uma indicação de que os buffers do PDR 150 estão sendo preenchidos ou esvaziados. Por exemplo, como descrito acima, os buffers no DR 108 seriam preenchidos se a TMC de entrada do DFI 104 for menor que a TMC de entrada do PDR 150. Em outro exemplo, como descrito acima, os buffers do DR 108 seriam esvaziados se a TMC de saída do DFI 104 for menor que a TMC de saída do PDR 150. Alguns protocolos permitem que um dispositivo publique a capacidade de seus buffers, ou uma derivação destes, à outros dispositivos com os quais ele se comunica, e esta informação pode ser usada para estimar se os buffers de um dispositivos estão sendo preenchidos ou esvaziados.
Por exemplo, em TCP, um dispositivo publicaria a quantidade de informação que está disposto a receber no 'Window' header de cada segmento ACK enviado. Mudanças no valor do 'Window' header normalmente refletem mudanças na capacidade dos buffers do dispositivo. Um aumento no valor 'Window' indica que os buffers estão sendo esvaziados, enquanto uma diminuição no valor 'Window' indica que os buffers estão sendo preenchidos.
Desta forma, um valor 'Window' diminuindo é uma indicação direta de que a TMC de entrada do PDR 150 é maior que a TMC de entrada do DFI 104, significando que o PDR 150 e o DFI 104 são dispositivos distintos (por exemplo, PDR 150 é um Dispositivo de Retransmissão 108).
Outro método para detectar uma TMC é medir as duas latências de duas comunicações, nas quais a única diferença entre elas é a quantidade de informação contida em cada uma, e então calcular a TMC da diferença entre as duas latências. Como descrito acima, o tempo necessário para uma comunicação ser transferida através de uma linha de comunicação é proporcional à quantidade de informação contida na comunicação. Desta forma, a TMC é igual a diferença entre as quantidades de informações nas duas comunicações, dividido pela diferença entre as duas latências.
Este método pode também ser usado em medições de TER, mais propriamente que latência. Por exemplo, o TER de um mecanismo ICMP Echo, com uma mensagem Echo curta (por exemplo, 64 bytes), e o TER com uma mensagem Echo longa (por exemplo, 1500 bytes), podem ser usados para detectar a TMC de um dispositivo. Deveria ser notado que se as mensagens de entrada e saída contêm a mesma quantidade de informação, como no exemplo ICMP Echo, o método de TER forneceria uma medição combinada de ambas TMC de entrada e saída do dispositivo. Um método para superar esta limitação é fazer medições de TER usando um protocolo no qual apenas uma das comunicações de entrada e saída contém grande quantidade de informação. Isto reduziria a contribuição da latência da outra comunicação ao TER, e conseqüentemente fornecer uma melhor aproximação da latência da primeira comunicação. Por exemplo, um segmento TCP SYN enviado a uma porta fechada iria normalmente disparar um segmento contendo o indicador RST (segmento RST). Enquanto o segmento SYN pode ser de um tamanho escolhido por seu remetente, o segmento RST iria usualmente ser pequeno (por exemplo, 40 bytes).
Outro método de detecção de uma TMC é estima-la de outras informações conhecidas do dispositivo. Por exemplo, encontrar o texto 'dsl' no DNS reverse do endereço de IP do dispositivo indica que é provavelmente uma linha DSL, a qual usualmente tem uma TMC de entrada de 500-2,500 kbps e uma TMC de saída de 64-256 kbps. Em outro exemplo, encontrar que o administrador do PDR 150 é AOL indica que este é provavelmente conectado através de uma linha dial- up voice-modem (já que esta é a opção de conectividade primária oferecida pelo AOL), a qual usualmente tem uma TCM de entrada superior a 56 kbps e uma TMC de saída superior a 33 kbps.
Dois Dispositivos usando o mesmo Dispositivo de Retransmissão
Em outra concretização particular da presente invenção, o SDR 102 detecta que o PDR 150 é um Dispositivo de Retransmissão 108 pela determinação de que as fontes originais de dois elementos de informação são dois dispositivos diferentes, sem o requerimento de que uma das fontes originais seja o PDR 150.
Nesta concretização, o SDR 102 tenta distinguir entre os dois casos seguintes:
Fig. 5A fornece um diagrama do primeiro caso, no qual ρ DFI 104 envia dois elementos de informação, EIPR1 e EIPR2, diretamente ao HM 110, sem usar o DR 108. Os dois elementos de informação são de um tipo que o DR 108 pode retransmitir.
Fig. 5B fornece um diagrama do segundo caso, no qual dois dispositivos diferentes, DFI 104 e DFI2 106, cada um envia um elemento de informação para o HM 110, em que ambos elementos de informação são retransmitidos pelo DR 108.
O SDR 102 distingue entre os dois casos da seguinte forma: O SDR 102 monitora as comunicações do HM 110 e desta maneira recebe do DR 108 dois elementos de informação potencialmente retransmitidos (EIPR1 e EIPR2). O SDR 102 então checa se uma característica (Característica-EIPRI) de uma fonte original (Fonte-EIPRI) do EIPR1 e uma característica (Característica- EIPR2) de uma fonte original (Fonte-EIPR2) do EIPR2 são Características Incompatíveis. Se realmente a Característica-EIPRI e a Característica-EIPR2 são Características Incompatíveis, então é mais provável que a fonte original do EIPR1 e a fonte original do EIPR2 sejam dispositivos distintos, o que significa que o segundo caso é mais provável, o que significa que provavelmente o EIPR1 e o EIPR2 tenham sido retransmitidos.
Por motivos de simplificação, a descrição desta concretização contém apenas três dispositivos, dois dos quais usam um dispositivo de retransmissão. Na prática, existem muitos dispositivos conectados à Internet 100, e cada um deles pode ou não usar um ou diversos dispositivos de retransmissão que também estão conectados à Internet 100. Mais geralmente, esta concretização detecta que um potencial dispositivo de retransmissão é um dispositivo de retransmissão pela determinação de que ao menos duas fontes originais de ao menos dois elementos de informação potencialmente retransmitidos que foram recebidos do potencial dispositivo de retransmissão, têm Características Incompatíveis. Como por definição um único dispositivo não é provável de ter Características Incompatíveis, então é provável que as duas fontes originais sejam dispositivos distintos, e desta forma, ao menos uma das fontes não é o potencial dispositivo de retransmissão, o que significa que o elemento de informação desta fonte foi retransmitido e o potencial dispositivo de retransmissão é um dispositivo de retransmissão.
Todos os métodos descritos acima para determinar se características são Características Incompatíveis são também aplicáveis a esta concretização, mutatis mutandis. Por exemplo, o SDR 102 pode comparar os http 'User-Agent' headers fornecidos nos EIPR1 e EIPR2, e se eles forem indicativos de sistemas operacionais diferentes, determinar que o DFI 104 e o DFI2 106 são dispositivos diferentes e desta forma o PDR 150 é um Dispositivo de Retransmissão 108. Em outro exemplo, o SDR 102 pode detectar que o TER das comunicações com a Fonte-EIPRI e a Fonte-EIPR2 são significantemente diferentes. Deveria ser notado que, neste caso, cada TER é a soma de: (a) o TER entre o DR 108 e o HM 110, e (b) o TER entre cada fonte original e o DR 108. Desta forma, o espaço de TER1 neste caso, é um resultado das diferenças entre: (c) o TER entre a Fonte-EIPRI e o DR 108, e (d) o TER entre a Fonte-EIPR2 e o DR 108. Os dois TER não são necessariamente significantemente diferentes, mas em alguns casos eles podem ser, permitindo que o SDR 102 detecte um espaço de TER.
Garantindo Comunicações com uma Fonte Original
Em algumas concretizações da presente invenção, informações relacionadas a características de dispositivos são obtidas de uma ou mais comunicações novas, e não da comunicação original ou comunicações que continham o EINR e/ou o EIPR. Para que tais novas comunicações sejam usáveis, deveria ser verificado que estas são comunicações com a fonte original do EIPR e/ou EINR.
O pedido de patente americana publicada No. 20040243832, a totalidade da qual é incorporada a esta por referência, expõe diversos métodos para determinar que duas mensagens de rede foram originadas do mesmo remetente. Enquanto estes métodos se referem a mensagem mais propriamente que a elementos de informação ou comunicações, e a remetentes mais propriamente que a fontes originais, será apreciado por alguém habilitado na técnica que a maioria dos métodos descritos em tal pedido de patente americana são aplicáveis para detectar que dois elementos de informação foram enviados pela mesma fonte original.
Em uma concretização exemplar, pacotes ICMP e pacotes TCP/IP recebidos com o mesmo endereço de IP fonte ou enviados ao mesmo endereço de IP de destino poderiam ser considerados como comunicações com o mesmo dispositivo. Em outra concretização exemplar, os pacotes TCP/IP de entrada que pertencem a uma conexão TCP poderiam ser considerados como originários de um mesmo dispositivo.
Em outra concretização exemplar, uma resposta http enviada seguindo uma requisição http, de acordo com o protocolo http poderia ser considerada como comunicação com a fonte da requisição http.
O Sistema
A Fig. 3 descreve os componentes do Sistema de Detecção de Retransmissão 102, de acordo com uma concretização particular da presente invenção.
Um Receptor de Elemento de Informação 30 monitora as comunicações que o HM 110 recebe. Ele potencialmente monitora também comunicações que o HM 110 envia. Ele potencialmente monitora também comunicações que o Remetente de Comunicações de Saída 36 envia.
Um Analisador de Incompatibilidade de Características 34 determina se a Característica do DFI e a Característica do PDR são Características Incompatíveis.
Um Módulo de Descoberta de Características 32 opcional descobre a Característica do DFI e/ou a Característica do PDR.
Um Remetente de Comunicações de Saída 36 opcional envia uma ou mais Comunicações de Saída.
Um Obtenedor de Parâmetros 38 opcional obtém um ou mais parâmetros indicativos de: (a) Característica do DFI, (b) Característica do PDR e/ou (c) se a Característica do DFI e a Característica do PDR são Características Incompatíveis. Um Banco de Dados de Características 40 opcional contém uma lista de pares de características e se elas são Características Incompatíveis. Por exemplo, o Banco de Dados de Características 40 pode conter uma descrição de quais clientes HTML são suportados por cada sistema operacional.
Deve ser entendido que de acordo com algumas concretizações, a presente invenção fornece para uso qualquer combinação de características ou parâmetros expostos no presente documento úteis para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão e/ou para determinar se um elemento de informação recebido foi retransmitido por um dispositivo de retransmissão.
Em algumas concretizações descritas acima, a Característica do DFI e/ou Característica do PDR foram relacionadas à latência e/ou a taxa de comunicação. Será apreciado por alguém habilitado na técnica que estes são casos específicos de casos mais gerais, nos quais a Característica do DFI e/ou a Característica do PDR são relacionadas à performance de comunicação.
'Performance de Comunicação' é um termo geral que se refere a todos os parâmetros descrevendo a velocidade, taxa, tempo, eficiência, etc, de uma comunicação.
Na determinação de se duas características são Características Incompatíveis, o SDR 102 deveria considerar o tempo no qual cada uma das características foi descoberta. Por exemplo, se as duas características são configurações de relógio de parede iguais a 9:05 e 10:05. e a segunda característica foi descoberta exatamente uma hora depois da primeira, então as duas características não poderiam ser consideradas Características Incompatíveis, porque a diferença no tempo do descobrimento explica diretamente a diferença nas características. Entretanto, se as mesmas duas características foram descobertas aproximadamente ao mesmo tempo, elas poderiam ser consideradas Características Incompatíveis. Em outro exemplo, se uma característica é uma medição de TER de 900 milisegundos e a outra característica é um TER de 940 milisegundos, e a primeira característica foi descoberta 24 horas após a outra, então as características não são necessariamente Características Incompatíveis, porque mudanças na topologia de rede podem ser culpadas por esta diferença. Entretanto, se as mesmas duas características foram descobertas durante o mesmo período de 100 milisegundos, a probabilidade de uma mudança de topologia é menor, e conseqüentemente é mais provável que as características sejam Características Incompatíveis.
Se as características foram descobertas aproximadamente ao mesmo tempo, então o SDR 102 deveria considerar se tais características são improváveis de concorrentemente se relacionarem ao mesmo dispositivo.
Os numerosos ensinamentos inovadores da presente invenção são descritos com particular referência a uma concretização exposta presentemente. Entretanto, deveria ser entendido que esta classe de concretizações fornecem apenas poucos exemplos dos muitos usos vantajosos dos ensinamentos inovadores aqui descritos. Em geral, afirmações feitas nas especificações da presente invenção não necessariamente delimitam qualquer uma das variadas invenções reivindicadas. Além disso, algumas afirmações podem ser aplicadas a algumas características inventivas, mas não a outras.
Enquanto concretizações particulares da invenção foram demonstradas e descritas, será óbvio para aqueles hábeis na técnica que mudanças e modificações podem ser feitas sem se distanciar da invenção em seus aspectos mais amplos, e desta forma, o objetivo nas reivindicações apensas é cobrir todas as ditas mudanças e modificações que esteja dentro do verdadeiro espírito e extensão da invenção.
De acordo com algumas concretizações, o termo "improvável" como usado aqui se refere a uma probabilidade de até 40%.
Em outras concretizações, esta probabilidade é de até 30%.
Em outras concretizações, esta probabilidade é de até 20%.
Em outras concretizações, esta probabilidade é de até 10%.
Em outras concretizações, esta probabilidade é de até 5%.
Em outras concretizações, esta probabilidade é de até 1%.
Em outras concretizações, esta probabilidade é de até 1/2%.
Similarmente, um evento 'provável' é um evento que ocorre com uma probabilidade de 100% menos a probabilidade do evento 'improvável'.
De acordo com algumas concretizações, um 'único' dispositivo é fisicamente um dispositivo. Todavia, é reconhecido na técnica que dispositivos eletrônicos conectados a redes de dados tais como dispositivos de retransmissão, hosts monitorados e dispositivos fontes de informação são freqüentemente um agrupamento de diversos dispositivos físicos diferentes logicamente configurados para se apresentarem a uma rede de dados e/ou dispositivos em uma rede de dados como um 'único' dispositivo. Conseqüentemente, como usado aqui, um 'único' dispositivo se refere tanto a um único dispositivo físico, assim como a uma pluralidade de dispositivos físicos logicamente configurados para se apresentarem como um 'único' dispositivo.
De acordo com algumas concretizações, localidades 'diferentes' como usado na presente invenção, se referem a lugares localizados em países diferentes.
De acordo com algumas concretizações, localidades 'diferentes' como usado na presente invenção, se referem a lugares localizados em estados diferentes.
De acordo com algumas concretizações, localidades 'diferentes' como usado na presente invenção, se referem a lugares localizados em províncias diferentes.
De acordo com algumas concretizações, localidades 'diferentes' como usado na presente invenção, se referem a lugares localizados em continentes diferentes.
De acordo com algumas concretizações, localidades 'diferentes' como usado na presente invenção, se referem a lugares localizados em fusos horários diferentes.
De acordo com algumas concretizações, localidades 'diferentes' como usado na presente invenção, se referem a localidades separadas por um mínimo de 10 quilômetros, ou por um mínimo de 200 quilômetros, ou por um mínimo de 1000 quilômetros, ou por um mínimo de 2500 quilômetros.

Claims (50)

1. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão para o sistema reivindicado em 44 a 49 e programa reivindicado em 50 caracterizado por compreender: a. Receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do dito segundo elemento de informação; e b. Determinar se uma característica de uma fonte original do dito primeiro elemento de informação e uma característica do potencial dispositivo de retransmissão são características improváveis de relacionar a um único dispositivo, em que um resultado positivo de tal determinação é indicativa de que o potencial dispositivo de retransmissão é um dispositivo de retransmissão.
2. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 1 e ainda caracterizado por o dito segundo elemento de informação ser de um tipo que um dispositivo retransmissão de uma classe de dispositivos de retransmissão são improváveis de retransmitir.
3. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 2 e ainda caracterizado por a dita classe de dispositivos de retransmissão ser selecionada de um grupo consistindo em um proxy SOCKS, um proxy HTTP usando o método GET1 um proxy HTTP usando o método CONNECT, um router de IP e um dispositivo de Tradução de Endereços de Rede.
4. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 1 e ainda caracterizado por o dito segundo elemento de informação ser parte de uma comunicação, em que a comunicação é de um tipo selecionado do grupo consistindo em IP, TCP, ICMP, DNS, http, SMTP, TLS, e SSL.
5. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 1 e ainda caracterizado por o dito primeiro elemento de informação ser parte de uma comunicação, em que a comunicação é de um tipo selecionado do grupo consistindo em IP, TCP, ICMP, DNS1 http, SMTP, TLS, e SSL.
6. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 1 e ainda caracterizado por os ditos primeiro e segundo elementos de informação serem partes de uma única comunicação.
7. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 6 e ainda caracterizado por ditos primeiro e segundo elementos de informação serem enviados em duas camadas diferentes de um protocolo stack.
8. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 1 e ainda caracterizado por o dito estágio de determinação compreender: i) descobrir a dita característica de uma fonte original do dito primeiro elemento de informação; e ii) descobrir a dita característica do potencial dispositivo de retransmissão.
9. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 8 e ainda caracterizado por o dito estágio de determinação ainda compreender: iii) comparar a dita característica de uma fonte original do dito primeiro elemento de informação com a dita característica do potencial dispositivo de retransmissão.
10. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 8 e ainda caracterizado por ainda compreender: c) obter um parâmetro indicativo da dita característica de uma fonte original do dito primeiro elemento de informação; e d) obter um parâmetro indicativo da dita característica do potencial dispositivo de retransmissão.
11. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 8 e ainda caracterizado por o dito estágio de determinação ainda compreender: iii) considerar um tempo no qual foi descoberta ao menos uma característica de uma fonte original de primeiro elemento de informação e uma característica do potencial dispositivo de retransmissão.
12. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 1 e ainda caracterizado por ainda compreender: c) obter um parâmetro indicativo de uma relação entre a dita característica da fonte original do primeiro elemento de informação e a dita característica do potencial dispositivo de retransmissão.
13. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 12 e ainda caracterizado por o dito estágio de determinação incluir analisar o dito parâmetro indicativo de uma relação entre a dita característica da fonte original do primeiro elemento de informação e a dita característica do potencial dispositivo de retransmissão.
14. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 12 e ainda caracterizado por o dito parâmetro ser obtido de ao menos um do dito primeiro elemento de informação e dito segundo elemento de informação.
15. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 1 e ainda caracterizado por ainda compreender: c) enviar uma comunicação de saída para ao menos uma da dita fonte original do primeiro elemento de informação e o potencial dispositivo de retransmissão; e d) receber um terceiro elemento de informação de ao menos uma dita fonte original do primeiro elemento de informação e o potencial dispositivo de retransmissão.
16. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 15 e ainda caracterizado por ainda incluir: e) derivar do dito terceiro elemento de informação relacionada a uma característica de ao menos uma da dita fonte original do primeiro elemento de informação e o potencial dispositivo de retransmissão.
17. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 15 e ainda caracterizado por ainda compreender: iii) verificar que uma fonte original do dito terceiro elemento de informação é a dita fonte original do dito primeiro elemento de informação
18. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 15 e ainda caracterizado por ainda compreender: iii) verificar que uma fonte original do dito terceiro elemento de informação é o potencial dispositivo de retransmissão.
19. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 15 e ainda caracterizado por o dito terceiro elemento de informação ser selecionado do grupo consistindo de uma mensagem ICMP, uma mensagem ICMP Echo Reply, um query DNS, um request http, uma resposta http, um "Server" header http, um endereço de IP, uma porta TCP, uma seqüência numérica inicial TCP, um TCP Inicial Window, um WHOIS Record, e um reverse DNS Record.
20. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 1 e ainda caracterizado por ao menos uma da dita característica de uma fonte original do dito primeiro elemento de informação e dita característica do potencial dispositivo de retransmissão ser uma característica relacionada a um status de configuração.
21. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 20 e ainda caracterizado por dita característica relacionada a um status de configuração ser selecionada do grupo consistindo de um tipo de sistema de operação, uma versão de sistema de operação, um tipo de software, um tipo de cliente http, um tipo de servidor http, tipo de cliente SMTP, um tipo de servidor SMTP, um time setting, um clock setting e um time zone setting.
22. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 21 e ainda caracterizado por dita determinação incluir examinar o parâmetro indicativo da dita característica relacionada a um status de configuração.
23. Método para determinar se um potencial dispositivo de retransmissão ser um dispositivo de retransmissão como reivindicado em 21 e ainda caracterizado por o dito parâmetro ser selecionado do grupo consistindo em um http 'User-Agent' header, um RFC 822 'X- Mailer' header, um RFC 822 'Received' header, um RFC 822 'date' header, um protocol implementation manner, um TCP/IP stack fingerprint, um endereço de IP, uma porta TCP, uma seqüência numérica inicial TCP e uma janela inicial de TCP.
24. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 1 e ainda caracterizado por ao menos uma da dita característica de uma fonte do dito primeiro elemento de informação e dita característica do potencial dispositivo de retransmissão ser uma característica relacionada à performance de comunicação.
25. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 24 e ainda caracterizado por dita característica relacionada à performance de comunicação ser selecionada do grupo consistindo em uma performance de comunicação medida, uma relativa performance de comunicação medida e uma performance de comunicação estimada.
26. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 24 e ainda caracterizado por dita característica relacionada à performance de comunicação ser selecionada do grupo consistindo em uma latência de comunicação, latência de uma comunicação de entrada, uma latência de uma comunicação de saída, um tempo de circulação da comunicação, uma taxa de comunicação, uma taxa de comunicação de entrada, uma taxa de comunicação de saída, uma taxa máxima de comunicação, uma taxa máxima de comunicação de entrada e uma taxa máxima de comunicação de saída.
27. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 24 e ainda caracterizado por dita determinação incluir examinar um parâmetro indicativo da dita característica relacionada a uma performance de comunicação.
28. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 27 e ainda caracterizado por dito parâmetro ser selecionado de um grupo consistindo de tempo de recebimento de um elemento de informação, tempo de envio de um elemento de informação, tempo de envio e recebimento, espaço de tempo de envio e recebimento, um endereço de IP, um Whois Record1 um reverse DNS Record, e uma taxa de informação conhecida.
29. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 28 e ainda caracterizado por um espaço maior de tempo de envio e recebimento ser indicativo de uma grande probabilidade de que um dispositivo de retransmissão está sendo usado para propósitos maliciosos.
30. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 24 e ainda caracterizado por dita característica relacionada à performance de comunicação ser estimada pela informação sobre ao menos uma da dita fonte original da dita primeira comunicação e o potencial dispositivo de retransmissão.
31. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 30 e ainda caracterizado por dita informação sobre, ao menos uma, da dita fonte original da dita primeira comunicação e o potencial dispositivo de retransmissão ser selecionada do grupo consistindo de uma locação de um dispositivo, um hostname de um dispositivo e um administrador de dispositivo.
32. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 1 e ainda caracterizado por ao menos uma da dita fonte original do dito primeiro elemento de informação e o potencial dispositivo de retransmissão ser selecionado do grupo consistindo de uma sub-rede, um administrador, e uma locação.
33. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 32 e ainda caracterizado por dita determinação incluir examinar um parâmetro indicativo de ao menos uma da dita característica de uma fonte da dita primeira comunicação e dita característica de uma fonte da dita segunda comunicação, e dito parâmetro ser selecionado do grupo consistindo de http "User-Agent" header, um RFC 822 'X- Mailer' header, um RFC 822 'Received' header, um RFC 822 'date' header, um endereço de IP, um Whois Record e um reverse DNS Record.
34. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão caracterizado por compreender: a) Receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do dito segundo elemento de informação; e b) Analisar um status de configuração de uma fonte original de ao menos um do dito primeiro e dito segundo elementos de informação, dito status de configuração selecionado de um grupo consistindo de um tipo de sistema de operação, uma versão de sistema de operação, um tipo de software, um tipo de cliente http, um tipo de servidor http, tipo de cliente SMTP, um tipo de servidor SMTP, um time setting, um clock setting e um time zone setting.
35. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão caracterizado por compreender: a) Receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão ser uma fonte original do dito segundo elemento de informação; e b) Analisar uma característica relacionada à performance de comunicação de uma fonte original de ao menos uma do dito primeiro e dito segundo elementos de informação.
36. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 35 e ainda caracterizado por dita característica relacionada à performance de comunicação ser selecionada do grupo consistindo em uma latência de comunicação, latência de uma comunicação de entrada, uma latência de uma comunicação de saída, um tempo de circulação da comunicação, uma taxa de comunicação, uma taxa de comunicação de entrada, uma taxa de comunicação de saída, uma taxa máxima de comunicação, uma taxa máxima de comunicação de entrada e uma taxa máxima de comunicação de saída.
37. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão caracterizado por compreender: a) enviar uma mensagem para um dispositivo de fonte de informação, disparando dito dispositivo de fonte de informação para enviar um DNS request; b) determinar do dito DNS request se o dito potencial dispositivo de retransmissão é um dispositivo de retransmissão.
38. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão caracterizado por compreender: a) receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão; e b) determinar se uma característica de uma fonte original do dito primeiro elemento de informação e uma característica de uma fonte original do dito segundo elemento de informação são características improváveis de relacionar a um único dispositivo. em que um resultado positivo de dita determinação é indicativo de que o potencial dispositivo de retransmissão é um dispositivo de retransmissão.
39. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão caracterizado por compreender: a) receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do dito segundo elemento de informação; e c) checar se o tempo de envio e recebimento para o potencial dispositivo de retransmissão é significantemente diferente que o tempo de envio e recebimento para uma fonte original do dito primeiro elemento de informação.
40. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão caracterizado por compreender: a) receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do dito segundo elemento de informação; e b) checar se um sistema de operação do potencial dispositivo de retransmissão é diferente de um sistema de operação de uma fonte original do dito primeiro elemento de informação.
41. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão caracterizado por compreender: a) receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do dito segundo elemento de informação; e b) checar se uma locação do potencial dispositivo de retransmissão é diferente de uma locação de uma fonte original do dito primeiro elemento de informação.
42. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão caracterizado por compreender: a) receber primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do dito segundo elemento de informação; e b) checar se um administrador do potencial dispositivo de retransmissão é diferente de um administrador de uma fonte original do dito primeiro elemento de informação.
43. Método para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão caracterizado por compreender: a) determinar se uma característica de uma fonte original de um primeiro elemento de informação e uma característica do potencial dispositivo de retransmissão são características improváveis para relacionar a um único dispositivo, em que o potencial dispositivo de retransmissão é um transmissor do dito primeiro elemento de informação e do dito segundo elemento de informação, em que o potencial dispositivo de retransmissão é uma fonte original do dito segundo elemento de informação em que um resultado positivo de dita determinação é indicativo de que o potencial dispositivo de retransmissão é um dispositivo relé.
44. Sistema para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão para o método reivindicado de 1 a 43 e programa reivindicado em 50 caracterizado por compreender: a) um receptor de elemento de informação, para receber elementos de informação de uma pluralidade de dispositivos incluindo um dispositivo de fonte de informações e o potencial dispositivo de retransmissão; e b) um analisador de incompatibilidade de características, para determinar se uma característica de dito dispositivo de fonte de informações e uma característica do potencial dispositivo de retransmissão são características improváveis de relacionar a um único dispositivo.
45. Sistema para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 44 e ainda caracterizado por compreender: c) um modulo de descoberta de características, para descobrir ao menos uma característica selecionada do grupo consistindo de uma característica de dito dispositivo de fonte de informações e uma característica do potencial dispositivo de retransmissão.
46. Sistema para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 44 e ainda caracterizado por dito receptor de elemento de informação ser ainda configurado para receber elementos de informação de um host monitorado.
47. Sistema para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 44 e ainda caracterizado por anda compreender: c) um remetente de elementos de informação de saída.
48. Sistema para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 44 e ainda caracterizado por ainda compreender: b) um obtenedor de parâmetros, para obter ao menos um parâmetro selecionado do grupo consistindo de um parâmetro indicativo de uma característica de um dispositivo de fonte de informação, um parâmetro indicativo de uma característica do potencial dispositivo de retransmissão, e um parâmetro indicativo de se uma característica de dito dispositivo de fonte de informação e uma característica de dito potencial dispositivo de retransmissão são características improváveis de relacionar a um único dispositivo.
49. Sistema para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão como reivindicado em 44 e ainda caracterizado por ainda compreender: c) um banco de dados de características para armazenar um mapa entre pares de características e dados indicativos de se ditos pares de características são características incompatíveis.
50. Programa de computador residente em um meio de armazenamento interpretável por computador para o método reivindicado de 1 a 43 e sistema reivindicado em 44 a 49 caracterizado por compreender instruções para fazer com que um computador: a) receba primeiro e segundo elementos de informação do potencial dispositivo de retransmissão, em que o potencial dispositivo de retransmissão é uma fonte original do dito segundo elemento de informação; e b) determine se uma característica de uma fonte original do dito primeiro elemento de informação e uma característica do dito potencial dispositivo de retransmissão são características improváveis para relacionar a um único dispositivo, em que um resultado positivo de dita determinação é indicativo de que o potencial dispositivo de retransmissão é um dispositivo relé.
BRPI0506963-7A 2004-01-09 2005-01-09 método, sistema e programa para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão BRPI0506963A2 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US53492704P 2004-01-09 2004-01-09
US60/534,927 2004-01-09
PCT/IL2005/000033 WO2005065038A2 (en) 2004-01-09 2005-01-09 Detecting relayed communications

Publications (1)

Publication Number Publication Date
BRPI0506963A2 true BRPI0506963A2 (pt) 2011-11-16

Family

ID=34749015

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0506963-7A BRPI0506963A2 (pt) 2004-01-09 2005-01-09 método, sistema e programa para determinar se um potencial dispositivo de retransmissão é um dispositivo de retransmissão

Country Status (9)

Country Link
US (4) US8966088B2 (pt)
EP (1) EP1702429B1 (pt)
JP (1) JP4596275B2 (pt)
CN (1) CN1965309B (pt)
AU (1) AU2005203856B2 (pt)
BR (1) BRPI0506963A2 (pt)
CA (1) CA2552481C (pt)
IL (2) IL176697A (pt)
WO (1) WO2005065038A2 (pt)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005065038A2 (en) * 2004-01-09 2005-07-21 Npx Technologies Ltd. Detecting relayed communications
US8782393B1 (en) 2006-03-23 2014-07-15 F5 Networks, Inc. Accessing SSL connection data by a third-party
US20070250441A1 (en) 2006-04-25 2007-10-25 Uc Group Limited Systems and methods for determining regulations governing financial transactions conducted over a network
US8301703B2 (en) * 2006-06-28 2012-10-30 International Business Machines Corporation Systems and methods for alerting administrators about suspect communications
JP4731428B2 (ja) * 2006-08-28 2011-07-27 セコム株式会社 監視装置、及び受信装置
US9326138B2 (en) 2006-09-06 2016-04-26 Devicescape Software, Inc. Systems and methods for determining location over a network
US8743778B2 (en) 2006-09-06 2014-06-03 Devicescape Software, Inc. Systems and methods for obtaining network credentials
US8000283B2 (en) * 2007-03-07 2011-08-16 Motorola Solutions, Inc. Method and apparatus for relay station neighbor discovery
US20090284600A1 (en) * 2008-05-14 2009-11-19 Chuan Wang Remote-control door viewer surveillance system
US20100263022A1 (en) * 2008-10-13 2010-10-14 Devicescape Software, Inc. Systems and Methods for Enhanced Smartclient Support
US20100106611A1 (en) * 2008-10-24 2010-04-29 Uc Group Ltd. Financial transactions systems and methods
US8489732B1 (en) * 2009-08-07 2013-07-16 Google Inc. System and method of using spatial and temporal signals to identify and prevent attacks
US8255393B1 (en) 2009-08-07 2012-08-28 Google Inc. User location reputation system
KR101167938B1 (ko) * 2009-09-22 2012-08-03 엘지전자 주식회사 컨텐츠에 대한 권리 이용 방법
JP5508042B2 (ja) * 2010-01-20 2014-05-28 克佳 長嶋 Ipアクセスログ解析装置およびその方法
US8700892B2 (en) 2010-03-19 2014-04-15 F5 Networks, Inc. Proxy SSL authentication in split SSL for client-side proxy agent resources with content insertion
US8407341B2 (en) * 2010-07-09 2013-03-26 Bank Of America Corporation Monitoring communications
EP2676399A4 (en) 2011-02-14 2016-02-17 Devicescape Software Inc SYSTEMS AND METHODS FOR NETWORK CARE
US20120272314A1 (en) * 2011-04-21 2012-10-25 Cybyl Technologies, Inc. Data collection system
WO2012166944A2 (en) 2011-06-03 2012-12-06 Uc Group Limited Systems and methods for registration, validation, and monitoring of users over multiple websites
US20120317172A1 (en) * 2011-06-13 2012-12-13 International Business Machines Corporation Mobile web app infrastructure
CN103024091B (zh) * 2011-09-26 2016-05-25 阿里巴巴集团控股有限公司 获得网络客户端真实物理地址的方法及装置
US10212062B2 (en) * 2012-10-09 2019-02-19 Assia Spe, Llc Method and system for latency measurement in communication systems
WO2014207262A1 (es) * 2013-06-24 2014-12-31 Telefonica Digital España, S.L.U. Un método para comunicaciones seguras a través de redes diferentes usando el protocolo socks
EP2819379A1 (en) 2013-06-28 2014-12-31 Thomson Licensing Method for adapting the downloading behavior of a client terminal configured to receive multimedia content, and corresponding terminal
KR101548210B1 (ko) * 2014-01-06 2015-08-31 고려대학교 산학협력단 왕복 시간 변화를 이용하여 익명 네트워크를 통한 우회 접속을 탐지하는 방법
CN104767837B (zh) * 2014-01-08 2018-08-24 阿里巴巴集团控股有限公司 一种识别代理ip地址的方法及装置
US9628512B2 (en) * 2014-03-11 2017-04-18 Vectra Networks, Inc. Malicious relay detection on networks
CN105338126B (zh) 2014-07-17 2018-10-23 阿里巴巴集团控股有限公司 远程查询信息的方法及服务器
US9721253B2 (en) 2015-05-06 2017-08-01 Forter Ltd. Gating decision system and methods for determining whether to allow material implications to result from online activities
CN107222503B (zh) * 2017-07-10 2020-08-11 北京知道未来信息技术有限公司 一种探测流加密代理服务器的方法
US10789301B1 (en) * 2017-07-12 2020-09-29 Groupon, Inc. Method, apparatus, and computer program product for inferring device rendered object interaction behavior
CN110022334B (zh) * 2018-01-09 2022-01-11 香港理工大学深圳研究院 一种代理服务器的检测方法、检测装置及终端设备
CN110710158B (zh) * 2018-05-07 2022-08-09 谷歌有限责任公司 验证与数字助理应用交接的代理的操作状态
CN110839017B (zh) * 2019-10-21 2022-02-08 腾讯科技(深圳)有限公司 代理ip地址识别方法、装置、电子设备及存储介质
CN110830454B (zh) * 2019-10-22 2020-11-17 远江盛邦(北京)网络安全科技股份有限公司 基于alg协议实现tcp协议栈信息泄露的安防设备检测方法
CN112787975B (zh) * 2019-11-05 2022-06-10 华为技术有限公司 一种接入设备类型确定方法、设备及系统
US20230067897A1 (en) * 2021-08-25 2023-03-02 Paypal, Inc. Automatic detection of proxy-based phishing sites
CN114143807B (zh) * 2021-10-27 2023-08-08 中盈优创资讯科技有限公司 一种路由注册完整率评价方法及装置
US11888730B1 (en) 2022-09-20 2024-01-30 Block, Inc. Dynamically optimizing routing within a decentralized network

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5892903A (en) * 1996-09-12 1999-04-06 Internet Security Systems, Inc. Method and apparatus for detecting and identifying security vulnerabilities in an open network computer communication system
US20020007411A1 (en) 1998-08-10 2002-01-17 Shvat Shaked Automatic network user identification
US6452915B1 (en) 1998-07-10 2002-09-17 Malibu Networks, Inc. IP-flow classification in a wireless point to multi-point (PTMP) transmission system
US6496824B1 (en) * 1999-02-19 2002-12-17 Saar Wilf Session management over a stateless protocol
EP1035708B1 (en) * 1999-03-05 2007-01-17 International Business Machines Corporation Method and system for optimally selecting a web firewall in a TCP/IP network
US6832253B1 (en) * 1999-04-01 2004-12-14 Cisco Technologies, Inc. Proximity as an aid to caching and secondary serving of data
US6757740B1 (en) 1999-05-03 2004-06-29 Digital Envoy, Inc. Systems and methods for determining collecting and using geographic locations of internet users
US6519568B1 (en) * 1999-06-15 2003-02-11 Schlumberger Technology Corporation System and method for electronic data delivery
WO2001038999A1 (en) 1999-11-23 2001-05-31 Escom Corporation Electronic message filter having a whitelist database and a quarantining mechanism
CN1158612C (zh) * 1999-12-16 2004-07-21 华为技术有限公司 用于帧中继网络和异步传输模式网络互通的方法以及装置
US6684250B2 (en) 2000-04-03 2004-01-27 Quova, Inc. Method and apparatus for estimating a geographic location of a networked entity
US7200673B1 (en) * 2000-06-09 2007-04-03 Steven Augart Determining the geographic location of a network device
US20020016831A1 (en) 2000-08-07 2002-02-07 Vidius Inc. Apparatus and method for locating of an internet user
US20020032793A1 (en) 2000-09-08 2002-03-14 The Regents Of The University Of Michigan Method and system for reconstructing a path taken by undesirable network traffic through a computer network from a source of the traffic
US20030026268A1 (en) * 2000-11-28 2003-02-06 Siemens Technology-To-Business Center, Llc Characteristic routing
US7305461B2 (en) 2000-12-15 2007-12-04 International Business Machines Corporation Method and system for network management with backup status gathering
US7360245B1 (en) * 2001-07-18 2008-04-15 Novell, Inc. Method and system for filtering spoofed packets in a network
US6907525B2 (en) * 2001-08-14 2005-06-14 Riverhead Networks Inc. Protecting against spoofed DNS messages
US7171683B2 (en) * 2001-08-30 2007-01-30 Riverhead Networks Inc. Protecting against distributed denial of service attacks
US20050097049A1 (en) * 2001-08-15 2005-05-05 Shea Writer Methods for verifying cardholder authenticity and for creating billing address database
JP2003099381A (ja) 2001-09-21 2003-04-04 Kddi Corp メール発信用リンクを含むページを送信するwwwサーバ及びプログラム
CN1666205A (zh) 2001-10-17 2005-09-07 Npx科技有限公司 在线接收的个人标识的验证
FI116017B (fi) 2002-01-22 2005-08-31 Netseal Mobility Technologies Menetelmä viestien lähettämiseksi turvallisten mobiiliviestintäyhteyksien läpi
US7310356B2 (en) * 2002-06-24 2007-12-18 Paradyne Corporation Automatic discovery of network core type
US7444428B1 (en) * 2002-08-26 2008-10-28 Netapp, Inc. Method and apparatus for estimating relative network proximity in the presence of a network filter
AU2003284503A1 (en) * 2002-11-29 2004-06-23 Freebit Co., Ltd. Server for routing connection to client device
WO2005065038A2 (en) 2004-01-09 2005-07-21 Npx Technologies Ltd. Detecting relayed communications
WO2005086681A2 (en) * 2004-03-04 2005-09-22 Quova, Inc. Geo-location and geo-compliance utilizing a client agent
JP4027378B2 (ja) 2005-04-26 2007-12-26 キヤノン株式会社 無線通信装置および無線通信方法

Also Published As

Publication number Publication date
US11522827B2 (en) 2022-12-06
EP1702429A2 (en) 2006-09-20
EP1702429A4 (en) 2011-08-03
CN1965309B (zh) 2010-11-17
AU2005203856B2 (en) 2009-07-30
JP4596275B2 (ja) 2010-12-08
JP2008527761A (ja) 2008-07-24
IL237152B (en) 2018-02-28
CA2552481A1 (en) 2005-07-21
WO2005065038A3 (en) 2006-11-16
US8966088B2 (en) 2015-02-24
EP1702429B1 (en) 2017-05-10
US10122683B2 (en) 2018-11-06
US20190182210A1 (en) 2019-06-13
WO2005065038A2 (en) 2005-07-21
US10798055B2 (en) 2020-10-06
IL176697A (en) 2015-02-26
US20090144408A1 (en) 2009-06-04
US20210126899A1 (en) 2021-04-29
AU2005203856A1 (en) 2005-07-21
IL176697A0 (en) 2006-10-31
CA2552481C (en) 2016-08-02
CN1965309A (zh) 2007-05-16
US20150172253A1 (en) 2015-06-18

Similar Documents

Publication Publication Date Title
US11522827B2 (en) Detecting relayed communications
Brandt et al. Domain validation++ for mitm-resilient pki
JP5377562B2 (ja) 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
Alotaibi et al. Security issues in protocols of TCP/IP model at layers level
JP5374536B2 (ja) 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
Jin et al. A detour strategy for visiting phishing URLs based on dynamic DNS response policy zone
Mogul Using screend to implement IP/TCP security policies
KR101053747B1 (ko) Bgp 네트워크의 보안 방법 및 이를 위한 라우터
Dai Internet-Wide Evaluations of Security and Vulnerabilities
Mateti Security issues in the TCP/IP suite
Bisen et al. Countermeasure tool-Carapace for Network Security
Suzuki et al. A scheme of secret communication using Internet control message protocol
Tools et al. Network Troubleshooting
Natale TCP/IP and security software applications
Neiman Hash stamp marking scheme for packet traceback
Casey Digital Evidence at the Network and Transport Layers
Wang The design and implementation of a social accountability framework
Fahmy et al. Balancing Privacy and Fidelity in Packet Traces for Security Evaluation
Mogul NSL Technical Note TN-2

Legal Events

Date Code Title Description
B07A Application suspended after technical examination (opinion) [chapter 7.1 patent gazette]
B09B Patent application refused [chapter 9.2 patent gazette]
B09B Patent application refused [chapter 9.2 patent gazette]