Resumo

O presente trabalho tem por finalidade mostrar quais são os protocolos abertos existentes para troca de informações entre componentes de uma arquitetura IDS¹ e como eles funcionam. Estes protocolos são considerados abertos por não estarem vinculados a fabricantes de hardware e software e sim a grupos autônomos que procuram uma padronização onde seja possível a cooperação entre diversos produtos, independentemente de fabricante.

¹IDS: "Técnicas de detecção de intrusos em um computador ou redes de computadores"[10]

1. Introdução

Quanto mais crescem os ataques aos computadores mais se justifica a utilização da tecnologia IDS (Intrusion Detection System) [09], uma vez que a proteção das redes baseadas em Firewall² não consegue detectar ataques embutidos nos protocolos de aplicação ou ataques de rede, como os DoS³. No caso de grandes redes corporativas, com várias redes locais geograficamente distribuídas, a proteção baseada em Firewall não detecta os ataques oriundos da própria rede interna [01].

² Firewall: "Um sistema ou a combinação de sistemas que reforçam a segurança entre uma ou mais redes."[12]

³ DoS: "Ações que impedem que um sistema de computador execute suas tarefas".[10]

Além disto, existe um problema associado à implementação e ao uso de detecção de intrusos e vulnerabilidades em grandes redes de computadores, que é a integração entre os analisadores, uma vez que analisadores de fabricantes diferentes não conseguem trocar informações. Quando as redes remotas são independentes, a administração centralizada se torna difícil, pois nem sempre os produtos de IDS que estão sendo utilizados são os mesmos.

Para proporcionar esta portabilidade entre os componentes de uma arquitetura IDS, surgiu um grupo de pesquisadores do IETF (Internet Engineering Task Force) que juntamente com os pesquisadores do DARPA-IE criaram um conjunto de protocolos chamado de IDP(Intrusion Detection Protocol) para a troca de informações entre componentes IDS. Este grupo de trabalho foi denominado IDWG (Intrusion Detection Working Group).

2. Características do IDWG

No desejo de definir tal protocolo, este grupo de trabalho criou um conjunto de especificações que são detalhadas nos próximos capítulos e cujas principais características estão descritas a seguir.

* Transmissões confiáveis: o protocolo que possibilita o envio de mensagens entre componentes de IDS deve ser confiável, especialmente se a rede está instalada em um ambiente hostil. Transmissões desta natureza são desejáveis para evitar a duplicação de mensagens. Tendo isto como objetivo, o grupo IDWG especifica que a plataforma IDP está baseada no protocolo TCP (Transmission Control Protocol), pois o mesmo já é amplamente utilizado, conhecido e confiável;

* Autenticação mútua: cada uma das partes envolvidas na troca de informações entre componentes IDS deve estar devidamente autenticada, possibilitando, com isto, que a qualquer momento a identidade dos componentes envolvidos na troca de informações possa ser verificada. Isto se faz necessário para evitar que alguém possa se fazer passar por um analisador IDS;

* Integridade e confidencialidade: a integridade é necessária para que nenhum outro processo possa modificar o conteúdo das informações que estão sendo transportadas pela rede. A confidencialidade serve para impedir que alguém possa analisar o conteúdo que está sendo transmitido;

* Resistir a Ataques DoS: todo mecanismo de IDS é um alvo para as pessoas que tentam atacar os recursos de uma rede. Os protocolos especificados pelo IDWG estão sendo projetados para rejeitar o mais rápido possível qualquer conexão não conhecida, tendo a possibilidade de mudar seu comportamento quando atacado;

* Aumento na segurança: a intenção dos protocolos IDP é aumentar a segurança, portanto eles foram projetados para operar através de Firewalls sem comprometer a segurança da rede. Isto se dá através de uma conexão extremamente segura entre os componentes.

3. Especificações IDWG

3.1. Formato para Troca de Mensagens em Detecção de Intrusos

O modelo de dados IDMEF (Intrusion Detection Message Exchange Format)[03] é uma representação de alertas orientada a objetos. Com ele consegue-se um padrão na especificação de alertas, permitindo o relacionamento entre ambientes de pouca ou grande complexidade.

O modelo IDMEF tem as seguintes características:

* Heterogeneidade: as informações associadas aos vários tipos de alertas são bastante heterogêneas. Alguns desses alertas são representados através de um pequeno conjunto de informações, tais como: endereço IP de origem, endereço IP de destino, nome do evento e data da ocorrência. Outros provêem muitas informações adicionais, tais como: portas de serviços, aplicações e processos envolvidos, informações sobre usuários, etc. Por ser orientado a objetos o modelo IDMEF consegue representar estas características através das funcionalidades de agregação e subclasses;

*Ambientes Distintos: alguns analisadores detectam ataques verificando o tráfego de informações nas redes enquanto outros usam os logs gerados pelos sistemas operacionais. Alertas de um mesmo ataque cuja fonte de informação é diferente, fornecem dados diferentes. O modelo IDMEF define classes que suportam diferentes dados de um mesmo ataque. Em particular as noções de origem e destino de um alerta são representadas por uma combinação de Nó, Processo, Serviço e classe de Usuário;

* Compatibilidade entre Analisadores: analisadores podem ser instalados para prover um conjunto pequeno de informações ou, quando instalados na sua versão completa, fornecem várias informações adicionais. Para isto é disponibilizado um conjunto de conversores de formatos que serão utilizados pelos analisadores para fornecer aos gerentes informações padronizadas. Para definir estas extensões ao esquema básico, o IDMEF define alertas de dois tipos: simples e complexos. Para prover tais características, são usadas as técnicas de associação e subclasses;

* Análise Diferente: Dependendo do ambiente no qual o analisador está inserido, ataques podem ser observados e reportados de maneiras diferentes. O modelo especificado flexibiliza estas diferenças através de subclasses que são definidas com atributos adicionais que podem compatibilizar os dados enviados para a plataforma de gerenciamento de rede.

3.2. Protocolo BEEP 

O protocolo genérico BEEP (Blocks Extensible Exchange Protocol)[11] é formado por um conjunto de frameworks que foram desenvolvidos para servir de base para que as aplicações possam trocar informações. Ele possibilita a troca de informações através de conexões permanentes, assíncronas e confiáveis. Suas principais características são detalhadas a seguir. 

3.2.1. Delimitação de Mensagens

O protocolo BEEP usa uma variação do método octet-counting para delimitar o final de uma mensagem. Além de contar o número de bytes, ele usa um trailler de nome END. O início de uma mensagem BEEP está delimitado por um conjunto de identificadores que fornecem as seguintes informações:

* o tipo da mensagem;

* uma identificação se a mensagem tem continuação;

* um número único de identificação para cada mensagem, para que se possa distingui-las quando elas estão sendo enviadas;

* a aplicação para qual a mensagem é endereçada.

Com todas estas características o protocolo BEEP consegue simplificar a verificação de erros.

Este protocolo também usa o mecanismo de controle de fluxo para permitir a multiplexação de canais sobre uma única camada de transporte. Este mesmo mecanismo é utilizado pelo protocolo TCP.

3.2.2 Codificação das Mensagens

Existem vários mecanismos de codificação de mensagens em uso na Internet. O protocolo SMTP usa o mecanismo descrito na RFC0822 enquanto o SNMP usa o ASN.1/BER. O protocolo BEEP utiliza para a codificação das mensagens o protocolo MIME[05].

3.2.3. Informações sobre as conexões

Protocolos de aplicações devem proporcionar um mecanismo de identificação de erros, possibilitando, assim, que as partes envolvidas na transmissão e as pessoas que manipulam tais protocolos possam saber se uma requisição ou recebimento de informações teve sucesso. O SMTP foi o primeiro protocolo de aplicação a usar tal mecanismo, que consiste em informar o erro através de um código de 3 dígitos. Após o SMTP vários outros protocolos, tais como FTP e HTTP, implementaram também tal mecanismo. 

O protocolo BEEP utiliza um campo textual de 3 dígitos para informar os erros. Além dos 3 dígitos existe uma informação adicional (positivo e negativo) que permite identificar de maneira mais objetiva se a transferência teve bom êxito.

3.2.4. Trocas assíncronas

A troca de mensagens entre componentes que utilizam o protocolo BEEP é realizada através de canais. Cada canal está associado a um perfil que define a sintaxe e a semântica das mensagens que estão sendo enviadas e recebidas. O conceito de canal provê a base do assincronismo do protocolo BEEP. Através de apenas uma sessão, vários canais podem ser abertos simultaneamente. Assim sendo, todas as mensagens são processadas de maneira síncrona em cada canal, não existindo limitações para o processamento de mensagens em canais diferentes. Um exemplo de uma sessão BEEP está demonstrado na figura 1, na qual através de uma única sessão dois canais diferentes, especificados por perfis diferentes, estão trocando mensagens.

