FACULTAD DE INGENIERIA

FACULTAD DE INGENIERIA UNIVERSIDAD DE BUENOS AIRES 66.48 SEMINARIO DE ELECTRÓNICA Profesores: Marcelo Utard Pablo Ronco Javier Bozzuto GRUPO F.F.G.G. INTEGRANTES : FERNÁNDEZ Diego (80345) FERRÉ, Federico (77548) GAVINOWICH Gabriel (80766) GRANT Melisa (82224) Octubre 2006

Índice Objetivo... 3 Introducción Teórica... 4 Management Information Base(MIB)... 6 Identificador de objeto (Object ID)... 10 Tablas... 10 Formato general de los mensajes y ASN.1 (Abstract Syntax Notation 1). 13 Tipos de datos en SMI... 14 Otros campos utilizados en la definición de objetos... 14 Estructura de los mensajes: PDUs y Operaciones... 15 Otros aspectos a considerar... 21 Maqueta... 22 Software utilizado... 23 Descripción y ejemplos de uso de los principales comandos... 24 PDU GET-REQUEST Y GET-RESPONSE... 27 PDU GET REQUEST ERRÓNEO... 30 USO DEL GET-NEXT CON EL COMANDO WALK... 32 PDU SET... 36 SET ERRÓNEO (authentication failure)... 39 SET ERRÓNEO (Bad Value)... 42 GET BULK... 44 TRAPS... 46 Conclusiones... 48 Bibliografía... 49 Página 2 de 49

Objetivo En el presente Trabajo Practico, se hace un estudio de las funciones básicas del protocolo Simple Network Managment Protocol (SNMP), realizando distintas pruebas basadas en la utilización de comandos, y analizando los resultados obtenidos. Página 3 de 49

Introducción Teórica El SNMP es un protocolo de la capa de aplicación que permite el intercambio de información de administración entre dispositivos de red,dando la posibilidad a los administradores de supervisar el desempeño de la red y buscar y resolver problemas. Una red administrada a través de SNMP consiste de tres componentes claves: Dispositivos administrados. Agentes. Sistemas administradores de red (NMS s) Un dispositivo administrado es un nodo de red que contiene un agente SNMP y reside en una red administrada. Estos recogen y almacenan información de administración, la cual es puesta a disposición de los NMS s usando SNMP. Los dispositivos administrados, a veces llamados elementos de red, pueden ser routers, servidores de acceso, switches, bridges, hubs, computadoras o impresoras. Un agente es un módulo de software de administración de red que reside en un dispositivo administrado. Es el encargado de comunicarse con el administrador contestando sus pedidos o enviándole información cuando corresponda. A su vez, traduce la información en un formato que es compatible con SNMP. Un administrador es el encargado de supervisar y controlar a los dispositivos administrados, pidiendo la información necesaria a los agentes. Para el funcionamiento de una red administrada, es necesaria la presencia de al menos un sistema administrador. Página 4 de 49

Existen actualmente tres versiones de SNMP. Version 1 (SNMPv1, descripta en la RFC 1157) implementación inicial de SNMP. Version 2 (SNMPv2c, descripta en la RFC 1902) es la segunda edición de SNMP. Provee nuevos tipos de datos, tamaños de contadores,y operaciones de protocolo. Version 3 (SNMPv3, descripta en las RFC 2271 a RFC 2275) es la versión más reciente de SNMP. Página 5 de 49

Management Information Base(MIB) Todas las variables que utiliza el SNMP se ordenan en una estructura de jerarquías virtual conocida como Managment Information Base (MIB). Todos los nombres de variables válidos están definidos en este encuadre, que establece una estructura de árbol para todos los objetos (y sus nombres) que pueden ser manejados mediante SNMP. En cierta forma la MIB es similar a un sistema de archivos. En lugar de ordenar archivos, la MIB organiza lógicamente información de administración, en una jerarquía de árbol. Cada nodo en el árbol esta identificado por una cadena de texto corta, denominada label, y un número entero, que representa su posición dentro del nivel en el árbol. En la siguiente figura se puede visualizar la parte superior del árbol: Página 6 de 49

