stringtranslate.com

Protocolo Simple de Manejo de Red

El Protocolo simple de administración de red ( SNMP ) es un protocolo estándar de Internet para recopilar y organizar información sobre dispositivos administrados en redes IP y para modificar esa información para cambiar el comportamiento del dispositivo. Los dispositivos que normalmente admiten SNMP incluyen módems de cable, enrutadores, conmutadores, servidores, estaciones de trabajo, impresoras y más. [1]

SNMP se utiliza ampliamente en la gestión de redes para el monitoreo de redes . SNMP expone datos de gestión en forma de variables en los sistemas gestionados organizados en una base de información de gestión (MIB), que describe el estado y la configuración del sistema. Luego, estas variables pueden consultarse de forma remota (y, en algunas circunstancias, manipularse) mediante la gestión de aplicaciones.

Se han desarrollado e implementado tres versiones importantes de SNMP. SNMPv1 es la versión original del protocolo. Las versiones más recientes, SNMPv2c y SNMPv3, presentan mejoras en rendimiento, flexibilidad y seguridad.

SNMP es un componente del conjunto de protocolos de Internet según lo define el Grupo de trabajo de ingeniería de Internet (IETF). Consiste en un conjunto de estándares para la gestión de redes, que incluye un protocolo de capa de aplicación , un esquema de base de datos y un conjunto de objetos de datos . [2]

Descripción general y conceptos básicos.

Principio de comunicación SNMP

En usos típicos de SNMP, una o más computadoras administrativas llamadas administradores tienen la tarea de monitorear o administrar un grupo de hosts o dispositivos en una red informática . Cada sistema administrado ejecuta un componente de software llamado agente que reporta información vía SNMP al administrador.

Una red administrada por SNMP consta de tres componentes clave:

Un dispositivo administrado es un nodo de red que implementa una interfaz SNMP que permite acceso unidireccional (solo lectura) o bidireccional (lectura y escritura) a información específica del nodo. Los dispositivos administrados intercambian información específica del nodo con los NMS. A veces llamados elementos de red, los dispositivos administrados pueden ser cualquier tipo de dispositivo, incluidos, entre otros, enrutadores , servidores de acceso , conmutadores , módems de cable , puentes , concentradores , teléfonos IP , cámaras de video IP , hosts de computadoras e impresoras .

Un agente es un módulo de software de administración de red que reside en un dispositivo administrado. Un agente tiene conocimiento local de la información de gestión y traduce esa información hacia o desde un formulario específico de SNMP.

Una estación de administración de red ejecuta aplicaciones que monitorean y controlan los dispositivos administrados. Los NMS proporcionan la mayor parte de los recursos de procesamiento y memoria necesarios para la gestión de la red. Pueden existir uno o más NMS en cualquier red gestionada.

Base de información de gestión

Los agentes SNMP exponen datos de gestión en los sistemas gestionados como variables. El protocolo también permite tareas de gestión activa, como cambios de configuración, mediante la modificación remota de estas variables. Las variables accesibles vía SNMP están organizadas en jerarquías. El propio SNMP no define qué variables debe ofrecer un sistema gestionado. Más bien, SNMP utiliza un diseño extensible que permite a las aplicaciones definir sus propias jerarquías. Estas jerarquías se describen como una base de información de gestión (MIB). Las MIB describen la estructura de los datos de gestión de un subsistema de dispositivo; utilizan un espacio de nombres jerárquico que contiene identificadores de objetos (OID). Cada OID identifica una variable que se puede leer o configurar mediante SNMP. Las MIB utilizan la notación definida por la Estructura de información de gestión versión 2.0 (SMIv2, RFC  2578), un subconjunto de ASN.1 .

Detalles del protocolo

