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 do Junos OS

O Junos OS permite que você conceda o acesso ou permissões aos comandos e aos níveis e declarações da hierarquia de configuração. Com isso, os usuários podem executar apenas esses comandos e configurar e exibir apenas as declarações para as quais tenham privilégios de acesso. Você pode usar expressões regulares estendidas para especificar quais comandos de modo operacional, declarações de configuração e hierarquias são recusadas ou permitidas para os usuários. Isso impede que usuários não autorizados executem ou configurem comandos e declarações confidenciais que podem causar danos à rede. Leia este tópico para obter mais informações.

Entender os níveis de privilégios de acesso do Junos OS

Cada comando CLI de nível superior e cada instrução de configuração têm um nível de privilégios de acesso associado a eles. Os usuários só podem executar esses comandos e configurar e exibir apenas aquelas declarações para as quais tenham privilégios de acesso. Os privilégios de acesso de cada classe de login são definidos por uma ou mais bandeiras de permissão.

Para cada classe de login, você pode negar ou permitir explicitamente o uso de comandos de modo operacional e de configuração que seriam permitidos ou não por um nível de privilégios especificado na permissions declaração.

As seções a seguir fornecem informações adicionais sobre permissões:

Bandeiras de permissão de classe de login do Junos OS

Os sinalizadores de permissão são usados para conceder a um usuário acesso a comandos do modo operacional e aos níveis e declarações da hierarquia de configuração. Ao especificar um sinal de permissão específico na classe de login do usuário no nível da hierarquia, você concederá ao usuário acesso aos níveis e declarações da hierarquia de configuração e comandos [edit system login class] correspondentes. Para conceder acesso a todos os comandos e declarações de configuração, use all o sinal de permissões.

Nota:

Cada comando listado representa esse comando e todas as subcomandações com esse comando como prefixo. Cada instrução de configuração listada representa o topo da hierarquia de configuração à qual essa bandeira dá acesso.

A permissions declaração especifica um ou mais dos sinalizadores de permissão indicados em Tabela 1 . As bandeiras de permissão não são acumuladas, portanto, para cada classe, você deve listar todas as bandeiras de permissão necessárias, incluindo a exibição de informações e o modo viewconfigure de configuração. Duas formas de controle de permissões para partes individuais da configuração são:

  • formulário "simples" — Fornece capacidade de somente leitura para esse tipo de permissão. Um exemplo é interface .

  • Formulário que termina em — Fornece capacidade de leitura -control e gravação para esse tipo de permissão. Um exemplo é interface-control .

Para bandeiras de permissão que concedam acesso a níveis e declarações de hierarquia de configuração, as bandeiras concederão privilégios somente de leitura a essa configuração. Por exemplo, o interface sinal de permissões dá acesso somente a leitura ao nível da [edit interfaces] hierarquia. A -control forma da bandeira dá acesso a leitura e gravação a essa configuração. Usando o exemplo anterior, interface-control concederá acesso de leitura e gravação ao nível [edit interfaces] da hierarquia.

Tabela 1 lista os sinalizadores de permissão de classe de login do Junos OS que você pode configurar incluindo a permissions instrução no nível [edit system login class class-name] da hierarquia.

As bandeiras de permissão concederão um conjunto específico de privilégios de acesso. Cada bandeira de permissão é listada com os comandos do modo operacional e os níveis e as declarações da hierarquia de configuração para os quais esse sinal dá acesso.

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

Sinal de permissão

Descrição

Acesso

É possível ver a configuração de acesso no modo de configuração e com o comando show configuration modo operacional.

controle de acesso

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

Admin

É possível ver as informações da conta do usuário no modo de configuração e com o comando show configuration modo operacional.

controle de administração

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

controle total

Pode exibir as contas dos usuários e configurá-las em [edit system login] nível de hierarquia.

all

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

Claro

É possível eliminar (excluir) informações aprendidas da rede armazenadas em vários bancos de dados de rede usando os clear comandos.

Configurar

Pode entrar no modo de configuração usando o configure comando.

Controle

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

Campo

É possível exibir comandos de depuração de campo. Reservado para suporte de depuração.

Firewall

É possível ver a configuração do filtro de firewall no modo de configuração.

controle de firewall

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

Disquete

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

flow-tap

É possível ver a configuração flow-tap no modo de configuração.

flow-tap-control

Pode exibir a configuração de flow-tap no modo de configuração e configurar informações de configuração de flow-tap no nível [edit services flow-tap] da hierarquia.

operação flow-tap

Pode fazer solicitações de toque de fluxo para o roteador ou switch. Por exemplo, um cliente do Dynamic Tasking Control Protocol (DTCP) precisa ter permissão para autenticar-se no flow-tap-operation Junos OS como usuário administrativo.

Nota:

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

operação idp-profiler

Pode exibir dados do profiler.

Interface

É possível ver a configuração da interface no modo de configuração e com o comando show configuration modo operacional.

controle de interface

É possível exibir informações de configuração de chassi, classe de serviço (CoS), grupos, opções de encaminhamento e informações de configuração de interfaces. É possível editar a configuração nos seguintes níveis de hierarquia:

  • [edit chassis]

  • [edit class-of-service]

  • [edit groups]

  • [edit forwarding-options]

  • [edit interfaces]

Manutenção

Pode realizar manutenção do sistema, incluindo iniciar um shell local no roteador ou switch e se tornar o superusuário na camada usando o comando, e pode interromper e reinicializar o roteador ou switch usando os su rootrequest system comandos.

Rede

Pode acessar a rede usando os pingssh comandos , e telnet . traceroute

espelhamento de sessão pgcp

É possível ver a pgcp configuração de espelhamento de sessões.

pgcp-session-mirroring-control

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

Redefinir

É possível reinicializar os processos de software usando o comando e configurar se os processos de software estão ativados ou restart inválidos em nível de [edit system processes] hierarquia.

Reversão

Pode usar o rollback comando para retornar a uma configuração previamente comprometida que não a mais recente comprometida.

roteamento

É possível ver informações gerais de configuração de políticas de roteamento, roteamento e roteamento nos modos de configuração e operação.

roteamento-controle

É possível exibir informações gerais de configuração de roteamento, protocolo de roteamento e política de roteamento e configurar roteamento geral no nível da hierarquia, protocolos de roteamento no nível da hierarquia e política de roteamento no nível [edit routing-options][edit protocols] da [edit policy-options] hierarquia.

Segredo

É possível ver senhas e outras chaves de autenticação na configuração.

controle secreto

É possível ver senhas e outras chaves de autenticação na configuração e modificá-las no modo de configuração.

Segurança

É possível ver a configuração de segurança no modo de configuração e com o comando show configuration do modo operacional.

controle de segurança

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

Shell

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

Snmp

É possível exibir informações de configuração do Protocolo de Gerenciamento de Rede Simples (SNMP) nos modos de configuração e operação.

snmp-control

Pode exibir informações de configuração de SNMP e modificar a configuração de SNMP em [edit snmp] nível de hierarquia.

Sistema

É possível exibir informações em nível de sistema nos modos de configuração e operacional.

controle do sistema

Pode exibir informações de configuração no nível do sistema e configurá-la em [edit system] nível de hierarquia.

Rastreamento

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

controle de rastreamento

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

