Este documento describe varias configuraciones de seguridad mejoradas para autenticación virtual, incluyendo la habilitación de retardos entre intentos de ingreso, el cierre de sesiones ante ataques de denegación de servicio, la generación de registros de sesiones, y la asignación de contraseñas y autenticación local. También cubre temas como la configuración de SSH, los niveles de privilegio de acceso, y la administración y monitoreo seguros de dispositivos de red.

1. Configuracion de seguridad mejorada
para autenticación virtual
• Asignar contraseñas y autenticación local no evita que un
dispositivo pueda ser objetivo de un ataque
• login blocking - quiet period (tiempo silencioso) – ACL
• Si el dispositivo lo permite el proceso de autenticación
deberá ser configurado con parámetros específicos:
• Retardos entre intentos de ingreso sucesivos
• Cierre de sesión si se sospechan ataques de DoS
• Generación de mensajes de registro del sistema para detección de
sesiones
• Estas mejoras no se aplican a las conexiones de consola.
Se asume que solo el personal autorizado tendrá acceso
físico a los dispositivos.

2. Comandos
• Router# configure terminal
• Router(config)# login block-for segundos attempts
intentos within segundos
• Router(config)# login quiet-mode access-class {acl-
nombre | acl-número}
• Router(config)# login delay segundos
• Router(config)# login on-failure log [every login]
• Router(config)# login on-success log [every login]

3. • La autenticación en las líneas vty debe ser configurada
para usar una combinación de nombre de usuario y
contraseña.
• Si se configuran las líneas para usar solo una contraseña,
no se habilitarán las funciones de ingreso mejoradas

5. • Por defecto, todas las funciones de ingreso mejoradas
están deshabilitadas.
• login block-for las habilita.
• login block-for monitorea la actividad de inicio de sesión
en el dispositivo y opera en dos modos:
• Modo normal (de vigilancia) - El router cuenta la cantidad de
intentos de ingresofallidos dentro de una cantidad de tiempo
determinada.
• Modo silencioso (período silencioso) - Si el número de ingresos
fallidos sobrepasa el umbral configurado, todos los intentos de
ingreso de Telnet, SSH y HTTP serán denegados.

6. • Cuando se habilita el modo silencioso, no se permite
ningún intento de ingreso, incluso el acceso
administrativo válido.
• Este comportamiento puede esquivarse para
proporcionar acceso a los hosts críticos en todo momento
mediante el uso de una ACL.
• La ACL debe ser creada e identificada usando el
comando login quiet-mode access-class.
• El comando login delay introduce un retraso uniforme
entre intentos sucesivos de ingreso.
• El retraso ocurre en todos los intentos de ingreso, tanto
fallidos como exitosos

7. • El comando auto secure habilita el registro de mensajes
para intentos fallidos de ingreso.
• El registro de intentos de ingreso exitosos no está
habilitado por defecto.
• Estos comandos pueden ser utilizados para mantener un
registro del número de intentos de ingreso exitosos y
fallidos.
• login on-failure log [every login] genera registros para las
solicitudes de ingreso fallidas.
• login on-success log [every login] genera mensajes en el
registro para las solicitudes de ingreso exitosas.

8. • El número de intentos de ingreso antes de que se genere
un mensaje puede especificarse mediante el parámetro
[every login]. El valor por defecto es 1. El rángo válido va
de 1 a 65,535.
• El comando show login failures muestra más información
en relación a los intentos fallidos, como la dirección IP de
la que se originó el intento de ingreso fallido

9. • Use mensajes banner para presentar una notificación
legal a los potenciales intrusos para informarles que no
son bienvenidos en esa red.
• Los banners son muy importantes para la red desde una
perspectiva legal.
• Pueden ser utilizados para informar a administradores
remotos de las restricciones de uso.
• La elección del contenido de los mensajes banner es
importante y debe ser revisada por un asesor legal antes
de colocarse en routers de red.
• Nunca use la palabra "bienvenido" o algún otro saludo
familiar que puede ser sacado de contexto o entendido
como una invitación para usar la red.

10. • banner {exec | incoming | login | motd | slip-ppp} d
message d
• Los tokens son opcionales y pueden ser utilizados en la
sección del mensaje del comando banner:
• $(hostname) - Muestra el nombre de host del router.
• $(domain) - Muestra el nombre de dominio del router.
• $(line) - Muestra los números de línea vty o tty
(asíncrona).
• $(line-desc) - Muestra la descripción de la línea.
• Tenga cuidado al colocar esta información en el router, ya
que provee más información a un potencial intruso

