Este trabalho apresenta de forma resumida os principais aspectos da terceira versão do protocolo SNMP. Na verdade o SNMPv3 estende o SNMPv2 especificando aspectos de segurança e administração que foram deixados de lado neste último. Após uma visão geral do protocolo, a segurança é explicada em maiores detalhes.

Introdução

A versão 3 do protocolo SNMP é derivada das duas especificações anteriores da arquitetura de gerenciamento padrão para a Internet (SNMPv1 e SNMPv2). Estas três especificações utilizam os mesmos conceitos e componentes e, portanto, possuem a mesma arquitetura.

Quando a primeira versão do protocolo SNMP foi desenvolvida, sua composição modular objetivava permitir sua migração com pouco esforço para o padrão de gerenciamento OSI (CMIP) [SNM 98a]. No entanto, durante o decorrer dos anos, esta estratégia demonstrou ter sido a decisão correta pelo motivo errado. Pois ao invés de incentivar o encaminhamento para a plataforma CMIP, a modularidade presente no protocolo permitiu a fácil criação e adaptação de versões mais recentes deste à base de gerenciamento já instalada.

Na verdade a principal contribuição do SNMPv3 é estender o SNMPv2 nas questões de segurança e administração [SNM 98a], conforme os ítens abaixo:

Segurança

Autenticação e privacidade
Autorização e controle de acesso

Administração

Nomeação de entidades
Pessoas e políticas
Usernames e gerenciamento de chaves
Destinos de notificação
Relações com proxy
Configuração remota através de operações SNMP

Visão geral do SNMPv3

A especificação do SNMPv3 é constituída de módulos e composta de vários documentos. Os escritores pretendem que os documentos possam ser revisados e alterados de maneira independente.

Sempre que possível, procurou-se reutilizar conceitos já definidos para versões anteriores do protocolo (SNMPv2) de maneira a evitar desgastes em redefinições desnecessárias.

Os documentos que descrevem a estrutura de gerenciamento SNMPv3 seguem a mesma arquitetura das versões anteriores e podem ser organizados e quatro categorias [SNM 98a]:

Linguagem de definição de dados
Módulos MIB
Operações de protocolo e mapeamentos de transporte
Segurança e administração

As três primeiras categorias foram incorporadas do SNMPv2. A quarta categoria foi desenvolvida para o SNMPv3 utilizando vários conceitos já presentes na versão SNMPv2 mas que foram deixadas de lado por terem sido consideradas de pouca relevância na ocasião.

Linguagem de definição de dados

Esta especificação, baseada no RFC 1902, define o SMI (Structure of Management Information) que por sua vez define os tipos de dados, modelos de objetos e as regras para escrever e revisar módulos MIB (Management Information Base). Especificações relacionadas são: RFC 1903 e RFC 1904.

Módulos MIB

Módulos MIB contém definições de objetos e também podem conter definições de notificações. Ou seja, a MIB determina as informações de gerenciamento de interesse para o controle do sistema.

De modo geral, informações de gerenciamento definidas em uma MIB podem ser utilizadas com qualquer versão do protocolo. Por exemplo, MIBs definidas de acordo com as especificações da SMI do protocolo SNMPv1 são compatíveis com as definições da arquitetura SNMPv3 e podem ser utilizadas em ambas as plataformas. E vice-versa, com apenas uma exceção. O protocolo SNMPv1 não consegue manipular o tipo de dado Counter64 definido no SNMPv2.

Operações de protocolo e mapeamentos de transporte

Estas especificações são incorporadas do SNMPv2. Estas especificações são encontradas em RFC 1905 e RFC 1906.

Segurança e administração

Os documentos que atualmente descrevem esta parte da especificação são as RFCs de 2271 a 2275, que serão resumidas a seguir.

Arquitetura / Segurança e Administração

A RFC 2271 define aspectos gerais da arquitetura SNMP Management Framework. Mas descreve em detalhes aspectos relacionados com segurança e administração. Define vários termos utilizados através da arquitetura SNMPv3:

Engines e aplicações. Equivalente a entidades de protocolo e entidades de aplicação, respectivamente, nas versões anteriores.
Entidades. Provedores de serviço como engines em agentes, e gerentes.
Identidades. Usuários de serviços.
Informações de gerenciamento. Incluindo suporte para múltiplos contextos lógicos.

O documento contém um pequeno módulo MIB que é implementado por todos os authoritative engines SNMPv3. Um authoritative engine é o receptor da mensagem, se esta exige uma resposta (por exemplo um get ou set) ou o remetente, se a mensagem não necessita de resposta.

Processamento e envio de Mensagens (MPD)

