Protección de dispositivos de red

La protección del tráfico de red saliente y el escrutinio del tráfico entrante son aspectos críticos de la
seguridad de la red. Asegurar el enrutador de borde, que se conecta a la red exterior, es un primer paso
importante para proteger la red.

El endurecimiento del dispositivo es una tarea crítica a la hora de proteger la red. Implica el uso de la
interfaz de línea de comandos (CLI) de Cisco IOS para implementar métodos probados de asegurar
físicamente el enrutador y proteger el acceso administrativo del enrutador. Algunos de estos métodos
implican proteger el acceso administrativo, incluido el mantenimiento de contraseñas, la configuración de
funciones mejoradas de inicio de sesión virtual y la implementación de Secure Shell (SSH). Dado que no
todo el personal de tecnología de la información debe tener el mismo nivel de acceso a los dispositivos de
infraestructura, la definición de roles administrativos en términos de acceso es otro aspecto importante de
la protección de los dispositivos de infraestructura.

También es importante proteger las funciones de administración y generación de informes de los

dispositivos Cisco IOS. En este capítulo se examinan las prácticas recomendadas para proteger syslog,
usar el Protocolo simple de administración de red (SNMP) y configurar el Protocolo de tiempo de red
(NTP).

Muchos servicios de enrutador están habilitados de forma predeterminada. Algunas de estas funciones

están habilitadas por motivos históricos, pero ya no son necesarias. En este capítulo se analizan algunos
de estos servicios y se examina el modo de bloqueo en un solo paso del comando de seguridad
automática, que se puede utilizar para automatizar las tareas de refuerzo de dispositivos.

La autenticación del protocolo de enrutamiento es una práctica recomendada de seguridad necesaria para
evitar la suplantación del protocolo de enrutamiento. En este capítulo se analiza la configuración de la
autenticación Open Shortest Path First (OSPF) con el cifrado Message Digest 5 (MD5) y Secure Hash
Algorithm (SHA). Los planos de control, gestión y datos se discuten con énfasis en la operación de
Control Plane Policing (CoPP).

Asegurar la infraestructura de red

Asegurar la infraestructura de la red es fundamental para la seguridad general de la red. La infraestructura

de red incluye enrutadores, conmutadores, servidores, puntos finales y otros dispositivos.

Piense en un empleado descontento mirando por encima del hombro de un administrador de red mientras
el administrador está iniciando sesión en un enrutador de borde. Es una forma sorprendentemente fácil
para que un atacante obtenga acceso no autorizado.

Si un atacante obtiene acceso a un enrutador, la seguridad y la administración de toda la red pueden verse
comprometidas. Por ejemplo, el atacante en la Figura 1 ha borrado la configuración de inicio y está
haciendo que el enrutador se recargue en cinco minutos. Cuando el enrutador se reinicia, no tendrá una
configuración de inicio.

Para evitar el acceso no autorizado a todos los dispositivos de la infraestructura, se deben implementar
políticas y controles de seguridad adecuados. Los enrutadores son un objetivo principal de los ataques
porque estos dispositivos actúan como policías de tránsito, que dirigen el tráfico hacia, desde y entre las
redes.
El enrutador de borde que se muestra en la Figura 2 es el último enrutador entre la red interna y una red
que no es de confianza, como Internet. Todo el tráfico de Internet de una organización pasa por un
enrutador de borde, que a menudo funciona como la primera y última línea de defensa de una red. El
enrutador de borde ayuda a asegurar el perímetro de una red protegida e implementa acciones de
seguridad que se basan en las políticas de seguridad de la organización. Por estas razones, es imperativo
proteger los enrutadores de red.

Enfoques de seguridad de Edge Router

La implementación del enrutador de borde varía según el tamaño de la organización y la complejidad del
diseño de red requerido. Las implementaciones de enrutadores pueden incluir un solo enrutador que
proteja toda una red interna o un enrutador que funcione como la primera línea de defensa en un enfoque
de defensa en profundidad.

Enfoque de enrutador único

En la Figura 1, un solo enrutador conecta la red protegida o la red de área local interna (LAN) a
Internet. Todas las políticas de seguridad están configuradas en este dispositivo. Esto se implementa más
comúnmente en implementaciones de sitios más pequeños, como sucursales y oficinas pequeñas, oficinas
en el hogar (SOHO). En redes más pequeñas, los enrutadores de servicios integrados (ISR) pueden
admitir las características de seguridad requeridas sin obstaculizar las capacidades de rendimiento del
enrutador.

Enfoque de defensa en profundidad

Un enfoque de defensa en profundidad es más seguro que el enfoque de un solo enrutador. Utiliza

múltiples capas de seguridad antes de que el tráfico ingrese a la LAN protegida. En la Figura 2, hay tres
capas principales de defensa: el enrutador de borde, el firewall y un enrutador interno que se conecta a la
LAN protegida. El enrutador de borde actúa como la primera línea de defensa y se conoce como
enrutador de detección. Después de realizar el filtrado de tráfico inicial, el enrutador de borde pasa todas
las conexiones destinadas a la LAN interna a la segunda línea de defensa, que es el firewall.

Por lo general, el firewall comienza donde termina el enrutador de borde y realiza un filtrado
adicional. Proporciona control de acceso adicional al rastrear el estado de las conexiones y actúa como un
dispositivo de punto de control. De forma predeterminada, el firewall niega el inicio de conexiones desde
las redes externas (no confiables) a la red interna (confiable). Sin embargo, permite a los usuarios internos
establecer conexiones a las redes que no son de confianza y permite que las respuestas regresen a través
del firewall. También puede realizar la autenticación de usuario (proxy de autenticación) en la que los
usuarios deben estar autenticados para obtener acceso a los recursos de la red.

Los enrutadores no son los únicos dispositivos que se pueden utilizar en un enfoque de defensa en
profundidad. También se pueden implementar otras herramientas de seguridad, como los sistemas de
prevención de intrusiones (IPS), los dispositivos de seguridad web (servidores proxy) y los dispositivos
de seguridad del correo electrónico (filtrado de correo no deseado).

Enfoque DMZ

En la Figura 3 se muestra una variación del enfoque de defensa en profundidad. Este enfoque incluye un
área intermedia, a menudo llamada zona desmilitarizada (DMZ). La DMZ se puede utilizar para
servidores a los que se debe acceder desde Internet o alguna otra red externa. La DMZ se puede
configurar entre dos enrutadores, con un enrutador interno que se conecta a la red protegida y un
enrutador externo que se conecta a la red desprotegida. Alternativamente, la DMZ puede ser simplemente
un puerto adicional de un solo enrutador. El cortafuegos se encuentra entre las redes protegidas y
desprotegidas. El firewall está configurado para permitir las conexiones requeridas, como HTTP, desde
redes externas (no confiables) a los servidores públicos en la DMZ. El firewall sirve como protección
principal para todos los dispositivos en la DMZ.

Tres áreas de seguridad del enrutador

Asegurar el enrutador de borde es un primer paso fundamental para proteger la red. Si hay otros
enrutadores internos, también deben configurarse de forma segura. Se deben mantener tres áreas de
seguridad del enrutador, como se muestra en la figura.

Seguridad física

Proporcione seguridad física a los enrutadores:

 Coloque el enrutador y los dispositivos físicos que se conectan a él en una habitación segura y
cerrada que sea accesible solo para el personal autorizado, que no tenga interferencias electrostáticas
o magnéticas, que tenga supresión de incendios y controles de temperatura y humedad.

 Instale una fuente de alimentación ininterrumpida (UPS) o un generador de energía de respaldo

diesel, y mantenga los componentes de repuesto disponibles. Esto reduce la posibilidad de una
interrupción de la red debido a una pérdida de energía.

Seguridad del sistema operativo

Hay algunos procedimientos involucrados en asegurar las características y el rendimiento de los sistemas
operativos del enrutador:

 Configure el enrutador con la máxima cantidad de memoria posible. La disponibilidad de

memoria puede ayudar a mitigar los riesgos para la red de algunos ataques de denegación de
servicio (DoS) al mismo tiempo que admite la más amplia gama de servicios de seguridad.

 Utilice la última versión estable del sistema operativo que cumpla con las especificaciones de
funciones del enrutador o dispositivo de red. Las funciones de seguridad y cifrado de un sistema
operativo se mejoran y actualizan con el tiempo, lo que hace que sea fundamental tener la versión
más actualizada.

 Mantenga una copia segura de las imágenes del sistema operativo del enrutador y los archivos de
configuración del enrutador como copias de seguridad.

Endurecimiento del enrutador

Elimine el abuso potencial de puertos y servicios no utilizados:

 Control administrativo seguro. Asegúrese de que solo el personal autorizado tenga acceso y de

que su nivel de acceso esté controlado.
  Desactive los puertos e interfaces no utilizados. Reducir la cantidad de formas en que se puede
acceder a un dispositivo.

 Deshabilite los servicios innecesarios. Al igual que en muchas computadoras, un enrutador tiene
servicios que están habilitados de forma predeterminada. Algunos de estos servicios son
innecesarios y un atacante puede utilizarlos para recopilar información sobre el enrutador y la red,
que luego se aprovecha en un ataque de explotación.

Acceso administrativo seguro

Asegurar el acceso administrativo es una tarea de seguridad extremadamente importante. Si una persona
no autorizada obtiene acceso administrativo a un enrutador, esa persona podría alterar los parámetros de
enrutamiento, deshabilitar las funciones de enrutamiento o descubrir y obtener acceso a otros sistemas
dentro de la red.

Varias tareas importantes están involucradas en asegurar el acceso administrativo a un dispositivo de

infraestructura, como se describe en la figura:

 Restringir la accesibilidad del dispositivo : limite los puertos accesibles, restrinja los
comunicadores permitidos y restrinja los métodos de acceso permitidos.

 Registre y cuente todos los accesos : registre a cualquier persona que acceda a un dispositivo, lo
que sucedió durante el acceso y cuándo ocurrió el acceso con fines de auditoría.

 Autenticar el acceso : asegúrese de que el acceso se otorgue solo a usuarios, grupos y servicios
autenticados. Limite el número de intentos fallidos de inicio de sesión y el tiempo permitido entre
inicios de sesión.

 Autorizar acciones : restrinja las acciones y vistas permitidas por cualquier usuario, grupo o
servicio en particular.

 Presentar notificación legal : muestre un aviso legal, desarrollado en conjunto con el asesor
legal de la empresa, para sesiones interactivas.

 Garantice la confidencialidad de los datos : proteja los datos confidenciales y almacenados

localmente para que no se puedan ver y copiar. Considere la vulnerabilidad de los datos en tránsito a
través de un canal de comunicación a los ataques de rastreo, secuestro de sesiones y de intermediario
(MITM).

Acceso seguro local y remoto

Se puede acceder a un enrutador con fines administrativos de forma local o remota:

 Acceso local : se puede acceder localmente a todos los dispositivos de infraestructura de red. El
acceso local a un enrutador generalmente requiere una conexión directa a un puerto de consola en el
enrutador Cisco y el uso de una computadora que ejecute software de emulación de terminal, como
se muestra en la Figura 1. El administrador debe tener acceso físico al enrutador y usar un cable de
 consola para conectarse al puerto de la consola. El acceso local se utiliza normalmente para la
configuración inicial del dispositivo.

 Acceso remoto : los administradores también pueden acceder a los dispositivos de infraestructura
de forma remota, como se muestra en las Figuras 2 y 3. Aunque la opción de puerto auxiliar está
disponible, el método de acceso remoto más común implica permitir conexiones Telnet, SSH,
HTTP, HTTPS o SNMP al enrutador desde un ordenador. La computadora puede estar en la red
local o en una red remota.

Algunos protocolos de acceso remoto envían los datos, incluidos los nombres de usuario y las
contraseñas, al enrutador en texto sin formato. Si un atacante puede recopilar tráfico de red mientras un
administrador está iniciando sesión de forma remota en un enrutador, el atacante puede capturar
contraseñas o información de configuración del enrutador. Por esta razón, es preferible permitir solo el
acceso local al enrutador. Sin embargo, en algunas situaciones, es posible que aún sea necesario el acceso
remoto. Se deben tomar precauciones al acceder a la red de forma remota:

 Cifre todo el tráfico entre la computadora del administrador y el enrutador. Por ejemplo, en lugar
