| Padronização
na Detecção de Intrusos
Autor: Marco Aurélio Bonato
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 IDS1 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.
1IDS: "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 Firewall2
não consegue detectar ataques embutidos nos protocolos de aplicação ou
ataques de rede, como os DoS3. 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].
2 Firewall: "Um sistema ou a combinação
de sistemas que reforçam a segurança entre uma ou mais redes."[12]
3 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 IPSec1
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.
1 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"2.
Quando um ou mais "gateways" existem entre
os componentes IDS que trocam informações, é necessário que seja criado
um túnel3 entre eles para que o canal de comunicação também
possa ser criado.
2 Gateway: Equipamento que possibilita que uma
sub-rede envie informações para outras sub-redes.
3 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.
bonato@celepar.gov.br
|
junho
2003 # 132