Figura 1: Sessão BEEP com múltiplos canais

3.2.5. Autenticação

Tradicionalmente os protocolos de aplicação têm ignorado o problema da autenticação, assim sendo, nem os componentes nem a troca de mensagens são autenticados. Um dos poucos protocolos que implementa autenticação é o FTP que possui um mecanismo de chave/senha para garantir o sucesso da conexão e também para que ambas as partes saibam quem é a origem e quem é o destino.

Para este função o IETF utiliza o protocolo SASL [08]. Com o SASL é possível também utilizar as credenciais de algum outro protocolo de segurança já existente. Por exemplo, as credenciais utilizadas pelo protocolo IPSec¹ podem também ser utilizada pelo SASL. Além da autenticação ele também garante a integridade e privacidade das mensagens que estão sendo transmitidas.

¹ IPSec: Protocolo para autenticar e garantir a segurança dos dados que estão sendo transportados através do protocolo IP[13].

Quando um canal é autenticado, uma identificação simples de usuário é feita para cada componente da sessão, onde cada sessão corresponde a somente um usuário, sendo que todos os canais atribuídos a um único usuário utilizam a mesma autenticação.

3.2.6. Privacidade

Para prover a privacidade das conexões o protocolo BEEP suporta além do SASL, o TLS (Transport Layer Security)[04], que é o padrão sugerido pelo IETF para a privacidade das conexões.

Quando a negociação para um canal seguro é iniciada por dois componentes, todas as conexões sem segurança que estão estabelecidas são finalizadas e reiniciadas depois de completado o modo de transmissão privativo.

3.2.7. Perfis BEEP

Todo canal criado para a transferência de dados está associado a um perfil, sendo ele responsável por especificar a sintaxe e a semântica das mensagens que estão sendo trocadas. Um protocolo de aplicação (IDP, por exemplo) que usa o protocolo BEEP é definido através de um ou mais perfis. Existe um em particular, denominado URI[02], que é usado por todos os demais no início de uma sessão e que tem a função de informar para os componentes qual é o perfil que será utilizado.

Existem dois tipos básicos de perfis, que determinam as operações que podem ser executadas sobre um canal de dados.

* Perfil de inicialização: é utilizado na inicialização de uma sessão, na autenticação e no transporte seguro de informações;

* Perfil Normal: serve para trocar dados. Normalmente é utilizado após a inicialização de uma sessão. Sua principal característica é estabelecer o padrão de troca de mensagens sobre um canal.

3.3. Protocolo IDXP

O protocolo IDXP(Intrusion Detection Exchange Protocol) [11] é implementado como um perfil do protocolo BEEP, descrevendo a maneira com que as informações são trocadas entre componentes IDS. Enquanto o modelo BEEP fornece o protocolo, o perfil IDXP especifica as características necessárias para o estabelecimento de um canal e a troca de informações entre os componentes envolvidos. A especificação IDXP pode ser dividida em 4 partes que serão detalhadas a seguir.

3.3.1 Conexões

Conexões entre componentes IDS podem ser estabelecidas dentro de uma mesma rede ou em redes que são separadas por "gateways"². Quando um ou mais "gateways" existem entre os componentes IDS que trocam informações, é necessário que seja criado um túnel³ entre eles para que o canal de comunicação também possa ser criado.

² Gateway: Equipamento que possibilita que uma sub-rede envie informações para outras sub-redes.
³ Túnel: Capacidade que os protocolos possuem de poder enviar um protocolo dentro do outro.

Para esta tarefa o perfil IDXP requer a utilização de um outro perfil do protocolo BEEP denominado inicialização. 

3.3.2. Segurança

Após o estabelecimento da conexão entre os dois componentes IDS é necessário que a segurança na troca das informações também seja estabelecida. Como o perfil de inicialização também provê a característica de segurança, nenhum outro perfil é necessário para esta funcionalidade. Com isto todas as condições de segurança estão preservadas no momento em que as informações são transmitidas. 

3.3.3. Canal BEEP

Depois que uma sessão BEEP já está estabelecida e que todos os processos de segurança já foram inicializados, a próxima fase do uso do perfil IDXP é abrir um canal aonde os dados podem ser trocados. A primeira mensagem contém a URI, que determina como as informações serão trocadas juntamente com um nome da máquina ou endereço IP da origem. Através destas informações o servidor tem capacidade de decidir se a solicitação oriunda do cliente é aceitável, retornando para o mesmo um "positivo" ou um "negativo". 