SNMP opera en la capa de aplicación del conjunto de protocolos de Internet . Todos los mensajes SNMP se transportan mediante el protocolo de datagramas de usuario (UDP). El agente SNMP recibe solicitudes en el puerto UDP 161. El administrador puede enviar solicitudes desde cualquier puerto de origen disponible al puerto 161 del agente. La respuesta del agente se envía de vuelta al puerto de origen del administrador. El administrador recibe notificaciones ( Traps e InformRequests ) en el puerto 162. El agente puede generar notificaciones desde cualquier puerto disponible. Cuando se utiliza con Transport Layer Security o Datagram Transport Layer Security , las solicitudes se reciben en el puerto 10161 y las notificaciones se envían al puerto 10162. [3]

SNMPv1 especifica cinco unidades de datos de protocolo (PDU) centrales. Se agregaron otras dos PDU, GetBulkRequest e InformRequest en SNMPv2 y la PDU de informes en SNMPv3. Todas las PDU SNMP están construidas de la siguiente manera:

Los siete tipos de PDU SNMP identificados por el campo tipo de PDU son los siguientes:

ObtenerSolicitud
Una solicitud de administrador a agente para recuperar el valor de una variable o lista de variables. Las variables deseadas se especifican en enlaces de variables (el campo de valor no se utiliza). La recuperación de los valores de las variables especificadas debe realizarse como una operación atómica por parte del agente. Se devuelve una respuesta con los valores actuales.
Establecer solicitud
Una solicitud de administrador a agente para cambiar el valor de una variable o lista de variables. Los enlaces de variables se especifican en el cuerpo de la solicitud. Los cambios en todas las variables especificadas deben realizarse como una operación atómica por parte del agente. Se devuelve una respuesta con nuevos valores (actuales) para las variables.
ObtenerSiguienteSolicitud
Una solicitud de gerente a agente para descubrir variables disponibles y sus valores. Devuelve una respuesta con enlace de variable para la siguiente variable lexicográfica en la MIB. Se puede recorrer toda la MIB de un agente mediante la aplicación iterativa de GetNextRequest a partir del OID 0. Las filas de una tabla se pueden leer especificando los OID de las columnas en los enlaces de variables de la solicitud.
Obtener solicitud masiva
Una solicitud de administrador a agente para múltiples iteraciones de GetNextRequest . Una versión optimizada de GetNextRequest . Devuelve una respuesta con múltiples enlaces de variables recorridos desde el enlace o enlaces de variables en la solicitud. Los campos de no repetidores y de repeticiones máximas específicos de la PDU se utilizan para controlar el comportamiento de la respuesta. GetBulkRequest se introdujo en SNMPv2.
Respuesta
Devuelve enlaces de variables y reconocimiento del agente al administrador para GetRequest , SetRequest , GetNextRequest , GetBulkRequest e InformRequest . Los informes de errores se proporcionan mediante los campos de estado de error e índice de error . Aunque se usó como respuesta tanto para obtención como para configuración, esta PDU se llamó GetResponse en SNMPv1.
Trampa
Notificación asincrónica del agente al gerente. Mientras que en otras comunicaciones SNMP, el administrador solicita activamente información al agente, estas son PDU que se envían desde el agente al administrador sin ser solicitadas explícitamente. Las capturas SNMP permiten a un agente notificar a la estación de administración sobre eventos importantes mediante un mensaje SNMP no solicitado. Las PDU de captura incluyen el valor actual de sysUpTime , un OID que identifica el tipo de captura y enlaces de variables opcionales. El direccionamiento de destino para las capturas se determina de manera específica de la aplicación, generalmente a través de variables de configuración de capturas en la MIB. El formato del mensaje de captura se cambió en SNMPv2 y la PDU pasó a llamarse SNMPv2-Trap .
InformarSolicitar
Notificación asincrónica reconocida. Esta PDU se introdujo en SNMPv2 y originalmente se definió como comunicación de administrador a administrador . [4] Implementaciones posteriores han aflojado la definición original para permitir las comunicaciones entre el agente y el administrador . [5] [6] [7] Las notificaciones de administrador a administrador ya eran posibles en SNMPv1 usando una trampa , pero como SNMP comúnmente se ejecuta a través de UDP donde la entrega no está asegurada y los paquetes descartados no se informan, la entrega de una trampa no estaba garantizada . InformRequest soluciona este problema ya que se devuelve un acuse de recibo al recibirlo. [6]