11. Configuración de SSH
• Paso 1. Asegurarse de que los routers destino estén
ejecutando una imagen del IOS de Cisco release 12.1(1)T
o posterior, para que soporten SSH.
• Solo las imágenes criptográficas del IOS de Cisco que
contienen el grupo de funciones IPsec soportan SSH.
Específicamente, las imágenes criptográficas del IOS de
Cisco 12.1 o la posterior IPsec DES o el Triple Data
Encryption Standard (3DES) soportan SSH.
• Estas imágenes generalmente tienen el ID k8 o k9 en su
nombre de imagen. Por ejemplo, c1841-advipservicesk9-
mz.124-10b.bin es una imagen que soporta SSH.

12. • Paso 2. Asegurarse de que cada uno de los routers
destino tenga un nombre de host único.
• Paso 3. Asegurarse de que cada router destino esté
usando el nombre de dominio correcto para la red.
• Paso 4. Asegurarse de que los routers destino estén
configurados para autenticación local o servicios AAA
para autenticación de usuario y contraseña. Esto es
obligatorio para una conexión SSH de router a router

13. CLI
• Paso 1. Si el router tiene un nombre de host único, configure el
nombre de dominio IP de la red usando el comando ip domain-name
nombre-dominio en el modo de configuración global.
• Paso 2. Deben generarse las claves secretas de una sola vía para
que un router cifre el tráfico SSH. Estas claves se denominan claves
asimétricas. El software IOS de Cisco usa el algoritmo Rivest,
Shamir, and Adleman (RSA) para generar claves. Para crear la clave
RSA, use el comando crypto key generate rsa general-keys módulo
modulus-size en el modo de configuración global. El módulo
determina el tamaño de la clave RSA y puede ser configurado de 360
bits a 2048 bits. Cuanto más grande sea el módulo, más segura será
la clave RSA. Sin embargo, las claves con valores de módulo
grandes toman más tiempo para ser generadas y para cifrarse y
descifrarse. La longitud mínima de clave módulo recomendada es de
1024 bits. Para verificar el SSH y mostrar las claves generadas, use
el comando show crypto key mypubkey rsa en modo EXEC
privilegiado. Si hay pares de claves existentes, se recomienda que
sean sobreescritos usando el comando crypto key zeroize rsa.

14. • Paso 3. Asegúrese de que haya una entrada de nombre
de usuario válida en la base de datos local. Si no la hay,
cree una usando el comando username nombre secret
contraseña.
• Paso 4. Habilite sesiones SSH vty de entrada usando los
comandos de línea vty login local y transport input ssh.
SSH se habilita automáticamente luego de que se
generan las claves RSA. Puede accederse al servicio
SSH del router usando software de cliente SSH.

16. Comandos SSH opcionales
• Versión SSH
• Período de vencimiento de sesión SSH
• Número de reintentos de autenticación

18. Asignación de roles administrativos.
Configuración de niveles de privilegios
• ¿debe proporcionarse acceso sin restricciones a todos
los empleados de una empresa?
• ¿Habrá que dar acceso sin restricciones a todos los
empleados del departamento de Informática?
• Los niveles de privilegio determinan a quién le será
permitido conectarse al dispositivo y qué podrá hacer una
vez que se conecte.
• La CLI del software IOS de Cisco tiene dos niveles de
acceso a los comandos

19. • El modo de usuario EXEC (nivel 1 de privilegios) -
Proporciona los privilegios más básicos al usuario del
modo EXEC y le permite solo comandos de nivel de
usuario con el promptrouter>.
• El modo EXEC privilegiado (nivel 15 de privilegios) -
Incluye todos los comandos de nivel enable con el prompt
router# .
• Aunque estos dos niveles proporcionan control, algunas
veces se necesita un nivel de control más preciso.
• El software IOS de Cisco tiene dos métodos para proveer
acceso a la infraestructura: nivel de privilegios y CLI
basada en roles.

20. Asignación de niveles de privilegios
• Router(config)# privilege modo {level nivel de comando |
reset} comando

23. • Los comandos específicamente asociados a un nivel de
privilegios superior nunca están disponibles para usuarios de
niveles de privilegio inferiores.
• Asignar un comando con múltiples palabras clave a un nivel
específico de privilegios también asigna todos los comandos
asociados con las primeras palabras clave del mismo nivel de
privilegios. Un ejemplo es el comando show ip route.
• Sin embargo, la mayor limitación es que si un administrador
necesita crear una cuenta que tenga acceso a la mayoría de,
aunque no todos, los comandos, deben configurarse
sentencias privilege exec para cada comando que debe ser
ejecutado en un nivel de privilegios inferior al 15.
• Este puede ser un proceso bastante tedioso.