de utilizar Telnet, utilice SSH versión 2; o en lugar de usar HTTP, use HTTPS.

 Establezca una red de administración dedicada, como se muestra en la Figura 4. La red de

administración debe incluir solo hosts de administración identificados y conexiones a una interfaz
dedicada en el enrutador.

 Configure un filtro de paquetes para permitir que solo los hosts de administración identificados y
los protocolos preferidos accedan al enrutador. Por ejemplo, permita solo solicitudes SSH de la
dirección IP de un host de administración para iniciar una conexión a los enrutadores en la red.

 Configure y establezca una conexión VPN a la red local antes de conectarse a una interfaz de
administración de enrutador.

Estas precauciones son valiosas, pero no protegen la red por completo. También deben implementarse
otros métodos de defensa. Uno de los métodos más básicos e importantes es el uso de una contraseña
segura.

Contraseñas seguras

Los atacantes implementan varios métodos para descubrir contraseñas administrativas. Pueden mirar por
encima del hombro de un usuario, intentar adivinar las contraseñas basándose en la información personal
del usuario u oler paquetes que contienen archivos de configuración de texto sin formato. Los atacantes
también pueden usar un descifrador de contraseñas, como L0phtCrack (Figura 1) o Cain & Abel para
descubrir contraseñas.

Los administradores deben asegurarse de que se utilicen contraseñas seguras en toda la red. Siga las
pautas de contraseñas seguras para proteger activos, como enrutadores y conmutadores. Las pautas de
contraseñas seguras se muestran en la Figura 2. En contraste, las Figuras 3 y 4 muestran ejemplos de
contraseñas débiles y contraseñas seguras.

En los enrutadores Cisco y muchos otros sistemas, los espacios que encabezan las contraseñas se ignoran,
pero los espacios después del primer carácter no se ignoran. Un método para crear una contraseña segura
es utilizar un espacio en blanco en la contraseña o crear una frase formada por muchas palabras. Esto se
llama frase de contraseña. A menudo, una frase de contraseña es más fácil de recordar que una contraseña
compleja. Una frase de contraseña es más larga y más difícil de adivinar que una contraseña.

Aumento de la seguridad de acceso

Hay varios comandos de configuración del enrutador que se pueden usar para aumentar la seguridad de la
contraseña, como se muestra en la Figura 1:

 De forma predeterminada, la longitud mínima de la contraseña es de seis caracteres. Para

aumentar la longitud mínima, utilice el comando del modo de configuración global de las
contraseñas de seguridad min-length length .

 De forma predeterminada, con la excepción de la contraseña generada por el comando enable

secret , todas las contraseñas de los routers de Cisco se almacenan en texto sin formato en los
archivos de configuración de inicio y ejecución del router. Para cifrar todas las contraseñas de texto
sin formato, utilice el comando de cifrado de contraseña del servicio en el modo de configuración
global. Como se muestra en la Figura 2, el cifrado se puede revertir fácilmente con la herramienta
adecuada. Por esa razón, este comando no debe usarse con la intención de proteger los archivos de
configuración de ataques graves.

 De forma predeterminada, una interfaz administrativa permanece activa e iniciada durante 10

minutos después de la última actividad de la sesión. Para deshabilitar las conexiones desatendidas,
use el comando exec-timeout minutes [ segundos ] en el modo de configuración de línea para cada
una de las líneas que están configuradas para el acceso.

También puede deshabilitar el proceso EXEC para una línea específica, como en el puerto auxiliar,
usando el comando no exec en el modo de configuración de línea. Este comando permite solo una
conexión saliente en la línea, deshabilitando el proceso EXEC para las conexiones que pueden intentar
enviar datos no solicitados al enrutador.

Algoritmos de contraseña secreta

Los hash MD5 ya no se consideran seguros porque los atacantes pueden reconstruir certificados
válidos. Esto puede permitir que los atacantes falsifiquen cualquier sitio web. La contraseña secreta de
habilitación, que se muestra en la Figura 1, usa un hash MD5 de forma predeterminada. Por lo tanto,
ahora se recomienda que configure todas las contraseñas secretas utilizando contraseñas tipo 8 o tipo 9. El
tipo 8 y el tipo 9 se introdujeron en Cisco IOS 15.3 (3) M. Los tipos 8 y 9 utilizan cifrado SHA. Debido a
que el tipo 9 es un poco más fuerte que el tipo 8, se utilizará a lo largo de este curso siempre que lo
permita el IOS de Cisco.

La Figura 2 muestra que configurar el cifrado de tipo 9 no es tan fácil como parece. No puede
simplemente ingresar enable secret 9 y la contraseña sin cifrar. Para utilizar esta forma del comando, debe
pegar la contraseña cifrada, que se puede copiar desde otra configuración de enrutador. Para ingresar una
contraseña no encriptada, use la sintaxis de comando enable algorítm-type que se muestra en la Figura
3. En la Figura 4 se muestra un ejemplo de configuración. Observe que la configuración en ejecución
ahora muestra una contraseña secreta enable tipo 9.
El cifrado de tipo 8 y tipo 9 también se introdujo en Cisco IOS 15.3 (3) M para el comando secreto de
nombre de usuario . Similar al comando enable secret, si simplemente ingresa un usuario con el
comando username secret, el cifrado predeterminado será MD5. Utilice el comando de tipo de algoritmo
de nombre de usuario para especificar el cifrado de tipo 9. La sintaxis se muestra en la Figura 5 junto
con un ejemplo.

Por razones de compatibilidad con versiones anteriores, los comandos enable password , username

password y line password están disponibles en Cisco IOS. Estos comandos no utilizan cifrado de forma
predeterminada. En el mejor de los casos, solo pueden usar cifrado de tipo 7, como se muestra en la
Figura 6. Por lo tanto, estos comandos no se usarán en este curso.

Asegurar el acceso a la línea

De forma predeterminada, la consola y los puertos auxiliares no requieren una contraseña para el acceso
administrativo. Además, el comando de contraseña configurado en la consola, vty y las líneas auxiliares
solo puede usar el tipo 7. Por lo tanto, debe configurar la consola y las líneas auxiliares para la
autenticación de nombre de usuario / contraseña con el comando de inicio de sesión local . Además, las
líneas vty solo deben configurarse para acceso SSH, como se muestra en la Figura 1.

Utilice el Comprobador de sintaxis de la Figura 2 para proteger el acceso administrativo a R2.

Nota : algunos dispositivos Cisco tienen más de cinco líneas vty. Verifique el número de líneas vty en la
configuración en ejecución antes de configurar la contraseña. Por ejemplo, los switches Cisco admiten
hasta 16 líneas vty simultáneas, numeradas del 0 al 15.

Mejora del proceso de inicio de sesión

La asignación de contraseñas y autenticación local no evita que un dispositivo sea blanco de un

ataque. Las mejoras de inicio de sesión de Cisco IOS que se muestran en la Figura 1 brindan más
seguridad al ralentizar los ataques, como los ataques de diccionario y los ataques DoS. Habilitar un perfil
de detección le permite configurar un dispositivo de red para reaccionar ante repetidos intentos fallidos de
inicio de sesión rechazando más solicitudes de conexión (o bloqueo de inicio de sesión). Este bloque se
puede configurar por un período de tiempo, que se denomina período de silencio. Las listas de control de
acceso (ACL) se pueden utilizar para permitir una conexión legítima desde direcciones de
administradores de sistemas conocidos.

Los banners están deshabilitados de forma predeterminada y deben habilitarse explícitamente. Utilice

el comando del modo de configuración global de banner que se muestra en la Figura 2 para especificar
los mensajes apropiados. Los carteles protegen a la organización desde una perspectiva legal. La elección
de la redacción adecuada para colocar en los mensajes publicitarios es importante y debe ser revisada por
un asesor legal antes de colocarla en los enrutadores de red. Nunca use la palabra bienvenida o cualquier
otro saludo familiar que pueda malinterpretarse como una invitación a usar la red.

Configuración de funciones de mejora de inicio de sesión

Los comandos de mejoras de inicio de sesión de Cisco IOS, que se muestran en la Figura 1, aumentan la
seguridad de las conexiones de inicio de sesión virtual. La figura 2 muestra un ejemplo de
configuración. El comando login block-for puede defenderse de los ataques DoS desactivando los inicios
de sesión después de un número específico de intentos fallidos de inicio de sesión. El comando de inicio
de sesión en modo silencioso se asigna a una ACL que identifica los hosts permitidos. Esto asegura que
solo los hosts autorizados puedan intentar iniciar sesión en el enrutador. El comando de retraso de inicio
de sesión especifica una cantidad de segundos que el usuario debe esperar entre intentos fallidos de inicio
de sesión. Los comandos de inicio de sesión en caso de éxito y de inicio de sesión en caso de
error registran los intentos de inicio de sesión exitosos y no exitosos.

Estas mejoras de inicio de sesión no se aplican a las conexiones de consola. Cuando se trata de

conexiones de consola, se asume que solo el personal autorizado tiene acceso físico a los dispositivos.

Nota : Estas mejoras de inicio de sesión solo se pueden habilitar si la base de datos local se utiliza para la
autenticación para el acceso local y remoto. Si las líneas están configuradas solo para autenticación de
contraseña, las funciones de inicio de sesión mejoradas no están habilitadas.

Habilitar mejoras de inicio de sesión

Para ayudar a que un dispositivo Cisco IOS proporcione detección de DoS, use el comando login block-
for . Todas las demás funciones de mejora de inicio de sesión están deshabilitadas hasta que se configura
el comando login block-for .

La Figura 1 muestra la sintaxis del comando y un ejemplo de configuración del comando login block-

for .

Específicamente, el comando login block-for monitorea la actividad del dispositivo de inicio de sesión y

opera en dos modos:

 Modo normal : también se conoce como modo de reloj. El enrutador lleva la cuenta del número
de intentos fallidos de inicio de sesión dentro de un período de tiempo identificado.

 Modo silencioso : esto también se conoce como período de silencio. Si el número de inicios de
sesión fallidos supera el umbral configurado, todos los intentos de inicio de sesión mediante Telnet,
SSH y HTTP se deniegan durante el tiempo especificado en el comando login block-for.

Cuando el modo silencioso está habilitado, no se permiten todos los intentos de inicio de sesión, incluido
el acceso administrativo válido. Sin embargo, para proporcionar acceso a hosts críticos, como hosts
administrativos específicos en todo momento, este comportamiento se puede anular mediante una
ACL. La ACL se crea e identifica mediante el comando login quiet-mode access-class , como se muestra
en la Figura 2. Solo los hosts identificados en la ACL tienen acceso al dispositivo durante el modo
silencioso.

Al implementar el comando login block-for , se invoca automáticamente un retraso de un segundo entre

los intentos de inicio de sesión. Para hacerlo más difícil para un atacante, el tiempo de retraso entre los
intentos de inicio de sesión se puede aumentar utilizando el comando de retraso de inicio de sesión ,
como se muestra en la Figura 3. El comando introduce un retraso uniforme entre los intentos de inicio de
sesión sucesivos. El retraso ocurre para todos los intentos de inicio de sesión, incluidos los intentos
fallidos o exitosos.

Las inicio de sesión de bloque para , inicio de sesión tranquila en modo de clase de acceso y de

retardo de inicio de sesión comandos ayudan a bloquear los intentos de acceso fallidos por un período
limitado de tiempo. Sin embargo, no pueden evitar que un atacante vuelva a intentarlo. ¿Cómo puede
saber un administrador cuando alguien intenta acceder a la red adivinando la contraseña?
Registro de intentos fallidos

Hay tres comandos que se pueden configurar para ayudar a un administrador a detectar un ataque de
contraseña, como se muestra en la Figura 1. Cada comando permite que un dispositivo genere mensajes
syslog para intentos de inicio de sesión fallidos o exitosos.

