ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA
FACOLTA' DI INGEGNERIA - SEDE DI CESENA
LABORATORIO DI INFORMATICA
Network Management
7. Infrastruttura amministrativa e SNMPv2C (community-based)
Claudio Salati
Copyright © 2001 by Claudio Salati
1
INFRASTRUTTURA AMMINISTRATIVA
•
I PDU SNMP scambiati fra manager e agent e le operazioni
eseguite di conseguenza dalla entita’ che emette o riceve un
PDU dipendono in realta’ dal quadro amministrativo che regola il
rapporto tra un manager ed un agent.
•
Autorizzazione - Un particolare manager ha diritto di eseguire
sulla MIB (istanza) di un certo agent tutte le operazioni
consentite dalla definizione della MIB (schema), o i suoi diritti
possono essere limitati per via amministrativa?
•
Autenticazione – come si puo’ essere sicuri dell’identita’ di chi
ha generato un PDU SNMP che si e’ ricevuto?
(anche per attribuirgli il giusto livello di autorizzazione!)
•
Privacy – come si puo’ garantire che lo scambio di messaggi fra
un manager ed un agent non sia intercettato da una terza parte?
(che magari vuole conoscere lo stato del sistema per poterlo
danneggiare)
2
AUTORIZZAZIONE (da RFC 1909)
For security reasons, it is often valuable to be able to restrict the
access rights of some management applications to only a subset
of the management information in the management domain.
To provide this capability, access to a context (la MIB di un sistema
gestito) is via a MIB view which details a specific set of managed
object types (and optionally, the specific instances of object types)
within that context.
For example, for a given context, there will typically always be one
MIB view which provides access to all management information in that
context, and often there will be other MIB views each of which
contains some subset of the information.
Since managed object types (and their instances) are identified via
the tree-like naming structure of ISO's OBJECT IDENTIFIERs, it is
convenient to define a MIB view as the combination of a set of
view subtrees, where each view subtree is a sub-tree within the
managed object naming tree.
3
AUTORIZZAZIONE (da RFC 1909)
- continua
In addition to restricting access rights by identifying (sub-)sets of
management information, it is also valuable to restrict the requests
allowed on the management information within a particular
context.
For example, one management application might be prohibited from
write-access to a particular context, while another might be allowed to
perform any type of operation (diversi access mode).
So, by providing access rights to a management application in terms
of the particular (subset) MIB view it can access for that context, then
the management application is restricted in the desired manner.
4
AUTENTICAZIONE e PRIVACY (da RFC 1909)
The enforcement of access rights requires the means not only to
identify the entity on whose behalf a request is generated but also to
authenticate such identification.
Another security capability which is (optionally) provided is the ability
to protect the data within an SNMPv2 operation from disclosure (i.e.,
to encrypt the data). This is particularly useful when sensitive data
(e.g., passwords, or security keys) are accessed via SNMPv2
requests.
5
PROBLEMI di SECURITY
Mascheramento
Un terzo pretende falsamente di essere una enita’ autorizzata.
Si deve avere la possibilita’ di accertare con certezza (autenticare) l’identita’
di chi ha generato un messaggio.
Integrita’
Un terzo intercetta e modifica un messaggio prima di prolungarlo alla
destinazione.
Si deve avere la possibilita’ di riconoscere un messaggio alterato.
Replay
Un terzo intercetta i messaggi fra entita' autorizzate e li duplica e ritrasmette
quando vuole lui.
Si deve poter riconoscere un messaggio che sia stato ritardato o duplicato
(dalla rete o da un terzo).
Privacy (intercettamento)
Un terzo puo' intercettare e comprendere i messaggi scambiati tra entita'
autorizzate.
I messaggi devono poter essere confezionati cosi' da risultare comprensibili
solo al destinatario legittimo.
6
CONTROLLO DI ACCESSO (da RFC 1909)
An access control policy specifies
• the types of SNMPv2 requests
• and associated MIB views
• which are authorized
• for a particular (id-)entity (on whose behalf a request is generated)
• when using a particular level of security
• to access a particular context (la MIB di un sistema gestito).
7
SECURITY MODEL (da RFC 1909)
A security model defines the mechanisms used to achieve an
administratively-defined level of security for protocol interactions:
1. by defining the security parameters associated with a
communication, including the authentication and privacy
algorithms and the security keys (if any) used.
2. by defining how entities on whose behalf requests are generated
are identified.
3. by defining how contexts are identified.
4. by defining the mechanisms by which an access control policy is
derived whenever management information is to be accessed.
 Per poter implementare il suo security model, una infrastruttura
