Protocolo de gerenciamento de rede simples - Simple Network Management Protocol

SNMPv3 STD0062
Protocolo de comunicação
Camada OSI Aplicativo
Porta (s) 161, 162 (Trap)
RFC (s) 3411-3418
SNMP seguro
Protocolo de comunicação
Camada OSI Aplicativo
Porta (s) 10161, 10162 (Trap)
RFC (s) 6353
Suíte de protocolo de Internet
Camada de aplicação
Camada de transporte
Camada de Internet
Camada de link

SNMP ( Simple Network Management Protocol ) é um protocolo padrão da Internet para coletar e organizar informações sobre dispositivos gerenciados em redes IP e para modificar essas informações para alterar o comportamento do dispositivo. Os dispositivos que normalmente oferecem suporte a SNMP incluem modems a cabo, roteadores, switches, servidores, estações de trabalho, impressoras e muito mais.

SNMP é amplamente utilizado em gerenciamento de rede para monitoramento de rede . O SNMP expõe os dados de gerenciamento na forma de variáveis ​​nos sistemas gerenciados organizados em uma base de informações de gerenciamento (MIB) que descreve o status e a configuração do sistema. Essas variáveis ​​podem então ser consultadas remotamente (e, em algumas circunstâncias, manipuladas) pelo gerenciamento de aplicativos.

Três versões significativas do SNMP foram desenvolvidas e implantadas. SNMPv1 é a versão original do protocolo. Versões mais recentes, SNMPv2c e SNMPv3, apresentam melhorias em desempenho, flexibilidade e segurança.

SNMP é um componente do Internet Protocol Suite conforme definido pela Internet Engineering Task Force (IETF). Ele consiste em um conjunto de padrões para gerenciamento de rede, incluindo um protocolo de camada de aplicativo , um esquema de banco de dados e um conjunto de objetos de dados .

Visão geral e conceitos básicos

Princípio de comunicação SNMP

Em usos típicos de SNMP, um ou mais computadores administrativos chamados gerentes têm a tarefa de monitorar ou gerenciar um grupo de hosts ou dispositivos em uma rede de computadores . Cada sistema gerenciado executa um componente de software denominado agente que relata informações via SNMP ao gerente.

Uma rede gerenciada por SNMP consiste em três componentes principais:

Um dispositivo gerenciado é um nó de rede que implementa uma interface SNMP que permite acesso unidirecional (somente leitura) ou bidirecional (leitura e gravação) a informações específicas do nó. Os dispositivos gerenciados trocam informações específicas do nó com os NMSs. Às vezes chamados de elementos de rede, os dispositivos gerenciados podem ser qualquer tipo de dispositivo, incluindo, mas não limitado a, roteadores , servidores de acesso , interruptores , cable modems , pontes , centros , telefones IP , câmeras de vídeo IP , computador anfitriões e impressoras .

Um agente é um módulo de software de gerenciamento de rede que reside em um dispositivo gerenciado. Um agente tem conhecimento local de informações de gerenciamento e traduz essas informações de ou para um formulário específico do SNMP.

Uma estação de gerenciamento de rede executa aplicativos que monitoram e controlam dispositivos gerenciados. Os NMSs fornecem a maior parte dos recursos de processamento e memória necessários para o gerenciamento da rede. Um ou mais NMSs podem existir em qualquer rede gerenciada.

Base de informações de gestão

Artigo principal: Base de informações de gestão

Os agentes SNMP expõem os dados de gerenciamento nos sistemas gerenciados como variáveis. O protocolo também permite tarefas de gerenciamento ativo, como alterações de configuração, por meio da modificação remota dessas variáveis. As variáveis ​​acessíveis via SNMP são organizadas em hierarquias. O próprio SNMP não define quais variáveis ​​um sistema gerenciado deve oferecer. Em vez disso, o SNMP usa um design extensível que permite que os aplicativos definam suas próprias hierarquias. Essas hierarquias são descritas como uma base de informações de gerenciamento (MIB). Os MIBs descrevem a estrutura dos dados de gerenciamento de um subsistema de dispositivo; eles usam um namespace hierárquico contendo identificadores de objeto (OID). Cada OID identifica uma variável que pode ser lida ou definida via SNMP. Os MIBs usam a notação definida pela Structure of Management Information Version 2.0 (SMIv2, RFC  2578 ), um subconjunto do ASN.1 .