RFC  1157 especifica que una implementación SNMP debe aceptar un mensaje de al menos 484 bytes de longitud. En la práctica, las implementaciones SNMP aceptan mensajes más largos. [8] : 1870  Si se implementa correctamente, un mensaje SNMP se descarta si falla la decodificación del mensaje y, por lo tanto, se ignoran las solicitudes SNMP con formato incorrecto. Luego, una solicitud SNMP descodificada correctamente se autentica utilizando la cadena de comunidad. Si la autenticación falla, se genera una trampa que indica un error de autenticación y se descarta el mensaje. [8] : 1871 

SNMPv1 y SNMPv2 utilizan comunidades para establecer confianza entre administradores y agentes. La mayoría de los agentes admiten tres nombres de comunidad, uno para solo lectura, uno para lectura y escritura y otro para captura. Estas tres cadenas comunitarias controlan diferentes tipos de actividades. La comunidad de solo lectura se aplica para obtener solicitudes. La cadena de comunidad de lectura y escritura se aplica a las solicitudes de configuración . La cadena de comunidad de trampas se aplica a la recepción de trampas . SNMPv3 también utiliza cadenas comunitarias, pero permite una autenticación y comunicación seguras entre el administrador SNMP y el agente. [9]

Versiones de protocolo

En la práctica, las implementaciones de SNMP suelen admitir varias versiones: normalmente SNMPv1, SNMPv2c y SNMPv3. [10] [11]

Versión 1

SNMP versión 1 (SNMPv1) es la implementación inicial del protocolo SNMP. El diseño de SNMPv1 fue realizado en la década de 1980 por un grupo de colaboradores que consideraban que el esfuerzo patrocinado oficialmente por OSI/IETF/NSF (National Science Foundation) (HEMS/CMIS/CMIP) era inimplementable en las plataformas informáticas de la época y potencialmente inviable. SNMP se aprobó basándose en la creencia de que era un protocolo provisional necesario para dar pasos hacia el despliegue a gran escala de Internet y su comercialización.

La primera Solicitud de Comentarios (RFC) para SNMP, ahora conocida como SNMPv1, apareció en 1988:

En 1990, estos documentos fueron reemplazados por:

En 1991, el RFC  1156 (MIB-1) fue reemplazado por el más utilizado:

SNMPv1 se utiliza ampliamente y es el protocolo de gestión de red de facto en la comunidad de Internet. [12]

SNMPv1 puede ser transportado por protocolos de capa de transporte como el Protocolo de datagramas de usuario (UDP), el Servicio de red en modo sin conexión OSI (CLNS), el Protocolo de entrega de datagramas AppleTalk (DDP) y el Intercambio de paquetes entre redes de Novell (IPX).

La versión 1 ha sido criticada por su mala seguridad. [13] De hecho, la especificación deja espacio para el uso de autenticación personalizada, pero las implementaciones ampliamente utilizadas "soportan sólo un servicio de autenticación trivial que identifica todos los mensajes SNMP como mensajes SNMP auténticos". [14] La seguridad de los mensajes, por lo tanto, pasa a depender de la seguridad de los canales a través de los cuales se envían los mensajes. Por ejemplo, una organización puede considerar que su red interna es lo suficientemente segura como para que no sea necesario cifrar sus mensajes SNMP. En tales casos, el nombre de la comunidad , que se transmite en texto sin cifrar , tiende a verse como una contraseña de facto, a pesar de la especificación original.

Versión 2