La parte superior del árbol consiste en Organizaciones de estándares: iso(1), ccitt(2), y la fusión iso-ccitt(3). Bajo el nodo iso(1), hay un nodo llamado org(3) para otras organizaciones. Bajo este nodo esta el dod(6) para el departamento de defensa, y bajo este último está internet(1) un sub-árbol para la comunidad internet, del mismo se desprenden las siguientes ramas: Página 7 de 49

Sub - Arbol Descripcion directory(1) Directorio OSI mgmt(2) Objetos Standard de RFC experimental(3) Experimentos de internet private(4) Específicos de proveedor security(5) Seguridad snmpv2(6) Internos de SNMP Tomando la rama de mgmt(2), el primer nodo es la misma MIB, un nodo único llamado mib-2(1). Se encuentra entonces la primer serie de ramas, llamadas Grupos de objetos (Object groups) que poseen las variables que deseamos consultar o controlar, y se listan a continuación: system(1) interfaces(2) at(3) ip(4) icmp(5) Página 8 de 49

tcp(6) udp(7) egp(8) cmot(9) transmission(10) snmp(11) Página 9 de 49

Identificador de objeto (Object ID) 66.48 Seminario de Redes A cada variable MIB se le asigna un identificador de objeto. El mismo esta compuesto por la secuencia de etiquetas numéricas de los nodos presentes en el camino desde la raíz al objeto. Por ejemplo, para obtener el Identificador de Objeto de sysdescr(1), debemos recorrer el árbol según se muestra a continuación: De esta forma el OID para el árbol internet es 1.3.6.1, el OID para el grupo de objetos system es 1.3.6.1.2.1.1, y el OID para el objeto sysdescr es 1.3.6.1.2.1.1.1. De todas formas, cuando deseemos usar este OID en la práctica, deberemos añadir un sufijo con otro número para obtener el valor de esta variable: la instancia del objeto. Tablas Para variables simples, el identificador de instancia 0 alude a la variable con ese nombre. Sin embargo la MIB también puede contener tablas de variables relacionadas. Página 10 de 49

MIB de Cisco La MIB privada de Cisco está representada por el identificador de objeto 1.3.6.1.4.1.9, o iso.org.dod.internet.private.enterprise.cisco. La MIB Cisco incluye los siguientes sub-árboles: local (2), temporary (3), and, ciscomgmt (9).. El sub-árbol local contiene objetos MIB definidos con anterioridad al IOS (Cisco Internetwork Operating System) Version 10.2. Estos objetos MIB implementaron la SMI de SNMPv1. Sin embargo,comenzando con el IOS versión 10.2, las MIB son definidas según el SMI de SNMPv2. Estas MIBs se sitúan en el sub-árbol ciscomgmt. Las MIBs definidas en local están siendo gradualmente desacreditadas por cisco, y reemplazadas por nuevos objetos definidos en ciscomgmt. Un ejemplo de esto ultimo es el grupo TCP, que habiendo sido formado primeramente en el grupo local, fue reemplazado por un nuevo grupo TCP en el arbol correspondiente a ciscomgmt. Página 11 de 49

A continuación se muestra un diagrama del árbol correspondiente a la MIB de cisco. Página 12 de 49

Formato general de los mensajes y ASN.1 (Abstract Syntax Notation 1) Los estándares no describen el formato del mensaje SNMP usando una simple lista de campos como ocurre en la mayoría de los estándares TCP/IP. En su lugar, los mensajes son definidos usando un lenguaje de descripción de datos llamado Abstract Syntax Notation 1 (ASN.1) que a su vez también es utilizado para describir los objetos MIB. El ASN.1 se describe en el estándar Structure of Managment Information (SMI). De esta forma, al estar los campos del mensaje definidos como objetos, poseen ciertas características: cada campo posee un nombre, y sus contenidos se describen usando uno de los tipos de datos estándar definidos por el SMI. Entonces, a diferencia de los formatos de mensaje normales donde cada campo posee solo un nombre y una longitud, el formato del campo del mensaje snmp posee un nombre y una sintaxis, como por ejemplo Integer, Octet String o IpAddress. La sintaxis del campo define su longitud, formato y cómo es usado. Página 13 de 49

