Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Privilégios de acesso ao usuário

Você (o administrador do sistema) concede aos usuários acesso ou permissões para comandos e níveis e declarações de hierarquia de configuração. Os usuários só podem executar esses comandos e visualizar e configurar apenas aquelas declarações para as quais eles têm privilégios de acesso. Você também pode usar expressões regulares estendidas para especificar quais comandos de modo operacional, declarações de configuração e hierarquias são permitidos ou negados aos usuários. Essa prática impede que usuários não autorizados executem comandos sensíveis ou configurem declarações que possam causar danos à rede.

Visão geral dos níveis de privilégio de acesso

Cada declaração de comando e configuração de CLI de alto nível tem um nível de privilégio de acesso associado. Os usuários só podem executar esses comandos e configurar e visualizar apenas aquelas declarações para as quais têm privilégios de acesso. Uma ou mais bandeiras de permissão definem os privilégios de acesso para cada aula de login.

Para cada classe de login, você também pode permitir ou negar explicitamente o uso de comandos de modo operacional e configuração e hierarquias de declaração que de outra forma seriam permitidas ou negadas por um nível de privilégio especificado na permissions declaração.

Bandeiras de permissão da classe de login

Você usa bandeiras de permissão para conceder a um usuário acesso a comandos de modo operacional e níveis e declarações de hierarquia de configuração. Você configura bandeiras de permissão para a classe de login do usuário no nível de [edit system login class] hierarquia. Quando você especifica uma determinada bandeira de permissão, o usuário obtém acesso aos comandos e aos níveis e declarações de hierarquia de configuração que correspondem a essa bandeira. Para conceder acesso a todos os comandos e declarações de configuração, use a bandeira de all permissões.

Nota:

Cada comando listado representa esse comando e todos os subcomandados com esse comando como prefixo. Cada declaração de configuração listada representa o topo da hierarquia de configuração à qual essa bandeira concede acesso.

A permissions declaração especifica uma ou mais das bandeiras de permissão listadas em Tabela 1. As bandeiras de permissão não são cumulativas. Para cada classe, você deve listar todas as bandeiras de permissão necessárias, inclusive view para exibir informações e configure entrar no modo de configuração. Duas formas de permissões controlam o acesso de um usuário às partes individuais da configuração:

  • Formulário "simples" — fornece recursos somente de leitura para esse tipo de permissão. Um exemplo é interface.

  • -control formulário — fornece recursos de leitura e gravação para esse tipo de permissão. Um exemplo é interface-control.

Para bandeiras de permissão que concedem acesso a níveis e declarações de hierarquia de configuração, as bandeiras de forma simples concedem privilégio somente de leitura a essa configuração. Por exemplo, a interface bandeira de permissão concede acesso somente de leitura ao nível de [edit interfaces] hierarquia. A -control forma da bandeira concede acesso de leitura e gravação a essa configuração. Por exemplo, a interface-control bandeira concede acesso de leitura e gravação ao nível de [edit interfaces] hierarquia.

Tabela 1 lista as bandeiras de permissão da classe de login que você pode configurar, incluindo a permissions declaração no nível de [edit system login class class-name] hierarquia.

As bandeiras de permissão concedem um conjunto específico de privilégios de acesso. Cada bandeira de permissão está listada com o modo operacional ou comandos de modo de configuração e níveis de hierarquia de configuração e declarações para as quais essa bandeira concede acesso.

Tabela 1: Bandeiras de permissão da classe de login

Bandeira de permissão

Descrição

access

Pode visualizar a configuração de acesso no modo operacional ou no modo de configuração.

access-control

Pode visualizar e configurar informações de acesso no nível de [edit access] hierarquia.

admin

Pode visualizar as informações da conta do usuário no modo operacional ou no modo de configuração.

admin-control

Pode visualizar as informações da conta do usuário e configurá-la no nível de [edit system] hierarquia.

all

Pode acessar todos os comandos de modo operacional e comandos de modo de configuração. Pode modificar a configuração em todos os níveis de hierarquia de configuração.

clear

Pode limpar (excluir) informações que o dispositivo aprende com a rede e armazena em vários bancos de dados de rede (usando os clear comandos).

configure

Pode entrar no modo de configuração (usando o configure comando) e confirmar configurações (usando o commit comando).

control

Pode realizar todas as operações de nível de controle — todas as operações configuradas com as bandeiras de -control permissão.

field

Pode visualizar comandos de depuração de campo. Reservado para suporte de depuração.

firewall

Pode visualizar a configuração do filtro de firewall no modo operacional ou no modo de configuração.

firewall-control

Pode visualizar e configurar informações de filtro de firewall no nível de [edit firewall] hierarquia.

floppy

Pode ler e escrever para a mídia removível.

flow-tap

Pode visualizar a configuração flow-tap no modo operacional ou no modo de configuração.

flow-tap-control

Pode visualizar e configurar informações de fluxo-tap no nível de [edit services flow-tap] hierarquia.

flow-tap-operation

Pode fazer solicitações de fluxo-tap para o roteador ou switch. Por exemplo, um cliente do Protocolo de Controle de Tarefas Dinâmicas (DTCP) deve ter flow-tap-operation permissão para se autenticar Junos OS como um usuário administrativo.

Nota:

A opção flow-tap-operation não está incluída na bandeira de all-control permissões.

idp-profiler-operation

Pode visualizar dados do profiler.

interface

Pode visualizar a configuração da interface no modo operacional e no modo de configuração.

interface-control

Pode visualizar chassis, classe de serviço (CoS), grupos, opções de encaminhamento e informações de configuração de interfaces. Pode modificar a configuração nos seguintes níveis de hierarquia:

  • [edit chassis]

  • [edit class-of-service]

  • [edit groups]

  • [edit forwarding-options]

  • [edit interfaces]

maintenance

Pode realizar a manutenção do sistema, incluindo iniciar uma concha local no dispositivo e se tornar o superusuário na concha (usando o su root comando) e parar e reiniciar o dispositivo (usando os request system comandos).

network

Pode acessar a rede usando os ping, ssh, telnete traceroute comandos.

pgcp-session-mirroring

Pode visualizar a configuração de espelhamento da pgcp sessão.

pgcp-session-mirroring-control

Pode modificar a configuração de pgcp espelhamento de sessão.

reset

Pode reiniciar processos de software usando o restart comando.

rollback

Pode usar o rollback comando para retornar a uma configuração previamente comprometida.

routing

Pode visualizar informações gerais de configuração de roteamento, roteamento e política de roteamento no modo de configuração e no modo operacional.

routing-control

Pode visualizar e configurar o roteamento geral no nível de [edit routing-options] hierarquia, protocolos de roteamento no nível de [edit protocols] hierarquia e roteamento de informações de políticas no nível hierárquica [edit policy-options] .

secret

Pode visualizar senhas e outras chaves de autenticação na configuração.

secret-control

Pode visualizar e modificar senhas e outras chaves de autenticação na configuração.

security

Pode visualizar informações de configuração de segurança no modo operacional e no modo de configuração.

security-control

Pode visualizar e configurar informações de segurança no nível de [edit security] hierarquia.

shell

Pode iniciar um shell local no roteador ou switch usando o start shell comando.

snmp

Pode visualizar informações de configuração do Protocolo de Gerenciamento de Rede Simples (SNMP) no modo operacional ou no modo de configuração.

snmp-control

Pode visualizar e modificar as informações de configuração de SNMP no nível de [edit snmp] hierarquia.

system

Pode visualizar informações de nível de sistema no modo operacional ou no modo de configuração.

system-control

Pode visualizar e modificar informações de configuração no nível do sistema no nível de [edit system] hierarquia.

trace

