UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERIA SEMINARIO DE REDES (66.12)

Informe N 1 SNMPv1,v2 y v3 Profesor: Ing. Marcelo Utard Ing. Pablo Ronco

Integrantes Goitia, Nicols 81520 Coria, Ariel 84651

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires ndice:

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Objetivo del trabajo Estudio del protocolo SNMP (Simple Network Management Protocol) y comparacin de sus tres versiones (SNMPv1, SMNPv2, SNMPv3). 1 Introduccin a la gestin de redes La gestin de redes consiste en controlar y monitorear los recursos de una red con el fin de evitar que sus prestaciones se degraden, de modo de cumplir con los requerimientos solicitados. Los componentes de un sistema de gestin de red son: Gestor: es la parte de la aplicacin que emite las directivas de operaciones de gestin y recibe notificaciones y respuestas. Agente: tiene la funcin de responder a las directivas enviadas por el gestor. Protocolo de gestin: es el conjunto de especificaciones que gobiernan la interaccin de procesos y elementos dentro de un sistema de gestin. Base de informacin de gestin: es el conjunto de objetos gestionados que representan a los recursos de la red que permiten algn tipo de gestin en una forma abstracta. SNMP (Simple Network Management Protocol) es una solucin a unos de los componentes de un sistema de gestin de red, el protocolo de gestin. Es un conjunto de especificaciones que definen el protocolo en s mismo, la estructura de datos y otros aspectos. El Gestor sirve como interface entre la persona y el sistema de gestin, debe tener aplicaciones para el anlisis de datos, monitoreo y control de red, debe ser capaz de transmitir los requerimientos del gestor dentro del sistema de gestin. El Agente es un software que reside en los dispositivos a gestionar, responde a los pedidos de informacin y acciones provenientes del gestor. El Gestor y el Agente se comunican utilizando el protocolo de gestin de red, en ste caso SNMP. Desde el punto de vista de la gestin, los recursos de los dispositivos se representan como objetos. Cada objeto es una variable que representa algn aspecto del dispositivo gestionado. Los objetos se organizan en una base de informacin de gestin (MIB, Management Information Base). La MIB funciona como un conjunto de puntos de acceso para el Gestor. 1.1 SNMPv1 SNMP fue diseado como un protocolo de nivel de aplicacin, est propuesto para operar sobre UDP. Desde la estacin de gestin pueden enviarse tres tipos de mensajes: GetRequest, GetNextRequest y SetRequest. Los dos primeros se usan para leer el valor de los objetos mientras que el ltimo para setearlos. Los tres mensajes son confirmados por el agente con un mensaje GetResponse. Adems el agente puede enviar un mensaje Trap en respuesta a un evento que afecte a los objetos gestionados. El mensaje Trap no requiere confirmacin por parte de la estacin de gestin. Las RFC que definen SNMPv1 son las siguientes: 3

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires RFC 1155 (sintaxis y semntica para definir objetos para administracin de red - SMI), RFC 1157 (protocolo de administracin para acceder a los objetos, monitorearlos y controlarlos - SNMP) RFC 1212 (lineamientos para definir nuevos mdulos sin generar redundancia MIB)

1.2 SMI La SMI define el marco general dentro del cual se define y construye una MIB. La SMI identifica los tipos de datos que pueden usarse en la MIB y especifica como se representan y denominan los recursos dentro de la MIB. La MIB puede guardar solo tipo de datos simples: escalares y matrices de escalares. La SMI no soporta la creacin de estructuras de datos complejos, simplificando la implementacin y mejorando la interoperabilidad. La SMI proporciona tcnicas para: Definir la estructura de una MIB. Definir objetos individuales. Codificar los valores de los objetos. 1.3 MIB La base de un sistema de gestin de redes es una base de datos acerca de los elementos a gestionar. Esta base de datos se denomina Management Information Base (MIB). Cada recurso a gestionar se representa como un objeto, la MIB es una coleccin estructurada de dichos objetos. Cada equipo administrado en la red mantiene una MIB que refleja el estado de los recursos del sistema, leyendo y modificando los valores de los objetos en la MIB. Para que la MIB cumpla con las necesidades de un sistema de gestin de redes, debe satisfacer ciertos objetivos: Los objetos usados para representar un recurso particular deben ser los mismos en todos los sistemas. Se debe usar un esquema comn de representacin de la informacin para lograr interoperabilidad. 1.3.1 Object ID

Todos los objetos gestionados se encuentran ordenados en una estructura de rbol. La estructura del rbol por s misma define un agrupamiento de objetos dentro de grupos relacionados lgicamente. Asociados con cada tipo de objeto dentro de una MIB hay un identificador de objeto (OID), el cul es nico para cada tipo de objeto. Su valor consiste en una secuencia de enteros denominados subidentificadores (cada subidentificador representa un nodo en el rbol) 4

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires

Por ejemplo el nodo internet(1) tiene un OID de 1.3.6.1. El documento SMI define 4 nodos bajo el mismo nodo internet(1): Directory(1): reservado para uso futuro. Mgmt(2): usado para objetos definidos en documentos aprobados por el IAB. Experimental(3): usado para identificar objetos utilizados en experimentos de Internet. Private(4): usados para identificar objetos definidos unilateralmente por los fabricantes. Actualmente hay dos versiones de MIB, mib-1 y mib-2, la segunda es una extensin de la primera. Ambas fueron provistas con el mismo OID de modo que slo puede haber una de las MIB presente en cualquier configuracin. 1.3.2 Sintaxis de objetos

Cada objeto dentro de una MIB se define de un modo formal, la definicin especifica el tipo de dato, estados permitidos y rangos de valores. La notacin ASN.1 se usa para definir cada objeto individual y tambin para definir la estructura completa de la MIB. A continuacin se mencionan los tipos de datos permitidos: Universal: formado por tipo de datos de uso general. Application Wide: tipos de datos que son relevantes para una aplicacin particular. Tabla: Tabla bidimensional de escalares.

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires 1.3.3 Codificacin

Los objetos en la MIB son codificados usando la codificacin estandarizada Basic Encoding Rules (BER). Las reglas describen un mtodo para codificar valores de cada tipo con una cadena de octetos. La codificacin establece que cualquier valor puede codificarse como una tripla con los siguientes componentes: Type: indica el tipo, adems si es primitive o constructed. Length: indica la longitud de la representacin del valor. Value: representa el valor como una cadena de octetos. 1.4 Comunidad SNMP involucra, adems de relaciones entre la estacin de gestin y los equipos administrados, relacin entre la estacin de gestin y otras estaciones de gestin. Cada estacin de gestin controla su propia MIB local y debe ser capaz de controlar la forma en que las otra estaciones de gestin acceden a dicha MIB. Es por ello que SNMP proporciona un mtodo de seguridad primitivo y de capacidad limitada conocido como comunidad. Una comunidad SNMP es una relacin entre un agente SNMP y un conjunto de gestores SNMP que definen caractersticas de autenticacin. El concepto de comunidad es un concepto local, definido en el equipo gestionado. Cada comunidad tiene un nombre de comunidad y las estaciones de gestin dentro de esa comunidad estn provistas con el nombre de comunidad y deben utilizarlo en todas las operaciones Get y Set. 1.5 Formatos SNMP Cada mensaje SNMP incluye un campo version con el nmero de versin de SNMP (0 para SNMPv1), un campo community con el nombre de la comunidad y uno de los cinco PDU dependiendo el tipo de mensaje.

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires

1.5.1

GetRequest

Se incluyen los siguientes datos: PDU type: indica que es una PDU GetRequest. Request-id: la entidad emisora asigna nmero de manera que cada pedido pendiente en el mismo agente est identificado unvocamente. Variablebindings: lista las intancias de los objetos cuyos valores son requeridos. La operacin GetRequest es atmica, es decir que se reciben todos los valores o no se recibe ninguno. Si la entidad receptora puede enviar todos los valores solicitados, responde con una operacin GetResponse con el valor de cada variable. Si al menos uno de los valores no se puede devolver, no se retorna ningn valor. 1.5.2 GetNextRequest

