Tabla de contenidos 
El sistema de autentificación y autorización KerberosTabla de contenidos El sistema de autentificación y autorización Kerberos
Figura: Gestión de red
Con el crecimiento en tamaño y complejidad de las redes basadas en TCP/IP, la necesidad de mecanismos de gestión de red se ha vuelto muy importante. En la actualidad, los protocolos que forman el soporte de la gestión de red son:
El IAB("Internet Architecture Board") emitió un RFC al respecto, en el que adoptaba dos actitudes diferentes:
El IAB recomienda que todas las implementaciones de IP y TCP sean gestionables. Actualmente, esto implica la implementación de MIB-II (RFC 1213), y de al menos el protocolo recomendado de gestión SNMP (RFC 1157).
Notar que los protocolos históricos SGMP (Simple Gateway Monitoring Protocol, RFC 1028) y MIB-I (RFC-1156) no están recomendados.
Tanto SNMP y CMOT utilizan los mismos conceptos básicos en la descripción y definición la información de gestión denominada SMI("Structure and Identification of Management Information") descrita en el RFC 1155 y MIB("Management Information Base"), descrita en el RFC 1156.
SNMP (Simple Network Management Protocol) es un protocolo estándar de Internet. Su status es recomendado. Su especificación actual se encuentra en el RFC 1157 - SNMP("Simple Network Management Protocol").
MIB-II es un protocolo estándar de Internet. Su status es recomendado. Su especificación actual se encuentra en el RFC 1213 - MIB-II:Management Information Base for Network Management of TCP/IP-based Internets.
CMIP (Common Management Information Protocol) y CMIS (Common Management Information Services) se definen según los estándares ISO/IEC 9595 y 9596.
CMOT (CMIS/CMIP Over TCP/IP) es un protocolo propuesto como estándar de Internet. Su status es electivo. Su especificación actual se encuentra en el RFC 1189 - CMOT y CMIP("Common Management Information Services and Protocols for the Internet").
OIM-MIB-II es un protocolo propuesto como estándar de Internet. Su status es electivo. Su especificación actual se encuentra en el RFC 1214 - Gestión OSI Internet Management: MIB("Management Information Base").
Otros RFCs emitidos por el IAB sobre este tema son:
El SMI define las reglas para describir los objetos gestionados y cómo los protocolos sometidos a la gestión pueden acceder a ellos. La descripción de los objetos gestionados se hace utilizando un subconjunto de ASN.1("Abstract Syntax Notation 1, estándar ISO 8824), un lenguaje de descripción de datos. La definición del tipo de objeto consta de cinco campos:
Como ejemplo, podemos tener:
Este ejemplo muestra la definición de un objeto contenido en el MIB. Su nombre es sysDescr y pertenece al grupo sistema(ver MIB("Management Information Base")).
Un objeto gestionado no sólo ha de ser descrito, también debe ser identificado. Esto se hace utilizando el identificado de objeto("Object Identifier") ASN.1 como si fuera un número de teléfono, reservando grupos de números para distintas localizaciones. En el caso de la gestión de red para TCP/IP, el número reservado fue 1.3.6.1.2 y SMI lo usa como base para la definición de nuevos objetos.
Este número se obtiene al unir a grupos de números con el siguiente significado:
En el ejemplo, {system 1} significa que el identificador del objeto es 1.3.6.1.2.1.1.1. Es el primer objeto en el primer grupo(sistema) en el MIB.
El MIB define los objetos que pueden ser gestionados para cada capa en el protocolo TCP/IP. Hay dos versiones, MIB-I and MIB-II. MIB-I fue definida en el RFC 1156, y está clasificado ahora como protocolo histórico con status no recomendado.
Figura: MIB - II("Management Information Base II") - Definición de grupo.
Cada nodo gestionado soporta sólo los grupos apropiados. Por ejemplo, si no hay pasarela, el grupo EGP no tiene por qué estar incluido. Pero si un grupo es apropiado, todos los objetos en ese grupo deben estar soportados.
La lista de objetos gestionados definidos deriva de aquellos elementos considerados esenciales. Este enfoque, consistente en tomar sólo los objetos esenciales no es restrictivo, ya que el SMI proporciona mecanismos de extensibilidad tales como la definición de una nueva versión de MIB o de objetos privados o no estandarizados.
Debajo hay algunos ejemplos de objetos de cada grupo. La lista completa está definida en el RFC 1213.
Esta no es la definición completa del MIB pero sirve de ejemplo de los objetos de cada grupo.
El grupo de interfaces contiene dos objetos de nivel superior: el número de interfaces del nodo(ifNumber) y una tabla con información de estas(ifTable). Cada entrada de la tabla(ifEntry) contiene los objetos de esa interfaz. Entre ellos, el tipo de interfaz(ifType) se identifica en el árbol MIB con notación ASN.1 como 1.3.6.1.2.1.2.2.1.3. Para un adaptador de red en anillo, su valor sería 9("iso88025-tokenRing") (ver Figura - Identificador de objeto).
Figura: Identificador de objeto - Asignación para redes TCP/IP.
SNMP añadió las mejoras de muchos años de experiencia con SGMP y le permitió trabajar con los objetos definidos en el MIB con la representación del SIM.
ElRFC 1157 define NMS("Network Management Station") como una estación que ejecuta aplicaciones de gestión de red(NMA) que monitorizan y controlan elementos de red(NE) como hosts, pasarelas y servidores de terminales. Estos elementos usan un agente de gestión(MA) para realizar estas funciones. El SNMP para la comunicación de información entre las NMS y los MA.
Figura: SNMP - Componentes de SNMP.
Todos las funciones de los MA son sólo alteraciones(set) o consultas(get) de variables, limitando así el número de funciones esenciales a dos y simplificando el protocolo. En la comunicación NE-NMS, se utilizan un número limitado de mensajes no solicitados(traps) para informar de eventos asíncronos. Del mismo modo, en un intento de mantener la sencillez, el intercambio de información requiere sólo un servicio de datagramas y cada mensaje se envía en un único datagrama. Esto significa que SNMP es adecuado para una gran variedad de protocolos de transporte. El RFC 1157 especifica el intercambio de mensajes vía UDP, aunque es posible emplear otros.
Las entidades que residen en las NMS y los elementos de red que se comunican con otros a través de SNMP se denominan entidades de aplicación de SNMP. Los procesos que las implementan son las entidades de protocolo. Un agente SNMP con un conjunto arbitrario de entidades es una comunicad SNMP, en la que cada entidad se nombra con una ristra de bytes que debe ser unívoca para esa comunidad.
Un mensaje de SNMP consiste en un identificador de la versión, un nombre de la comunidad SNMP y un PDU("protocol data unit"). Toda implementación de SNMP debe soportar las cinco PDUs siguientes:
Los formatos de estos mensajes son los siguientes:
Figura: Formato de mensaje SNMP - Formato de las PDU Request, Set y Trap.
CMOT es la arquitectura de gestión de red desarrollada con vistas a mantener una relación más estrecha con el CMIP("Common Management Information Protocol") de OSI("Open System Interconnection"). Con esta premisa, CMOT se divide, como en OSI, en un modelo organizacional, funcional e informacional.
En los dos primeros el mismo concepto de OSI se usa en CMOT y SNMP. La identificación de objetos se efectúa empleando el subárbol relacionado con DoD con subdivisiones en lo que respecta a gestión, directorio, experimental y privado. Todos los objetos de gestión se definen en el MIB("Management Information Base"), y se representan con el SMI("Structure and Identification of Management Information"), un subconjunto de ASN.1("Abstract Syntax Notation 1" de OSI).
En el modelo funcional, CMOT adopta el modelo OSI que divide los componentes de gestión en managers y agentes. El agente recoge información, realiza comandos y ejecuta tests, y el manager recibe datos, genera comandos y envía instrucciones a los agentes. El manager y el agente están constituidos por un conjunto específico de entidades de información de gestión por cada capa de comunicación, denominadasLME ("Layer Management Entities").
Figura: CMOT - Componentes de CMIP sobre TCP/IP.
Todos los LME los coordina el SMAP("System Management Application Process") que es capaz de comunicarse entre diferentes sistemas a través de CMIP("Common Management Information Protocol").
En el mundo OSI, la gestión sólo se puede producir sobre conexiones establecidas por completo entre managers y agentes. CMOT permite el intercambio de información de gestión usando servicios no orientados a conexión(datagramas). Pero para mantener la misma interfaz del servicio que requiere CMIP, llamada CMIS("Common Management Information Services"), la arquitectura de CMOT define una nueva capa, el LPP("Lightweight Presentation Protocol"). Esta capa se ha definido para proporcionar los servicios de presentación que necesita CMIP de tal forma que la totalidad de los estándares OSI para la gestión de red se adapten a la arquitectura TCP/IP de CMOT.
Figura: LPP("Lightweight Presentation Protocol")
SNMP define un protocolo que permite efectuar operaciones en una serie de variables. Este conjunto de variables(el MIB) y un conjunto básico o núcleo está predefinidas. Sin embargo, el diseño del MIB cuenta con la posibilidad de expandir este núcleo sea expandido. Desafortunadamente, las implementaciones convencionales de agentes SNMP no suministran mecanismos para que el usuario cree nuevas variables. El DPI enfoca esta cuestión proporcionando mecanismos que permiten al usuario añadir, borrar o reemplazar dinámicamente variables en el MIB local sin tener que recompilar el agente SNMP. Esto es posible gracias a un subagente que se comunica con el agente a través del DPI. El RFC 1228 lo describe.
El DPI de SNMP habilita a un proceso para registrar la existencia de una variable MIB en el agente SNMP, que pasará la solicitud al subagente. El subagente devuelve a su vez la respuesta apropiada al agente. Este, finalmente, empaqueta una respuesta SNMP y envía la respuesta a la NMS que inició la solicitud. El subagente es completamente invisible (transparente) para la NMS.
La comunicación entre el agente SNMP y sus clientes(subagentes) tiene lugar sobre un canal. Típicamente se trata de una conexión TCP, pero se pueden emplear otros protocolo de transporte orientados a conexión.
El agente en el DPI puede:
La siguiente figura muestra el flujo entre el agente SNMP y el subagente.
Figura: Descripción del DPI de SNMP
La infraestructura de la versión 2 de SNMP se publicó en abril de 1993 y consiste en 12 RFCs, incluyendo el primero, el 1441, que es una introducción. En agosto de 1993 los 12 RFCs se convirtieron en un estándar con status electivo.
Esta infraestructura consta de las siguientes disciplinas:
Definición del subconjunto de ASNN.1 para la creación de módulos MIB. Descripción en el RFC 1442.
Definición del conjunto inicial de convenios textuales disponible para todos los módulos MIB. Descripción en el RFC 1443.
Definición de las operaciones del protocolo con respecto a las PDUs enviadas y recibidas en el RFC 1448.
Definición del mapeado de SNMPv2 sobre un conjunto inicial de dominios de transporte ya que se puede utilizar en diferentes pilas de protocolo. El mapeado en UDP es el preferido. El RFC también define OSI, AppleTalk, IPX, etc. Descripción en el RFC 1449.
Definición del MIB y del MIB Manager-Manger. Descripción en los RFCs 1450 y 1451.
Definición de SNMPv2 Party, SP("Security Protocols") y Party MIB. Descripción en los RFCs 1445, 1446 y 1447.
Definición de la compatibilidad o capacidad de notación de los agentes. Descripción en el RFC 1444.
Las siguientes secciones describen las principales diferencias y mejoras desde SNMPv1 a SNMPv2.
Una entidad SNMPv2 es un proceso real que realiza operaciones de gestión de red mediante la generación y/o respuesta a/de mensajes SNMPv2. Todas las posibles operaciones de una entidad se pueden restringir a un subconjunto de las operaciones que puede efectuar el entorno de gestión("SNMPv2 Party" o EG). Remitirse aSNMPv2 Party más abajo. Una entidad SNMPv2 podría pertenecer a múltiples entidades gestoras, y mantiene las siguientes bases de datos locales:
Una entidad SNMPv2 puede actuar como agente o como manager SNMPv2.
Un entorno de gestión es un entorno de ejecución virtual cuyas operaciones se restringen, por razones de seguridad o de otra índole, a un subconjunto definido administrativamente de todas las operaciones que puede realizar una entidad SNMPv2 particular. Remitirse a Entidad SNMPv2 más arriba. Arquitectónicamente, cada EG comprende:
El GetBulkRequest está definido en el RFC 1448 y forma por tanto parte de las operaciones del protocolo. Un mensaje GetBulkRequest se genera y se transmite como una petición de una aplicación SNMPv2. Su fin es solicitar la transferencia de una cantidad de datos potencialmente elevada, incluyendo, sin que ello le condicione, la rapidez y eficiencia en la recuperación de grandes tablas. GetBulkRequest es más eficiente que GetNextRequest en la recuperación de grandes tablas MIB de objetos. Su sintaxis es:
GetBulkRequest [ non-repeaters = N, max-repetitions = M ]
( RequestedObjectName1,
RequestedObjectName2,
RequestedObjectName3 )
Where:
Con GetBulkRequest se pueden conseguir los valores de sólo la siguiente variable o de las siguientes M variables con una sola solicitud.
Asumiendo la siguiente tabla ARP en un host que ejecuta un agente NMPv2:
Interface-Number Network-Address Physical-Address Type
1 10.0.0.51 00:00:10:01:23:45 static
1 9.2.3.4 00:00:10:54:32:10 dynamic
2 10.0.0.15 00:00:10:98:76:54 dynamic
Un manager SNMPv2 envía la siguiente respuesta para conseguir sysUpTime y la tabla ARP completa:
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
( sysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType )
La entidad SNMPv2 que actúa como agente responde con la PDU Response:
Response (( sysUpTime.0 = "123456" ),
( ipNetToMediaPhysAddress.1.9.2.3.4 =
"000010543210" ),
( ipNetToMediaType.1.9.2.3.4 = "dynamic" ),
( ipNetToMediaPhysAddress.1.10.0.0.51 =
"000010012345" ),
( ipNetToMediaType.1.10.0.0.51 = "static" ))
La entidad SNMPv2 que hace de manager continúa con:
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
( sysUpTime,
ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51 )
El agente responde con:
Response (( sysUpTime.0 = "123466" ),
( ipNetToMediaPhysAddress.2.10.0.0.15 =
"000010987654" ),
( ipNetToMediaType.2.10.0.0.15 =
"dynamic" ),
( ipNetToMediaNetAddress.1.9.2.3.4 =
"9.2.3.4" ),
( ipRoutingDiscards.0 = "2" ))
Esta respuesta señala el final de la tabla al manager. Con GetNextRequest se hubieran necesitado cuatro solicitudes para conseguir la misma información. Si se hubiera fijado el valor max-repetition de GetBulkRequest a tres, en este ejemplo sólo se hubiera necesitado una solicitud.
Un mensaje InformRequest se genera y se transmite como una solicitud de una aplicación de una entidad manager SNMPv2 que desea notificar a otra aplicación, que se ejecuta también en un manager SNMPv2, información en el ámbito del MIB(MIB view) (20) para un entorno local a la aplicación que envía el mensaje. El paquete se utiliza para indicar al manager del otro entorno de la información accesible en el emisor. (comunicación manager-manager a través de los límites del entorno). Las dos primeras variables en la lista de asociaciones de variables de un mensaje InformRequest son sysUpTime.0 y snmpEventID.i (21)respectivamente. Les pueden seguir otras variables.
Este MIB define los objetos gestionados que determinan el comportamiento de la entidadSNMPv2.
Nota: No es una sustitución del MIB-II.
Las siguientes son algunas definiciones de objetos para hacerse una idea de sus contenidos:
snmpORLastChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"El valor de sysUpTime en el momento
del cambio más reciente en el valor
o estado de cualquier instancia de
snmpORID."
warmStart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"Un trap warmStart significa que la entidad
SNMPv2, actuando como agente, se está reinicializando
a sí misma de tal modo que la configuración
no se altere."
El EG del MIB define los objetos gestionados que se corresponden con las propiedades asociadas a un EG SNMPv2. Un ejemplo de algunos objetos del MIB:
partyIdentity OBJECT-TYPE
SYNTAX Party
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Un identificador de EG unívoco
para un EG de SNMPv2 particular."
partyAuthProtocol OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"El protocolo de autentificación
por el que se autentifican el
origen y la integridad de todos
los mensajes que genera el EG. El
valor noAuth significa que los
mensajes no están autentificados.
Una vez que se crea una instancia
de este objeto, su valor no puede
ser alterado."
La finalidad de este MIB es proporcionar los medios para la coordinación entre múltiples estaciones de gestión. Es decir, los medios por los que las funciones de control y monitorización de la gestión de red se pueden distribuir entre múltiples NMS en una gran red. Específicamente, este MIB suministra mecanismos para que una NMS solicite servicios de gestión de otra. Por tanto, una entidad SNMPv2 puede tener un doble papel; cuando proporciona información de gestión a otro manager, actúa como agente, y cuando pide información, actúa como manager. El MIB manager-manager consta de las tres tablas siguientes:
Cada alarma es una condición específica detectada mediante la monitorización periódica, en un intervalo de muestreo configurable, de los valores de una determinada variable con información de gestión. Un ejemplo de condición de alarma es cuando la variable monitorizada toma un valor fuera de rango. Cada condición de alarma dispara un evento, que puede a su vez desencadenar una o más notificaciones para otras NMS usando el InformRequest.
El protocolo de autentificación proporciona un mecanismo para que la gestión de SNMPv2 permita identificar que las comunicaciones que genera un entorno se originan efectivamente en ese entorno.
El protocolo de autentificación proporciona un mecanismo para que la gestión de SNMPv2 permita proteger las comunicaciones que genera un entorno de cualquier intrusión.
Las principales amenazas contra las que el protocolo de seguridad de SNMPv2 aporta protección son:
Los siguientes servicios de seguridad proporcionan medidas contra las anteriores amenazas:
La proporciona el algoritmo de condensación de mensajes MD5. Se calcula un resumen o extracto de 128 bits de la porción indicada del mensaje SNMPv2 y se incluye como parte del mensaje enviado al receptor.
A cada mensaje se le añade un prefijo con un valor secreto que comparten el emisor del mensaje y el receptor, antes de calcular el extracto.
En cada mensaje se incluye un sello de tiempo,
La proporciona el protocolo simétrico de privacidad que encripta una porción adecuada del mensaje de acuerdo con una llave secreta conocida sólo por el emisor y el receptor. Este protocolo se usa conjuntamente con el algoritmo simétrico de encriptación, en el modo de encadenamiento de cifrado de bloques, que forma parte del DES("Data Encryption Standard"). La parte designada del mensaje se encripta y se incluye como parte el mensaje enviado el receptor.
Uno de los propósitos del modelo administrativo para SNMPv2 es definir como la infraestructura administrativa se aplica para llevar a cabo una administración de red efectiva en diversas configuraciones y entornos.
El modelo implica el uso de diferentes identidades en el intercambio de mensajes. De esta forma, representa abandonar el basado en comunidades del SNMPv1 original. Al identificar sin ambigüedad al emisor y al receptor de cada mensaje, esta nueva estrategia mejora el esquema histórico de comunidades ya que permite un diseño del control de acceso a los datos más conveniente así como el empleo de protocolos de seguridad asimétricos(con llave pública) en el futuro. Remitirse a Figura - Formato de mensaje de SNMPv2 para conocer el nuevo formato de mensaje.
Figura: Formato de mensaje de SNMPv2
El mensaje pasa a ser encapsulado en un datagrama UDP/IP normal y se envía a su destino a través de la red.
Para más información, remitirse a los RFCs mencionados arriba.
Protocolo de servicios NetBIOS