Pode visualizar configurações de arquivo de rastreamento e configurar propriedades de arquivo de rastreamento.

trace-control

Pode modificar configurações de arquivo de rastreamento e configurar propriedades de arquivo de rastreamento.

view

Pode usar vários comandos para exibir a tabela de roteamento atual em todo o sistema e valores e estatísticas específicos do protocolo. Não é possível visualizar a configuração secreta.

view-configuration

Pode visualizar toda a configuração, exceto segredos, scripts de sistema e opções de eventos.

Nota:

Somente usuários com a maintenance permissão podem visualizar a configuração de script de confirmação, script de operação ou script de eventos.

Permitir e negar comandos individuais e hierarquias de declaração para aulas de login

Por padrão, todos os comandos de CLI de alto nível e os níveis de hierarquia de configuração associaram níveis de privilégio de acesso. Os usuários só podem executar esses comandos e visualizar e configurar apenas aquelas declarações para as quais eles têm privilégios de acesso. Para cada classe de login, você pode permitir e negar explicitamente o uso de comandos de modo operacional e modo de configuração e hierarquias de declaração que de outra forma seriam permitidas ou negadas por um nível de privilégio especificado na permissions declaração.

As bandeiras de permissão concedem a um usuário acesso a comandos de modo operacional e de configuração e a níveis e declarações de hierarquia de configuração. Ao especificar uma bandeira de permissão específica na classe de login do usuário no nível de [edit system login class] hierarquia, você concede ao usuário acesso aos níveis e declarações da hierarquia de configuração e comandos correspondentes. Para conceder acesso a todos os comandos e declarações de configuração, use a bandeira de all permissões.

Você pode permitir ou negar explicitamente o uso de comandos e declarações configurando, allow-commandsdeny-commandse allow-configurationdeny-configuration declarações para uma aula de login. Nas declarações, você usa expressões regulares estendidas para definir quais comandos e declarações permitem ou negam para usuários atribuídos à classe.

Exemplo: Configure permissões de usuários com níveis de privilégio de acesso

Este exemplo configura as permissões do usuário para uma aula de login. Você configura permissões de usuário para uma aula de login para impedir que os usuários realizem ações de rede não autorizadas. Os usuários só podem executar esses comandos e visualizar e modificar apenas aquelas declarações para as quais têm privilégios de acesso. Essa restrição impede que usuários não autorizados executem comandos sensíveis ou configurem declarações que possam causar danos à rede.

Requisitos

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes de configurar este exemplo.

Visão geral

Cada comando CLI de alto nível e cada declaração de configuração tem um nível de privilégio de acesso associado a ele. Ao configurar uma aula de login, você pode permitir ou negar explicitamente o uso de comandos de modo operacional e configuração e declarações de configuração. Os usuários só podem executar esses comandos e visualizar e configurar apenas aquelas declarações para as quais eles têm privilégios de acesso.

Você define os privilégios de acesso para cada aula de login especificando uma ou mais bandeiras de permissão na permissions declaração. As bandeiras de permissão concedem a um usuário acesso a comandos, declarações e hierarquias. As bandeiras de permissão não são cumulativas. Para cada aula de login, você deve listar todas as bandeiras de permissão necessárias, inclusive view para exibir informações e configure entrar no modo de configuração. Ao especificar uma bandeira de permissão específica na classe de login do usuário, você concede ao usuário acesso aos comandos, declarações e hierarquias correspondentes. Para conceder acesso a todos os comandos e declarações de configuração, use a bandeira de all permissões. As bandeiras de permissão fornecem um formulário somente de leitura ("simples") e recursos de leitura e gravação (formulário que termina em -controle) para um tipo de permissão.

Nota:

Os all bits de permissão da classe de login têm precedência sobre expressões regulares estendidas quando um usuário emite um rollback comando com a rollback bandeira de permissão ativada.

Para configurar níveis de privilégio de acesso do usuário para uma aula de login, inclua a permissions declaração no nível de [edit system login class class-name] hierarquia, seguida pelas bandeiras de permissão. Configure várias permissões como uma lista separada por espaço em suportes quadrados:

Dica:

Para visualizar as permissões disponíveis, use a ajuda sensível ao contexto da CLI e digite um ponto de interrogação (?) após a permissions declaração:

Configuração

Este exemplo configura a classe de snmp-admin login. Os usuários desta classe de login podem configurar e visualizar apenas parâmetros SNMP.

Configure permissões de usuários com níveis de privilégio de acesso

Procedimento passo a passo

Para configurar privilégios de acesso para a aula de login:

  1. Configure a aula de snmp-admin login com as configurebandeiras e snmpsnmp-control permissão.

    As bandeiras de permissão configuradas fornecem recursos de leitura (snmp) e de leitura e gravação (controle de snmp) para SNMP, e este é o único privilégio de acesso permitido para esta classe de login. Todos os outros privilégios de acesso são negados.

  2. Crie as contas de usuário que são atribuídas à classe de snmp-admin login.

Resultados

No modo de configuração, confirme sua configuração entrando no show system login comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Depois de configurar o dispositivo, entre commit no modo de configuração.

Verificação

Faça login usando um nome de usuário atribuído à nova classe de login e confirme que a configuração está funcionando corretamente.

Verificar a configuração do SNMP

Propósito

Verifique se um usuário da classe de snmp-admin login pode configurar SNMP.

Ação

No modo de configuração, configure declarações de SNMP no nível de [edit snmp] hierarquia.

Significado

O usuário da classe de snmp-admin login é capaz de configurar parâmetros SNMP. O usuário pode configurar esses parâmetros porque as bandeiras de permissão especificadas para esta classe incluem snmp (recursos de leitura) e bits de permissão de controle de snmp (recursos de leitura e gravação).

Verifique a configuração não-SNMP

Propósito

Verifique se um usuário da classe de snmp-admin login não pode modificar declarações de configuração não-SNMP.

Ação

No modo de configuração, tente configurar qualquer declaração não SNMP, como uma declaração na interfaces hierarquia.

Significado

O usuário da classe de snmp-admin login não é capaz de configurar a [edit interfaces] hierarquia porque as bandeiras de permissão especificadas para esta classe não permitem. Nesse caso, a CLI emite uma mensagem de erro.

Expressões regulares para permitir e negar comandos de modo operacional, declarações de configuração e hierarquias

Este tópico contém as seguintes seções:

Entender as declarações de permitir e negar

Cada hierarquia de declaração de configuração e comando de CLI de alto nível tem um nível de privilégio de acesso associado a ele. Cada classe de login pode permitir ou negar explicitamente o uso de comandos de modo operacional e configuração e hierarquias de configuração e declarações que de outra forma seriam permitidas ou negadas por um nível de privilégio. Os usuários só podem executar esses comandos e visualizar e configurar apenas aquelas declarações para as quais eles têm privilégios de acesso.

Os privilégios de acesso para cada classe de login são definidos por uma ou mais bandeiras de permissão especificadas na permissions declaração no nível hierárquico [edit system login class class-name] . Além disso, você pode permitir ou negar o uso de comandos específicos e hierarquias de configuração definindo expressões regulares estendidas. Você pode especificar as expressões regulares configurando as seguintes declarações para uma aula de login:

  • allow-commands e deny-commands— Permitir ou negar acesso a comandos de modo operacional e de configuração.

  • allow-configuration e deny-configuration— Permitir ou negar acesso a hierarquias de configuração específicas.

    Nota:

    Essas declarações executam correspondências mais lentas, com mais flexibilidade, especialmente em correspondências de wildcard. No entanto, pode levar muito tempo para avaliar todas as declarações possíveis se um grande número de expressões regulares ou expressões de wildcard estão configuradas, possivelmente afetando negativamente o desempenho.

  • allow-commands-regexps e deny-commands-regexps— Permitir ou negar acesso a comandos específicos usando strings de expressões regulares.

  • allow-configuration-regexps e deny-configuration-regexps— Permitir ou negar acesso a hierarquias de configuração específicas usando strings de expressões regulares.

