Capítulo 32:
Seguridad y monitoreo de red
Una red segura es tan sólida como su eslabón más débil; la capa
2 puede ser el eslabón más débil. Los ataques comunes a la capa 2 incluyen
reconocimiento de CDP, explotación de Telnet, saturación de tabla de
direcciones MAC, ataques por VLAN y ataques relacionados con DHCP. Los
administradores de redes deben saber cómo mitigar estos ataques y cómo proteger
el acceso administrativo con AAA y cómo proteger el acceso al puerto con
802.1X.
Supervisar una red en funcionamiento puede proporcionar
información a un administrador de red para administrar la red de forma
proactiva e informar estadísticas de uso de la red a otros. La actividad de los
enlaces, las tasas de error y el estado de los enlaces son algunos de los
factores que contribuyen a que un administrador de red determine el estado y el
uso de una red. Recopilar y revisar esta información en el transcurso del
tiempo permite que un administrador de red vea y proyecte el crecimiento, y
puede contribuir a que el administrador detecte y reemplace una parte defectuosa
antes de que falle por completo. SNMP suele usarse para recopilar información
sobre dispositivos.
El tráfico de red debe monitorearse para detectar el tráfico
malicioso. Los administradores de redes usan analizadores de puertos y
dispositivos IPS para contribuir a esta tarea. Sin embargo, la infraestructura
conmutada no permite la replicación de puertos de manera predeterminada. Se
debe implementar Cisco SPAN para habilitar la replicación de puertos. Esto
permite que el switch envíe el tráfico duplicado a los analizadores de puertos
o dispositivos IPS para monitorear el tráfico malicioso o sospechoso.
Este capítulo detalla las amenazas de seguridad por LAN más
comunes y cómo mitigar el riesgo. Además, describe SNMP y cómo usarlo para
monitorear una red, y cómo implementar SPAN local para capturar y monitorear el
tráfico con analizadores de puertos o dispositivos de IPS.
Ataques comunes
de LAN
Las organizaciones suelen implementar soluciones de
seguridad mediante routers, firewalls, sistemas de prevención de intrusiones
(IPS) y dispositivos VPN. Estas soluciones protegen los elementos de las
capas 3 a 7.
Las LAN de
capa 2 suelen considerarse un entorno seguro. Sin embargo, como se muestra
en la figura, si la capa 2 se ve comprometida, todas las capas superiores
también se ven afectadas. En la actualidad, con BYOD y ataques más
sofisticados, las LAN se han vuelto más vulnerables.
Por ejemplo, un
empleado descontento con acceso a la red interna puede capturar marcos de
capa 2. Esto puede dejar obsoletas a todas las medidas de seguridad
implementadas en las capas 3 y superior. El atacante también podría hacer
un desastre en la infraestructura de red de LAN de capa 2 y crear situaciones
de DoS. Por lo tanto, además de proteger las capas 3 a 7, los profesionales de
seguridad de red también deben mitigar amenazas contra la infraestructura de
LAN de capa 2.
El primer paso para
mitigar los ataques a la infraestructura de capa 2 es comprender el
funcionamiento subyacente de la capa 2 y las amenazas de la infraestructura
de capa 2.
Algunos ataques
comunes contra la infraestructura de LAN de Capa 2 son:
·
Ataque de reconocimiento de CDP
·
Ataques de Telnet
·
Ataque de saturación de tablas de
direcciones MAC
·
Ataques de VLAN
·
Ataques de DHCP
Los primeros dos
ataques se centran en tener acceso administrativo al dispositivo de red. Los
ataques restantes se centran en la interrupción de las operaciones de red. Hay
otros ataques más sofisticados. No obstante, el enfoque de esta sección está
puesto en los ataques comunes de capa 2.
Nota: Para obtener más información sobre los ataques de
capa 2, consulte el curso de Seguridad CCNA (CCNA Security).
Ataque de
reconocimiento de CDP
Cisco Discovery Protocol (CDP) es un protocolo de detección de
enlaces de capa 2 patentado. Está habilitado en todos los dispositivos de
Cisco de manera predeterminada. CDP puede detectar automáticamente otros
dispositivos con CDN habilitado y ayudar a configurar automáticamente la
conexión. Los administradores de red también usan CDP para configurar
dispositivos de red y solucionar problemas.
La información de CDP se envía por los puertos con CDP
habilitado en transmisiones periódicas sin encriptar. La información de CDP
incluye la dirección IP del dispositivo, la versión de software de IOS, la
plataforma, las funcionalidades y la VLAN nativa. El dispositivo que recibe el
mensaje de CDP actualiza la base de datos de CDP.
La información de CDP es muy útil para la solución de problemas
de red. Por ejemplo, CDP puede usarse para verificar la conectividad de
capa 1 y 2. Si un administrador no puede hacer ping a una interfaz con
conexión directa, pero aún recibe información de CDP, es probable que el
problema esté en la configuración de capa 3.
Sin embargo, un atacante puede usar la información proporcionada
por CDP para detectar vulnerabilidades en la infraestructura de red.
En la figura, una captura de Wireshark de ejemplo muestra el
contenido de un paquete de CDP. El atacante puede identificar la versión del
software Cisco IOS del dispositivo. Esto permite que el atacante determine si
hay vulnerabilidades de seguridad específicas de esa versión determinada de
IOS.
Las transmisiones de CDP se envían sin encriptación ni
autenticación. Por lo tanto, un atacante puede interferir con la
infraestructura de la red enviando tramas de CDP fabricadas con información
falsa sobre dispositivos a los dispositivos de Cisco con conexión directa.
Para mitigar la explotación de CDP, se debe limitar el uso de
CDP en los dispositivos o puertos. Por ejemplo, se debe deshabilitar CDP en los
puertos de extremo que se conectan a dispositivos no confiables.
Para deshabilitar CDP globalmente en un dispositivo, use el
comando del modo de configuración global no cdp run. Para habilitar CDP
globalmente, use el comando de configuración global cdp run.
Para deshabilitar CDP en un puerto, use el comando de
configuración de interfaz no cdp enable. Para habilitar CDP en un
puerto, use el comando de configuración de interfaz cdp enable.
Nota: El Protocolo de detección de capa de enlace (LLDP) también es
vulnerable a los ataques de reconocimiento. Configure no lldp run para
deshabilitar LLDP a nivel global. Para deshabilitar LLDP en la interfaz,
configure no lldp transmit y no lldp receive.
La figura muestra
un archivo de captura de paquetes de una sesión de CDP con Wireshark. Se
resalta la línea con la versión de software del dispositivo de Cisco. Un cuadro
explicativo que apunta a los datos resaltados dice: “Wireshark capturó la
versión de software de la trama de CDP. Software Cisco IOS, software C2960
(C2960-LANBASEK9-M), versión 12.2(44)SE, SOFTWARE DE LANZAMIENTO (fc1) …”
Ataques de
Telnet
La capacidad de administrar de forma remota una
infraestructura de LAN conmutada es un requisito operativo; por lo tanto, debe
admitirse.
Sin embargo, el
protocolo de Telnet es intrínsecamente inseguro y un atacante puede usarlo para
obtener acceso remoto a un dispositivo de red de Cisco. Hay herramientas que
permiten que un atacante inicie ataques contra las líneas de vty del switch.
Hay dos tipos de
ataques de Telnet:
·
Ataque de
contraseña por fuerza bruta: el atacante puede
usar una lista de contraseñas comunes, palabras del diccionario y variaciones
de palabras para descubrir la contraseña administrativa. Si la contraseña no se
descifra en la primera fase, comienza una segunda fase. El atacante usa
herramientas especializadas de auditoría de contraseñas como las que se muestra
en la figura. El software crea combinaciones secuenciales de caracteres para
adivinar la contraseña. Con el tiempo suficiente y dadas las condiciones
propicias, un ataque de contraseña por fuerza bruta puede descifrar casi cualquier
contraseña.
·
Ataque de DoS por
Telnet: el atacante solicita continuamente
conexiones de Telnet para inhabilitar el servicio de Telnet y evitar que el
administrador tenga acceso remoto al switch. Esto se puede combinar con otros
ataques directos a la red como parte de un esfuerzo coordinado para impedir que
el administrador de red acceda a dispositivos clave durante la infracción.
Hay varias maneras
de mitigar los ataques de Telnet:
·
Use SSH en vez de Telnet para las
conexiones de administración remota.
·
Use contraseñas sólidas y cámbielas
con frecuencia. Una contraseña segura debe tener una combinación de mayúsculas
y minúsculas, y debe incluir números y símbolos (caracteres especiales).
·
Limite el acceso a las líneas de vty
con una lista de control de acceso (ACL) que permita el acceso sólo a los
dispositivos de administrador y deniegue el acceso a todos los demás.
·
Autentique y autorice el acceso
administrativo al dispositivo mediante AAA con los protocolos TACACS+ o RADIUS.
Ataque de
saturación de tablas de direcciones MAC
Uno de los ataques más básicos y más comunes de switch LAN es el
ataque por saturación de direcciones MAC. Este ataque también se conoce como
ataque por sobrecarga de tabla de direcciones MAC o ataque por sobrecarga de la
tabla CAM.
Pensemos qué sucede cuando un switch recibe las tramas
entrantes. La tabla de direcciones MAC del switch tiene las direcciones MAC
asociadas con cada puerto físico y la VLAN asociada con cada puerto. Cuando un
switch de la Capa 2 recibe una trama, el switch busca en la tabla de
direcciones MAC la dirección MAC de destino. Todos los modelos de switches
Catalyst utilizan una tabla de direcciones MAC para la conmutación en la Capa
2. A medida que llegan las tramas a los puertos del switch, se registran las
direcciones MAC de origen en la tabla de direcciones MAC. Si la dirección MAC
tiene una entrada en la tabla, el switch reenvía la trama al puerto
correspondiente. Si la dirección MAC no existe en la tabla de direcciones MAC,
el switch satura todos los puertos con la trama, excepto el puerto en el cual
se la recibió.
Las figuras 1 a 3 muestran esta conducta predeterminada del
switch.
En la figura 1, el host A envía tráfico al host B. El
switch recibe las tramas y agrega la dirección MAC de origen del host A a
la tabla de direcciones MAC. A continuación, el switch busca la dirección MAC
de destino en la tabla de direcciones MAC. Si el switch no encuentra la MAC de
destino en la tabla de direcciones MAC, copia la trama y la envía masivamente
(por saturación) por todos los puertos de switch, a excepción del puerto de
recepción.
En la figura 2, el host B recibe y procesa la trama. A
continuación, envía una respuesta al host A. El switch recibe la trama entrante
del host B. El switch ahí agrega la dirección MAC de origen y la asignación de
puerto del host B a la tabla de direcciones MAC. El switch busca la dirección
MAC de destino en la tabla de direcciones MAC y reenvía las tramas desde el
puerto 1 hasta el host A.
La tabla de direcciones MAC del switch con el tiempo se aprende
todas las direcciones MAC que están conectadas y reenvía las tramas solo entre
puertos de comunicación. En la figura 3, por ejemplo, todas las tramas
enviadas por el host A (o por cualquier otro host) al host B se reenvía por el
puerto 2 del switch. No se transmite desde todos los puertos porque el
switch conoce la ubicación de la dirección MAC de destino.
Un atacante puede aprovecharse de esta conducta predeterminada
del switch para crear un ataque por saturación de direcciones MAC. Las tablas de
direcciones MAC poseen límite de tamaño. Los ataques por saturación de MAC se
aprovechan de esta limitación con direcciones MAC de origen falsas que colman
la tabla de direcciones MAC del switch y saturan el switch.
Las figuras 4 y 5 muestran cómo se genera un ataque por
saturación de tabla de direcciones MAC.
En la figura 4, un atacante usa una herramienta de ataque a
la red y envía continuamente al switch tramas con direcciones MAC de origen y
destino falsas generadas al azar. El switch sigue actualizando la tabla de
direcciones MAC con la información de las tramas falsas.
A la larga, la tabla de direcciones MAC se colma de direcciones
MAC falsas y pasa al modo de apertura ante falla. En este modo, el switch
transmite todas las tramas a todas las máquinas en la red. Como resultado, el
atacante puede capturar todas las tramas, incluso las tramas que no están
dirigidas a su tabla de direcciones MAC.
En la figura 5, el switch está en modo de apertura ante
falla y transmite todas las tramas recibidas por todos los puertos. Por lo
tanto, las tramas enviadas del host A al host B también se transmiten del
puerto 3 del switch y son visibles para el atacante.
Configure la seguridad de puertos del switch para mitigar los
ataques por sobrecarga de la tabla de direcciones MAC.
La figura 1
muestra un switch con tres computadoras conectadas: host A, host B y host C. La
figura muestra el envío de un paquete del host A al host B. Como el switch no
tiene una entrada en la tabla MAC para el host B, el switch saturará la trama.
La figura 2 muestra la respuesta del host B ante la saturación. Mientras
host B envía una respuesta al host A, el switch agrega al host B a la tabla de
direcciones MAC. Al mismo tiempo, e host C descarta el paquete porque no es el
host B. La figura 3 muestra el envío de otro paquete del host A al host B.
Ahora que el switch tiene una entrada de dirección MAC para el host B, el
paquete se envía directamente al host B. La figura 4 muestra el envío
desde el host C de paquetes de datos con direcciones MAC falsas de origen y
destino para tratar de saturar y colapsar el switch. La figura 5 muestra
una tabla de direcciones MAC completa en un switch. Con esto se logra que todos
los paquetes se transmitan al puerto correspondiente. El switch está saturado y
ahora funciona como concentrador.
Ataques de VLAN
La arquitectura VLAN simplifica el mantenimiento de
la red y mejora el rendimiento, pero también posibilita el uso indebido.
Existen diversos ataques relacionados con VLAN.
La figura muestra
un tipo de amenaza de VLAN: el ataque de suplantación de switch. El atacante
intenta acceder a la VLAN configurando un host para que suplante a un switch y
use el protocolo de enlace troncal 802.1Q y la función de protocolo de enlace
troncal dinámico (DTP) patentada por Cisco para establecer un enlace troncal
con el switch que se conecta. Si tiene éxito y el switch establece un enlace
troncal con el host, el atacante podrá acceder a todas las VLAN del switch y
podrá desviar (es decir, enviar y recibir) tráfico en todas las VLAN.
Hay varias maneras
de mitigar los ataques de VLAN:
·
Configure explícitamente los enlaces
de acceso
·
Deshabilite explícitamente los
enlaces troncales automáticos
·
Habilite manualmente los enlaces
troncales
·
Deshabilite los puertos sin usar,
conviértalos en puertos de acceso y asígnelos a una VLAN de agujero negro
·
Cambie la VLAN nativa predeterminada
·
Implemente seguridad de puertos
Ataques de DHCP
DHCP es el protocolo que asigna automáticamente una
dirección IP válida de un pool de DHCP a un host.
Hay dos tipos de
ataques de DHCP que pueden dirigirse a una red conmutada:
·
Ataque de
suplantación de DHCP: un atacante configura un servidor
DHCP falso en la red para que envíe direcciones IP a los clientes. Este tipo de
ataque obliga a los clientes a usar un servidor falso de sistema de nombres de
dominio (DNS) y una computadora que está bajo el control del atacante como
gateway predeterminado.
·
Ataque por
agotamiento de DHCP: un atacante satura el servidor DHCP
con solicitudes de DHCP falsas y, con el tiempo, ocupa todas las direcciones IP
disponibles del grupo de servidores DHCP. Una vez que se emiten estas
direcciones IP, el servidor no puede emitir más direcciones; esta situación
produce un ataque por denegación de servicio (DoS), ya que los nuevos clientes
no pueden obtener acceso a la red.
Nota: Un ataque de DoS es todo ataque que se use para
sobrecargar dispositivos y servicios de red específicos con tráfico ilegítimo,
lo que evita que el tráfico legítimo llegue a dichos recursos.
El agotamiento de
DHCP suele usarse antes de los ataques de suplantación de DHCP para denegar el
servicio al servidor DHCP legítimo. Esto facilita la introducción de un servidor
DHCP falso en la red.
Configure la
detección DHCP y la seguridad de puertos en el switch para mitigar los ataques
de DHCP.
La figura muestra una red de tres
switches, una computadora cliente y un servidor DHCP. Un atacante inserta un
servidor DHCP dudoso en la red para tratar de iniciar un ataque por
suplantación de DHCP.
Protección de
la LAN
Según lo indicado al comienzo de este capítulo, la
seguridad es tan sólida como el eslabón más débil del sistema, y la capa 2
se considera el enlace más débil. Por lo tanto, deben implementarse soluciones
de seguridad de capa 2 para proteger la red.
Muchos protocolos
de administración de red como Telnet, syslog, SNMP, TFTP, y FTP no son seguros.
Hay varias estrategias para proteger la Capa 2 de la red:
·
Usar siempre variantes seguras de
estos protocolos, como SSH, SCP, SSL, SNMPv3 y SFTP.
·
Usar siempre contraseñas sólidas y
cambiarlas a menudo.
·
Habilitar CDP solo en ciertos
puertos.
·
Proteger el acceso de Telnet.
·
Usar una VLAN de administración
dedicada que solo aloje el tráfico de administración.
·
Usar ACL para filtrar el acceso no
deseado.
La figura resalta
cuatro soluciones de seguridad de switches de Cisco para mitigar los ataques de
capa 2.
Este tema cubre
varias soluciones de seguridad de Capa 2:
·
Mitigación de ataques de saturación
de tablas de direcciones MAC mediante seguridad de puertos
·
Mitigación de ataques de VLAN
·
Mitigación de ataques de DHCP
mediante detección de DHCP
·
Protección del acceso administrativo
con AAA
·
Protección de acceso a dispositivos
con autenticación de puertos 802.1X
Nota: La protección de IP de origen (IPSG) y la
inspección dinámica de ARP (DAI) son soluciones de seguridad de switch
avanzadas que se analizan en el curso de Seguridad CCNA (CCNA Security).
Mitigación de
ataques por saturación de tabla de direcciones MAC
El método más simple y eficaz de evitar ataques por saturación
de la tabla de direcciones MAC es habilitar la seguridad de puertos.
La seguridad de puertos permite que un administrador especifique
direcciones MAC estáticas para un puerto, o permite que el switch obtenga
dinámicamente una cantidad limitada de direcciones MAC. Al limitar a uno la
cantidad de direcciones MAC permitidas en un puerto, la seguridad de puertos se
puede usar para controlar la expansión no autorizada de la red, como se muestra
en la figura.
Cuando se asignan direcciones MAC a un puerto seguro, dicho
puerto solo reenvía tramas con direcciones MAC de origen del grupo de
direcciones definidas. Cuando un puerto configurado con seguridad de puertos
recibe una trama, se compara la dirección MAC de origen de la trama con la
lista de direcciones de origen seguras que se configuró manualmente o se
detectó automáticamente en el puerto.
Si se configura un puerto como seguro y se alcanza la cantidad
máxima de direcciones MAC, cualquier intento adicional de conexión de las direcciones
MAC desconocidas genera una violación de seguridad. La figura resume estos
puntos.
Mitigar ataques
de VLAN
La figura muestra la mejor manera de evitar ataques
básicos de VLAN:
·
Deshabilite las negociaciones de DTP
(enlaces troncales automáticos) en los puertos sin enlaces troncales con el
comando de configuración de interfaz switchport mode access.
·
Habilite manualmente el enlace
troncal en un puerto con enlaces troncales con el comando switchport mode
trunk.
·
Deshabilite las negociaciones de DTP
(enlaces troncales automáticos) en los puertos con enlaces troncales con el
comando de configuración de interfaz switchport non-negotiate.
·
Cambie la configuración de la VLAN
nativa a otra opción que no sea VLAN 1. Elija una configuración de VLAN en
desuso con el comando switchport trunk native vlan número-vlan (comando
del modo de configuración de interfaz)
·
Deshabilite los puertos en desuso y
asígnelos a una VLAN en desuso.
Mitigación de
ataques de DHCP
Un ataque de suplantación de DHCP se produce cuando
un servidor DHCP dudoso se conecta a la red y brinda parámetros de
configuración IP falsos a los clientes legítimos. La suplantación de DHCP es
riesgosa porque los clientes pueden arrendar información de IP de direcciones
de servidores DNS maliciosos, gateway predeterminados maliciosos o asignaciones
de IP maliciosas.
Las mejores
prácticas de seguridad recomiendan el uso de la detección DHCP para mitigar los
ataques de suplantación de DHCP.
Si la detección
DHCP está habilitada en una interfaz o VLAN y un switch recibe un paquete DHCP
en un puerto no confiable, el switch compara la información del paquete de
origen con la almacenada en la base de datos vinculante de detección DHCP. El
switch negará los paquetes que contengan la siguiente información:
·
Mensajes no autorizados del servidor
DHCP que provengan de un puerto no confiable.
·
Mensajes del cliente DHCP que no
cumplan con la base de datos de enlaces de detección DHCP o con los límites de
velocidad.
En una red grande,
la creación de la base de datos de enlaces de detección DHCP puede llevar
tiempo una vez que se habilita. Por ejemplo, la detección DHCP podría tardar
dos días en completar la base de datos si el tiempo de arrendamiento DHCP es de
cuatro días.
La detección DHCP
reconoce dos tipos de puertos:
·
Puertos de
confianza de DHCP: Solo se puede confiar en los puertos
conectados a servidores DHCP corriente arriba. Estos puertos deben hacer que
los servidores DHCP legítimos respondan con mensajes de oferta de DHCP y de
acuse de recibo de DHCP. Los puertos confiables se deben identificar
explícitamente en la configuración.
·
Puertos no
confiables: estos puertos se conectan a los
hosts que no deben proporcionar mensajes de servidor DHCP. De manera
predeterminada, todos los puertos de switch no son confiables.
La figura
proporciona una representación visual de la asignación de puertos de detección
DHCP en una red. Observe cómo los puertos confiables siempre conducen al
servidor de DHCP legítimo, mientras que el resto de los puertos (es decir, los
puertos de acceso que se conectan a los terminales) no son confiables de manera
predeterminada.
Nota: Para obtener más información sobre la detección
DHCP, consulte el curso de Seguridad CCNA (CCNA Security).
Protección del
acceso administrativo con AAA
Para evitar que usuarios malintencionados obtengan
acceso a equipos de red y servicios sensibles, los administradores deben
habilitar el control de acceso. El control de acceso limita a las personas o
los dispositivos que pueden utilizar recursos específicos. También limita los
servicios o las opciones que están disponibles después de que se concede el
acceso.
Existen diferentes
métodos para implementar la autenticación en un dispositivo Cisco, y cada
método ofrece varios niveles de seguridad. El marco de trabajo de
autenticación, autorización y auditoría (AAA) se usa para proteger el acceso de
los dispositivos. La autenticación de AAA puede usarse para autenticar a los
usuarios para el acceso administrativo o puede usarse para autenticar a los
usuarios para el acceso remoto a la red.
Cisco ofrece dos
métodos comunes de implementar servicios de AAA:
·
Autenticación de
AAA local: AAA local usa una base de datos
local para la autenticación. Este método se conoce a veces como autenticación
autónoma. Este método almacena los nombres de usuario y las contraseñas a nivel
local en el router de Cisco, y los usuarios se autentican con la base de datos
local. AAA local es ideal para las redes pequeñas.
·
Autenticación de
AAA basada en servidor: la autenticación de AAA basada en
servidor es una solución mucho más escalable. Con el método basado en servidor,
el router accede a un servidor central de AAA. El servidor de AAA tiene los
nombres de usuario y las contraseñas para todos los usuarios y actúa como
sistema de autenticación centralizado para todos los dispositivos de la
infraestructura.
En la figura 1
se muestra cómo funciona la autenticación de AAA local:
·
El cliente establece una conexión con
el router.
·
El router AAA pide al usuario un
nombre de usuario y una contraseña.
·
El router autentica el nombre de
usuario y la contraseña con la base de datos local, y el usuario obtiene acceso
a la red en función de la información de la base de datos local.
En la figura 2
se muestra el funcionamiento de la autenticación de AAA basada en servidor:
·
El cliente establece una conexión con
el router.
·
El router AAA pide al usuario un
nombre de usuario y una contraseña.
·
El router autentica el nombre de
usuario y la contraseña mediante un servidor de AAA remoto.
Como se muestra en
la figura 3, el router habilitado por AAA usa el protocolo de sistema de
control de acceso del controlador de acceso a terminales (TACACS+) o el
protocolo de servicio de autenticación remota para usuarios de entrada
telefónica (RADIUS) para comunicarse con el servidor de AAA. Mientras ambos
protocolos pueden usarse para la comunicación entre un router y los servidores
AAA, TACACS+ se considera el protocolo más seguro. Esto se debe a que se cifran
todos los intercambios de protocolos TACACS+, mientras que RADIUS solo cifra la
contraseña del usuario. RADIUS no cifra nombres de usuario, información de la
cuenta, o cualquier otra información que contenga el mensaje de RADIUS.
Nota: Para obtener más información sobre AAA, consulte
el curso de Seguridad CCNA (CCNA Security).
Protección de
acceso a dispositivos con 802.1X
La autenticación de usuarios de red puede obtenerse
con autenticación basada en servidor de AAA. El protocolo o estándar 802.1X
puede servir para autenticar los dispositivos de red en la red corporativa. Hay
otro protocolo que sirve para proteger las computadoras que se conectan a una
LAN.
El estándar IEEE
802.1X define un control de acceso y un protocolo de autenticación basados en
puertos. IEEE 802.1X evita que las estaciones de trabajo no autorizadas se
conecten a una LAN a través de puertos de switch de acceso público. El servidor
de autenticación autentica cada estación de trabajo que está conectada a un
puerto del switch antes habilitar cualquier servicio ofrecido por el switch o
la LAN.
Con la
autenticación 802.1X basada en puertos, los dispositivos de la red cumplen
roles específicos, como se muestra en la figura:
·
Cliente
(suplicante): suele ser el puerto habilitado para
802.1X en el dispositivo. El dispositivo solicita acceso a los servicios de LAN
y switch y luego responde a las solicitudes del switch. En la figura, el
dispositivo es una PC que ejecuta software de cliente que cumple con 802.1X.
Otro cliente suplicante es un dispositivo inalámbrico que cumple con 802.1X,
como una computadora portátil o una tablet.
·
Switch
(autenticador): controla el acceso físico a la red
según el estado de autenticación del cliente. El switch funciona como actúa
intermediario (proxy) entre el cliente y el servidor de autenticación. Solicita
la identificación de la información del cliente, verifica dicha información al
servidor de autenticación y transmite una respuesta al cliente. El switch
utiliza un agente de software de RADIUS que es responsable de encapsular y
desencapsular las tramas del protocolo de autenticación extensible (EAP) y de
interactuar con el servidor de autenticación. Otro dispositivo que podría
actuar como autenticador es un punto de acceso inalámbrico que actúa como
intermediario entre el cliente inalámbrico y el servidor de autenticación.
·
Servidor de
autenticación: realiza la autenticación concreta
del cliente. El servidor de autenticación valida la identidad del cliente y
notifica al switch o a otro autenticador, como un punto de acceso inalámbrico,
si el cliente tiene autorización para acceder a los servicios de LAN y switch.
Debido a que el switch actúa como el proxy, el servicio de autenticación es
transparente para el cliente. El sistema de seguridad RADIUS con extensiones de
EAP es el único servidor de autenticación admitido.
Nota: Para obtener más información sobre 802.1X,
consulte el curso de Seguridad CCNA (CCNA Security).
Introducción a
SNMP
El protocolo simple de administración de redes
(SNMP) se desarrolló para que los administradores puedan administrar nodos como
servidores, estaciones de trabajo, routers, switches y dispositivos de
seguridad en una red IP. Permite que los administradores de redes monitoreen y
administren el rendimiento de la red, detecten y resuelvan problemas de red y
planifiquen el crecimiento de la red.
SNMP es un
protocolo de capa de aplicación que proporciona un formato de mensaje para la
comunicación entre administradores y agentes. El sistema SNMP consta de tres
elementos:
·
Administrador de SNMP
·
Agentes SNMP (nodo administrado)
·
Base de información de administración
(MIB)
Para configurar
SNMP en un dispositivo de red, primero es necesario definir la relación entre
el administrador y el agente.
El administrador de
SNMP forma parte de un sistema de administración de red (NMS). El administrador
de SNMP ejecuta software de administración SNMP. Como se muestra en la
ilustración, el administrador de SNMP puede recopilar información de un agente
SNMP mediante una acción “get” y puede cambiar la configuración en un agente
mediante la acción “set”. Además, lo agentes de SNMP pueden reenviar
información directamente a un administrador de red mediante notificaciones.
El agente de SNMP y
MIB se alojan en los dispositivos del cliente de SNMP. Los dispositivos de red
que se deben administrar, como los switches, los routers, los servidores, los
firewalls y las estaciones de trabajo, cuentan con un módulo de software de
agente SMNP. Las MIB almacenan datos sobre el dispositivo y estadísticas operativas
y deben estar disponibles para los usuarios remotos autenticados. El agente de
SNMP es responsable de brindar acceso a la MIB local.
SNMP define cómo se
intercambia la información de administración entre las aplicaciones de
administración de red y los agentes de administración. El administrador de SNMP
sondea los agentes y consulta la MIB para los agentes de SNMP en el puerto UDP
161. Los agentes de SNMP envían todas las notificaciones de SNMP al
administrador de SNMP en el puerto UDP 162.
Funcionamiento
de SNMP
Los agentes SNMP que residen en los dispositivos
administrados recopilan y almacenan información sobre los dispositivos y su
funcionamiento. El agente almacena esta información localmente en la MIB. El
administrador de SNMP luego usa el agente SNMP para tener acceso a la
información dentro de la MIB.
Existen dos
solicitudes principales de administrador de SNMP: get y set. NMS usa una
solicitud get para solicitar datos al dispositivo. NMS usa una solicitud
"set" para cambiar las variables de configuración en el dispositivo
de agente. Una solicitud set también puede iniciar acciones dentro de un
dispositivo. Por ejemplo, una solicitud set puede hacer que un router se
reinicie, que envíe o que reciba un archivo de configuración. El administrador
de SNMP utiliza las acciones de las solicitudes get y set para realizar las
operaciones descritas en la tabla de la figura 1.
El agente SNMP
responde a las solicitudes del administrador de SNMP de la siguiente manera:
·
Obtener una
variable de MIB: el agente de SNMP ejecuta esta
función en respuesta a GetRequest-PDU del administrador de red. El agente
obtiene el valor de la variable de MIB solicitada y responde al administrador
de red con dicho valor.
·
Definir una
variable de MIB: el agente de SNMP ejecuta esta
función en respuesta a SetRequest-PDU del administrador de red. El agente de
SNMP cambia el valor de la variable de MIB al valor especificado por el
administrador de red. La respuesta del agente SNMP a una solicitud set incluye
la nueva configuración en el dispositivo.
En la
figura 2, se muestra el uso de una solicitud get de SNMP para determinar
si la interfaz G0/0 está up/up (activa/activa).
raps del agente
SNMP
NMS sondea periódicamente a los agentes SNMP que residen en los
dispositivos administrados para solicitar datos a los dispositivos mediante la
solicitud get. Con este proceso, una aplicación de administración de red puede
recopilar información para controlar cargas de tráfico y verificar las
configuraciones de los dispositivos administrados. La información puede
visualizarse por una GUI en NMS. Se pueden calcular los promedios, los mínimos
o los máximos, representar los datos gráficamente o establecer umbrales para
activar un proceso de notificación cuando se exceden los umbrales. Por ejemplo,
NMS puede controlar el uso de CPU de un router Cisco. El administrador de SNMP
toma una muestra del valor periódicamente y presenta esta información en un
gráfico para que el administrador de redes la use para crear una línea de base,
redactar un informe o ver información en tiempo real.
El sondeo periódico de SNMP tiene desventajas. En primer lugar,
existe un retraso entre el momento en el que ocurre un evento y el momento en
el que NMS lo advierte (mediante el sondeo). En segundo lugar, existe un nivel
de equilibrio entre la frecuencia del sondeo y el uso del ancho de banda.
Para mitigar estas desventajas, es posible que los agentes SNMP
generen y envíen traps para informarle a NMS sobre ciertos eventos de
inmediato. Las traps son mensajes no solicitados que alertan al administrador
de SNMP sobre una condición o un evento en la red. Algunos ejemplos de las
condiciones de trap incluyen, entre otros, la autenticación incorrecta de
usuarios, los reinicios, el estado del enlace (activo o inactivo), el
seguimiento de direcciones MAC, el cierre de una conexión TCP, la pérdida de
conexión a un vecino u otros eventos importantes. Las notificaciones de trap
reducen los recursos de red y de agente al eliminar la necesidad de algunas de
las solicitudes de sondeo de SNMP.
En la figura 1, se muestra el uso de una trap de SNMP para
alertar al administrador de red que la interfaz G0/0 falló. El software de NMS
puede enviar un mensaje de texto al administrador de red, mostrar una ventana
emergente en el software de NMS o mostrar el ícono del router en color rojo en
la GUI de NMS.
El intercambio de todos los mensajes de SNMP se muestra en la
figura 2.
Versiones de
SNMP
Hay varias versiones de SNMP:
·
SNMPv1: el protocolo simple de administración de red, un
estándar de Internet completo, se define en RFC 1157.
·
SNMPv2c: se define en las RFC 1901 a 1908; utiliza el marco
administrativo basado en cadenas de comunidad.
·
SNMPv3: protocolo interoperable basado en estándares
definido originalmente en las RFC 2273 a 2275; proporciona acceso seguro
mediante la autenticación y el cifrado de paquetes a través de la red. Incluye
estas características de seguridad: integridad del mensaje para asegurar que no
se alteró un paquete en tránsito, autenticación para determinar que el mensaje
proviene de un origen válido, y cifrado para evitar que un origen no autorizado
lea el contenido de un mensaje.
Todas las versiones
usan administradores de SNMP, agentes SNMP y MIB. El software IOS de Cisco
admite las tres versiones mencionadas anteriormente. La versión 1 es una
solución antigua y no se suele encontrar en las redes actuales; por lo tanto,
este curso se centra en las versiones 2c y 3.
SNMPv1 y SNMPv2c
usan una forma de seguridad basada en comunidades. Una ACL y una contraseña
definen la comunidad de administradores que pueden acceder a la MIB del agente.
A diferencia de
SNMPv1, SNMPv2c incluye un mecanismo de recuperación masiva e informes de
mensajes de error más detallados para las estaciones de administración. El
mecanismo de recuperación masiva recupera tablas y grandes cantidades de
información, lo que minimiza la cantidad de idas y vueltas requeridas. El
manejo de errores mejorado de SNMPv2c incluye códigos de error ampliados que
distinguen diferentes tipos de condiciones de error. Estas condiciones se
informan mediante un único código de error en SNMPv1. Los códigos de devolución
de error en SNMPv2c incluyen el tipo de error.
Nota: SNMPv1 y SNMPv2c ofrecen características de
seguridad mínima. Específicamente, SNMPv1 y SNMPv2c no pueden autenticar el
origen de un mensaje de administración ni proporcionar cifrado. La descripción
más actualizada de SNMPv3 se encuentra en las RFC 3410 a 3415. Agrega métodos
para garantizar la transmisión segura de datos importantes entre los
dispositivos administrados.
SNMPv3 proporciona
tanto modelos como niveles de seguridad. Un modelo de seguridad es una
estrategia de autenticación configurada para un usuario y el grupo dentro del
que reside el usuario. Un nivel de seguridad es el nivel de seguridad permitido
dentro de un modelo de seguridad. La combinación del nivel de seguridad y el
modelo de seguridad determina qué mecanismo de seguridad se utiliza al manejar
un paquete SNMP. Los modelos de seguridad disponibles son SNMPv1, SNMPv2c y
SNMPv3.
La tabla de la
figura identifica las características de las distintas combinaciones de modelos
y niveles de seguridad.
Un administrador de
red debe configurar el agente SNMP para que use la versión de SNMP que admite
la estación de administración. Debido a que un agente puede comunicarse con
varios administradores de SNMP, es posible configurar el software para admitir
comunicaciones mediante SNMPv1, SNMPv2c o SNMPv3.
Cadenas de
comunidad
Para que SNMP funcione, NMS debe tener acceso a la
MIB. Para asegurar que las solicitudes de acceso sean válidas, debe haber
cierta forma de autenticación.
SNMPv1 y SNMPv2c
usan cadenas de comunidad que controlan el acceso a la MIB. Las cadenas de
comunidad son contraseñas de texto no cifrado. Las cadenas de la comunidad de
SNMP autentican el acceso a los objetos MIB.
Existen dos tipos
de cadenas de comunidad:
·
Solo lectura (ro): proporciona acceso a las variables de MIB, pero no
permite realizar cambios a estas variables, solo leerlas. Debido a que la
seguridad es mínima en la versión 2c, muchas organizaciones usan SNMPv2c en
modo de solo lectura.
·
Lectura y escritura
(rw): proporciona acceso de lectura y
escritura a todos los objetos de la MIB.
Para ver o
establecer variables de MIB, el usuario debe especificar la cadena de comunidad
correspondiente para el acceso de lectura o escritura.
Haga clic en
Reproducir en la figura para ver una animación sobre el funcionamiento de SNMP
con la cadena de comunidad.
Nota: las contraseñas de texto no cifrado no se
consideran un mecanismo de seguridad. Esto se debe a que las contraseñas de
texto no cifrado son sumamente vulnerables a los ataques man-in-the-middle
(intermediario), en los que se ven comprometidas a través de la captura de
paquetes.
La figura es una animación. La
animación muestra a un trabajador en una PC como estación de administración de
SNMP, un servidor web con agente de SNMP y una base de datos central de MIB. El
administrador solicita estadísticas al servidor web y descubre que hay diez mil
usuarios.
ID de objeto de
base de información de administración
La MIB organiza variables de manera jerárquica. Las
variables de MIB permiten que el software de administración controle el
dispositivo de red. Formalmente, la MIB define cada variable como una ID de
objeto (OID). Las OID identifican de forma exclusiva los objetos administrados
en la jerarquía de la MIB. La MIB organiza las OID según estándares RFC en una
jerarquía de OID, que se suele mostrar como un árbol.
El árbol de la MIB
para un dispositivo determinado incluye algunas ramas con variables comunes a
varios dispositivos de red y algunas ramas con variables específicas de ese
dispositivo o proveedor.
Las RFC definen
algunas variables públicas comunes. La mayoría de los dispositivos implementan
estas variables de MIB. Además, los proveedores de equipos de redes, como
Cisco, pueden definir sus propias ramas privadas del árbol para admitir las
nuevas variables específicas de sus dispositivos. En la ilustración 1, se
muestran partes de la estructura de MIB definida por Cisco Systems, Inc.
Observe que la OID se puede describir en palabras o números para buscar una
variable específica en el árbol. Los OID de Cisco se numeran de la siguiente
manera: .iso (1).org (3).dod (6).internet (1).private (4).enterprises (1).cisco
(9). Por lo tanto, el OID es 1.3.6.1.4.1.9.
Dado que la CPU es
uno de los recursos clave, se debe medir de manera continua. Las estadísticas
de CPU deben recopilarse en NMS y se deben representar gráficamente. La
observación del uso de la CPU durante un período extendido permite que el
administrador establezca una línea de base aproximada para el uso de la CPU.
Los valores de umbral se pueden establecer en relación con esta línea de base.
Cuando el uso de la CPU supera este umbral, se envían notificaciones. Una
herramienta de representación gráfica de SNMP puede sondear de forma periódica
a los agentes SNMP, como un router, y representar gráficamente los valores
recopilados. En la figura 2, se muestran ejemplos de 5 minutos de uso
de la CPU por parte de un router durante un período de unas semanas.
Los datos se
recuperan mediante la utilidad snmpget, que se emite en NMS. Con la utilidad de
snmpget, se pueden extraer manualmente datos en tiempo real o hacer que NMS
ejecute un informe para obtener un período de tiempo en el que usar los datos
para obtener el promedio. La utilidad snmpget requiere que se establezca la
versión de SNMP, la comunidad correcta, la dirección IP del dispositivo de red
que se debe consultar y el número de OID. En la figura 3, se demuestra el
uso de la utilidad de freeware snmpget, que permite la recuperación rápida de
información de la MIB.
La figura 3
incluye un comando de utilidad snmpget de muestra con varios parámetros, como:
·
-v2c - versión de SNMP
·
-c comunidad - contraseña de SNMP,
llamada cadena de comunidad
·
10.250.250.14 - Dirección IP del
dispositivo monitoreado
·
1.3.6.1.4.1.9.2.1.58.0 - OID de
variable de MIB
En la última línea,
se muestra la respuesta. El resultado muestra una versión abreviada de la
variable de MIB. A continuación, indica el valor real en la ubicación de la
MIB. En este caso, el promedio cambiante exponencial de 5 minutos del
porcentaje de ocupación de la CPU es del 11%. La utilidad proporciona cierta
información sobre los mecanismos básicos de funcionamiento de SNMP. Sin
embargo, trabajar con nombres de variables de MIB largos como
1.3.6.1.4.1.9.2.1.58.0 puede ser problemático para el usuario promedio.
Generalmente, el personal de operaciones de red utiliza un producto de
administración de red con una GUI fácil de usar, con el nombre completo de la
variable de datos de MIB transparente para el usuario.
El navegador de
SNMP de Cisco del sitio web http://cisco.com permite que un administrador de redes consulte
detalles sobre un OID en particular. En la figura 4, se muestra un ejemplo
asociado a un cambio de configuración en un switch Cisco 2960.
SNMPv3
El protocolo simple de administración de redes
versión 3 (SNMPv3) autentica y cifra los paquetes de toda la red para
proporcionar un acceso seguro a los dispositivos. El agregado de la
autenticación y el cifrado a SNMPv3 brinda una solución a las vulnerabilidades
de las versiones anteriores de SNMP.
SNMPv3 autentica y
encripta los paquetes en la red para proporcionar un acceso seguro a los
dispositivos, como se muestra en la figura. Esto responde a las
vulnerabilidades de versiones anteriores de SNMP.
SNMPv3 proporciona
tres funciones de seguridad:
·
Integridad y
autenticación de mensajes: las transmisiones
del administrador de SNMP (NMS) a los agentes (nodos administrados) pueden
autenticarse para garantizar la identidad del emisor y la integridad y la puntualidad
del mensaje. Esto garantiza que el paquete no se haya manipulado en tránsito y
que sea de una fuente válida.
·
Encriptación: los mensajes de SNMPv3 se pueden encriptar para
garantizar la privacidad. La encriptación cifra los contenidos de un paquete
para evitar que los vea una fuente no autorizada.
·
Control de acceso: limita a los administradores SNMP a ciertas
acciones en partes específicas de los datos. Por ejemplo, se puede evitar que
NMS tenga acceso total al dispositivo de firewall.
Pasos para
configurar SNMP
Un administrador de red puede configurar SNMPv2 para obtener
información de red de los dispositivos de red. Como se muestra en la
ilustración, todos los pasos básicos para configurar SNMP se realizan en el
modo de configuración global.
Paso 1. (Obligatorio) Configure la cadena de comunidad
y el nivel de acceso (solo lectura o de lectura y escritura) con el comandosnmp-server
community cadenaro | rw.
Paso 2. (Opcional) Registre la ubicación del
dispositivo con el comandosnmp-server location texto.
Paso 3. (Opcional) Registre el contacto del sistema
con el comandosnmp-server contact texto.
Paso 4. (Opcional) Restrinja el acceso de SNMP a los
host de NMS (administradores de SNMP) permitidos por una ACL: defina la ACL y
haga referencia a la ACL con el comandosnmp-server community string
número-o -nombre-de ACL. Este comando se puede utilizar para especificar la
cadena de comunidad y para restringir el acceso de SNMP a través de las ACL.
Los pasos 1 y 4 pueden combinarse en un paso, si lo desea; el dispositivo de
red de Cisco combina los dos comandos en uno si se introducen por separado.
Paso 5: (Opcional) Especifique el destinatario de las
operaciones de notificación de SNMP con el comandosnmp-server host id-de-host
[version {1| 2c | 3 [auth | noauth
| priv]}] cadena-de-comunidad . De manera predeterminada, no se
define ningún administrador de notificaciones.
Paso 6: (Opcional) Habilite las notificaciones en un
agente de SNMP con el comandosnmp-server enable traps tipos-de-notificación.
Si no se especifica ningún tipo de notificación de traps en este comando,
entonces se envían todos los tipos de trap. Es necesario el uso reiterado de
este comando si se desea un subconjunto determinado de tipos de trap.
Nota: de manera predeterminada, SNMP no tiene ninguna trap
configurada. Sin este comando, los administradores de SNMP deben realizar
sondeos para obtener toda la información importante.
Verificación de
la configuración de SNMP
Existen varias soluciones de software para ver el resultado de
SNMP. Para nuestros fines, el servidor de syslog Kiwi muestra los mensajes de
SNMP asociados a las traps de SNMP.
La PC1 y el R1 están configurados para demostrar el resultado en
un administrador de SNMP en relación con las traps de SNMP.
Como se muestra en la figura 1, se asignó la dirección IP
192.168.1.3/24 a la PC1. El servidor de syslog Kiwi está instalado en la PC1.
Después de que se configura el R1, cada vez que ocurre un evento
que califique como trap, se envían traps de SNMP al administrador de SNMP. Por
ejemplo, si se activa una interfaz, se envía una trap al servidor. Los cambios
de configuración en el router también activan el envío de traps de SNMP al
administrador de SNMP. Se puede ver una lista de más de 60 tipos de
notificación de traps con el comando snmp-server enable traps ? En la
configuración de R1, no se especifican tipos de notificación "trap"
en el comando snmp-server enable traps tipos-de-notificación ,
por lo que se envían todas las notificaciones.
En la figura 2, hay una casilla de verificación activada en
el menú Configuración para indicar que el administrador de redes quiere
que el software administrador de SNMP detecte las notificación de SNMP en el
puerto UDP 162.
En la figura 3, la fila superior del resultado de trap de
SNMP que se muestra indica que el estado de la interfaz GigabitEthernet0/0
cambió a up (activo). Además, cada vez que se pasa del modo EXEC privilegiado
al modo de configuración global, el administrador de SNMP recibe una trap, como
se muestra en la fila resaltada.
Para verificar la configuración SNMP, utilice cualquier variante
del comando show snmp del modo EXEC privilegiado. El comando más útil es
simplemente el comando show snmp, ya que muestra la información que
suele ser de interés al examinar la configuración SNMP. A menos que haya una
configuración SNMPv3 involucrada, la mayoría de las otras opciones de comandos
solo muestran partes seleccionadas del resultado del comando show snmp.
En la figura 4, se proporciona un ejemplo del resultado de show snmp.
El resultado del comando show snmp no muestra información
relacionada con la cadena de comunidad SNMP o, si corresponde, con la ACL
asociada. La figura 5 muestra la cadena de comunidad de SNMP y la
información de ACL, con el comando show snmp community.
Utilice el verificador de sintaxis de la figura 6 para
configurar y verificar SNMP en el R1.
Prácticas
recomendadas de SNMP
SNMP es muy útil para monitorear y solucionar
problemas, como se muestra en la figura, pero también puede crear
vulnerabilidades de seguridad. Por este motivo, antes de implementar SNMP,
tenga en cuenta las prácticas recomendadas de seguridad.
SNMPv1 y SNMPv2c
dependen de las cadenas de comunidad SNMP en texto no cifrado para autenticar
el acceso a los objetos de la MIB. Estas cadenas de comunidad, al igual que
todas las contraseñas, se deben elegir cuidadosamente para asegurar que no sean
demasiado fáciles de descifrar. Además, las cadenas de comunidad se deben
cambiar a intervalos regulares y de acuerdo con las políticas de seguridad de
la red. Por ejemplo, se deben cambiar las cadenas cuando un administrador de
red cambia de función o deja la empresa. Si SNMP se utiliza solo para
monitorear los dispositivos, use comunidades de solo lectura.
Asegúrese de que
los mensajes de SNMP no se propaguen más allá de las consolas de
administración. Se deben usar ACL para evitar que los mensajes de SNMP se
envíen más allá de los dispositivos requeridos. También deben usarse ACL en los
dispositivos monitoreados para limitar el acceso solo a sistemas de
administración.
Se recomienda
SNMPv3 porque proporciona autenticación y cifrado de seguridad. Existen otros
comandos del modo de configuración global que puede implementar un
administrador de red para aprovechar la autenticación y el cifrado en SNMPv3:
·
El comandosnmp-server group groupname
{v1 | v2c | v3 {auth | noauth | priv}}
crea un nuevo grupo de SNMP en el dispositivo.
·
El comandosnmp-server user username
groupname v3 [encrypted] [auth {md5 | sha}
auth-password] [priv {des | 3des | aes {128
| 192 | 256}} priv-password] sirve para agregar un usuario nuevo
al grupo de SNMP especificado en el comandosnmp-server group groupname.
Pasos de
configuración de SNMPv3
SNMPv3 se puede proteger en cuatro pasos. La figura
muestra la sintaxis. A continuación se describe cada paso:
Paso
1: Configure una ACL estándar que
permita el acceso a administradores de SNMP autorizados.
Paso
2. Configure una vista de SNMP con el
comando de configuración global snmp-server view para indicar qué
identificadores de objetos MIB (OID) podrá leer el administrador de SNMP. Se
requiere la configuración de una visualización para limitar los mensajes SNMP a
acceso de sólo lectura.
Paso 3. Configure las funciones del grupo de SNMP con el
comando de configuración global snmp-server group. Este comando tiene
los siguientes parámetros (consulte la sintaxis en la figura):
·
Configura un nombre para el grupo.
·
Establece la versión de SNMP.
·
Especifica la autenticación y la
encriptación necesarias.
·
Asocia la vista del paso 2 al grupo.
·
Especifica el acceso de lectura o de
lectura y escritura.
·
Filtra el grupo con la ACL
configurada en el paso 1.
Paso
4. Configure las funciones de usuario
del grupo de SNMP con el comando de configuración global snmp-server user.
El comando tiene los siguientes parámetros:
·
Configura un nombre de usuario.
·
Asocia al usuario con el nombre de
grupo configurado en el paso 3.
·
Establece la versión de SNMP.
·
Establece el tipo de autenticación.
Se prefiere el SHA y debe ser admitido por el software de administración de
SNMP.
·
Establece el tipo de encriptación.
·
Configura una contraseña de
encriptación.
Verificación de
la configuración de SNMPv3
En el ejemplo de la figura 1, se configura una ACL estándar
denominada PERMIT-ADMIN. Se configura para permitir solo la red 192.168.1.0/24.
Todos los hosts conectados a esta red tendrán permiso para acceder al agente
SNMP que se ejecuta en R1.
Una vista de SNMP se denomina SNMP-RO y se configura para
incluir todo el árbol ISO de MIB. En una red de producción, el administrador de
red probablemente configuraría esta vista para incluir sólo los OID de MIB que
fueran necesarios para supervisar y administrar la red.
Se configura un grupo SNMP con el nombre ADMIN. El SNMP se
establece en versión 3 con autenticación y cifrado requeridos. El grupo tiene
acceso de solo lectura a la vista (SNMP-RO). El acceso para el grupo está
limitado por PERMIT-ADMIN ACL.
Un usuario SNMP, BOB, se configura como miembro del grupo ADMIN.
El SNMP se establece en la versión 3. La autenticación se establece para usar
SHA, y se configura una contraseña de autenticación. Aunque el R1 admite hasta
el cifrado AES 256, software de administración SNMP solo admite AES 128. Por lo
tanto, el cifrado se establece en AES 128 y se configura una contraseña de
cifrado.
Use el verificador de sintaxis de la figura 2 para
configurar R1 con autenticación de SNMPv3 con una ACL.
Replicación de
puertos
Un analizador de paquetes (también conocido como analizador de
protocolos, detector de paquetes o analizador de tráfico) es una herramienta
valiosa para ayudar a supervisar y a resolver los problemas de una red. Un
analizador de paquetes es el software que captura los paquetes que ingresan y
que salen de una tarjeta de interfaz de red (NIC). Por ejemplo, Wireshark es un
analizador de paquetes que se usa comúnmente para capturar y analizar los
paquetes en una computadora local.
¿Qué sucedería si un administrador de red deseara capturar los
paquetes de muchos otros dispositivos fundamentales y no solo la NIC local? Una
solución consiste en configurar los dispositivos de red para copiar y enviar el
tráfico que va a los puertos de interés a un puerto conectado a un analizador
de paquetes. El administrador luego podría analizar el tráfico de red de
diversas fuentes en la red.
Sin embargo, la operación básica de una red conmutada moderna
inhabilita la capacidad del analizador de paquetes para capturar el tráfico de
otras fuentes. Por ejemplo, un usuario que ejecuta Wireshark puede capturar
sólo el tráfico que entra a su NIC. No puede capturar el tráfico entre otro
host y un servidor. El motivo es porque un switch de capa 2 completa la tabla
de direcciones MAC en base a la dirección MAC de origen y el puerto de ingreso
de la trama de Ethernet. Una vez que se crea la tabla, el switch solamente
reenvía el tráfico destinado a una dirección MAC directamente al puerto
correspondiente. Esto evita que un analizador de paquetes conectado a otro
puerto del switch "escuche" otro tráfico del switch.
La solución a este dilema es habilitar los puertos reflejados.
La función de puertos reflejados permite que un switch copie y envíe tramas de
Ethernet desde puertos específicos al puerto de destino conectado a un
analizador de paquetes. La trama original aún se reenvía de la manera habitual.
La figura muestra un ejemplo de replicación de puertos. Vale
notar que el tráfico entre PC1 y PC2 también se envía a la computadora portátil
con un analizador de paquetes instalado.
Análisis de
tráfico sospechoso
La función Analizador de puertos con switches
(SPAN) de los switches Cisco es un tipo de puertos reflejados que envía copias
de la trama que ingresa a un puerto, desde otro puerto del mismo switch. SPAN
permite que los administradores o los dispositivos recopilen y analicen el
tráfico.
Como se muestra en
la Figura 1, SPAN suele implementarse para enviar tráfico a dispositivos
especializados como:
·
Analizadores de
paquetes: usan software como Wireshark para
capturar y analizar el tráfico para solucionar problemas. Por ejemplo, un
administrador puede capturar el tráfico destinado a un servidor para solucionar
problemas de funcionamiento insatisfactorio de una aplicación de red.
·
Sistemas de
protección contra intrusiones (IPS):
Los IPS se centran en el aspecto de seguridad del tráfico y se implementan para
detectar ataques a la red mientras suceden, al enviar alertas o bloquear los
paquetes maliciosos durante el ataque. Los IPS suelen implementarse como
servicio en un router ISR G2 o con un dispositivo exclusivo.
Mientras que los
analizadores de paquetes suelen usarse para solucionar problemas, el IPS busca
patrones específicos en el tráfico. A medida que el flujo de tráfico pasa por
los IPS, se analiza el tráfico en tiempo real y se toman medidas al detectar
patrones de tráfico malicioso.
Las redes modernas
son entornos conmutados. Por lo tanto, SPAN es fundamental para un
funcionamiento eficaz de IPS. SPAN puede implementarse como SPAN local o SPAN
remoto (RSPAN).
SPAN local
SPAN local implica la replicación del tráfico de un
switch a otro puerto del switch. Se usan varios términos para identificar los
puertos entrantes y salientes. La tabla de la figura 1 describe los
términos de SPAN de uso general. La figura 2 identifica los puertos de
SPAN.
Una sesión SPAN es
la asociación entre los puertos de origen (o VLAN) y un puerto de destino.
El tráfico que
entra o que sale del puerto de origen (o VLAN) es replicado por el switch en el
puerto de destino. SPAN puede admitir varios puertos de origen en la misma
sesión o una VLAN completa como origen del tráfico, una sesión de SPAN no
admite ambas opciones. Los puertos de capa 2 y de capa 3 se pueden configurar
como puertos de origen.
Existen tres cosas
más importantes para tener en cuenta cuando configuramos SPAN:
·
El puerto de destino no puede ser un
puerto de origen, y el puerto de origen no puede ser un puerto de destino.
·
El número de puerto de destino
depende de la plataforma. Algunas plataformas permiten más de un puerto de
destino.
·
El puerto de destino ya no es un
puerto de switch normal. A través de ese puerto solo pasa tráfico supervisado.
Se dice que la
función SPAN es local cuando todos los puertos supervisados se encuentran en el
mismo switch que el puerto de destino. Esta función contrasta con del SPAN
remoto (RSPAN).
SPAN remoto
SPAN remota (RSPAN) permite que los puertos de origen y destino
estén en switches diferentes. RSPAN es útil cuando el analizador de paquetes o
IPS está en un switch diferente al del tráfico que se monitorea.
La tabla de la figura 1 describe los términos de RSPAN.
La figura 2 muestra el reenvío de RSPAN entre dos switches.
Vale notar que RSPAN extiende el alcance de SPAN al habilitar el monitoreo
remoto de varios switches en la red.
El RSPAN utiliza dos sesiones. Una sesión se utiliza como origen
y la otra sesión se usa para copiar o recibir el tráfico de una VLAN. El
tráfico para cada sesión RSPAN es enlaces troncales transportados en una VLAN
RSPAN definido por el usuario que se dedique (para esa sesión RSPAN) en todos
los switches participantes.
Nota: La configuración de RSPAN se detalla en el curso de Seguridad
CCNA (CCNA Security).
Configuración de
SPAN local
La función SPAN de los switches de Cisco envía una copia de cada
trama que ingresa al puerto de origen, sale del puerto de destino y se dirige
al analizador de paquetes o IPS. Se usa un número de sesión para identificar
una sesión de SPAN local.
La figura 1 muestra la sintaxis del comando de
configuración global monitor session. Este comando sirve para asociar un
puerto de origen y un puerto de destino con una sesión de SPAN. Cada sesión usa
un comando de monitor session diferente. Se puede especificar una VLAN
en vez de un puerto físico.
Por ejemplo, en la Figura 2, PCA está conectado a F0/1 y una
computadora con una aplicación analizadora de paquetes está conectada a F0/2.
El objetivo es capturar todo el tráfico enviado o recibido por PCA en el puerto
F0/1 y enviar una copia de esas tramas al analizador de paquetes (o a IPS) en
el puerto F0/2. La sesión de SPAN del switch copiará todo el tráfico enviado y
recibido por el puerto de origen F0/1 al puerto de destino F0/2.
Verificación de
SPAN local
El comando show monitor se usa para verificar la sesión
de SPAN. Este comando muestra el tipo de sesión, los puertos de origen de cada
dirección de tráfico y el puerto de destino.
En el ejemplo que se muestra en la figura 1, el número de
sesión es 1, el puerto de origen para ambas direcciones del tráfico es F0/1 y
el puerto de destino es F0/2. El SPAN de ingreso está deshabilitado en el
puerto de destino, por lo que solo se copia a ese puerto el tráfico que sale del
puerto de destino.
Use el verificador de sintaxis de la figura 2 para
configurar y verificar el SPAN local.
Solución de
problemas con SPAN: Descripción general
SPAN permite que los administradores solucionen problemas de
red. Por ejemplo, una aplicación de red puede tardar demasiado en ejecutar
tareas. Para investigar esto, un administrador de red puede usar SPAN para
duplicar y redirigir el tráfico a un analizador de paquetes como Wireshark. El
administrador luego puede analizar el tráfico de todos los dispositivos para
solucionar problemas de funcionamiento por debajo del nivel óptimo de la
aplicación de red.
Los sistemas antiguos con fallas de NIC también pueden ocasionar
problemas. Si SPAN está habilitado en un switch para enviar tráfico a un
analizador de paquetes, un técnico de red puede detectar y aislar el terminal
que causa el exceso de tráfico, como se muestra en la figura.