amministrativa definisce un proprio messaggio SNMP che
incapsula il PDU SNMP e che contiene tutte le altre informazioni
necessarie
 diverse infrastrutture amministrative definiranno in generale
diversi messaggi SNMP
8
INFRASTRUTTURE AMMINISTRATIVE in SNMPv2
• Community based
• Normalmente indicata come SNMPv2C
• Derivata dall'infrastruttura amministrativa di SNMPv1
• Specificata in RFC 1901 (con riferimento a RFC 1157 di
SNMPv1)
• E' l'infrastruttura standard di SNMPv2 e quella piu' largamente
implementata
• User based
• Normalmente indicata come SNMPv2U o USEC (User-based
Security Model)
• Specificata in RFC 1910
• Riutilizzata anche in SNMPv3
• Diffusamente implementata
• Party based
• Infrastruttura originale di SNMPv2
• poi abortita, oggi solo di valore storico
9
Community-based SNMPv2 (SNMPv2C)
 identita’ dell’entita’ che genera una richiesta
• una community e' una relazione tra un agent e un insieme di
manager
• una community e' individuata da una OCTET STRING
(community name)
• ogni agent puo’ definire diverse community
 uno stesso manager puo’ appartenere a diverse community
su un singolo agent
• una community e’ definita localmente ad un agent
 diversi agent possono associare diversi insiemi di manager e
di diritti di accesso/MIB view ad uno stesso community name
• ogni manager deve tenere registrate tutte le community cui
appartiene nell’accedere ai sistemi gestiti sotto suo controllo
 un manager puo’ utilizzare diversi community name per
interagire con un medesimo agent a seconda dell’identita’
(log-in) dell’operatore che lo sta utilizzando
10
Community-based SNMPv2 (SNMPv2C)
 MIB view e access mode: diritti di accesso
• una MIB view e’ definita come insieme di sottoalberi della MIBistanza
• sono definiti due access mode: READ-ONLY e READ-WRITE
• community profile: coppia { access mode, MIB view }
• specifica le operazioni amministrativamente possibili su una
certa MIB view
• notare che l’access mode si applica uniformemente su tutti gli
oggetti di una MIB view
• per ogni community definita sull'agent viene definita una coppia
{community name, community profile} :
 l'insieme di queste coppie definisce l'access control policy
dell'agent
• ogni messaggio scambiato tra manager e agent e' associato ad
una community e, dopo l’autenticazione, viene assoggettato alla
politica di autorizzazione definita dal relativo community profile
11
Community-based SNMPv2 (SNMPv2C)
 access mode: diritti di accesso
• operazioni possibili su di un object-instance della MIB view
• in base al MAX-ACCESS del suo object-type
• in base alla definizione del community profile (access mode)
notaccessible
accessible
-for-notify
read-only
read-write read-create
READ-ONLY
-
trap
trap,
get
trap,
get
trap,
get
READ-WRITE
-
trap
trap,
get
trap,
get,
set
trap,
get,
set,
set-create
12
Community-based SNMPv2 (SNMPv2C)
Access Control Policy
Community name
SNMP Agent Identity
SNMP Managers’ Identity
Community Profile
MIB view
Access Mode
13
Messaggio SNMPv2C
COMMUNITY-BASED-SNMPv2 DEFINITIONS ::= BEGIN
IMPORTS PDUs FROM SNMPv2-PDU;
-- top-level SNMPv2C message
Message ::=
SEQUENCE {
version
INTEGER { version2 (1) },
-- modified from RFC 1157 (SNMPv1)
-- indica SNMPv2, 0 indicherebbe SNMPv1
community OCTET STRING,
-- community name
data
PDUs
-- as defined in RFC 1905
}
END
-- N.B. diversi framework amministrativi possono richiedere diversi formati
-- di Message
14
Messaggio Community Based reale

