Dois-je définir le secret d'activation sur le périphérique Cisco?

16

J'installe un routeur Cisco 2901. J'ai un mot de passe de connexion sur la ligne de console et les lignes vty sont configurées pour n'accepter que les connexions ssh avec authentification par clé publique. La ligne auxiliaire est fermée. Il n'y a que deux administrateurs qui accéderont au routeur et nous sommes tous les deux autorisés à effectuer n'importe quelle configuration sur le routeur.

Je ne suis pas un expert en équipement Cisco, mais je considère que c'est suffisant pour sécuriser l'accès à la configuration du routeur. Cependant, chaque guide que j'ai lu indique que je dois définir un secret d'activation, indépendamment de tout autre mot de passe d'utilisateur ou de ligne.

Y a-t-il quelque chose de plus dans le mot de passe d'activation que je ne connais pas? Existe-t-il un autre moyen d'accéder au routeur que les lignes de console, auxiliaires ou vty?

EDIT: J'ai ajouté la configuration réelle ci-dessous pour être plus clair sur ma situation. Les travaux suivants, nécessitant un mot de passe d'activation, ou une usernameconfiguration en dehors de celui à l'intérieur 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
Marwan
la source
1
réponse courte: non requise , mais très fortement recommandée - car c'est la première ligne de défense pour les soldats privés
Ricky Beam
Mais si j'ai des mots de passe sur la ligne de console et les vtys, pourquoi aurais-je besoin d'un autre mot de passe? De plus, le secret d'activation devra être partagé entre le personnel administratif, qui demande simplement qu'il soit écrit, envoyé par e-mail, etc. Mieux vaut que chaque administrateur ait son propre mot de passe / clé privé.
Marwan
activer élève priv. À moins que vous ne le changiez (via aaa), il s'applique toujours une fois que vous avez une ligne de commande.
Ricky Beam

Réponses:

24

Non, vous ne le faites pas - techniquement. Mais si vous pouvez entrer en mode d'activation sans celui-ci dépend de la façon dont vous vous connectez.

Voici la version de gratification instantanée:

Vous pouvez entrer via la console sans mot de passe d'activation, mais vous serez bloqué en mode utilisateur si vous utilisez un mot de passe de connexion vty simple sans mot de passe d'activation défini.

Voici la version longue du répondeur StackExchange:

L'authentification Cisco est une sorte de gâchis pour un débutant. Il y a beaucoup de bagages hérités là-bas. Permettez-moi d'essayer de décomposer cela dans un sens réel.

