SNMP Servicios El Simple Network Management Protocol (SNMP) es el protocolo estándar de Internet para el seguimiento automatizado y administración remota. Hay varias versiones diferentes de SNMP, con las características de seguridad diferentes. Si una red tiene un despliegue de infraestructura de SNMP en el lugar de la administración, a continuación, todos los routers de esa red debe estar configurado para participar en ella con seguridad. A falta de un desplegado régimen SNMP, SNMP todas las instalaciones en todos los routers deben desactivar siguiendo estos pasos:
Explícitamente unset (borrar) todas las cadenas existentes en la comunidad. Desactivar SNMP cierre del sistema y las características trampa. Deshabilitar el sistema de proceso de SNMP. El siguiente ejemplo muestra cómo deshabilitar SNMP mediante la aplicación de estas recomendaciones. Se inicia con un listado de la configuración actual para encontrar las cadenas de comunidad SNMP, SNMP en cuenta que debe estar habilitado para que las cadenas de comunidad SNMP para aparecer en el listado de configuración. La lista de configuración suele ser muy largo, así que es posible que desee utilizar la salida de IOS de filtrado para mostrar sólo las líneas relacionadas con SNMP (en IOS 12.0 y anteriores, sólo debe hacer una lista toda la configuración e inspeccionar visualmente). Central# show running-config | include snmp Building configuration... snmp-server community public RO snmp-server community admin RW Central# Central# config t Enter configuration commands, one per line. End with CNTL/Z. Central(config)# ! erase old community strings Central(config)# no snmp-server community public RO Central(config)# no snmp-server community admin RW Central(config)# Central(config)# ! disable SNMP trap and system-shutdown features Central(config)# no snmp-server enable traps Central(config)# no snmp-server system-shutdown Central(config)# no snmp-server trap-authCentral(config)# Central(config)# ! disable the SNMP service Central(config)# no snmp-server Central(config)# end
El último comando en el ejemplo, no snmp-server, se cierra todo el proceso de SNMP en el router. Al procesar SNMP se apaga, algunas declaraciones de
configuración SNMP no aparecerá en ninguna lista de la configuración activa, pero todavía puede estar allí! La manera más segura para garantizar que SNMP está realmente disponible para un atacante, y lo seguirá siendo, es hacer una lista lo establecido cadenas de comunidad SNMP y que se especifique unset como se indica más arriba. Para obtener información sobre la configuración y el uso de SNMP de forma segura, consulte la Sección 4.5.3. Servicio SNMP Un router Cisco se puede configurar para actuar como un cliente de SNMP. Cuando el servicio SNMP está habilitado en un router, herramientas de gestión de red se puede utilizar para recopilar información sobre la configuración del router, la tabla de rutas, la carga de tráfico, y mucho más. Versiones de 1 y 2 de SNMP no son considerados seguros debido a la falta de autenticación fuerte. Por lo tanto, SNMP sólo debe utilizarse en redes internas o protegidos. El siguiente ejemplo muestra la configuración de una lista de acceso IP estándar que se aplica a un servidor SNMP. Esta lista de acceso permite que el host con dirección IP 14.2.6.6 para recoger información SNMP del router. La lista niega todas las demás conexiones. East(config)# access-list 75 permit host 14.2.6.6 East(config)# access-list 75 deny any log East(config)# snmp-server community N3T-manag3m3nt ro 75
SNMP Trap registro Routers de Cisco tienen la capacidad de informar ciertos acontecimientos como trampas SNMP. Mientras que sólo un pequeño subconjunto de todos los mensajes de registro se puede informar de esta manera, puede ser útil en una red que ya cuenta con gestión SNMP desplegado. Hay cuatro partes a la creación de captura SNMP de registro. En primer lugar, establecer el nivel de registro de la trampa, en segundo lugar, seleccionar un registro de SNMP de acogida, en tercer lugar, establecer la interfaz de origen SNMP, por último, permitir capturas de SNMP para syslog. El siguiente ejemplo muestra cómo configurar la captura de SNMP registro para un host de recepción 14.2.9.1. Central# config t Enter configuration commands, one per line. End with CNTL/Z. Central(config)# logging trap information Central(config)# snmp-server host 14.2.9.1 traps public Central(config)# snmp-server trap-source loopback0 Central(config)# snmp-server enable traps syslog Central(config)# exit Central#
Muchos de los mensajes de captura enviados por un router Cisco no aparecen como mensajes de error en el formato comercial de herramientas de visualización de SNMP. Puede ser necesario añadir especificaciones de formato de Cisco específica a las herramientas de SNMP. Sin embargo, mensajes de captura sobre los cambios de estado de enlace y otros eventos típicos de hardware de red que sean interpretables por los bancos comerciales herramientas SNMP, y puede ser útil en el seguimiento del estado de la red. SNMP se describe con más detalle en la siguiente sub-sección. Seguridad para el Simple Network Management Protocol (SNMP) El Simple Network Management Protocol (SNMP) es compatible con una conexión entre dos entidades que se comunican entre sí: el administrador y la entidad de gestión, el agente. En el caso de los routers de Cisco, el router es siempre el agente. Una aplicación de software en un PC o estación de trabajo normalmente actúa como el gerente. Una implementación libre y útil de un agente SNMP y director se puede obtener de la página principal de NET-SNMP (http://netsnmp.sourceforge.net/ - NET-SNMP es el sucesor de UCD-SNMP, el agente SNMPv3 utiliza en la creación de esta sección). Un dispositivo del agente SNMP mantiene la información y la hace accesible a los administradores, la información sobre cada dispositivo está organizado en una tienda virtual llamada Management Information Base (MIB). SNMP es el protocolo de transporte utilizado para compartir información y el cambio entre el MIB. El MIB es una estructura jerárquica, un árbol que se usa para almacenar una base de datos virtual de información de gestión de red. Cada pieza de datos, u objeto, en una MIB se hace referencia a un identificador de objeto (OID). Un OID es el único, el nombre de puntos, numérico, donde las ramas de los puntos por separado en un árbol MIB. Al solicitar el valor de un objeto, se puede utilizar el OID o el nombre real de cada rama (separados por puntos). Si el valor de referencia no es una hoja inferior del árbol, los valores para toda la rama se devuelven. Una discusión a fondo de SNMP organización de los datos está fuera del alcance de esta guía, para más información consultar [7]. SNMPse puede utilizarparaconsultarelestado deo establecerlos valoresde loscomponentes dela red.
SNMP también puede ser utilizado por una entidad en la red el envío de alertas que indica problemas. En este momento hay tres versiones de SNMP: SNMPv1, SNMPv2c y SNMPv3. IOS versión 11.3 soporta SNMPv1 y SNMPv2c. Versiones de IOS 12.0 y posteriores admiten las tres versiones de SNMP. En esta sección se dará una breve visión general de la seguridad SNMP y detallará cómo habilitar SNMP de forma más segura. Cisco IOS soporta un gran número de comandos SNMP-relacionados, los que no tienen un impacto directo en la seguridad no están cubiertos.
SNMP Security
Cuando SNMPv1 se desarrolló, que inicialmente estaba destinado a ser una solución a corto plazo para (a distancia) la gestión de redes. Como tal, se desarrolló con rapidez y gran seguridad no era un requisito. Sin embargo, ya que fue el protocolo de gestión de red sólo está disponible en ese momento, llegó a ser ampliamente utilizado. Las propuestas fueron planteadas a integrar la seguridad (así como una mayor funcionalidad) en versiones posteriores del protocolo. Lamentablemente, el conflicto surgió entre los defensores de la propuesta en competencia y ninguna norma de seguridad fue acordado. Por lo tanto la seguridad fuerte ha quedado fuera de SNMPv2c. A finales de 1990, SNMPv3 fue desarrollado específicamente con una gran seguridad en mente. SNMPv1 y SNMPv2c han seguridad débil. SNMPv1 utiliza una cadena de comunidad para limitar el acceso a la MIB. Esta cadena se envía a través de la red en texto sin cifrar. SNMPv2 se basa en el mismo mecanismo para controlar el acceso a la MIB. SNMPv3 define tres niveles de seguridad. Se describen en la tabla de abajo. Tabla 4-4: SNMPv3 Seguridad Security Level
SNMPv3
Authentication
Encryption
noAuth NoPriv
User name sent in the clear
None
auth NoPriv
HMAC-MD5 or HMAC-SHA
None
authPriv
HMAC-MD5 or HMAC-SHA
DES (56-bit)
La documentación de Cisco IOS 12.0 indica que soporta todos los tres niveles de seguridad. Sin embargo, cifrado DES de 56 bits no era compatible con las versiones de IOS utilizadas para la preparación de esta sección (12.0 (7) y 12.0 (5)). SNMP vulnerabilidad A principios de 2002, graves vulnerabilidades de SNMP se dieron a conocer que afectó a los routers de Cisco y muchos otros dispositivos de red. Si su versión de IOS es uno de los más vulnerables (y casi todos los IOS antes de febrero de 2002), entonces usted debería actualizar su IOS (recomendado), SNMP desactivar por completo, o tomar otras medidas de protección. Para obtener más información, consulte el aviso de seguridad de Cisco "mensaje incorrecto SNMP-Manejo de vulnerabilidades" [9]. Configuración de SNMP - Introducción En ambas versiones del IOS 11 y 12, hay algunos comandos básicos que debe ejecutar para habilitar SNMP. A fin de que una cadena de comunidad SNMP por
defecto se debe establecer. Esta cadena se almacena en el router con el texto en claro y se envían a través de la red en el claro. Por lo tanto, cualquiera que conozca la cadena de comunidad tiene acceso a prácticamente todo el MIB. SNMP registro también debe estar habilitado (ver sección 4.5.1). Es una buena idea para ejecutar el show snmp comando para mostrar el estado SNMP y las estadísticas, como se muestra a continuación. East# config t Enter configuration commands, one per line. End w ith CNTL/Z East(config)# snmp-server community publicstring East(config)# snmp-server host 14.2.6.6 traps public East(config)# exit East# show snmp Chassis: east Contact: John Doe Location: Headquarters 0 SNMP packets input 0 Bad SNMP version errors 0 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 0 Number of requested variables 0 Number of altered variables 0 Get-request PDUs 0 Get-next PDUs 0 Set-request PDUs 0 SNMP packets output 0 Too big errors (Maximum packet size 2048) 0 No such name errors 0 Bad values errors 0 General errors 0 Response PDUs 0 Trap PDUs SNMP logging: enabled Logging to 14.2.6.6.162, 0/10, 0 sent, 0 dropped. East#
La ejecución de estas órdenes básicas por sí mismos no es muy seguro. Por desgracia, en Cisco IOS versión 11.3 (que implementa SNMPv1 y SNMPv2c), no hay otra alternativa al habilitar SNMP. Si bien hay alguna mención de las opciones de seguridad mejoradas (por SNMPv2c) en la documentación de Cisco, estos comandos se han deshabilitado. Sin embargo, en la versión 12.0, SNMPv3 ha llevado a cabo y proporciona más funciones de seguridad. El resto de esta sección se centra en SNMPv3.
SNMPv3 Un router Cisco capaz de ejecutar SNMPv3 permite más medidas de seguridad que deben aplicarse. Es una buena idea desactivar la cadena pública de la comunidad. A continuación una lista de control de acceso (ver sección 4.3) debe ser creado para limitar el acceso de la máquina al router (a través de SNMP). Más de una máquina se puede agregar en la lista de acceso. Lo que sigue es un ejemplo que hace esto. East# config t Enter configuration commands, one per line. End w ith CNTL/Z East(config)# no snmp-server community publicstring East(config)# ! create access list to use later East(config)# access-list 20 permit 14.2.6.6 East(config)# exit
Después de estos comandos, SNMP todavía está habilitado, pero nadie tiene acceso a la MIB, porque la cadena de comunidad, que únicamente se define el acceso a la MIB, se desactiva. Un método mejor para permitir el acceso a la MIB es el uso de controles estrictos. El acceso limitado puede ser dada a la MIB por definir grupos, usuarios y puntos de vista MIB. Una vista MIB define una parte de la MIB que un usuario o grupo puede ver / modificar siempre y cuando tengan las credenciales apropiadas. En primer lugar, un grupo deben ser definidos por la especificación de un nombre de grupo, la versión de SNMP y el modelo de seguridad deseado. Un punto de vista específico SNMP MIB, así como el acceso a ese punto de vista también se puede definir. Si este punto de vista MIB no se especifica el valor por defecto es tener acceso a básicamente todo el MIB. El segundo paso es añadir usuarios al grupo. A continuación, una vista MIB debe ser definido para incluir a cualquiera de las ramas específicas MIB o excluir ramas específicas MIB. En el ejemplo siguiente se define un usuario sin privilegios, "jdoe", que es un miembro de la "publicUser" del grupo. Este grupo tiene acceso de lectura a la "sysonly" punto de vista, que es el "sistema" rama de la MIB. Esta rama contiene información útil y es beneficioso para los usuarios que tienen acceso. No hay cadena de comunidad se requiere, sino que la autenticación se basa en el nombre de usuario. Este es un ejemplo de un modelo de seguridad noAuthNoPriv. En el ejemplo siguiente también introduce dos nuevos comandos para verificar que los nuevos grupos y usuarios se han añadido correctamente. East# config t Enter configuration commands, one per line. End w ith CNTL/Z East(config)# snmp-server group publicUser v3 noauth read sysonly East(config)# snmp-server user jdoepublicUser v3 East(config)# snmp-server view sysonly system included East(config)# exit
East# East# show snmp group groupname: publicUser security model:v3 noauth readview :sysonlywriteview: notifyview: row status: active East# East# show snmp user User name: jdoe Engine ID: 00000009020000500F033680 storage-type: nonvolatile active East# East# show snmp view sysonly system - included nonvolatile active East#
El modelo más seguro es implementado authNoPriv. Este modelo de seguridad utiliza MD5 o SHA hash a la cadena de comunidad. Los pasos para apoyar este modelo de seguridad son similares a los pasos en el apoyo al modelo noAuthNoPriv. En primer lugar, un grupo debe ser definido. A continuación, los usuarios deben añadirse al grupo con una cadena de contraseña. Esta cadena puede ser utilizando hash MD5 o SHA. Entonces el punto de vista MIB se define. Una vista MIB se puede definir por más de un incluidos / excluidos declaración para restringir la vista a la correspondiente ramas MIB. En el ejemplo siguiente se define un usuario con privilegios, "root " que utiliza MD5 para la autenticación. Esto significa que cuando el usuario "root" intenta acceder y modificar datos MIB, su "secret" cadena de comunidad se hash y luego enviados a través de la red. Esto hace que sea más difícil de poner en peligro la cadena de comunidad. El usuario "root" es miembro del grupo "administrator". En este ejemplo, los miembros del grupo de administradores han restringido el acceso de lectura y escritura, definido por el punto de vista "adminview", con el MIB. Este punto de vista da acceso a todas las partes del MIB excepto las ramas que muestran la información de enrutamiento. Así que, aunque la cadena de comunidades de alguna manera en peligro, las tablas de enrutamiento no son accesibles de forma remota. Del mismo modo, las tablas de enrutamiento no pueden ser modificados de forma remota. Por supuesto, aunque no está demostrado, es siempre una buena idea usar los comandos show para verificar la nueva configuración. East# config t Enter configuration commands, one per line. End w ith CNTL/Z East(config)# snmp-server group administrator v3 auth read adminview write adminview East(config)# snmp-server user root administrator v3 auth md5 ³secret´ access 20 East(config)# snmp-server view adminview internet included East(config)# snmp-server view adminviewip.ipAddrTableexcl East(config)# snmp-server view adminviewip.ipRouteTableexcl East(config)# exit
Los ejemplos anteriores muestran algunas reglas básicas que deben seguirse para configurar SNMP en un router. Listas de acceso (Access-list), usuarios, grupos y puntos de vista deben ser definidos para controlar el acceso a la MIB. Mientras SNMP es útil porque permite a un administrador para configurar el Router
de forma remota, sino que también proporciona un conducto potencialmente peligroso en una red. Security for Remote Monitoring (RMON)
Esta sub-sección se describen los problemas de RMON y la seguridad relacionados con él. Si no está utilizando RMON, debe ser desactivada. RMON se basa en SNMP, se puede deshabilitar mediante la desactivación de SNMP (ver sección 4.2). De lo contrario, siga las indicaciones a continuación. Listado de RMON (Overview of RMON) La supervisión remota (RMON), es una extensión de SNMP. Proporciona la capacidad de seguimiento y análisis de tráfico - datos desde y hacia dispositivos de red en segmentos de red distribuida. El estándar de RMON fue desarrollado originalmente por la Internet Engineering Task Force (IETF) para proporcionar la supervisión proactiva y el análisis de los datos de tráfico en los segmentos LAN distribuida. La RMON Management Information Base (MIB) se define en el RFC 1757 es un método estándar para el seguimiento de las operaciones básicas de los dispositivos de red en segmentos de LAN, proporcionando interoperabilidad entre las estaciones de administración SNMP y RMON agentes de vigilancia. Analizadores de Protocolo o sondas RMON añadir una mayor capacidad de vigilancia de los agentes RMON por pasiva recoger los paquetes de datos en el segmento de LAN seguimiento. La sonda se comunica la información recogida a una estación de administración de red a través de SNMP. En la estación de gestión de red, un administrador de red utiliza aplicaciones como NetScout Manager Plus, Conexión Optivity, o HP OpenView para procesar y mostrar los resultados de RMON en forma gráfica o un informe. Especificaciones de RMON se definen en la norma básica de RMON, RFC 1757, conocido como RMON1 y en la versión extendida, RFC 2021, conocido como RMON2. RMON1 Se aplica ampliamente en la mayoría de dispositivos de comunicación de datos. Sin embargo, RMON1 recoge las estadísticas de tráfico actuales e históricos hasta el MAC de la capa del modelo OSI. RMON2 proporciona estadísticas de nivel de tráfico de más de granularidad de comportamiento de la red desde la red hasta las capas de aplicación del modelo OSI. Aplicación de RMON en routers Cisco Las versiones del IOS de Cisco instalado en la mayoría de los routers Cisco, a partir de IOS 11.1 en un máximo de IOS 12.0, aplicar una pequeña sub-sección de la Norma agente RMON1. Imágenes IOS pedir con la opción de RMON explícita, básicamente RMON1, recoger y registrar la información en todos los nueve grupos, Estadística, Historia, alarma, Host, HostTopN, Matrix, filtros de paquetes
de captura, y los grupos de eventos. Si el agente instalado en el router no incluye la opción de RMON explícita, el agente de RMON implementa los grupos de alarmas y eventos solamente. Dado que la opción de RMON es un complemento de mejora para el router IOS de Cisco, este documento se refiere únicamente a las características y los problemas de seguridad aplicables a las versiones de IOS más comunes. A fin de que RMON en los routers de Cisco, una cadena de comunidad de lectura sólo es necesario cuando la configuración del agente SNMP estándar. Como medida de seguridad, una de lectura y escritura cadena de comunidad es sumamente desalentador (ver sección 4.2). Algunas sondas de monitoreo de red puede requerir una lectura / escritura cadena de comunidad con el fin de comunicarse con el agente. Además, si la arquitectura de red incluye un despliegue de infraestructura y de la estación de gestión SNMP de la red, a continuación, habilitar SNMP en el router (ver Sección 4.5.2). La estación de gestión de la red registrará información sobre todos los eventos configurados en el router provocó un seguimiento. La base IOS agente RMON apoya a los grupos de alarmas y eventos. La configuración del grupo de alarma depende de un acontecimiento previamente configurado RMON. El grupo de alarma periódicamente muestras estadísticas de las variables y las compara con los umbrales configurados en el agente. Los parámetros de configuración de una alarma identificar una variable SNMP MIB para vigilar, el período de votación, un umbral de aumento con el evento asociado, y un umbral de caída. Si una muestra de datos cruza un umbral definido, el agente de RMON dispara un evento. El evento disparado, registra un mensaje o genera una trampa y lo transmite a la estación de administración de red. La aplicación de la salida y la caída de los umbrales de alarma dependen de la configuración anterior de un evento asociado. La base IOS agente RMON soporta los siguientes comandos:
showrmon alarms Display information on alarms configured showrmon events Display information on events configured rmon event number [log] C onfigure an RMON event [trap community ] [description string ] [owner string ] rmon alarm number MIB-object C onfigure an RMON alarm interval {delta | absolute} rising-threshold value [event-number ] falling-threshold value [event-number ] [owner string ]
Los dos primeros comandos muestran información sobre las instalaciones de RMON configurado. Utilice el comando de eventos de RMON para proporcionar una descripción de un evento y se especifica si se registra un mensaje o una trampa se genera. Utilice el comando de alarma de RMON para designar a la actual variable MIB seguimiento en el router Cisco. Las alarmas RMON
proporcionar una excelente herramienta para el control de la interfaz de red soportados por el ruteador. Sin embargo, existen varias limitaciones en el tipo de variables SNMP RMON es capaz de vigilar. Las alarmas pueden definir cualquier variable SNMP MIB que tiene un tipo de datos elementales, tales como número entero, contador de calibre, timeticks, etc El objeto MIB de seguimiento también debe resolverse en una notación ASN.1. Es aceptable utilizar el identificador de objetos (OID) o el nombre de la variable cualificada que se resuelve en su OID. Un requisito importante que es fácil pasar por alto es el número de instancia de la variable de control. Todos los objetos de seguimiento deben incluir un número de instancia de la variable de control. Variables incluidas en el formato de tabla SNMP tendrá un número de instancia equivalente al número de entrada de la tabla. Todas las demás variables de datos primaria debe tener un número de instancia de "0". Por ejemplo, el siguiente comando define una alarma configurado en un miembro de la mesa de interfaces MIB II, ifTable: Central# config t Enter configuration commands, one per line. End w ith CNTL/Z. Central(config)# rmon alarm 1 ifEntry.13.1 30 delta r ising-threshold 40 1 falling-threshold 0 owner rscg Central(config)# exit Central# show rmon alarms Alarm 1 is active, owned by rscg Monitors ifEntry.13.1 every 30 second(s) Taking delta samples, last value was 3 Rising threshold is 40, assigned to event 1 Falling threshold is 0, assigned to event 0 On startup enable rising or falling alarm Alarm 2 is active, owned b y config . . Central#
La entrada de la interfaz, ifEntry.13.1, identifica ifInDiscards variable, el número de paquetes entrantes descartado. Número de alarma 1 se define un período de muestreo de cada 30 segundos para el número de paquetes descartados de entrada a la interfaz Ethernet almacenado en una entrada de la tabla o la instancia 1. El agente vigila aumentos de cuarenta paquetes descartados o más a partir del último valor de la muestra. Un agente de RMON router puede ser muy útil para controlar el número de suma de comprobación, los errores de entrada y de salida, los paquetes de entrada y salida descartados, protocolos desconocidos o no compatibles, etc RMON puede ser muy intensivo de datos en función del número de variables de control y la duración del período de muestreo. Si la cantidad de tráfico generado por RMON parece ser demasiado alto, a continuación, cambiar el período de muestreo a un tiempo más largo (por ejemplo, 30 segundos y 60 segundos).
