Detecção de Intrusão Usando SNMP

Gerência de Redes – 99/2

Prof. Liane Tarouco

Rafael Campello

Conteúdo

Introdução

Dado o aumento de popularidade da Internet, incidentes de segurança envolvendo intrusão vêm se tornando eventos cada vez mais comuns. Embora alguns desses incidentes sejam impulsionados pela simples curiosidade e não representem verdadeiros riscos às corporações, muitos deles são tentativas maliciosas de comprometer a disponibilidade de alguns sistemas ou a integridade e a privacidade das informações neles contidas.

Independente dos esforços realizados por projetistas, implementadores e administradores de sistemas, é prudente assumir que ataques inevitavelmente ocorrerão e, em alguns casos, terão sucesso. Como nenhuma organização possui tempo e recursos financeiros ilimitados para gastar com segurança, o máximo que pode ser feito é tentar reduzir os riscos de possíveis quebras de segurança a níveis aceitáveis, ou seja, não existe solução definitiva e completa em segurança.

Nesse sentido, prevenir ataques (falhas) é ainda o principal enfoque dado quando trata-se de segurança. É nesse ponto que encontram-se os principais esforços em dar ao sistema mecanismos que visem aumentar a sua proteção, prevenindo ameaças como destruição ou roubo de informações ou de outros recursos, modificação ou deturpação da informação, revelação de informação e interrupção de serviços. Firewalls e proxies são exemplos de mecanismos freqüentemente utilizados na tentativa de prevenir possíveis intrusões.

No entanto, quando o objetivo é atingir níveis maiores de segurança, o uso de técnicas de prevenção de falhas não tem demonstrado suficiência, sendo necessário a aplicação de tolerância a falhas. Criar mecanismos de controle de falhas que garantam a indicação de erros ocorridos (sistemas seguros a falhas), um funcionamento correto ou a condução a um estado seguro (livre de falhas) ou a certeza de um comportamento correto mesmo na presença de falhas (falhas mascaradas) são necessidades reais. Assim, tolerar falhas, detectando, confinando e corrigindo esses erros é um novo enfoque de segurança que vem sendo dado aos sistemas computacionais. É de vital importância criar meios de detectar e responder a ataques, mantendo os serviços mais importantes e alertando a equipe de segurança da ocorrência dessas tentativas.

Várias propostas têm sido feitas com o intuito de criar mecanismos para detectar intrusões. A fonte dos dados, o método usado para detectar atividades intrusivas, a freqüência do uso e o comportamento diante de iminentes intrusões são pontos divergentes nas diferentes propostas. Outra característica marcante nessas ferramentas é a completa falta de padronização em diferentes aspectos, dificultando a interoperabilidade entre os mecanismos empregados, o intercâmbio dos históricos de ataques entre instituições e, também, a portabilidade dessas ferramentas.

Esforços atuais estão sendo feitos na tentativa de diminuir essas diferenças, criando padrões de interoperabilidade ou sugerindo o uso de protocolos de gerenciamento já existentes. Como exemplo da primeira alternativa, um grupo de trabalho do IETF, chamado Intrusion Detection Working Group, está trabalhando na definição de um formato para intercâmbio de dados sobre detecção de intrusão. Alguns trabalhos, por outro lado, buscam no uso de SNMP a forma de integrar os sistemas de detecção de intrusão (IDSs) e, também, de permitir a troca de dados com diferentes plataformas de gerenciamento.

O objetivo deste tutorial é relatar as características e peculiaridades da área de detecção de intrusão, abordar resumidamente o protocolo SNMP e analisar, fundamentado em trabalhos e propostas já formuladas, as possibilidades, vantagens e desvantagens de usar SNMP e agentes com MIBS proprietárias para auxiliar na detecção de intrusão.

 

Voltar ao início

Detecção de Intrusão

Quando um usuário de um sistema de informação toma uma ação que não é legalmente permitida, isso é chamado intrusão [SIE 99]. Segundo Heady [HEA 90], uma intrusão é definida como qualquer conjunto de ações que tentam comprometer a integridade, sigilo ou disponibilidade de um recurso. O intruso, por sua vez, pode ser classificado de diferentes formas. Habra [HAB 92], baseado em outros trabalhos, classificou os ataques em 3 categorias, levando em consideração o tipo de intruso:

a) Invasões externas: ataques feitos por usuários que não estão autorizados a utilizar o sistema;

b) Invasões internas: ataques feitos por usuários autorizados a utilizar o sistema, incluindo:

b.1) Usuários autorizados que tentam ir além de seus privilégios em algum recurso;

b.2) Usuários disfarçados que operam com outra identidade;

b.3) Usuários privilegiados que são autorizados a utilizar o sistema e têm privilégios de acesso mas que utilizam seus direitos de maneira maliciosa.

c) Vírus e cavalos de tróia: ataques feitos por processos ou programas maliciosos.

Na tentativa de minimizar os risco de ocorrência desses ataques, sistemas de detecção de intrusão (IDSs) vêm sendo desenvolvidos e utilizados em muitos ambientes. Segundo Ko [KO 96], o objetivo da detecção de intrusão é detectar atividades em um sistema que violem as políticas de segurança ou comprometam a sua segurança.

Vários critérios podem ser usados na tentativa de classificar a detecção de intrusão. Baseado no método de detecção utilizado, pode-se classificá-los em detecção de anomalia (anomaly intrusion detection) e detecção de mau uso (misuse detection). Essa classificação é aceita pela grande maioria da comunidade acadêmica, embora seja estendida por vários autores. Ko [KO 96] inclui a análise de configuração (configuration analysis) e define uma nova abordagem, baseada em especificação (specification-based approach). Halme [HAL 95], por sua vez, inclui uma abordagem híbrida e um monitoramento contínuo da saúde do sistema (continuous system health monitoring). A seguir é detalhada a classificação comumente aceita.

a) Detecção de Anomalia: A premissa central da detecção de anomalia é que a atividade intrusiva é um subconjunto da atividade anômala. Considerando que um intruso não tenha noção do padrão de uso do recurso atacado, boas são as chances de seu comportamento ser considerado anômalo. Nesse tipo de detecção, a atividade observada é comparada com um padrão de uso considerado normal, criado distintamente por usuário, grupo de usuários, aplicações ou para recursos do sistema. Um evento que desvie dessa definição de comportamento é considerado anômalo. A detecção de anomalia provê um método para detectar invasões sem exigir conhecimento específico do sistema operacional ou de suas falhas de segurança. No entanto, em muitos ambientes, é difícil estabelecer padrões de comportamento para usuários e determinar os valores limites que sinalizam uma anomalia. Além disso, detecção de anomalia sozinha não pode detectar todos os tipos de intrusões, pois nem todas as invasões produzem uma anomalia identificável.

b) Detecção de Mau Uso: a principal suposição da detecção de mau uso é que existem ataques que podem ser precisamente codificados de forma a capturar qualquer arranjo ou variação de atividades que explorem a mesma vulnerabilidade. Assim, a detecção de mau uso essencialmente busca "más atividades" em comparação com descrições abstratas de atividades indesejadas. Essa abordagem tenta esboçar regras que descrevam conhecidos problemas de segurança (baseada em invasões anteriores ou em atividades que possam explorar fraquezas conhecidas). Uma vantagem de detecção de mau uso é poder garantir detecção de intrusões conhecidas se suas assinaturas estão incluídas na base de dados do detetor de mau uso. Porém a limitação fundamental deste modelo é a sua falta de habilidade em tratar ataques imprevisíveis e vulnerabilidades desconhecidas do sistema.