Los dos primeros comandos, registro de inicio de sesión exitoso y registro de inicio de sesión en caso
de falla , generan mensajes de syslog para intentos de inicio de sesión exitosos y fallidos. El número de
intentos de inicio de sesión antes de que se genere un mensaje de registro se puede especificar utilizando
la sintaxis [ cada inicio de sesión ], donde el valor predeterminado es 1 intento. El rango válido es de 1 a
65.535.

Como alternativa al comando de registro de inicio de sesión en caso de falla , el comando de tasa de
falla de autenticación de seguridad se puede configurar para generar un mensaje de registro cuando se
exceda la tasa de falla de inicio de sesión.

Utilice el comando show login para verificar la configuración del comando login block-for y el modo

actual. En la Figura 2, el R1 se configuró para bloquear los hosts de inicio de sesión durante 120 segundos
si fallan más de cinco solicitudes de inicio de sesión en 60 segundos. R1 también confirma que el modo
actual es normal y que ha habido cuatro fallas de inicio de sesión en los últimos 55 segundos porque
quedan cinco segundos en el modo normal.

Las figuras 3 y 4 muestran un ejemplo de lo que ocurre cuando se excede el umbral de intento fallido.

La Figura 5 muestra el estado resultante usando el comando show login . Observe que ahora está en modo
silencioso y permanecerá en modo silencioso durante otros 105 segundos. R1 también identifica que la
ACL PERMIT-ADMIN contiene una lista de hosts autorizados a conectarse durante el modo silencioso.

El comando show login failures muestra información adicional sobre los intentos fallidos, como la
dirección IP desde la que se originaron los intentos fallidos de inicio de sesión. La Figura 6 muestra el
resultado de muestra del comando show login failures .

Utilice el Comprobador de sintaxis de la Figura 7 para configurar la seguridad de inicio de sesión

mejorada en R2.

Pasos para configurar SSH

Hay cuatro requisitos que el enrutador debe cumplir antes de configurar SSH:

 Ejecuta una versión de Cisco IOS que admite SSH

 Utiliza un nombre de host único

 Contiene el nombre de dominio correcto de la red.

 Configurado para autenticación local o servicios AAA

La Figura 1 es un ejemplo de los cinco pasos necesarios para configurar un enrutador Cisco para que
admita SSH con autenticación local:
Paso 1 . Configure el nombre de dominio IP de la red utilizando el comando ip domain-name domain-
name en el modo de configuración global.

Paso 2 . Se deben generar claves secretas unidireccionales para que un enrutador pueda cifrar el tráfico
SSH. Estas claves se conocen como claves asimétricas. El software Cisco IOS utiliza el algoritmo Rivest,
Shamir y Adleman (RSA) para generar claves. Para crear la clave RSA, use el comando crypto key
generate rsa general-keys modulus modulus-size en el modo de configuración global. El módulo
determina el tamaño de la clave RSA y se puede configurar desde 360 bits hasta 4096 bits. Cuanto mayor
sea el módulo, más segura será la clave RSA. Sin embargo, las claves con valores de módulo grandes
tardan un poco más en generarse, cifrar y descifrar. La longitud mínima recomendada de la clave de
módulo es de 1.024 bits.

Nota : SSH se habilita automáticamente después de que se generan las claves RSA.

Paso 3 . Aunque no es técnicamente necesario, debido a que los enrutadores Cisco tienen SSH versión 2
de forma predeterminada, puede configurar manualmente la versión 2 con el comando de configuración
global ip ssh versión 2 . La versión original tiene vulnerabilidades conocidas.

Paso 4 . Asegúrese de que haya una entrada de nombre de usuario de base de datos local válida. Si no es
así, cree uno usando el comando de nombre de usuario de tipo algoritmo scrypt secret secret .

Paso 5 . Habilite las sesiones SSH entrantes de vty usando los comandos line vty, login local y ssh de
entrada de transporte .

Para verificar SSH y mostrar las claves generadas, use el comando show crypto key mypubkey rsa en el
modo EXEC privilegiado. Si hay pares de claves existentes, se recomienda que se sobrescriban con
el comando crypto key zeroize rsa . Si hay pares de claves existentes, se recomienda que se eliminen
mediante el comando crypto key zeroize rsa . La Figura 2 proporciona un ejemplo de verificación de las
claves criptográficas SSH y eliminación de las claves antiguas.

Modificación de la configuración SSH

Para verificar la configuración del comando SSH opcional, use el comando show ip ssh , como se
muestra en la Figura 1. También puede modificar el intervalo de tiempo de espera SSH predeterminado y
el número de intentos de autenticación. Utilice el comando del modo de configuración global ip ssh time-
out seconds para modificar el intervalo de tiempo de espera predeterminado de 120 segundos. Esto
configura la cantidad de segundos que SSH puede usar para autenticar a un usuario. Una vez autenticado,
se inicia una sesión EXEC y se aplica el tiempo de espera de ejecución estándar configurado para vty.

De forma predeterminada, un usuario que inicia sesión tiene tres intentos para ingresar la contraseña
correcta antes de desconectarse. Para configurar un número diferente de reintentos SSH consecutivos,
utilice el comando del modo de configuración global ip ssh authentication-retries integer .

Use el Verificador de sintaxis en la Figura 2 para habilitar SSH en R2.

Conexión a un enrutador habilitado para SSH

Para verificar el estado de las conexiones del cliente, use el comando show ssh . Hay dos formas
diferentes de conectarse a un enrutador habilitado para SSH:
  De forma predeterminada, cuando SSH está habilitado, un enrutador Cisco puede actuar como
servidor SSH o cliente SSH. Como servidor, un enrutador puede aceptar conexiones de cliente
SSH. Como cliente, un enrutador puede conectarse a través de SSH a otro enrutador habilitado para
SSH (consulte las Figuras 1, 2 y 3).

 Conéctese mediante un cliente SSH que se ejecuta en un host, como se muestra en las Figuras 4,
5, 6 y 7. Algunos ejemplos de estos clientes incluyen PuTTY, OpenSSH y TeraTerm.

El procedimiento para conectarse a un enrutador Cisco varía según la aplicación cliente SSH que se
utilice. Generalmente, el cliente SSH inicia una conexión SSH al enrutador. El servicio SSH del enrutador
solicita la combinación correcta de nombre de usuario y contraseña. Una vez verificado el inicio de
sesión, el enrutador se puede administrar como si el administrador estuviera usando una sesión Telnet
estándar.

Limitación de la disponibilidad de comandos

Las grandes organizaciones tienen muchas funciones laborales variadas dentro de un departamento de
TI. No todas las funciones laborales deben tener el mismo nivel de acceso a los dispositivos de
infraestructura (como se muestra en las Figuras 1 y 2). El software Cisco IOS tiene dos métodos para
proporcionar acceso a la infraestructura: nivel de privilegios y CLI basada en roles. Ambos métodos
ayudan a determinar quién debería poder conectarse al dispositivo y qué debería poder hacer esa persona
con él. El acceso CLI basado en roles proporciona más granularidad y control.

De forma predeterminada, la CLI del software Cisco IOS tiene dos niveles de acceso a los comandos:

 Modo EXEC de usuario (nivel de privilegio 1) : proporciona los privilegios de usuario del
modo EXEC más bajos y solo permite comandos de nivel de usuario disponibles en el indicador del
router>.

 Modo EXEC privilegiado (nivel de privilegio 15) : incluye todos los comandos de nivel de
habilitación en el indicador del número de enrutador.

Hay 16 niveles de privilegios en total, como se muestra en la Figura 3. Cuanto mayor sea el nivel de
privilegios, más acceso al enrutador tiene un usuario. Los comandos que están disponibles en niveles de
privilegios inferiores también se pueden ejecutar en niveles superiores. Para asignar comandos a un nivel
de privilegio personalizado, use el comando del modo de configuración global de privilegios (Figura 4).

Configurar y asignar niveles de privilegios

Para configurar un nivel de privilegio con comandos específicos, utilice el nivel de privilegio ejecutivo
de nivel [ comando ] . La Figura 1 muestra ejemplos para tres niveles de privilegios diferentes.

 El nivel de privilegio 5 tiene acceso a todos los comandos disponibles para el nivel predefinido 1
y el comando ping.

 El nivel de privilegio 10 tiene acceso a todos los comandos disponibles para el nivel 5, así como
al comando de recarga.
  El nivel de privilegio 15 está predefinido y no es necesario configurarlo explícitamente. Este
nivel de privilegio tiene acceso a todos los comandos, incluida la visualización y el cambio de
configuración.

Hay dos métodos para asignar contraseñas a los diferentes niveles de privilegios:

 Para un usuario al que se le otorga un nivel de privilegio específico, use el comando de modo de
configuración global de contraseña secreta de nivel de privilegio de nombre de usuario

 Para el nivel de privilegio, use el comando enable secret level password del modo de

configuración global

Nota : Tanto el secreto de nombre de usuario como los comandos enable secret están configurados

para el cifrado de tipo 9.

Utilice el comando de nombre de usuario para asignar un nivel de privilegios a un usuario

específico. Utilice el comando enable secret para asignar un nivel de privilegio a una contraseña
específica del modo EXEC. Por ejemplo, al usuario SUPPORT se le asigna el nivel de privilegio 5 con la
contraseña cisco5. Sin embargo, como se muestra en la Figura 2, cualquier usuario puede acceder al nivel
de privilegio 5 si ese usuario sabe que la contraseña secreta de habilitación es cisco5. La Figura 2 también
demuestra que el nivel de privilegio 5 no puede recargar el enrutador. En la Figura 3, el usuario habilita el
nivel de privilegio 10 que tiene acceso a la recargamando. Sin embargo, los usuarios con el nivel de
privilegio 10 no pueden ver la configuración en ejecución. En la Figura 4, el usuario habilita el nivel de
privilegio 15 que tiene acceso completo para ver y cambiar la configuración, incluida la visualización de
la ejecución de la configuración.

Limitaciones de los niveles de privilegio

El uso de niveles de privilegios tiene sus limitaciones:

 Sin control de acceso a interfaces, puertos, interfaces lógicas y ranuras específicas en un

enrutador.

 Los comandos disponibles en los niveles de privilegios inferiores siempre se pueden ejecutar en
los niveles superiores.

 Los comandos configurados específicamente en un nivel de privilegio superior no están

disponibles para usuarios con privilegios inferiores.

 La asignación de un comando con varias palabras clave permite el acceso a todos los comandos
que utilizan esas palabras clave. Por ejemplo, permitir el acceso a show ip route permite al usuario
acceder a todos los comandos show y show ip .

Nota : Si un administrador debe crear una cuenta de usuario que tenga acceso a la mayoría de los
comandos, pero no a todos, las declaraciones de exec de privilegios deben configurarse para cada
comando que deba ejecutarse con un nivel de privilegio inferior a 15.

Utilice el Verificador de sintaxis en la Figura 2 para configurar los niveles de privilegios en R2.
Acceso CLI basado en roles

En un esfuerzo por brindar más flexibilidad de la que permiten los niveles de privilegios, Cisco introdujo
la función de acceso CLI basada en roles en Cisco IOS Release 12.3 (11) T. Esta característica
proporciona un acceso más fino y granular al controlar qué comandos están disponibles para roles
específicos, como se muestra en las Figuras 1 y 2. El acceso CLI basado en roles permite al administrador
de la red crear diferentes vistas de las configuraciones del enrutador para diferentes usuarios. Cada vista
define los comandos de la CLI a los que puede acceder cada usuario.

Seguridad

El acceso CLI basado en roles mejora la seguridad del dispositivo al definir el conjunto de comandos CLI
accesibles por un usuario específico. Además, los administradores pueden controlar el acceso de los
usuarios a puertos específicos, interfaces lógicas y ranuras en un enrutador. Esto evita que un usuario
cambie accidental o intencionalmente una configuración o recopile información a la que no debería tener
acceso.

Disponibilidad

El acceso CLI basado en roles evita la ejecución involuntaria de comandos CLI por parte de personal no
autorizado y minimiza el tiempo de inactividad.

Eficiencia operacional