Nota:

Se suas configurações existentes usarem as allow/deny-commands ou allow/deny-configuration declarações, usar as mesmas opções de configuração com as allow/deny-commands-regexps declarações ou allow/deny-configuration-regexps declarações pode não produzir os mesmos resultados. Os métodos de pesquisa e correspondência diferem nas duas formas dessas declarações.

Permitir explicitamente hierarquias de declaração de comandos e configuração usando as allow/deny-* declarações adiciona às permissões que a permissions declaração já define. Da mesma forma, negar explicitamente hierarquias de comandos e declarações de configuração usando as allow/deny-* declarações remove as permissões que a permissions declaração já define.

Por exemplo, na configuração a seguir, a configure permissão permite que usuários da classe de login entrem no modo de configuração. Além disso, a allow-configuration expressão permite que os usuários modifiquem a configuração no nível da hierarquia e a [edit system services] comprometam.

Da mesma forma, na configuração a seguir, o usuário da classe de login pode realizar todas as operações que a all bandeira de permissões permite, exceto que o usuário não pode visualizar ou modificar a configuração no nível de [edit system services] hierarquia:

Entendendo a sintaxe de permitir e negar declarações

Você pode configurar uma declaração allow/deny-* apenas uma vez em cada aula de login. Quando você configura uma declaração:

  • Você pode configurar quantas expressões regulares forem necessárias.

  • Expressões regulares não são sensíveis ao caso

As allow/deny-commands declarações são mutuamente exclusivas com as allow/deny-commands-regexps declarações, e as allow/deny-configuration declarações são mutuamente exclusivas com as allow/deny-configuration-regexps declarações. Por exemplo, você não pode configurar ambos allow-configuration e allow-configuration-regexps na mesma classe de login.

Para definir privilégios de acesso a comandos, especifique expressões regulares estendidas usando as declarações e deny-commands declaraçõesallow-commands. Inclua cada expressão autônoma completa em parênteses e use o símbolo do pipe ( |) para separar as expressões. Não use espaços entre expressões regulares conectadas com o símbolo do pipe. A expressão completa está inclusa em cotações duplas.

Por exemplo:

Você deve usar âncoras ao especificar expressões regulares complexas com a allow-commands declaração. Por exemplo:

Para definir privilégios de acesso a partes da hierarquia de configuração, especifique expressões regulares estendidas nas declarações e deny-configuration declaraçõesallow-configuration. Inclua os caminhos completos em parênteses e use o símbolo do pipe ( | ) para separar as expressões. Não use espaços entre expressões regulares conectadas com o símbolo do pipe. A expressão completa está inclusa em cotações duplas.

Por exemplo:

Ao especificar expressões regulares estendidas usando as allow/deny-commands-regexps ou allow/deny-configuration-regexps declarações, inclua cada expressão dentro das cotações (" "), e separe as expressões usando um espaço. Inclua várias expressões em suportes quadrados [ ]. Por exemplo:

Modificadores como set, loge count não são suportados dentro da seqüência de expressão regular a ser combinada. Se você usa um modificador, então nada é compatível.

Configuração correta:

Configuração incorreta:

Entender a precedência e a correspondência da declaração Permitir e Negar

Por padrão, as allow-commands expressões regulares e allow-configuration a precedência se deny-commands sobrepõem e deny-configuration expressões. Assim, se você configurar o mesmo comando para as declarações e deny-commands declaraçõesallow-commands, a operação de permissão prevalecerá sobre a operação de negação. Da mesma forma, se você configurar a mesma declaração para as declarações e deny-configuration declaraçõesallow-configuration, a operação de permissão prevalecerá sobre a operação de negação.

Por exemplo, a configuração a seguir permite que um usuário da classe de test login instale software usando o request system software add comando, embora a deny-commands declaração inclua o mesmo comando:

Da mesma forma, a configuração a seguir permite que um usuário no teste de test classe de login visualiza e modifique a hierarquia de [edit system services] configuração, embora a deny-configuration declaração inclua a mesma hierarquia:

Se o e deny-commands as allow-commands declarações tiverem duas variantes diferentes de um comando, a combinação mais longa sempre será executada. A configuração a seguir permite que um usuário na classe de test login execute o commit synchronize comando, mas não o commit comando. Isso porque commit synchronize é a combinação mais longa entre commit e commit synchronize, e é especificada para allow-commands.

A configuração a seguir permite que um usuário na classe de test login execute o commit comando, mas não o commit synchronize comando. Isso porque commit synchronize é a combinação mais longa entre commit e commit synchronize, e é especificada para deny-commands.

Em contraste com as outras declarações, o comportamento padrão das *-regexps declarações é que as deny-commands-regexps expressões regulares têm deny-configuration-regexps precedência e allow-configuration-regexpsallow-commands-regexps expressões. Você pode configurar a regex-additive-logic declaração no nível da [edit system] hierarquia para forçar as allow-configuration-regexps expressões regulares a prevalecerem sobre as deny-configuration-regexps declarações. Configurar a declaração permite negar hierarquias de configuração em um nível mais alto e, em seguida, apenas permitir que o usuário tenha acesso a sub-hierarquias específicas.

Entender as regras de permitir e negar declarações