Detalhes do protocolo

O SNMP opera na camada de aplicação do conjunto de protocolos da Internet . Todas as mensagens SNMP são transportadas via User Datagram Protocol (UDP). O agente SNMP recebe solicitações na porta UDP 161. O gerente pode enviar solicitações de qualquer porta de origem disponível para a porta 161 no agente. A resposta do agente é enviada de volta à porta de origem no gerenciador. O gerente recebe notificações ( Traps e InformRequests ) na porta 162. O agente pode gerar notificações a partir de qualquer porta disponível. Quando usado com Transport Layer Security ou Datagram Transport Layer Security , as solicitações são recebidas na porta 10161 e as notificações são enviadas para a porta 10162.

SNMPv1 especifica cinco unidades de dados de protocolo principais (PDUs). Duas outras PDUs, GetBulkRequest e InformRequest, foram adicionadas ao SNMPv2 e a PDU de relatório foi adicionada ao SNMPv3. Todos os PDUs SNMP são construídos da seguinte forma:

Cabeçalho IP Cabeçalho UDP versão comunidade Tipo PDU Identificação do Pedido status de erro índice de erro ligações variáveis

Os sete tipos de PDU SNMP conforme identificados pelo campo do tipo PDU são os seguintes:

GetRequest
Uma solicitação de gerente para agente para recuperar o valor de uma variável ou lista de variáveis. As variáveis ​​desejadas são especificadas em associações de variáveis ​​(o campo de valor não é usado). A recuperação dos valores de variáveis ​​especificados deve ser feita como uma operação atômica pelo agente. Uma resposta com os valores atuais é retornada.
SetRequest
Uma solicitação de gerente para agente para alterar o valor de uma variável ou lista de variáveis. As associações de variáveis ​​são especificadas no corpo da solicitação. As alterações em todas as variáveis ​​especificadas devem ser feitas como uma operação atômica pelo agente. Uma resposta com novos valores (atuais) para as variáveis ​​é retornada.
GetNextRequest
Uma solicitação de gerente para agente para descobrir as variáveis ​​disponíveis e seus valores. Retorna uma Resposta com associação de variável para a próxima variável lexicograficamente no MIB. Todo o MIB de um agente pode ser percorrido pela aplicação iterativa de GetNextRequest começando em OID 0. As linhas de uma tabela podem ser lidas especificando OIDs de coluna nas ligações de variáveis ​​da solicitação.
GetBulkRequest
Uma solicitação de gerente para agente para várias iterações de GetNextRequest . Uma versão otimizada de GetNextRequest . Retorna uma resposta com várias associações de variáveis ​​obtidas a partir da associação de variáveis ​​ou associações na solicitação. Não-repetidores específicos de PDU e campos de repetições máximas são usados ​​para controlar o comportamento de resposta. GetBulkRequest foi introduzido no SNMPv2.
Resposta
Retorna associações de variáveis ​​e confirmação do agente para o gerente para GetRequest , SetRequest , GetNextRequest , GetBulkRequest e InformRequest . Relatórios de erro é fornecido pelo erro de status e erro de índice campos. Embora tenha sido usado como uma resposta para get e sets, esse PDU foi chamado de GetResponse no SNMPv1.
Armadilha
Notificação assíncrona de agente para gerente. Enquanto em outra comunicação SNMP, o gerente solicita ativamente informações do agente, essas são PDUs que são enviadas do agente para o gerente sem serem explicitamente solicitadas. Os traps SNMP permitem que um agente notifique a estação de gerenciamento de eventos significativos por meio de uma mensagem SNMP não solicitada. As PDUs de trap incluem o valor sysUpTime atual , um OID que identifica o tipo de trap e ligações de variáveis ​​opcionais. O endereçamento de destino para traps é determinado de uma maneira específica do aplicativo, normalmente por meio de variáveis ​​de configuração de trap no MIB. O formato da mensagem de trap foi alterado no SNMPv2 e o PDU foi renomeado para SNMPv2-Trap .
InformRequest
Notificação assíncrona confirmada. Esta PDU foi introduzida no SNMPv2 e foi originalmente definida como comunicação de gerente para gerente . Implementações posteriores afrouxaram a definição original para permitir a comunicação entre o agente e o gerente . As notificações de gerente para gerente já eram possíveis no SNMPv1 usando um Trap , mas como o SNMP geralmente é executado em UDP, onde a entrega não é garantida e os pacotes descartados não são relatados, a entrega de um Trap não era garantida. InformRequest corrige isso, pois uma confirmação é devolvida no recebimento.