SNMPv2, definido por RFC  1441 y RFC  1452, revisa la versión 1 e incluye mejoras en las áreas de rendimiento, seguridad y comunicaciones de administrador a administrador. Introdujo GetBulkRequest , una alternativa a los GetNextRequests iterativos para recuperar grandes cantidades de datos de gestión en una sola solicitud. El nuevo sistema de seguridad basado en partidos introducido en SNMPv2, considerado por muchos como demasiado complejo, no fue adoptado ampliamente. [13] Esta versión de SNMP alcanzó el nivel de madurez del estándar propuesto, pero versiones posteriores la consideraron obsoleta. [15]

El Protocolo simple de administración de red basado en la comunidad versión 2 , o SNMPv2c , se define en RFC  1901– RFC  1908. SNMPv2c comprende SNMPv2 sin el controvertido nuevo modelo de seguridad SNMP v2, utilizando en su lugar el esquema de seguridad simple basado en la comunidad de SNMPv1. Esta versión es uno de los relativamente pocos estándares que cumple con el nivel de madurez del borrador del estándar del IETF y fue ampliamente considerado el estándar SNMPv2 de facto . [15] Posteriormente se reformuló como parte de SNMPv3. [dieciséis]

El Protocolo simple de administración de redes basado en el usuario versión 2 , o SNMPv2u , se define en RFC  1909– RFC  1910. Se trata de un compromiso que intenta ofrecer mayor seguridad que SNMPv1, pero sin incurrir en la alta complejidad de SNMPv2. Una variante de esto se comercializó como SNMP v2* y el mecanismo finalmente se adoptó como uno de los dos marcos de seguridad en SNMP v3. [17]

contadores de 64 bits

La versión 2 de SNMP introduce la opción para contadores de datos de 64 bits. La versión 1 fue diseñada sólo con contadores de 32 bits que pueden almacenar valores enteros desde cero hasta 4,29 mil millones (precisamente 4,294,967,295). Un contador versión 1 de 32 bits no puede almacenar la velocidad máxima de una interfaz de 10 gigabits o más, expresada en bits por segundo. De manera similar, las estadísticas de seguimiento de un contador de 32 bits para una interfaz de 10 gigabits o más pueden volver a cero en menos de un minuto, lo que puede ser un intervalo de tiempo más corto durante el cual se sondea un contador para leer su estado actual. Esto daría como resultado datos perdidos o no válidos debido a la transferencia de valores no detectados y corrupción de los datos de seguimiento de tendencias.

El contador de la versión 2 de 64 bits puede almacenar valores de cero a 18,4 quintillones (precisamente 18.446.744.073.709.551.615) y, por lo tanto, es poco probable que experimente un vuelco del contador entre eventos de sondeo. Por ejemplo, se prevé que Ethernet de 1,6 terabits esté disponible en 2025. Un contador de 64 bits que se incremente a una velocidad de 1,6 billones de bits por segundo podría retener información para dicha interfaz sin necesidad de renovarse durante 133 días.

Interoperabilidad SNMPv1 y SNMPv2c

SNMPv2c es incompatible con SNMPv1 en dos áreas clave: formatos de mensajes y operaciones de protocolo. Los mensajes SNMPv2c utilizan formatos de encabezado y unidad de datos de protocolo (PDU) diferentes a los de los mensajes SNMPv1. SNMPv2c también utiliza dos operaciones de protocolo que no están especificadas en SNMPv1. Para superar la incompatibilidad, RFC  3584 define dos estrategias de coexistencia SNMPv1/v2c: agentes proxy y sistemas de gestión de red bilingües.

Agentes apoderados

Un agente SNMPv2 puede actuar como agente proxy en nombre de los dispositivos administrados por SNMPv1. Cuando un NMS SNMPv2 emite un comando destinado a un agente SNMPv1, lo envía al agente proxy SNMPv2. El agente proxy reenvía los mensajes Get, GetNexty Setal agente SNMPv1 sin cambios. El agente proxy convierte los mensajes GetBulk en GetNextmensajes y luego los reenvía al agente SNMPv1. Además, el agente proxy recibe y asigna mensajes de captura SNMPv1 a mensajes de captura SNMPv2 y luego los reenvía al NMS.

