Gerenciamento de redes - UFPEsuruagy/cursos/Gerencia-MP/2015...Formato da Mensagem SNMPv3 53...

SNMP

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

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

SNMPv1 3

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

Do gerente para o agente:

get

getnext

set

Do agente para o gerente:

getresponse

trap

5

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.

SNMPv2 15

Gerência Internet: SNMPv2 16

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.


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.


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

SMIv2 21

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

22

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.


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.


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.

SNMPv3 33

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.

Evolução da Arquitetura SNMP 35

Especificações SNMPv3 36

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)

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

Arquitetura SNMP atual 37

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 |

+-------------------------------------------------------------------+

Gerente SNMPv3 39

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.

Agente SNMPv3 43

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.

Formato da Mensagem SNMPv3 47


msgVersion: setado para snmpv3 (3).


msgID: identificador único usado por duas entidades SNMP para coordenação de

mensagens de solicitação e resposta. Vai de 0 até 231-1.


msgMaxSize: tamanho máximo da mensagem enviada ou recebida por uma

entidade SNMP. Vai de 484 até 231-1 octetos.


msgFlags: um octeto contendo três flags nos seus três dígitos menos significativos:

reportableFlag, provFlag e authFlag.


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:


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


msgGlobalData: contém parâmetros necessários pelo Subsistema de

Processamento de Mensagens para coordenação das mensagens.


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.


contextEngineID: identifica inequivocamente uma entidade SNMP.


contextName: identifica inequivocamente um contexto particular dentro do

escopo de um contextEngineID associado.


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

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.


msgAuthoritativeEngineID: identificador do núcleo com autoridade

envolvido na troca dessa mensagem.


msgAuthoritativeEngineBoots: valor do snmpEngineBoots no núcleo

com autoridade envolvido na troca dessa mensagem.


msgAuthoritativeEngineTime: valor do snmpEngineTime no núcleo

com autoridade envolvido na troca dessa mensagem.


msgUserName: o usuário (principal) em cujo interesse a mensagem está sendo

trocada.


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


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)

Sincronização 72

Sincronização 73

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.

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

MIB usmUser 83

Criação da Mensagem junto ao USM 84

Recepção da Mensagem junto ao USM 85

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.


geração do par de chaves original 88


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

, 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

Lógica do VACM 98

Parâmetros da MIB VACM 99

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

SNMP: Limitações do Modelo 100


Escalabilidade e eficiência

Aumento do overhead da rede

Aumento de atrasos (latência)

Capacidade de processamento do gerente

Limite de segmento do gerente


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)


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


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

Gerenciamento de redes - UFPEsuruagy/cursos/Gerencia-MP/2015...Formato da Mensagem SNMPv3 53...

Documents

Transcript of Gerenciamento de redes - UFPEsuruagy/cursos/Gerencia-MP/2015...Formato da Mensagem SNMPv3 53...