SNMP Baseado em slides gentilmente cedidos pelo Prof. João Henrique Kleinschmidt da UFABC.

Apresentação em tema: "SNMP Baseado em slides gentilmente cedidos pelo Prof. João Henrique Kleinschmidt da UFABC."— Transcrição da apresentação:

1 SNMP Baseado em slides gentilmente cedidos pelo Prof. João Henrique Kleinschmidt da UFABC.

2 Gerência Internet: Introdução
À 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

4 SNMPv1: Especificações
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)

5 Mensagens SNMPv1 Do gerente para o agente: Do agente para o gerente:
get getnext set Do agente para o gerente: getresponse trap

6 Formato da mensagem e das PDUs SNMPv1

7 SNMPv1: Comunidades 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. Firewalls podem ajudar a restringir o acesso aos agentes apenas pelos NMS conhecidos e a não aceitar traps oriundas de equipamentos não gerenciados. Outra alternativa: mudança frequente do nome da comunidade...

8 SNMPv1: Operações de Leitura
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.

9 SNMPv1: Respostas da Leitura
As PDUs GetRequest e GetNextRequest são replicadas atomicamente com o envio de PDUs GetResponse.

10 SNMPv1: Operações de Escrita
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.

11 SNMPv1: Respostas da Escrita
As PDUs SetRequest também é replicada atomicamente com o envio de uma PDU GetResponse.

12 SNMPv1: Mensagem Trap 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).

13 SNMPv1: Regras de Codificação
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).

14 SNMPv1: Deficiências 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

16 Gerência Internet: SNMPv2
Um conjunto de RFCs referenciadas como SNMP- seguro 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.

17 Gerência Internet: SNMPv2
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

18 Gerência Internet: SNMPv2
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).

19 SNMPv2: Especificações
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

20 SNMPv2: SMIv2 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

22 Mensagens SNMPv2 e 3 Do gerente para o agente:
get getnext Set getbulk inform report Do agente para o gerente: getresponse trap getbulkresponse

23 Formato da mensagem e das PDUs SNMPv2

24 SNMPv2: Respostas de Leitura
As PDUs GetRequest e GetNextRequest são replicadas com o envio de PDUs Response – neste caso, porém, respostas parciais são permitidas.

25 SNMPv2: GetBulkRequest
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.

26 SNMPv2: GetBulkRequest
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.

27 SNMPv2: GetBulkRequest
Exemplo de utilização da PDU GetBulkRequest:

28 SNMPv2: SetRequest PDUs SetRequest são replicadas com PDUs Response.
O processamento que ocorre na troca dessas PDUs difere um pouco daquele que ocorre no SNMPv1.

29 SNMPv2: InformRequest PDUs InformRequest são trocadas entre gerentes SNMPv2, sendo replicadas por PDUs Response. Elas introduzem descentralização à arquitetura SNMP.

30 SNMPv2: InformRequest Exemplo de utilização da PDU InformRequest:

31 SNMPv2: Trap As PDU TRAP SNMPv2 difere em formato daquela definida para o SNMPv1. Porém, assim como acontece no SNMPv1, nenhuma réplica é emitida.

32 SNMPv2: Avaliação 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

34 SNMPv3 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
SGMP = Simple Gateway Management Protocol.

36 Especificações SNMPv3 RFC Título Data 3410
Introduction and Applicability Statements for Internet-Standard Management Framework Dez. 2002 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) 3413 Simple Network Management Protocol (SNMP) Applications 3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) 3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

37 Arquitetura SNMP atual

38 RFC 5590 +------------------------------+ | 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 | RFC 5590

39 Gerente SNMPv3

40 Gerente SNMPv3 O Dispatcher pode ser compreendido como um simples gerente de tráfego.

41 Gerente SNMPv3 O Subsistema de Processamento de Mensagens prepara mensagens para transmissão e processa mensagens recebidas.

42 Gerente SNMPv3 O Subsistema de Segurança realiza funções de autenticação e privacidade.

43 Agente SNMPv3

44 Agente SNMPv3 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.

45 Fluxo de Mensagens Fluxo originado por um Gerador de Comandos ou um Gerador de Notificações.

46 Fluxo de Mensagens Fluxo originado por um Respondedor de Comandos.

47 Formato da Mensagem SNMPv3

48 Formato da Mensagem SNMPv3
msgVersion: setado para snmpv3 (3).