RFC  1157 especifica que uma implementação SNMP deve aceitar uma mensagem de pelo menos 484 bytes de comprimento. Na prática, as implementações SNMP aceitam mensagens mais longas. Se implementada corretamente, uma mensagem SNMP é descartada se a decodificação da mensagem falhar e, portanto, as solicitações SNMP malformadas são ignoradas. Uma solicitação SNMP decodificada com sucesso é então autenticada usando a string de comunidade. Se a autenticação falhar, um trap é gerado indicando uma falha de autenticação e a mensagem é eliminada.

SNMPv1 e SNMPv2 usam comunidades para estabelecer confiança entre gerentes e agentes. A maioria dos agentes oferece suporte a três nomes de comunidade, um para somente leitura, leitura e gravação e trap. Essas três cadeias de caracteres da comunidade controlam diferentes tipos de atividades. A comunidade somente leitura se aplica para obter solicitações. A string de comunidade de leitura e gravação se aplica a solicitações definidas . A string de comunidade de armadilhas se aplica ao recebimento de armadilhas . O SNMPv3 também usa strings de comunidade, mas permite autenticação e comunicação seguras entre o gerenciador SNMP e o agente.

Versões de protocolo

Na prática, as implementações SNMP geralmente oferecem suporte a várias versões: normalmente SNMPv1, SNMPv2c e SNMPv3.

Versão 1

SNMP versão 1 (SNMPv1) é a implementação inicial do protocolo SNMP. O design do SNMPv1 foi feito na década de 1980 por um grupo de colaboradores que viam o esforço oficialmente patrocinado da OSI / IETF / NSF (National Science Foundation) (HEMS / CMIS / CMIP) como não implementável nas plataformas de computação da época, bem como potencialmente impraticável. O SNMP foi aprovado com base na crença de que era um protocolo provisório necessário para a implementação em larga escala da Internet e sua comercialização.

A primeira solicitação de comentários (RFCs) para SNMP, agora conhecida como SNMPv1, apareceu em 1988:

  • RFC  1065  - Estrutura e identificação de informações de gerenciamento para internets baseados em TCP / IP
  • RFC  1066  - Base de informações de gerenciamento para gerenciamento de rede de internets baseados em TCP / IP
  • RFC  1067  - Um protocolo de gerenciamento de rede simples

Em 1990, esses documentos foram substituídos por:

  • RFC  1155  - Estrutura e identificação de informações de gerenciamento para internets baseados em TCP / IP
  • RFC  1156  - Base de informações de gerenciamento para gerenciamento de rede de internets baseados em TCP / IP
  • RFC  1157  - Um protocolo simples de gerenciamento de rede

Em 1991, o RFC  1156 (MIB-1) foi substituído pelo usado com mais frequência:

  • RFC  1213  - Versão 2 da base de informações de gerenciamento (MIB-2) para gerenciamento de rede de internets baseados em TCP / IP

SNMPv1 é amplamente usado e é o protocolo de gerenciamento de rede de fato na comunidade da Internet.

SNMPv1 pode ser transportado por protocolos de camada de transporte , como User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connection-mode Network Service (CLNS), AppleTalk Datagram Delivery Protocol (DDP) e Novell Internetwork Packet Exchange (IPX).

A versão 1 foi criticada por sua falta de segurança. A especificação permite, de fato, espaço para autenticação customizada a ser usada, mas implementações amplamente usadas "suportam apenas um serviço de autenticação trivial que identifica todas as mensagens SNMP como mensagens SNMP autênticas". A segurança das mensagens, portanto, torna-se dependente da segurança dos canais pelos quais as mensagens são enviadas. Por exemplo, uma organização pode considerar sua rede interna suficientemente segura para que nenhuma criptografia seja necessária para suas mensagens SNMP. Nesses casos, o "nome da comunidade", que é transmitido em texto não criptografado , tende a ser visto como uma senha de fato, apesar da especificação original.

