SNMP
Gerência Internet: Introdução 2 À exemplo do que ocorre com a abordagem da ISO, a arquitetura SNMP define também um modelo de comunicação e um modelo de informação. Essa arquitetura tem incorporado várias inovações ao longo de sua existência, de forma que existem atualmente três versões: SNMPv1 SNMPv2 SNMPv3
3 SNMPv1
SNMPv1: Especificações 4 Principais especificações relativas à primeira versão do protocolo SNMP (SNMPv1): RFC Título 1155 Structure and identification of management information for TCP/IP-based internets 1157 Simple Network Management Protocol (SNMP) 1212 Concise MIB definitions 1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II (Updated by RFC 2011, RFC 2012, RFC 2013)
Mensagens SNMPv1 5 Do gerente para o agente: get getnext set Do agente para o gerente: getresponse trap
Formato da mensagem e das PDUs SNMPv1 6
SNMPv1: Comunidades 7 Um nome de comunidade representa um relacionamento entre um agente e um (ou vários) gerentes, definindo características de autenticação e controle de acesso. O nome de comunidade não é encriptado, o que restringe muitas vezes a gerência à simples monitoração.
SNMPv1: Operações de Leitura 8 As operações de leitura dos valores de um ou mais objetos gerenciados são iniciadas pelos gerentes com o envio de PDUs GetRequest ou GetNextRequest. Essas PDUs são endereçadas à porta UDP 161 do agente SNMPv1 remoto.
SNMPv1: Respostas da Leitura 9 As PDUs GetRequest e GetNextRequest são replicadas atomicamente com o envio de PDUs GetResponse.
SNMPv1: Operações de Escrita 10 As operações de escrita dos valores de um ou mais objetos gerenciados são iniciadas pelos gerentes com o envio de PDUs SetRequest. Essas PDUs também são endereçadas à porta UDP 161 do agente SNMPv1 remoto.
SNMPv1: Respostas da Escrita 11 As PDUs SetRequest também é replicada atomicamente com o envio de uma PDU GetResponse.
SNMPv1: Mensagem Trap 12 A PDU Trap é uma notificação assíncrona utilizada pelo agente SNMP para informar um ou mais gerentes sobre algum evento significativo. Essa PDU é endereçada à porta UDP 162 do(s) gerente(s).
SNMPv1: Regras de Codificação 13 PDUs e objetos gerenciados são codificados para transmissão usando-se BER (Basic Encoding Rules). Em BER, cada elemento é estruturado como uma lista TLV (Type, Length, Value).
SNMPv1: Deficiências 14 Deficiências observadas no SNMPv1: Inabilidade em coletar um grande volume de dados Não é possível obter visões consistentes de tabelas de objetos gerenciados. Escalabilidade limitada Modelo é fortemente centralizado em torno de uma única estação de gerência. Ausência de mecanismos eficazes de segurança Nome de comunidade não sofre encriptação, inibindo a realização de operações mais sensíveis.
15 SNMPv2
Gerência Internet: SNMPv2 16 Um conjunto de RFCs referenciadas como SNMPseguro foram emitidas com o status de Proposed Standard em julho de 1992. O SNMP-seguro endereçava exclusivamente aspectos de segurança ausentes no SNMPv1. Outra abordagem denominada SMP (Simple Management Protocol) foi emitida também em julho de 1992 sob a forma de oito documentos (não RFCs) submetidos à IETF.
Gerência Internet: SNMPv2 17 Além de endereçar aspectos de desempenho e funcionalidade, o SMP incorporava também as melhorias de segurança propostas pelo SNMP-seguro. Após a publicação do SNMP-seguro e do SMP, surgiu um consenso na comunidade Internet de que era hora de se criar uma segunda versão para o SNMP. Dois grupos de trabalho foram formados: um deles endereçava aspectos de segurança, enquanto o outro endereçava os demais aspectos. O esforço combinado foi publicado como Internet Standards em Março de 1993.
Gerência Internet: SNMPv2 18 Após anos de experiência como SNMPv2, um Grupo de Trabalho da IETF revisou as especificações. O resultado dessa revisão foi um novo conjunto de RFCs, emitidas em 1996. Os sofisticados mecanismos de segurança do SNMPv2 foram substituídos por outro baseado em nomes de comunidade, como é utilizado no SNMPv1. Por essa razão, o SNMPv2 atualmente vigente também é conhecido como SNMPv2c (Community-based).
SNMPv2: Especificações 19 RFC Título 1901 Introduction to Community-Based SNMPv2 2578 Structure of Management Information Version 2 (SMIv2) 2579 Textual Conventions for SMIv2 2580 Conformance Statements for SMIv2 3416 Protocol Operations for SNMPv2 3417 Transport Mappings for SNMPv2 3418 Management Information Base for SNMPv2 3584 Coexistence Between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
SNMPv2: SMIv2 20 A SMI definida para o SNMPv2 é um superconjunto daquela definida para o SNMPv1. Ela estabelece mecanismos mais elaborados para a definição de objetos gerenciados e MIBs. As melhorias providas concentraram-se nas seguintes áreas: Definição de objetos Tabelas conceituais Definição de notificações Módulos de informação
21 SMIv2
Mensagens SNMPv2 e 3 22 Do gerente para o agente: get getnext Set getbulk inform report Do agente para o gerente: getresponse trap getbulkresponse inform report
Formato da mensagem e das PDUs SNMPv2 23
SNMPv2: Respostas de Leitura 24 As PDUs GetRequest e GetNextRequest são replicadas com o envio de PDUs Response neste caso, porém, respostas parciais são permitidas.
SNMPv2: GetBulkRequest 25 As PDUs GetBulkRequest foi criada especificamente para a tarefa de coleta volumosa de dados. Essa PDU tem dois campos não encontrados em quaisquer outras PDUs: non-repeaters e max-repetitions.
SNMPv2: GetBulkRequest 26 non-repeaters: Qtde. de variáveis presentes em variablebindings para as quais uma única instância é retornada. max-repetitions: Qtde. de instâncias a serem retornadas para as variáveis restantes de variablebindings.
SNMPv2: GetBulkRequest 27 Exemplo de utilização da PDU GetBulkRequest:
SNMPv2: SetRequest 28 PDUs SetRequest são replicadas com PDUs Response. O processamento que ocorre na troca dessas PDUs difere um pouco daquele que ocorre no SNMPv1.
SNMPv2: InformRequest 29 PDUs InformRequest são trocadas entre gerentes SNMPv2, sendo replicadas por PDUs Response. Elas introduzem descentralização à arquitetura SNMP.
SNMPv2: InformRequest 30 Exemplo de utilização da PDU InformRequest:
SNMPv2: Trap 31 As PDU TRAP SNMPv2 difere em formato daquela definida para o SNMPv1. Porém, assim como acontece no SNMPv1, nenhuma réplica é emitida.
SNMPv2: Avaliação 32 Vantagens introduzidas pelo SNMPv2: SMI mais elaborada, com maior número de tipos e facilidades de manipulação de tabelas. Facilidade de coleta volumosa de dados, mediante criação de uma PDU especializada em tal tarefa. Modelo mais descentralizado, também viabilizado através de uma PDU especialmente criada para tal. Deficiência ainda observada: Ausência de mecanismos eficazes de segurança na troca de PDUs entre gerentes e agentes.
33 SNMPv3
SNMPv3 34 Vários grupos independentes começaram a trabalhar em melhorias de segurança para o SNMPv2. Duas abordagens sobressaíram-se: SNMPv2u e SNMPv2*. Elas serviram como insumo para o Grupo de Trabalho SNMPv3 da IETF, em Março de 1997. Em Janeiro de 1998, esse grupo produziu uma série de documentos com o status de Proposed Standard. Em Dezembro de 2002, estes documentos foram atualizados e receberam o status de Internet Standard. O SNMPv3 incorpora as funcionalidades definidas nas versões anteriores e adiciona mecanismos de segurança à arquitetura.
35 Evolução da Arquitetura SNMP
Especificações SNMPv3 36 RFC Título Data 3410 Introduction and Applicability Statements for Internet-Standard Management Framework 3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks (Updated by RFC 5343, RFC 5590) 3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) (Updated by RFC 5590) Dez. 2002 Dez. 2002 Dez. 2002 3413 Simple Network Management Protocol (SNMP) Applications Dez. 2002 3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) (Updated by RFC 5590) 3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) Dez. 2002 Dez. 2002
37 Arquitetura SNMP atual
38 +------------------------------+ Network +------------------------------+ ^ ^ ^ v v v +-------------------------------------------------------------------+ +--------------------------------------------------+ Transport Subsystem +-----+ +-----+ +-----+ +-----+ +-------+ UDP TCP SSH TLS... other +-----+ +-----+ +-----+ +-----+ +-------+ +--------------------------------------------------+ ^ Dispatcher v +-------------------+ +---------------------+ +----------------+ Transport Message Processing Security Dispatch Subsystem Subsystem +------------+ +------------+ +-> v1mp <---> USM +------------+ +------------+ +------------+ +------------+ +-> v2cmp <---> Transport Message +------------+ Security Dispatch <---------> +------------+ Model +-> v3mp <---> +------------+ +------------+ +------------+ PDU Dispatch +------------+ Other +-------------------+ +-> othermp <---> Model(s) ^ +------------+ +------------+ +---------------------+ +----------------+ v +-------+-------------------------+---------------+ ^ ^ ^ v v v +-------------+ +---------+ +--------------+ +-------------+ COMMAND ACCESS NOTIFICATION PROXY RESPONDER <-> CONTROL <-> ORIGINATOR FORWARDER Application Applications Application +-------------+ +---------+ +--------------+ +-------------+ ^ ^ v v +----------------------------------------------+ MIB instrumentation SNMP entity +-------------------------------------------------------------------+
39 Gerente SNMPv3
Gerente SNMPv3 40 O Dispatcher pode ser compreendido como um simples gerente de tráfego.
Gerente SNMPv3 41 O Subsistema de Processamento de Mensagens prepara mensagens para transmissão e processa mensagens recebidas.
Gerente SNMPv3 42 O Subsistema de Segurança realiza funções de autenticação e privacidade.
43 Agente SNMPv3
Agente SNMPv3 44 O Subsistema de Controle de Acesso provê serviços de autorização para controlar o acesso às MIBs para leitura e escrita de valores de objetos gerenciados.
Fluxo de Mensagens 45 Fluxo originado por um Gerador de Comandos ou um Gerador de Notificações.
Fluxo de Mensagens 46 Fluxo originado por um Respondedor de Comandos.
47 Formato da Mensagem SNMPv3
Formato da Mensagem SNMPv3 48 msgversion: setado para snmpv3 (3).
Formato da Mensagem SNMPv3 49 msgid: identificador único usado por duas entidades SNMP para coordenação de mensagens de solicitação e resposta. Vai de 0 até 2 31-1.
Formato da Mensagem SNMPv3 50 msgmaxsize: tamanho máximo da mensagem enviada ou recebida por uma entidade SNMP. Vai de 484 até 2 31-1 octetos.
Formato da Mensagem SNMPv3 51 msgflags: um octeto contendo três flags nos seus três dígitos menos significativos: reportableflag, provflag e authflag.
Formato da Mensagem SNMPv3 52 Comentários sobre o msgflags: Se reportflag for setado em 1, uma PDU Report deve ser enviada (caso das PDUs Get/SetRequest e Inform). O contrário ocorre quando ela é setada em 0 (caso para PDUs Response, Trap e Report). Para os bits privflag e authflag, o comportamento é o seguinte:
Formato da Mensagem SNMPv3 53 msgsecuritymodel: indica qual modelo de segurança foi utilizado para o preparo da mensagem. Vai de 0 até 2 31-1. Valores reservados são 1 (SNMPv1), 2 (SNMPv2) e 3 (SNMPv3).
Formato da Mensagem SNMPv3 54 msgglobaldata: contém parâmetros necessários pelo Subsistema de Processamento de Mensagens para coordenação das mensagens.
Formato da Mensagem SNMPv3 55 msgsecurityparameters: contém parâmetros relacionados ao Subsistema de Segurança, não sendo portanto interpretados pelo Subsistema de Processamento de Mensagens ou o Dispatcher.
Formato da Mensagem SNMPv3 56 contextengineid: identifica inequivocamente uma entidade SNMP.
Formato da Mensagem SNMPv3 57 contextname: identifica inequivocamente um contexto particular dentro do escopo de um contextengineid associado.
Formato da Mensagem SNMPv3 58 scopepdu: informação necessária pelas aplicações de processamento das PDUs. Contém uma PDU num contexto que é inequivocamente identificado pelos campos contextname e contextengineid.
Conceitos de Segurança 59 Confidencialidade (Sigilo): apenas o remetente e o destinatário pretendido devem entender o conteúdo da mensagem remetente cifra (codifica) msg destinatário decifra (decodifica) msg Autenticação: remetente e destinatário querem confirmar a identidade um do outro Integridade e não-repudiação de Mensagem: remetente e destinatário querem garantir que a mensagem não seja alterada (em trânsito ou após) sem que isto seja detectado Disponibilidade e Controle de Acesso: os serviços devem estar acessíveis e disponíveis para os usuários
Melhorias de Segurança 60 USM User-based Security Model VACM View Access Control Model
USM User-based Security Model 61 O USM (User-based Security Model) do SNMPv3 oferece proteção contra os seguintes ataques: Modificação da informação Mascaramento Modificação do fluxo de mensagens Observação do conteúdo de mensagens Porém, o USM não protege contra os seguintes ataques: Negação de serviço Análise de tráfego
Núcleo com Autoridade 62 Conceito de Núcleo com Autoridade (authoritative engine): Se uma mensagem contiver uma PDU que requer uma resposta (Get, GetNext, GetBulk, Set ou Inform), então seu receptor será o núcleo com autoridade. Se uma mensagem contiver uma PDU que não requer uma resposta (Trap, Response ou Report), então seu emissor será o núcleo com autoridade. Conclusão: Considerando um modelo simples gerente-agente, é o agente quem possui o núcleo autorizado.
Núcleo com Autoridade 63 Qual a importância desta definição? A pontualidade da mensagem é determinada em relação ao relógio mantido pelo núcleo com autoridade As mensagens enviadas contêm o valor de relógio deste núcleo e o receptor (sem autoridade) pode sincronizar com este relógio Processo de localização de chave, permite que uma entidade principal possua chaves armazenadas em múltiplos núcleos (engines)
Objetos 64 Objetos snmpengineboots e snmpenginetime: São mantidos por núcleos autorizados, sendo inicialmente setados em 0. snmpenginetime é incrementado a cada segundo, até chegar a 2 31 1. Nesse valor, snmpengineboots é incrementado e snmpenginetime é setado em 0 e recomeça a ser incrementado. se o sistema for reinicializado, snmpengineboots será incrementado e snmpenginetime será setado em 0 e recomeçará a ser incrementado.
Objetos 65 Interpretação dada para esses objetos: snmpengineboots representa a quantidade de vezes em que o núcleo autorizado foi (re)inicializado desde a sua configuração original. snmpenginetime representa a quantidade de segundos decorridos desde a última (re)inicialização do núcleo autorizado. Propósito desses objetos: permitir a sincronização entre núcleos SNMP.
Formato da Mensagem SNMPv3 66 msgauthoritativeengineid: identificador do núcleo com autoridade envolvido na troca dessa mensagem.
Formato da Mensagem SNMPv3 67 msgauthoritativeengineboots: valor do snmpengineboots no núcleo com autoridade envolvido na troca dessa mensagem.
Formato da Mensagem SNMPv3 68 msgauthoritativeenginetime: valor do snmpenginetime no núcleo com autoridade envolvido na troca dessa mensagem.
Formato da Mensagem SNMPv3 69 msgusername: o usuário (principal) em cujo interesse a mensagem está sendo trocada.
Formato da Mensagem SNMPv3 70 msgauthenticationparameters: Null se a autenticação não estiver sendo utilizada nessa troca. Caso contrário, esse é um parâmetro de autenticação (para o USM, um código de autenticação de mensagem HMAC Hash-based Message Authentication Code).
Formato da Mensagem SNMPv3 71 msgprivacyparameters: Null se a privacidade não estiver sendo utilizada nessa troca. Caso contrário, esse é um parâmetro de privacidade (para o USM, um valor usado para formar o IV (Initial Vector) do modo CBC (Cipher Block Chaining ) do algoritmo DES (Data Encryption Standard). A RFC3826 apresenta o uso do AES (Advanced Encryption Standard)
72 Sincronização
73 Sincronização
Estabelecimento de janelas de tempo 74 As mensagens devem ser recebidas dentro de uma janela de tempo razoável para evitar atrasos e ataques de reprodução (replay) Fatores determinantes para o projeto: precisão dos relógios envolvidos atrasos fim-a-fim frequência de sincronização Implicação dos erros cometidos no projeto: janelas muito pequenas rejeitarão mensagens autênticas. janelas muito grandes aumentarão a vulnerabilidade aos ataques por réplica ou atraso.
75 Estabelecimento de janelas de tempo
76 Estabelecimento de janelas de tempo
Sincronização e Janelas de Tempo 77 Observação: Os mecanismos de sincronização e janelas de tempo só podem ser aplicados se: 1. Autenticação for empregada. 2. A mensagem for considerada autêntica via HMAC. Essa restrição é essencial porque o escopo da autenticação inclui os campos msgauthoritativeengineid, msgauthoritativeengineboots e msgauthoritativeenginetime.
Descoberta 78 O USM requer o uso de um processo de descoberta para obter informação suficiente sobre núcleos com autoridade antes de qualquer comunicação. Através da descoberta, um núcleo SNMP sem autoridade aprende o valor do ID do núcleo com autoridade e entra em sincronismo com esse núcleo. O processo de descoberta é composto por dois passos, sendo o primeiro deles obrigatório. O segundo é dado apenas quando a autenticação for necessária. A ser descritos a seguir.
Descoberta 79 Passo 1: núcleo sem autoridade aprende a ID do núcleo com autoridade.
Descoberta 80 Passo 2: núcleo sem autoridade estabelece sincronismo com núcleo com autoridade.
USM: Funções Criptográficas 81 No USM, são utilizadas duas funções criptográficas: autenticação e privacidade. Para suportá-las, cada núcleo SNMP mantém um par de chaves authkey e privkey para cada um dos núcleos com os quais se comunica. Os valores de authkey e privkey servem de subsídio para a geração e verificação dos campos msgauthenticationparameters e msgprivacyparameters. Porém, eles não são acessíveis através do SNMPv3.
Geração de Parâmetros de Autenticação e Privacidade 82
83 MIB usmuser
84 Criação da Mensagem junto ao USM
85 Recepção da Mensagem junto ao USM
Gerência de Chaves 86 Os pares authkey e privkey usados na comunicação entre um núcleo SNMP e vários outros núcleos são, na verdade, derivados de um único par de chaves. As chaves authkey e privkey são chamadas de chaves locais. A gerência de chaves lida com a criação do par de chaves originais e com a geração e atualização das chaves locais.
Gerência de Chaves: geração do par de chaves original 87 As chaves de autenticação e privacidade originais (string de bits) são geradas a partir de senhas. O processo de geração dessas chaves não utiliza nenhum repositório externo especializado no armazenamento de chaves. Além disso, ele aumenta a lentidão na execução de ataques do estilo força bruta. É composto por dois passos.
Gerência de Chaves: geração do par de chaves original 88
Gerência de Chaves: geração de chaves locais 89 Consiste no processo, composto por dois passos, para a geração de subchaves (chaves locais). Objetiva evitar as seguintes medidas: Um usuário tenha que relembrar pares de chaves cuja quantidade aumenta com a adição de novos sistemas gerenciados. Um adversário aprenda uma chave para um agente e esteja apto a personificar qualquer outro agente para qualquer usuário, ou vice-versa.
Geração de chaves originais e chaves locais 90
VACM View-based Access Control Model 91 Determina se o acesso a objetos gerenciados numa MIB local por entidades remotas deve ser permitida. Utiliza uma MIB que define a política de controle de acesso para este agente, tornando possível configurações remotas. Define cinco elementos: Grupos, Nível de Segurança, Contextos, Visões de MIB e Política de Acesso.
Grupos 92 Grupo: é definido como um conjunto de tuplas <securityname,securitymodel>, ao qual associa-se um groupname. securityname e securitymodel são equivalentes aos campos msgusername e msgsecuritymodel da mensagem SNMPv3.
Nível de Segurança 93 Nível de Segurança: obtido a partir do campo msgflags da mensagem SNMPv3. Apenas relembrando... noauthnopriv authnopriv authpriv
Contextos 94 Contexto: trata-se de um subconjunto de objetos gerenciados numa MIB local. Uma determinada entidade SNMP é identificada por um contextengineid. Esta entidade pode manter vários contextos diferentes. Cada um destes contextos é identificado por um contextname diferente.
Visões de MIB 95 Visão de MIB: é definida em termos de uma coleção, ou família, de subárvores de MIBs. Uma tabela que faz uso de subárvores para definir subconjuntos de objetos gerenciados possui os seguintes parâmetros: Subtree: OID que identifica a subárvore. Mask: permite refinar a identificação da subárvore no nível de objetos gerenciados individuais. Type: informa se a subárvore está incluída ou excluída da Visão.
Política de Acesso 96 Política de Acesso: baseia-se nos seguintes parâmetros: A entidade solicitando o acesso (principal). O nível de segurança empregado na solicitação. O modelo de segurança utilizado para processamento da mensagem de solicitação. O contexto da MIB para a solicitação. O objeto gerenciado solicitado. O tipo de acesso solicitado (leitura, escrita ou notificação).
MIB VACM (View-based Access Control Model) 97
98 Lógica do VACM
Parâmetros da MIB VACM 99 Parâmetros da MIB VACM para configuração inicial Semi-Security.
100 SNMP: Limitações do Modelo
SNMP: Limitações do Modelo 101 Escalabilidade e eficiência Aumento do overhead da rede Aumento de atrasos (latência) Capacidade de processamento do gerente Limite de segmento do gerente
SNMP: Limitações do Modelo 102 Escalabilidade e eficiência Transferência ineficiente de grande quantidade de dados Limitação do get-next Get-bulk overshoot effect Tamanho máximo de mensagem SNMP datagrama UDP Ausência de mecanismos de compressão Baixa eficiência do BER Protocolo de transporte não confiável (UDP)
SNMP: Limitações do Modelo 103 Segurança Mecanismo de comunidades limitado (v1/v2) Não pode ser considerado como autenticação Texto da comunidade trafega em claro Configurações complexas no SNMPv3 Mecanismo de Chaves Compartilhadas inseguro (v3) Dificuldade de atravessar Firewalls
SNMP: Limitações do Modelo 104 Gerenciamento Integrado e Configurações de redes Modelo de informações limitado Não orientado a objetos Não hierárquico Difícil programação de Interfaces de Gerenciamento mais aprimoradas devidos às limitações