Tiene el mismo patrn de intercambio y formato que la PDU GetRequest. La diferencia est en que el que responde el pedido retorna la instancia del objeto que sigue en orden lexicogrfico al objeto nombrado. Esto permite a una estacin de gestin descubrir dinmicamente la estructura de un MIB. 1.5.3 SetRequest

Se utiliza para escribir el valor de un objeto, por lo tanto la lista de campo variablebindings contiene el nombre del objeto y el valor al que se quiere setear el mismo. La operacin tambin es atmica, se actualizan todos los datos o ninguno. Si la estacin receptora puede actualizar todos los campos, responde con GetResponse que incluye el valor de cada variable, de lo contrario si no se pudieron actualizar se devuelve GetResponse pero sin valores. 7

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires 1.5.4 Trap

Es emitida por una entidad SNMP en nombre de una aplicacin del agente. Es utilizado para notificar asincrnicamente a la estacin de gestin sobre la ocurrencia de un evento significativo. A diferencia de las dems operaciones, no se genera un mensaje de respuesta. 1.6 Limitaciones de SNMPv1 Una de las limitaciones es el tema de seguridad en SNMPv1, la siguiente versin incluye seguridad en el acceso a las MIB. Los valores de error son resumidos en slo unos pocos (noError, tooBig, noSuchName, badValue, readOnly), en la siguiente versin se puede identificar con ms claridad el tipo de error. 2 SNMPv2

Con el fin de solucionar algunos problemas en su versin original surge SNMPv2. 2.1 Historia de SNMPv2 SNMPv2 surge ante la necesidad de cubrir deficiencias de SNMPv1. Bsicamente intenta implementar: Mejoras en la seguridad Nuevos aspectos de gestin SNMPv2 fue desarrollado durante fines de 1992, descripto originalmente en las RFC 1441-1452, ahora obsoletas. 2.2 Documentos que definen SNMPv2 (RFC) Las RFC que lo cubren: 3416 SNMPv2 3417 Transport Mapping 3418 MIB 2576 Coexistencia SNMPv1 y SNMPv2.

2.3 Caractersticas Generales Extiende el modelo de comunicaciones considerablemente, posibilitando tanto una gestin altamente centralizada como distribuida. Capacidad de los sistemas para operar tanto como agentes como gestores. Capacidad de comunicacin gestor-gestor con la posibilidad de jerarquizar la gestin. Mayor eficiencia en la transferencia de la informacin. 8

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Soporta una sealizacin extendida de errores. 2.4 Mejoras respecto a SNMPv1 La evolucin natural de SNMPv1 es SNMPv2, introduciendo algunas mejoras las cuales se pueden dividir en tres categoras: Estructura de la Informacin de Gestin (SMI). Capacidad de interaccin Gestor-Gestor. Operaciones de protocolo. La Estructura de la Informacin de Gestin de SNMPv2 es un super-conjunto de la de SNMPv1, con especificaciones y documentacin ms elaborada de los objetos gestionados y MIBs.Principales mejoras: Nuevas definiciones de objetos y nueva macro OBJECT-TYPE. Definiciones y funciones para el manejo especfico de tablas. Definicin de una macro para las notificaciones, que incluye informacin adicional de referencia a otros elementos de la MIB (NOTIFICATION-TYPE macro). Mdulos de informacin. Las PDU de SNMPv2 van encapsuladas en un mensaje como en SNMPv1.Los mensajes de SNMPv2 proveen la funcionalidad necesaria para las caractersticas de seguridad que proporciona ste.SNMPv2 provee tres tipos de acceso a la informacin de gestin: GESTOR-AGENTE, pregunta-respuesta. GESTOR-GESTOR, pregunta-respuesta (nuevo con respecto SNMPv1). AGENTE-GESTOR, sin confirmar (traps). 2.5 Estructura de la informacin (SMI) La Estructura de la Informacin de Gestin (SMI) define las reglas para el manejo de la informacin, utilizando ASN.1.Adems la Estructura de la Informacin de Gestin de SNMPv2 es un super-conjunto de la de SNMPv1, con especificaciones y documentacin ms elaborada de los objetos gestionados y MIBs. El SMI de SNMPv2 se describe en el RFC 1902. Este RFC hace algunas adiciones y mejoras en los tipos de datos especificados en el SMI de SNMPv1, como la inclusin de cadenas de bits, las direcciones de red y los contadores. Las cadenas de bits se definen slo en SNMPv2 y comprenden una cadena de entre cero o ms bits identificados con un nombre que especifican un valor. Las direcciones de red representan una direccin de protocolo de una familia en particular. SNMPv1 admite slo las direcciones IP de 32 bits, pero SNMPv2 soporta otros tipos de direcciones tambin. Los contadores son nmeros enteros no negativos que aumentan hasta alcanzar un valor mximo y luego vuelve a cero. En SNMPv1, solo existe un nico tamao de contador de 32 bits. En SNMPv2, se definen contadores de 32 bits y de 64 bits.

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Las principales mejoras en cuanto a la estructura de la informacin es: Nuevas definiciones de objetos y nueva macro OBJECT-TYPE. Definiciones y funciones para el manejo especfico de tablas. Definicin de una macro para las notificaciones, que incluye informacin adicional de referencia a otros elementos de la MIB (NOTIFICATION-TYPE macro). Mdulos de informacin.

2.5.1

Definicin de nuevos objetos

El nuevo SMI se encuentra dividido en tres partes para realizar la definicin de un objeto. Estas son: Definiciones de Objetos: Informacin acerca del significado y la forma del objeto. o Se usa la macro OBJECT-TYPE: La macro OBJECT-TYPE se usa para definir un objeto gestionado. La expansin de la macro OBJECT-TYPE conceptualmente sucede durante la implementacin y no en tiempo de ejecucin. Mas adelante veremos los principales campos que definen la esta macro. Definiciones de Mdulos: Informacin general acerca del mdulo, contacto, history, etc. o Se usa la macro MODULE-IDENTITY: Todos los mdulos de informacin empiezan con esta macro la cual proporciona informacin de contacto e historial de revisiones. Definiciones de Notificaciones: Informacin acerca de la sintaxis y la semntica de una notificacin. o Se usa la macro NOTIFICATION-TYPE: es usada la para la transmisin de informacin de administracin que no han sido solicitadas.

2.5.2

Modificaciones al OBJECT-TYPE

Como con SNMPv1 la definicin de objetos en SNMPv2 son usados para describir los objetos administrados. La macro OBJECT TYPE tiene la misma estructura general definida en la macro OBJECT TYPE del RFC 1155 (SNMP SMI) para definir objetos con ciertas mejoras.

10

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires La siguiente imagen muestra la definicin de la macro OBJECT-TYPE segn el RFC 2578.

