Exemplo: Proteção da configuração do Junos OS contra modificações ou exclusões

Procedimento passo a passo

Para proteger uma configuração no nível superior da hierarquia:

Identifique a hierarquia que você deseja proteger e emita o protect comando para a hierarquia no nível hierárquicos [edit] .

Por exemplo, se você quiser proteger todo [edit access] o nível de hierarquia, use o seguinte comando:

[edit]
user@host# protect access

Resultados

Protege todos os elementos sob a hierarquia dos pais.

[edit]
user@host# protect access
warning: statement not found

Procedimento passo a passo

Para proteger uma hierarquia infantil contida na hierarquia dos pais:

Navegue até a hierarquia dos contêineres-mãe. Use o protect comando para a hierarquia no nível dos pais.

Por exemplo, se você quiser proteger o nível de [edit system syslog console] hierarquia, use o seguinte comando no nível de [edit system syslog] hierarquia.

[edit system syslog]
user@host# protect console

Resultados

Protege todos os elementos da hierarquia infantil.

Procedimento passo a passo

Para proteger uma declaração de configuração dentro de um nível de hierarquia:

Navegue até o nível hierárquica contendo a declaração que deseja proteger e emitir o protect comando para a hierarquia.

Por exemplo, se você quiser proteger a host-name declaração sob o [edit system] nível hierárquico, use o seguinte comando:

[edit system]
user@host# protect host-name

Resultados

Procedimento passo a passo

Algumas declarações de configuração podem levar vários valores. Por exemplo, a address declaração no nível de [edit system login deny-sources] hierarquia pode levar uma lista de nomes de host, endereços IPv4 ou endereços IPv6. Suponha que você tenha a seguinte configuração:

[edit system login]
deny-sources {
    address [ 172.17.28.19 172.17.28.20 172.17.28.21 172.17.28.22];
}

Para proteger todos os endereços para a address declaração, use o seguinte comando no [edit] nível:

[edit]
user@host# protect system login deny-sources address

Resultados

Todos os endereços ([172.17.28.19 172.17.28.20 172.17.28.21 172.17.28.22]) para a address declaração estão protegidos.

Procedimento passo a passo

Suponha que você tenha a seguinte configuração:

[edit groups ]
test1 {
    system {
        name-server {
            10.1.2.1;
            10.1.2.2;
            10.1.2.3;
            10.1.2.4;
        }
    }
}

Para proteger um ou mais endereços individuais para a name-server declaração, emita o seguinte comando no [edit] nível:

[edit]
user@host# protect groups test1 system name-server 10.1.2.1
user@host# protect groups test1 system name-server 10.1.2.4

Resultados

Os endereços 10.1.2.1 e 10.1.2.4 estão protegidos.

Procedimento passo a passo

Suponha que você tenha a seguinte configuração no nível de [edit system] hierarquia:

protect: system {
    host-name bigping;
    domain-search 10.1.2.1;
    login {
        deny-sources {
            protect: address [ 172.17.28.19 172.17.28.173 172.17.28.0 174.0.0.0 ];
        }
    }
}

Para desprotegir todo [edit system] o nível de hierarquia, emita o seguinte comando no [edit] nível:

[edit]
user@host# unprotect system

Resultados

Todo o system nível de hierarquia está desprotegido.

Propósito

Para verificar se uma hierarquia de configuração está protegida.

Ação

No modo de configuração, emita o show comando no nível de [edit] hierarquia para ver todas as hierarquias de configuração e declarações de configuração protegidas.

...
protect: system {
    host-name bigping;
    domain-search 10.1.2.1;
    login {
        deny-sources {
            protect: address [ 172.17.28.19 172.17.28.173 172.17.28.0 174.0.0.0 ];
        }
    }
}
...

Propósito

Para verificar se uma configuração está protegida ao tentar modificar a configuração usando os activatecomandos e renamecopyinsertdelete comandos.

Ação

Para verificar se uma configuração está protegida:

1. Tente usar o activate, copy, , renameinserte delete comandos para uma hierarquia de alto nível ou uma hierarquia de nível infantil ou uma declaração dentro da hierarquia.

   Para uma hierarquia ou declaração protegida, o Junos OS exibe um aviso apropriado de que o comando não executou. Por exemplo:

   content_copy zoom_out_map

   protect: system {
       host-name a;
       inactive: domain-search [ a b ];
   }
   

2. Para verificar se a hierarquia está protegida, tente emitir o activate comando para a domain-search declaração:

   [edit system]

   content_copy zoom_out_map

   user@host# activate system domain-search

   O Junos OS CLI exibe uma mensagem apropriada:

   content_copy zoom_out_map

   warning: [system] is protected, 'system domain-search' cannot be activated
   

Propósito

Para visualizar os protect comandos usados para proteger uma configuração.

Ação

1. Navegue até a hierarquia necessária.

2. Emite o show | display set relative comando.

user@host> show | display set relative
set system host-name bigping
set system domain-search 10.1.2.1
set system login deny-sources address 172.17.28.19
set system login deny-sources address 172.17.28.173
set system login deny-sources address 172.17.28.0
set system login deny-sources address 174.0.0.0
protect system login deny-sources address
protect system

Propósito

Para verificar se as hierarquias ou declarações protegidas também estão exibidas no XML. Hierarquias, declarações ou identificadores protegidos são exibidos com o | display xml atributo no XML.

Ação

Para ver a configuração em XML:

1. Navegue até a hierarquia que você deseja ver.

2. Use o show comando com o símbolo e a opção | display xmldo tubo:

   [edit system]

   content_copy zoom_out_map

   user@host# show | display xml
   [edit]
   user@host# show system | display xml 
   <rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.2I0/junos">
       <configuration junos:changed-seconds="1291279234" junos:changed-localtime="2017-12-02 00:40:34 PST">
               <system protect="protect">
                   <host-name>bigping</host-name>
                   <domain-search>10.1.2.1</domain-search>
                   <login>
                       <message>
           
           
           \jnpr
           
           \tUNAUTHORIZED USE OF THIS ROUTER
           \tIS STRICTLY PROHIBITED!
           
           
       </message>
                   <class>
                       <name>a</name>
                       <allow-commands>commit-synchronize</allow-commands>
                       <deny-commands>commit</deny-commands>
                   </class>
                   <deny-sources>
                       <address protect="protect">172.17.28.19</address>
                       <address protect="protect">172.17.28.173</address>
                       <address protect="protect">172.17.28.0</address>
                       <address protect="protect">174.0.0.0</address>
                   </deny-sources>
               </login>
               <syslog>
                   <archive>
                   </archive>
               </syslog>
           </system>
   </configuration>
   <cli>
       <banner>[edit]</banner>
   </cli>
       </rpc-reply>
   

   Nota:

   Carregar uma configuração XML com a unprotect="unprotect" tag desprotegi uma hierarquia já protegida. Por exemplo, suponha que você carregue a seguinte hierarquia XML:

   content_copy zoom_out_map

   <protocols unprotect="unprotect">
   	<ospf>
   	    <area>
   		<name>0.0.0.0</name>
   		<interface>
   		    <name>all</name>
   		</interface>
   	    </area>
   	</ospf>
       </protocols>
   
   

   A [edit protocols] hierarquia fica desprotegida se já estiver protegida.