allow/deny-configurationallow/deny-commands-regexpsallow/deny-configuration-regexps E as allow/deny-commandsdeclarações têm precedência sobre as permissões de classe de login. Ao configurar essas declarações, as seguintes regras se aplicam:

  • Expressões regulares para allow-commands e declarações também podem incluir, loadcommit, rollback, , save, statuse update comandosdeny-commands.

  • Os all bits de permissão da classe de login têm precedência sobre expressões regulares estendidas quando um usuário emite o rollback comando com a rollback bandeira de permissão ativada.

  • Os usuários não podem emitir o load override comando ao especificar uma expressão regular estendida. Os usuários só podem emitir os mergecomandos e replacepatch configuração.

  • Você pode usar o caractere wildcard ao denotar expressões regulares. No entanto, você deve usá-lo como parte de uma expressão regular. Você não pode usar [ * ] ou [ .* ] como a única expressão. Além disso, você não pode configurar a allow-configuration declaração com uma expressão como (interfaces (description (|.*)), porque isso avalia allow-configuration .*.

Entender as diferenças para as declarações *-regexps

Esta seção descreve as diferenças entre as allow/deny-configuration declarações e as allow/deny-configuration-regexps declarações.

As allow/deny-configuration-regexps declarações dividem a expressão regular em símbolos e comparam cada peça com cada parte do caminho completo da configuração especificada, enquanto as allow/deny-configuration declarações correspondem à seqüência completa. Para allow/deny-configuration-regexps declarações, você configura um conjunto de strings em que cada string é uma expressão regular, com espaços entre os termos da cadeia. Essa sintaxe oferece combinação muito rápida, mas oferece menos flexibilidade. Para especificar expressões de wildcard, você deve configurar wildcards para cada símbolo da corda delimitada por espaço que deseja combinar, o que torna mais difícil usar expressões de wildcard para essas declarações.

Por exemplo:

  • Expressão regular combinando um símbolo usando allow-configuration-regexps

    Este exemplo mostra que options essa é a única expressão combinada contra o primeiro símbolo da declaração.

    A configuração anterior corresponde às seguintes declarações:

    • definir as condições de opçõescondition de política dinâmica

    • definir rotas estáticas static-route de roteamento next-hop next-hop

    • definir opções de evento geram intervalo de tempo do evento eventseconds

    A configuração anterior não corresponde às seguintes declarações:

    • opções de host com nome de host do sistema

    • opções de descrição de interfaces interface-name

  • Expressão regular combinando três símbolos usando allow-configuration-regexps

    Este exemplo mostra que ssh essa é a única expressão combinada contra o terceiro símbolo da declaração.

    No exemplo anterior, os três símbolos incluem .*, .*e .*ssh, respectivamente.

    A configuração anterior corresponde às seguintes declarações:

    • nome de host do sistemaname-ssh

    • ssh de serviços do sistema

    • serviços de sistema de saída ssh

    A configuração anterior não corresponde à seguinte declaração:

    • ssh interface-namedescrição de interfaces

É mais fácil usar a declaração para restringir o deny-configuration acesso de configuração do que usar a deny-configuration-regexps declaração. Tabela 2 Ilustra o uso tanto das declarações quanto deny-configurationdeny-configuration-regexps das declarações em configurações diferentes para alcançar o mesmo resultado de restringir o acesso a uma configuração específica.

Tabela 2: Restrição do acesso de configuração Usando declarações de negação de configuração e negação de configuração-regexps

Configuração negada

Usando: deny-configuration

Usando: deny-configuration-regexps

Resultado

xnm-ssl

[edit system]
login {
    class test {
        permissions configure;
         allow-configuration .*;
        deny-configuration .*xnm-ssl;
    }
}
[edit system]
login {
    class test {
        permissions configure;
         allow-configuration .*;
        deny-configuration-regexps ".* .* .*-ssl"";
    }
}

A declaração de configuração a seguir é negada:

  • xnm-ssl de serviços de sistema

ssh

[edit system]
login {
    class test {
        permissions configure;
        allow-configuration .*;
        deny-configuration ".*ssh";
    }
}
[edit system]
login {
    class test {
        permissions configure;
        allow-configuration .*;
        deny-configuration-regexps ".*ssh";
        deny-configuration-regexps ".* .*ssh";
        deny-configuration-regexps ".* .* .*ssh";
    }
}

As seguintes declarações de configuração são negadas:

  • nome de host do sistemaname-ssh

  • ssh de serviços do sistema

  • serviços de sistema de saída ssh

  • ssh-known-host de segurança

Embora as allow/deny-configuration declarações também sejam úteis quando você deseja uma configuração simples, as allow/deny-configuration-regexps declarações fornecem melhor desempenho e superam a ambiguidade que existia ao combinar expressões nas allow/deny-configuration declarações.

Usando expressões regulares em servidores de autorização remota

Você pode usar expressões regulares estendidas para especificar quais comandos de modo operacional e de configuração e declarações de configuração e hierarquias são permitidos ou negados para determinados usuários. Você especifica essas expressões regulares localmente no allow/deny-commandsallow/deny-configurationallow/deny-commands-regexps nível de hierarquia e allow/deny-configuration-regexps declarações[edit system login class class-name]. Você especifica essas expressões regulares remotamente especificando os atributos TACACS+ ou RADIUS específicos do fornecedor da Juniper Networks na configuração do servidor de autorização. Quando você configura parâmetros de autorização local e remotamente, o dispositivo mescla as expressões regulares recebidas durante o TACACS+ ou autorização RADIUS com quaisquer expressões regulares definidas no dispositivo local.

Nota:

A partir do Junos OS Release 18.1, as declarações e deny-commands-regexps o allow-commands-regexps suporte para a autorização do TACACS+.

Ao especificar várias expressões regulares em uma configuração local usando, allow-commandsdeny-commands, allow-configurationou deny-configuration declarações, você configura expressões regulares dentro dos parênteses e as separa usando o símbolo do pipe. Você inclui a expressão completa em cotações duplas. Por exemplo, você pode especificar vários allow-commands parâmetros com a seguinte sintaxe:

O servidor de autorização RADIUS usa os seguintes atributos e sintaxe:

O servidor de autorização TACACS+ usa os seguintes atributos e sintaxe:

Ao especificar várias expressões regulares em uma configuração local usando, allow-commands-regexpsdeny-commands-regexps, allow-configuration-regexpsou deny-configuration-regexps declarações, você configura expressões regulares dentro de duas cotações e as separa usando o operador de espaço. Você inclui a expressão completa em suportes quadrados. Por exemplo, você pode especificar vários parâmetros de permitir comandos com a seguinte sintaxe:

O servidor de autorização RADIUS usa os seguintes atributos e sintaxe:

O servidor de autorização TACACS+ usa os seguintes atributos e sintaxe:

Os servidores RADIUS e TACACS+ também oferecem suporte a uma sintaxe simplificada onde você especifica cada expressão individual em uma linha separada. Por exemplo, a sintaxe simplificada do servidor RADIUS é:

Da mesma forma, a sintaxe simplificada do servidor TACACS+ é:

Tabela 3 diferencia a configuração de autorização local e a configuração de autorização de servidor TACACS+ usando expressões regulares.

Tabela 3: Amostra a configuração de autorização local e remota usando expressões regulares

Configuração local

Configuração remota do TACACS+

login {
    class local {
        permissions configure;
        allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)";
        deny-commands .*;
        allow-configuration "(interfaces .* unit 0 family ethernet-switching vlan mem.* .*)|(interfaces .* native.* .*)|(interfaces .* unit 0 family ethernet-switching interface-mo.* .*)|(interfaces .* unit .*)|(interfaces .* disable)|(interfaces .* description .*)|(vlans .* vlan-.* .*)"
        deny-configuration .*;
    }
}
user = remote {
    login = username
    service = junos-exec {
        allow-commands1 = "ping .*"
        allow-commands2 = "traceroute .*"
        allow-commands3 = "show .*"
        allow-commands4 = "configure"
        allow-commands5 = "edit"
        allow-commands6 = "exit"
        allow-commands7 = "commit"
        allow-commands8 = ".*xml-mode"
        allow-commands9 = ".*netconf.*"
        allow-commands10 = ".*need-trailer"
        allow-commands11 = "rollback.*"
        allow-commands12 = "junoscript"
        deny-commands1 = ".*"
        allow-configuration1 = "interfaces .* unit 0 family ethernet-switching vlan mem.* .*"
        allow-configuration2 = "interfaces .* native.* .*"
        allow-configuration3 = "interfaces .* unit 0 family ethernet-switching interface-mo.* .*"
        allow-configuration4 = "interfaces .* unit .*"
        allow-configuration5 = "interfaces .* disable"
        allow-configuration6 = "interfaces .* description .*"
        allow-configuration7 = "interfaces .*"
        allow-configuration8 = "vlans .* vlan-.* .*"
        deny-configuration1 = ".*"
        local-user-name = local-username
        user-permissions = "configure"
    }
}
Nota:
  • Você precisa permitir explicitamente o acesso ao modo NETCONF, local ou remotamente, emitindo os seguintes três comandos: xml-modeenetconfneed-trailer.

  • Ao usar a deny-configuration = ".*" declaração, você deve permitir todas as configurações desejadas usando a allow-configuration declaração. No entanto, essa configuração pode afetar o limite de buffer de expressões regulares permitido para a allow-configuration declaração. Se esse limite for excedido, a configuração permitida pode não funcionar.

Especifique expressões regulares

Aviso:

Ao especificar expressões regulares para comandos e declarações de configuração, preste muita atenção aos seguintes exemplos. Uma expressão regular com sintaxe inválida pode não produzir os resultados desejados, mesmo que a configuração seja cometida sem qualquer erro.

Você deve especificar expressões regulares para comandos e declarações de configuração da mesma maneira que executar o comando ou declaração completo. Tabela 4 lista as expressões regulares para configurar privilégios de acesso para as [edit interfaces] hierarquias e [edit vlans] declarações.

