snmp baseado em slides gentilmente cedidos pelo prof. joão henrique kleinschmidt da ufabc
TRANSCRIPT
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