49 Formato da Mensagem SNMPv3
msgID: identificador único usado por duas entidades SNMP para coordenação de mensagens de solicitação e resposta. Vai de 0 até

50 Formato da Mensagem SNMPv3
msgMaxSize: tamanho máximo da mensagem enviada ou recebida por uma entidade SNMP. Vai de 484 até octetos.

51 Formato da Mensagem SNMPv3
msgFlags: um octeto contendo três flags nos seus três dígitos menos significativos: reportableFlag, provFlag e authFlag.

52 Formato da Mensagem SNMPv3
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:

53 Formato da Mensagem SNMPv3
msgSecurityModel: indica qual modelo de segurança foi utilizado para o preparo da mensagem. Vai de 0 até Valores reservados são 1 (SNMPv1), 2 (SNMPv2) e 3 (SNMPv3).

54 Formato da Mensagem SNMPv3
msgGlobalData: contém parâmetros necessários pelo Subsistema de Processamento de Mensagens para coordenação das mensagens.

55 Formato da Mensagem SNMPv3
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.

56 Formato da Mensagem SNMPv3
contextEngineID: identifica inequivocamente uma entidade SNMP.

57 Formato da Mensagem SNMPv3
contextName: identifica inequivocamente um contexto particular dentro do escopo de um contextEngineID associado.

58 Formato da Mensagem SNMPv3
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.

59 Conceitos de Segurança
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 Maiores informações: Capítulo 8 de Kurose e Ross.

60 Melhorias de Segurança
USM – User-based Security Model VACM – View Access Control Model

61 USM – User-based Security Model
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

62 Núcleo com Autoridade 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.

63 Núcleo com Autoridade 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)

64 Objetos Objetos snmpEngineBoots e snmpEngineTime:
São mantidos por núcleos autorizados, sendo inicialmente setados em 0. snmpEngineTime é incrementado a cada segundo, até chegar a 231− 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.

65 Objetos 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.

66 Formato da Mensagem SNMPv3
msgAuthoritativeEngineID: identificador do núcleo com autoridade envolvido na troca dessa mensagem.

67 Formato da Mensagem SNMPv3
msgAuthoritativeEngineBoots: valor do snmpEngineBoots no núcleo com autoridade envolvido na troca dessa mensagem.

68 Formato da Mensagem SNMPv3
msgAuthoritativeEngineTime: valor do snmpEngineTime no núcleo com autoridade envolvido na troca dessa mensagem.

69 Formato da Mensagem SNMPv3
msgUserName: o usuário (principal) em cujo interesse a mensagem está sendo trocada.

70 Formato da Mensagem SNMPv3
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).

71 Formato da Mensagem SNMPv3
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 LRET = Latest Received Engine Time

73 Sincronização p. 503

74 Estabelecimento de janelas de tempo
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

77 Sincronização e Janelas de Tempo
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.

78 Descoberta 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.

79 Descoberta Passo 1: núcleo sem autoridade aprende a ID do núcleo com autoridade.

80 Descoberta Passo 2: núcleo sem autoridade estabelece sincronismo com núcleo com autoridade.

81 USM: Funções Criptográficas
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.

82 Geração de Parâmetros de Autenticação e Privacidade

83 MIB usmUser

84 Criação da Mensagem junto ao USM

85 Recepção da Mensagem junto ao USM

86 Gerência de Chaves 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.

87 Gerência de Chaves: geração do par de chaves original
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.

88 Gerência de Chaves: geração do par de chaves original

89 Gerência de Chaves: geração de chaves locais
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.

90 Geração de chaves originais e chaves locais

91 VACM – View-based Access Control Model
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. Capítulo 17 de Stallings

92 Grupos 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.

93 Nível de Segurança Nível de Segurança: obtido a partir do campo msgFlags da mensagem SNMPv3. Apenas relembrando... noAuthNoPriv authNoPriv authPriv

94 Contextos 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.

95 Visões de MIB 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.

96 Política de Acesso 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).

97 MIB VACM (View-based Access Control Model)

98 Lógica do VACM

99 Parâmetros da MIB VACM Parâmetros da MIB VACM para configuração inicial “Semi-Security”.

100 SNMP: Limitações do Modelo

101 SNMP: Limitações do Modelo
Escalabilidade e eficiência Aumento do overhead da rede Aumento de atrasos (latência) Capacidade de processamento do gerente Limite de segmento do gerente

102 SNMP: Limitações do Modelo
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)

103 SNMP: Limitações do Modelo
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

104 SNMP: Limitações do Modelo
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