Tabela 4: Especifique expressões regulares

Declaração

Expressão regular

Notas de configuração

[edit interfaces]

O set comando para interfaces é executado da seguinte forma:

[edit]
user@host# set interfaces interface-name unit interface-unit-number

A set interfaces declaração está incompleta por si só e requer a opção unit de executar a declaração.

Como resultado, a expressão regular necessária para negar a set interfaces configuração deve especificar toda a cadeia executável com o .* operador no lugar de variáveis de declaração:

[edit system login class class-name]
user@host# set permissions configure
user@host# set deny-configuration "interfaces .* unit .*"
  • O .* operador denota tudo desde o ponto especificado em diante para esse comando ou declaração em particular. Neste exemplo, ele denota qualquer nome de interface com qualquer valor unitário.

  • Especificar apenas a deny-configuration "interfaces .*" declaração está incorreto e não nega o acesso à configuração das interfaces para a classe de login especificada.

  • Outras opções válidas podem ser incluídas na expressão regular. Por exemplo:

    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set deny-configuration "interfaces .* description .*"
    
    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]
    
    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration "interfaces .* unit 0 family ethernet-switching vlan mem.* .*"
    

    Nota: A mem.* expressão regular neste exemplo é usada quando espera-se que várias cordas que começam com a mem palavra-chave sejam incluídas na expressão regular especificada. Quando espera-se que apenas uma member corda seja incluída, a member .* expressão regular é usada.

[edit vlans]

O set comando para VLANs é executado da seguinte forma:

[edit]
user@host# set vlans vlan-name vlan-id vlan-id

Aqui, a set vlans declaração está incompleta por si só e requer a opção vlan-id de executar a declaração.

Como resultado, a expressão regular necessária para permitir a set vlans configuração deve especificar toda a cadeia executável com o .* operador no lugar de variáveis de declaração:

[edit system login class class-name]
user@host# set permissions configure
user@host# set allow-configuration "vlans .* vlan-id .*"
  • O .* operador denota tudo desde o ponto especificado em diante para esse comando ou declaração em particular. Neste exemplo, ele denota qualquer nome VLAN com qualquer ID VLAN.

  • Outras opções válidas na hierarquia da [edit vlans] declaração podem ser incluídas na expressão regular. Por exemplo:

    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration-regexps [ "vlans .* vlan-id .*" "vlans .* vlan-id .* description .*" "vlans .* vlan-id .* filter .*" ]
    

Operadores de expressões regulares

Tabela 5 lista operadores de expressão regular comuns que você pode usar para permitir ou negar modos operacionais e de configuração.

Comando expressões regulares implementam as expressões regulares estendidas (modernas), conforme definido no POSIX 1003.2.

Tabela 5: Operadores comuns de expressão regular

Operador

Jogo

Exemplo

|

Um dos dois ou mais termos separados pelo cano. Cada termo deve ser uma expressão autônoma completa em parênteses, sem espaços entre o cano e os parênteses adjacentes.

[edit system login class test]
user@host# set permissions configure
user@host# set allow-commands "(ping)|(traceroute)|(show system alarms)|(show system software)"
user@host# set deny-configuration "(access)|(access-profile)|(accounting-options)|(applications)|(apply-groups)|(bridge-domains)|(chassis)|(class-of-service)"

Com a configuração anterior, os usuários atribuídos à classe de login de teste têm acesso de modo operacional restrito apenas aos comandos especificados na allow-commands declaração. Eles também têm acesso ao modo de configuração, exceto os níveis de hierarquia especificados na deny-configuration declaração.

^

No início de uma expressão, costumava denotar onde o comando começa, onde pode haver alguma ambiguidade.

[edit system login class test]
user@host# set permissions interface
user@host# set permissions interface-control
user@host# set allow-commands "(^show) (log|interfaces|policer))|(^monitor)"

Com a configuração anterior, os usuários atribuídos à classe de login de teste têm acesso à visualização e configuração da configuração da interface. A allow-commands declaração concede acesso a comandos que começam com as showmonitor palavras-chave.

Para o primeiro filtro, os comandos especificados incluem , show logshow interfacese show policer comandos. O segundo filtro especifica todos os comandos que começam com a monitor palavra-chave, como os comandos ou os monitor interfacesmonitor traffic comandos.

$

Personagem no final de um comando. Costumava denotar um comando que deve ser combinado exatamente até aquele ponto.

[edit system login class test]
user@host# set permissions interface
user@host# set allow-commands "(show interfaces$)"

Com a configuração anterior, os usuários atribuídos à classe de login de teste podem visualizar a configuração das interfaces no modo de configuração. Os usuários também podem visualizar a configuração da interface com o comando do show configuration modo operacional. No entanto, a expressão regular especificada na allow-commands declaração restringe os usuários a executar apenas o show interfaces comando e nega o acesso a extensões de comando como show interfaces detail ou show interfaces extensive.

[ ]

Variedade de letras ou dígitos. Para separar o início e o fim de uma faixa, use um hífen (- ).

[edit system login class test]
user@host# set permissions clear
user@host# set permissions configure
user@host# set permissions network
user@host# set permissions trace
user@host# set permissions view
user@host# set allow-configuration-regexps [ "interfaces [gx]e-.* unit [0-9]* description .*" ]

Com a configuração anterior, os usuários atribuídos à classe de login de teste têm permissões de usuário no nível do operador. Esses usuários também têm acesso para configurar interfaces dentro da faixa especificada de nome da interface e número de unidade (0 a 9).

( )

Um grupo de comandos indicando uma expressão completa e autônoma a ser avaliada. O resultado é então avaliado como parte da expressão geral. Os parênteses devem ser usados em conjunto com as operadoras de pipe, conforme explicado.

[edit system login class test]
user@host# set permissions all
user@host# set allow-commands "(clear)|(configure)"
user@host# deny-commands "(mtrace)|(start)|(delete)"

Com a configuração acima, os usuários atribuídos à classe de login de teste têm permissões de nível de superusuário e têm acesso aos comandos especificados na allow-commands declaração.

*

Zero ou mais termos.

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m*)"

Com a configuração acima, os usuários atribuídos à classe de login de teste cujo nome de usuário de login começa são m negados acesso de configuração.

+

Um ou mais termos.

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m+)"

Com a configuração acima, os usuários atribuídos à classe de login de teste cujo nome de usuário de login começa são m negados acesso de configuração.

.

Qualquer personagem, exceto um espaço" ".

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m.)"

Com a configuração acima, os usuários atribuídos à classe de login de teste cujo nome de usuário de login começa são m negados acesso de configuração.

.*

Tudo desde o ponto especificado em diante.

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m .*)"

Com a configuração acima, os usuários atribuídos à classe de login de teste cujo nome de usuário de login começa são m negados acesso de configuração.

Da mesma forma, a deny-configuration "protocols .*" declaração nega todo o acesso de configuração no nível hierárquica [edit protocols] .

Nota:
  • .+E as *operações podem ser alcançadas usando.*.

  • A e deny-configuration .* as deny-commands .* declarações negam o acesso a todos os comandos de modo operacional e hierarquias de configuração, respectivamente.

Nota:

O ! operador de expressão regular não tem suporte.

Exemplos de expressão regulares

Tabela 6 lista as expressões regulares usadas para permitir opções de configuração em duas hierarquias[edit system ntp server] de configuração e [edit protocols rip], como exemplo, especificar expressões regulares.

Nota:

Tabela 6 não fornece uma lista abrangente de todas as expressões e palavras-chave regulares para todas as declarações e hierarquias de configuração. As expressões regulares listadas na tabela são validadas apenas para as [edit system ntp server] hierarquias e [edit protocols rip] declarações.

