Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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.
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
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.
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.
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
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é 231-1.
Formato da Mensagem SNMPv3 50
msgMaxSize: tamanho máximo da mensagem enviada ou recebida por uma
entidade SNMP. Vai de 484 até 231-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é 231-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 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.
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)
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.
Estabelecimento de janelas de tempo 75
Estabelecimento de janelas de tempo 76
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.
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
, 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
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