Ver

Pode usar vários comandos para exibir estatísticas e valores e estatísticas atuais em toda a rede, tabela de roteamento e dados e estatísticas específicos do protocolo. Não é possível ver a configuração secreta.

configuração de exibição

É possível ver toda a configuração, exceto segredos, scripts do sistema e opções de evento.

Nota:

Somente usuários com a maintenance permissão podem exibir configuração de script de commit, op ou script de evento.

Permitindo ou negando comandos individuais para classes de login do Junos OS

Por padrão, todos os comandos de CLI de nível superior associaram níveis de privilégios de acesso. Os usuários só podem executar esses comandos e exibir apenas as declarações para as quais tenham privilégios de acesso. Para cada classe de login, você pode negar ou permitir explicitamente o uso de comandos de modo operacional e de configuração que seriam permitidos ou não por um nível de privilégios especificado na permissions declaração.

Os sinalizadores de permissão são usados para conceder a um usuário acesso a comandos do modo operacional e aos níveis e declarações da hierarquia de configuração. Ao especificar um sinal de permissão específico na classe de login do usuário no nível da hierarquia, você concederá ao usuário acesso aos níveis e declarações da hierarquia de configuração e comandos [edit system login class] correspondentes. Para conceder acesso a todos os comandos e declarações de configuração, use all o sinal de permissões. Para bandeiras de permissão que concedam acesso a níveis e declarações de hierarquia de configuração, as bandeiras concederão privilégios somente de leitura a essa configuração. Por exemplo, o interface sinal de permissões dá acesso somente a leitura ao nível da [edit interfaces] hierarquia. A -control forma da bandeira dá acesso a leitura e gravação a essa configuração. Usando o exemplo anterior, interface-control concederá acesso de leitura e gravação ao nível [edit interfaces] da hierarquia.

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

  • Expressões usadas para permitir e negar comandos para usuários em RADIUS e servidores TACACS+ foram simplificadas. Em vez de uma única e longa expressão com vários comandos ( ), você allow-commands=cmd1 cmd2 ... cmdn pode especificar cada comando como uma expressão separada. Essa nova sintaxe é válida para todos os bits de permissão allow-configurationdeny-configuration do allow-commandsdeny-commands usuário.

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

  • Se você permitir e negar os mesmos comandos, as permissões têm precedência sobre as allow-commands permissões especificadas pelo deny-commands . Por exemplo, se você incluir e , o usuário da classe allow-commands "request system software add" de login tiver permissão para instalar software usando o deny-commands "request system software add"request system software add comando.

  • Expressões regulares allow-commands para e também podem incluir os comandos , deny-commandscommitloadrollback , savestatusupdate

  • Se você especificar uma expressão regular para e com duas variantes diferentes de um comando, a combinação mais longa allow-commands sempre será deny-commands executada.

    Por exemplo, se você especificar uma expressão regular para com o comando e uma expressão regular para com o comando, os usuários atribuídos a essa classe de login poderão emitir o comando, mas não o allow-commandscommit-synchronizedeny-commandscommitcommit synchronizecommit comando. Isso se deve ao fato de ser a combinação mais longa entre e ele especificado commit-synchronizecommit para commit-synchronizeallow-commands .

    Da mesma forma, se você especificar uma expressão regular para com o comando e uma expressão regular para com o comando, os usuários atribuídos a essa classe de login poderão emitir o comando, mas não o allow-commandscommitdeny-commandscommit-synchronizecommitcommit-synchronize comando. Isso se deve ao fato de ser a combinação mais longa entre e ele especificado commit-synchronizecommit para commit-synchronizedeny-commands .

Exemplo: Configuração de permissões de usuário com níveis de privilégios de acesso

Este exemplo mostra como exibir permissões para uma conta de usuário e configurar as permissões do usuário com privilégios de acesso para uma classe de login. Com isso, os usuários podem executar apenas esses comandos e configurar e exibir apenas as declarações para as quais tenham privilégios de acesso. Isso impede que usuários não autorizados executem ou configurem comandos e declarações confidenciais que podem causar danos à rede.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Um Juniper Networks de segurança

  • Um servidor TACACS+ (ou RADIUS)

  • Construção do Junos OS em execução no Juniper Networks dispositivo

Antes de começar:

  • Estabelecer conexão entre o dispositivo e o servidor TACACS+.

    Para obter informações sobre a configuração de um servidor TACACS+, consulte Configurar autenticação TACACS+.

  • Configure pelo menos um usuário atribuído a uma classe de login no Juniper Networks dispositivo. Pode haver mais de uma classe de login, cada uma com várias configurações de permissão e mais de um usuário no dispositivo.

Visão geral

Cada comando da interface de linha de comando (CLI) de nível superior e cada instrução de configuração do Junos OS tem um nível de privilégios de acesso associado a ele. Para cada classe de login, você pode negar ou permitir explicitamente o uso de comandos de modo operacional e de configuração que seriam permitidos ou não por um nível de privilégios. Os usuários só podem executar esses comandos e configurar e exibir apenas aquelas declarações para as quais tenham privilégios de acesso. Para configurar níveis de privilégios de acesso, inclua permissions a declaração em nível de [edit system login class class-name] hierarquia.

Os privilégios de acesso de cada classe de login são definidos por um ou mais sinalizadores de permissão especificados na permissions declaração. Os sinalizadores de permissão são usados para conceder a um usuário acesso a comandos, declarações e hierarquias de configuração do modo operacional. As bandeiras de permissão não são acumuladas, portanto, para cada classe de login, você deve listar todas as bandeiras de permissão necessárias, incluindo a exibição de informações e o modo viewconfigure de configuração. Ao especificar um sinal de permissão específico na classe de login do usuário, você concederá ao usuário acesso aos comandos, declarações e hierarquias de configuração correspondentes. Para conceder acesso a todos os comandos e declarações de configuração, use all o sinal de permissões. As bandeiras de permissão fornecem a capacidade de leitura somente de leitura (formulário simples) e de leitura e gravação (formulário que termina no controle) para um tipo de permissão.

Nota:

Os bits de permissão da classe de login têm precedência sobre expressões regulares estendidas quando um usuário emite um comando de reação com o sinal all de permissão de rebaixamento ativado.

Para configurar níveis de privilégios de acesso ao usuário:

  1. Exibir permissões para uma conta de usuário.

    Você pode exibir as permissões de uma conta de usuário antes de configurar os privilégios de acesso para essas permissões.

    Para exibir as permissões do usuário, insira ? no nível [edit] da hierarquia:

  2. Configure permissões de usuário com privilégios de acesso.

    Todos os usuários que podem fazer login em um dispositivo devem estar em uma classe de login. Para cada classe de login, você pode configurar os privilégios de acesso que os usuários associados podem ter quando estão conectados ao dispositivo.

    Para configurar níveis de privilégios de acesso para permissões do usuário, inclua a declaração no nível da hierarquia, seguido da permissão do usuário, da opção e dos sinalizadores permissions[edit system login class class-name] de permissão permissions necessários.

Configuração

Configuração de permissões de usuário com níveis de privilégios de acesso

Procedimento passo a passo