Tabela 6: Exemplos de expressões regulares

Hierarquia de declarações

Expressões regulares

Configuração permitida

Configuração negada

[edit system ntp server]

     

Chave key-number

[edit system login class test]
set permissions configure
set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* key .*" ]
set deny-configuration-regexps [ "system ntp server .* version .*" "system ntp server .* prefer" ]
  • IP do servidor

  • IP do servidor e chave

  • Versão

  • Preferem

Versão version-number

[edit system login class test]
set permissions configure
set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* version .*" ]
set deny-configuration-regexps [ "system ntp server .* key .*" "system ntp server .* prefer" ]
  • IP do servidor

  • IP do servidor e versão

  • Chave

  • Preferem

Preferem

[edit system login class test]
set permissions configure
set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* prefer" ];
set deny-configuration-regexps [ "system ntp server .* key .*" "system ntp server .* version .*" ]
  • IP do servidor

  • IP do servidor e prefira

  • Chave

  • Versão

[edit protocols rip]

     

tamanho de mensagem message-size

[edit system login class test]
set permissions configure
set allow-configuration-regexps "protocols rip message-size .*"
set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip route-timeout .*" "protocols rip update-interval .*" ]
  • tamanho de mensagem

  • métrica

  • tempo limite de roteamento

  • intervalo de atualização

métrica metric-in

[edit system login class test]
set permissions configure
set  allow-configuration-regexps "protocols rip metric-in .*"
set  deny-configuration-regexps [ "protocols rip message-size .*" "protocols rip route-timeout .*" "protocols rip update-interval .*" ]
  • métrica

  • tamanho de mensagem

  • tempo limite de roteamento

  • intervalo de atualização

tempo limite de roteamento route-timeout

[edit system login class test]
set permissions configure
set allow-configuration-regexps "protocols rip route-timeout .*"
set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip message-size .*" "protocols rip update-interval .*" ]
  • tempo limite de roteamento

  • tamanho de mensagem

  • métrica

  • intervalo de atualização

intervalo de atualização update-interval

[edit system login class test]
set permissions configure
set allow-configuration-regexps "protocols rip update-interval .*"
set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip route-timeout .*" "protocols rip message-size .*" ]
  • intervalo de atualização

  • tamanho de mensagem

  • métrica

  • tempo limite de roteamento

Como definir privilégios de acesso com declarações de configuração e negação de permissão

Você pode definir privilégios de acesso para hierarquias de declaração de configuração usando uma combinação dos seguintes tipos de declarações:

  • bandeiras de permissão

  • allow-configuration e deny-configuration declarações

As bandeiras de permissão definem os limites maiores do que uma pessoa ou classe de login pode acessar e controlar. As allow-configuration declarações e deny-configuration declarações contêm uma ou mais expressões regulares que permitem ou negam hierarquias e declarações de configuração específicas. As allow-configuration declarações e deny-configuration as declarações têm precedência sobre bandeiras de permissão e dão ao administrador um controle mais fino sobre exatamente quais hierarquias e declarações o usuário pode visualizar e configurar.

Este tópico explica como definir privilégios de acesso usando allow-configuration e deny-configuration declarações mostrando exemplos de configurações de classe de login que usam essas declarações. Exemplos de 1 a 3 criam aulas de login que permitem aos usuários acesso a todos os comandos e declarações, exceto os definidos na deny-configuration declaração.

Observe que a bit de permissão e a bandeira de permissão são usadas de maneira intercambiável.

Exemplo 1

Para criar uma classe de login que permita ao usuário executar todos os comandos e configurar tudo, exceto parâmetros de telnet:

  1. Defina as permissões de classe de login do usuário para all.
  2. Inclua a declaração a seguir deny-configuration .

Exemplo 2

Criar uma aula de login que permita ao usuário executar todos os comandos e configurar tudo, exceto declarações em qualquer classe de login cujo nome começa com "m":

  1. Defina as permissões de classe de login do usuário para all.

  2. Inclua a declaração a seguir deny-configuration .

Exemplo 3

Criar uma classe de login que permita ao usuário executar todos os comandos e configurar tudo, exceto os [edit system login class] níveis de hierarquia ou [edit system services] :

  1. Defina as permissões de classe de login do usuário para all.

  2. Inclua a declaração a seguir deny-configuration :

Os exemplos a seguir mostram como usar as declarações e deny-configuration declarações allow-configuration para determinar permissões inversas entre si para o nível de [edit system services] hierarquia.

Exemplo 4

Para criar uma classe de login que permita que o usuário tenha privilégios de configuração completos apenas no nível de [edit system services] hierarquia:

  1. Defina as permissões de classe de login do usuário para configure.

  2. Inclua a declaração a seguir allow-configuration :

Exemplo 5

Para criar uma classe de login que permita ao usuário permissões completas para todos os comandos e todas as hierarquias de configuração, exceto o nível de [edit system services] hierarquia:

  1. Defina as permissões de classe de login do usuário para all.

  2. Inclua a declaração a seguir deny-configuration .

Exemplo: Use a lógica aditiva com expressões regulares para especificar privilégios de acesso

Este exemplo mostra como usar a lógica aditiva ao usar expressões regulares para configurar privilégios de acesso de configuração.

Requisitos

Este exemplo usa um dispositivo que executa o Junos OS Release 16.1 ou posterior.

Visão geral

Você pode definir expressões regulares para controlar quem pode fazer mudanças na configuração e o que elas podem mudar. Essas expressões regulares indicam hierarquias de configuração específicas que os usuários de uma classe de login podem acessar. Por exemplo, você pode definir expressões regulares que permitem que os usuários modifiquem um grupo de instâncias de roteamento e definam expressões regulares que impedem os usuários de fazer alterações em quaisquer outras instâncias de roteamento ou para outros níveis de configuração. Você define as expressões regulares configurando as e deny-configuration-regexps declarações allow-configuration-regexps para uma aula de login.

Por padrão, a deny-configuration-regexps declaração tem precedência sobre a allow-configuration-regexps declaração. Se uma hierarquia de configuração aparecer em uma deny-configuration-regexps declaração para uma aula de login, ela não será visível para os usuários dessa classe, independentemente do conteúdo da allow-configuration-regexps declaração. Se uma hierarquia de configuração não aparecer em uma deny-configuration-regexps declaração, ela será visível para os usuários dessa classe se ela aparecer em uma declaração allow-configuration-regexps .

Você pode mudar esse comportamento padrão permitindo a lógica aditiva para as *-configuration-regexps declarações. Ao ativar a lógica aditiva, a allow-configuration-regexps declaração tem precedência sobre a deny-configuration-regexps declaração.

Assim, se a deny-configuration-regexps declaração negar acesso a todas as hierarquias de configuração em um determinado nível (protocolos .*), mas a allow-configuration-regexps declaração permitir o acesso a uma sub-hierarquia (protocolos bgp .*), então, por padrão, o dispositivo nega acesso às hierarquias para usuários nessa classe de login porque a deny-configuration-regexps declaração tem precedência. No entanto, se você habilitar a lógica aditiva, o dispositivo permite o acesso à sub-hierarquia especificada para usuários nessa classe de login, porque isso allow-configuration-regexps tem precedência neste caso.

Configuração

Procedimento passo a passo

