¿Necesito establecer el secreto de habilitación en el dispositivo Cisco?

Estoy configurando un enrutador Cisco 2901. Tengo una contraseña de inicio de sesión en la línea de la consola, y las líneas vty están configuradas para aceptar solo conexiones ssh con autenticación de clave pública. La línea auxiliar está cerrada. Solo hay dos administradores que accederán al enrutador y ambos estamos autorizados a realizar cualquier configuración en el enrutador.

No soy un experto en equipos Cisco, pero considero que esto es adecuado para asegurar el acceso a la configuración del enrutador. Sin embargo, en cada guía que he leído, debo establecer un secreto de habilitación, independientemente de cualquier otra contraseña de usuario o línea.

¿Hay algo más en la contraseña de habilitación que no sepa? ¿Hay alguna otra forma de acceder al enrutador que no sean las líneas de consola, auxiliar o vty?

EDITAR: He agregado la configuración real a continuación para ser más claro sobre mi situación. Lo siguiente funciona, al requerir una contraseña de habilitación, o una usernameconfiguración aparte de la que está dentro ip ssh pubkey-chain.

aaa new-model

ip ssh time-out 60
ip ssh authentication-retries 2
ip ssh version 2
ip ssh pubkey-chain
 username tech
  key-hash ssh-rsa [HASH]
ip scp server enable

line vty 0 4
 transport input ssh

No, no lo haces, técnicamente. Pero si puede ingresar al modo de habilitación sin uno depende de cómo inicie sesión.

Aquí está la versión de gratificación instantánea:

Puede ingresar a través de la consola sin una contraseña de habilitación, pero se quedará atascado en el modo de usuario si usa una contraseña de inicio de sesión vty simple sin un conjunto de contraseña de habilitación.

Aquí está la versión ansiosa de StackExchange:

La autenticación de Cisco es un desastre para un principiante. Hay mucho equipaje heredado allí. Permítanme tratar de analizar esto en un sentido del mundo real.

Todos los que tienen un inicio de sesión empresarial en un enrutador o conmutador van directamente al modo privilegiado (habilitar). El modo de usuario es básicamente un lobby frontal, y tiene poco más propósito que mantener el borrador fuera. En las grandes organizaciones donde tiene grandes redes y grupos de trabajo igualmente vastos, puede ser justificable tener a alguien que pueda llamar a la puerta principal y asegurarse de que alguien todavía esté allí. (Es decir, iniciar sesión y ejecutar los comandos más triviales solo para ver que el dispositivo, de hecho, responde y no está en llamas). Pero en todos los entornos en los que he trabajado, el nivel 1 tenía al menos alguna capacidad para romper cosas.

Como tal, y particularmente en un escenario como el suyo, conocer la contraseña de habilitación es obligatorio para hacer cualquier cosa. Se podría decir que este es un segundo nivel de seguridad: una contraseña para ingresar al dispositivo, otra para escalar a privilegios administrativos, pero eso me parece un poco tonto.

Como ya se señaló, puede (y muchas personas lo hacen) usar la misma contraseña, lo que no ayuda mucho si alguien ha obtenido acceso no autorizado a través de telnet / ssh. Tener contraseñas estáticas y globales compartidas por todos es posiblemente más problemático que tener solo un token requerido para ingresar. Finalmente, la mayoría de los otros sistemas (servicios, dispositivos, etc.) no requieren una segunda capa de autenticación, y generalmente no se consideran inseguros debido a esto.

OK, esa es mi opinión sobre el tema. Tendrá que decidir por sí mismo si tiene sentido a la luz de su propia postura de seguridad. Vamos a ir al grano.

Cisco (sabiamente) requiere que establezca una contraseña de acceso remoto de forma predeterminada. Cuando ingresa al modo de configuración de línea ...

router> enable
router# configure terminal
router(config)# line vty 0 15
router(config-line)#

... puede decirle al enrutador que omita la autenticación:

router(config-line)# no login

... y rápidamente hackeado, pero su atacante terminará en modo de usuario. Entonces, si tiene configurada una contraseña de habilitación, al menos tiene algo limitado el daño que se puede hacer. (Técnicamente, tampoco puedes seguir adelante sin una contraseña de habilitación. Más sobre eso en un momento ...)

Naturalmente, nadie haría esto en la vida real. Su requisito mínimo, por defecto y por sentido común, es establecer una contraseña simple:

router(config-line)# login
router(config-line)# password cisco