Sistema de gestión de red bilingüe.

Los sistemas bilingües de administración de redes SNMPv2 admiten tanto SNMPv1 como SNMPv2. Para admitir este entorno de administración dual, una aplicación de administración examina la información almacenada en una base de datos local para determinar si el agente admite SNMPv1 o SNMPv2. Según la información de la base de datos, el NMS se comunica con el agente utilizando la versión adecuada de SNMP.

Versión 3

Aunque SNMPv3 no realiza cambios en el protocolo aparte de agregar seguridad criptográfica, se ve muy diferente debido a las nuevas convenciones textuales, conceptos y terminología. [1] El cambio más visible fue definir una versión segura de SNMP, agregando mejoras de seguridad y configuración remota a SNMP. [18] El aspecto de la seguridad se aborda ofreciendo tanto una autenticación sólida como un cifrado de datos para la privacidad. Para el aspecto administrativo, SNMPv3 se centra en dos partes: los originadores de notificaciones y los reenviadores de proxy. Los cambios también facilitan la configuración y administración remota de las entidades SNMP, además de abordar cuestiones relacionadas con la implementación, la contabilidad y la gestión de fallas a gran escala.

Características y mejoras incluidas:

La seguridad fue una de las mayores debilidades de SNMP hasta la v3. La autenticación en las versiones 1 y 2 de SNMP equivale a nada más que una contraseña (cadena de comunidad) enviada en texto sin cifrar entre un administrador y un agente. [1] Cada mensaje SNMPv3 contiene parámetros de seguridad que están codificados como una cadena de octetos. El significado de estos parámetros de seguridad depende del modelo de seguridad que se utilice. [20] El enfoque de seguridad en los objetivos v3: [21]

v3 también define USM y VACM, que luego fueron seguidos por un modelo de seguridad de transporte (TSM) que brindaba soporte para SNMPv3 sobre SSH y SNMPv3 sobre TLS y DTLS.

A partir de 2004, el IETF reconoce la versión 3 del Protocolo simple de administración de redes según lo definido por RFC  3411- RFC  3418 [22] (también conocido como STD0062) como la versión estándar actual de SNMP. El IETF ha designado a SNMPv3 como un estándar completo de Internet , [23] el nivel de madurez más alto para un RFC. Considera obsoletas las versiones anteriores (designándolas de diversas formas históricas u obsoletas ). [15]

Problemas de implementación

Muchos proveedores no utilizan plenamente las potentes capacidades de escritura de SNMP, que permitirían la configuración de dispositivos de red, en parte debido a la falta de seguridad en las versiones de SNMP anteriores a SNMPv3 y en parte porque muchos dispositivos simplemente no pueden configurarse a través de dispositivos individuales. El objeto MIB cambia.

Algunos valores SNMP (especialmente los valores tabulares) requieren conocimientos específicos de los esquemas de indexación de tablas, y estos valores de índice no son necesariamente consistentes en todas las plataformas. Esto puede causar problemas de correlación al obtener información de múltiples dispositivos que pueden no emplear el mismo esquema de indexación de tablas (por ejemplo, al obtener métricas de utilización del disco, donde un identificador de disco específico es diferente en todas las plataformas) .

Algunos proveedores importantes de equipos tienden a ampliar demasiado sus sistemas de control y configuración centrados en la interfaz de línea de comando (CLI) patentados. [25] [ verificación fallida ]

