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 admin@10.1.1.1
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!