Versão 2

O SNMPv2, definido pela RFC  1441 e RFC  1452 , revisa a versão 1 e inclui melhorias nas áreas de desempenho, segurança e comunicações de gerente para gerente. Ele introduziu GetBulkRequest , uma alternativa para GetNextRequests iterativo para recuperar grandes quantidades de dados de gerenciamento em uma única solicitação. O novo sistema de segurança baseado em partido introduzido no SNMPv2, visto por muitos como excessivamente complexo, não foi amplamente adotado. Esta versão do SNMP atingiu o nível de maturidade do Padrão proposto, mas foi considerada obsoleta por versões posteriores.

O protocolo de gerenciamento de rede simples baseado na comunidade versão 2 , ou SNMPv2c , é definido no RFC  1901 - RFC  1908 . O SNMPv2c compreende o SNMPv2 sem o polêmico novo modelo de segurança SNMP v2, usando, em vez disso, o esquema de segurança simples baseado na comunidade do SNMPv1. Esta versão é um dos poucos padrões que atendem ao nível de maturidade do Draft Standard da IETF e foi amplamente considerada o padrão SNMPv2 de fato . Posteriormente, foi reafirmado como parte do SNMPv3.

O protocolo de gerenciamento de rede simples com base no usuário versão 2 , ou SNMPv2u , é definido no RFC  1909 - RFC  1910 . Este é um compromisso que tenta oferecer maior segurança do que SNMPv1, mas sem incorrer na alta complexidade do SNMPv2. Uma variante disso foi comercializada como SNMP v2 * e o mecanismo foi eventualmente adotado como uma das duas estruturas de segurança do SNMP v3.

Contadores de 64 bits

O SNMP versão 2 apresenta a opção de contadores de dados de 64 bits. A versão 1 foi projetada apenas com contadores de 32 bits que podem armazenar valores inteiros de zero a 4,29 bilhões (precisamente 4.294.967.295). Um contador de versão 1 de 32 bits não pode armazenar a velocidade máxima de uma interface de 10 gigabit ou maior, expressa em bits por segundo. Da mesma forma, um contador de 32 bits que rastreia estatísticas para uma interface de 10 gigabits ou maior pode voltar a zero novamente em menos de um minuto, o que pode ser um intervalo de tempo menor do que um contador para ler seu estado atual. Isso resultaria em perda ou dados inválidos devido ao rollover de valor não detectado e corrupção de dados de rastreamento de tendência.

O contador da versão 2 de 64 bits pode armazenar valores de zero a 18,4 quintilhões (precisamente 18.446.744.073.709.551.615) e, portanto, é improvável que haja uma rolagem do contador entre os eventos de votação. Por exemplo, está previsto que a Ethernet de 1,6 terabit esteja disponível em 2025. Um contador de 64 bits incrementado a uma taxa de 1,6 trilhão de bits por segundo seria capaz de reter informações para tal interface sem passar por 133 dias.

Interoperabilidade SNMPv1 e SNMPv2c

O SNMPv2c é incompatível com o SNMPv1 em duas áreas principais: formatos de mensagem e operações de protocolo. As mensagens SNMPv2c usam formatos de unidade de dados de protocolo e cabeçalho (PDU) diferentes das mensagens SNMPv1. O SNMPv2c também usa duas operações de protocolo que não são especificadas no SNMPv1. Para superar a incompatibilidade, o RFC  3584 define duas estratégias de coexistência SNMPv1 / v2c: agentes proxy e sistemas bilíngues de gerenciamento de rede.

Agentes proxy

Um agente SNMPv2 pode atuar como um agente proxy em nome de dispositivos gerenciados SNMPv1. Quando um SNMPv2 NMS emite um comando destinado a um agente SNMPv1, ele o envia ao agente proxy SNMPv2. O agente proxy encaminha Get, GetNexte Setmensagens para o agente SNMPv1 inalterado. As mensagens GetBulk são convertidas pelo agente proxy em GetNextmensagens e, em seguida, encaminhadas ao agente SNMPv1. Além disso, o agente proxy recebe e mapeia mensagens de trap SNMPv1 para mensagens de trap SNMPv2 e as encaminha para o NMS.