Através de uma única sessão BEEP vários canais IDXP podem ser criados, economizando, assim, o estabelecimento de novas sessões.

3.3.4. Transferência de Dados

Dados sobre detecção de intrusos são enviados dos clientes para os servidores em um dos três tipos de dados MIME: text/xml, text/plain ou application/octet-stream. Dados em XML estão em conformidade com as mensagens IDMEF, sendo que os outros dois tipos foram criados para não restringir o uso de novas implementações. 

3.4. Protocolo IAP

O protocolo IAP (Intrusion Alert Protocol) [06] foi especificamente construído para transportar alertas entre componentes de IDS. Como todo protocolo, ele é baseado em um modelo de comunicação e troca de mensagens. Ele é caracterizado pela simplicidade, não tendo a mesma robustez do protocolo BEEP/IDXP.

3.4.1. Modelo de Comunicação

O protocolo IAP utiliza um modelo de comunicação similar ao HTTP 1.0. Um dos componentes faz requisições e o outro responde, mas algumas adaptações foram necessárias para que ele pudesse funcionar de maneira mais eficiente. A primeira é que o componente que estabelece a conexão pode responder e solicitar, isto é, não está caracterizado quem é o servidor e quem é o cliente. A segunda é que o protocolo HTTP suporta vários níveis de servidores proxy com a utilização do armazenamento de informações (cache). Já o protocolo IAP suporta somente um tipo de proxy que é similar a um túnel do protocolo HTTP, através do qual as informações são trocadas, mas não entendidas.

3.4.2. Sintaxe das Mensagens

As mensagens que são trocadas através do protocolo IAP são baseadas em textos. Na figura 2 é mostrada uma requisição IAP que inclui o início de uma mensagem IDMEF. Toda requisição começa com uma linha contendo o tipo da operação e a versão do protocolo IAP que está sendo utilizada. Os cabeçalhos "Content-Length:" e "Content-Type:" são utilizados para indicar o tamanho e o tipo de informação que está sendo transferida. Todo cabeçalho é seguido por uma linha em branco e a mensagem, que pode estar vazia.

Toda requisição é respondida por uma mensagem que tem um formato similar. Na primeira linha tem a versão do protocolo IAP e 3 dígitos de código de retorno que indicam se a solicitação foi bem sucedida ou não. Esta linha é seguida por cabeçalhos, uma linha em branco e a mensagem, como na requisição. Um exemplo de mensagem IAP está demonstrado na figura 2.

Figura 2: Exemplo de Mensagem IAP

3.4.3. Iniciando uma conexão 

Vários detalhes importantes devem ser trabalhados antes que as informações possam ser transportadas através do protocolo IAP. Os dois componentes que irão trocar informações devem estar autenticados, deve-se iniciar a encriptação dos dados e decidir quem irá fazer a requisição dos dados. Somente depois desta fase inicial de reconhecimento de ambos os componentes é que informações com alertas podem ser transferidas. 

Depois que a conexão está estabelecida, uma requisição de conexão IAP é enviada levando a versão do protocolo em uso e o endereço IP da máquina de destino. Se a conexão é feita através de um servidor proxy, ele terá um cabeçalho adicional de nome "Via:". Estes cabeçalhos são examinados pelos proxys para constatar se a conexão não está em loop, sendo nesta fase o único momento em que um servidor proxy analisa as informações que estão sendo transferidas através do protocolo IAP. A partir deste momento o servidor proxy irá transmitir as mensagens de maneira transparente até que a conexão seja encerrada.

Se a requisição de conexão é bem sucedida, o componente que a iniciou irá solicitar para que ela se transforme em TLS, que é a maneira segura de transportar os dados.

Depois que a conexão foi transformada, existe uma verificação TLS. Isto significa que o componente que iniciou a conexão assume a característica de cliente. Cada um dos componentes que faz parte da conexão deverá enviar um certificado assinado digitalmente e verificar a autenticidade do certificado recebido. É conveniente notar que os servidores proxy envolvidos no envio das mensagens não participam da conexão TLS, eles simplesmente transferem informações de um componente para o outro. O uso de certificados assinados digitalmente entre os dois componentes é vital para garantir que toda esta estrutura não seja atacada por alguém que insira pacotes não desejados no meio da transferência dos dados.