Para permitir que a lógica aditiva permita explicitamente que os usuários em uma determinada classe de login tenham acesso a uma ou mais hierarquias de configuração individuais:

  1. Inclua a deny-configuration-regexps declaração e negue explicitamente o acesso a hierarquias de configuração.

    Por exemplo:

  2. Inclua a allow-configuration-regexps declaração e defina expressões regulares para que as hierarquias específicas permitam.

    Por exemplo:

  3. Habilite uma lógica aditiva para as allow-configuration-regexps expressões regulares.deny-configuration-regexps

  4. Atribuir a aula de login a um ou mais usuários.

  5. Comprometa suas mudanças.

    Os usuários atribuídos a esta classe de login têm acesso às hierarquias de configuração incluídas na allow-configuration-regexps declaração, mas não têm acesso às outras hierarquias especificadas na deny-configuration-regexps declaração.

Nota:

Ao configurar a regex-additive-logic declaração, a mudança de comportamento se aplica a todas e deny-configuration-regexpsallow-configuration-regexps declarações presentes em todas as aulas de login. Se você habilitar a lógica aditiva, você deve avaliar as declarações existentes para qualquer impacto e atualizar as expressões regulares nessas declarações conforme apropriado.

Exemplos

Use expressões regulares com lógica aditiva

Propósito

Esta seção fornece exemplos de expressões regulares que usam lógica aditiva para oferecer ideias para criar configurações apropriadas para o seu sistema.

Permitir instâncias de roteamento específicas

A classe de login do exemplo a seguir inclui uma expressão regular que permite a configuração de instâncias de roteamento cujos nomes começam com CUST-VRF-; por exemplo, CUST-VRF-1, CUST-VRF-25e CUST-VRF-100assim por diante. O exemplo também inclui uma expressão regular que impede a configuração de quaisquer instâncias de roteamento.

Por padrão, a deny-configuration-regexps declaração tem precedência, e a configuração anterior impede que os usuários da classe de login configurem quaisquer instâncias de roteamento, independentemente do nome.

No entanto, se você configurar a declaração a seguir, a allow-configuration-regexps declaração tem precedência. Assim, os usuários podem configurar instâncias de roteamento cujos nomes começam com CUST-VRF-, mas os usuários não podem configurar nenhuma outra instância de roteamento.

Permitir apenas a configuração de peer BGP

A classe de login do exemplo a seguir inclui expressões regulares que impedem a configuração no nível da hierarquia, mas permitem a [edit protocols] configuração de pares BGP:

Por padrão, a configuração anterior impede que os usuários da classe de login faça alterações em quaisquer hierarquias abaixo [edit protocols].

No entanto, se você configurar a declaração a seguir, os usuários da classe de login podem fazer alterações em pares BGP, mas os usuários não podem configurar outros protocolos ou outras declarações BGP fora do nível de hierarquia permitido.

Verificação

Para verificar se você definiu corretamente os privilégios de acesso:

  1. Configure uma aula de login e cometa as alterações.

  2. Atribua a aula de login a um username.

  3. Faça login como atribuído username com a nova classe de login.

  4. Tente configurar os níveis de hierarquia permitidos.

    • Você deve ser capaz de configurar declarações em níveis de hierarquia que foram permitidos.

    • Os níveis de hierarquia negados não devem ser visíveis.

    • Quaisquer expressões permitidas ou negadas devem prevalecer sobre quaisquer permissões concedidas com a permissions declaração.

Exemplo: Configure permissões de usuário com privilégios de acesso para comandos de modo operacional

Este exemplo mostra como configurar aulas de login personalizadas e atribuir privilégios de acesso para comandos de modo operacional. Os usuários da classe de login podem executar apenas os comandos para os quais têm acesso. Isso impede que usuários não autorizados executem comandos sensíveis que podem causar danos à rede.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Um dispositivo da Juniper Networks

  • Um servidor TACACS+ (ou RADIUS)

Antes de começar, estabeleça uma conexão TCP entre o dispositivo e o servidor TACACS+. No caso do servidor RADIUS, estabeleça uma conexão UDP entre o dispositivo e o servidor RADIUS.

Visão geral e topologia

Figura 1 ilustra uma topologia simples, na qual o roteador R1 é um dispositivo da Juniper Networks e tem uma conexão TCP estabelecida com um servidor TACACS+.

Figura 1: Topologia Topologia

Este exemplo configura R1 com três aulas de login personalizadas: Classe 1, Classe2 e Classe3. Cada classe define privilégios de acesso para o usuário configurando a permissions declaração e definindo expressões regulares estendidas usando as declarações e deny-commands declaraçõesallow-commands.

A finalidade de cada aula de login é a seguinte:

  • Class1— Define privilégios de acesso apenas para o usuário com a allow-commands declaração. Esta aula de login oferece permissões e autorização para o usuário no nível do operador para reinicializar o dispositivo.

  • Class2— Define privilégios de acesso apenas para o usuário com a deny-commands declaração. Esta aula de login oferece permissões de usuário no nível do operador e nega acesso a set comandos.

  • Class3— Define privilégios de acesso para o usuário com as declarações e deny-commands declaraçõesallow-commands. Esta aula de login oferece permissões e autorização para usuários de nível superusuário para acessar interfaces e visualizar informações de dispositivos. Ele também nega acesso aos comandos e configure à edit rede.

O roteador R1 tem três usuários diferentes, User1, User2 e User3 atribuídos às aulas de login classe1, Class2 e Class3, respectivamente.

Configuração

Configuração rápida de CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos no CLI no nível de [edit] hierarquia e, em seguida, entrar commit no modo de configuração.

R1

Configure parâmetros de autenticação para roteador R1

Procedimento passo a passo

Para configurar a autenticação R1 do roteador:

  1. Configure a ordem na qual R1 tenta autenticar o usuário. Neste exemplo, a autenticação do servidor TACACS+ é primeiro, seguida pela autenticação do servidor RADIUS e depois pela senha local.

  2. Configure o servidor TACACS+.

  3. Configure o servidor RADIUS.

  4. Configure parâmetros de contabilidade R1.

Configure privilégios de acesso com a Declaração de comandos (Class1)

Procedimento passo a passo

Especificar expressões regulares usando a allow-commands declaração:

  1. Configure a classe de login Class1 e atribua permissões de usuário em nível de operador.

  2. Configure a allow-commands expressão regular para permitir que os usuários da classe reinicializem o dispositivo.

  3. Configure a conta do usuário para a classe de login Class1.

Configure privilégios de acesso com a Declaração de comandos de negação (Class2)

Procedimento passo a passo

Especificar expressões regulares usando a deny-commands declaração:

  1. Configure a classe de login Class2 e atribua permissões de usuário em nível de operador.

  2. Configure a deny-commands expressão regular para impedir que os usuários da classe executem set comandos.

  3. Configure a conta do usuário para a classe de login Class2.

Configure privilégios de acesso com as Declarações de comandos de permissão e negação (Class3)

Procedimento passo a passo

Especificar expressões regulares usando as declarações e deny-commands as allow-commands declarações:

  1. Configure a classe de login Class3 e atribua permissões de nível de superusuário.

  2. Configure a deny-commands expressão regular para impedir que os usuários da classe executem quaisquer comandos.

  3. Configure a allow-commands expressão regular para permitir que os usuários entrem no modo de configuração.

  4. Configure a conta do usuário para a classe de login Class3.

Resultados

No modo de configuração, confirme sua configuração entrando no show system comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Verificação

Faça login como o nome de usuário atribuído com a nova classe de login e confirme que a configuração está funcionando corretamente.

Verificando a configuração class1

Propósito

Verifique se as permissões e comandos permitidos na classe de login Class1 estão funcionando.

Ação

No modo operacional, execute o show system users comando.

No modo operacional, execute o request system reboot comando.

Significado

A classe de login Class1 à qual o Usuário1 é atribuído tem permissões de usuário no nível do operador e permite que os usuários da classe executem o request system reboot comando.