Outro aspecto relevante na classificação dos sistemas de detecção de intrusão é a origem dos dados usados na detecção. Usualmente, esses dados podem ser trilhas de auditoria geradas pelo sistema (registros da atividade do sistema, também conhecidos como logs) ou tráfego de rede. No primeiro caso, dados gerados por aplicações, por serviços ativos ou pelo próprio sistema operacional serão utilizados na detecção de intrusão. Importantes aspectos surgem na coleta, armazenamento e tratamento desses dados. Dependendo da atividade do sistema, eles tendem a crescer até uma quantidade praticamente intratável, problema que pode aumentar se for levado em consideração eventos gerados pelo sistema operacional (abertura de arquivo, chamadas de sistema, etc). Esforços em comprimir a massa de dados gerada, reduzir (selecionar e resumir as informações existentes) ou pré-selecionar os eventos a serem registrados vêm sendo feitos e representam uma grande área para novos trabalhos. Além disso, preocupações com a segurança dessas informações complementam a gama de problemas a serem tratados. A grande vantagem na utilização desse tipo de fonte é a possibilidade de analisar eventos ocorridos em um nível de sistema, observando diretamente tratamentos de arquivos, execução de aplicações, tentativas de acesso a recursos e, se necessário, até mesmo o padrão de digitação do usuário. Por outro lado, ataques originalmente dirigidos à protocolos e serviços de rede, por exemplo, raramente serão relatados pelo sistema de auditoria.

A segunda fonte de dados para detecção de intrusão, o tráfego de rede, pode ser usado para analisar ataques feitos diretamente sobre os recursos de rede, imperceptíveis ao sistema de auditoria. Nesse caso, problemas semelhantes surgem com a quantidade de tráfego de algumas redes, ampliados com o aumento considerável da largura de banda disponível atualmente. Esses dados podem ser coletados de forma centralizada, com um elemento responsável por capturar o tráfego entre várias máquinas, distribuído, com vários coletores repassando os dados para um analisador, ou diretamente de cada máquina, capturando os dados a nível de protocolos e serviços [JOU 97].

O período de análise e o tempo de resposta na detecção de uma intrusão é mais um aspecto usado para classificar os diferentes tipos de sistema. Em sistemas onde a análise dos dados é feita, mesmo que automática, em períodos esparsos, temos a chamada análise post-mortem. Nesses casos a detecção de intrusão é normalmente realizada em períodos de pouco uso do sistema, utilizando dados previamente coletados. Oposto a esse comportamento, a detecção em tempo real analisa instantaneamente os dados gerados, reportando possíveis ataques em tempo hábil à tomada de contramedidas.

A resposta imediata ou não a um ataque também pode ser usado como critério de classificação. Em casos de sistemas que alertam a ocorrência de possíveis ataques instantaneamente, temos uma detecção de intrusão ativa. Na detecção passiva, registros que indicam possíveis intrusões são gerados e posteriormente analisados.

Assim, os sistemas de detecção de intrusão podem ser classificados da seguinte forma:

 

Voltar ao início

Simple Network Management Protocol (SNMP)

Os protocolos de gerenciamento e os mecanismos associados a eles são partes da solução adotada para permitir que gerentes de redes possam localizar e corrigir problemas em um ambiente. O sistema de gerenciamento de rede da arquitetura Internet TCP/IP opera na camada de aplicação e baseia-se em um protocolo simples, chamado SNMP (Simple Network Management Protocol). Os padrões que definem a estrutura de gerenciamento de redes Internet são descritos nos documentos RFC-1155 (Structure Of Management Information), RFC-1156 (Management Information Base) e RFC-1157 (Simple Network Management Protocol).

Resumidamente, os principais objetivos do protocolo SNMP são:

a) Reduzir o custo da construção de um agente que suporte o protocolo;

b) Reduzir o tráfego de mensagens de gerenciamento pela rede necessárias para gerenciar dos recursos da rede;

c) Reduzir o número de restrições impostas às ferramentas de gerenciamento da rede, devido ao uso de operações complexas e pouco flexíveis;

d) Apresentar operações simples de serem entendidas, sendo facilmente usadas pelos desenvolvedores de ferramentas de gerenciamento;

e) Permitir facilmente a introdução de novas características e novos objetos não previstos ao se definir o protocolo;

f) Construir uma arquitetura que seja independente de detalhes relevantes à somente algumas implementações particulares.

Como no esquema de gerenciamento OSI, os processos que implementam as funções de gerenciamento Internet atuam como agentes ou gerentes. Os agentes coletam, junto aos objetos gerenciados, as informações recolhidas pelos gerentes, com o objetivo de detectar a presença de falhas no funcionamento dos componentes da rede (hosts, gateways, processos executando os protocolos de comunicação, etc) ou o estado atual de algum objeto gerenciado. Na comunicação entre agente e gerente, o SNMP utiliza o protocolo UDP.