En febrero de 2002, el Centro de Coordinación del Equipo de Respuesta a Emergencias Informáticas (CERT-CC) del Carnegie Mellon Software Engineering Institute (CM-SEI) emitió un aviso sobre SNMPv1, [26] después de que el Grupo de Programación Segura de la Universidad de Oulu realizara un análisis exhaustivo del manejo de mensajes SNMP. La mayoría de las implementaciones SNMP, independientemente de la versión del protocolo que admitan, utilizan el mismo código de programa para decodificar unidades de datos de protocolo (PDU) y se identificaron problemas en este código. Se encontraron otros problemas con la decodificación de mensajes de captura SNMP recibidos por la estación de administración SNMP o solicitudes recibidas por el agente SNMP en el dispositivo de red. Muchos proveedores tuvieron que publicar parches para sus implementaciones SNMP. [8] : 1875 

Implicaciones de seguridad

Usando SNMP para atacar una red

Debido a que SNMP está diseñado para permitir a los administradores monitorear y configurar dispositivos de red de forma remota, también se puede utilizar para penetrar una red. Un número importante de herramientas de software pueden escanear toda la red utilizando SNMP, por lo que los errores en la configuración del modo lectura-escritura pueden hacer que una red sea susceptible a ataques. [27] : 52 

En 2001, Cisco publicó información que indicaba que, incluso en modo de sólo lectura, la implementación SNMP de Cisco IOS es vulnerable a ciertos ataques de denegación de servicio . Estos problemas de seguridad se pueden solucionar mediante una actualización de IOS. [28]

Si no se utiliza SNMP en una red, se debe desactivar en los dispositivos de red. Al configurar el modo de solo lectura SNMP, se debe prestar mucha atención a la configuración del control de acceso y desde qué direcciones IP se aceptan mensajes SNMP. Si los servidores SNMP se identifican por su IP, SNMP solo podrá responder a estas IP y se negarán los mensajes SNMP de otras direcciones IP. Sin embargo, la suplantación de direcciones IP sigue siendo un problema de seguridad. [27] : 54 

Autenticación

SNMP está disponible en diferentes versiones y cada versión tiene sus propios problemas de seguridad. SNMP v1 envía contraseñas en texto sin formato a través de la red. Por lo tanto, las contraseñas se pueden leer con el rastreo de paquetes . SNMP v2 permite el hash de contraseñas con MD5 , pero esto debe configurarse. Prácticamente todo el software de administración de redes admite SNMP v1, pero no necesariamente SNMP v2 o v3. SNMP v2 se desarrolló específicamente para proporcionar seguridad de datos , es decir, autenticación , privacidad y autorización , pero solo la versión 2c de SNMP obtuvo el respaldo del Grupo de Trabajo de Ingeniería de Internet (IETF), mientras que las versiones 2u y 2* no lograron obtener la aprobación del IETF debido a problemas de seguridad. asuntos. SNMP v3 utiliza MD5, Secure Hash Algorithm (SHA) y algoritmos con clave para ofrecer protección contra modificaciones de datos no autorizadas y ataques de suplantación de identidad . Si se necesita un mayor nivel de seguridad, el Estándar de cifrado de datos (DES) se puede utilizar opcionalmente en el modo de encadenamiento de bloques de cifrado . SNMP v3 se implementa en Cisco IOS desde la versión 12.0(3)T. [27] : 52 

SNMPv3 puede estar sujeto a ataques de fuerza bruta y de diccionario para adivinar las claves de autenticación o claves de cifrado, si estas claves se generan a partir de contraseñas cortas (débiles) o contraseñas que se pueden encontrar en un diccionario. SNMPv3 permite tanto proporcionar claves criptográficas aleatorias distribuidas uniformemente como generar claves criptográficas a partir de una contraseña proporcionada por el usuario. El riesgo de adivinar cadenas de autenticación a partir de valores hash transmitidos a través de la red depende de la función hash criptográfica utilizada y de la longitud del valor hash. SNMPv3 utiliza el protocolo de autenticación HMAC - SHA-2 para el modelo de seguridad basado en usuario (USM). [29] SNMP no utiliza un protocolo de autenticación por desafío mutuo más seguro . SNMPv3 (como otras versiones del protocolo SNMP) es un protocolo sin estado y ha sido diseñado con una cantidad mínima de interacciones entre el agente y el administrador. Por lo tanto, introducir un protocolo de enlace de desafío-respuesta para cada comando impondría una carga al agente (y posiblemente a la red misma) que los diseñadores del protocolo consideraron excesiva e inaceptable. [ cita necesaria ]