A continuacin se detallarn los cambios realizados en la definicin de la macro OBJECT-TYPE en SNMPv2 respecto a la definicin en SNMPv1. UnitsPart: Esta clusula se incluye para definir la unidad asociada al objeto. Por ejemplo en caso de estar midiendo una variable de tiempo podra definirse si se trata de segundos, milisegundos, etc. Max-Access: Esta clusula es similar a la clusula ACCESS de SNMPv1. En este caso se ha eliminado la definicin solo de escritura debido a su similitud con la definicin lectura y escritura y se han creado las nuevas categoras: accesible para notificacin un objeto de este tipo es accesible nicamente a travs de una notificacin. lectura y creacin un objeto de este tipo tiene acceso de lectura, escritura y creacin. Clusula status: En esta categora se han eliminado las definiciones mandatory (obligatorio) y optional (opcional) y se defini current (actual). Esta nueva definicin indica que el objeto es vlido en el nuevo estndar, mientras que si el estado es obsolete (obsoleto) no se recomienda el uso del objeto. En caso de que el estado sea deprecated (desactualizado) indica que la definicin del objeto es obsoleta, pero que algunos fabricantes pueden utilizarla con la finalidad de mantener un cierto nivel de interoperabilidad con implementaciones anteriores. ReferPart. Clusula textual opcional que define una referencia cruzada con otro mdulo de la MIB. 11

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires IndexPart. Es ms compleja que en SNMPv1, ya que se usa para el manejo de las tablas en SNMPv2. DefValPart. Es opcional e indica un valor por defecto aceptable para cuando se crea una instancia del objeto. Se deja a discrecin de agente. VALUE NOTATION. El nombre usado por SNMPv2 para acceder a este objeto va SNMPv2. Los tipos de datos definidos para SNMPv2 y su relacin con SNMPv1 son los que se muestran en la tabla.

2.5.3

Tablas en SNMPv2

SNMPv2 mejora las convenciones usadas en la SNMPv1 para facilitar la creacin, eliminacin y acceso a las filas de una tabla. Se permiten dos tipos de tablas conceptuales en SNMPv2: Tablas que prohben la creacin y eliminacin archivos por parte de la estacin de gestin. Este tipo de tablas tiene el nmero de filas fijado por el agente. Los objetos columna pueden ser del tipo read-write, aunque en su mayora suelen ser solamente read-only. Tablas que permiten la creacin y eliminacin de filas a la estacin de gestin. En este caso las tablas pueden no tener inicialmente filas creadas y que la estacin de gestin cree las filas a medida que sean necesarias. Ambos tipos de tablas proveen nuevas convenciones y facilidades para acceder a las filas de manera ms simple a travs de los ndices. 2.5.3.1 Indexacin de tablas

12

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Las opciones que permite SNMPv2 para la indexacin de tablas son dos: utilizar la clusula INDEX o utilizar la clusula AUGMENTS. La clusula INDEX define la construccin y orden de las columnas que conforman las filas. La clusula AUGMENT se utiliza para agregar ms columnas a una tabla ya existente sin modificar su definicin. Los objetos que incluyen la clusula AUGMENT se denominan extensin de fila conceptual. 2.5.3.2 Creacin de filas Para que una tabla permita la creacin y eliminacin de filas deben tener obligatoriamente un objeto columna denominado status cuyo valor de sintaxis debe ser RowStatus y el valor de MAX-ACCESS debe ser read-create (lectura y creacin). La definicin de RowStatus muestra dos mtodos posibles para la creacin de una fila: createAndWait y createAndGo. Mtodo createAndWait: La estacin de gestin comienza enviando al agente una peticin para crear una fila con un identificador de instancia dado (valor de los ndices). Si el pedido es correcto el agente crea la fila nueva y asigna los valores a los objetos que tienen valores por defecto. Si todos los objetos readcreate tienen valores por defecto, el estado de la fila cambia a notInService. En caso que algunos objetos no posean valores por defecto, el estado de la fila cambia a notReady. Luego, el gestor enva un Get para determinar el estado de cada uno de los objetos read-create en la fila. En el caso de los objetos que no tengan asignado un valor el agente responde al gestor con el valor noSuchInstance, y responde noSuchObject por cada objeto que est definido en la MIB, pero no es soportado por el agente. La estacin de gestin debe asignar valores (mediante un Set) a los objetos noSuchInstance y puede cambiar los valores por defecto, si as lo requiere. Una vez que estn asignados todos los valores de los objetos read-create el gestor puede asignar, mediante un Set, el valor active al estado de la fila. Mtodo createAndGo: Este mtodo es ms simple que el anterior, pero tiene dos limitaciones, los objetos de la fila deben poder enviarse en una nica PDU (Set o Response) y el gestor no aprende automticamente los valores por defecto de los objetos. La estacin de gestin en primer lugar asigna el identificador de instancia. Luego puede realizar un Get para determinar los objetos read-create que tienen el valor noSuchInstance, o puede obtener esta informacin por conocimiento previo del agente. El gestor posteriormente enva una PDU del tipo Set para crear una fila nueva y asignar los valores a todos los objetos read-create. Si la operacin Set es llevada a cabo, la fila es creada y se cambia su estado a active. 2.5.3.3 Eliminacin de filas

13

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Para eliminar una fila, la estacin de gestin debe enviar un comando Set para cambiar el estado de la fila a destroy. Si este comando llega al agente sin errores, el agente elimina inmediatamente la fila liberando los recursos asociados. Una estacin de gestin puede querer suspender una fila que est activa. Para realizar esta operacin el gestor debe enviar un comando Set para modificar el estado de la fila a notInService. Si el agente no quiere suspender esa fila enva una respuesta con el error wrongValue. De otra manera, el agente coloca la fila fuera de servicio y enva una respuesta sin errores. 2.5.3.4 Extensin de la tabla ifTable (ifXTable)

El grupo de interfases contiene informacin sobre las interfases fsicas de la entidad, incluyendo informacin de configuracin y estadsticas sobre los eventos que ocurren en cada interfase. Cada interfase es pensada como si estuviera conectada a una subred, aunque se puede hallar con una conexin punto a punto. La implementacin de este grupo es obligatoria. El grupo incluye un objeto escalar que representa el nmero de interfases asociadas a la entidad y una tabla ( ifTable) que contiene una fila por cada interfase. La tabla ifXTable es una extensin de la tabla ifTable. Esta tabla tiene los siguientes objetos columna: Contadores de paquetes broadcast y multicast entrantes y salientes de cada interfase. Contadores de paquetes y octetos de alta capacidad (64 bits). Un objeto que permite la habilitacin/deshabilitacin de envo de traps en caso de haberse cado o restitudo una conexin. Un objeto que estima la tasa de transferencia en Mbps. Un objeto que indica si se evaluarn los paquetes en forma promiscua o si solamente se evaluarn los paquetes dirigidos a esa estacin. Los paquetes broadcast y multicast no son considerados en esta definicin. Un objeto que indica si hay un conector fsico.

2.6 Protocolo Las PDU de SNMPv2 van encapsuladas en un mensaje como en SNMPv1. SNMPv2 provee tres tipos de acceso a la informacin de gestin: GESTOR-AGENTE: Una entidad SNMPv2 que opera en el rol de gestor enva una peticin a una entidad SNMPv2 que opera en el rol de agente la cual responde a la peticin. Este tipo es usado para recibir o modificar informacin de administracin relacionada con el dispositivo administrado. GESTOR-GESTOR: Una entidad SNMPv2 que opera en el rol de gestor enva una peticin a una entidad SNMPv2 que opera en el rol de gestor la cual responde a la peticin. Este tipo es usado para notificar a una entidad SNMPv2 que opera en el rol de gestor de informacin asociada con otra entidad SNMPv2 que opera en el rol de gestor (nuevo con respecto SNMPv1).

14

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires AGENTE-GESTOR: Una entidad SNMPv2 que opera en el rol de agente enva un mensaje no solicitado denominado trap a una entidad SNMPv2 que opera en el rol de gestor. Este tipo es usado para notificar a una entidad SNMPv2 que opera en el rol de gestor de un evento excepcional que ha ocurrido con el dispositivo administrado. 2.6.1 PDUs y Operaciones

El formato de las PDU para SNMPv2 se puede ver en el siguiente esquema.

Un mensaje SNMPv2 esta constituido por una cabecera que indica cual es la version y un nombre de comunidad que identifica al conjunto de managers y a los dipositivos administrados. En SNMPv2 contamos con 7 tipos de PDUs y son las siguientes GetRequest. GetNextRequest. SetRequest. SNMPv2-Trap. InformRequest. Response. GetBulkRequest.