Tipos de datos en SMI Se definen básicamente dos tipos de datos Datos tradicionales : Son fragmentos de información singulares, como por ejemplo enteros o cadenas. Estos son llamados Tipos Básicos en SMIv2. SMIv1 diferencia entre los tipos Primitivos, como por ejemplo enteros definidos en ASN.1, y Tipos Definidos que son formas especiales de los tipos primitivos pero con cierto significado especial cuando son usados. SMIv2 no diferencia entre estos términos. Datos Tabulares: Son colecciones múltiples de datos. Estos pueden tomar la forma de una lista, o una tabla de tipos básicos. Por ejemplo, una tabla de enteros puede ser construida para representar una serie de valores. En SMIv1 estos se llaman Tipos Constructores, mientras que en SMIv2 se llaman Tablas Conceptuales. Estas pueden ser accedidas utilizando mecanismos especiales de SNMP diseñados para leer tablas, que son analizados en la siguiente sección. Otros campos utilizados en la definición de objetos En el caso de la definición de objetos, la SMI define además de la sintaxis un campo de acceso, que define cómo la aplicación de SNMP usará el objeto, Status, que define la vigencia actual de la definición del objeto, y una descripción textual del mismo. Página 14 de 49

Estructura de los mensajes: PDUs y Operaciones El SNMPv1 cuenta con cinco mensajes protocolares (PDU): GET : Le permite al administrador obtener la instancia de un objeto del agente. GETNEXT: Le permite al administrador obtener la siguiente instancia de un objeto del agente SET: Le permite al administrador setear el valor de una instancia de un objeto del agente. GETRESPONSE: Respuesta del agente a un pedido del administrador. TRAP: Lo manda el agente ante una situación determinada en el dispositivo administrado. Estos cinco mensajes definen 4 operaciones: Página 15 de 49

El SNMPv2 redefine el PDU GetResponse por Response y agrega otros dos: GETBULK: permite obtener del agente una gran cantidad de instancias con un solo pedido, ideal para obtener tablas rápidamente. INFORM: Similar al Trap pero debe recibir un ACK del administrador, sino retransmite. Como se mencionó anteriormente las tramas no estan definidas en forma de campos, sino con el formato ASN.1. De la RFC 1157 se obtiene la siguiente definición: Message ::= SEQUENCE { version -- version-1 for this RFC INTEGER { version-1(0) }, community -- community name OCTET STRING, } data ANY -- e.g., PDUs if trivial -- authentication is being used Donde dice data, puede ser reemplazado con cualquiera de los PDUs, si se observa la definición del GetRequest GetRequest-PDU ::= [0] IMPLICIT SEQUENCE { request-id RequestID, error-status -- always 0 ErrorStatus, error-index -- always 0 ErrorIndex, Página 16 de 49

variable-bindings VarBindList } A su vez los tipos error-index, error-status y demás tienen su definición en la RFC 1157. Si se analiza una trama GetRequest de la MIB sysuptime (1.3.6.1.2.1.1.3 ) tendría el siguiente formato (todos los números en hexadecimal): 30 26 2 1 0 4 6 70 sequence largo INTEGER largo vers string Largo p 75 62 6c 69 63 a0 19 2 u b l i c getreq largo INT 2 7c 35 2 1 0 2 1 largo request ID request ID INT largo status INTEGER largo 0 30 0d 30 0b 6 7 2b err index sequence largo secuence largo OI largo 1,3 6 1 2 1 1 3 5 0,6,1,2,1,1,3 null largo Pero para tener una lectura más comoda a continuación se las tratará como si fuesen campos sabiendo que antes hubo que interpretar la notación ASN.1. La genereal se vería: Versión Community string Campos de control Variable Binding En el campo versión, se especifica la versión del snmp utilizado, para la v1, este campo esta en 0. El community string indica la comunidad a la que pertenece el que manda y el que recibe, funciona como método de autenticación. Los campos de control y de variables, son dependientes del PDU que se utilice, para los get, getnext y getresponse se usa: Tipo Identificador de pedido Error Indice de error OI Valor El tipo indica el tipo de PDU, las opciones son: Página 17 de 49