Los usuarios solo ven los comandos CLI aplicables a los puertos y CLI a los que tienen acceso. Por lo
tanto, el enrutador parece ser menos complejo y los comandos son más fáciles de identificar cuando se
usa la función de ayuda en el dispositivo.

Vistas basadas en roles

La CLI basada en roles proporciona tres tipos de vistas que dictan qué comandos están disponibles:

Vista raíz

Para configurar cualquier vista del sistema, el administrador debe estar en la vista raíz. La vista raíz tiene
los mismos privilegios de acceso que un usuario con privilegios de nivel 15. Sin embargo, una vista de
root no es lo mismo que un usuario de nivel 15. Solo un usuario de vista raíz puede configurar una nueva
vista y agregar o eliminar comandos de las vistas existentes.

Vista CLI

Se puede agrupar un conjunto específico de comandos en una vista CLI. A diferencia de los niveles de
privilegios, una vista CLI no tiene jerarquía de comandos ni vistas superiores o inferiores. A cada vista se
le deben asignar todos los comandos asociados con esa vista. Una vista no hereda comandos de ninguna
otra vista. Además, los mismos comandos se pueden utilizar en varias vistas.

Supervista

Una supervista consta de una o más vistas CLI. Los administradores pueden definir qué comandos se
aceptan y qué información de configuración es visible. Las supervistas permiten que un administrador de
red asigne usuarios y grupos de usuarios múltiples vistas CLI a la vez, en lugar de tener que asignar una
sola vista CLI por usuario con todos los comandos asociados con esa vista CLI.

Las supervistas tienen varias características específicas:

 Una sola vista CLI se puede compartir dentro de múltiples supervistas.

 Los comandos no se pueden configurar para una supervista. Un administrador debe agregar
comandos a la vista CLI y agregar esa vista CLI a la supervista.

 Los usuarios que han iniciado sesión en una supervista pueden acceder a todos los comandos
configurados para cualquiera de las vistas CLI que forman parte de la supervista.

 Cada supervista tiene una contraseña que se utiliza para cambiar entre supervistas o de una vista
CLI a una supervista.

 Eliminar una supervista no elimina las vistas CLI asociadas. Las vistas CLI permanecen
disponibles para ser asignadas a otra supervista.

Haga clic en Reproducir en la animación para obtener una explicación de las vistas.

Configuración de vistas basadas en roles

Antes de que un administrador pueda crear una vista, se debe habilitar AAA mediante el comando aaa
new-model . Para configurar y editar vistas, un administrador debe iniciar sesión como vista raíz
utilizando el comando EXEC privilegiado enable view . La sintaxis del comando enable view se muestra
en la Figura 1. También se puede utilizar el comando enable view root . Cuando se le solicite, ingrese
la contraseña secreta de habilitación .

Hay cinco pasos para crear y administrar una vista específica:

Paso 1 . Habilite AAA con el comando del modo de configuración global del nuevo modelo aaa . Salga
y acceda a la vista raíz con el comando enable view .

Paso 2 . Cree una vista usando el comando del modo de configuración global view-name del analizador
view . Esto habilita el modo de configuración de vista. Excluyendo la vista raíz, hay un límite máximo de
15 vistas en total.

Paso 3 . Asigne una contraseña secreta a la vista mediante el comando de modo de configuración de vista
de contraseña cifrada secreta . La Figura 2 muestra la sintaxis de comandos para
la vista del analizador y los comandos secretos .

Paso 4 . Asigne comandos a la vista seleccionada usando el comando parser-mode en el modo de

configuración de vista. La Figura 3 muestra la sintaxis del comando para el comando de comandos.

Paso 5 . Salga del modo de configuración de vista escribiendo el comando exit .

La Figura 4 proporciona un ejemplo de configuración de tres vistas. Observe en el ejemplo que

el comando secreto solo admite el cifrado MD5 (tipo 5). Además, observe que cuando se agrega un
comando a una vista antes de que se asigne la contraseña, se produce un error. La Figura 5 muestra las
vistas configuradas en la configuración en ejecución.

Utilice el Comprobador de sintaxis de la Figura 6 para configurar las vistas en R2.

Configuración de supervistas de CLI basadas en roles

Los pasos para configurar una supervista son esencialmente los mismos que para configurar una vista
CLI, excepto que el comando view view-name se usa para asignar comandos a la supervista. El
administrador debe estar en la vista raíz para configurar una supervista. Para confirmar que se está
utilizando la vista raíz, use el comando enable view o enable view root . Cuando se le solicite, ingrese
la contraseña secreta .

Hay cuatro pasos para crear y administrar una supervista:

Paso 1 . Crear una vista con la vista analizador nombre-vista supervista mando y entrar en el modo de

configuración supervista.

Paso 2 . Asigne una contraseña secreta a la vista mediante el comando secret encrypted-password . La

Figura 1 muestra la sintaxis de comandos para la supervista de la vista del analizador y
los comandos secretos .

Paso 3 . Asigne una vista existente usando el comando view view-name en el modo de configuración de

vista. La Figura 2 muestra la sintaxis del comando para ver.

Paso 4 . Salga del modo de configuración de supervista escribiendo el comando exit .

Se puede asignar más de una vista a una supervista y las vistas se pueden compartir entre supervistas. La
Figura 3 proporciona un ejemplo de configuración de tres supervistas: USUARIO, SOPORTE y JR-
ADMIN. La Figura 4 muestra las supervistas configuradas en la configuración en ejecución.

Para acceder a las vistas existentes, ingrese el comando enable view view-name en modo de usuario e
ingrese la contraseña que se asignó a la vista personalizada. Utilice el mismo comando para cambiar de
una vista a otra.

Utilice el Verificador de sintaxis en la Figura 5 para configurar supervistas en R2.

Verificar vistas de CLI basadas en roles

Para verificar una vista, use el comando enable view . Ingrese el nombre de la vista para verificar y
proporcione la contraseña para iniciar sesión en la vista. Utilice el comando del signo de interrogación
( ? ) Para verificar que los comandos disponibles en la vista sean correctos.

La Figura 1 habilita la supervista USUARIO y enumera los comandos disponibles en la vista.

La Figura 2 habilita la supervista SUPPORT y enumera los comandos disponibles en la vista.

La Figura 3 habilita la vista JR-ADMIN y enumera los comandos disponibles en la vista.

Si no especifica una vista para el comando enable view, como se muestra en la Figura 4, puede iniciar
sesión como root. Desde la vista raíz, use el comando show parser view all para ver un resumen de todas
las vistas. Observe cómo el asterisco identifica las supervistas.

Característica de configuración resistente de Cisco IOS

La función de configuración resistente de Cisco IOS permite una recuperación más rápida si alguien
reformatea la memoria flash de forma maliciosa o involuntaria o borra el archivo de configuración de
inicio en la memoria de acceso aleatorio no volátil (NVRAM). La función mantiene una copia de trabajo
segura del archivo de imagen IOS del enrutador y una copia del archivo de configuración en ejecución. El
usuario no puede eliminar estos archivos seguros y se los conoce como el conjunto de arranque principal.

La figura describe algunos hechos sobre la configuración resistente de Cisco IOS.

Habilitación de la función de resiliencia de imagen de IOS

Los comandos para proteger la imagen de IOS y el archivo de configuración en ejecución se muestran en
la figura. Para proteger la imagen de IOS y habilitar la resistencia de la imagen de Cisco IOS, utilice
el comando del modo de configuración global de imagen de arranque segura . Cuando se habilita por
primera vez, la imagen de Cisco IOS en ejecución está protegida y se genera una entrada de registro. La
función de resistencia de la imagen de Cisco IOS solo se puede desactivar mediante una sesión de consola
mediante la forma no del comando. Este comando funciona correctamente solo cuando el sistema está
configurado para ejecutar una imagen desde una unidad flash con una interfaz ATA. Además, la imagen
en ejecución debe cargarse desde el almacenamiento persistente para asegurarse como principal. Las
imágenes que se cargan desde una ubicación remota, como un servidor TFTP, no se pueden proteger.

Para tomar una instantánea de la configuración en ejecución del enrutador y archivarla de manera segura
en un almacenamiento persistente, use el comando del modo de configuración global secure boot-
config , como se muestra en la figura. Se muestra un mensaje de registro en la consola que notifica al
usuario que la resistencia de la configuración está activada. El archivo de configuración está oculto y no
se puede ver ni eliminar directamente desde el indicador de la CLI. Puede utilizar el comando secure
boot-config repetidamente para actualizar el archivo de configuración a una versión más reciente después
de que se hayan emitido nuevos comandos de configuración.

Los archivos protegidos no aparecen en la salida de un comando dir que se emite desde la CLI. Esto se

debe a que el sistema de archivos de Cisco IOS evita que se enumeren archivos seguros. La imagen en
ejecución y los archivos de configuración en ejecución no son visibles en la salida del
comando dir . Utilice el comando show secure bootset para verificar la existencia del archivo, como se
muestra en la figura.

La imagen del conjunto de arranque principal

Restaure un conjunto de arranque primario desde un archivo seguro después de que el enrutador haya sido
manipulado, como se muestra en la figura:

Paso 1 . Vuelva a cargar el enrutador con el comando reload . Si es necesario, emita la secuencia de

interrupción para ingresar al modo ROMmon.
Paso 2 . Desde el modo ROMmon, ingrese el comando dir para listar el contenido del dispositivo que
contiene el archivo de arranque seguro.

Paso 3 . Inicie el enrutador con la imagen del conjunto de inicio seguro utilizando el comando
de inicio seguido de la ubicación de la memoria flash (por ejemplo, flash0), dos puntos y el nombre de
archivo que se encuentra en el Paso 2.

Paso 4 . Ingrese al modo de configuración global y restaure la configuración segura a un nombre de

archivo de su elección usando el comando secure boot-config restore seguido de la ubicación de la
memoria flash (por ejemplo, flash0), dos puntos y un nombre de archivo de su elección. En la figura, se
utiliza el nombre de archivo rescue-cfg.

Paso 5 . Salir del modo de configuración global y emitir la copia comando para copiar el archivo de
configuración rescatado a la configuración en ejecución.

Configuración de copia segura

La función Resiliente de Cisco IOS proporciona un método para proteger la imagen de IOS y los archivos
de configuración localmente en el dispositivo. Utilice la función de Protocolo de copia segura (SCP) para
copiar estos archivos de forma remota. SCP proporciona un método seguro y autenticado para copiar la
configuración del enrutador o los archivos de imagen del enrutador a una ubicación remota. SCP se basa
en SSH y requiere que se configure la autenticación y autorización AAA para que el enrutador pueda
determinar si el usuario tiene el nivel de privilegio correcto.

Nota : La configuración AAA se tratará con mayor detalle en un capítulo posterior.

Configure el enrutador para SCP del lado del servidor con AAA local:

Paso 1 . Configure SSH, si aún no lo ha configurado.

Paso 2 . Para la autenticación local, configure al menos un usuario con nivel de privilegio 15.

Paso 3 . Habilite AAA con el comando del modo de configuración global del nuevo modelo aaa .

Paso 4 . Utilice el comando local predeterminado de inicio de sesión de autenticación aaa para

especificar que la base de datos local se utilice para la autenticación.

Paso 5 . Utilice el comando local predeterminado del exec de autorización aaa para configurar la

autorización del comando. En este ejemplo, todos los usuarios locales tendrán acceso a los comandos
EXEC.

Paso 6 . Habilite la funcionalidad del lado del servidor de SCP con el comando ip scp server enable .

R1 es ahora un servidor SCP y utilizará conexiones SSH para aceptar transferencias de copias seguras de
usuarios autenticados y autorizados. Las transferencias pueden originarse desde cualquier cliente SCP, ya
sea que ese cliente sea otro enrutador, conmutador o estación de trabajo.

La Figura 2 muestra una transferencia SCP de enrutador a enrutador. En R2, use