O processamento e envio de mensagens (Message Processing and Dispatching) é tratado no RFC 2272. Define procedimentos para o envio de mensagem SNMP de múltiplas versões para os processadores de mensagens apropriados, e também o envio de PDUs (Protocol Data Units) para aplicações SNMP. Este documento também descreve o modelo de processamento de mensagens do protocolo. Um engine SNMP deve suportar pelo menos um modelo de processamento de mensagens, mas também pode suportar mais de um. Por exemplo para fornecer suporte a SNMPv3 e SNMPv1.

Aplicações

Existem cinco tipos de aplicações quer podem ser associadas com um engine SNMP: geradores de comandos, respondedores de comandos, originadores de notificação, recebedores de notificação e transmissores de proxy. Estas definições encontram-se no RFC 2273.

Modelo de Segurança baseado no usuário (USM)

O RFC 2274 (User-based Security Model) especifica a segurança no nível de mensagens. Descreve os quatro principais ataques que são defendidos pelo modelo de segurança baseado no usuário:

Modificação da informação.
Mascaramento.
Modificação do fluxo de mensagens
Espionagem (opcional)

São utilizados os algoritmos MD5 (Message Digest 5) e SHA (Secure Hash Algoritm) para cálculo de hash com chave de maneira a defender de ataques de modificação de dados, fornecer autenticação de origem dos dados, e defender de ataques de mascaramento.

O USM utiliza indicadores de tempo monotonicamente incrementados e fracamente sincronizados para a defesa contra certos tipos de ataques que modificam o fluxo de mensagens. São especificados mecanismos de sincronização automática de clock baseados no protocolo sem dependência de fontes de temporização exterior.

Para a proteção contra espionagem , o USM utiliza o DES (Data Encryption Standard) no modo CBC (Cipher Block Chaining).

Este documento também inclui uma MIB para monitoramento remoto e gerenciamento de parâmetros da configuração do USM, incluindo a distribuição e o gerenciamento de chaves.

Uma entidade de protocolo pode fornecer suporte simultâneo para múltiplos modelos de segurança assim como múltiplos protocolos de privacidade e autenticação Todos os protocolos utilizados pelo USM são baseados em criptografia simétrica (mecanismos de chave privada). A arquitetura SNMPv3 permite utilizar mecanismos de chave pública no futuro.

Controle de acesso baseado em visão (VACM)

Descrito no RFC 2275, o VACM (View-based Access Control Model) define elementos de procedimento para controlar o acesso a informações de gerenciamento. Também inclui uma MIB para gerenciamento remoto de parâmetros de configuração para o VACM.

Segurança no SNMPv3

Os mecanismos para implementar segurança no SNMP são divididos entre dois subsistemas [BLU 97]: o Módulo de Segurança e o Módulo de Controle de Acesso.

A arquitetura SNMP utiliza o termo principal (mandante), em benefício do qual os serviços são fornecidos. Um principal pode ser um indivíduo, um conjunto de indivíduos, uma aplicação, um conjunto de aplicações ou combinações dos casos anteriores.

Múltiplos Modelos de Segurança

Os conceitos de segurança evoluem com o passar do tempo. Isto não se aplica apenas a algoritmos de criptografia como também a todo o mecanismo de segurança utilizado. Assim, o protocolo SNMP suporta diversos modelos de segurança. Permite ainda que diferentes modelos de segurança coexistam na mesma entidade. As mensagens carregam um campo no cabeçalho que indica o modelo de segurança utilizado.

Para garantir a interoperabilidade, existe um modelo de segurança que deve ser implementado por qualquer entidade compatível com SNMPv3. É chamado de User-based Security Model (USM) e é identificado pelo número 3.

USM

Os ataques que devem ser defendidos pelo USM são:

Modificação da informação. Uma entidade não autorizada tenta alterar uma mensagem SNMP em trânsito (originalmente disparada em benefício de uma entidade autorizada).
Mascaramento. Tentativa de uma entidade não autorizada de realizar uma operação assumindo a identidade de uma entidade autorizada.
Modificação no fluxo de mensagens. Retardo ou reenvio de mensagens em um período superior ao permitido em condições normais de operação da rede.
Espionagem. Entidades não autorizadas visualizam o conteúdo da troca de mensagens SNMP.

Foi decidido que análise de tráfego e negação de serviço (DOS – Denial of Service) não seriam abordados por dois motivos: primeiro, porque seria impossível e em segundo lugar porque a ameaça não é significante.

Identificação

No USM, um principal é representado por um user e identificado por um userName. O papel do user é guardar sua senha e informações relacionadas a segurança, como o algoritmo de criptografia a ser utilizado.

Entidades SNMP são identificadas por seu snmpEngineID. Estas entidades podem ser agentes tradicionais executando em dispositivos gerenciados, estações de gerenciamento de rede, gerentes intermediários, etc. O userName é utilizado para identificação e autorização enquanto snmpEngineID é necessário para identificar o alvo de uma operação SNMP.

Quando dois engines SNMP se comunicam, um é designado para ser o engine de autenticação.

