Identificação de requisitos

A terceira versão da Arquitectura de Gestão SNMP – SNMPv3 – surgiu essencialmente pelos enormes problemas de segurança não resolvidos nas versões anteriores. A experiência obtida com a desenvolvimento da segunda versão foi fulcral para a toda a filosofia de base do SNMPv3. Neste contexto, houve algumas preocupações fundamentais que estiveram na base da sua especificação, e que por terem sido ignoradas na segunda versão, tiveram como consequência a sua ineficácia na resolução dos problemas de segurança e a sua difícil aceitação no mercado.

Figura 21: requisitos e características fundamentais de SNMPv3

Assim sendo, foram adoptados os seguintes princípios, que se ilustram na Figura 21, durante a especificação da arquitectura de gestão SNMPv3:

1. Utilizar como base o trabalho existente, para o qual existe experiência de implmentação e consenso sobre o seu valor acrescentado.

2. Colmatar a deficiência de segurança das versões anteriores, que impossibilita a real utilização de opções de configuração via mensagens SNMP SetRequest. 3. Conceber uma arquitectura modular, que fosse possível implementar em diversos

ambientes operacionais, desde sistemas simples, com funcionalidades mínimas, até sistemas complexos, capazes de gerirem redes de grandes dimensões.

4. Permitir que esse arquitectura pudesse ser utilizada sem interferência do processo de normalização, de forma a que a sua utilização não estivesse sujeita à obtenção de consenso global em torno de toda a arquitectura.

5. Permitir a utilização de modelos alternativos de segurança.

6. Manter o SNMP o mais simples possível (chave do sucesso das versões anteriores !) Base de concepção: SNMPv2 Base de concepção: SNMPv2 Simplicidade Simplicidade Segurança execução das acções de controlo Segurança execução das acções de controlo Arquitectura modular Arquitectura modular Diferentes ambientes operacionais Diferentes ambientes operacionais

Normalização por partes Normalização por partes

Modelos de segurança alternativos Modelos de segurança alternativos Base de concepção: SNMPv2 Base de concepção: SNMPv2 Simplicidade Simplicidade Segurança execução das acções de controlo Segurança execução das acções de controlo Arquitectura modular Arquitectura modular Diferentes ambientes operacionais Diferentes ambientes operacionais

Normalização por partes Normalização por partes

Modelos de segurança alternativos Modelos de segurança alternativos Diferentes ambientes operacionais Diferentes ambientes operacionais

Normalização por partes Normalização por partes

Modelos de segurança alternativos Modelos de segurança

71

7. fosse progressivamente aceite como norma, podendo as partes normalizadas serem utilizadas

Com base nestes requisitos, foram tomadas as seguintes opções de desenvolvimento: 1. Arquitectura: tem de ser definida com base em limites conceptuais, que se

traduzam directamente nos documentos de especificação. Neste contexto, definem-se sub-sistemas, que descrevem os serviços fornecidos por partes especifícas da arquitectura; as interfaces (abstractas) entre os serviços são definidas através de primitivas de serviço e os serviços que são fornecidos pelos sub-sistemas.

2. Documentos auto-suficientes: a especificação de uma dada parte do SNMP deve ser contida, tanto quanto possível, num documento único, que engloibará as funções, as variáveis da MIB, etc..Desta forma, assegura-se que qualquer alteração que se venha a realizar numa parte do SNMPv3, não tem qualquer impacto nos documentos que especificam outras partes da arquitectura.

3. Configuração remota: o sub-sistema de Segurança e Controlo de Acessos adiciona um novo conjunto de parâmetrso de configuração ao SNMP. Para alé, disso, o sistema de segurança implica a troca frequenta de chaves entre entidadase SNMP. Para que estas tarefas sejam viáveis num ambiente operacional de grande dimensão, deverá ser possível efectuar a configuração remota.

4. Complexidade controlada: em equipamentos simples, os recursos associafas à gestão SNMP têm de ser necessariamente reduzidos. Simultâneamente, pode haver necessidade de configurações mais complexas, que necessitem de mais funcionalidades e que possam dispender mais recursos na gestão SNMP. A especificação da arquitectura SNMPv3 deve permitir fazer face a estes dois tipos de situações antagónicas.

5. Ataques à segurança: o sub-sistema de Segurança deve ser capaz de proteger o sistema de gestão contra os principais tipos de ataques, nomeadamente: modificação de informação, masquerade, modificação do fluxo de mensagens, disclosure. A protecção contra a negação do serviço e a análise de tráfego não está incluída na especificação.

Ante de proceder com o estudo do SNMPv3, relembremos então alguns conceitos importantes de segurança...

1.1.1

Enquadramento da segurança no cenário de gestão

Existem vários tipos de ataques à segurança duma rede com objectivos diferenciados, que em termos de gestão podem ter consequências a diferentes níveis. Os que normalmente se destacam neste contexto são:

• Modificação da informação: uma entidade não autorizada pode alterar as mensagens de gestão em trânsito, modificando por exemplo os parâmetros de configuração, ou mesmo a informação de contas.

• Mascaragem: uma entidade pode realiza operações para as quais não tenha permissões, se assumir a identificação de uma outra entidade, autorizada para o efeito.

72

• Modificação da sequência de mensagens: as mensagens SNMP podem ser atrasadas, re-ordenadas ou duplicadas (uma vez que o protocolo é sem ligação), dando origem à realização de operações não permitidas. Por exemplo, uma mensagem de reboot pode ser copiada, com o objectivo de ser re-enviada noutro instante de tempo.

• Espionagem: uma entidade não autorizada pode observar as trocaas entre o gestor e os agentes e aprender os valores dos objectos geridos e dos eventos que dão origem a notificações. Com base neste procedimento pode, por exemplo, aprender a sequência de acções necessária à alteração de passwords e reconhecer as passwords do sistema.

Existem dois outros tipos de ataques de segurança – negação de serviço e análise de tráfego – que não são objecto de protecção em SNMPv3. A negação de serviço impede as trocas entre um gestor e um agente e, em muitas situações não se consegue distinguir duma falha na rede. Para além disso, quando ocorrem, afecta todo o tipo de operações, pelo que deve ser resolvido ao nível da segurança global do sistema e não apenas ao nível da gestão. Relativamente à análise de tráfego, muitas trocas de informação de gestão têm um padrão previsível, em que os comandos e as respostas são emitidos de forma regular, pelo que não vale a pena prevenir este tipo de ataques.

2 Arquitectura SNMPv3