El formato de cada PDU se muestra a continuacin.

15

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires

Es importante mencionar que significa cada uno de los campos mencionados anteriormente: Peticin ID: usado para distinguir de entre otras solicitudes, cada solicitud con una identificacin nica. Error-status: usado para indicar que ha sucedido una excepcin mientras se procesaba una solicitud. Error-index: cuando el error-status es diferente a cero (no hubo error) puede proporcionar informacin adicional indicando que variable caus la excepcin. Campos variables: una lista de nombre de variables con sus correspondientes valores, normalmente contiene los datos solicitados por una operacin Get o Trap. Non Repeaters: especfica el nmero de variables en la lista variable-bindings (vnculos variables) para las cuales debe ser retornado un slo sucesor lexicogrfico. Max Repetitions: determina la cantidad de sucesores lexicogrficos que deben devolverse para las restantes variables en el campo variable-bindings. 2.6.2 Mensajes SNMP

La siguiente tabla muestra las operaciones y su equivalente en SNMPv1.

16

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires

GetRequest El formato y la semntica de esta PDU son idnticos a la de SNMPv1. La diferencia est en la manera de manejar la respuesta. En SNMPv2 esta operacin no es atmica, es decir, se devuelven valores en la lista de vnculos variables (variablebindings) aunque no se puedan devolver todos los valores requeridos. Si ocurre alguna condicin de excepcin (noSuchName, noSuchInstance), se devuelve el nombre de la variable junto con la indicacin de la excepcin en lugar del valor. En SNMPv2, la respuesta se construye procesando cada variable de la lista enviada de acuerdo con las siguientes reglas: Si una variable no tiene un prefijo de OID que concuerde exactamente con el prefijo de alguna variable accesible por este pedido, entonces el campo valor es igual a noSuchObject (no existe tal objeto). Caso contrario, si el nombre de la variable no concuerda exactamente con el nombre de alguna variable accesible por este pedido, entonces el campo valor es igual a noSuchInstance (no existe tal instancia). Este caso solo se da para objetos columnas donde la fila no existe o est bajo creacin. Caso contrario, el campo valor es igual al valor de la variable nombrada.

Si el procesamiento del nombre de la variable falla por cualquier otra razn, no se devuelve ningn valor. En cambio, la entidad retorna una PDU response con una condicin de error de genErr y un valor en el campo ndice de error que indica que variable de la lista variable-bindings (vnculos variables) que caus el problema. GetNextRequest El formato y la semntica de esta PDU son idnticos a la de SNMPv1. La diferencia es que puede devolver resultados parciales. En SNMPv2, la respuesta se construye procesando cada variable de la lista enviada de acuerdo con las siguientes reglas: 17

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Se determina la variable (instancia de objeto) que est luego en orden lexicogrfico a la variable nombrada. El par resultante en el campo vnculos variables (variable-bindings) contiene el nombre y el valor de la variable correspondiente. Si no existe sucesor en orden lexicogrfico , el par en el campo variable-bindings est formado por el nombre de la variable solicitada y el valor est seteado a endOfMibView, que significa que se ha alcanzado el final de los datos.

Si el procesamiento de cualquier variable falla por alguna otra razn, se sigue el mismo procedimiento que GetRequest. GetBulkRequest Una de las principales mejoras que proporciona SNMPv2 es esta PDU. Su propsito es minimizar el nmero de intercambios necesarios para recuperar una gran cantidad de informacin. La PDU GetBulkRequest le permite a un gestor SNMPv2 recuperar informacin de modo que la respuesta sea tan larga como sea posible teniendo en cuenta las restricciones en el tamao del mensaje. Esta operacin utiliza el mismo principio de seleccin que GetNextRequest, es decir, selecciona la prxima instancia en orden lexicogrfico. La diferencia est en que GetBulklRequest permite especificar el nmero de sucesores lexicogrficos a seleccionar. En esta PDU existen dos campos que no se encuentran en las dems PDUs: nonrepeaters (sin repeticiones) y max-repetitions (repeticiones mximas). El primero especfica el nmero de variables en la lista variable-bindings (vnculos variables) para las cuales debe ser retornado un slo sucesor lexicogrfico. El segundo determina la cantidad de sucesores lexicogrficos que deben devolverse para las restantes variables en el campo variable-bindings. SetRequest Igual en sintaxis y significado que en SNMPv1, salvo en la forma de procesar la respuesta, en la que se dan dos fases diferenciadas: Primero se validan todos los pares de variables con su valor, comprobando posibles condiciones de error. Segundo se realiza la modificacin de los valores por los recibidos en la PDU SetRequest.

SNMPv2-Trap 18

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Es generada y transmitida por una entidad SNMPv2 que acta como agente ante la aparicin de algn evento inusual, como en SNMPv1 pero con un formato distinto. Usa el mismo formato que las dems PDUs (a excepcin de GetBulkRequest) y contiene dentro del campo vnculos variables los siguientes objetos: sysUpTime.0: medida de tiempo cuando el agente fue reiniciado snmpTrapOID.0: Parte del grupo trap en la MIB SNMPv2 El agente puede optar por la inclusin de variables adicionales.

InformRequest Esta PDU la enva una entidad SNMPv2 actuando como gestor a otra entidad que acte como gestor, en beneficio de la aplicacin que usa sta ltima para completar la informacin de gestin. El campo vnculos variables de la PDU InformRequest contiene los mismos elementos que tiene el SNMPv2-Trap. Cuando la entidad receptora lee una InformRequest construye una respuesta con los mismos valores de los campos que en la PDU entrante, salvo que sea demasiado grande, caso en el que se responde con una PDU con condicin de error igual a tooBig e ndice de error igual a cero. Report No hay una definicin de cmo o cuando usar una PDU Report, debido a que la descripcin del uso de esta PDU se encontraba en documentos relacionados con la seguridad que fueron desechados. Se mantiene una referencia a esta PDU en el documento de la especificacin del protocolo. 2.6.3 Cdigos de error

En la siguiente tabla se enumeran los cdigos de error que hablamos con anterioridad y se realiza una breve descripcin de cada una de ellas.

19

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires
Cdigo de Error noError (0) tooBig (1) noSuchName (2) badValue (3) readOnly (4) genError (5) noAccess (6) wrongType (7) wrongLenght (8) wrongEncoding (9) wrongValue (10) noCreation (11) inconsistentValue (12) resourceUnavailable (13) commitFiled (14) undoFailed (15) autorizationError (16) noWritable (17) inconsistentName (18) v1 v2 Descripcin Sin error. Respuesta ms larga de lo que admite el formato de la PDU. OID no referencia a una instancia o no se encuentra en la vista. Valor inconsistente. Solo de lectura. Error genrico. La variable no es soportada por la vista de la MIB para esa operacin. El nuevo valor proporcionado es de un tipo de datos ASN.1 errneo. El nuevo valor proporcionado es de longitud errnea. El nuevo valor proporcionado est codificado errneamente. El nuevo valor est fuera del rango de valores admitidos para el tipo de objeto correspondiente. La variable no existe y el agente no puede crear instancias del tipo objeto correspondiente. El valor proporcionado es inconsistente con los valores de otro objeto en el agente. Un recurso requerido no puede ser reservado. Indica que hubo un fallo en la segunda pasada pero que se deshicieron los cambios. Indica que fall la segunda pasada y que algunos cambios no pudieron deshacerse. Error de autorizacin. La variable existe pero el agente no puede modificar instancias del tipo objeto correspondiente. La variable no existe y no puede ser creada porque el nombre de la instancia es inconsistente con los valores de otro objeto en el agente

x x x x x x

x x x x x x x x x x x x x x x x x x x

20

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires En la siguiente tabla encontramos las PDUs con la que trabaja cada error