A classe de login do operador predefinido tem as seguintes bandeiras de permissão especificadas:

  • clear— Pode usar clear comandos para limpar (excluir) informações que o dispositivo aprende com a rede e armazena em vários bancos de dados de rede.

  • network— Pode acessar a rede usando osping, sshe telnettraceroute comandos.

  • reset— Pode reiniciar processos de software usando o restart comando.

  • trace— pode visualizar configurações de arquivo de rastreamento e configurar propriedades de arquivo de rastreamento.

  • view— pode usar vários comandos para exibir a tabela de roteamento atual em todo o sistema e valores e estatísticas específicos do protocolo. Não é possível visualizar a configuração secreta.

Para a classe de login Class1, além das permissões de usuário mencionadas acima, o User1 pode executar o request system reboot comando. A primeira saída exibe as permissões de visualização como um operador, e a segunda saída mostra que o único request system comando que o User1 pode executar como operador é o request system reboot comando.

Verificando a configuração class2

Propósito

Verifique se as permissões e comandos permitidos para a classe de login Class2 estão funcionando.

Ação

No modo operacional, execute o ping comando.

A partir do aviso de CLI, verifique os comandos disponíveis.

A partir do prompt CLI, execute qualquer comando definido.

Significado

A classe de login Class2 à qual o Usuário2 é atribuído tem permissões de usuário no nível do operador e nega acesso a todos os set comandos.

As bandeiras de permissão especificadas para a classe de login do operador predefinido são as mesmas especificadas para o Class1.

Verificando a configuração da classe3

Propósito

Verifique se as permissões e comandos permitidos para a classe de login Class3 estão funcionando.

Ação

No modo operacional, verifique os comandos disponíveis.

Insira o modo de configuração.

Significado

A classe de login Class3 à qual o Usuário3 é atribuído tem permissões de superusuário (todos), mas essa classe só permite que os usuários executem o configure comando. A classe nega acesso a todos os outros comandos de modo operacional. Como as expressões regulares especificadas nas allow/deny-commands declarações têm precedência sobre as permissões do usuário, o User3 no R1 tem acesso apenas ao modo de configuração e tem acesso negado a todos os outros comandos de modo operacional.

Exemplo: Configure permissões de usuário com privilégios de acesso para declarações de configuração e hierarquias

Este exemplo mostra como configurar aulas de login personalizadas e atribuir privilégios de acesso a hierarquias de configuração específicas. Os usuários da classe de login podem visualizar e modificar apenas essas declarações de configuração e hierarquias às quais têm acesso. Isso impede que usuários não autorizados modifiquem configurações de dispositivos que possam causar danos à rede.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Um dispositivo da Juniper Networks

  • Um servidor TACACS+ (ou RADIUS)

Antes de começar, estabeleça uma conexão TCP entre o dispositivo e o servidor TACACS+. No caso do servidor RADIUS, estabeleça uma conexão UDP entre o dispositivo e o servidor RADIUS.

Visão geral e topologia

Figura 2 ilustra uma topologia simples, na qual o roteador R1 é um dispositivo da Juniper Networks e tem uma conexão TCP estabelecida com um servidor TACACS+.

Figura 2: Topologia Topologia

Este exemplo configura R1 com duas aulas de login personalizadas: Classe 1 e Classe2. Cada classe define privilégios de acesso para o usuário configurando a permissions declaração e definindo expressões regulares estendidas usando, deny-configurationallow-configuratione allow-configuration-regexpsdeny-configuration-regexps declarações.

A finalidade de cada aula de login é a seguinte:

  • Class1— Define privilégios de acesso para o usuário com as declarações e deny-configuration declaraçõesallow-configuration. Essa aula de login oferece acesso apenas para configurar a [edit interfaces] hierarquia e nega todo o acesso no dispositivo. Para isso, as permissões do usuário incluem configure fornecer acesso de configuração. Além disso, a allow-configuration declaração permite o acesso à configuração das interfaces, e a deny-configuration declaração nega acesso a todas as outras hierarquias de configuração. Como a declaração de permissão tem precedência sobre a declaração de negação, os usuários atribuídos à classe de login Class1 podem acessar apenas o nível de [edit interfaces] hierarquia.

  • Class2— Define privilégios de acesso para o usuário com as declarações e deny-configuration-regexps declaraçõesallow-configuration-regexps. Essa aula de login oferece permissões de usuário de nível superusuário e permite explicitamente a configuração em vários níveis de hierarquia para interfaces. Também nega acesso aos níveis de [edit system][edit protocols] hierarquia.

O roteador R1 tem dois usuários, User1 e User2, atribuídos às aulas de login classe 1 e Class2, respectivamente.

Configuração

Configuração rápida de CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos no CLI no nível de [edit] hierarquia e, em seguida, entrar commit no modo de configuração.

R1

Configure parâmetros de autenticação para roteador R1

Procedimento passo a passo

Para configurar a autenticação R1 do roteador:

  1. Configure a ordem na qual R1 tenta autenticar o usuário. Neste exemplo, a autenticação do servidor TACACS+ é primeiro, seguida pela autenticação do servidor RADIUS e depois pela senha local.

  2. Configure o servidor TACACS+.

  3. Configure o servidor RADIUS.

  4. Configure os parâmetros de contabilidade R1.

Configure privilégios de acesso com as Declarações de configuração de permissão e negação (Class1)

Procedimento passo a passo

Para especificar expressões regulares usando as declarações e deny-configuration declaraçõesallow-configuration:

  1. Configure a aula de login class1 com configure permissões.

  2. Configure a allow-configuration expressão regular para permitir que os usuários da classe visualizem e modifiquem parte do [edit interfaces] nível de hierarquia.

  3. Configure a deny-configuration expressão regular para negar o acesso a todas as hierarquias de configuração.

  4. Configure a conta do usuário para a classe de login Class1.

Configure privilégios de acesso com as declarações de permitir configuração-regexps e negar configuração-regexps (Class2)

Procedimento passo a passo

Para especificar expressões regulares usando as declarações e deny-configuration-regexps declaraçõesallow-configuration-regexps:

  1. Configure a classe de login Class2 e atribua permissões ao superusuário (todos).

  2. Configure a allow-configuration-regexps expressão regular para permitir que os usuários da classe acessem várias hierarquias sob o nível hierárquico [edit interfaces] .

  3. Configure a deny-configuration-regexps expressão regular para impedir que os usuários da classe visualizam ou modifiquem a configuração nos [edit system] níveis de hierarquia.[edit protocols]

  4. Configure a conta do usuário para a classe de login Class2.

Resultados

No modo de configuração, confirme sua configuração entrando no show system comando. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Verificação

Faça login como o nome de usuário atribuído com a nova classe de login e confirme que a configuração está funcionando corretamente.

Verifique a configuração do Class1

Propósito

Verifique se as permissões permitidas na classe 1 estão funcionando.

Ação

No modo operacional, verifique os comandos disponíveis.

No modo de configuração, verifique as permissões de configuração disponíveis.

Significado

O User1 tem configure permissões de usuário, como visto na primeira saída. Além disso, no modo de configuração, o Usuário1 tem acesso ao nível de interfaces hierarquia, mas apenas a esse nível de hierarquia, como visto na segunda saída.

Verifique a configuração da classe 2

Propósito

Verifique se a configuração da Classe 2 está funcionando como esperado.

Ação

No modo de configuração, acesse a interfaces configuração.

No modo de configuração, acesse as system hierarquias de configuração.protocols

Significado

O User2 tem permissões para configurar interfaces em R1, mas o usuário não tem permissão para visualizar ou modificar os níveis de [edit system][edit protocols] hierarquia.

Tabela de histórico de liberação
Versão
Descrição
18.1
A partir do Junos OS Release 18.1, as declarações e deny-commands-regexps o allow-commands-regexps suporte para a autorização do TACACS+.