Sistema de gerenciamento de rede bilíngue

Os sistemas bilíngues de gerenciamento de rede SNMPv2 suportam SNMPv1 e SNMPv2. Para oferecer suporte a esse ambiente de gerenciamento duplo, um aplicativo de gerenciamento examina as informações armazenadas em um banco de dados local para determinar se o agente oferece suporte a SNMPv1 ou SNMPv2. Com base nas informações do banco de dados, o NMS se comunica com o agente usando a versão apropriada do SNMP.

Versão 3

Embora o SNMPv3 não faça alterações no protocolo além da adição de segurança criptográfica, ele parece muito diferente devido às novas convenções textuais, conceitos e terminologia. A mudança mais visível foi definir uma versão segura do SNMP, adicionando segurança e aprimoramentos de configuração remota ao SNMP. O aspecto da segurança é abordado com a oferta de autenticação forte e criptografia de dados para privacidade. Para o aspecto de administração, o SNMPv3 concentra-se em duas partes, a saber, originadores de notificação e encaminhadores de proxy. As alterações também facilitam a configuração e administração remotas das entidades SNMP, bem como abordam questões relacionadas à implantação em grande escala, contabilidade e gerenciamento de falhas.

Recursos e aprimoramentos incluídos:

  • Identificação de entidades SNMP para facilitar a comunicação apenas entre entidades SNMP conhecidas - Cada entidade SNMP tem um identificador chamado SNMPEngineID, e a comunicação SNMP só é possível se uma entidade SNMP conhecer a identidade de seu par. Traps e notificações são exceções a esta regra.
  • Suporte para modelos de segurança - um modelo de segurança pode definir a política de segurança em um domínio administrativo ou uma intranet. SNMPv3 contém as especificações para um modelo de segurança baseado no usuário (USM).
  • Definição de objetivos de segurança onde os objetivos do serviço de autenticação de mensagens incluem proteção contra o seguinte:
    • Modificação de informações - proteção contra algumas entidades SNMP não autorizadas que alteram mensagens em trânsito geradas por um principal autorizado.
    • Máscara - Proteção contra tentativas de operações de gerenciamento não autorizadas para algum principal, assumindo a identidade de outro principal que tenha as autorizações apropriadas.
    • Modificação do fluxo de mensagens - proteção contra mensagens que são reordenadas, atrasadas ou reproduzidas de forma maliciosa para afetar operações de gerenciamento não autorizadas.
    • Divulgação - Proteção contra espionagem nas trocas entre os motores SNMP.
  • A especificação para USM - USM consiste na definição geral dos seguintes mecanismos de comunicação disponíveis:
    • Comunicação sem autenticação e privacidade (NoAuthNoPriv).
    • Comunicação com autenticação e sem privacidade (AuthNoPriv).
    • Comunicação com autenticação e privacidade (AuthPriv).
  • Definição de diferentes protocolos de autenticação e privacidade - os protocolos de autenticação MD5, SHA e HMAC-SHA-2 e os protocolos de privacidade CBC_DES e CFB_AES_128 são suportados no USM.
  • Definição de um procedimento de descoberta - Para encontrar o SNMPEngineID de uma entidade SNMP para um determinado endereço de transporte e endereço de terminal de transporte.
  • Definição do procedimento de sincronização de tempo - Para facilitar a comunicação autenticada entre as entidades SNMP.
  • Definição da estrutura SNMP MIB - Para facilitar a configuração e administração remota da entidade SNMP.
  • Definição dos MIBs USM - Para facilitar a configuração remota e administração do módulo de segurança.
  • Definição do modelo de controle de acesso baseado em visualização (VACM) MIBs - Para facilitar a configuração e administração remota do módulo de controle de acesso.

A segurança era uma das maiores fraquezas do SNMP até a v3. A autenticação nas versões 1 e 2 do SNMP equivale a nada mais do que uma senha (string de comunidade) enviada em texto não criptografado entre um gerente e um agente. Cada mensagem SNMPv3 contém parâmetros de segurança que são codificados como uma string de octeto. O significado desses parâmetros de segurança depende do modelo de segurança que está sendo usado. A abordagem de segurança em alvos v3:

  • Confidencialidade - criptografia de pacotes para evitar espionagem por uma fonte não autorizada.
  • Integridade - integridade da mensagem para garantir que um pacote não foi violado durante o trânsito, incluindo um mecanismo opcional de proteção contra reprodução de pacotes.
  • Autenticação - para verificar se a mensagem é de uma fonte válida.