Quiconque a une entreprise se connectant à un routeur ou à un commutateur passe presque directement au mode privilégié (activer). Le mode utilisateur est essentiellement un hall d'entrée et sert à peine plus que de garder le brouillon à l'extérieur. Dans les grandes organisations où vous avez de vastes réseaux et des bassins de main-d'œuvre tout aussi vastes, il peut être justifié d'avoir quelqu'un qui peut frapper à la porte d'entrée et s'assurer que quelqu'un est toujours là. (C'est-à-dire, pour vous connecter et exécuter les commandes les plus triviales juste pour voir que le périphérique répond, et pas en feu.) Mais dans tous les environnements dans lesquels j'ai travaillé, le niveau 1 avait au moins une certaine capacité à casser des choses.

En tant que tel, et en particulier dans un scénario comme le vôtre, connaître le mot de passe d'activation est obligatoire pour faire quoi que ce soit. On pourrait dire que c'est un deuxième niveau de sécurité - un mot de passe pour entrer dans l'appareil, un autre pour passer au privilège administratif - mais cela me semble un peu idiot.

Comme déjà indiqué, vous pouvez (et beaucoup de gens le font) utiliser le même mot de passe, ce qui n'aide pas beaucoup si quelqu'un a obtenu un accès non autorisé via telnet / ssh. Avoir des mots de passe globaux statiques partagés par tout le monde est sans doute plus un problème que d'avoir un seul jeton requis pour entrer. Enfin, la plupart des autres systèmes (services, appliances, etc.) ne nécessitent pas de deuxième couche d'authentification et ne sont généralement pas considérés comme non sécurisés pour cette raison.

OK, c'est mon opinion sur le sujet. Vous devrez décider par vous-même si cela a du sens à la lumière de votre propre position de sécurité. Nous allons passer aux choses sérieuses.

Cisco (judicieusement) vous demande de définir un mot de passe d'accès à distance par défaut. Lorsque vous passez en mode de configuration en ligne ...

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

... vous pouvez dire au routeur de sauter l'authentification:

router(config-line)# no login

... et rapidement piraté, mais votre attaquant se retrouvera en mode utilisateur. Donc, si vous avez un mot de passe activé, au moins vous avez quelque peu limité les dégâts qui peuvent être causés. (Techniquement, vous ne pouvez pas aller plus loin sans activer le mot de passe. Plus d'informations à ce sujet dans un instant ...)

Naturellement, personne ne ferait cela dans la vraie vie. Votre exigence minimale, par défaut et par bon sens, est de définir un mot de passe simple:

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

Maintenant, on vous demandera un mot de passe et vous vous retrouverez à nouveau en mode utilisateur. Si vous entrez via la console, vous pouvez simplement taper enablepour y accéder sans avoir à entrer un autre mot de passe. Mais les choses sont différentes via telnet, où vous obtiendrez probablement ceci à la place:

$ 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> 

Passons à autre chose ... Vous savez probablement déjà que, par défaut, tous vos mots de passe configurés apparaissent en texte brut:

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

C'est l'une de ces choses qui resserre le sphincter du soucieux de la sécurité. Que ce soit une anxiété justifiée est à nouveau quelque chose que vous devez décider vous-même. D'une part, si vous disposez d'un accès suffisant pour voir la configuration, vous disposez probablement d'un accès suffisant pour modifier la configuration. D'autre part, si vous arrive d'avoir négligemment révélé votre configuration à quelqu'un qui n'a pas les moyens eux - mêmes, alors ... eh bien, maintenant ils n'ont les moyens.

Heureusement, la première ligne de l'extrait ci-dessus no service password-encryption, est la clé pour changer cela:

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

Maintenant, quand vous regardez la configuration, vous voyez ceci:

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

C'est légèrement meilleur que les mots de passe en texte brut, car la chaîne affichée n'est pas assez mémorable pour surfer. Cependant, il est trivial de décrypter - et j'utilise ce terme librement ici. Vous pouvez littéralement coller cette chaîne ci-dessus dans l'un des douze crackers de mot de passe JavaScript sur la première page de résultats Google, et récupérer immédiatement le texte d'origine.

Ces mots de passe soi-disant «7» sont généralement considérés comme «obscurcis» plutôt que «cryptés» pour souligner le fait qu'il est à peine meilleur que rien.

Cependant, il s'avère que toutes ces passwordcommandes sont obsolètes. (Ou s'ils ne le sont pas, ils devraient l'être.) C'est pourquoi vous avez les deux options suivantes:

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 version secrète est hachée avec un algorithme à sens unique, ce qui signifie que la seule façon de récupérer le texte d'origine est par force brute - c'est-à-dire, en essayant toutes les chaînes d'entrée possibles jusqu'à ce que vous génériez le hachage connu.

Lorsque vous entrez le mot de passe à l'invite, il passe par le même algorithme de hachage, et devrait donc finir par générer le même hachage, qui est ensuite comparé à celui du fichier de configuration. S'ils correspondent, votre mot de passe est accepté. De cette façon, le texte brut n'est pas connu du routeur, sauf pendant le bref moment où vous créez ou entrez le mot de passe. Remarque: Il est toujours possible qu'une autre entrée puisse générer le même hachage, mais statistiquement, c'est une probabilité très faible (lire: négligeable).

Si vous deviez utiliser vous-même la configuration ci-dessus, le routeur autorisera les lignes enable passwordet enable secretà exister, mais le secret l'emporte à l'invite du mot de passe. C'est l'un de ces Cisco-ismes qui n'a pas beaucoup de sens, mais c'est comme ça. De plus, il n'y a pas de secretcommande équivalente du mode de configuration de ligne, vous êtes donc coincé avec des mots de passe obscurcis.

Très bien, nous avons donc maintenant un mot de passe qui ne peut pas être récupéré (facilement) à partir du fichier de configuration - mais il y a toujours un problème. Il est transmis en texte brut lorsque vous vous connectez via telnet. Pas bien. Nous voulons SSH.

SSH, conçu avec une sécurité plus solide à l'esprit, nécessite un peu de travail supplémentaire - et une image IOS avec un certain ensemble de fonctionnalités. Une grande différence est qu'un simple mot de passe n'est plus suffisant. Vous devez passer à l'authentification basée sur l'utilisateur. Et pendant que vous y êtes, configurez une paire de clés de chiffrement:

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

Maintenant, vous cuisinez au gaz! Notez que cette commande utilise des secretmots de passe. (Oui, vous pouvez, mais ne devriez pas, utiliser password). La privilege 15partie vous permet de contourner complètement le mode utilisateur. Lorsque vous vous connectez, vous passez directement en mode privilégié:

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

router#

Dans ce scénario, il n'est pas nécessaire d'utiliser un mot de passe d'activation (ou secret).

Si vous n'êtes pas encore penser, « wow ... quel clusterfudge qui était », gardez à l' esprit il y a un tout autre poste de longue haleine qui se cache toujours derrière la commande aaa new-model, où vous arrivez à plonger dans des choses comme des serveurs d'authentification externes (RADIUS , TACACS +, LDAP, etc.), les listes d'authentification (qui définissent les sources à utiliser et dans quel ordre), les niveaux d'autorisation et la comptabilité des activités des utilisateurs.

Enregistrez tout cela pendant un moment où vous avez envie de rester verrouillé hors de votre routeur pendant un certain temps.

J'espère que cela pourra aider!

SirNickity
la source
1
Bienvenue! Grande première réponse!
Digital Trauma
Merci, c'est une réponse très perspicace. Je connais les différents périphériques de cryptage de mot de passe et j'utilise un nouveau modèle aaa (j'ai modifié ma question pour refléter cela).
Marwan
Ne pas avoir de secret d'activation ne semble pas être un problème pour moi. Que je telnet / ssh avec un nom d'utilisateur / mot de passe ou une clé publique, je peux simplement taper enableet cela fonctionne. De plus, avoir un nom d'utilisateur avec le privilège 15 nécessite toujours que je tape enable. Est-ce dû au nouveau modèle aaa?
Marwan
1
Avez-vous essayé de définir des listes d'authentification? Utilisez "aaa authentification login local par défaut", et "aaa autorisation exec par défaut local". Alternativement, utilisez "si authentifié" au lieu de "local" sur ce dernier.
SirNickity
J'ai essayé de dupliquer votre configuration sur un 2811 exécutant IOS 15.1 (4) M et j'ai trouvé des résultats intéressants. Si je n'ai PAS défini de lignes authen / author aaa, je peux me connecter avec une clé publique et aucune déclaration de nom d'utilisateur global. Si je définis les lignes authen / author par mon commentaire précédent, je ne suis pas en mesure de SSH avec juste une clé publique - la commande de nom d'utilisateur global est requise (échec d'autorisation sinon.) Si je fais quelque chose de stupide et saisis un nom d'utilisateur global avecOUT un secret / mot de passe, SSH fonctionne avec une clé, mais telnet fonctionne sans mot de passe - alors ne faites pas ça.
SirNickity
4

Oui, vous devez le régler sur quelque chose. C'est juste ainsi que fonctionne l'IOS. Vous pouvez le faire comme votre mot de passe de connexion, si vous le souhaitez.

Pour plusieurs utilisateurs, je vous recommande de configurer l'authentification AAA, qui vous permettra de passer directement en mode d'activation sans avoir à entrer un autre mot de passe. Il vous permettra également de suivre l'activité de chaque administrateur. (Mais vous devez toujours définir le mot de passe secret d'activation sur quelque chose.)

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
Ron Trunk
la source
2
Pour sauvegarder la réponse de Ron, elle doit être activée si vous voulez entrer en mode d'exécution privilégié à moins que vous ne configuriez vos VTY pour entrer directement au niveau 15.
jwbensley
@jwbensley. Bonne idée. J'avais oublié ça.
Ron Trunk
J'utilise un nouveau modèle aaa, mais la définition du privilège 15 nécessite toujours que j'utilise la commande enable. Je n'ai pas non plus besoin d'activer un secret / mot de passe (je viens de tester tout cela).
Marwan
Allez-y au travail. Apparemment, je devais spécifier aaa authorization exec default localde saisir automatiquement un privilège.
Marwan
1

Pour compléter les informations existantes ici.

enable

La première option pour définir le enablemot de passe est enable password.

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

Comme vous pouvez le voir, le mot de passe est stocké en texte brut. C'est mauvais .

Le second est 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

C'est mieux . Au moins, nous avons un hachage du mot de passe maintenant. Cependant, cela n'utilise toujours que du MD5 salé, il est donc raisonnablement facile de le casser avec une grande liste de mots et openssl.

La troisième option (et le but de cette réponse) est celle enable algorithm-typequi nous permet d'utiliser PBKDF2 ou 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

C'est vraiment mieux .

Philip D'Ath a écrit un joli résumé sur les raisons du choix du type 9. Thomas Pornin et Ilmari Karonen fournissent des informations plus détaillées.

Samuel Harmer
la source
0

Il s'agit essentiellement d'une couche de sécurité supplémentaire. Si vous ne disposez pas d'une version d'IOS qui prend en charge le chiffrement par mot de passe du service, seuls les mots de passe d'activation sont chiffrés alors que la console et les mots de passe VTY sont en texte brut. Si quelqu'un était en mesure d'obtenir une copie de votre configuration (par exemple à partir d'une sauvegarde ou d'un ordinateur sans surveillance qui était connecté), le mot de passe d'activation crypté rendrait plus difficile le contrôle de votre routeur, même s'il peut se connecter via Telnet.

Même avec des mots de passe VTY et console chiffrés, vous devriez toujours avoir un mot de passe d'activation différent pour être sûr et fournir une barrière supplémentaire.

pooter03
la source
0

Arrêtez 1 des 2 utilisateurs admin.cisco sont très attentifs à tout, n'importe quel type de point d'entrée de piratage via connect. Avec deux administrateurs. Connecté, le Cisco croira qu'un intrus est également connecté et bloquera toute progression sans connexion appropriée. Une fois le contrôle rétabli, vous devriez pouvoir ajouter des

MAMAN
la source