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

SNMPBaseado 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ítulo1155 Structure and identification of management

information for TCP/IP-based internets1157 Simple Network Management Protocol (SNMP)1212 Concise MIB definitions1213 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: 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.

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 1993.

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ítulo1901 Introduction to Community-Based SNMPv22578 Structure of Management Information Version 2

(SMIv2)2579 Textual Conventions for SMIv22580 Conformance Statements for SMIv23416 Protocol Operations for SNMPv23417 Transport Mappings for SNMPv23418 Management Information Base for SNMPv23584 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 inform report

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

36

Especificações SNMPv3RFC Título Data3410 Introduction and Applicability Statements for

Internet-Standard Management FrameworkDez. 2002

3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks(Updated by RFC 5343, RFC 5590)

Dez. 2002

3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)(Updated by RFC 5590)

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)

Dez. 2002

3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

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

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é 231-1.

50

Formato da Mensagem SNMPv3 msgMaxSize: tamanho máximo da mensagem enviada ou recebida

por uma entidade SNMP. Vai de 484 até 231-1 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é 231-1. 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

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

ObjetosObjetos 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

73

Sincronização

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 TempoObservaçã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.

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