A v3 também define o USM e o VACM, que foram seguidos posteriormente por um modelo de segurança de transporte (TSM) que fornecia suporte para SNMPv3 sobre SSH e SNMPv3 sobre TLS e DTLS.

  • O USM (modelo de segurança com base no usuário) fornece funções de autenticação e privacidade (criptografia) e opera no nível da mensagem.
  • O VACM (modelo de controle de acesso baseado em visualização) determina se um determinado principal tem permissão para acessar um objeto MIB específico para executar funções específicas e opera no nível de PDU.
  • TSM (Transport Security Model) fornece um método para autenticar e criptografar mensagens em canais de segurança externos. Dois transportes, SSH e TLS / DTLS, foram definidos para fazer uso da especificação TSM.

A partir de 2004, a IETF reconhece o Simple Network Management Protocol versão 3 conforme definido pelo RFC  3411 - RFC  3418 (também conhecido como STD0062) como a versão padrão atual do SNMP. O IETF designou SNMPv3 um padrão completo da Internet , o nível de maturidade mais alto para um RFC. Ele considera as versões anteriores obsoletas (designando-as de várias formas "Históricas" ou "Obsoletas").

Problemas de implementação

Os poderosos recursos de gravação do SNMP, que permitiriam a configuração de dispositivos de rede, não estão sendo totalmente utilizados por muitos fornecedores, em parte devido à falta de segurança nas versões SNMP anteriores ao SNMPv3 e em parte porque muitos dispositivos simplesmente não são capazes de ser configurados individualmente MIB object changes.

Alguns valores SNMP (especialmente valores tabulares) requerem conhecimento específico de esquemas de indexação de tabela, e esses valores de índice não são necessariamente consistentes em todas as plataformas. Isso pode causar problemas de correlação ao buscar informações de vários dispositivos que podem não empregar o mesmo esquema de indexação de tabela (por exemplo, buscar métricas de utilização de disco, em que um identificador de disco específico é diferente entre as plataformas).

Alguns dos principais fornecedores de equipamentos tendem a estender demais seus sistemas de controle e configuração centrados na interface de linha de comando (CLI).

Em fevereiro de 2002, o Centro de Coordenação da Equipe de Resposta a Emergências de Computadores (CERT-CC) do Carnegie Mellon Software Engineering Institute (CM-SEI) emitiu um parecer sobre SNMPv1, depois que o Grupo de Programação Segura da Oulu University conduziu uma análise completa do tratamento de mensagens SNMP. A maioria das implementações SNMP, independentemente da versão do protocolo que suportam, usa o mesmo código de programa para decodificar unidades de dados de protocolo (PDU) e problemas foram identificados neste código. Outros problemas foram encontrados com a decodificação de mensagens de trap SNMP recebidas pela estação de gerenciamento SNMP ou solicitações recebidas pelo agente SNMP no dispositivo de rede. Muitos fornecedores tiveram que emitir patches para suas implementações SNMP.

Implicações de segurança

Usando SNMP para atacar uma rede

Como o SNMP foi projetado para permitir que os administradores monitorem e configurem dispositivos de rede remotamente, ele também pode ser usado para penetrar em uma rede. Um número significativo de ferramentas de software pode fazer a varredura de toda a rede usando SNMP, portanto, erros na configuração do modo de leitura e gravação podem tornar uma rede suscetível a ataques.

Em 2001, a Cisco divulgou informações que indicavam que, mesmo no modo somente leitura, a implementação SNMP do Cisco IOS é vulnerável a certos ataques de negação de serviço . Esses problemas de segurança podem ser corrigidos por meio de uma atualização do IOS.

Se o SNMP não for usado em uma rede, ele deve ser desativado nos dispositivos de rede. Ao configurar o modo somente leitura SNMP, deve-se prestar muita atenção à configuração do controle de acesso e de quais endereços IP as mensagens SNMP são aceitas. Se os servidores SNMP forem identificados por seu IP, o SNMP só terá permissão para responder a esses IPs e as mensagens SNMP de outros endereços IP serão negadas. No entanto, a falsificação de endereço IP continua sendo uma preocupação de segurança.