Para configurar privilégios de acesso:

  1. A partir do dispositivo, veja a lista de permissões disponíveis para a conta do usuário. Neste exemplo, o nome de usuário da conta do usuário é host.

    A saída lista as permissões do host do usuário. Classes de login personalizadas podem ser criadas configurando diferentes privilégios de acesso nessas permissões de usuário.

  2. Configure uma classe de privilégios de acesso para permitir que o host do usuário configure e veja apenas os parâmetros de SNMP. Neste exemplo, essa classe de login é chamada de gerenciamento de rede. Para personalizar a classe de login do gerenciamento de rede, inclua os sinalizadores de permissão SNMP à configure permissão do usuário.

    Aqui, os flags de permissão configurados fornecem recursos de leitura (snmp) e de leitura e gravação (snmp-control) para SNMP, e esse é o único privilégio de acesso permitido para a classe de login do gerenciamento de rede. Em outras palavras, todos os outros privilégios de acesso que não sejam a configuração e exibição de parâmetros SNMP são negados.

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show system login comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Verificação

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

Verificação da configuração de SNMP

Propósito

Verificar se a configuração de SNMP pode ser executada.

Ação

No modo de configuração, execute comandos SNMP básicos em [edit snmp] nível de hierarquia.

Significado

O host do usuário atribuído à classe de login do gerenciamento de rede é capaz de configurar parâmetros SNMP, pois os sinalizadores de permissão especificados para esta classe incluem bits de permissão snmp (recursos de leitura) e snmp-control (recursos de leitura e gravação).

Verificação da configuração não SNMP

Propósito

Verificar se a configuração não SNMP foi negada para a classe de login do gerenciamento de rede.

Ação

A partir do modo de configuração, execute qualquer configuração de interfaces não SNMP, por exemplo.

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

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

Entender expressões regulares

Você pode usar expressões regulares estendidas para especificar quais comandos de modo operacional, declarações de configuração e hierarquias são negados ou permitidos. Você especifica essas expressões regulares localmente nos atributos , e declarações em nível de hierarquia ou remotamente, especificando allow/deny-commandsallow/deny-configuration, Juniper Networks allow/deny-commands-regexpsallow/deny-configuration-regexp[edit system login class class-name] TACACS+ ou atributos RADIUS fornecedores específicos do fornecedor na configuração do seu servidor de autorização.

Nota:

A partir da versão 18.1 do Junos OS, os e os depoimentos são allow-commands-regexpsdeny-commands-regexps suportados para autorização DO TACACS+.

A diferença entre uma configuração de autorização local e remota é o padrão no qual as declarações de expressões regulares são executadas. Embora seja possível especificar várias expressões regulares usando strings na configuração de autorização local, em uma configuração remota, as declarações de expressões regulares precisam ser divididas e especificadas em strings individuais. Quando os parâmetros de autorização estão configurados remotamente e localmente, as expressões regulares recebidas durante o TACACS+ ou RADIUS de autorização são mescladas com quaisquer expressões regulares disponíveis no dispositivo local.

Ao especificar várias expressões regulares em uma configuração local usando as declarações, ou , ou expressões, as expressões regulares são configuradas entre allow-configurationdeny-configurationallow-commands parênteses e separadas usando o símbolo deny-commands do pipe. A expressão completa está entre aspas duplas. Por exemplo, você pode especificar vários allow-commands parâmetros com a seguinte sintaxe:

A mesma expressão configurada remotamente no servidor de autorização usa a seguinte sintaxe:

Ao especificar várias expressões regulares em uma configuração local usando allow-configuration-regexps as declarações , ou expressões, as expressões regulares são configuradas em citações duplas e separadas usando o deny-configuration-regexps operador de allow-commands-regexpsdeny-commands-regexps espaço. A expressão completa está fechada em suportes quadrados. Por exemplo, você pode especificar vários parâmetros de permitir comandos com a seguinte sintaxe:

A mesma expressão configurada remotamente no servidor de autorização usa a seguinte sintaxe:

Tabela 2 diferencia a configuração de autorização local e remota usando expressões regulares.

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

Configuração local

Configuração remota

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.*"
        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, emissão dos três comandos a seguir: xml-modenetconfneed-trailer e.

  • Quando a declaração for usada, todas as outras configurações deny-configuration = “.*” desejadas devem ser permitidas usando a allow-configuration instrução. Isso pode afetar o limite de buffer de expressões regulares permitido para a allow-configuration declaração. Quando esse limite exceder, a configuração permitida pode não funcionar. Esse limite de tamanho de buffer de expressão regular foi ampliado na Versão 14.1x53-D40, 15.1 e 16.1 do Junos OS.

Especificando expressões regulares

Aviso:

Quando você especificar a expressão regular para comandos e declarações de configuração, preste muita atenção aos exemplos a seguir, pois a expressão regular com sintaxe inválida pode não produzir os resultados desejados, mesmo se a configuração for comprometida sem qualquer erro.

Expressões regulares de comandos e declarações de configuração devem ser especificadas da mesma maneira que executando o comando ou a declaração completa. Tabela 3 lista as expressões regulares para configurar privilégios de acesso para as hierarquias e as hierarquias de declaração [edit interfaces][edit vlans] e para o delete interfaces comando.

Tabela 3: Especificando 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 de executar a unit declaração.

Como resultado, a expressão regular necessária para negar a configuração deve especificar toda a string executável com o operador no lugar das variáveis set interfaces.* 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 instrução específica. Neste exemplo, ele indica qualquer nome de interface com qualquer valor unitar.

  • Especificar apenas a instrução está incorreta e não negar o acesso à deny-configuration "interfaces .*" configuração de 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.* .*"
    

    Note: A expressão regular deste exemplo é usada quando espera-se que várias strings a partir da palavra-chave mem.*mem sejam incluídas na expressão regular especificada. Quando member espera-se que apenas uma string seja incluída, a expressão regular é member .* usada.

delete interfaces

O delete comando para interfaces é executado da seguinte forma:

[edit]
user@host# delete interfaces interface-name

A declaração pode ser executada por si mesma e não requer a conclusão delete interfaces de declarações adicionais.

Como resultado, a expressão regular necessária para negar a delete interfaces declaração deve especificar o seguinte:

[edit system login class class-name]
user@host# set permissions configure
user@host# set allow-configuration "interfaces .*"
user@host# set deny-configuration "interfaces .*"
  • O .* operador denota tudo desde o ponto especificado em diante para esse comando ou instrução específica. Neste exemplo, ele denota qualquer nome de interface.

  • Para a expressão regular entrar em vigor, a classe de login especificada deve permitir permissões de configuração para a deny-configuration "interfaces .*" hierarquia de interfaces usando a allow-configuration "interfaces .*" expressão regular.

[edit vlans]

O set comando para VLANs é executado da seguinte forma:

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

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

Como resultado, a expressão regular necessária para permitir a configuração deve especificar toda a string executável com o operador no set vlans.* lugar das 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 instrução específica. Neste exemplo, ele indica qualquer nome VLAN com qualquer ID VLAN.

  • Outras opções válidas na hierarquia [edit vlans] da 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 4 lista operadores de expressões regulares comuns que você pode usar para permitir ou negar modos operacionais e de configuração.

Expressões regulares de comando implementam expressões regulares estendidas (modernas), conforme definido no POSIX 1003.2.

Tabela 4: Operadores comuns de expressão regular