Las deficiencias de seguridad de todas las versiones de SNMP pueden mitigarse mediante mecanismos de confidencialidad y autenticación de IPsec . [ cita necesaria ] SNMP también se puede transportar de forma segura a través de Datagram Transport Layer Security (DTLS). [10]

Muchas implementaciones de SNMP incluyen un tipo de descubrimiento automático en el que se descubre y sondea automáticamente un nuevo componente de la red, como un conmutador o enrutador. En SNMPv1 y SNMPv2c esto se hace a través de una cadena comunitaria que se transmite en texto claro a otros dispositivos. [10] Las contraseñas de texto sin cifrar representan un riesgo de seguridad importante. Una vez que la cadena de la comunidad se conoce fuera de la organización, podría convertirse en el objetivo de un ataque. Para alertar a los administradores sobre otros intentos de recopilar cadenas de comunidad, se puede configurar SNMP para pasar trampas de fallas de autenticación de nombres de comunidad. [27] : 54  Si se utiliza SNMPv2, el problema se puede evitar habilitando el cifrado de contraseña en los agentes SNMP de los dispositivos de red.

La configuración predeterminada común para las cadenas de comunidad es "pública" para acceso de solo lectura y "privada" para lectura y escritura. [8] : 1874  Debido a los valores predeterminados bien conocidos, SNMP encabezó la lista de problemas comunes de configuración predeterminada del Instituto SANS y ocupó el décimo lugar entre las 10 amenazas más críticas a la seguridad de Internet de SANS para el año 2000. [30] Sistema y los administradores de red frecuentemente no cambian estas configuraciones. [8] : 1874 

Ya sea que se ejecute sobre TCP o UDP, SNMPv1 y v2 son vulnerables a ataques de suplantación de IP . Con la suplantación de identidad, los atacantes pueden eludir las listas de acceso a dispositivos en agentes implementados para restringir el acceso SNMP. Los mecanismos de seguridad SNMPv3 como USM o TSM pueden evitar ataques de suplantación de identidad.

Referencias RFC

Ver también