Um objeto gerenciado representa um recurso que pode ser um sistema hospedeiro (estação de trabalho, servidor de terminais, etc), um gateway ou um equipamento de transmissão (modem, pontes, concentradores, etc). Cada objeto gerenciado é visto como uma coleção de variáveis cujo valor pode ser lido ou alterado. O gerente envia comandos aos agentes, solicitando uma leitura no valor das variáveis dos objetos gerenciados (get e response), ou modificando seu valor (set). A modificação do valor de uma variável pode ser usada para disparar indiretamente a execução de operações nos recursos associados aos objetos gerenciados (por exemplo, uma reinicialização). Na troca de informações entre o gerente e o agente, são aplicados mecanismos de autenticação que, embora simples, diminuem a possibilidade de usuários não autorizados interferirem no funcionamento da gerência.

O SNMP define o formato e a ordem que deve ser seguida no intercâmbio de informações de gerenciamento. As informações sobre os objetos gerenciados são armazenados em bases de informações, chamadas MIB (Management Information Base), que definem o conjunto e a semântica dos objetos que os servidores SNMP devem controlar, ou seja, define o conjunto conceitual de objetos que um servidor SNMP controla. A MIB é usada para armazenar em seus objetos os estados internos das entidades de uma rede. Especificada em ASN.1, ela é totalmente flexível, permitindo que objetos completamente novos sejam definidos e gerenciados pelos mesmos mecanismos e plataformas de gerenciamento.

Embora o SNMP baseie-se na troca de operações entre gerente e agente, o que permite aos gerentes solicitar que um agente lhes informe ou modifique o valor de uma variável de um objeto na MIB, uma outra forma de interação existe. Essa operação, chamada trap, permite que um agente informe ao gerente a ocorrência de um evento específico, sem a necessidade de sucessivas solicitações. Assim, ao contrário de outros protocolos de gerenciamento que apresentam muitos comandos (operações), o SNMP possui somente um conjunto limitado de comandos. Portanto, é muito mais simples de ser implementado do que um protocolo com muitas operações, em que cada operação sobre um objeto necessita de um comando diferente para implementá-la.

 

Voltar ao início

Detecção de Intrusão Usando SNMP

 Tendo em vista a grande quantidade de variações existente entre os atuais sistemas de detecção intrusão, claramente perceptíveis pelo exposto na seção 2, um dos problemas mais discutidos na comunidade acadêmica é a interoperabilidade desses sistemas. Criar ferramentas genéricas que, cada uma em sua especialidade, cooperem na tentativa de detectar o maior número de ataques possíveis e que possam ser facilmente migradas de um sistema operacional para outro, é uma tarefa de difícil solução hoje. Além dessa cooperação, a integração dessas ferramentas com as plataformas de gerenciamento já disponíveis é outro objetivo perseguido.

Nesse sentido, algumas propostas surgem e apontam algumas direções viáveis na busca por uma maior interoperabilidade. Essas propostas serão descritas abaixo, e, na próxima seção, analisadas em conjunto.

a) Formato padrão para troca de dados entre IDSs: essa proposta é fruto de um grupo de trabalho organizado pela IETF em 1999, chamado Intrusion Detection Working Group (IDWG) que pretende definir formatos e procedimentos de troca de dados para compartilhar informações de interesse a sistemas de detecção e resposta a intrusões, e a sistemas de gerenciamento que possam interagir com eles. Em cooperação com outros grupos de trabalho da IETF, os resultados esperados do IDWG são:

1. Um conjunto de requisitos, que descreva os requisitos funcionais de alto-nível para a comunicação entre IDSs, além dos requisitos para a comunicação desses IDSs com sistemas de gerenciamento. Cenários serão usados para ilustrar o documento criado;

2. Uma linguagem comum para a especificação de intrusões, que descreva formatos de dados que satisfaçam os requisitos;

3. Um framework, que identifique os melhores protocolos existentes para a comunicação entre IDSs e descreva como os formatos de dados concebidos relacionam-se com eles.