el comando copiar . Primero especifique la ubicación del archivo de origen (flash0: R2backup.cfg) y
luego el destino (scp :). Responda la serie de mensajes para establecer una conexión con el servidor SCP
en el R1. En el R1, puede ingresar el comando debug ip scp para ver cómo se realiza la transferencia. El
problema de autenticación más común es una combinación incorrecta de nombre de usuario y
contraseña. También hay una falla de autenticación si la combinación de nombre de usuario / contraseña
no se configuró con la palabra clave privilege 15 en el servidor SCP.

Recuperación de la contraseña de un enrutador

Si un enrutador está comprometido o necesita ser recuperado de una contraseña mal configurada, un
administrador debe usar procedimientos de recuperación de contraseña, como los que se muestran en la
figura. Por razones de seguridad, la recuperación de la contraseña requiere que el administrador tenga
acceso físico al enrutador a través de un cable de consola. Dependiendo del dispositivo, el procedimiento
detallado para la recuperación de la contraseña varía.

Recuperación de contraseña

Si alguien obtuvo acceso físico a un enrutador, podría potencialmente obtener el control de ese
dispositivo a través del procedimiento de recuperación de contraseña. Este procedimiento, si se realiza
correctamente, deja intacta la configuración del enrutador. Si el atacante no realiza cambios importantes,
este tipo de ataque es difícil de detectar. Un atacante puede utilizar este método de ataque para descubrir
la configuración del enrutador y otra información pertinente sobre la red, como los flujos de tráfico y las
restricciones de control de acceso.

Un administrador puede mitigar esta posible brecha de seguridad mediante el comando del modo de
configuración global de recuperación de contraseña sin servicio . Este comando es un comando de
Cisco IOS oculto y no tiene argumentos ni palabras clave. Si un enrutador está configurado con
el comando de recuperación de contraseña sin servicio , se deshabilita todo el acceso al modo
ROMmon.

Cuando se ingresa el comando de recuperación de contraseña sin servicio , se muestra un mensaje de

advertencia y se debe reconocer antes de habilitar la función, como se muestra en la Figura 1.

Cuando está configurado, el comando show running-config muestra una declaración de recuperación de

contraseña sin servicio , como se muestra en la Figura 2.

Como se muestra en la Figura 3, cuando se inicia el enrutador, la secuencia de inicio inicial muestra un
mensaje que indica que LA FUNCIONALIDAD DE RECUPERACIÓN DE CONTRASEÑA ESTÁ
DESHABILITADA.

Para recuperar un dispositivo después de ingresar el comando de recuperación de contraseña sin

servicio , inicie la secuencia de interrupción dentro de los cinco segundos posteriores a la descompresión
de la imagen durante el arranque. Se le solicitará que confirme la acción de la tecla de interrupción. Una
vez confirmada la acción, la configuración de inicio se borra por completo, se habilita el procedimiento
de recuperación de contraseña y el enrutador se inicia con la configuración predeterminada de fábrica. Si
no confirma la acción de interrupción, el enrutador se inicia normalmente con el comando
de recuperación de contraseña sin servicio habilitado.

PRECAUCIÓN : Si la memoria flash del enrutador no contiene una imagen de IOS de Cisco válida
debido a la corrupción o eliminación, el comando ROMmon xmodem no se puede utilizar para cargar una
nueva imagen flash. Para reparar el enrutador, un administrador debe obtener una nueva imagen de Cisco
IOS en un SIMM flash o en una tarjeta PCMCIA. Sin embargo, si un administrador tiene acceso a
ROMmon, puede restaurar un archivo IOS a la memoria flash utilizando un servidor TFTP. Consulte
Cisco.com para obtener más información sobre las imágenes flash de respaldo.

Determinación del tipo de acceso de administración

En una red pequeña, administrar y monitorear una pequeña cantidad de dispositivos de red es una
operación sencilla. Sin embargo, en una gran empresa con cientos de dispositivos, monitorear, administrar
y procesar mensajes de registro puede ser un desafío. Desde el punto de vista de los informes, la mayoría
de los dispositivos de red pueden enviar datos de registro que pueden ser invaluables para solucionar
problemas de red o amenazas de seguridad. Estos datos se pueden ver en tiempo real, bajo demanda y en
informes programados.

Al registrar y administrar información, el flujo de información entre los hosts de administración y los
dispositivos administrados puede tomar dos caminos:

 En banda : la información fluye a través de una red de producción empresarial, Internet o ambos,
utilizando canales de datos regulares.

 Fuera de banda (OOB) : la información fluye en una red de gestión dedicada en la que no reside
tráfico de producción.

Por ejemplo, la red de la Figura 1 tiene dos segmentos de red separados por un enrutador Cisco IOS que
proporciona servicios de firewall para proteger la red de administración. La conexión a la red de
producción permite que los hosts de administración accedan a Internet y proporciona un tráfico de
administración en banda limitado. La administración dentro de banda ocurre solo cuando la
administración OOB no es posible o no está disponible. Si se requiere administración en banda, entonces
ese tráfico debe enviarse de forma segura mediante un túnel encriptado privado o un túnel VPN.

La Figura 2 muestra más detalles para la red de administración protegida. Aquí es donde residen los hosts
de administración y los servidores de terminales. Cuando se colocan dentro de la red de administración,
los servidores de terminales ofrecen conexiones de consola directas OOB a través de la red de
administración a cualquier dispositivo de red que requiera administración en la red de producción. La
mayoría de los dispositivos deben conectarse a este segmento de gestión y configurarse mediante la
gestión OOB.

Debido a que la red de administración tiene acceso administrativo a casi todas las áreas de la red, puede
ser un objetivo muy atractivo para los piratas informáticos. El módulo de gestión del firewall incorpora
varias tecnologías diseñadas para mitigar dichos riesgos. La principal amenaza es un pirata informático
que intenta acceder a la red de gestión. Esto se puede lograr a través de un host administrado
comprometido al que debe acceder un dispositivo de administración. Para mitigar la amenaza de un
dispositivo comprometido, se debe implementar un fuerte control de acceso en el firewall y en todos los
demás dispositivos. Los dispositivos de administración deben configurarse de manera que eviten la
comunicación directa con otros hosts en la misma subred de administración mediante el uso de segmentos
de LAN o VLAN separados.

Acceso fuera de banda y dentro de banda

Como regla general, por motivos de seguridad, la gestión OOB es adecuada para grandes redes
empresariales. Sin embargo, no siempre es deseable. La decisión de utilizar la gestión OOB depende del
tipo de aplicaciones de gestión que se ejecutan y de los protocolos que se supervisan. Por ejemplo,
considere una situación en la que dos conmutadores centrales se gestionan y supervisan mediante una red
OOB. Si un enlace crítico entre estos dos conmutadores centrales falla en la red de producción, la
aplicación que monitorea esos dispositivos nunca puede determinar que el enlace ha fallado y nunca
alertar al administrador. Esto se debe a que la red OOB hace que todos los dispositivos parezcan estar
conectados a una única red de administración OOB. La red de administración OOB no se ve afectada por
el enlace caído. Con aplicaciones de gestión como estas, Es preferible ejecutar la aplicación de gestión en
banda de forma segura. Las pautas de gestión de OOB se muestran en la Figura 1.

Se recomienda la administración en banda en redes más pequeñas como un medio para lograr una
implementación de seguridad más rentable. En tales arquitecturas, el tráfico de gestión fluye en banda en
todos los casos. Se hace lo más seguro posible usando protocolos de administración seguros, por ejemplo,
usando SSH en lugar de Telnet. Otra opción es crear túneles seguros, utilizando protocolos como IPsec,
para la gestión del tráfico. Si el acceso de administración no es necesario en todo momento, se pueden
colocar agujeros temporales en un firewall mientras se realizan las funciones de administración. Esta
técnica debe usarse con precaución y todos los orificios deben cerrarse inmediatamente cuando se
completen las funciones de gestión. Las pautas de gestión dentro de banda se muestran en la Figura 2.

Por último, si utiliza herramientas de administración remota con administración en banda, tenga cuidado
con las vulnerabilidades de seguridad subyacentes de la propia herramienta de administración. Por
ejemplo, los administradores SNMP se utilizan a menudo para facilitar la resolución de problemas y las
tareas de configuración en una red. Sin embargo, SNMP debe tratarse con sumo cuidado porque el
protocolo subyacente tiene su propio conjunto de vulnerabilidades de seguridad.

Introducción a Syslog

La implementación de una función de registro es una parte importante de cualquier política de seguridad
de red. Cuando ocurren ciertos eventos en una red, los dispositivos de red tienen mecanismos confiables
para notificar al administrador con mensajes detallados del sistema. Estos mensajes pueden ser no críticos
o significativos, y hay varias opciones disponibles para almacenarlos, interpretarlos y mostrarlos. Los
administradores pueden recibir alertas sobre todos los mensajes o solo los mensajes que puedan tener el
mayor impacto en la infraestructura de la red.

El método más común para acceder a los mensajes del sistema desde dispositivos de red es usar un
protocolo llamado syslog, que se describe en RFC 5424. Syslog usa el puerto 514 del Protocolo de
datagramas de usuario (UDP) para enviar mensajes de notificación de eventos a través de redes IP a los
recolectores de mensajes de eventos, como se muestra en la figura.

Muchos dispositivos de red admiten syslog, incluidos enrutadores, conmutadores, servidores de

aplicaciones, cortafuegos y otros dispositivos en red. El servicio de registro de syslog proporciona tres
funciones principales:

 La capacidad de recopilar información de registro para monitorear y solucionar problemas

 La capacidad de seleccionar el tipo de información de registro que se captura.

 La capacidad de especificar los destinos de los mensajes syslog capturados

Operación de Syslog
En los dispositivos de red de Cisco, el protocolo syslog comienza enviando mensajes del sistema y la
salida de depuración a un proceso de registro local que es interno al dispositivo. La forma en que el
proceso de registro gestiona y genera estos mensajes se basa en las configuraciones del dispositivo. Por
ejemplo, los mensajes de syslog pueden enviarse a través de la red a un servidor de syslog externo. Estos
mensajes se pueden recuperar y luego incluir en varios informes para facilitar la lectura.

Los enrutadores Cisco pueden registrar información sobre cambios de configuración, violaciones de
ACL, estado de la interfaz, utilización de la CPU y muchos otros tipos de eventos. Por ejemplo, utilice
los comandos del procesador de marca de agua baja sin memoria libre io y del procesador de marca
de agua baja sin memoria para establecer los umbrales de memoria. El enrutador enviará notificaciones,
especificadas en kilobytes, al servidor syslog cuando la memoria libre disponible caiga por debajo del
umbral. El enrutador enviará notificaciones nuevamente cuando la memoria libre disponible se eleve al
cinco por ciento por encima del umbral.

Los enrutadores Cisco pueden registrar información sobre cambios de configuración, violaciones de
ACL, estado de la interfaz y muchos otros tipos de eventos. Los enrutadores Cisco se pueden configurar
para enviar mensajes de syslog a varias instalaciones diferentes, como se muestra en la figura:

 Búfer de registro : los mensajes se almacenan en la memoria del enrutador durante un período de
tiempo. Sin embargo, los eventos se borran cuando se reinicia el enrutador.

 Consola : el registro de la consola está activado de forma predeterminada. Los mensajes de

Syslog se envían a la línea de la consola cuando el administrador activa la interfaz.

 Líneas de terminal : las sesiones EXEC habilitadas se pueden configurar para recibir mensajes
de registro en cualquier línea de terminal.

 Servidor de Syslog : los enrutadores Cisco se pueden configurar para reenviar mensajes de
registro a un servicio de Syslog externo.

Mensaje de Syslog

Los dispositivos de Cisco producen mensajes de Syslog como resultado de eventos de red. Cada mensaje
de syslog contiene un nivel de gravedad y una función.

Los niveles numéricos más pequeños son las alarmas de syslog más críticas. El nivel de gravedad de los
mensajes se puede configurar para controlar dónde se muestra cada tipo de mensaje (es decir, en la
consola o en otros destinos). La lista completa de niveles de syslog se muestra en la Figura 1. Cada nivel
de syslog tiene su propio significado, como se muestra en la Figura 2.