l'infrastruttura amministrativa community-based e' comune sia a
SNMPv1 che a SNMPv2

l'infrastruttura amministrativa community-based puo' supportare
contemporaneamente SNMPv1 e V2
-- top-level community-based message per SNMPv1 e SNMPv2
Message ::=
SEQUENCE {
version INTEGER { version1 (0), version2 (1) },
-- indica SNMPv2 o SNMPv1
community
OCTET STRING,
-- community name
data
ANY
-- PDU SNMPv1 o SNMPv2
}
15
Architettura di un agent bilingue SNMPv1 e SNMPv2
RUN-TIME
SYSTEM SMIv1
RUN-TIME
SYSTEM SMIv2
SNMPv1
SNMPv2
INFRASTRUTTURA AMMINISTRATIVA COMMUNITY-BASED
UDP
IP
16
Community-based SNMPv2 (SNMPv2C)
 parametri di security
• non esiste nessun meccanismo di
• encrittazione
• autenticazione
• il community name e' trasportato in chiaro
• nel messaggio SNMPv2C non e' presente nessun time-stamp
 il community name trasportato nel messaggio serve solo come
identificatore (handle) della community
 la definizione dell'access control policy sull'agent (e sul manager)
• non e' gestibile attraverso SNMP
• ma avviene solo per altra via (configurazione locale
dell'agent)
17
SNMPv2C e SECURITY
• mascheramento
non esiste nessun metodo per proteggersi dal mascheramento:
chiunque puo' leggere e riutilizzare il community name di un
messaggio autentico che ha intercettato
• integrita'
chiunque puo' alterare un messaggio autentico che ha intercettato
in modo non rilevabile
• replay
chiunque puo' ritrasmettere/ritardare un messaggio autentico che
ha intercettato
• privacy
chiunque puo' leggere correttamente un messaggio autentico che
sia riuscito ad intercettare
18
SNMPv2C e SECURITY: CONSEGUENZE
• molte implementazioni di agent SNMPv2 (e SNMPv1) non
supportano operazioni di set
• o almeno non supportano l'operazione di set per oggetti una cui
configurazione errata/maliziosa potrebbe portare a conseguenze
disastrose
• da cio' una tendenza a definire MIB (in particolare negli statement
di module-compliance) nelle quali l'operazione set e' poco
utilizzata (il suo supporto non e' comunque considerato un
requisito)
• e quindi una tendenza a utilizzare SNMP come strumento di
monitoraggio piuttosto che di controllo attivo della rete
• da cio' anche la necessita' di definire una evoluzione sicura di
SNMPv2: SNMPv3!
 SNMPv3 ::= SNMPv2 + security