24. Configuración de acceso a la CLI basado
en roles
• El acceso a la CLI basado en roles permite al
administrador de la red crear diferentes vistas de las
configuraciones del router para diferentes usuarios. Cada
vista define los comandos CLI a los que cada usuario
tiene acceso
• Seguridad
• El acceso a la CLI basado en roles mejora la seguridad del
dispositivo, ya que define el grupo de comandos de la CLI que es
accesible para un usuario particular.
• Los administradores pueden controlar el acceso del usuario a
puertos, interfaces lógicas y ranuras específicas en un router.
• Esto detiene al usuario de cambiar la configuración o recolectar
información a la que no debería tener acceso.

25. • Disponibilidad
• El acceso a la CLI basado en roles imposibilita la ejecución no
intencional de comandos de CLI por parte de personal no
autorizado, lo que podría dar resultados no deseados.
• Esto minimiza el período de inactividad.
• Eficiencia operativa
• Los usuarios solo ven los comandos de la CLI que son aplicables a
los puertos y la CLI a los que tienen acceso; por lo tanto, el router
parece menos complejo y los comandos son de más fácil
identificación cuando se usa la función de ayuda en el dispositivo.

26. • La CLI basada en roles proporciona tres tipos de vistas:
• Vista de root :
• Para configurar cualquier vista en el sistema, el administrador debe
estar en la vista de root.
• La vista de root tiene los mismos privilegios de acceso que un usuario
con nivel 15 de privilegios. Sin embargo, una vista de root no es lo
mismo que un usuario de nivel 15.
• Solo un usuario de vista de root puede configurar una nueva vista y
agregar o remover comandos de las vistas existentes.

27. • Vista de CLI
• Puede asociarse un grupo específico de comandos a una vista CLI.
• A diferencia de los niveles de privilegios, la vista CLI no tiene jerarquías
de comandos y, por lo tanto, no hay vistas superiores o inferiores.
• Deben asignarse todos los comandos asociados con cada vista, y las
vistas no heredan comandos de otras vistas.
• Adicionalmente, los mismos comandos pueden ser utilizados en varias
vistas.
• Supervista
• Consiste en una o más vistas CLI.
• Los administradores pueden definir qué comandos son aceptados y qué
información de configuración es visible.
• Las supervistas permiten al administrador de redes asignar a los
usuarios y grupos de usuarios múltiples vistas CLI de una sola vez, en
lugar de tener que asignar una sola vista CLI por usuario con todos los
comandos asociados a esa única vista CLI.

28. Características de las supervistas
• Una sola vista CLI puede ser compartida entre varias
supervistas.
• No pueden configurarse comandos para una supervista.
• El administrador debe agregar comandos a la vista CLI y
luego agregar esa vista CLI a la supervista.
• Los usuarios que están autenticados en una supervista
pueden acceder a todos los comandos que están
configurados para cualquiera de las vistas CLI que son
parte de la supervista.

29. • Cada supervista tiene una contraseña que se usa para
moverse 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.

32. • Antes de que un administrador pueda crear una vista,
debe habilitarse AAA con el comando aaa new-model o
• Para configurar y editar las vistas, el administrador debe
ingresar a la vista de root usando el comando de EXEC
privilegiado enable view . Tambien puede usarse el
comando enable view root. Ingrese la contraseña enable
secret cuando se la pida.

33. Pasos para crear y administrar una vista
específica.
• Paso 1.
• Habilitar AAA con el comando de configuración global aaa new-model.
• Salga e ingrese a la vista de root con el comando enable view.
• Paso 2.
• Cree una vista usando el comando parser view nombre-vista. Esto habilita el
modo de configuración de la vista.
• Excluyendo la vista de root, hay un límite máximo de 15 vistas en total.
• Paso 3.
• Asigne una contraseña secret a la vista usando el comando secret
contraseñacifrada.
• Paso 4.
• Asigne comandos a la vista seleccionada usando el comando commands
parsermode {include | include-exclusive | exclude} [all] [interface nombre-
interfaz | comando] en el modo de configuración de vista.
• Paso 5.
• Salga del modo de configuración de la vista emitiendo el comando exit.

34. • Los pasos para configurar una supervista son
esencialmente los mismos que para configurar una vista
CLI, excepto que en lugar de usar el comando commands
para asignar comandos, debe usarse el comando view
nombre-vista para asignar vistas.
• El administrador debe estar en la vista de root para
configurar una supervista. Para confirmar que se está
usando la vista de root, use el comando enable view o el
comando enable view root.
• Ingrese la contraseña enable secret cuando se la solicite.

35. Monitoreo y administración de
dispositivos

41. Administración y reportes seguros

42. • Fuera de banda (out-of-band - OOB) - Flujos de
información en una red de administración dedicada en los
cuales no reside tráfico de producción.
• En banda (in-band) - Flujos de información que
atraviesan la red de producción de la empresa, Internet o
ambos a través de canales de datos comunes.