IDSs de Larga-Escala

Podemos afirmar que os sistemas de detecção de intrusão convencionais não são estruturados para a troca de informações de segurança entre diferentes organizações. Estas informações normalmente são mantidas restritas ao escopo da organização onde foram coletadas. Contudo, como se pode per- ceber pela análise da literatura, uma tendência na detecção e intrusão é o uso de IDSs de larga escala que fazem a correlação de informações provenientes de múltiplas origens na Internet.

Exemplos bem conhecidos desses sistemas são o DShield.org7 (Distributed Intrusion Detection

System) e o myNetWatchman8. Essas duas iniciativas disponibilizam agentes de coleta (sensores)

que são instalados em firewalls, roteadores ou outros dispositivos de filtragem e controle de acesso. Os dados coletados são enviados a um gerenciador centralizado para a correlação e análise. Como resultado, são disponibilizados alertas e estatísticas que irão auxiliar na prevenção de ataques.

Infelizmente, tais mecanismos de correlação possuem os inconvenientes relacionados à centra- lização da análise e os IDSs correspondentes não utilizam formatos e protocolos padronizados de comunicação, restringindo o uso mais amplo de sensores. Também não é possível a cooperação ou o compartilhamento direto de informações entre as organizações envolvidas na coleta dos dados.

O IDF (Intrusion Detection Force) [Teo et al., 2003] é um dos poucos trabalhos nesta área que propõe mecanismos para a troca de informações sobre incidentes de segurança entre organizações por meio da Internet. O artigo sugere um sistema de detecção de intrusão em escala global para a internet, que seria uma infra-estrutura virtual sobre a Internet atual, que possibilitaria a troca de informações de segurança, análise inteligente de dados e resposta a intrusões. O principal objetivo seria defender as organizações e proteger a Internet como um todo.

Segundo os autores da proposta do IDF, a arquitetura escolhida para o sistema é um modelo hí- brido entre a hierárquica e a totalmente distribuída, combinando as vantagens de ambos os modelos. Sendo assim, foi decidido por uma hierarquia com dois níveis com apenas dois tipos de entidades a serem implementadas: os “nodos” e “supernodos”. O nodo corresponde ao primeiro nível da hierar- quia, enquanto os supernodos estão no segundo nível, conforme ilustrado na Figura 3.10.

Cada nodo do IDF é um IDS completo que coleta dados e os analisa, além de implementar meca- nismos de respostas no sistema ao qual está associado. Nodos próximos são agrupados em conjuntos

7_{http://www.dshield.org}

chamados “coletivos”. Os coletivos permitem a redundância para suportar a segurança e survivabi- lity. Para isso, os dados obtidos em um nodo são replicados aos demais nodos do coletivo. O nodo também funciona como sensor, compartilhando informações com os supernodos que realizam a cor- relação e análise das informações obtidas. Um único nodo “eleito” do coletivo fica responsável pela comunicação com os supernodos. Se ele falhar, outro do coletivo o substitui dinamicamente. Os supernodos também são agrupados formando um “supercoletivo” que compartilha informações com outros supercoletivos. A área sob autoridade de um supercoletivo é chamada de zona, que facilita o gerenciamento e administração, além de escalabilidade.

Coletivo A1 Nodo Nodo Nodo Nodo Coletivo A1 Nodo Nodo Nodo Nodo Coletivo A1 Nodo Nodo Nodo Nodo Coletivo A1 Nodo Nodo Nodo Nodo Coletivo Supernodo B Supernodo Supernodo Supernodo Supernodo Coletivo Supernodo A Supernodo Supernodo Supernodo Supernodo Zona A Zona B Sensores Sensores Analisadores Analisadores

Figura 3.10: Entidades na arquitetura IDF

Dentro do modelo de detecção de intrusão distribuída, os nodos agem como sensores e os super- nodos como analisadores. O IDF não define como os elementos serão gerenciados.

Não há informações sobre o protocolo de comunicação entre os nós ou o formato das mensagens que são transmitidas. Também não são mencionados mecanismos de segurança para autenticação dos elementos ou troca de mensagens. Não há outras referências sobre o IDF e aparentemente o projeto está parado. Porém, as idéias apresentadas, sobretudo a arquitetura escalar, permitem pensar em sistemas de detecção de intrusão e gerenciamento interorganizacionais mais restritos, ao invés de sistemas em escala global, nos quais haja menos restrições de segurança e a infra-estrutura necessária seja mais modesta.

Outro IDS de larga-escala é proposto pelo projeto DOMINO [Yegneswaran et al., 2004]. O ob- jetivo do DOMINO é construir uma infra-estrutura para detecção de intrusão e resposta global dis- tribuída por meio da combinação de dados provenientes de origens distintas. Os dados coletados são compartilhados com a finalidade de prevenir ataques de worms, criando uma “lista negra” de endereços que potencialmente podem ser usados em ataques.

A arquitetura do DOMINO, ilustrada na Figura 3.11, é composta de elementos analisadores (Axis) que fazem o cruzamento e correlação de dados provenientes de uma hierarquia de sensores

(Satellites) ou de outros dispositivos (Terrestrial Nodes), como firewalls e IDSs de rede. Os sensores Sattellites são honey-pots para atrair e monitorar o tráfego malicioso (scans) destinado a endereços não utilizados na rede.

A A A A A Saída de Dados Entrada de Dados TERRESTRIAL NODES FIREWALLS EXTERNOS Nós AXIS DOMINO Satellites Pontos de acesso DOMINO Sensores Sensores Sensores Analisadores

Figura 3.11: Organização dos nós DOMINO em uma rede overlay peer-to-peer

Os Axis formam uma rede overlay peer-to-peer que utilizam mecanismos de comunicação seguros para a troca de informações entre si. Esses mecanismos incluem a autenticação mútua, além da criptografia e a assinatura de mensagens.

Segundo os autores, o mecanismo de compartilhamento de dados (alertas) é baseado em um “espaço de tuplas único e acessível a todos” (flat tuple space). Porém não são dados detalhes do mesmo ou de como é formada a rede overlay. Também não há menção sobre a segurança destes espaços de tuplas.

No DOMINO, os sensores e analisadores são disponibilizados e gerenciados apenas pelos admi- nistradores das redes aos quais estão conectados. Estes elementos podem ser configurados, atualiza- dos e inquiridos usando mensagens específicas. Não é definido um elemento específico de gerencia- mento.

As mensagens do DOMINO são formatadas em XML usando uma extensão do formato IDMEF (ver seção 3.3.2). Esta extensão inclui novos tipos de mensagens e alterações na classificação dos alertas, que não são totalmente compatíveis com a especificação do IDMEF.