Senhas

Cada usuário possui duas senhas)que são octetos de strings. Uma senha é utilizada para autenticação e outra para criptografia.

Chaves e senhas

Os usuários utilizam senhas em formato ASCII. Para utilizar esta senha, o USM concatena esta string com ela mesma até formar um texto de 1 MB e então realiza um hash desse texto, resultando na chave que será utilizada pelo sistema.

Localização das chaves

Para utilizar o sistema, a senha do usuário ou a chave obtida do hash dessa senha é composta com o identificador público de um engine remoto. O resultado dessa composição é submetido a uma função criptográfica forte de uma via. O resultado somente faz sentido para este engine que desse modo pode realizar a autenticação do usuário.

Autenticação

O objetivo da autenticação do USM é determinar de que usuário a mensagem é originada, para qual engine é destinada, se foi alterada no caminho e, com um menor grau de certeza, se esta mensagem é original ou uma repetição indevida de uma mensagem anterior.

Integridade de dados e autenticação

A integridade de dados e a autenticação da mensagem são realizados através da utilização de fingerprints (impressões digitais) das mensagens. Esses fingerprints são impossíveis de serem forjados devido à utilização do método HMAC (Hash Message Authentication Code).

Para o cálculo do hash pode ser utilizado tanto MD5 quanto SHA-1.

Estampas de tempo

O USM utiliza relógios sincronizados para garantir a atualidade das mensagens. Toda a mensagem carrega um timestamp que é examinado após o recebimento. Se a diferença entre o timestamp e o relógio local for muito grande, a mensagem é descartada por ser antiga. O problema consiste em garantir o sincronismo dos relógios.

Clock Autoritativo

Na comunicação entre dois engines, um é eleito como autoritativo e seu clock é aceito como correto. O engine não autoritativo deve sincronizar seu clock de acordo com este, através de mensagens get para obter o valor do correto de clock.

Janela de oportunidade

É determinado um tempo limite para que as mensagens trafeguem na rede. Este tempo limite fornece uma janela de tempo em que a mensagem pode ser considerada válida. O USM utiliza o tempo de 150 segundos como janela de validade. Esta janela não é configurável.

Se durante o tempo de 150 segundos uma mensagem aparecer duas vezes, ele deve ser tratada normalmente como qualquer mensagem duplicada pela rede. A partir desse tempo, a mensagem é simplesmente descartada como antiga.

Privacidade

Assim como nas versões anteriores do protocolo SNMP, a utilização de privacidade é opcional. Se o engine suporta privacidade, ele deve utilizar o algoritmo DES (Data Encryption Standard). No entanto outros algoritmos também pode ser utilizados.

As chaves são obtidas, localizadas, mantidas e atualizadas da mesma maneira que as chaves de autenticação.

Considerações Finais

O protocolo SNMP tem evoluído desde sua criação e hoje encontra-se em sua terceira versão. As principais características dessa versão relacionam-se a segurança e administração.

As questões referentes a segurança foram planejadas desde as primeiras versões do protocolo. Principalmente no SNMPv2. Mas sempre foram deixadas de lado por necessitarem de definições mais rigorosas e que deveriam possuir consenso da comunidade, o que aparentemente foi conseguido apenas agora.

Especificando modelos de segurança, o SNMPv3 ataca um dos maiores problemas do SNMP, segundo críticos do protocolo.

Entre as empresas que apoiam o novo protocolo encontram-se Advent Network Management, Inc., Bay Networks, BMC Software, Cisco Systems, Hewlett-Packard, IBM, InterWorking Labs, Liebert Corporation, SNMP Research International, Tivoli, University of Quebec in Montreal.

No entanto as RFCs referentes ao protocolo apenas adquiriram status de draft durante este ano.

Portanto deve-se esperar que mais fabricantes apoiem esse padrão e adeqüem seus produtos em um futuro próximo.

Referências Bibliográficas

[BLU 97] BLUMENTHAL, U. & WIJNEN, B. Security Features of SNMPv3 em The Simple Times. Volume 5. Número 1. Dezembro de 1997. Disponível em: http://www.simple-times.org/pub/simple-times/issues/5-1.html#announcements. Acessado em 18/12/98.

[SNM 98a] SNMP RESEARCH INTERNATIONAL. SNMPv3 Introduction to SNMPv3. Abril de 1998. Disponível em: http://www.snmp.org/v3hotspot/white.html. Acessado em 18/12/98.

[SNM 98b] SNMP RESEARCH INTERNATIONAL. SNMPv3 HotSpot Information. Abril de 1998. Disponível em: http://www.snmp.org/v3hotspot/index.html. Acessado em 18/12/98.

Universidade Federal do Rio Grande do Sul
Instituto de Informática
PPGCC
Disciplina de Gerência de Redes de Computadores
Profa. Dra. Liane Tarouco
Dezembro de 1998