Chapter 7: Managing NetShield Nodes

Home Prev	InCenter 2.2.5 On-Premises Administration Guide	Next

When any firewall is added to InCenter it means the following:

InCenter has the ability to communicate with that particular firewall.
There is a copy of that node's configuration in the InCenter database.
For NetShield nodes only, the local configuration in the firewall has a flag set to indicate that it is now under centralized management control. The meaning of this type of control is discussed further in Chapter 10, Centralized Management Control
For NetShield nodes, changes to the node configuration can be performed via the InCenter user interface and then be deployed in a single operation. The node's configuration as well as the InCenter database copy are both updated with the changes. With NetWall nodes, examining node statistics becomes possible through dashboards in the WebUI.

A RemoteMgmtSSH Object is Required on a Node

Before a NetShield firewall can be added, its configuration must be changed locally to allow InCenter access using SSH. To do this, a RemoteMgmtSSH object must be added that allows SSH access by InCenter so that the firewall acts as an administrator SSH server. Doing this is described in the separate cOS Core Administration Guide.

Along with creating a RemoteMgmtSSH object on a NetShield node , it is recommended to also make the following local changes to the node:

It is recommended to create a new User object on the firewall which will be the user that is used by InCenter for connection.
The AuthenticationProfile object on the firewall used for InCenter access should have its MaxMultipleSessions property set to at least a value of 5 or higher.
For direct local access to InCenter, it is recommended to disable the default admin user and instead set up a new User object in the local database for this purpose.

Note that configuring a NetWall node for InCenter access is done differently to NetShield nodes and is described in Section 6.3, Setting Up Monitoring.

Node Naming

When a node is added to InCenter, a Name must be specified. The following should be noted about this name:

The name must be unique within InCenter.
The default node name is a valid name but it can be used for only one node in InCenter because of the requirement for uniqueness.
The current name on the firewall will be changed to the node name specified in InCenter. In other words, the two are always synchronized.

7.1. Adding Nodes with the CLI

When managing a Clavister Next Generation Firewall for the first time using the CLI, the steps are as follows:

Create an RemoteMgmtSSH object on the node to allow InCenter management.
Access the InCenter CLI using an SSH client.
Add the Clavister Next Generation Firewall as a node.
Import the node's configuration to the InCenter database.
Make any required changes to the node configuration.
Activate all changes and then commit them.

Adding any node and importing its configuration into InCenter only has to be done once.

Adding a Node with Username/Password Authentication

Suppose the Ethernet interface of a Clavister Next Generation Firewall for management access has the IPv4 address 203.0.113.5 and that the username for administrator access is admin and the password is mysecret.

To add this node with the logical name my-node1, the CLI would be:

admin@InCenter:/> add StandaloneNode
			Name=my-node1
			IP=203.0.113.5
			Username=admin
			NodeType=NetWall
			AuthenticationMethod=Password
			Password=mysecret

Note that the NodeType property must be specified. The NodeType would be set to NetShield for NetShield nodes.

The following should be noted about the add command:

The NodeType property must be specified since this does not have a default value.
The optional parameter Group= could have been included in the above command to specify membership of some InCenter node group. Group membership can also be specified later. Using groups is described further in Chapter 15, Node Groups.
A license could also be optionally specified for the node using the Licensed=Yes parameter along with the License= parameter to specify the License object to use. Licenses are discussed further in Chapter 13, License Management.

Adding a Node with Public Key Authentication

Using public key authentication is the recommended method of adding a node to InCenter.

Assuming that a SSHPrivateKey object has already been defined in InCenter and the node itself has been configured for public key authentication, the modified CLI to add a node would be the following:

admin@InCenter:/> add StandaloneNode
			Name=my-node1
			IP=203.0.113.5
			Username=admin
			NodeType=NetWall	
			AuthenticationMethod=PublicKey
			PrivateKey=my-key

Note that if the node had already been added using username and password authentication, the authentication method could be changed to use public key authentication with a set command. For example:

admin@InCenter:/> set StandaloneNode my-node1
			AuthenticationMethod=PublicKey
			PrivateKey=my-key

Creating a SSHPrivateKey object is described in Section 7.5, Using Public Key Authentication.

Deploying Changes to a Node

Even though the node is added in the CLI, no subsequent configuration made with the InCenter CLI changes will be stored in the InCenter database or deployed to the node until an activate command is issued. This must be followed by a commit command to make these changes permanent:

admin@InCenter:/> activate
Activate successful
admin@InCenter:/> commit
Committed
admin@InCenter:/>

This command sequence is exactly the same as the sequence used when making the firewall configuration change directly. It makes sure that the change will not break communication with the server by demanding that a second command is entered to commit the changes.

The activate command will apply all pending changes to affected nodes at the same time. If an error occurs, all changes are rolled back. If all changes are successful, the commit command will make the changes permanent.

Importing the Node Configuration

Once a node is defined to InCenter, the next step is to import the firewall configuration into InCenter. This is done with the following command sequence:

admin@InCenter:/> node my-node1 import
Importing configuration from: my-node1
Import done
admin@InCenter:/> activate
Activate successful
admin@InCenter:/> commit
Committed
admin@InCenter:/>

This sequence results in the node configuration being read and saved in the InCenter configuration database on the server. Subsequent configuration changes made through InCenter will now be reflected in both the node configuration and InCenter's database copy.

In addition, the node is brought under centralized management control by InCenter and it will no longer be possible to change the configuration of the node by direct connection to it. This is explained further in Chapter 10, Centralized Management Control.

	Note: Import requires an Activate/Commit
	An import command must be followed by an activate then a commit command for the import into InCenter to be completed.

If an import operation is not performed, it will not be possible to make node configuration changes under the control of InCenter.

Nodes Can Also Be Exported

InCenter provides an export operation for a standalone node which is the opposite to import. This will push the current configuration held in the InCenter database out to the node so that it synchronizes with the database. For example:

admin@InCenter:/> node my-node1 export

The export command is discussed further in Section 4.4, Activating Changes.

Editing Node Properties with the CLI

Any of a node's properties except the name can be changed using the set command. For example, to change the IP address of the node called my-node1 to 203.0.113.9, the following command could be used:

admin@InCenter:/> set StandaloneNode my-node1 IP=203.0.113.9