Los niveles de Syslog de cero a cuatro son mensajes sobre la funcionalidad de software o hardware. La
gravedad del problema determina el nivel de syslog real aplicado. Los niveles cinco y seis de Syslog son
para notificaciones y mensajes informativos. El nivel siete de Syslog indica que los mensajes se generan
mediante la emisión de varios comandos de depuración.

Además de especificar la gravedad, los mensajes de syslog contienen información sobre la

instalación. Las instalaciones de Syslog son identificadores de servicio que identifican y categorizan los
datos del estado del sistema para informar de mensajes de error y eventos. Las opciones de la función de
registro que están disponibles son específicas del dispositivo de red.
El formato de los mensajes de syslog de Cisco IOS se muestra en la Figura 3.

Sistemas Syslog

Las implementaciones de Syslog siempre contienen dos tipos de sistemas:

 Servidores de Syslog : también conocidos como hosts de registro, estos sistemas aceptan y
procesan los mensajes de registro de los clientes de Syslog.

 Clientes de Syslog : enrutadores u otros tipos de equipos que generan y reenvían mensajes de
registro a los servidores de Syslog.

La topología de la figura identifica el servidor syslog en la dirección IP 10.2.2.6. El resto de los

servidores y dispositivos de la topología se pueden configurar como clientes syslog, que envían mensajes
syslog al servidor syslog.

Configurar el registro del sistema

Configure el registro del sistema:

Paso 1 . Configure el host de registro de destino mediante el comando logging host , como se muestra en
la Figura 1.

Paso 2 . (Opcional) Establezca el nivel de gravedad del registro (captura) mediante el comando
de captura de registro , como se muestra en la Figura 2.

Paso 3 . Configure la interfaz de origen mediante el comando logging source-interface , como se

muestra en la Figura 3. Este comando especifica que los paquetes syslog contienen la dirección IPv4 o
IPv6 de una interfaz específica, independientemente de la interfaz que utilice el paquete para salir del
enrutador.

Paso 4 . Habilite el registro en todos los destinos habilitados con el comando logging on , como se
muestra en la Figura 4.

La Figura 5 muestra la topología de referencia de syslog. La Figura 6 muestra una configuración de

syslog de muestra para R1. Utilice el comando show logging para ver la configuración de registro y los
mensajes syslog almacenados en búfer.

Introducción a SNMP

Otra herramienta de monitoreo común es el Protocolo simple de administración de redes (SNMP). SNMP

se desarrolló para permitir a los administradores administrar dispositivos en una red IP. Permite a los
administradores de red monitorear el rendimiento de la red, administrar dispositivos de red, solucionar
problemas de red y planificar el crecimiento de la red.

SNMP consta de tres elementos relevantes para el Sistema de gestión de red (NMS):

 Administrador SNMP
  Agentes SNMP (nodo administrado)

 Base de información de gestión (MIB)

Los administradores y agentes de SNMP utilizan UDP para intercambiar información. Específicamente,

los agentes SNMP escuchan el puerto UDP 161 mientras que los administradores SNMP escuchan el
puerto UDP 162. El administrador SNMP ejecuta el software de administración SNMP. Como se muestra
en la figura, el administrador SNMP puede recopilar información de un agente SNMP mediante obtener
solicitudes y puede cambiar las configuraciones de un agente mediante la acción de establecer
solicitudes. El agente SNMP debe estar configurado para proporcionar acceso a la MIB local. Además,
los agentes SNMP se pueden configurar para reenviar notificaciones (capturas) directamente a un
administrador SNMP.

Base de información de gestión (MIB)

Los mensajes SNMP set, get y trap tienen acceso para crear y cambiar la información en la MIB. Esta
información está organizada jerárquicamente para que SNMP pueda acceder a ella rápidamente. Cada
pieza de información dentro de la MIB recibe un ID de objeto (OID). El MIB organiza los OID según los
estándares RFC en una jerarquía de OID, como se muestra en la Figura 1. El significado de cada uno de
los niveles del árbol está más allá del alcance de este curso. Sin embargo, tenga en cuenta que los
mensajes SNMP para dispositivos Cisco se almacenan en la MIB en las siguientes ubicaciones:
1.3.6.1.4.1.9. Este es solo un ejemplo. El árbol MIB para cualquier dispositivo dado incluye ramas con
variables comunes a muchos dispositivos de red y ramas con variables específicas para ese dispositivo o
proveedor.