21

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires 3 SNMPv3

En el mes de enero del ao 1998 la Internet Engineering Task Force (IETF) propone un conjunto de RFC desde la 2271 a la 2275 las cuales definen un conjunto de medidas para implementar las tres grandes falencias que posea el protocolo SNMP, estas son: - Autenticacin. - Seguridad. - Control de acceso. Estos nuevos estndares propuestos son los que definen la nueva versin de este protocolo denominada versin 3. Es as que esta nueva versin de SNMPv3 aborda especialmente dos aspectos del protocolo, la administracin y la seguridad. Adems el objetivo principal de SNMPv3 es definir una arquitectura modular que pueda ser fcilmente extendida. Es por eso que lo que antes llambamos agentes y gestores SNMP, ahora los pasaremos a llamar entidades SNMP. 3.1 Documentos que definen SNMPv3 Estos son los RFC que definen el funcionamiento de SNMPv3. RFC 2571 An Architecture for Describing SNMP Management Frameworks. B. Wijnen, D. Harrington, R. Presuhn. April 1999. (Format: TXT=139260 bytes) (Obsoletes RFC2271) (Status: DRAFT STANDARD) RFC 2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. April 1999. (Format: TXT=96035 bytes) (Obsoletes RFC2272) (Status: DRAFT STANDARD) RFC 2573 SNMP Applications. D. Levi, P. Meyer, B. Stewart. April 1999. (Format: TXT=150427 bytes) (Obsoletes RFC2273) (Status: DRAFT STANDARD) RFC 2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. April 1999. (Format: TXT=190755 bytes) (Obsoletes RFC2274) (Status: DRAFT STANDARD) RFC 2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. April 1999. (Format: TXT=79642 bytes) (Obsoletes RFC2275) (Status: DRAFT STANDARD) 3.2 Coexistencia entre SNMPv1, v2 y v3 SNMPv3 permite la transicin y coexistencia de los diferentes documentos MIB generados en la versin 1 (SNMPv1) y la versin 2 (SNMPv2).

22

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Por otra parte, tambin permite la coexistencia de las entidades que soportan las diferentes versiones de SNMP en una red multi-lenguaje y adems el procesamiento de operaciones protocolares en los mltiples lenguajes implementados. Adems los agentes SNMP estn dotados de Subsistemas de Procesamientos de Mensajes que aceptan mensajes de modelos SNMPv1, SNMPv2 y SNMPv3. 3.3 Mejoras respecto a las versiones anteriores La ltima versin de SNMP, SNMPv3, refuerza las prestaciones de seguridad, incluyendo autentificacin, privacidad y control de acceso; y de administracin de protocolo, con una mayor modularidad y la posibilidad de configuracin remota. Cabe destacar que SNMPv3 no se trata de un estndar que reemplaza a SNMPv1 y/o SNMPv2, sino que define una serie de capacidades adicionales de seguridad y administracin a ser utilizadas en conjuncin con SNMPv2 (preferiblemente) o SNMPv1. Estas mejoras hacen que SNMP se constituya en un protocolo de gestin susceptible de ser utilizado con altas prestaciones en todo tipo de redes, desplazando a medio plazo a CMIP (Common Management Information Protocol) como estndar de gestin de las grandes redes de las operadoras de telecomunicacin. El modelo de seguridad basado en usuario o USM (User-Based Security Model) proporciona los servicios de autentificacin y privacidad en SNMPv3. El mecanismo de autentificacin en USM asegura que un mensaje recibido fue, de hecho, trasmitido por la entidad indicada en el campo correspondiente a la fuente en la cabecera del mensaje; y adems, que el mensaje no fue alterado durante su trnsito y que no fue artificialmente retardado o repetido. Para conseguir la autentificacin, el gestor y el agente que desean comunicarse deben compartir la misma clave de autentificacin secreta configurada previamente fuera de SNMPv3 (no es almacenada en la MIB y no es accesible mediante SNMP). El protocolo de autentificacin utilizado puede ser el HMAC-MD5-96 o el HMAC-SHA-96. Para asegurarse de que los mensajes llegan dentro de una ventana temporal razonable que descarte el posible retardo de mensajes y el ataque mediante mensajes repetidos, se utilizan mecanismos de sincronizacin entre emisor y receptor y el chequeo de la ventana temporal constituida por el momento de emisin del mensaje y su momento de recepcin. Por otro lado, la facilidad de privacidad de USM posibilita a los gestores y a los agentes encriptar mensajes para prevenir que sean analizados por intrusos. De nuevo, el gestor y el agente deben compartir una clave secreta configurada previamente. El algoritmo de encriptacin utilizado es el CBC (Cipher Block Chaining) de DES (Data Encryption Standard), conocido tambin por DES-56. El modelo de control de acceso basado en vistas o VCAM (Views-Based Access Control Model) permite proporcionar diferentes niveles de acceso a las MIB de los agentes para los distintos gestores en SNMPv3. Un agente puede, de este modo, restringir el acceso de ciertos gestores a parte de su MIB o bien limitar las operaciones susceptibles de realizar por ciertos gestores sobre una parte de su MIB. La poltica de control de acceso a ser utilizada por el agente para cada gestor debe estar configurada previamente; consistiendo bsicamente en una tabla que detalla los privilegios de acceso para los distintos gestores autorizados. Mientras que la autentificacin es realizada por

23

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires usuario, el control de acceso es realizado por grupos, donde un grupo podra ser un conjunto de usuarios. 3.4 Arquitectura de SNMPv3 SNMP se compone de entidades, donde cada entidad implementa una parte de la funcionalidad de SNMP y asi, puede actuar como un agente en el nodo o como un nodo administrador. Una entidad esta compuesta por una coleccin de mdulos que interactan entre s para ofrecer unos servicios. En la siguiente figura se observa el diagrama general de bloques de una entidad SNMPv3.

En el diagrama podemos observar que existen dos partes bsicas en una entidad SNMP. Una de ellas es el Motor SNMP, que es obligatoria, y se encarga de implementar las funciones para envo y recepcin de mensajes, autenticacin, cifrado y control de acceso a los objetos de gestin. La segunda parte que compone a una entidad SNMP es el de las Aplicaciones que se encargan de procesar las PDUs y utilizan las funciones del motor. Observamos entonces que tanto el motor como las aplicaciones se encuentran implementadas por mdulos, esto trae la ventaja de poder actualizar cada modulo por separado, sin tener la necesidad de modificar el estndar completo. 3.5 Motor SNMP

24

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires El Motor de un agente SNMP se encarga de implementar distintas funciones que implican el envo y recepcin de datos. Este a su vez se encuentra distribuido en mdulos que interactan entre si. Estos mdulos son: Dispatcher Subsistema de procesamiento de mensajes Subsistema de Seguridad Subsistema de control de acceso

A continuacin veremos cuales son las funciones de estos mdulos. 3.5.1 Dispatcher

El Dispatcher o Despachador se encarga del envo y de la recepcin de mensajes y PDUs entre la red y los distintos mdulos de la entidad. Adems permite el soporte de distintas versiones de mensajes SNMP. Este modulo acepta las PDUs de las aplicaciones para su transmisin por la red y lo realiza a travs del subsistema de procesamiento de mensajes para preparar el mensaje saliente. En cambio, cuando los datos entran a la entidad SNMP, este se encarga de tomarlos y los entrega a la aplicacin correspondiente. 3.5.2 Procesamiento de mensajes

El Subsistema de Procesamiento de mensajes es el encargado de preparar los mensajes para envo y de extraer los datos de mensajes recibidos. Este Subsistema a la vez se compone de uno o varios modelos de Procesamiento de Mensajes, como lo muestra la figura.