Autenticação

O SNMP está disponível em diferentes versões, cada uma com seus próprios problemas de segurança. SNMP v1 envia senhas em texto não criptografado pela rede. Portanto, as senhas podem ser lidas com a detecção de pacotes . SNMP v2 permite hash de senha com MD5 , mas isso deve ser configurado. Praticamente todos os softwares de gerenciamento de rede suportam SNMP v1, mas não necessariamente SNMP v2 ou v3. O SNMP v2 foi desenvolvido especificamente para fornecer segurança de dados , ou seja , autenticação , privacidade e autorização , mas apenas o SNMP versão 2c obteve o endosso da Internet Engineering Task Force (IETF), enquanto as versões 2u e 2 * não obtiveram a aprovação do IETF devido à segurança questões. SNMP v3 usa MD5, Secure Hash Algorithm (SHA) e algoritmos de chave para oferecer proteção contra modificação de dados não autorizada e ataques de spoofing . Se um nível mais alto de segurança for necessário, o Data Encryption Standard (DES) pode ser usado opcionalmente no modo de encadeamento de bloco de criptografia . O SNMP v3 é implementado no Cisco IOS desde a versão 12.0 (3) T.

O SNMPv3 pode estar sujeito a ataques de força bruta e de dicionário para adivinhar as chaves de autenticação ou chaves de criptografia, se essas chaves forem geradas a partir de senhas curtas (fracas) ou que possam ser encontradas em um dicionário. O SNMPv3 permite fornecer chaves criptográficas aleatórias distribuídas de maneira uniforme e gerar chaves criptográficas a partir de uma senha fornecida pelo usuário. O risco de adivinhar strings de autenticação de valores de hash transmitidos pela rede depende da função de hash criptográfica usada e do comprimento do valor de hash. O SNMPv3 usa o protocolo de autenticação HMAC - SHA-2 para o User-Based Security Model (USM). O SNMP não usa um protocolo de autenticação de handshake de desafio mais seguro . SNMPv3 (como outras versões de protocolo SNMP) é um protocolo sem estado e foi projetado com uma quantidade mínima de interações entre o agente e o gerenciador. Assim, a introdução de um handshake de desafio-resposta para cada comando imporia uma carga ao agente (e possivelmente à própria rede) que os projetistas de protocolo consideraram excessiva e inaceitável.

As deficiências de segurança de todas as versões SNMP podem ser atenuadas pela autenticação IPsec e mecanismos de confidencialidade. O SNMP também pode ser transportado com segurança pelo Datagram Transport Layer Security (DTLS).

Muitas implementações SNMP incluem um tipo de descoberta automática em que um novo componente de rede, como um switch ou roteador, é descoberto e pesquisado automaticamente. No SNMPv1 e SNMPv2c, isso é feito por meio de uma string de comunidade que é transmitida em texto não criptografado para outros dispositivos. As senhas de texto não criptografado são um risco de segurança significativo. Uma vez que a string da comunidade é conhecida fora da organização, ela pode se tornar o alvo de um ataque. Para alertar os administradores sobre outras tentativas de coletar strings de comunidade, o SNMP pode ser configurado para passar traps de falha de autenticação de nome de comunidade. Se SNMPv2 for usado, o problema pode ser evitado habilitando a criptografia de senha nos agentes SNMP dos dispositivos de rede.

A configuração padrão comum para strings de comunidade é "pública" para acesso somente leitura e "privada" para leitura-gravação. Por causa dos padrões bem conhecidos, o SNMP encabeçou a lista de Problemas de Configuração Padrão Comum do SANS Institute e ficou em décimo lugar no ranking das 10 maiores ameaças de segurança da Internet do SANS no ano de 2000. Administradores de sistema e rede freqüentemente não os alteram configurações.

Quer seja executado sobre TCP ou UDP, SNMPv1 e v2 são vulneráveis ​​a ataques de falsificação de IP . Com o spoofing, os invasores podem ignorar as listas de acesso do dispositivo em agentes que são implementados para restringir o acesso SNMP. Os mecanismos de segurança SNMPv3, como USM ou TSM, evitam um ataque de falsificação bem-sucedido.