Cisco SNMP Object Navigator permite a un administrador de red investigar detalles sobre un OID
en particular. La Figura 2 muestra un ejemplo de cómo determinar que el OID 1.3.6.1.2.1.4.21 está
reservado para la tabla de enrutamiento de un dispositivo. Haga
clic aquí (https://snmp.cloudapps.cisco.com/Support/SNMP/do/BrowseOID.do) Versiones SNMP

Hay varias versiones de SNMP disponibles:

 SNMPv1 : definido en RFC 1157; no proporcionó ningún mecanismo de autenticación o cifrado

 SNMPv2c : definido en las RFC 1901 a 1908; mejoró en SNMPv1 pero no proporcionó ningún
mecanismo de autenticación o cifrado

 SNMPv3 : definido en las RFC 2273 a 2275; proporciona acceso seguro a los dispositivos
mediante la autenticación y el cifrado de paquetes a través de la red

Los detalles del modelo de seguridad para cada versión se muestran en la figura.

Vulnerabilidades SNMP

En cualquier topología de red, al menos un nodo administrador debe ejecutar el software de

administración SNMP. Los dispositivos de red que se pueden administrar, como conmutadores,
enrutadores, servidores y estaciones de trabajo, están equipados con el módulo de software del agente
SNMP. Estos agentes son responsables de proporcionar al administrador SNMP acceso a una MIB local,
que almacena datos sobre el funcionamiento del dispositivo.

SNMP es vulnerable a los ataques precisamente porque los agentes SNMP pueden ser consultados con
solicitudes de obtención y aceptar cambios de configuración con solicitudes de configuración, como se
muestra en la figura. Por ejemplo, una solicitud de configuración puede hacer que un enrutador se
reinicie, envíe un archivo de configuración o reciba un archivo de configuración. También se puede
configurar un agente SNMP para enviar capturas o notificaciones. En SNMPv1 y SNMPv2c, estas
solicitudes y notificaciones no están autenticadas ni cifradas.

SNMPv3

SNMPv3 autentica y cifra los paquetes en la red para proporcionar acceso seguro a los dispositivos. Esto
solucionó las vulnerabilidades de versiones anteriores de SNMP.

SNMPv3 proporciona tres funciones de seguridad:

 Integridad y autenticación de mensajes : garantiza que un paquete no haya sido manipulado en

tránsito y que provenga de una fuente válida, como se muestra en la Figura 1.

 Cifrado : codifica el contenido de un paquete para evitar que una fuente no autorizada lo vea,
como se muestra en la Figura 2.

 Control de acceso : restringe a cada principal a ciertas acciones en porciones específicas de

datos, como se muestra en la Figura 3.

Configuración de la seguridad SNMPv3

SNMPv3 se puede proteger con solo unos pocos comandos, como se muestra en la figura.

Paso 1 . Configure una ACL que permitirá el acceso a administradores SNMP autorizados.

Paso 2 . Configure una vista SNMP con el comando snmp-server view para identificar los OID de MIB
que el administrador SNMP podrá leer. Es necesario configurar una vista para limitar los mensajes SNMP
al acceso de solo lectura.

Paso 3 . Configure las funciones del grupo SNMP con el comando snmp-server group :

 Configure un nombre para el grupo.

 Establezca la versión SNMP en 3 con la palabra clave v3 .

 Requiere autenticación y cifrado con la palabra clave priv .

 Asocie una vista al grupo y dele acceso de solo lectura con el comando de lectura .

 Especifique la ACL configurada en el Paso 1.

Paso 4 . Configure las funciones de usuario del grupo SNMP con el comando de usuario snmp-server :

 Configure un nombre de usuario y asocie al usuario con el nombre del grupo configurado en el
Paso 3.

 Establezca la versión SNMP en 3 con la palabra clave v3 .

 Establezca el tipo de autenticación en md5 o sha y configure una contraseña de autenticación. Se

prefiere SHA y debe ser compatible con el software de gestión SNMP.

 Solicite el cifrado con la palabra clave priv y configure una contraseña de cifrado.

Una discusión completa de las opciones de configuración para SNMPv3 está más allá del alcance de este
curso.

Ejemplo de configuración segura SNMPv3

La Figura 1 muestra una configuración de ejemplo para proteger SNMPv3.

Paso 1 . Una ACL estándar se denomina PERMIT-ADMIN y está configurada para permitir solo la red
192.168.1.0/24. Todos los hosts conectados a esta red podrán acceder al agente SNMP que se ejecuta en
R1.

Paso 2 . Una vista SNMP se denomina SNMP-RO y está configurada para incluir el árbol iso completo de
la MIB. En una red de producción, el administrador de la red probablemente configuraría esta vista para
incluir solo los OID de MIB que fueran necesarios para monitorear y administrar la red.

Paso 3 . Un grupo SNMP se configura con el nombre ADMIN. SNMP está configurado en la versión 3 y
se requiere autenticación y cifrado. El grupo tiene acceso de solo lectura a la vista (SNMP-RO). El acceso
para el grupo está limitado por PERMIT-ADMIN ACL.

Paso 4 . Un usuario SNMP, BOB, está configurado como miembro del grupo ADMIN. SNMP está
configurado en la versión 3. La autenticación está configurada para usar SHA y se configura una
contraseña de autenticación. Aunque el R1 admite hasta un cifrado AES 256, el 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 Syntax Checker en la Figura 2 para configurar R1 con autenticación SNMPv3 usando una ACL.

Verificación de la configuración de SNMPv3

Verifique la mayor parte de la configuración de seguridad SNMPv3 viendo la configuración en ejecución,

como se muestra en la Figura 1. Observe que la configuración de usuario del servidor snmp está
oculta. Utilice el comando show snmp user para ver la información del usuario.

Verifique que el administrador SNMP pueda enviar solicitudes de obtención al R1 mediante una
herramienta de administración SNMP, como el navegador SNMP MIB gratuito de
ManageEngine . Configure la herramienta con los detalles del usuario, como se muestra en la Figura 2.
Cuando se configura un usuario, use las funciones de la herramienta de administración SNMP para probar
que el usuario configurado puede acceder al agente SNMP. En la Figura 3, el administrador de la red
ingresó el OID para la tabla de direcciones IP. La solicitud de obtención devolvió toda la información de
direccionamiento para R1. El administrador de la red se autenticó con las credenciales
adecuadas. Verifique que los datos estén encriptados ejecutando un analizador de protocolos, como
Wireshark, y capture los paquetes SNMP (consulte la Figura 4).

Haga clic aquí para ver la demostración de Keith Barker sobre cómo configurar y verificar SNMPv3.

Protocolo de tiempo de red

Muchas de las cosas relacionadas con la seguridad de una red, como los registros de seguridad, dependen
de una fecha y una marca de tiempo precisas. Los segundos importan cuando se trata de un ataque porque
es importante identificar el orden en el que ocurrió un ataque específico. Asegúrese de que los mensajes
de registro tengan una marca de tiempo precisa manteniendo la sincronización de los relojes en los hosts y
los dispositivos de red.

Por lo general, la configuración de fecha y hora en el enrutador se puede establecer mediante uno de dos
métodos:

 Edite manualmente la fecha y la hora

 Configurar el protocolo de tiempo de red (NTP)

La figura muestra un ejemplo de configuración manual del reloj. A medida que una red crece, resulta
difícil garantizar que todos los dispositivos de infraestructura estén funcionando con tiempo
sincronizado. Incluso en un entorno de red más pequeño, el método manual no es ideal. Si un enrutador se
reinicia, ¿cómo obtendrá una fecha y una marca de tiempo precisas?

Una mejor solución es configurar el NTP en la red. Este protocolo permite a los enrutadores de la red
sincronizar su configuración de hora con un servidor NTP. Un grupo de clientes NTP que obtiene
información de fecha y hora de una sola fuente tiene configuraciones de hora más consistentes. Cuando se
implementa NTP en la red, se puede configurar para sincronizar con un reloj maestro privado o se puede
sincronizar con un servidor NTP disponible públicamente en Internet.

NTP usa el puerto UDP 123 y está documentado en RFC 1305.

Servidor NTP

Al determinar si se debe utilizar un reloj privado para la sincronización o un reloj público, es necesario
sopesar los riesgos y beneficios de ambos.

Si se implementa un reloj maestro privado, el administrador debe asegurarse de que la fuente de tiempo
sea válida y de un sitio seguro. Se pueden introducir vulnerabilidades si el sitio no es seguro. Por ejemplo,
un atacante puede lanzar un ataque DoS enviando datos NTP falsos a través de Internet a la red en un
intento de cambiar los relojes. Este ataque posiblemente podría hacer que los certificados digitales dejen
de ser válidos. Un atacante podría intentar confundir a un administrador de red durante un ataque
interrumpiendo los relojes de los dispositivos de red. Este escenario dificultaría que el administrador de la
red determine el orden de los eventos de syslog en varios dispositivos.
Obtener la hora del reloj de Internet significa que los paquetes no seguros están permitidos a través del
firewall. Muchos servidores NTP en Internet no requieren autenticación de pares. Por lo tanto, el
administrador de la red debe confiar en que el reloj en sí es confiable, válido y seguro.

Las comunicaciones (conocidas como asociaciones) entre máquinas que ejecutan NTP suelen estar
configuradas estáticamente. A cada dispositivo se le asigna la dirección IP de los maestros NTP. Es
posible mantener un tiempo preciso mediante el intercambio de mensajes NTP entre cada par de
máquinas con una asociación.

En una red configurada con NTP, uno o más enrutadores se designan como el encargado del reloj maestro
(también conocido como maestro NTP) mediante el comando del modo de configuración global ntp
master , como se muestra en la Figura 1.

Los clientes NTP se ponen en contacto con el maestro o escuchan los mensajes del maestro para
sincronizar sus relojes. Póngase en contacto con el maestro mediante el comando ntp server ip-address ,
como se muestra en la Figura 2.

En un entorno LAN, NTP se puede configurar para usar mensajes de difusión IP mediante el comando de
modo de configuración de interfaz de cliente de difusión ntp , como se muestra en la Figura 3. Esta
alternativa reduce la complejidad de la configuración porque cada máquina se puede configurar para
enviar o recibir mensajes de difusión. La precisión del cronometraje se reduce marginalmente porque el
flujo de información es unidireccional.

La Figura 4 muestra un ejemplo de topología de servidor NTP y maestro NTP. Las figuras 5 y 6 muestran
las configuraciones necesarias para admitir esa topología en R1 y R2.

Autenticación NTP

La versión 3 de NTP (NTPv3) y posteriores admiten un mecanismo de autenticación criptográfica entre

pares NTP. Este mecanismo de autenticación se puede utilizar para ayudar a mitigar un ataque. Se utilizan
tres comandos en el maestro NTP y el cliente NTP:

 ntp authenticate (Figura 1)

 ntp clave-clave-número -clave md5 clave-valor (Figura 2)

 ntp clave de confianza número de clave (Figura 3)

La Figura 4 muestra una configuración de autenticación NTP de muestra.

Los clientes configurados sin autenticación todavía obtienen la hora del servidor. La diferencia es que
estos clientes no autentican el servidor como fuente segura.

Utilice el comando show ntp association detail , como se muestra en la Figura 5, para confirmar que el
servidor es una fuente autenticada.

Nota : También puede establecer el valor del número de clave como un argumento en el comando ntp
server ntp-server-address .

Utilice Syntax Checker en la Figura 6 para configurar la autenticación NTP en R1.

Protocolos de descubrimiento CDP y LLDP

Los enrutadores Cisco se implementan inicialmente con muchos servicios que están habilitados de forma
predeterminada. Esto se hace por conveniencia y para simplificar el proceso de configuración requerido
para que el dispositivo esté operativo. Sin embargo, algunos de estos servicios pueden hacer que el
dispositivo sea vulnerable a ataques si la seguridad no está habilitada. Los administradores también
pueden habilitar servicios en los enrutadores Cisco que pueden exponer el dispositivo a un riesgo
significativo. Ambos escenarios deben tenerse en cuenta al proteger la red.

El Cisco Discovery Protocol (CDP) es un ejemplo de un servicio que está habilitado de forma
predeterminada en los routers Cisco. El Link Layer Discovery Protocol (LLDP) es un estándar abierto
que se puede habilitar en dispositivos Cisco, así como en otros dispositivos de proveedores que admiten
LLDP. La configuración y verificación de LLDP es similar a CDP. En la Figura 1, R1 y S1 están
configurados con LLDP, utilizando el comando de configuración global lldp run . Ambos dispositivos
ejecutan CDP de forma predeterminada. La salida para mostrar detalles de vecinos cdp y mostrar
detalles de vecinos lldp revelará la dirección de un dispositivo, la plataforma y los detalles del sistema
operativo.

Desafortunadamente, los atacantes no necesitan tener dispositivos habilitados para CDP o LLDP para
recopilar esta información confidencial. Se puede descargar software fácilmente disponible, como Cisco
CDP Monitor que se muestra en la Figura 2, para obtener la información. La intención de CDP y LLDP es
facilitar a los administradores el descubrimiento y la resolución de problemas de otros dispositivos en la
red. Sin embargo, debido a las implicaciones de seguridad, estos protocolos de descubrimiento deben
usarse con precaución. Si bien es una herramienta extremadamente útil, no debería estar en todas partes
de la red. Los dispositivos Edge son un ejemplo de un dispositivo que debería tener esta función
desactivada.

Configuración de protocolos y servicios

Los atacantes eligen servicios y protocolos que hacen que la red sea más vulnerable a la explotación
malintencionada.

Muchas de estas funciones deben desactivarse o restringirse en sus capacidades según las necesidades de
seguridad de una organización. Estas características van desde protocolos de descubrimiento de redes,
como CDP y LLDP, hasta protocolos disponibles globalmente como ICMP y otras herramientas de
escaneo.

Algunas de las configuraciones predeterminadas en el software Cisco IOS están ahí por razones
históricas. Eran configuraciones lógicas predeterminadas en el momento en que se escribió originalmente
el software. Otras configuraciones predeterminadas tienen sentido para la mayoría de los sistemas, pero
pueden crear riesgos de seguridad si se utilizan en dispositivos que forman parte de la defensa del
perímetro de una red. Los estándares exigen otros valores predeterminados, pero no siempre son
deseables desde el punto de vista de la seguridad.

La Figura 1 resume la función y la configuración predeterminada de los protocolos y servicios. La Figura

2 muestra la configuración de seguridad recomendada para protocolos y servicios.

Hay varias prácticas importantes disponibles para ayudar a garantizar que un dispositivo sea seguro:
  Desactive los servicios e interfaces innecesarios.

 Deshabilite y restrinja los servicios de administración configurados comúnmente, como SNMP.

 Deshabilite sondas y exploraciones, como ICMP. Garantizar la seguridad del acceso a la terminal.

 Desactive los protocolos de resolución de direcciones (ARP) gratuitos y proxy.

 Desactive las difusiones dirigidas por IP.

Cisco AutoSecure

Lanzado en la versión 12.3 del IOS, Cisco AutoSecure es una función que se inicia desde la CLI y ejecuta
un script. AutoSecure primero hace recomendaciones para corregir las vulnerabilidades de seguridad y
luego modifica la configuración de seguridad del enrutador, como se muestra en la figura.

AutoSecure puede bloquear las funciones del plano de gestión y los servicios y funciones del plano de
reenvío de un enrutador. Hay varios servicios y funciones del plano de gestión:

 BOOTP seguro, CDP, FTP, TFTP, PAD, UDP y pequeños servidores TCP, MOP, ICMP
(redirecciones, respuestas de máscara), enrutamiento de origen IP, Finger, cifrado de contraseña,
keepalives TCP, ARP gratuito, ARP proxy y transmisión dirigida

 Notificación legal mediante banner

 Funciones seguras de contraseña e inicio de sesión

 NTP seguro

 Acceso SSH seguro

 Servicios de intercepción de TCP

Hay tres servicios y funciones de plano de reenvío que AutoSecure habilita:

 Reenvío expreso de Cisco (CEF)

 Filtrado de tráfico con ACL

 Inspección del firewall de Cisco IOS para protocolos comunes

AutoSecure se utiliza a menudo en el campo para proporcionar una política de seguridad de referencia en
un nuevo enrutador. Luego, las funciones se pueden modificar para respaldar la política de seguridad de
la organización.

Uso de la función Cisco AutoSecure

Utilice el comando auto secure para habilitar la configuración de la función Cisco AutoSecure. Esta
configuración puede ser interactiva o no interactiva. La Figura 1 muestra la sintaxis del comando para
el comando auto seguro . La figura 2 muestra los parámetros del comando. La Figura 3 muestra
descripciones de los parámetros del comando.

En el modo interactivo, el enrutador muestra opciones para habilitar y deshabilitar servicios y otras
funciones de seguridad. Este es el modo predeterminado, pero también se puede configurar mediante
el comando auto seguro completo .

El modo no interactivo se configura con el comando auto secure no-interact . Esto ejecutará

automáticamente la función Cisco AutoSecure con la configuración predeterminada recomendada de
Cisco. El comando de seguridad automática también se puede ingresar con palabras clave para
configurar componentes específicos, como el plano de administración ( palabra clave
de administración ) y el plano de reenvío ( palabra clave de reenvío ).

Usando el comando auto seguro

Cuando se inicia el comando de seguridad automática , un asistente de CLI guía al administrador a

través de la configuración del dispositivo. Se requiere la entrada del usuario.

1. Se ingresa el comando de seguridad automática . El enrutador muestra el mensaje de bienvenida del

asistente de configuración de AutoSecure, como se muestra en la Figura 1.

2. El asistente recopila información sobre las interfaces externas, como se muestra en la Figura 2.

3. AutoSecure protege el plano de administración al deshabilitar los servicios innecesarios, como se

muestra en la Figura 3.

4. AutoSecure solicita un banner, como se muestra en la Figura 4.

5. AutoSecure solicita contraseñas y habilita las funciones de contraseña e inicio de sesión, como se
muestra en la Figura 5.

6. Las interfaces están protegidas, como se muestra en la Figura 6.

7. El plano de reenvío está asegurado, como se muestra en la Figura 7.

Cuando se completa el asistente, una configuración en ejecución muestra todos los ajustes y cambios de
configuración.

Nota : AutoSecure debe usarse cuando se configura inicialmente un enrutador. No se recomienda en

enrutadores de producción.

Use Syntax Checker en la Figura 8 para asegurar R1 usando AutoSecure.

Suplantación de protocolos de enrutamiento

Los sistemas de enrutamiento pueden ser atacados interrumpiendo los enrutadores de la red de pares o
falsificando o falsificando la información contenida en los protocolos de enrutamiento. La información de
enrutamiento de suplantación generalmente se puede usar para hacer que los sistemas se desinforman
(mienten) entre sí, provocan un ataque DoS o hacen que el tráfico siga una ruta que normalmente no
seguiría. Hay varias consecuencias de la suplantación de la información de enrutamiento:

 Redirigir el tráfico para crear bucles de enrutamiento

 Redirigir el tráfico para que se pueda monitorear en un enlace inseguro

 Redirigir el tráfico para descartarlo

Haga clic en el botón Reproducir en la animación para ver un ejemplo de un ataque que crea un bucle de
enrutamiento.

Suponga que un atacante ha podido conectarse directamente al enlace entre R1 y R2. El atacante envía
información de enrutamiento falsa de R1 que indica que R2 es el destino preferido a la red
192.168.10.0/24. Aunque el R1 ya tiene una entrada en la tabla de enrutamiento para la red
192.168.10.0/24, la nueva ruta tiene una métrica más baja y, por lo tanto, es la entrada preferida en la
tabla de enrutamiento.

En consecuencia, cuando la PC3 envía un paquete a la PC1 (192.168.10.10/24), R3 reenvía el paquete a

R2, que a su vez lo reenvía a R1. R1 no reenvía el paquete al host PC1. En cambio, enruta el paquete a R2
porque la mejor ruta aparente a 192.168.10.0 / 24 es a través de R2. Cuando R2 obtiene el paquete, busca
en su tabla de enrutamiento y encuentra una ruta legítima a la red 192.168.10.0/24 a través de R1 y
reenvía el paquete de regreso a R1, creando el bucle. El bucle fue causado por la desinformación
inyectada en R1.

Para obtener más información sobre las amenazas genéricas a los protocolos de enrutamiento, haga
clic aquí (https://www.ietf.org/rfc/rfc4593.txt) Autenticación del protocolo de enrutamiento OSPF
MD5

OSPF admite la autenticación del protocolo de enrutamiento mediante MD5. La autenticación MD5 se
puede habilitar globalmente para todas las interfaces o por interfaz.

Habilite la autenticación OSPF MD5 a nivel mundial:

 ip ospf message-digest-key key comando de configuración de interfaz de contraseña md5 .

 area area-id authentication message-digest comando de configuración del enrutador.

Este método fuerza la autenticación en todas las interfaces habilitadas para OSPF. Si una interfaz no está
configurada con el comando ip ospf message-digest-key , no podrá formar adyacencias con otros
vecinos OSPF.

Habilite la autenticación MD5 por interfaz:

 ip ospf message-digest-key key comando de configuración de interfaz de contraseña md5 .

 Comando de configuración de la interfaz ip ospf authentication message-digest .

La configuración de la interfaz anula la configuración global. Las contraseñas de autenticación MD5 no
tienen que ser las mismas en un área. Sin embargo, deben ser iguales entre vecinos.

En la Figura 1, R1 y R2 están configurados con OSPF y el enrutamiento funciona correctamente. Sin

embargo, los mensajes OSPF no están autenticados ni cifrados. En la Figura 2, R1 y R2 están
configurados con autenticación OSPF MD5. La autenticación se configura por interfaz porque ambos
enrutadores usan solo una interfaz para formar adyacencias OSPF. Observe que cuando se configura R1,
la adyacencia OSPF se pierde con R2 hasta que R2 se configura con la autenticación MD5
correspondiente.

Autenticación del protocolo de enrutamiento OSPF SHA

MD5 ahora se considera vulnerable a los ataques y solo debe usarse cuando no está disponible una
autenticación más sólida. La versión 15.4 (1) T de Cisco IOS agregó soporte para la autenticación OSPF
SHA, como se detalla en RFC 5709. Por lo tanto, el administrador debe usar la autenticación SHA
siempre que todos los sistemas operativos del router admitan la autenticación OSPF SHA.

La autenticación OSPF SHA incluye dos pasos principales. La sintaxis de los comandos se muestra en la
Figura 1:

Paso 1. Especifique una cadena de claves de autenticación en el modo de configuración global:

 Configure un nombre de cadena de claves con el comando de cadena de claves .

 Asignar el llavero de un número y una contraseña con la clave y la clave de cadena

de comandos.

 Especifique la autenticación SHA con el comando algoritmo criptográfico .

 (Opcional) Especifique cuándo caducará esta clave con el comando send-lifes .

Paso 2. Asigne la clave de autenticación a las interfaces deseadas con el comando ip ospf authentication
key-chain .

En la Figura 2, R1 y R2 están configurados con autenticación OSPF SHA usando una clave llamada
SHA256 y la cadena de clave ospfSHA256. Observe que cuando se configura R1, la adyacencia OSPF se
pierde con R2 hasta que R2 se configura con la autenticación SHA correspondiente.

Use Syntax Checker en la Figura 3 para configurar la autenticación OSPF usando SHA 256.

Operaciones de dispositivos de red

Si bien la función principal de los enrutadores es reenviar contenido generado por el usuario a través del
plano de datos, los enrutadores también generan y reciben tráfico destinado a los planos de control y
gestión. Por lo tanto, los enrutadores deben poder distinguir entre el plano de datos, el plano de control y
los paquetes del plano de gestión para tratar cada paquete de forma adecuada, como se muestra en la
figura.
  Paquetes del plano de datos: paquetes generados por el usuario que los dispositivos de red
siempre reenvían a otros dispositivos de la estación final. Desde la perspectiva del dispositivo de
red, los paquetes del plano de datos siempre tienen una dirección IP de destino de tránsito y pueden
ser manejados por procesos de reenvío basados en direcciones IP de destino normales.

 Paquetes del plano de control : dispositivos de red generados o recibidos paquetes que se
utilizan para la creación y operación de la red. Los ejemplos incluyen protocolos, como OSPF, ARP,
Border Gateway Protocol (BGP) y otros protocolos que mantienen la red convergente y funcionando
correctamente. Los paquetes del plano de control son generalmente paquetes enviados al enrutador o
dispositivo de red. La dirección IP de destino es la del enrutador.

 Paquetes del plano de administración : dispositivos de red generados o recibidos paquetes que
se utilizan para administrar la red. Los ejemplos incluyen protocolos, como Telnet, SSH, SNMP,
NTP y otros protocolos utilizados para administrar el dispositivo o la red.

En condiciones normales de funcionamiento de la red, la gran mayoría de los paquetes que manejan los
dispositivos de red son paquetes de plano de datos. Estos paquetes son manejados por Cisco Express
Forwarding (CEF). CEF utiliza el plano de control para rellenar previamente la tabla Base de información
de reenvío (FIB) de CEF en el plano de datos con la interfaz de salida adecuada para un flujo de paquetes
determinado. Los paquetes posteriores que fluyen entre ese mismo origen y destino son reenviados por el
plano de datos en base a la información contenida en la FIB.

Vulnerabilidades del plano de control y gestión

El procesador del enrutador (la CPU en el plano de control) es significativamente menos capaz de
manejar los tipos de velocidades de paquetes que experimenta CEF y, por lo tanto, nunca participa
directamente en el reenvío de los paquetes del plano de datos.

Por el contrario, cuando las altas velocidades de paquetes sobrecargan el plano de control o gestión, los
recursos del procesador de ruta pueden verse abrumados. Esto reduce la disponibilidad de estos recursos
para tareas críticas para la operación y mantenimiento de la red. Los eventos maliciosos y no maliciosos
pueden abrumar los recursos del procesador de ruta. Los eventos maliciosos incluyen ataques de paquetes
diseñados o simplemente altas tasas de paquetes dirigidos al plano de control. Los eventos no maliciosos
pueden ser el resultado de configuraciones incorrectas de enrutadores o redes, errores de software o
eventos de convergencia de fallas de red. Es importante tomar las medidas adecuadas para evitar que el
procesador de ruta se vea abrumado, ya sea por eventos maliciosos o no maliciosos.

Una interfaz ACL es el enfoque tradicional y más generalmente disponible para administrar todos los
paquetes que entran o salen de un dispositivo de red. Las ACL se comprenden bien y, en general, se
aplican a los paquetes del plano de datos, servicios, control y gestión. Como se muestra en la figura, las
ACL se aplican en el nivel de la interfaz a cada paquete que ingresa (o sale) a la interfaz, no solo a los
paquetes del plano de control. Además, las ACL deben aplicarse a todas las interfaces a las que se
aplicará la política. En enrutadores de gran tamaño, esta tarea puede llevar mucho tiempo.

y consulte RFC 4593. Mitigue los ataques al protocolo de enrutamiento configurando la autenticación
OSPF.

para abrir Cisco SNMP Object Navigator.

Operación CoPP

Control Plane Policing (CoPP) es una función de Cisco IOS diseñada para permitir a los administradores
administrar el flujo de tráfico que se envía al procesador de ruta, como se muestra en la figura. Cisco
define el término "despeje" para describir la acción que realiza una interfaz cuando envía un paquete al
procesador de ruta. CoPP está diseñado para evitar que el tráfico innecesario abrume al procesador de ruta
que, si no se reduce, podría afectar el rendimiento del sistema.

CoPP protege el procesador de ruta en los dispositivos de red al tratar los recursos del procesador de ruta
como una entidad separada con su propia interfaz. En consecuencia, una política CoPP se puede
desarrollar y aplicar solo a aquellos paquetes dentro del plano de control. A diferencia de las ACL de
interfaz, no se desperdicia ningún esfuerzo investigando paquetes del plano de datos que nunca llegarán al
plano de control.

La configuración de CoPP está más allá del alcance de este curso.

Demostración en video: protección del enrutador

Este video muestra cómo proteger los enrutadores completando lo siguiente:

 Configurar un servidor maestro NTP y clientes

 Configurar la autenticación NTP

 Habilitar la autenticación OSPF

 Cifre todas las contraseñas

 Requerir contraseñas de longitud mínima

 Crea cuentas de usuario con contraseñas seguras

 Registrar mensajes en un servidor syslog

 Configurar SSH

 Asegure la imagen de arranque

 Cree una configuración de respaldo segura

 Utilice el comando autosecure

Haga clic aquí (https://static-course-assets.s3.amazonaws.com/CCNAS2/en/course/files/Securing

%20Network%20Devices.pdf) Práctica de laboratorio: Protección del enrutador para acceso
administrativo

En este laboratorio, completará los siguientes objetivos:

  Configure los ajustes básicos del dispositivo.

 Controle el acceso administrativo para los enrutadores.

 Configure roles administrativos.

 Configure los informes de administración y resistencia de Cisco IOS.

 Configure las funciones de seguridad automatizadas.

Práctica de laboratorio: Protección del enrutador para acceso administrativo

https://static-course-assets.s3.amazonaws.com/CCNAS2/en/course/files/2.6.1.2%20Lab%20-
%20Securing%20the%20Router%20for%20Administrative%20Access.pdf

Packet Tracer: configure los routers Cisco para operaciones Syslog, NTP y SSH

En este Packet Tracer, completará los siguientes objetivos:

 Configure los enrutadores como clientes NTP.

 Configure los enrutadores para actualizar el reloj del hardware mediante NTP.

 Configure los enrutadores para registrar mensajes en el servidor syslog.

 Configure enrutadores para marcar los mensajes de registro de fecha y hora.

 Configure los usuarios locales.

 Configure las líneas VTY para aceptar solo conexiones SSH.

 Configure el par de claves RSA en el servidor SSH.

 Verifique la conectividad SSH desde el cliente de la PC y el cliente del enrutador.

Packet Tracer: configuración de enrutadores Cisco para operaciones Syslog, NTP y SSH: instrucciones

Packet Tracer: configuración de enrutadores Cisco para operaciones Syslog, NTP y SSH: PKA

https://static-course-assets.s3.amazonaws.com/CCNAS2/en/course/files/2.6.1.2%20Lab%20-
%20Securing%20the%20Router%20for%20Administrative%20Access.pdfCapítulo 2: Protección
de dispositivos de red

Al proteger una red, el endurecimiento del dispositivo debe ser el primer paso. Esto incluye proteger el
perímetro de la red, asegurar el acceso administrativo a los dispositivos de la infraestructura, mejorar la
seguridad de inicio de sesión virtual y usar protocolos seguros sobre un protocolo no seguro. Por ejemplo,
usar SSH en lugar de Telnet o HTTPS en lugar de HTTP.
Limitar el acceso administrativo también es importante. Los administradores deben proporcionar acceso a
los dispositivos de la infraestructura según los niveles de privilegios e implementar una CLI basada en
roles para proporcionar acceso administrativo jerárquico.

Las imágenes de IOS y los archivos de configuración deben protegerse mediante la función de
configuración resistente de Cisco IOS. Se debe implementar el monitoreo de la red, incluida la
configuración de Syslog, SNMP y NTP.

En resumen, los administradores deben identificar todos los servicios, interfaces y servicios de
administración que son vulnerables a los ataques a la red. Esto se logra mediante la realización rutinaria
de auditorías de seguridad. Los administradores deben utilizar el comando de seguridad automática de
la CLI de Cisco IOS antes de implementar nuevos dispositivos en un entorno de producción. Se debe
implementar la autenticación del protocolo de enrutamiento para proteger el plano de control de la
suplantación del protocolo de enrutamiento.