De este modo, el procesador puede tomar mensajes de modelos que provengan de entidades que trabajen con SNMPv1, SNMPv2 o SNMPv3. Un ejemplo de cmo actan los mdulos al recibir un mensaje es el siguiente: Ejemplo: el Dispatcher recibe un mensaje SNMPv3 vlido y determina el numero de versin: 3 En ese caso el Dispatcher lo enva al Modelo de Procesamiento de Mensajes SNMPv3 donde se extrae el mensaje A su vez, este llama al Subsistema de Seguridad para descifrarlo (si es necesario) y autentificarlo, para luego si enviar el mensaje a la aplicacin adecuada 25

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires 3.5.3 Seguridad

El Subsistema de Seguridad es quien ejecuta las funciones de autenticacin y encriptado. Recibe y entrega los mensajes al Subsistema de Procesamiento de Mensajes. Ofrece varios servicios o esquemas de seguridad segn el modelo SNMPv1, SNMPv2, o SNMPv3

3.5.3.1 Modelo de Seguridad Basado en Usuarios (USM) El modelo de seguridad SNMPv3 se llama Modelo de Seguridad basado en Usuarios USM (por sus siglas en ingles, User-based Security Model) Especficado en el RFC2574. Esta especificacin abarca: Autenticacin: Proporciona integridad de datos y autenticacin del origen de los datos. Puntualidad: Brinda proteccin contra el retardo o reenvo de mensajes. Privacidad: Brinda proteccin contra la interpretacin de los datos del mensaje. Formato de mensaje: Define el formato del campo msgSecurityParameters, que soporta las funciones de autenticacin, puntualidad, y privacidad. Descubrimiento: Define procedimientos mediante los que un motor SNMP obtiene informacin acerca de otro motor SNMP. Gestin de claves: Define procedimientos para la generacin, actualizacin, y uso de las claves. El modelo de seguridad SNMPv3 protege los mensajes SNMPv3 frente las siguientes amenazas a la seguridad: Modificacin de mensajes generados por un usuario autorizado (por otro no autorizado) Suplantacin de un usuario autorizado por otro no autorizado

26

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Modificacin del flujo de mensajes. o SNMP se basa en UDP. Los mensajes podran ser capturados, reordenados, retrasados y, posiblemente, reenviados en un instante posterior. Por ejemplo, una operacin Set podra ser capturada y reenviada ms tarde Escuchas en la red. o Si los mensajes estn cifrados no tienen sentido para alguien que realiza escuchas El modelo de seguridad de SNMPv3 se basa actualmente en los siguientes protocolos de autenticacin y privacidad: Protocolos de autenticacin HMAC-MD5-96 y HMAC-SHA-96: o Verificar que el contenido del mensaje no ha sido alterado o Verifica a su vez la fuente del mensaje Protocolo de privacidad (cifrado) CBC-DES (Cipher Block Chaining-Data Encryption Standard) o CBC-AES (Cipher Block Chaining-Advanced Encryption Standard) o Encripta el contenido 3.5.3.2 Motor SNMP Autorizado. En cualquier transmisin de mensajes, una de las dos entidades se designa como motor SNMP autorizado. Para esto se siguen las siguientes reglas: 1. Cuando el mensaje SNMP contiene una carga que genera una respuesta (por ejemplo, las PDUs Get, GetNext, GetBulk, Set, o Inform), el receptor del mismo es el autorizado. 2. Cuando el mensaje SNMP contiene una carga que no genera una respuesta (por ejemplo, las PDUs SNMPv2-Trap, Response, o Report), el transmisor del mismo es el autorizado. Esta designacin sirve para un proceso de localizacin de clave, que se describir luego, pero le permite a un nico principal tener claves guardadas en mltiples motores; estas claves son localizadas por el motor autorizado de manera que el principal es responsable de una nica clave evitando el riesgo de seguridad que implica guardar mltiples copias de una misma clave en una red distribuida. 3.5.3.3 Funciones Criptogrficas USM tiene definida dos funciones criptogrficas: autenticacin y encriptacin. Para soportar estas funciones un motor SNMP requiere dos valores: una clave de autenticacin (authKey) y una clave de encriptacin (privKey). Se mantienen valores de estas claves para los siguientes usuarios:

27

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Usuarios locales: Cualquier principal en este motor SNMP para quin las operaciones de gestin estn autorizadas. Usuarios remotos: Cualquier principal en un motor SNMP remoto para quin se desea comunicacin. Estos valores son atributos de usuario guardados para cada usuario relevante. Los valores de privKey y authKey no son accesibles mediante SNMP. 3.5.3.4 Autenticacin Se definen dos alternativas para esta tarea, HMAC-MD5-96 y HMAC-SHA-96. La mecnica de esta funcin es que a travs de una cadena de bit de entrada de cualquier longitud finita, generar un nico resumen de salida de longitud fija. Que en el caso de esta norma es de 20 Byte para SHA o 16 Byte para MD5. Esta funcin es llamada One Way pues no es posible a travs del resumen de salida obtener el texto de entrada, tambin resultar computacionalmente imposible obtener un valor de salida igual a travs de otro valor de entrada, como as tampoco desde un valor de salida ya calculado, obtener otro valor de entrada diferente al verdadero. La aplicacin aqu propuesta toma los datos y la clave y produce un resumen: - Resumen = H (clave, datos). En cualquiera de los dos casos, se toman como vlidos los primeros 96 bit, descartando el resto. Esta especificacin soporta el protocolo HMAC [RFC-2104] con la opcin SHA1 (Hash Message Autentication-Secure Hash Standard Versin 1) [RFC-2403] y MD5 (Messge Digest Verin 5) [RFC-2403]. 3.5.3.5 Encriptacin. USM utiliza el modo cipher block chaining (CBC) del Data Encryption Standart (DES) para la encriptacin. La clave privada (PrivKey) antes mencionada de longitud 16 byte es empleada aqu dividindola en dos, los primeros 8 Byte, es decir 64 bit son empleados como clave para DES, el cual solo tendr en cuenta 56, dejando 8 para control de paridad. Los ltimos 8 Byte son empleados como Vector de Inicializacin (IV) para comenzar con el cifrado en cadena. Esta tcnica CBC, se basa en tomar el primer bloque de texto plano, y realizar una operacin XOR con un Vector de inicializacin y luego de esta operacin recin se pasar al cifrado de ese bloque. En el segundo bloque se realizar nuevamente la operacin XOR, pero esta vez ser el texto plano de este bloque con el bloque cifrado anteriormente, y luego se cifrar. Esta mecnica se ir realizando en los sucesivos bloques, es decir XOR con el bloque cifrado anterior y luego cifrado. El descifrado se realiza en forma inversa.

28

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires - cifrado = E (clave, texto). - D (clave, cifrado) = texto. 3.5.3.6 Localizacin de claves: Una clave localizada es un secreto compartido entre un usuario y un motor SNMP autoritativo. El problema del empleo de una sola clave por parte del usuario con todos los agentes es que si se descubriera la misma, sera vulnerable todo el sistema. Si el caso fuera lo contrario es decir que se deseara emplear una clave distinta para cada agente, entonces el usuario debera recordar todas las contraseas lo cual en la prctica no es viable. Para dar solucin a estos problemas la RFC 2574 propone este proceso por el cual una clave nica de usuario (o pueden ser dos: una para privacidad y otra para autenticacin) es convertida a mltiples claves nicas tambin, una para cada motor SNMP, este proceso es lo que se denomina Localizacin de claves. Las caractersticas fundamentales que propone este proceso son: Cada agente SNMP tiene su propia clave nica para cada usuario autorizado a administrarlo, por lo tanto si la clave de uno de ellos es comprometida, no lo sern las del resto. La clave de un usuario es diferente en cada agente SNMP, por lo tanto si se compromete la clave de un agente, no comprometer al resto ni a la clave del usuario. La administracin de la red, puede realizarse en forma segura remotamente desde cualquier punto de la red. Este proceso se genera a partir de una contrasea de usuario (Passw) que puede tener cualquier longitud. La RFC 2574 no hace referencia sobre la misma, pero las polticas de seguridad deberan determinar las pautas para que no sea trivial. Los pasos a seguir en este proceso son: a. El usuario introduce una contrasea (Passw). b. El primer algoritmo repite la misma tantas veces como fuera necesario para producir una cadena de caracteres de longitud 220, es decir 1.048.576 octetos. c. Se aplica el algoritmo hash con MD5 o SHA1 (explicados en 6.1.), y se obtiene la clave de usuario (Ku) de longitud 16 o 20 octetos, acorde a la funcin empleada. d. Se concatena la clave de usuario (Ku) con el identificador de cada motor SNMP (SNMP engine ID) y nuevamente se aplica el algoritmo hash con MD5 o SHA1 y se obtiene la clave de usuario Localizada (Kul) de longitud 16 o 20 octetos, acorde a la funcin empleada.