Ahora, se le pedirá una contraseña y volverá a terminar en modo de usuario. Si enableingresa a través de la consola, puede escribir para obtener acceso sin tener que ingresar otra contraseña. Pero las cosas son diferentes a través de telnet, donde probablemente obtendrá esto en su lugar:

$ telnet 10.1.1.1
Trying 10.1.1.1...
Connected to 10.1.1.1.
Escape character is '^]'.


User Access Verification

Password: *****
router> enable
% No password set
router> 

Continuando ... Probablemente ya sepa que, por defecto, todas sus contraseñas configuradas se muestran como texto sin formato:

router# show run | inc password
no service password-encryption
 password cisco

Esta es una de esas cosas que tensa el esfínter de los conscientes de la seguridad. Si se trata de ansiedad justificada, es algo que debe decidir usted mismo. Por un lado, si tiene acceso suficiente para ver la configuración, probablemente tenga acceso suficiente para cambiar la configuración. Por otro lado, si por casualidad le has revelado tu configuración a alguien que no tiene los medios, entonces ... bueno, ahora sí tienen los medios.

Afortunadamente, esa primera línea en el fragmento de arriba no service password-encryptiones la clave para cambiar eso:

router(config)# service password-encryption
router(config)# line vty 0 15
router(config-line)# password cisco

Ahora, cuando miras la configuración, ves esto:

router(config-line)# do show run | begin line vty
line vty 0 4
 password 7 01100F175804
 login
line vty 5 15
 password 7 01100F175804
 login
!
!
end

Esto es marginalmente mejor que las contraseñas de texto sin formato, porque la cadena que se muestra no es lo suficientemente memorable como para navegar por los hombros. Sin embargo, es trivial descifrar, y uso ese término libremente aquí. Literalmente, puede pegar esa cadena arriba en una de una docena de crackers de contraseñas de JavaScript en la primera página de resultados de Google, y recuperar el texto original de inmediato.

Estas llamadas contraseñas "7" se consideran comúnmente "ofuscadas" en lugar de "cifradas" para resaltar el hecho de que es apenas mejor que nada.

Sin embargo, resulta que todos esos passwordcomandos están en desuso. (O si no lo son, deberían serlo). Es por eso que tiene las siguientes dos opciones:

router(config)# enable password PlainText
router(config)# enable secret Encrypted
router(config)# do show run | inc enable
enable secret 5 $1$sIwN$Vl980eEefD4mCyH7NLAHcl
enable password PlainText

La versión secreta está codificada con un algoritmo unidireccional, lo que significa que la única forma de recuperar el texto original es mediante fuerza bruta, es decir, probando todas las cadenas de entrada posibles hasta que genere el hash conocido.

Cuando ingresa la contraseña cuando se le solicita, pasa por el mismo algoritmo de hash y, por lo tanto, debe terminar generando el mismo hash, que luego se compara con el del archivo de configuración. Si coinciden, se acepta su contraseña. De esa forma, el enrutador no conoce el texto sin formato, excepto durante el breve momento en que crea o ingresa la contraseña. Nota: Siempre existe la posibilidad de que alguna otra entrada pueda generar el mismo hash, pero estadísticamente es una probabilidad muy baja (léase: insignificante).

Si tuviera que usar la configuración anterior usted mismo, el enrutador permitirá que existan las líneas enable passwordy enable secret, pero el secreto se obtiene de la solicitud de contraseña. Este es uno de esos ismos de Cisco que no tiene mucho sentido, pero es así. Además, no hay secretun comando equivalente desde el modo de configuración de línea, por lo que está atascado con contraseñas ofuscadas allí.

Bien, ahora tenemos una contraseña que no se puede recuperar (fácilmente) del archivo de configuración, pero todavía hay un problema. Se transmite en texto sin formato cuando inicia sesión a través de telnet. No es bueno. Queremos SSH.

SSH, diseñado con una seguridad más sólida en mente, requiere un poco de trabajo extra, y una imagen IOS con un cierto conjunto de características. Una gran diferencia es que una contraseña simple ya no es lo suficientemente buena. Necesita graduarse para la autenticación basada en el usuario. Y mientras lo hace, configure un par de claves de cifrado:

router(config)# username admin privilege 15 secret EncryptedPassword
router(config)# line vty 0 15
router(config-line)# transport input ssh
router(config-line)# no password
router(config-line)# login local
router(config-line)# exit
router(config)# ip ssh version 2
router(config)# crypto key generate rsa modulus 1024