Tipo PDU 0 Get 1 GetNext 2 GetResponse 3 Set 4 Trap El identificador es un número usado para asociar los pedidos a su respuesta (que mantienen el mismo número). Error: Es un código que indica el error que se produjo, es llenado por el GetResponse, 0 significa que no se ha producido ningún error. Índice de error: Es un puntero al objeto que genero el error. Variable Binding: Esta formado por el identificador del objeto como una secuencia de enteros y el valor que ese objeto posee (si es un get o getnext este número estará en cero. Para los TRAPS, el formato es el siguiente: Tipo Enterprise Dirección del agente Código Trap generico Código Trap especifico Time Stamp OI Valor Enterprise: El identificador del objeto que generó el trap Dirección del agente: La dirección IP del agente que mandó el trap Código de Trap genérico: Si el trap esta dentro de una lista de traps predefinidos (cold reset, power on, etc) se especifica el código en este campo. Página 18 de 49

Código de Trap específico:si el trap es generado por alguna causa que es propia del dispositivo, el código va en este campo. Los códigos son dependientes del fabricante. Time Stamp: El tiempo desde el ultimo encendido del dispositivo que envía el trap. OI y Valor: Similares al caso anterior. En el Trap se manda información adicional que se considerá puede ser útil. En SNMPv2 los campos de control y de variable binding se mantienen igual, en cambio según la versión, se agregan una serie de parámetros para reforzar la seguridad. Para identificar el SNMPv2 el campo de versión es rellenado con 1. En el TP usaremos la versión el comando GETBULK de la v2c (community) que mantiene exactamente igual los campos de version y community string, en el resto: Tipo Identificador de pedido Non repeaters Max repetitions OI Valor Non repeaters: Da la cantidad de objetos sobre los que no se harán iteraraciones, es decir si el valor es de 2 trará los dos primeros objetos como si fuera un getnext normal y sobre los siguientes hará las iteraciones. Max repetitions: la cantidad de veces que iterará sobre los objetos a continuación de los nonrepeaters. Es decir, el número de objetos que traerá el getbulk es: Página 19 de 49

O = N + M * R Donde La cantidad de objetos que se pidieron es X N = Non Repeaters R = X Non Repeaters M = Max repetitions Hay limitaciones en cuanto a los valores que pueden tomar los campos, por ejemplo si se piden dos objetos (X = 2) la cantidad especificada en Non Repeaters no puede valer 4. La resolución de estos casos está contemplada en la RFC 3416. Página 20 de 49

Otros aspectos a considerar 66.48 Seminario de Redes SNMP es un protocolo de capa de aplicación usado en la mayoría de los casos sobre UDP. El mayor overhead y el tener que establecer una conexión en cada intercambio, hacen a TCP poco ideal para un protocolo que continuamente esta preguntando a los agentes. El uso de UDP también tiene su desventaja en la falta de confiabilidad, lo que obliga al NMS a pedir retransmisiones cuando no obtiene respuesta a su pedido. La característica de SNMP hace que la duplicación de pedidos o respuestas no represente un problema, ya que simplemente se recibirá la misma información dos veces. El mayor inconveniente se presenta en el trap, si este mensaje se pierde no hay forma de recuperarlo, es por esto que en la v2 se introduce el inform para asegurar al agente que el mensaje enviado llegó a destino. Hay dos puertos reservados entre los well known ports el 161 es el puerto en que escuchan los agentes y administradores para recibir los get, getnext y set. En cambio los administradores esperan recibir por el puerto 162 los traps emitidos por los agentes. Página 21 de 49

Maqueta Se utilizó un router Cisco 1601, conectado a la PC con la que hicimos el sniffing, a traves de su puerto Eth0. El siguiente esquema muestra la configuración de la red con las respectivas direcciones IP: Se utilizo la máscara 255.255.252.0 con lo cual la dirección de red es 157.92.48.0. Página 22 de 49

Software utilizado Se utilizó para la realización del presente Trabajo Practico, el Software Net-SNMP. El mismo consta de un conjunto de aplicaciones utilizadas para implementar SNMP v1, SNMP v2c y SNMP v3 utilizando IPv4 o IPv6. Entre otras cosas, las aplicaciones de linea de comandos de este programa permiten: Obtener información de un dispositivo con soporte SNMP, utilizando los request simples (snmpget, snmpgetnext) o multiples(snmpwalk,snmptable, snmpdelta) Manipular información de configuración de un dispositivo con soporte SNMP(snmpset) Obtener determinada información estipulada de un dispositivo con soporte snmp(snmpdf,snmpnetstat,snmpstatus) Convertir entre las formas numéricas y textuales de los OID de las MIB, y visualizar el contenido y estructura de la misma (snmptranslate) Página 23 de 49

Descripción y ejemplos de uso de los principales comandos Snmpget Este comando puede ser usado para obtener informacion de un host remoto, dado su nombre, informacion de autenticacion y OID. snmpget [COMMON OPTIONS] [-Cf] OID [OID]... Un ejemplo de su uso sería: % snmpget -c demopublic -v 2c test.net-snmp.org system.sysuptime.0 system.sysuptime.0 = Timeticks: (586731977) 67 days, 21:48:39.77 Donde test.net-snmp.org es el nombre del host al que se quiere acceder, demopublic es el community name, y se desea el valor del OID system.sysuptime.0 Snmpgetnext Se utiliza para obtener el proximo OID en el árbol MIB. La estructura del comando es similar a la del get snmpgetnext [COMMON OPTIONS] [-Cf] OID [OID]... Ejemplo: % snmpgetnext -v 2c -c demopublic test.net-snmp.org system.sysuptime.0 system.syscontact.0 = Wes Hardaker wjhardaker@ucdavis.edu snmpwalk Hace una serie completa de getnexts automáticamente, y termina cuando devuelve un resultado que no está más dentro del rango del OID que se especificó originalmente. Página 24 de 49

snmpwalk [APPLICATION OPTIONS] [COMMON OPTIONS] [OID] Ejemplo: %snmpwalk -Os -c public -v 1 zeus system Devolverá todas las variables bajo System: sysdescr.0 = STRING: "SunOS zeus.net.cmu.edu 4.1.3_U1 1 sun4m" sysobjectid.0 = OID: enterprises.hp.nm.hpsystem.10.1.1 sysuptime.0 = Timeticks: (155274552) 17 days, 23:19:05 syscontact.0 = STRING: "" sysname.0 = STRING: "zeus.net.cmu.edu" syslocation.0 = STRING: "" sysservices.0 = INTEGER: 72 Snmpset Permite modificar información en el host remoto. Para cada variable que se desea setear, se debe especificar el OID, el tipo de dato y el valor al que se lo quiere setear. snmpset [COMMON OPTIONS] OID TYPE VALUE [OID TYPE VALUE]... El campo type, es un caracter que puede tomar uno de los siguientes valores: i:integer u:unsigned s:string x:hex STRING d:decimal STRING n:nullobj o:objid t:timeticks a:ipaddress b:bits Página 25 de 49

Ejemplo: snmpset -c private -v 1 test-hub system.syscontact.0 s dpz@noc.rutgers.edu ip.ipforwarding.0 = 2 Setea las variables syscontact.0 and ipforwarding.0 a: system.syscontact.0 = STRING: "dpz@noc.rutgers.edu" ip.ipforwarding.0 = INTEGER: not-forwarding(2) Snmpbulkget Utiliza el request getbulk de SNMP para solicitar información a una entidad de modo eficiente. Uno o mas OID pueden ser dados como argumentos en la linea de comandos. snmpbulkget [APPLICATION OPTIONS] [COMMON OPTIONS] OID [OID]... Página 26 de 49

Análisis de Capturas PDU GET-REQUEST Y GET-RESPONSE Usando el software NET SNMP, se le pide al router el registro sysuptime, que indica la cantidad de ciclos de reloj que el sistema estuvo operando. Comando C:\Documents and Settings\alumno>snmpget -c public -v 1 -Of 157.92.50.110.sysUpTime.0 Respuesta.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.sysUpTimeInstance = Timeticks: (515520) 1:25:55.20 Resultados esperados La conexión UDP de los get-request se hace en el puerto 161. El tipo de PDU SNMP se especifica en el campo PDU type. También debe poseer un campo de identificación de la consulta (requestid) para relacionar las posibles varias respuestas al pedido que se hizo. Resultados obtenidos Se ve que al enviar una comando get request, el mismo viaja en un PDU SNMP que está montado sobre UDP. El puerto fuente es el 2014, y el destino es el 161. Con respecto a SNMP, la versión utilizada es la 1. El nombre de la comunidad es PUBLIC, y el mismo se transfiere en texto plano, detalle que hace inseguro a esta versión de SNMP, dado que si se quisiera tener acceso al agente SNMP y no se sabe el nombre de la comunidad, no hace falta más que colocar un sniffer y esperar hasta capturar un mensaje y leer el nombre de la comunidad. El tipo de PDU se especifica con un entero, siendo 0 en el caso de GET-REQUEST, y 2 en el caso de GET-RESPONSE. El campo de Request ID se usa para Página 27 de 49

reconocer a qué pregunta va dirigida la respuesta, dado que es el mismo tanto en el GET-REQUEST, como en el GET-RESPONSE. El identificador de objeto indica por qué objeto de la MIB se está haciendo el request. En este caso, como es un escalar que no está dentro de una tabla, hay que terminar el identificador con un.0 (punto cero). En el request, el valor del objeto es NULL, y en el response es el valor de pulsos de reloj que el router estuvo encendido. Página 28 de 49

Detalle de tramas GET REQUEST GET RESPONSE Página 29 de 49

PDU GET REQUEST ERRÓNEO En este caso, se envía un request del mismo objeto que antes (sysuptime), pero se omite la terminación en.0. Comando C:\Documents and Settings\alumno>snmpget -c public -v 1 -Of 157.92.50.110 sysuptime Respuesta Error in packet Reason: (nosuchname) There is no such variable name in this MIB. Failed object:.iso.org.dod.internet.mgmt.mib-2.system.sysuptime Resultados esperados El envío de este request, provocará un error, dado que el router no reconocerá el objeto que se pide, por lo tanto, el router contestará con una trama GET-RESPONSE con un mensaje de error diciendo que no posee ese objeto dentro de sus MIB s. Resultados obtenidos En el PDU GET-REQUEST, el identificador de objeto es el mismo que antes, pero sin el.0 final. Esto provoca que la respuesta del agente sea un PDU con el campo de estado de error conteniendo un entero de valor 2 que quiere decir no such a name, indicando que dicho nombre de identificador de objeto no está dentro de sus definiciones MIB. Página 30 de 49

Detalle de tramas GET-REQUEST ERRÓNEO GET RESPONSE DEL GET REQUEST ERRONEO Página 31 de 49

USO DEL GET-NEXT CON EL COMANDO WALK El programa utilizado nos permite usar el comando SNMP-WALK, que hace uso del comando GETNEXT. Sirve para recorrer todas las MIB s a partir de cierto punto. Comando C:\Documents and Settings\alumno>snmpwalk -c public -v 1 -Of 157.92.50.110 dod Respuesta(extracto): SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork Operating System Software IOS (tm) 1600 Software (C1600-NOSY-M), Version 12.0(4)T, RELEASE SOFTWARE (fc1) Copyright (c) 1986-1999 by cisco Systems, Inc.Compiled Wed 28-Apr-99 17:40 by kpma SNMPv2-MIB::sysObjectID.0= OID: SNMPv2-SMI::enterprises.9.1.113 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (541454) 1:30:14.54 SNMPv2-MIB::sysContact.0 = STRING: SNMPv2-MIB::sysName.0 = STRING: Router Resultados esperados En nuestro caso, ejecutamos el SNMPWALK a partir del objeto.dod en el árbol lexicográfico, con lo cual obtenemos u barrido de todas las MIB s que posea el router. Resultados obtenidos Evidentemente, al hacer un GETNEXT a partir de.dod, el router responde con la primer MIB definida que es SysDescr. El manager lee el identificador de objeto de la respuesta, y lo usa para hacer el GETNEXT siguiente. Esto se repite para cada objeto hasta que se termine de recorrer todo el árbol que incluya el router. Obviamente, para cada par de GETNEXT y GETRESPONSE; se tiene el mismo Request ID. El tipo de PDU del GET-NEXT es un entero de valor 1. Página 32 de 49

Página 33 de 49

Detalle de tramas GET NEXT REQUEST GET RESPONSE GET NEXT REQUEST (SIGUIENTE) Página 34 de 49

Se observa que el ciclo de GetNext finaliza cuando el agente contesta con No Such A Name. Esto significa que no hay más objetos MIB. Esto es lógico ya que se había pedido lo que estaba debajo del DOD. Si se hubiese pedido un Subárbol más pequeño, el Walk hubiera terminado cuando el agente conteste con un Objeto fuera de ese Subárbol. Página 35 de 49

PDU SET Para enviar un PDU del tipo SET, tenemos que actuar sobre un objeto que tenga tipo de acceso de escritura y trabajar dentro de una comunidad que tenga privilegios de escritura. Para esto último creamos una nueva comunidad llamada nerdos y la configuramos con privilegios de escritura. Luego actuamos sobre el objeto ipforwarding. Comando C:\Documents and Settings\alumno>snmpset -c nerdos -v 1 -Of 157.92.50.110 ip.ipforwarding.0 = 2 Respuesta.iso.org.dod.internet.mgmt.mib-2.ip.ipForwarding.0 = INTEGER: notforwarding(2) Resultados esperados Se espera que se envíe una PDU con el nombre de comunidad nerdos, y que en el campo del valor del objeto esté el valor deseado, en lugar del valor NULL como en los request Resultados obtenidos Se ve que en lugar de una PDU SET, hay tres. Esto es debido a que el software NET SNMP posee un timer de espera de 1 segundo por defecto entre reintentos. Es decir, si a un segundo de enviado el SET, el agente no responde, el manager reenvía el SET. Se muestra solamente el detalle de un SET y de un RESPONSE, pero si mostráramos el detalle de los tres, se observaría que el request ID es el mismo para los tres SETS y para los tres RESPONSE. En las PDU s se puede ver el nombre de la comunidad, el identificador de objeto y el valor, tanto en el SET REQUEST como en el RESPONSE Página 36 de 49

Página 37 de 49

Detalle de tramas SET REQUEST GET RESPONSE Página 38 de 49

SET ERRÓNEO (authentication failure) En este caso se envía un SET con un nombre de comunidad erróneo. Comando C:\Documents and Settings\alumno>snmpset -c private -v 1 -Of 157.92.50.110 ip.ipforwarding.0 = 2 Respuesta Timeout: No Response from 157.92.50.110 Resultados esperados Al enviar una PDU con un nombre de comunidad erróneo, el agente se da cuenta de que se está queriendo acceder a su base de datos MIB sin la autenticación adecuada, con lo cual envía un TRAP informando quién quiere acceder a las MIB s., e informando que la autenticación es incorrecta. Previamente hay que configurar al router especificándole quién será la entidad que reciba las notificaciones del tipo TRAP. En nuestro caso, dicha entidad es la misma PC que envía las PDU de SNMP. Resultados obtenidos Antes que nada, se observa que no hay un solo SET, sino varios. Esto es debido al funcionamiento del software que, como fue explicado en la sección anterior, tiene un temporizador para reenviar el comando si no se tiene respuesta en un segundo. A cada SET, le corresponde un TRAP. Esto es debido a la falla de autenticación. El tipo del TRAP es authenticationfailure, y se informa en el campo de valor, la dirección IP de la entidad que está tratando de acceder al agente sin la debida autenticación. Dentro del TRAP también se informa la dirección del agente SNMP que generó el TRAP, que es en este caso el router. Esto sirve para que el receptor del Trap, en caso de que esté configurado como receptor de TRAPS de varias entidades, sepa de cuál de ellas proviene. Página 39 de 49

Página 40 de 49

Detalle de tramas SET REQUEST TRAP generado Página 41 de 49

SET ERRÓNEO (Bad Value) En este caso, se envía un set tratando de modificar un objeto con un valor que no es correcto Comando C:\Documents and Settings\alumno>snmpset -c nerdos -v 1 -Of 157.92.50.110 ip.ipforwarding.0 = 6 Respuesta C:\Documents and Settings\alumno>snmpset -c melissa -v 1 -Of 157.92.50.110 ip.i pforwarding.0 = 2 Error in packet. Reason: (BadValue).iso.org.dod.internet.mgmt.mib-2.ip.ipForwarding.0 = 6 Resultados esperados Al enviar un set con las características mencionadas anteriormente, el agente debería enviar una respuesta informando que hubo un error, y especificándolo notificando que se trata del tipo Bad Value Resultados obtenidos Como dijimos anteriormente se envía un SET-REQUEST y se genera una respuesta indicando el tipo de error Página 42 de 49

Detalle de tramas SET REQUEST ERRÓNEO RESPONSE (BAD VALUE) Página 43 de 49

GET BULK Se usará la instrucción GetBulk para obtener los valores de una tabla con un solo pedido. Comando C:\Documents and Settings\alumno> snmpbulkget v 2c Cn0 Cr12 -Os -c public 157.92.50.110 iftable Resultado(extracto) ifindex.1 = INTEGER: 1 ifindex.2 = INTEGER: 2 ifindex.3 = INTEGER: 2 ifdescr.1 = STRING: Ethernet0 Resultados Esperados: Obtener los primeros 12 valores de la tabla iftable. La tabla consta de tres instancias que son las tres interfaces. Al pedirle con el valor Max Repetitions en 12, hará 12 preguntas sobre las tablas. Es decir, que traerá las primeras cuatro columnas de la tabla para cada una de las tres instancias. De haber usado GetNext, se hubieran hecho 12 preguntas y respuestas separadas para obtener el mismo resultado. Capturas: Página 44 de 49

Página 45 de 49

TRAPS Los TRAPS son mensajes que pueden ser enviados cuando se detecta la ocurrencia de algún suceso. El router fue configurado como para que el host que reciba los mensajes del tipo TRAP sea la misma máquina con la cual hacemos el sniffing. Para generar un TRAP, hacemos uso del comando no shutdown del router, que sirve para dar de alta una interfase. El pasaje de estado inactivo a activo de una interfase genera un TRAP Resultados esperados El router debe enviar un TRAP del tipo linkup. Esto se hace mediante el campo generic-trap, asignándole el valor 3. El TRAP también debe identificar cuál es la interfase que se activó, y eso se hace gracias a que en la lista de variables, indica la interfase con el objeto ifindex. Los TRAPS hacen uso del puerto 162 de UDP. Resultados obtenidos Se ve que la conexión UDP se hace mediante el puerto 162. El mensaje SNMP no solo posee el dato del índice de la interfase que se activa (ifindex), sino que también notifica una descripción (ifdescr) y el tipo de la interfase (iftype). Página 46 de 49

Detalle de tramas Página 47 de 49

Conclusiones Hemos verificado el funcionamiento del protocolo SNMP analizando el comportamiento de la comunicación al utilizar los comandos GET-REQUEST, GET-NEXT-REQUEST, SET, TRAP y GET-BULK-REQUEST. También se analizaron casos fallidos, en los que hubo errores de autenticación y de sintaxis. Gracias a esto pudimos afianzar nuestro conocimiento del protocolo SNMP, del esquema de funcionamiento de la administración de redes basándose en el uso de SNMP y de las MIB. Página 48 de 49