19
SNMPv2C: trasmissione di un messaggio
// protocol entity SNMPv2
snmpV2encodePDUs(snmpV2PDUs, &snmpV2PDUsBer);
// infrastruttura amministrativa community-based
snmpV2CauthenticationTX(
dstCommunity, dst, dstlen,
localAddr, localAddrLen,
snmpV2PDUsBer, &snmpV2CMsg.data);
snmpV2CMsg.version = version2;
// ==1, SNMPv2
snmpV2CMsg.community = dstCommunity;
snmpV2CencodeMsg(snmpV2CMsg, &snmpMsgInBER);
sendTo(snmpUdpSocket, &snmpMsgInBER, size(snmpMsgInBER),
0, dst, dstlen);
20
SNMPv2C: trasmissione di un messaggio
notare che nel caso di SNMPv2C la procedura di autenticazione
snmpV2CauthenticationTX(
dstCommunity,
dst, dstlen,
localAddr, localAddrLen,
snmpV2PDUsBer, &snmpV2CMsg.data)
• al piu’ si limita a verificare che il community name sia registrato (sul
manager), per l’agent indicato da dst, dstlen
• non fa uso degli indirizzi mittente e destinazione,
• non inserisce un time-stamp nel messaggio
• non effettua nessuna elaborazione su snmpV2PDUsBer per
encrittarne il contenuto o aggiungervi informazione (e.g. un timestamp) prima di copiarlo nel campo snmpV2CMsg.data
21
SNMPv2C: ricezione di un messaggio
1
actualLength = recvfrom(snmpUdpSocket, &snmpMsgInBER,
MAX_UDP_DATAGRAM_SIZE,
0, from, fromlen);
snmpInPkts += 1; // object-instance snmpInPkts.0
if (snmpV2CdecodeMsg(snmpMsgInBER, &snmpV2CMsg)
!= NOERR) {
snmpInASNParseErrs +=1; // object-instance
// snmpInASNParseErrs.0
// then discard
} else if (snmpV2CMsg.version != version2) {
snmpInBadVersions += 1; // object-instance
// snmpInBadVersions.0
// then discard
22
SNMPv2C: ricezione di un messaggio
2
} else if (snmpV2CauthenticationRX(
snmpV2CMsg.community, from, fromlen,
localAddr, localAddrLen,
snmpV2CMsg.data, &snmpV2PDUsBer)
== fail) {
snmpInBadCommunityNames += 1; // object-instance
// snmpInBadCommunityNames.0
// then discard
if (snmpEnableAuthenTraps == enabled) {
// check local knowledge, and in case generate
// authenticationFailure trap
. . .
}
// il codice di risposta di errore authorizationError
// non e' usato nell'infrastruttura amministrativa SNMPv2C
} else if (snmpV2decodePDUs(snmpV2PDUsBer,
&snmpV2PDUs)
!= NOERR) {
snmpInASNParseErrs += 1;
// then discard
23
SNMPv2C: ricezione di un messaggio
3
} else if (communityProfile(snmpV2CMsg.community,
snmpV2PDUs)
!= allowed) {
snmpInBadCommunityUses += 1; // object-instance
// snmpInBadCommunityUses.0
// then discard
if (snmpEnableAuthenTraps == enabled) {
// check local knowledge, and in case generate
// authenticationFailure trap
. . .
}
// il codice di risposta di errore authorizationError
// non e' usato nell'infrastruttura amministrativa
// SNMPv2C
} else {
// process SNMP PDUs
. . .
}
24
SNMPv2C: ricezione di un messaggio
notare che nel caso di SNMPv2C la procedura di autenticazione
snmpV2CauthenticationRX(
snmpV2CMsg.community,
from, fromlen,
localAddr, localAddrLen,
snmpV2CMsg.data, &snmpV2PDUsBer)
• si limita a verificare il community name, che e’ gia’ in chiaro
• non fa uso degli indirizzi mittente e destinazione,
• non ha a disposizione un time-stamp del messaggio
• non deve effettuare nessuna elaborazione su snmpV2CMsg.data
per decrittare il contenuto del campo, dato che questo e’ gia’ in
chiaro: si limita a copiare il contenuto del campo data in
snmpV2PDUsBer
25
RFC 1907: object-type citati
 object group: snmpCommunityGroup
snmpInBadCommunityNames OBJECT-TYPE
SYNTAX
Counter32
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"The total number of SNMP messages delivered to the SNMP
entity which used a SNMP community name not known to said
entity."
::= { snmp 4 }
26
RFC 1907: object-type citati
 object group: snmpCommunityGroup
snmpInBadCommunityUses OBJECT-TYPE
SYNTAX
Counter32
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"The total number of SNMP messages delivered to the SNMP
entity which represented an SNMP operation which was not
allowed by the SNMP community named in the message."
::= { snmp 5 }
27
RFC 1907: object-type citati
 object group: snmpGroup
snmpInPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of messages delivered to the SNMP entity
from the transport service."
::= { snmp 1 }
snmpInBadVersions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of SNMP messages which were delivered to
the SNMP entity and were for an unsupported SNMP version."
::= { snmp 3 }
28
RFC 1907: object-type citati
 object group: snmpGroup
snmpInASNParseErrs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of ASN.1 or BER errors encountered by the
SNMP entity when decoding received SNMP messages."
::= { snmp 6 }
29