Referências RFC

  • RFC  1155 (STD 16) - Estrutura e Identificação de Informações Gerenciais para as Internets baseadas em TCP / IP
  • RFC  1156 (histórico) - Base de informações de gerenciamento para gerenciamento de rede de internets baseados em TCP / IP
  • RFC  1157 (histórico) - Um protocolo de gerenciamento de rede simples (SNMP)
  • RFC  1213 (STD 17) - Management Information Base for Network Management of TCP / IP-based internets: MIB-II
  • RFC  1452 (Informativo) - Coexistência entre a versão 1 e a versão 2 do Network Management Framework padrão da Internet (obsoleto pelo RFC  1908 )
  • RFC  1901 (Experimental) - Introdução ao SNMPv2 baseado na comunidade
  • RFC  1902 (Rascunho do padrão) - Estrutura de informações de gerenciamento para SNMPv2 (obsoleto pelo RFC  2578 )
  • RFC  1908 (Standards Track) - Coexistência entre a versão 1 e a versão 2 da estrutura de gerenciamento de rede padrão da Internet
  • RFC  2570 (Informativo) - Introdução à versão 3 do Network Management Framework padrão da Internet (obsoleto pelo RFC  3410 )
  • RFC  2578 (STD 58) - Estrutura de informações de gerenciamento versão 2 (SMIv2)
  • RFC  3410 (informativo) - declarações de introdução e aplicabilidade para o Internet Standard Management Framework
  • STD 62 contém os seguintes RFCs:
    • RFC  3411  - Uma arquitetura para descrever estruturas de gerenciamento de protocolo de gerenciamento de rede simples (SNMP)
    • RFC  3412  - Processamento e envio de mensagens para o protocolo de gerenciamento de rede simples (SNMP)
    • RFC  3413  - Aplicativos de protocolo de gerenciamento de rede simples (SNMP)
    • RFC  3414  - Modelo de segurança baseado no usuário (USM) para a versão 3 do protocolo de gerenciamento de rede simples (SNMPv3)
    • RFC  3415  - Modelo de controle de acesso baseado em visualização (VACM) para o protocolo de gerenciamento de rede simples (SNMP)
    • RFC  3416  - Versão 2 do Protocolo de Operações para o Simple Network Management Protocol (SNMP)
    • RFC  3417  - Mapeamentos de transporte para o protocolo de gerenciamento de rede simples (SNMP)
    • RFC  3418  - Management Information Base (MIB) para o Simple Network Management Protocol (SNMP)
  • RFC  3430 (Experimental) - Simple Network Management Protocol (SNMP) sobre Transmission Control Protocol (TCP) Transport Mapping
  • RFC  3584 (BCP 74) - Coexistência entre a versão 1, a versão 2 e a versão 3 da estrutura de gerenciamento de rede padrão da Internet
  • RFC  3826 (proposto) - O algoritmo de criptografia do padrão de criptografia avançado (AES) no modelo de segurança baseado no usuário SNMP
  • RFC  4789 (proposto) - Protocolo de gerenciamento de rede simples (SNMP) sobre redes IEEE 802
  • RFC  5343 (STD 78) - Simple Network Management Protocol (SNMP) Context EngineID Discovery
  • RFC  5590 (STD 78) - Subsistema de transporte para o protocolo de gerenciamento de rede simples (SNMP)
  • RFC  5591 (STD 78) - Modelo de segurança de transporte para o protocolo de gerenciamento de rede simples (SNMP)
  • RFC  5592 (proposto) - modelo de transporte seguro de shell para o protocolo de gerenciamento de rede simples (SNMP)
  • RFC  5608 (proposto) - Uso do RADIUS (Remote Authentication Dial-In User Service) para modelos de transporte SNMP (Simple Network Management Protocol).
  • RFC  6353 (STD 78) - Modelo de transporte de segurança da camada de transporte (TLS) para o protocolo de gerenciamento de rede simples (SNMP)
  • RFC  7630 (proposto) - Protocolos de autenticação HMAC-SHA-2 no modelo de segurança baseado no usuário (USM) para SNMPv3

Veja também

Referências

Leitura adicional

links externos