Preciso definir o segredo de ativação no dispositivo Cisco?

Estou configurando um roteador Cisco 2901. Eu tenho uma senha de login na linha do console e as linhas vty são configuradas para aceitar apenas conexões ssh com autenticação de chave pública. A linha auxiliar está desligada. Existem apenas dois administradores que acessarão o roteador e nós dois estamos autorizados a executar qualquer configuração no roteador.

Não sou especialista em equipamentos Cisco, mas considero adequado para garantir o acesso à configuração do roteador. No entanto, todos os guias que li afirmam que devo definir um segredo de ativação, independentemente de qualquer outro usuário ou senha de linha.

Existe algo mais na senha de ativação que eu não conheço? Existe alguma outra maneira de acessar o roteador além das linhas de console, auxiliar ou vty?

EDIT: Adicionei a configuração real abaixo para ser mais claro sobre minha situação. O seguinte funciona, com a exigência de uma senha de habilitação ou uma usernameconfiguração além da 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

Não, você não - tecnicamente. Mas se você pode entrar no modo de ativação sem um depende de como você faz login.

Aqui está a versão instantânea da gratificação:

Você pode entrar pelo console sem uma senha de habilitação, mas ficará no modo de usuário se usar uma senha de login vty simples sem uma senha de habilitação definida.

Aqui está a versão longa do respondente StackExchange:

A autenticação da Cisco é uma bagunça para iniciantes. Há muita bagagem legada lá. Deixe-me tentar explicar isso no sentido do mundo real.

Todo mundo que tem alguma empresa registrando-se em um roteador ou comutador passa diretamente para o modo privilegiado (habilitado). O modo de usuário é basicamente um lobby frontal e serve pouco mais a propósitos do que manter o rascunho de fora. Nas grandes organizações em que você tem vastas redes e grupos de trabalho igualmente vastos, pode ser justificável ter alguém que possa bater na porta da frente e garantir que alguém ainda esteja lá. (Ou seja, para efetuar login e executar os comandos mais triviais apenas para verificar se o dispositivo está respondendo e não está pegando fogo.) Mas em todos os ambientes em que trabalhei, a camada 1 tinha pelo menos alguma capacidade de quebrar coisas.

Como tal, e particularmente em um cenário como o seu, é necessário conhecer a senha de ativação para fazer qualquer coisa. Você poderia dizer que esse é um segundo nível de segurança - uma senha para entrar no dispositivo, outra para escalar para privilégios administrativos - mas isso me parece um pouco tolo.

Como já observado, você pode (e muitas pessoas o fazem) usar a mesma senha, o que não ajuda muito se alguém obtiver acesso não autorizado via telnet / ssh. Ter senhas estáticas e globais compartilhadas por todos é sem dúvida mais um problema do que ter apenas um token necessário para entrar. Finalmente, a maioria dos outros sistemas (serviços, dispositivos etc.) não requer uma segunda camada de autenticação e geralmente não é considerada insegura por causa disso.

OK, essa é minha opinião sobre o assunto. Você terá que decidir por si próprio se isso faz sentido à luz de sua própria postura de segurança. Vamos ao que interessa.

A Cisco (sabiamente) exige que você defina uma senha de acesso remoto por padrão. Quando você entra no modo de configuração de linha ...

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

... você pode dizer ao roteador para ignorar a autenticação:

router(config-line)# no login

... e ser hackeado imediatamente, mas seu invasor acabará no modo de usuário. Portanto, se você tiver uma senha de ativação definida, pelo menos, você limitará um pouco o dano que pode ser causado. (Tecnicamente, você não pode ir mais longe sem uma senha de ativação. Mais sobre isso em um momento ...)

Naturalmente, ninguém faria isso na vida real. Seu requisito mínimo, por padrão e por bom senso, é definir uma senha simples:

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

Agora, você será solicitado a fornecer uma senha e voltará ao modo de usuário. Se você estiver acessando o console, basta digitar enablepara obter acesso sem precisar digitar outra senha. Mas as coisas são diferentes via telnet, onde você provavelmente obterá isso:

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

Seguindo em frente ... Você provavelmente já sabe que, por padrão, todas as suas senhas configuradas são exibidas em texto simples:

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

Essa é uma daquelas coisas que aperta o esfíncter dos conscientes da segurança. Se a ansiedade justificada é novamente algo que você precisa decidir por si mesmo. Por um lado, se você tiver acesso suficiente para ver a configuração, provavelmente terá acesso suficiente para alterar a configuração. Por outro lado, se acontecer de você ter descuidadamente revelou sua configuração para alguém que não tem os meios-se, então ... bem, agora eles não têm os meios.

Felizmente, essa primeira linha no trecho acima no service password-encryptioné a chave para mudar isso:

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

Agora, quando você olha para a configuração, vê o seguinte:

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

Isso é marginalmente melhor do que as senhas de texto simples, porque a string exibida não é memorável o suficiente para navegar pelos ombros. No entanto, é trivial descriptografar - e eu uso esse termo livremente aqui. Você pode literalmente colar essa sequência acima em um dos doze crackers de senha JavaScript na primeira página de resultados do Google e recuperar o texto original imediatamente.