29

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires e. Esta clave debe ser configurada en los agentes SNMP del sistema en forma segura. f. Queda almacenada en cada agente SNMP esta ltima Kul por cada usuario, la cual se debe tener en cuenta que no es una contrasea sino la funcin One Way de ciertas concatenaciones de esa contrasea, es decir que desde esta no se puede reconstruir la contrasea del usuario, y como la misma no est disponible va SNMP, no se podra tener acceso a ella. La siguiente grafica muestra los pasos requeridos para obtener la clave de forma segura.

3.5.4

Control de accesos

El Subsistema de Control de Acceso es el encargado de proveer servicios de autorizacin para controlar el acceso a las MIBs. Un Agente soporta uno o ms modelos de Control de Accesos diferentes llamado View-Based Access Control Model (VACM). Este subsistema se ejecuta en los agentes tradicionales, permitiendo determinar quien est autorizado a acceder a la MIB de los mismos. El nico modelo definido para esta actividad se denomina Modelo de Control de Accesos basado en Vistas (VACM: View-Based Access Control Model) y est definido en la RFC-2575. VACM tiene dos caractersticas fundamentales: Determina si un acceso a la MIB local est permitido. Posee su propia MIB en la cual se definen las polticas de acceso y habilita la configuracin remota. Adems se definen cinco elementos que constituyen la VACM:

30

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires 1. Grupos: Es un conjunto de cero o ms duplas {Modelo de Seguridad, Nombre de seguridad} que definen los Objetos que pueden ser administrados por ese Nombre. 2. Nivel de seguridad: Define qu tareas sern permitidas (lectura, escritura o notificacin) para cada grupo. 3. Contexto: Es un subconjunto de instancias de objetos en la MIB local. Permite agrupar objetos con distintas polticas de acceso. 4. Vistas de la MIB: Define conjuntos especficos de objetos administrados, los cuales se pueden agrupar en jerarquas de rboles y familias de manera tal que se pueda, por ejemplo, restringir su acceso a determinados grupos. 5. Poltica de acceso: VACM permite a un motor SNMP ser configurado para asegurar un conjunto de accesos correctos, los cuales dependen de los siguientes factores: 3.6 Los distintos usuarios pueden tener distintos privilegios de acceso. El nivel de seguridad para una determinada solicitud. El modelo de seguridad empleado para procesar las solicitudes de mensajes. El contexto de la MIB. La instancia al objeto para el cual fue solicitado el acceso. El tipo de acceso solicitado (lectura, escritura o notificacin).

Aplicaciones SNMP

SNMP posee cinco tipos de aplicaciones, las cuales pueden asociarse con cada uno de sus instrumentos. Dichas aplicaciones son las siguientes: Generadores de Orden Generador de Respuestas Creadores de la Notificacin Receptores de la notificacin Proxy

En RFC 2573 se describen detalladamente este tipo de aplicaciones 3.6.3 Generador de Orden

Inicia las PDUs SNMP Get, GetNext, GetBulk o SetRequest que enva el sistema local y procesa las respuestas a los pedidos que antes se haban enviado. Para iniciar las respuestas deber llamar al Dispatcher, dndole los datos que luego formarn parte del header del mensaje, entre los que se encontrarn el destino del mensaje, la versin del protocolo a utilizar, modelo de seguridad y nivel de seguridad que sern requeridos, la PDU y una bandera indicando si espera o no respuesta entre otros.

31

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires 3.6.4 Generador de Respuestas

Recibe las solicitudes destinadas al sistema local y luego deber desarrollar la operacin de protocolos necesaria para generar una respuesta adecuada y reenviarla a la entidad solicitante. Deber utilizar control de acceso para verificar si el solicitante est autorizado a obtener esa informacin u ordenar la modificacin de datos. Una vez recibida la solicitud y determinado que el mensaje debe responderse, esta aplicacin deber determinar el tipo de mensaje entrante, comunicarse con la base de datos, preparar la respuesta y luego entregar esa respuesta al Dispatcher para que ste la enve. Si por el contrario se determina que esa solicitud no debe responderse se enva al solicitante un mensaje comunicando una falla en el acceso.

3.6.5

Creadores de notificacin

Es el encargado de monitorear al sistema ante condiciones o eventos particulares y, de producirse una anormalidad, genera un mensaje Trap o Inform relativo a esas condiciones monitoreadas. El Creador de notificaciones acta de la siguiente manera: Primero, empleando mecanismos de filtro apropiados se determina cul es la informacin que debe enviarse. Si el filtro determina que una notificacin no debe enviarse se contina el proceso, sino se recuperan variables de la Base de datos de Informacin local que permitan determinar la entidad a la que se le debe enviar el mensaje, el modelo de seguridad a utilizar y el nivel de seguridad requerido. Luego se hace una verificacin para determinar si debe enviarse o no la notificacin. Una vez concluidos estos pasos se construye una PDU que si no necesita respuesta se enva al Despachador, en caso contrario antes de que la PDU sea enviada al Despachador se indica la necesidad de una respuesta, se cachean los datos del gestor al que se le envi la informacin ante la posible necesidad de retransmitir los datos [RFC 2573]. 3.6.6 Receptores de notificacin

Escucha por mensajes de notificacin o Traps y genera un mensaje de respuesta. 3.6.7 Proxy Forwarder

Se encarga del direccionamiento de mensajes SNMP. Es una aplicacin opcional El uso de SNMP requiere que todos los agentes, as como los managers, deban soportar una suite de protocolo, tal como UDP e IP. Esto limita la administracin

32

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires directa y excluye otros dispositivos, tales como puentes y modems, que no soportan cualquier parte de la suite del protocolo TCP/IP. Para acomodar dispositivos que no implementan SNMP, se desarrollado el concepto de proxy. En este esquema un agente SNMP acta como un proxy para uno o ms dispositivos; esto es, el agente SNMP acta en nombre de los dispositivos que se encuentran en el proxy.

Entonces esta aplicacin se encarga de adelantar mensajes. Usa primitivas del Despachador para adelantar cuatro tipos de mensajes: Los mensajes creados por la aplicacin Generador de Ordenes, o sea los mensajes que el gestor le enva al cliente: determina a qu motor debera ir el mensaje y entrega la respuesta que antes se haba recibido de ese motor. Los mensajes creados por la aplicacin Creador de Notificaciones, o sea que contienen notificaciones ya sea Trap o Inform: el Proxy debe determinar qu motores debern recibir la notificacin. Los mensajes creados por la aplicacin generadora de comandos, o sea las respuestas que el Agente le enva al Gestor: en este caso el Proxy determina las solicitudes y notificaciones que antes estuvieron en juego para adelantar la respuesta. Mensajes que contienen indicaciones de reporte: el proxy determina qu clases internas de PDU y que notificaciones previas estn en juego.