Referencias

  1. ^ a b C Douglas R. Mauro y Kevin J. Schmidt. (2001). SNMP esencial (1ª ed.). Sebastopol, CA: O'Reilly & Associates.
  2. ^ Una arquitectura para describir marcos de gestión del protocolo simple de administración de redes (SNMP). doi : 10.17487/RFC3411 . RFC 3411.
  3. ^ RFC  6353 Sección 10
  4. ^ J. Caso; K. McCloghrie; el señor rosa; S. Waldbusser (abril de 1993). "RFC 1448 - Operaciones de protocolo para la versión 2 del Protocolo simple de administración de red (SNMPv2)". Grupo de Trabajo de Ingeniería de Internet. doi :10.17487/RFC1448. Una InformRequest-PDU se genera y transmite a petición de una aplicación en una entidad SNMPv2 que actúa en una función de administrador, que desea notificar a otra aplicación (en una entidad SNMPv2 que también actúa en una función de administrador) de información en la vista MIB de una parte. local para la aplicación de envío. {{cite journal}}: Citar diario requiere |journal=( ayuda )
  5. ^ D. Leví; P. Meyer; B. Stewart (abril de 1999). "RFC 2573 – Aplicaciones SNMP". Grupo de Trabajo de Ingeniería de Internet. doi :10.17487/RFC2573. {{cite journal}}: Citar diario requiere |journal=( ayuda )
  6. ^ ab "Solicitudes de información SNMP". Cisco . Consultado el 9 de diciembre de 2011 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
  7. ^ "Comprensión de la implementación de SNMP en el software JUNOS". Redes de enebro . Consultado el 11 de febrero de 2013 . {{cite journal}}: Citar diario requiere |journal=( ayuda )
  8. ^ abcdeHarold F. Tipton; Micki Krause (2007). Manual de gestión de seguridad de la información, sexta edición . Prensa CRC. ISBN 9780849374951.
  9. ^ Douglas Mauro; Kevin Schmidt (2005). Manual de gestión de seguridad de la información, sexta edición SNMP esencial: ayuda para administradores de sistemas y redes . O'Reilly Media, Inc. págs. 21-22. ISBN 9780596552770.
  10. ^ a b C Stuart Jacobs (2015). Seguridad de la información en ingeniería: la aplicación de conceptos de ingeniería de sistemas para lograr la seguridad de la información . John Wiley e hijos. pag. 367.ISBN 9781119104797.
  11. ^ RFC  3584 "Coexistencia entre la versión 1, la versión 2 y la versión 3 del marco de gestión de red estándar de Internet"
  12. ^ Wiley, John (1 de diciembre de 2015). Seguridad de la información en ingeniería: la aplicación de conceptos de ingeniería de sistemas para lograr la seguridad de la información. John Wiley e hijos. pag. 366.ISBN 9781119104711. Consultado el 14 de septiembre de 2017 .
  13. ^ ab "Seguridad en SNMPv3 frente a SNMPv1 o v2c" (PDF) . Archivado desde el original (PDF) el 29 de abril de 2013.
  14. ^ RFC  1157
  15. ^ abc "Detalle de búsqueda de RFC: seguimiento de estándares RFC de snmpv2". El editor RFC . Consultado el 24 de febrero de 2014 .
  16. ^ RFC  3416
  17. ^ SNMPv3 - Modelo de seguridad del usuario, Dr. Dobbs , consultado el 9 de marzo de 2019
  18. ^ En esta edición: SNMP versión 3 Archivado el 27 de julio de 2017 en Wayback Machine The Simple Times ISSN  1060-6084
  19. ^ RFC 7860
  20. ^ David Zeltserman (1999). Una guía práctica para SNMPv3 y la gestión de redes . Upper Saddle River, Nueva Jersey: Prentice Hall PTR.
  21. ^ "SNMPv3". Sistemas Cisco. Archivado desde el original el 19 de julio de 2011.
  22. ^ "SNMP versión 3". Instituto de Sistemas Operativos y Redes Informáticas . Consultado el 7 de mayo de 2010 .
  23. ^ Editor RFC Archivado el 29 de octubre de 2007 en Wayback Machine Lista de estándares de Internet (STD) actuales
  24. ^ "Comprensión de los valores del índice de la tabla en SNMP".
  25. ^ "Presentaciones de SNMP Research a favor de la gestión basada en estándares sobre CLI patentadas". Investigación SNMP . Consultado el 12 de octubre de 2010 .
  26. ^ Aviso CERT CA-2002-03 Múltiples vulnerabilidades en muchas implementaciones
  27. ^ abcd Andrew G. Mason; Mark J. Newcomb (2001). Soluciones de seguridad de Internet seguras de Cisco . Prensa de Cisco. ISBN 9781587050169.
  28. ^ Andrew G. Mason; Mark J. Newcomb (2001). Soluciones de seguridad de Internet seguras de Cisco . Prensa de Cisco. págs.52. ISBN 9781587050169.
  29. ^ Protocolos de autenticación HMAC-SHA-2 en el modelo de seguridad basado en usuario (USM) para SNMPv3 . RFC 7630 . 
  30. ^ "Instituto SANS - Controles de seguridad críticos de la CEI".

Otras lecturas

enlaces externos