Essas chamadas "7" senhas são comumente consideradas "ofuscadas" em vez de "criptografadas" para destacar o fato de que elas são apenas melhores do que nada.

No entanto, todos esses passwordcomandos foram descontinuados. (Ou, se não estiverem, deveriam estar.) É por isso que você tem as duas opções a seguir:

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

A versão secreta é dividida em hash com um algoritmo unidirecional, o que significa que a única maneira de recuperar o texto original é por força bruta - ou seja, tentando todas as seqüências de entrada possíveis até que você gere o hash conhecido.

Quando você digita a senha no prompt, ela passa pelo mesmo algoritmo de hash e, portanto, deve acabar gerando o mesmo hash, que é comparado com o do arquivo de configuração. Se eles corresponderem, sua senha será aceita. Dessa forma, o texto sem formatação não é conhecido pelo roteador, exceto durante o breve momento em que você está criando ou digitando a senha. Nota: Sempre há a chance de alguma outra entrada gerar o mesmo hash, mas estatisticamente é uma probabilidade muito baixa (leia-se: desprezível).

Se você fosse para usar a configuração acima de si mesmo, o roteador irá permitir que tanto os enable passworde enable secretde existir linhas, mas as vitórias secretas da senha pronta. Este é um daqueles Cisco-isms que não faz muito sentido, mas é do jeito que é. Além disso, não há secretcomando equivalente no modo de configuração de linha, então você fica preso com senhas ofuscadas por lá.

Tudo bem, agora temos uma senha que não pode ser recuperada (facilmente) do arquivo de configuração - mas ainda há um problema. Ele está sendo transmitido em texto sem formatação quando você faz login via telnet. Nada de bom. Queremos SSH.

O SSH, sendo projetado com segurança mais robusta em mente, requer um pouco de trabalho extra - e uma imagem do IOS com um determinado conjunto de recursos. Uma grande diferença é que uma senha simples não é mais suficiente. Você precisa passar para autenticação baseada no usuário. E enquanto você está nisso, configure um par de chaves de criptografia:

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

Agora você está cozinhando com gás! Observe que este comando usa secretsenhas. (Sim, você pode, mas não deve, usar password). A privilege 15peça permite que você ignore completamente o modo de usuário. Ao fazer login, você vai direto para o modo privilegiado:

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

router#

Nesse cenário, não há necessidade de usar uma senha de habilitação (ou segredo).

Se você ainda não está pensando, "wow ... o que uma clusterfudge que era", tenha em mente há todo um outro post prolixo ainda à espreita por trás do comando aaa new-model, onde você começa a mergulhar em coisas como servidores de autenticação externos (RADIUS , TACACS +, LDAP etc.), listas de autenticação (que definem as fontes a serem usadas e em que ordem), níveis de autorização e contabilidade de atividades do usuário.

Guarde tudo isso por um tempo em que você sentir vontade de ficar bloqueado por um tempo.

Espero que ajude!

Sim, você precisa configurá-lo para algo. É assim que o IOS funciona. Você pode torná-lo igual à sua senha de login, se desejar.

Para vários usuários, recomendo que você configure a autenticação AAA, que permitirá que você entre diretamente no modo de ativação sem precisar digitar outra senha. Também permitirá que você acompanhe a atividade de administradores individuais. (Mas você ainda precisa definir a senha secreta de habilitação para 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 adicionar à informação existente aqui.

enable

A primeira opção para definir a enablesenha é enable password.

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

Como você pode ver, a senha é armazenada em texto sem formatação. Isso é ruim .

O segundo é 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

Isto é melhor . Pelo menos agora temos um hash da senha. No entanto, isso ainda usa apenas MD5 salgado, portanto é provavelmente razoavelmente fácil de quebrar com uma grande lista de palavras e openssl.

A terceira opção (e a finalidade desta resposta) é a enable algorithm-typeque nos permite usar 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

Isso é definitivamente o melhor .

Philip D'Ath escreveu um bom resumo sobre por que escolher o tipo 9. Thomas Pornin e Ilmari Karonen fornecem informações mais detalhadas.

É basicamente uma camada extra de segurança. Se você não possui uma versão do IOS compatível com criptografia de senha de serviço, habilite apenas as senhas são criptografadas enquanto o console e as senhas VTY são em texto sem formatação. Se alguém conseguisse obter uma cópia da sua configuração (digamos, de um backup ou de um computador autônomo que foi telnetado), a senha de habilitação criptografada dificultaria o controle do roteador, mesmo que ele possa ser telnetado.

Mesmo com senhas VTY e console criptografadas, você ainda deve ter uma senha de habilitação diferente para estar do lado seguro e fornecer uma barreira extra.

Encerre 1 dos 2 usuários admin.cisco é muito atento a qualquer, qualquer, qualquer tipo de possível ponto de entrada de hackers via connect. Com dois administradores. Conectado, o cisco acreditará que um invasor também está conectado e bloqueia o progresso adicional sem o login adequado. Depois que o controle for restabelecido, você poderá adicionar administradores