¡Ahora estás cocinando con gas! Observe que este comando usa secretcontraseñas. (Sí, puedes, pero no deberías, usar password). La privilege 15parte le permite omitir el modo de usuario por completo. Cuando inicia sesión, pasa directamente al modo privilegiado:

$ ssh [email protected]
Password: *****

router#

En este escenario, no es necesario usar una contraseña de habilitación (o secreto).

Si aún no está pensando, "wow ... qué confusión fue eso ", tenga en cuenta que hay otra publicación de largo aliento todavía al acecho detrás del comando aaa new-model, donde puede sumergirse en cosas como servidores de autenticación externos (RADIUS , TACACS +, LDAP, etc.), listas de autenticación (que definen las fuentes a utilizar y en qué orden), niveles de autorización y contabilidad de actividad del usuario.

Guarde todo eso por un tiempo en que tenga ganas de quedar fuera de su enrutador por un tiempo.

¡Espero que ayude!

Sí, debes configurarlo en algo. Así es como funciona el IOS. Puede hacerlo igual que su contraseña de inicio de sesión, si lo desea.

Para múltiples usuarios, le recomiendo que configure la autenticación AAA, que le permitirá pasar directamente al modo de activación sin tener que ingresar otra contraseña. También le permitirá realizar un seguimiento de la actividad de los administradores individuales. (Pero aún necesita establecer la contraseña secreta de habilitación en algo).

aaa new model
aaa authentication login default local
aaa authorization enable default local

username chen-li password foo privilege 15
username safar password bar privilege 15

Para agregar a la información existente aquí.

enable

La primera opción para configurar la enablecontraseña es enable password.

Switch(config)#enable password passfoo
Switch#show running-config | include enable
enable password passfoo

Como puede ver, la contraseña se almacena en texto sin formato. Esto es mala .

El segundo es enable secret.

Switch(config)#enable secret ?
  0      Specifies an UNENCRYPTED password will follow
  5      Specifies a MD5 HASHED secret will follow
  8      Specifies a PBKDF2 HASHED secret will follow
  9      Specifies a SCRYPT HASHED secret will follow
  LINE   The UNENCRYPTED (cleartext) 'enable' secret
  level  Set exec level password
Switch(config)#enable secret passfoo
Switch#show running-config | include enable
enable secret 5 $1$cSF4$uydOsfi3J2vGT.77tuYWh1

Esto es mejor . Al menos tenemos un hash de la contraseña ahora. Sin embargo, esto solo usa MD5 salado, por lo que es razonablemente fácil de descifrar con una gran lista de palabras y openssl.

La tercera opción (y el propósito de esta respuesta) es la enable algorithm-typeque nos permite usar PBKDF2 o SCRYPT.

Switch(config)#enable algorithm-type ?
  md5     Encode the password using the MD5 algorithm
  scrypt  Encode the password using the SCRYPT hashing algorithm
  sha256  Encode the password using the PBKDF2 hashing algorithm
Switch(config)#enable algorithm-type scrypt secret ?
  LINE   The UNENCRYPTED (cleartext) 'enable' secret
  level  Set exec level password
Switch(config)#enable algorithm-type scrypt secret passfoo
Switch#show running-config | include enable
enable secret 9 $9$dXjOMeJPYKOFbl$0D4.ItXi8yrjp.A9dt7Ew6tTgr3LYmMlzD672d.LjFk

Esto es definitivamente lo mejor .

Philip D'Ath ha escrito un buen resumen sobre por qué elegir el tipo 9. Thomas Pornin e Ilmari Karonen proporcionan información más detallada.

Básicamente es una capa extra de seguridad. Si no tiene una versión de IOS que admita el cifrado de contraseña de servicio, solo habilite las contraseñas cifradas mientras que las contraseñas de consola y VTY son texto sin formato. Si alguien pudiera obtener una copia de su configuración (por ejemplo, desde una copia de seguridad o una computadora desatendida que se conectó por telnet), la contraseña de habilitación cifrada dificultaría el control de su enrutador, incluso si pueden telnet.

Incluso con VTY cifrado y contraseñas de consola, aún debe tener una contraseña de habilitación diferente para estar seguro y proporcionar una barrera adicional.

Cierre 1 de los 2 usuarios administradores. Francisco tiene una gran cantidad de cualquier, cualquier, cualquier tipo de punto de entrada para hackear a través de Connect. Con dos administradores. Conectado, Cisco creerá que un intruso también está conectado y bloqueará el progreso sin un inicio de sesión adecuado. Una vez que se restablezca el control, debería poder agregar