Para que el proxy pueda llevar a cabo su tarea debe basarse en la informacin de contexto que le permitir determinar qu motores accedieron a la informacin y cmo adelantar los mensajes y qu motor deber recibir notificaciones de la informacin.

33

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires 4 Comparacin entre SNMPv1, v2 y v3

Durante todo el informe estuvimos hablando de las tres versiones del protocolo de gestin de redes SNMP, ahora en este apartado haremos una comparacin entre estas versiones indicando cuales son sus ventajas. SNMPv1 constituye la primera definicin e implementacin del protocolo SNMP, estando descrito en las RFC 1155, 1157 y 1212 del IETF (Internet Engineering Task Force). El vertiginoso crecimiento de SNMP desde su aparicin en 1988, puso pronto en evidencia sus debilidades, principalmente su imposibilidad de especificar de una forma sencilla la transferencia de grandes bloques de datos y la ausencia de mecanismos de seguridad; debilidades que trataran de ser subsanadas en las posteriores definiciones del protocolo. Pero a pesar de sus debilidades, esta versin del protocolo SNMP es el mas fcil de implementar, lo que le permite residir en equipos de bajos recursos. Sus operaciones son simples y suficientes para que un gestor pueda obtener los valores de una o ms instancias de un agente. Debido a la imposibilidad de transferir grandes bloques de datos y de contar con un nivel de seguridad bajo que no ofrece autenticacin ni privacidad es que se decide realizar una nueva versin de este protocolo. SNMPv2 apareci en 1993, definido en las RFC 1441-1452. SNMP v1 y v2 tienen muchas caractersticas en comn, siendo la principal mejora la introduccin de tres nuevas operaciones de protocolo: GetBulkRequest para que el gestor recupere de una forma eficiente grandes bloques de datos, tales como las columnas de una tabla; InformRequest para que un agente enve informacin espontnea al gestor y reciba una confirmacin; y Report para que el agente enve de forma espontnea excepciones y errores de protocolo. Estas nuevas operaciones se traducen en nuevas mejoras para la adquisicin de datos, porque en la versin 1 cuando una de las variables en la lista de un comando GET fallaba, hacia que todo el comando fallara, obligando a eliminar esta variable de la lista y volver a consultar. En SNMPv2 este procesamiento es automtico, y el error se indica en el valor de retorno de la variable. Otra de las modificaciones se encuentra en la PDU de la operacin Trap. Esta operacin contaba con una PDU propia en la versin 1, pero esto fue modificado en la nueva versin, ya que en la nueva definicin, el PDU de la operacin Trap comparte el mismo formato que las PDUs de las operaciones GetRequest y SetRequest. SNMPv2 tambin incorpora un conjunto mayor de cdigos de error y ms colecciones de datos. En 1995 apareci una revisin de SNMPv2, denominada SNMPv2c y descrita en las RFC 1901-1910, aadiendo como mejoras una configuracin ms sencilla y una mayor modularidad; pero manteniendo el sencillo e inseguro mecanismo de autentificacin de SNMPv1 y SNMPv2 basado en la correspondencia del denominado nombre de comunidad. Esto de todas maneras segua mostrando las falencias que mostraba SNMP en cuanto a la seguridad, ni SNMPv1, ni SNMPv2 pueden autenticar la fuente del mensaje y mucho menos proporcionar encriptacin del mismo. En una red de gestin dnde no exista o no sea posible la autenticacin, hay probabilidades de que usuarios no autorizados fcilmente puedan ejercer tareas de manejo ms an espiar informacin cuando sta es pasada de un Sistema otro. Es por ello que muchas implementaciones en SNMPv1/SNMPv2 son limitadas a capacidades de Slo Lectura, lo que como consecuencia reduce las utilidades de control y monitoreo de la red.

34

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires Debido a estas falencias en la seguridad se crea una nueva versin de este protocolo llamado SNMPv3 en el ao 1997. Esta versin refuerza las prestaciones de seguridad ya que proporciona los servicios de autentificacin y privacidad en la transferencia de datos entre las entidades. Ya vimos que SNMPv3 utiliza el modelo de seguridad basado en usuario o USM (User-Based Security Model) que es la encargada de realizar la autenticacin de los mensajes utilizando claves secretas proporcionadas por el protocolo de autenticacin HMAC-MD5-96 o el HMAC-SHA-96. Adems USM encripta los mensajes utilizando los algoritmos de encriptacin DES o AES. SNMPv3 refuerza tambin el control de acceso a los diferentes niveles de la MIB mediante el modelo de control de acceso basado en vistas o VCAM (Views-Based Access Control Model). De todas maneras, la mayor ventaja de esta versin es definir las funcionalidades de un agente SNMP en mdulos separados que interactan entre si. Esto permite que las actualizaciones sean mucho ms simples de realizar modificando los mdulos y permite a su vez una coexistencia ms sencilla entre las distintas versiones de SNMP. 5 Conclusiones

Una red corporativa debe contar con un sistema de administracin porque hay que asegurar a los usuarios: Utilizacin. Monitorizacin del trfico y calidad de servicio. Brindar soluciones rpidas a los problemas que aparezcan.

De aqu surge la necesidad de desarrollar un protocolo de gestin de red como el SNMP. En la primera versin (SNMPv1) se implementan las operaciones de lectura/escritura de datos y envo de eventos (TRAP). Su principal desventaja es la falta de seguridad ya que solo incluye el concepto de COMUNIDAD para limitar el acceso de las estaciones de gestin a los agentes. Por ello surge la segunda versin de SNMP (SNMPv2), con el objetivo de avanzar en el tema de seguridad e introducir algunas mejoras de gestin. Al desarrollar el proyecto se observa que los esfuerzos para mejorar la seguridad dificultan mucho la implementacin por lo que se abandona el tema y solo se implementan mejoras en la gestin como el agregado de operaciones (GetBulkRequest) y modificacin en los tipos de datos entre otros. Finalmente la ltima versin del protocolo (SNMPv3) dio solucin al tema de seguridad utilizando un modelo basado en usuario (USM), el mismo proporciona servicios de autenticacin y control de acceso mediante claves secretas. Tambin se utilizan algoritmos de encriptacin DES o AES.

35

Seminario de Redes - Trabajo Prctico N1 Protocolo SNMP Facultad de Ingeniera Universidad de Buenos Aires El competidor de SNMP es CMIP (Common Management Information Protocol) aunque es ms utilizado para redes WAN mientras que SNMP se prefiere en redes LAN. Tiene un nivel de seguridad mucho ms avanzado que SNMP pero es ms difcil su implementacin, adems es costoso tanto a nivel de hardware como software. En conclusin, SNMP es una buena eleccin para gestionar una red ya que es simple en su operacin y fue resolviendo sus falencias con sus distintas versiones hasta la versin 3 donde implementa seguridad en el protocolo. 6 Bibliografa

[1] Simple Network Management Protocol en http://es.wikipedia.org/wiki/SNMP [2] "Data and Computer communications". W. Stallings, 7a Edicin, Prentice Hall. [3] SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 (3rd Edition) Stalling, William. Addison Wesley 1999. [4] TCP/IP Simple Network Management Protocol (SNMP) Protocol en http://www.tcpipguide.com [5] Gestin de red en http://ditec.um.es/laso/docs/tut-tcpip [6] SNMPv3 en http://neutron.ing.ucv.ve/revista-e/No6/Brice%C3%B1o%20Maria/SNMPv3.html [7] SNMP en http://www.cisco.com/en/US/docs/internetworking/technology/handbook/SNMP.html [8] Normas en castellano en http://www.normes-internet.com [9] Chapter 8: Basic Concepts of SNMP - Simple Network Mgmt Protocol The text, "Network Security Essentials, Applications and Standards" by William Stallings) http://www.csc.gatech.edu/~copeland/8813/slides/08-SNMP.pdf

36