Depois que a conexão TLS foi estabelecida, uma requisição de verificação de versão do protocolo IAP é enviada para a máquina que iniciou a conexão. Isto é necessário para que em ambos os lados da conexão a versão do protocolo IAP seja a mesma. Isto é feito somente após a verificação TLS porque qualquer informação transmitida antes do estabelecimento da segurança é passível de ser modificada. Depois de todas estas verificações qualquer um dos componentes pode se denominar Servidor, independentemente se ele foi o iniciador da conexão.

3.4.4. Enviando Alertas

Depois que todas as regras foram estabelecidas, o servidor pode iniciar o envio dos alertas fazendo as requisições IAP. Embora o formato definido para o protocolo IAP seja flexível, a versão 0.4 deste protocolo permite que somente o servidor possa enviar mensagens. Novas versões permitirão que outros tipos de dados possam ser enviados, tais como: informações sobre configurações, informações específicas de um determinado analisador, etc. 

4. Conclusão

Está cada vez mais complicado administrar segurança em grandes redes corporativas, por se tratar de ambientes extremamente complexos e com uma variedade muito grande de hardware e software.

Em linhas gerais este trabalho tenta mostrar o que está sendo feito para a padronização na administração de ambientes IDS. Por se tratar de uma tecnologia nova, ainda não é possível determinar se o mercado irá utilizá-la.

5. Referências

1. BACE, R.; MELL, P. NIST Special publication on intrusion detection systems. 2000. Disponível em: http://csrc.nist.gov/publications/nistpubs/
800-31/sp800-31.pdf>. Acesso em: 26 maio 2003.

2. BERNERS-LEE, T. et al. RFC2396: Uniform Resource Identifiers (URI). 1998. Disponível em: http://www.faqs.org/
rfcs/rfc2396.html. Acesso em: 26 maio 2003.

3. CURRY,D.; DEBAR, H. Intrusion detection message exchange format data model and extensible markup language (XML) document type definition. Fev. 2002. Trabalho em andamento. Disponível em: http://www.ietf.org/internet-drafts/
draft-ietf-idwg-idmef-xml-10.txt. Acesso em: 26 maio 2003.

4. DIERKS, T.; ALLEN, C. RFC2246: The TLS protocol version 1. 1999. Disponível em: http://www.faqs.org/rfcs/rfc2246.html. Acesso em: 26 maio 2003.

5. FREED, N.; BORENSTEIN, N. RFC2046: Multipurpose Internet Mail Extension (MIME) part two: media types. 1996. Disponível em: http://www.faqs.org/rfcs/rfc2046.html. Acesso em: 26 maio 2003.

6. GUPTA, D. et al. IAP: intrusion detection protocol. Internet Engineering Task Force. 2001. Disponível em: http://www.ietf.org/proceedings/
00jul/I-D/idwg-iap-01.txt. Acesso em: 26 maio 2003.

7. MATTNEWS, G. et al. The Intrusion Detection Exchange Protocol (IDXP). Internet Engineering 
Task Force. 2002. Disponível em: http://www.ietf.org/
internet-drafts/draft-ietf- idwg-beep-idxp-07.txt. Acesso em: 26 maio 2003.

8. MYERS, J. RFC2222: Simple Authentication andSecurity Layer (SASL). 1997. Disponível em: 
http://www.faqs.org/rfcs/rfc2222.html. Acesso em: 26 maio 2003.

9. MUKHERJEE, B.; LEVITT, K. N.; HEBERLEIN, L. T. Network intrusion detection. IEEE Network. June 1994. Disponível em: http://seclab.cs.ucdavis.edu/
papers/mhl94.pdf. Acesso em: 26 maio 2003.

10. NSA glosary of terms used in security and intrusion detection. 1999. Disponível em: http://www.sans.org/newlook/
resources/glossary.htm. Acesso em: 16 maio 2003.

11. ROSE, M. RFC 3080: the blocks extensible exchange protocol core. Mar. 2001. Disponível em: http://www.faqs.org/rfcs/rfc3080.html. Acesso em: 26 maio 2003.

12. SIYAN, K.; HARE, R. C. Internet firewalls and network security. Indianapolis: New Riders Publishing, 1995. 410p. 

13. RSA Laboratories. What is IPsec? Disponível em: 
http://www.rsasecurity.com/rsalabs/
faq/5-1-4.html. Acesso em: 16 maio 2003.