Operador

Jogo

Exemplo

|

Um de dois ou mais termos separados pelo tubo. Cada termo deve ser uma expressão autônoma completa, fechada entre parênteses (), sem espaços entre o tubo 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 acima, os usuários atribuídos à classe de login de teste têm acesso ao modo operacional restrito apenas aos comandos especificados na instrução e ao modo de configuração, exceto os níveis de hierarquia especificados na allow-commandsdeny-configuration declaração.

^

No início de uma expressão, usada para indicar onde o comando começa, onde pode haver alguma ambigüidade.

[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 acima, os usuários atribuídos à classe de login de teste têm acesso à configuração e visualização da interface a partir do modo operacional e de configuração. A allow-commands declaração especifica o acesso a comandos que começam com showmonitor palavras-chave.

Para o primeiro filtro, os comandos especificados incluem show log os comandos , e show interfaces . show policer O segundo filtro especifica todos os comandos a partir da monitor palavra-chave, como monitor interfaces ou monitor traffic comandos.

$

Personagem ao final de um comando. Usado para denotar um comando que deve ser exatamente igualado a esse ponto.

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

Com a configuração acima, os usuários atribuídos à classe de login de teste podem exibir a configuração da interface no modo de configuração e com o comando modo operacional com a permissão do show configuration usuário da interface. Entretanto, a expressão regular especificada na declaração restringe os usuários a executar apenas o comando e negar o acesso às extensões de allow-commandsshow interfaces comando, como show interfaces detail ou show interfaces extensive .

[ ]

Variedade de letras ou dígitos. Para separar o início e a ponta de um intervalo, 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 acima, os usuários atribuídos à classe de login de teste têm permissões de usuário no nível do operador e têm acesso a configurar interfaces dentro do intervalo especificado de nome da interface e número da unidade (0 a 9).

( )

Um grupo de comandos, indicando uma expressão completa e independente a ser avaliada. O resultado é então avaliado como parte da expressão geral. Os parênteses devem ser usados junto com os operadores de pipe, como 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 em 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 com o acesso de configuração m é negado.

+

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 com o acesso de configuração m é negado.

.

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 com o acesso de configuração m é negado.

.*

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 com o acesso de configuração m é negado.

Da mesma forma, a deny-configuration "protocols .*" declaração nega todo o acesso à configuração no nível da [edit protocols] hierarquia.

Nota:
  • As * operações e as operações podem ser +. realizadas .* usando-se.

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

Nota:

O Junos OS não tem suporte para o ! operador de expressões regular.

Exemplos de expressões regulares

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

Nota:

Tabela 5 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 suportadas na Versão 16.1 do Junos OS e são validadas apenas para as hierarquias e [edit system ntp server][edit protocols rip] declarações.

Tabela 5: Exemplos de expressões regulares

Hierarquia de declarações

Expressões regulares

Configuração permitida

Configuração negada

[edit system ntp server]

     

número-chave

[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

número da versão

[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

  • key

  • 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 preferir

  • key

  • Versão

[edit protocols rip]

     

tamanho da mensagem

[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 da mensagem

  • métrica

  • route-timeout

  • intervalo de atualização

metric-in 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 da mensagem

  • route-timeout

  • intervalo de atualização

tempo de roteá-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 .*" ]
  • route-timeout

  • tamanho da mensagem

  • métrica

  • intervalo de atualização

intervalo de atualização de intervalo de atualização

[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 da mensagem

  • métrica

  • route-timeout

Exemplos de definição de privilégios de acesso usando declarações de configuração de permitir e negar

Você pode definir privilégios de acesso 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 e declarações têm precedência sobre as bandeiras de permissão e dão ao administrador um controle mais preciso deny-configuration sobre exatamente ao que o usuário tem acesso.

Este tópico explica a definição de privilégios de acesso usando e declarações mostrando uma série de exemplos de configuração de classe de allow-configurationdeny-configuration login usando essas declarações. Exemplos de 1 a 3 usam ambos os sinalizadores de permissão e declarações para criar classes de login que permitem que os usuários tenham acesso a deny-configuration tudo, exceto algo. Cada ou declaração está configurada com uma ou mais expressões allow-configurationdeny-configuration regulares a serem permitidas ou negadas.

Observe que o bit de permissão e o sinal de permissão são usados intercambiávelmente.

Exemplo 1

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

  1. De definir o bit de permissão da classe de login do usuário para all .
  2. Inclua a seguinte deny-configuration declaração.

Exemplo 2

Para criar uma classe de login que permita ao usuário configurar tudo, exceto qualquer coisa em qualquer classe de login cujo nome comece com "m":

  1. De definir o bit de permissão da classe de login do usuário para all .

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

Exemplo 3

Este próximo exemplo mostra a criação de uma classe de login com o bit de permissão que impede o usuário de editar uma configuração ou emissão de comandos (como) nos níveis ou allcommit na [edit system login class][edit system services] hierarquia:

Para criar uma classe de login que permita ao usuário configurar tudo, exceto nos níveis [edit system login class] ou [edit system services] na hierarquia:

  1. De definir o bit de permissão da classe de login do usuário para all .

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

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

Exemplo 4

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

  1. De definir o bit de permissão da classe de login do usuário para configure .

  2. Inclua a seguinte allow-configuration declaração.

Exemplo 5

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

  1. De definir o bit de permissão da classe de login do usuário para all .

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

Exemplo: Usando 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.

Configuração

Procedimento passo a passo

Para habilitar a lógica aditiva para expressões regulares:

  1. Para permitir explicitamente que uma ou mais hierarquias de modo de configuração individuais incluam a instrução no nível da hierarquia, configurada com as allow-configuration-regexps[edit system login class class-name] expressões regulares a serem permitidas.

  2. Atribua a classe de login a um ou mais usuários.

  3. Habilitar lógica aditiva para expressões regulares.

  4. Compromete suas mudanças.

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

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Um Juniper Networks J Series, Série M, Série MX ou Série T dispositivo

  • Junos OS Release 16.1 ou mais tarde

    • Deve haver pelo menos um usuário atribuído a uma classe de login.

    • Pode haver mais de uma classe de login, cada uma com várias configurações de permissão e mais de um usuário no dispositivo.

Visão geral

Para controlar quem pode fazer alterações de configuração no sistema e o que especificamente elas podem mudar, você pode criar expressões regulares que indicam porções específicas da hierarquia de configuração que os usuários de uma classe de usuário nomeada têm permissão para acessar. Por exemplo, você pode criar expressões regulares que especifiquem um grupo de instâncias de roteamento permitidas pelos usuários e impeçam que os usuários criem alterações em outras instâncias de roteamento ou em qualquer outro nível de configuração.

Você configura expressões regulares usando allow-configuration-regexps as e deny-configuration-regexps declarações. Por padrão, as declarações têm precedência sobre as declarações de deny-configuration-regexps usuários na classe de usuário allow-configuration-regexps nomeada à qual são aplicadas.

Se uma hierarquia de configuração aparecer em uma instrução para uma classe de usuário nomeada, ela não será visível para os usuários, independentemente do deny-configuration-regexps conteúdo da allow-configuration-regexps declaração. Se uma hierarquia de configuração não aparecer em uma declaração, ela fica visível se ela aparece em uma declaração ou se não há nenhuma instrução configurada para a classe deny-configuration-regexpsallow-configuration-regexps do allow-configuration-regexps usuário..

Opcionalmente, você pode alterar esse comportamento padrão para que a lógica aditiva (ou seja, negar tudo por padrão/ permitir que alguns como especificados) seja usada em expressões regulares. Quando a lógica aditiva é ativada, o comportamento das expressões regulares existentes muda para que todas as hierarquias de configuração sejam negadas a menos que elas sejam incluídas em uma declaração para a classe de usuário allow-configuration-regexps nomeada.

Exemplos

Usando expressões regulares com lógica aditiva

Propósito

Esta seção fornece exemplos de expressões regulares que usam lógica aditiva para dar a você 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 ; por CUST-VRF-CUST-VRF-1 exemplo, CUST-VRF-25 , e assim CUST-VRF-100 por diante:

Se a declaração a seguir estiver incluída na configuração, ele impede que o usuário configure outras instâncias de roteamento e negue o acesso a qualquer hierarquia de configuração de instâncias não roteamento:

Permitir BGP única configuração de peer

A classe de login do exemplo a seguir inclui uma expressão regular que permite a configuração de BGP peers:

Caso a instrução a seguir seja incluída na configuração, ela impede que o usuário mude outras alterações, como exclusão ou desativação de BGP declarações:

Verificação

Para verificar se os privilégios de acesso foram definidos corretamente:

  1. Configure uma classe de login e faça as alterações.

  2. Atribua a classe de login a um nome de usuário.

  3. Faça login como o nome de usuário atribuído à nova classe de login.

  4. Tentar realizar as configurações permitidas.

    • Você deve ser capaz de realizar alterações de configuração em níveis de hierarquia e expressões regulares permitidas.

    • Todas as outras hierarquias não devem ser visíveis.

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

Exemplo: Configuração de permissões de usuário com privilégios de acesso para comandos do modo operacional

Este exemplo mostra como configurar classes de login personalizadas e atribuir privilégios de acesso para comandos do modo operacional. Isso permite que usuários da classe de login personalizado executem apenas os comandos operacionais para os quais os privilégios de acesso foram especificados. Isso impede que usuários não autorizados executam comandos confidenciais que podem causar danos à rede.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Um Juniper Networks de segurança

  • Um servidor TACACS+ (ou RADIUS)

  • Construção do Junos OS em execução no Juniper Networks dispositivo

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 RADIUS servidor.

    Para obter informações sobre a configuração de um servidor TACACS+, consulte Configurar autenticação TACACS+.

  • Configure pelo menos um usuário atribuído a uma classe de login no Juniper Networks dispositivo. Pode haver mais de uma classe de login, cada uma com várias configurações de permissão e mais de um usuário no dispositivo.

Visão geral e topologia

Cada comando da interface de linha de comando (CLI) de nível superior e cada instrução de configuração do Junos OS tem um nível de privilégios de acesso associado a ele. Para cada classe de login, você pode negar ou permitir explicitamente o uso de comandos de modo operacional e de configuração que seriam permitidos ou não por um nível de privilégios. Os usuários só podem executar esses comandos e configurar e exibir apenas aquelas declarações para as quais tenham privilégios de acesso. Para configurar níveis de privilégios de acesso, inclua permissions a declaração em nível de [edit system login class class-name] hierarquia.

Os privilégios de acesso de cada classe de login são definidos por um ou mais sinalizadores de permissão especificados na permissions declaração. Além disso, você pode especificar expressões regulares estendidas com as seguintes declarações:

  • allow-commands e deny-commands — Permitir ou negar o acesso apenas aos comandos do modo operacional.

  • allow-configuration e deny-configuration — Permitir ou negar acesso apenas a uma hierarquia de configuração específica.

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

  • allow-commands-regexps e deny-commands-regexps —(somente autorização TACACS+) Permitir ou negar acesso a um comando específico usando strings de expressões regulares.

As declarações acima definem os privilégios de acesso de um usuário a comandos de modo operacional individual, declarações de configuração e hierarquias. Essas declarações têm precedência sobre as permissões de classe de login definidas para um usuário.

Configuration Notes

Ao configurar os , e declarações com privilégios de acesso, leve em allow-commandsdeny-commands consideração o allow-configurationdeny-configuration seguinte:

  • Você pode incluir a instrução permitir/negar apenas uma vez em cada classe de login.

  • Se o mesmo comando estiver configurado em declarações e declarações ou declarações, a operação permitirá ter precedência sobre allow-commandsdeny-commands a declaração de allow-configurationdeny-configuration negação.

    Por exemplo, com a seguinte configuração, um usuário atribuído ao teste de classe de login pode instalar software usando o comando, embora a instrução também request system software adddeny-commands o inclua:

    Por exemplo, com a seguinte configuração, um usuário atribuído ao teste de classe de login pode acessar a hierarquia de configuração, embora a instrução também [edit system services]deny-configuration a inclua:

  • Se você especificar uma expressão regular para e declarações com duas variantes diferentes de um comando, a combinação mais longa allow-commandsdeny-commands sempre será executada.

    Por exemplo, para a configuração a seguir, um usuário designado para testar a classe de login pode executar o commit synchronize comando e não o commit comando. Isso se deve ao fato de ser a combinação mais longa entre commit-synchronizecommitcommit-synchronize e, e ela está especificada para allow-commands .

  • Expressões regulares allow-commands para e declarações também podem incluir os deny-commandscommitload comandos, , rollbacksavestatusupdate

  • Permitir explicitamente hierarquias de modo de configuração ou expressões regulares usando a instrução acrescenta ao allow-configuration conjunto de permissões regulares que usam a permissions instrução. Da mesma forma, negar explicitamente hierarquias do modo de configuração ou expressões regulares usando a instrução remove as permissões da hierarquia do modo de configuração especificada, das permissões padrão fornecidas pela deny-configurationpermissions declaração.

    Por exemplo, para a seguinte configuração, o usuário da classe de login pode editar a configuração no nível da hierarquia e nos comandos do modo de configuração de problema (como), além de apenas entrar no modo de configuração usando o comando, que é a permissão especificada pelo sinal de permissão de [edit system services]commitconfigure configuração:

    Da mesma forma, para a seguinte configuração, o usuário da classe de login pode realizar todas as operações permitidas pelo sinal de todas as permissões, exceto a emissão de comandos do modo de configuração (como) ou modificar a configuração no nível da commit[edit system services] hierarquia:

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

  • Se você tiver configurações existentes usando as ou declarações, usar as mesmas opções de configuração com as ou declarações pode não produzir os mesmos resultados, pois os métodos de pesquisa e de combinação diferem nas duas formas dessas allow/deny-configurationallow/deny-commandsallow/deny-configuration-regexpsallow/deny-commands-regexps declarações.

  • Para definir privilégios de acesso a partes da hierarquia de configuração, especifique os caminhos completos nas expressões regulares estendidas com allow-configuration as e deny-configuration declarações. Use parênteses em uma expressão regular estendida que conecta duas ou mais expressões com o símbolo pipe (|).

    Por exemplo:

  • Se a expressão regular contiver espaços, operadores ou caracteres de caracteres curinga, estando a expressão entre aspas. Expressões regulares não são sensíveis a casos; por exemplo, allow-commands "show interfaces" .

  • Modificações como definir,registrare contar não são suportadas na cadeia de caracteres de expressão regular a ser adida. Se um modificador for usado, nada será igualado.

    Configuração incorreta:

    Configuração correta:

  • Âncoras são necessárias ao especificar expressões regulares complexas com a allow-commands instrução.

    Por exemplo:

  • Ao especificar expressões regulares estendidas usando-se as e declarações, cada expressão separada por um símbolo (|) deve ser uma expressão autônoma completa, devendo ser fechada entre allow/deny-commandsallow/deny-configuration parênteses ( ). Não use espaços entre expressões regulares separadas por parênteses e conectadas ao símbolo | pipe.

    Por exemplo:

  • Ao especificar expressões regulares estendidas usando a ou a instrução, cada expressão fechada entre aspas (") e separada por um espaço deve ser fechada em allow/deny-configuration-regexpsallow/deny-commands-regexps suportes angulares [ ].

    Por exemplo:

  • Você pode usar o caractere * wildcard ao denocar expressões regulares. Entretanto, ele deve ser usado como uma porção de uma expressão regular. Você não pode usar [ * ] ou [ .* ] sozinho.

  • Não é possível configurar allow-configuration a instrução com as interfaces (descrição (|. *)) expressão regular, conforme avalia a allow-configuration = .* expressão regular.

  • Você pode configurar o máximo de expressões regulares necessárias para serem permitidas ou negadas. Expressões regulares a serem negadas têm precedência sobre configurações a serem permitidas.

Topologia

Figura 1: Configuração da autenticação de servidor TACACS+Configuração da autenticação de servidor TACACS+

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

Neste exemplo, R1 está configurado com três classes de login personalizadas — Class1, Class2 e Class3 — para especificar privilégios de acesso com expressões regulares estendidas usando as e declarações de maneira allow-commandsdeny-commands diferente.

A finalidade de cada classe de login é a seguinte:

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

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

  • Class3— Define privilégios de acesso para o usuário com as allow-commands declarações e deny-commands as declarações. Essa classe de login fornece permissões de usuário em nível de superusuário e deve fornecer autorização para acessar interfaces e exibir informações do dispositivo. Ele também deve negar acesso a edit e configure comandos.

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

Configuração

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

R1

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

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia do Usuário da CLI.

Para configurar a autenticação do roteador R1:

  1. Configure a ordem na qual a autenticação deve ocorrer para R1. Neste exemplo, a autenticação do servidor TACACS+ é primeiro, seguida RADIUS autenticação do servidor e, em seguida, a senha local.

  2. Estabeleça conexão R1 com o servidor TACACS+.

  3. Configure RADIUS de autenticação de servidor.

  4. Configure os parâmetros de configuração da contabilidade R1.

Configuração de privilégios de acesso com somente instrução de comandos de autorização (Class1)

Procedimento passo a passo

Para especificar expressões regulares usando apenas allow-commands a instrução:

  1. Configure a classe de login personalizado Class1 e atribua permissões de usuário no nível do operador. Para obter informações sobre as classes de login do sistema predefinidas, consulte a visão geral das classes de login do Junos OS.

  2. Especifique o comando para habilitar a reinicialização de R1 na allow-commands declaração.

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

Configurando privilégios de acesso com somente declaração de comandos de negação (Class2)

Procedimento passo a passo

Para especificar expressões regulares usando apenas deny-commands a instrução:

  1. Configure a classe de login personalizado Class2 e atribua permissões de usuário no nível do operador. Para obter informações sobre as classes de login do sistema predefinidas, consulte a visão geral das classes de login do Junos OS.

  2. Desative a execução de quaisquer comandos definidos na deny-commands declaração.

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

Configuração de privilégios de acesso com declarações de autorização e negação de comandos (Class3)

Procedimento passo a passo

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

  1. Configure a classe de login personalizado Class3 e atribua permissões de usuário em nível de superusuário. Para obter informações sobre as classes de login do sistema predefinidas, consulte a visão geral das classes de login do Junos OS.

  2. Especifique os comandos para habilitar apenas os comandos na allow-commands declaração.

  3. Desative a execução de todos os comandos na deny-commands declaração.

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

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show system comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Verificação

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

Verificação da configuração de Class1

Propósito

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

Ação

Do modo operacional, execute o show system users comando.

Do modo operacional, execute o request system reboot comando.

Significado

A classe de login Class1 à qual o Usuário1 é atribuído tem as permissões do usuário no nível do operador e tem permissão para executar o request system reboot comando.

A classe de login do operador predefinido tem os seguintes sinalizadores de permissão especificados:

  • clear— É possível eliminar (excluir) informações aprendidas da rede armazenadas em vários bancos de dados de rede usando os clear comandos.

  • network— Pode acessar a rede usando os pingssh comandos , e telnet . traceroute

  • reset— É possível reinicializar os processos de software usando o comando e configurar se os restart processos de software estão ativados ou inválidos em nível de [edit system processes] hierarquia.

  • trace— É possível exibir configurações de arquivo de rastreamento e configurar propriedades de arquivo de rastreamento.

  • view— Pode usar vários comandos para exibir estatísticas e valores e estatísticas atuais em toda a rede, na tabela de roteamento e nos valores e estatísticas específicos do protocolo. Não é possível ver a configuração secreta.

Para a classe de login Class1, além das permissões de usuário citadas 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 comando que o User1 pode executar como um operador é request o request system reboot comando.

Verificação da configuração de Class2

Propósito

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

Ação

Do modo operacional, execute o ping comando.

A partir do aviso da CLI, consulte as permissões disponíveis.

A partir do aviso CLI, execute qualquer comando definido.

Significado

A classe de login Class2 à qual o Usuário2 é atribuído tem as permissões de usuário no nível do operador e o acesso não é autorizado a todos os set comandos. Ele é exibido nas saídas de comando.

Os sinalizadores de permissão especificados para a classe de login do operador predefinido são os mesmos da Classe1.

Verificação da configuração de Class3

Propósito

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

Ação

A partir do aviso da CLI, consulte as permissões disponíveis.

A partir do modo operacional, insira o modo de configuração.

Significado

A classe de login Class3 à qual o Usuário3 é atribuído tem as permissões do usuário do superusuário (todas), mas é permitida apenas a execução do comando e o acesso não é permitido a todos os outros comandos do modo configure operacional. Como as expressões regulares especificadas nas declarações têm precedência sobre as permissões do usuário, o Usuário3 em R1 tem acesso apenas ao modo de configuração, e fica impedido de acessar todos os outros comandos do modo allow/deny-commands operacional.

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

Este exemplo mostra como configurar classes de login personalizadas e atribuí-los privilégios de acesso a partes da hierarquia de configuração. Isso permite que usuários da classe de login personalizada executem apenas as declarações de configuração e as hierarquias para as quais os privilégios de acesso foram especificados. Isso impede que usuários não autorizados acessem configurações de dispositivo que podem causar danos à rede.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Um Juniper Networks de segurança

  • Um servidor TACACS+ (ou RADIUS)

  • Construção do Junos OS em execução no Juniper Networks dispositivo

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 RADIUS servidor.

    Para obter informações sobre a configuração de um servidor TACACS+, consulte Configurar autenticação TACACS+.

  • Configure pelo menos um usuário atribuído a uma classe de login no Juniper Networks dispositivo. Pode haver mais de uma classe de login, cada uma com várias configurações de permissão e mais de um usuário no dispositivo.

Visão geral e topologia

Cada comando da interface de linha de comando (CLI) de nível superior e cada instrução de configuração do Junos OS tem um nível de privilégios de acesso associado a ele. Para cada classe de login, você pode negar ou permitir explicitamente o uso de comandos de modo operacional e de configuração que seriam permitidos ou não por um nível de privilégios. Os usuários só podem executar esses comandos e configurar e exibir apenas aquelas declarações para as quais tenham privilégios de acesso. Para configurar níveis de privilégios de acesso, inclua permissions a declaração em nível de [edit system login class class-name] hierarquia.

Os privilégios de acesso de cada classe de login são definidos por um ou mais sinalizadores de permissão especificados na permissions declaração. Além disso, você pode especificar expressões regulares estendidas com as seguintes declarações:

  • allow-commands e deny-commands — Permitir ou negar o acesso aos comandos do modo operacional.

  • allow-configuration e deny-configuration — Permitir ou negar acesso a partes da hierarquia de configuração.

    Essas declarações executam correspondências mais lentos, com mais flexibilidade, especialmente na correspondência de caracteres curinga. 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 caracteres curinga estiver configurado, o que pode afetar o desempenho.

  • allow-configuration-regexps e deny-configuration-regexps — Permitir ou negar acesso a uma hierarquia de configuração específica usando strings de expressões regulares. Essas declarações são semelhantes a e declarações, exceto que nas declarações você pode configurar conjuntos de strings nos quais as strings incluem espaços ao usar o allow-configurationdeny-configuration primeiro conjunto de allow/deny-configuration-regexps declarações.

As declarações acima definem os privilégios de acesso de um usuário a comandos de modo operacional individual, declarações de configuração e hierarquias. Essas declarações têm precedência sobre um bit de bit de permissões de classe de login definido para um usuário.

Difference between allow/deny-configuration and allow/deny-configuration-regexps statements

As allow-configuration e declarações foram deny-configuration introduzidas antes da versão 7.4 do Junos OS. As allow-configuration-regexps e declarações foram deny-configuration-regexps introduzidas na Versão 11.2 do Junos OS. Na Versão 11.4 do Junos OS, as declarações e as declarações foram preteridas, mas, como essas declarações foram úteis na execução de configurações simples, essas declarações não foram prepreendidas no Junos OS Release 11.4R6, e, a partir da versão 11.4R6, ambas e as declarações são allow-configurationdeny-configurationallow/deny-configurationallow/deny-configuration-regexps suportadas.

As declarações dividem a expressão regular em tokens e igualam cada peça a cada parte do caminho completo da configuração especificada, enquanto as declarações se igualam à allow/deny-configuration-regexpsallow/deny-configuration string completa. Para declarações, você configura um conjunto de strings nas quais cada string é uma expressão regular, com espaços entre allow/deny-configuration-regexps os termos da string. Isso fornece correspondência muito rápida, mas com menos flexibilidade. Para especificar expressões de caracteres curinga, você deve configurar caracteres curinga para cada símbolo da string delimitada por espaço que deseja combinar, e isso torna mais entediante o uso de expressões de caracteres curinga para essas declarações.

Por exemplo:

  • Expressões regulares que correspondênciam um símbolo usando allow-configuration-regexps

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

    A configuração acima bate com as seguintes declarações:

    • definir a condição options de política-condição dynamic-db

    • definir roteamento- optionsroteamento estático roteamento static-route next-hop next-hop

    • definir segundos de intervalo de tempo do evento- gerar options evento

    A configuração acima não combina com as seguintes declarações:

    • host de nome de host do sistema-options

    • descrição do nome da interfaceoptions

  • Expressões regulares que correspondênciam três tokens usando allow-configuration-regexps

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

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

    A configuração acima bate com as seguintes declarações:

    • hostname de nome de host do sistema-ssh

    • serviços de sistema ssh

    • serviços de sistema de saída-ssh

    A configuração acima não combina com a seguinte instrução:

    • descrição do nome da interfacessh

Você pode restringir o acesso à configuração facilmente usando a declaração em comparação com o uso da declaração. Ilustra o uso das declarações e das declarações em diferentes configurações para obter o mesmo resultado da restrição do acesso deny-configurationdeny-configuration-regexps a uma Tabela 6deny-configurationdeny-configuration-regexps configuração específica.

Tabela 6: Restrição do acesso à configuração Usando a configuração de negação e as declarações deny-configuration-regexps

Configuração negada

Usando: configuração de negação

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 seguinte instrução de configuração é negada:

  • serviços de sistema xnm-ssl

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:

  • hostname-ssh de nome de host do sistema

  • ssh de serviços de sistema

  • serviços de sistema de saída

  • host conhecido por ssh de segurança

Embora as declarações também sejam úteis quando a configuração simples é desejada, as declarações fornecem melhor desempenho e superam a ambigüidade existente ao combinar expressões allow/deny-configurationallow/deny-configuration-regexps definidas nas allow/deny-configuration declarações.

Nota:

As allow/deny-configuration declarações e as declarações são allow/deny-configuration-regexps mutuamente exclusivas e não podem ser configuradas juntas para uma classe de login. Em um determinado ponto de tempo, uma classe de login pode incluir a allow/deny-configuration declaração ou a allow/deny-configuration-regexps declaração. Se você tiver configurações existentes usando as declarações, usar as mesmas opções de configuração com as declarações pode não produzir os mesmos resultados, pois os métodos de pesquisa e de combinação diferem nas duas formas dessas allow/deny-configurationallow/deny-configuration-regexps declarações.

Configuration Notes

Ao configurar os , e declarações com privilégios de acesso, leve em allow-configurationdeny-configuration consideração o allow-configuration-regexpsdeny-configuration-regexps seguinte:

  • Você pode incluir uma deny-configuration e uma allow-configuration instrução em cada classe de login.

  • As allow/deny-configuration declarações e as declarações são allow/deny-configuration-regexps mutuamente exclusivas e não podem ser configuradas juntas para uma classe de login. Em um determinado ponto de tempo, uma classe de login pode incluir a allow/deny-configuration declaração ou a allow/deny-configuration-regexps declaração. Se você tiver configurações existentes usando as declarações, usar as mesmas opções de configuração com as declarações pode não produzir os mesmos resultados, pois os métodos de pesquisa e de combinação diferem nas duas formas dessas allow/deny-configurationallow/deny-configuration-regexps declarações.

  • Permitir explicitamente hierarquias de modo de configuração ou expressões regulares usando a instrução acrescenta ao allow-configuration conjunto de permissões regulares que usam a permissions instrução. Da mesma forma, negar explicitamente hierarquias do modo de configuração ou expressões regulares usando a instrução remove as permissões da hierarquia do modo de configuração especificada, das permissões padrão fornecidas pela deny-configurationpermissions declaração.

    Por exemplo, para a seguinte configuração, o usuário da classe de login pode editar a configuração no nível da hierarquia e nos comandos do modo de configuração de problema (como), além de apenas entrar no modo de configuração usando o comando, que é a permissão especificada pelo sinal de permissão de [edit system services]commitconfigure configuração:

    Da mesma forma, para a seguinte configuração, o usuário da classe de login pode realizar todas as operações permitidas pelo sinal de todas as permissões, exceto a emissão de comandos do modo de configuração (como) ou modificar a configuração no nível da commit[edit system services] hierarquia:

  • Para definir privilégios de acesso a partes da hierarquia de configuração, especifique os caminhos completos nas expressões regulares estendidas com allow-configuration as e deny-configuration declarações. Use parênteses em uma expressão regular estendida que conecta duas ou mais expressões com o símbolo pipe (|).

    Por exemplo:

  • Ao especificar expressões regulares estendidas usando-se as e declarações, cada expressão separada por um símbolo (|) deve ser uma expressão autônoma completa, devendo ser fechada entre allow/deny-commandsallow/deny-configuration parênteses ( ). Não use espaços entre expressões regulares separadas por parênteses e conectadas ao símbolo | pipe.

    Por exemplo:

  • Ao especificar expressões regulares estendidas usando a instrução, cada expressão fechada entre aspas (") e separada por um espaço deve ser fechada em allow-deny-configuration-regexps suportes angulares [ ].

    Por exemplo:

  • Se o mesmo comando estiver configurado em declarações e em declarações, a operação allow tem allow-configurationdeny-configuration precedência sobre a declaração de negação.

    Por exemplo, com a seguinte configuração, um usuário atribuído ao teste de classe de login pode acessar a hierarquia de configuração, embora a instrução também [edit system services]deny-configuration a inclua:

    Por exemplo, se um certo comando ou configuração for permitido, por exemplo, usar tudo isso, podemos usar o comando para negar acesso deny-configuration a uma hierarquia específica.

  • Modificações como definir,registrare contar não são suportadas na cadeia de caracteres de expressão regular a ser adida. Se um modificador for usado, nada será igualado.

    Configuração incorreta:

    Configuração correta:

  • Você pode usar o caractere * wildcard ao denocar expressões regulares. Entretanto, ele deve ser usado como uma porção de uma expressão regular. Você não pode usar [ * ] ou [ .* ] sozinho.

  • Não é possível configurar allow-configuration a instrução com as interfaces (descrição (|. *)) expressão regular, conforme avalia a allow-configuration = .* expressão regular.

  • Você pode configurar o máximo de expressões regulares necessárias para serem permitidas ou negadas. Expressões regulares a serem negadas têm precedência sobre configurações a serem permitidas.

Topologia

Figura 2: Configuração da autenticação de servidor TACACS+Configuração da autenticação de servidor TACACS+

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

Neste exemplo, R1 está configurado com duas classes de login personalizadas — Class1 e Class2 — para especificar privilégios de acesso com expressões regulares estendidas usando as declarações , e as declarações de maneira allow-configurationdeny-configurationallow-configuration-regexpsdeny-configuration-regexps diferente.

A finalidade das classes de login é a seguinte:

  • Class1— Defina privilégios de acesso para o usuário com allow-configuration os e deny-configuration declarações. Essa classe de login deve fornecer acesso apenas para configurar a hierarquia de interfaces e negar todos os outros acessos no dispositivo. Para isso, as permissões do usuário devem incluir configurar para fornecer acesso à configuração. Além disso, a declaração deve permitir allow-configuration a configuração das interfaces, e a declaração deve negar acesso a todas as outras deny-configuration configurações. Como a instrução de permitir 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 [edit interfaces] da hierarquia.

  • Class2— Defina privilégios de acesso para o usuário com allow-configuration-regexps os e deny-configuration-regexps declarações. Essa classe de login fornece permissões de usuário em nível de superusuário e, além disso, permite explicitamente a configuração em vários níveis de hierarquia para interfaces. Também nega o acesso à configuração aos [edit system] níveis e [edit protocols] à hierarquia.

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

Configuração

Configuração rápida CLI

Para configurar rapidamente este exemplo, copie os comandos a seguir, confie-os em um arquivo de texto, remova quaisquer quebras de linha, altere quaisquer detalhes necessários para combinar a configuração da rede, copie e copie e copie os comandos na CLI no nível da hierarquia e, em seguida, entre no modo de [edit]commit configuração.

R1

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

Procedimento passo a passo

O exemplo a seguir requer que você navegar por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar pela CLI, consulte Como usar o Editor de CLI no modo de configuração no Guia do Usuário da CLI.

Para configurar a autenticação do roteador R1:

  1. Configure a ordem na qual a autenticação deve ocorrer para R1. Neste exemplo, a autenticação do servidor TACACS+ é primeiro, seguida RADIUS autenticação do servidor e depois a senha local.

  2. Estabeleça conexão R1 com o servidor TACACS+.

  3. Configure RADIUS de autenticação de servidor.

  4. Configure os parâmetros de configuração de contabilidade R1.

Configuração de privilégios de acesso com declarações de configuração de permitir e negar (Class1)

Procedimento passo a passo

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

  1. Configure a classe de login personalizado Class1 e atribua permissões de usuário de configuração.

  2. Especifique a expressão regular na allow-configuration instrução para permitir a configuração em [edit interfaces] nível de hierarquia. Para permitir set comandos em nível de [edit interfaces] hierarquia, a expressão regular usada é interfaces .* unit .* .

  3. Especifique a expressão regular na deny-configuration declaração para desativar todo o acesso à configuração. A expressão regular usada para negar todo o acesso à configuração é .* .

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

Configuração de privilégios de acesso com permit-configuration-regexps e deny-configuration-regexps Statements (Class2)

Procedimento passo a passo

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

  1. Configure a classe de login personalizado Class2 e atribua permissões ao usuário do superusuário (todos). Para obter informações sobre as classes de login do sistema predefinidas, consulte Visão geral das classes de login do Junos OS.

  2. Especifique a expressão regular para permitir o acesso a várias hierarquias no nível [edit interfaces] da hierarquia.

  3. Especifique a expressão regular para negar a configuração nos [edit system] níveis e [edit protocols] na hierarquia.

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

Resultados

A partir do modo de configuração, confirme sua configuração ao entrar no show system comando. Se a saída não apresentar a configuração pretendido, repetir as instruções neste exemplo para corrigir a configuração.

Verificação

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

Verificação da configuração de Class1

Propósito

Verificar se as permissões permitidas na classe de login Class1 estão funcionando.

Ação

A partir do aviso da CLI, consulte as permissões disponíveis.

A partir do modo de configuração, consulte as permissões de configuração disponíveis.

Significado

O User1 configurou as permissões do usuário vistas na primeira saída, e o único acesso de configuração permitido para o Usuário1 está no nível da hierarquia das interfaces. Todas as outras configurações são negadas, como visto na segunda saída.

Verificação da configuração de Class2

Propósito

Verificar se a configuração class2 está funcionando.

Ação

A partir do modo de configuração, acesse a configuração das interfaces.

A partir do modo de configuração, acesse as hierarquias de configuração do sistema e dos protocolos.

Significado

O User2 tem permissões para configurar interfaces de R1, mas os níveis e os níveis de hierarquia são impedidos de acesso, como visto [edit system][edit protocols] na saída.