Dois documentos, disponíveis na forma de Internet-drafts, já foram criados na tentativa de atingir os objetivos acima. O primeiro, Intrusion Detection Exchange Format Requirements (http://www.ietf.org/internet-drafts/draft-ietf-idwg-requirements-02.txt), criado em outubro de 1999 e válido até abril de 2000, define os requisitos exigidos no primeiro item dos objetivos. Além da definição de termos utilizados na área de detecção de intrusão, como analisador, evento, sensor, dentre outros, esse documento apresenta um modelo arquitetural que representa a distinção exata de cada um dos elementos envolvidos na detecção de intrusão. Nesse modelo é assumida a existência de sensores, responsáveis pela informação de eventos, analisadores, que determinam a existência de eventos suspeitos e de gerentes, responsáveis pelo recebimento de alertas gerados pelos analisadores. A definição de um formato e o método de comunicação no envio desses alertas é o propósito do IDEF.

O outro documento organizado pelo IDWG, chamado Intrusion Detection Exchange Format Data Model (http://www.ietf.org/internet-drafts/draft-ietf-idwg-data-model-00.txt), também data de outubro de 1999 e é válido até março de 2000. Nele está descrito um formato de dados proposto para representar a informação exportada por IDSs, incluindo as razões pela criação desse formato.

Essa proposta é baseada na criação de uma hierarquia de classes, semelhante ao que é usado na gerência de redes (MIBs SNMP). Essa opção foi feita porque, segundo o documento, os alertas seguem um paradigma orientado a objetos, permitindo a preservação de toda a noção de objetos. Além disso, uma hierarquia de classes permite que diferentes formatos sejam incorporados de uma maneira consistente, especializando classes na criação de subclasses que possam estender o modelo para novos alertas. Assim, diferentes tipos de IDS's foram analisados e um diagrama de classes foi elaborado, baseado em tipos básicos compatíveis com as RFCs do SNMP.

O terceiro item dos objetivos ainda não foi definido, principalmente dado ao pouco tempo de criação do IDWG.

b) Uso de SNMP como padrão de interação: essa é uma proposta genérica aplicada pelos idealizadores do projeto JiNao [JOU 97], sistema de detecção de intrusão escalável, baseado em tráfego de rede e tempo real, patrocinado pelo DARPA e desenvolvido em colaboração pela MCNC e a Universidade do Estado da Carolina do Norte (NCSU). Nesse projeto, um dos objetivos é utilizar o protocolo SNMP como padrão de interação, permitindo que o sistema seja facilmente integrado com plataformas de gerenciamento existentes, além de integrar diferentes métodos de prevenção e detecção de intrusão em um único sistema. Para tanto, o sistema é composto de dois subsistemas, um local e outro remoto. O subsistema local possui os seguintes módulos: interceptação/redireção, prevenção baseada em regras, detecção baseada em estatística e em protocolo, decisão e módulo de abstração de informação. Ele também inclui uma MIB e funções para acesso a agentes remotos. O subsistema remoto consiste de um conjunto de aplicações de gerenciamento para monitoração e controle de diferentes subsistemas de detecção local, permitindo a reconfiguração e o recebimento de alertas por parte dos diferentes subsistemas de detecção. A interação entre todos esses elementos é feita através do padrão SNMP, facilitando a interoperabilidade com plataformas de gerenciamento já existentes.

 

Voltar ao início

Considerações Finais

 Dois exemplos concretos de esforços na tentativa de facilitar a interoperabilidade entre IDSs foram expostos na seção anterior. Embora outras propostas possam ser citadas, um estudo exaustivo sobre o assunto foge ao escopo do presente trabalho. Contudo, várias colocações podem ser feitas baseadas nas experiências acumuladas com os trabalhos citados.

Valer-se dos conceitos, literatura e experiência vastamente difundidos do padrão SNMP para integrar diferentes IDSs é uma ótima alternativa. A flexibilidade e extensibilidade inerentes a esse padrão permitem criar ótimas soluções para os problemas já descritos. No entanto, algumas observações devem ser feitas, com detalhes importantes a serem ponderados.

A alternativa proposta no projeto JiNao é um ótimo exemplo de IDSs usando SNMP. Nela o SNMP é usado como interface entre os diferentes módulos do sistema, permitindo uma interação baseada em um padrão conhecido, o que possibilita a integração desse sistema com plataformas de gerenciamento ou com outros IDSs que usem a mesma solução para interoperabilidade. No JiNao, os agentes SNMP são processos altamente especializados que recolhem tráfego de rede e buscam indícios de violações no sistema. Após o processamento ser feito e na iminência de algum ataque, alertas são repassados, via SNMP, para módulos de gerenciamento, responsáveis pela coordenação dos diferentes analisadores.

Usando essa estratégia, o JiNao evita utilizar o SNMP para disponibilizar dados puros, como uma ponte entre um analisador centralizado e os diversos agentes, minimizando o tráfego gerado pela ferramenta. Essa é uma das primeiras preocupações que deve ser levada em conta na utilização do SNMP em IDSs. Criar MIBs que mantenham dados puros, como o número de tentativas de login em um equipamento, por exemplo, inevitavelmente irá gerar um excessivo tráfego de gerenciamento, indesejável e proibitivo. Transferir o processamento dos dados gerados para próximo da fonte é a melhor opção, permitindo, inclusive, a adoção de tecnologias como o RMON, por exemplo.

Essa estratégia, embora solucione a falta de um meio para a troca de dados entre os elementos de um IDS, ainda não resolve por completo todos os problemas apresentados. Sem um padrão de fato que regularize um formato a ser amplamente utilizado, trocar dados entre diferentes IDSs torna-se uma tarefa praticamente impossível. Possibilitar a criação de analisadores e gerenciadores genéricos, que possam ser utilizados em diferentes arquiteturas de IDS e em diferentes plataformas é um dos principais objetivos perseguidos.

Nesse sentido, a proposta do IDWG enquadra-se perfeitamente como um formato padrão para a troca de informações sobre intrusão. Se concluída, essa proposta fornecerá uma base importante na integração entre os diferentes IDSs. Com ela, incidentes de segurança poderão ser facilmente relatados e trocados, tanto entre diferentes IDSs como entre diferentes instituições. Outro ponto importante a ser levado em consideração é a segurança e a autenticação. Permitir que informações de intrusão sejam acessadas, adulteradas ou eliminadas compromete toda a validade do sistema. Essas tarefas devem estar presentes no próprio protocolo, aliviando a tarefa dos elementos envolvidos e dos padrões de troca de informação criados.

Por fim, torna-se visível a forte tendência do uso de SNMP em IDSs. Integrar as duas alternativas citadas e difundir essa proposta como um padrão a ser adotado pelos responsáveis por desenvolver novos IDSs apresenta-se como uma boa solução para integração dessas ferramentas.

Voltar ao início

Referências Bibliográficas

[SIE 99] SIELKEN, Robert. Application Intrusion Detection. Charlottesville: University of Virginia, 1999. (Technical Report número CS-99-17, disponível via ftp anônimo em ftp://ftp.cs.virginia.edu/pub/techreports/CS-99-17.ps.Z).

[HEA 90] HEADY, R. et al. The architecture of a network level intrusion detection system. Universidade do Novo México, 1990.

[HAB 92] HABRA, Naji et al. ASAX: Software architecture and rule-based language for universal audit trail analysis. In Proceedings of European Symposium on Research in Computer Security, Novembro 1992.

[KO 96] KO, Calvin. Execution Monitoring of Secrity-Critical Programs in a Distributed System: A Specification-based Approach. California at Davis University, 1996. (Tese de Doutorado disponível em http://seclab.cs.ucdavis.edu/~ko/papers/thesis.ps.

[JOU 97] JOU, Y. Fank; WU, S, Felix. Scalable Intrusion Detection for the Emerging Network Infrastructure. Relatório Técnico, 1997. (disponível em http://www.anr.mcnc.org/projects/JiNao/design.ps)

[HAL 95] HALME, Lawrence R.; BAUER, Kenneth. AINT misbehaving - a taxonomy of anti-intrusion techniques. In Proceedings of the 18th National Information Systems Security Conference,  Outubro 1995.

 

Voltar ao início