Example: Protecting the Junos OS Configuration from Modification or Deletion
This example shows how to use the protect and unprotect commands in the configuration mode to protect and unprotect the CLI configuration.
Requirements
This example uses the following hardware and software components:
- A J Series, M Series, MX Series, or T Series device
- Junos OS 11.2 or later running on all devices
Overview
The Junos OS enables you to protect the device configuration from being modified or deleted by other users. This can be accomplished by using the protect command in the configuration mode of the CLI. Likewise, you can also unprotect a protected configuration by using the unprotect command.
These commands can be used at any level of the configuration hierarchy—a top-level parent hierarchy or a configuration statement or an identifier within the lowest level of the hierarchy.
If a configuration hierarchy is protected, users cannot perform the following activities:
- Deleting or modifying a hierarchy or a statement or identifier within the protected hierarchy
- Inserting a new configuration statement or an identifier within the protected hierarchy
- Renaming a statement or identifier within the protected hierarchy
- Copying a configuration into a protected hierarchy
- Activating or deactivating statements within a protected hierarchy
- Annotating a protected hierarchy
Protecting a Parent-Level Hierarchy
Step-by-Step Procedure
To protect a configuration at the top level of the hierarchy:
- Identify the hierarchy that you want to protect and issue
the protect command for the hierarchy at the [edit] hierarchy level.
For example, if you want to protect the entire [edit access] hierarchy level, issue the following command:
[edit]user@host# protect access
Results
Protects all elements under the parent hierarchy.
 |
|
Protecting a Child Hierarchy
Step-by-Step Procedure
To protect a child hierarchy contained within a parent hierarchy:
- Navigate to the parent container hierarchy. Use the protect command for the hierarchy at the parent level.
For example, if you want to protect the [edit system syslog console] hierarchy level, use the following command at the [edit system syslog] hierarchy level.
[edit system syslog]user@host# protect console
Results
Protects all elements under the child hierarchy.
Protecting a Configuration Statement Within a Hierarchy
Step-by-Step Procedure
To protect a configuration statement within a hierarchy level:
- Navigate to the hierarchy level containing the statement
that you want to protect and issue the protect command
for the hierarchy.
For example, if you want to protect the host-name statement under the [edit system] hierarchy level, issue the following command:
[edit system]user@host# protect host-name
Results
Protecting a List of Identifiers for a Configuration Statement
Step-by-Step Procedure
Some configuration statements can take multiple values. For example, the address statement at the [edit system login deny-sources] hierarchy level can take a list of hostnames, IPv4 addresses, or IPv6 addresses. Suppose you have the following configuration:
- To protect all the addresses for the address statement, issue the following command at the [edit] level:[edit]user@host# protect system login deny-sources address
Results
All the addresses ([172.17.28.19 172.17.28.20 172.17.28.21 172.17.28.22]) for the address statement are protected.
Protecting an Individual Member from a Homogenous List
Step-by-Step Procedure
Suppose you have the following configuration:
- To protect one or more individual addresses for the name-server statement, issue the following command at the [edit] level:[edit]user@host# protect groups test1 system name-server 10.1.2.1user@host# protect groups test1 system name-server 10.1.2.4
Results
Addresses 10.1.2.1 and 10.1.2.4 are protected.
Unprotecting a Configuration
Step-by-Step Procedure
Suppose you have the following configuration at the [edit system] hierarchy level:
- To unprotect the entire [edit system] hierarchy
level, issue the following command at the [edit] level:[edit]user@host# unprotect system
Results
The entire system hierarchy level is unprotected.
Verification
Verify That a Hierarchy Is Protected Using the show Command
Purpose
To check that a configuration hierarchy is protected.
Action
In the configuration mode, issue the show command at the [edit] hierarchy level to see all the configuration hierarchies and configuration statements that are protected.
| Note: All protected hierarchies or statements are prefixed with a protect: string. |
Verify That a Hierarchy Is Protected by Attempting to Modify a Configuration
Purpose
To verify that a configuration is protected by trying to modify the configuration using the activate, copy, insert, rename, and delete commands.
Action
To verify that a configuration is protected:
- Try using the activate, copy, insert, rename, and delete commands for a top-level
hierarchy or a child-level hierarchy or a statement within the hierarchy.
For a protected hierarchy or statement, the Junos OS displays an appropriate warning that the command has not executed. For example:
protect: system {host-name a;inactive: domain-search [ a b ];} - To verify that the hierarchy is protected, try issuing
the activate command for the domain-search statement:
[edit system]
user@host# activate system domain-searchThe Junos OS CLI displays an appropriate message:
warning: [system] is protected, 'system domain-search' cannot be activated
Verify Usage of the protect Command
Purpose
To view the protect commands used for protecting a configuration.
Action
- Navigate to the required hierarchy.
- Issue the show | display set relative command.
user@host> show | display set relativeset 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
View the Configuration in XML
Purpose
To check if the protected hierarchies or statements are also displayed in the XML. Protected hierarchies, statements, or identifiers are displayed with the protect="protect" attribute in the XML.
Action
To view the configuration in XML:
- Navigate to the hierarchy you want to view and issue the show command with the pipe symbol and option | display xml:
[edit system]
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="2010-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>Note: Loading an XML configuration with the unprotect="unprotect" tag unprotects an already protected hierarchy. For example, suppose you load the following XML hierarchy:
<protocols unprotect="unprotect"> <ospf> <area> <name>0.0.0.0</name> <interface> <name>all</name> </interface> </area> </ospf> </protocols>The [edit protocols] hierarchy becomes unprotected if it is already protected.
