cOS Core is designed to give both high performance and high reliability. Not only does it provide an extensive feature set, it also enables the administrator to be in full control of almost every detail of the system. This means the product can be deployed in the most challenging environments.

A good understanding on how cOS Core configuration is performed is crucial for proper usage of the system. For this reason, this section provides an in-depth presentation of the configuration subsystem as well as a description of how to work with the various management interfaces.

Management Access Methods

All management access requires that a Remote Management object exists to allow that access. The predefined Remote Management objects and how to create new ones are described in the next section.

Management access to cOS Core by an administrator depends on two factors:

The Default Interface and IP for Management Access

cOS Core assigns the default IPv4 address 192.168.1.1 to this management interface and HTTPS or SSH access is allowed from the 192.168.1.0/24 network.

Remote Management Objects

Predefined Remote Management Objects

For other types of access, such as SNMP access, additional Remote Management objects must be created.

Configuring IPv6 Management Access

Preventing Loss of Management Access

If the default 30 second delay is too short, the delay can be changed in the configuration's advanced settings. The setting to change has the name Validation Timeout in the Web Interface and NetconBiDirTimeout in the CLI. It is a global setting.

Device:/> set Settings RemoteMgmtSettings NetconBiDirTimeout=60

An Alternative Method of Changing the Management Interface

Changing the Management IP Address

There are two ways of changing the management interface:

Device:/> set Address IP4Address InterfaceAddresses/If1_ip
			Address=192.168.1.2

Changing a Remote Management Object

Device:/> set RemoteManagement RemoteMgmtHTTP rmgmt_http
			HTTP=Yes
			HTTPS=Yes
			Network=management_net
			Interface=If2

HA Cluster Management IPs Must Be Different

The individual IPv4 addresses for the management interface of the cluster master and slave units are held in the IP4 HA Address object for that interface and this is duplicated on both master and slave units. If the management interface IP in this address object is changed on one unit it will be automatically copied over to the other unit by the synchronization process.

Device:/> set Address IP4HAAddress lan_ha_ip Address:2=192.168.1.2

Adding Remote Management Objects

Device:/> add RemoteManagement RemoteMgmtHTTP https_access
			Network=all-nets
			Interface=If2
			LocalUserDatabase=AdminUsers
			HTTPS=Yes

Management Access Failure from an all-nets Route

To solve this problem, the administrator will need to create a specific route that routes management interface traffic leaving the firewall back to the management sub-network.

Viewing Management Status

Device:/> management

 Name          Type         Mode             Interface     Network
 ------------  -----------  ---------------  -----------   -----------
               InCenter
 MySSH         SSH          PubKey/Password  *             0.0.0.0/0

However, the command can be narrowed to give more detailed information about a particular management method using the -type option and this will be more helpful for InCenter. For example:

Device:/> management -type=InCenter
	
               Type: InCenter
             Status: Connected (14m 34s)
          Interface: If1
            Address: 192.168.199.200 (997)

The number 997 in the above is the port number. Similarly for SSH:

Device:/> management -type=SSH MySSH
	
               Name: MySSH
               Type: SSH
               Mode: PubKey/Password
          Interface: *
            Network: 0.0.0.0/0

Note that the name of the SSH management object must be included after the Type is specified because there may be more than one in the configuration. This is not needed when the Type is InCenter since there can only be one connection. It is also not needed if the type is InControl.

Where the Status field is shown in the above output, it can have one of the following values:

The management command and its options are also described in the separate cOS Core CLI Reference Guide.

In the default configuration, cOS Core has a predefined local user database called AdminUsers. This contains two predefined user accounts:

	Important
	For security reasons, it is recommended to change the default passwords of the default accounts as soon as possible after connecting with the Clavister firewall.

Creating Additional Accounts

Only One Administrator Account Can Be Logged In

However, cOS Core does allow the same administrator account (in other words, using the same administrator credentials) to be logged in more than once at the same time. This means it is possible, for example, to have a CLI session in progress as an administrator at the same time as also performing administrator management operations through the Web Interface.

cOS Core provides an intuitive Web Interface (WebUI) for management via an Ethernet interface using a standard modern web browser. This allows the administrator to perform remote management from anywhere on a private network or over the Internet using a standard computer without having to install proprietary client software.

The Default Management Interface in Virtual Environments

The Default Management Interface for Clavister Hardware Products

The Default Logical Management Interface for the RSG-400

More details on management access and how to change the management interface and/or IP address from the default is described in Section 2.1.2, Configuring Network Management Access.

Setting the Management Computer IP Address

The diagram below illustrates management computer connection via a switch.

Figure 2.1. Management Computer Connection

For some Clavister hardware products, an IPv4 DHCP server is already enabled in cOS Core on the management interface. This means it is necessary only to enable an IPv4 DHCP client on the management computer's Ethernet interface for the computer to get the required IP addresses automatically after connection. Manual configuration is not required. This feature is described in the relevant Getting Started Guide for the hardware product. A DHCP server is never enabled for cOS Core in virtual environments. A DHCP server is not enabled by default for cOS Core's logical interfaces in the RSG-400.

For a description of how to set a static IP address on a Windows or MacOS computer, see the relevant appendix in the separate Clavister Getting Started Guide for the platform being used.

Logging on to the Web Interface

Figure 2.2. Initial Browser Web Interface Access

Note that the protocol must be https:// when accessing cOS Core for the first time (HTTP access can be enabled later if required). With HTTPS, cOS Core will send back its own self-signed certificate for the encryption and the browser will ask the administrator to confirm that a security exception should be made.

When communication with the cOS Core is successfully established, a user authentication dialog like the one shown below will then be shown in the browser window.

Figure 2.3. Web Interface Login Dialog

After entering a valid username and password the Login button is clicked. If the user credentials are valid, the administrator is taken to the main Web Interface page.

	Note: Password caching is prevented
	The Web Interface prevents the caching of the password from the login credentials. This is also done in other cOS Core features where a password is requested through a browser screen. For example, with VPN authentication.

First Time Web Interface Login and the Setup Wizard

After successful login, the cOS Core Web Interface will be presented in the browser window. If no configuration changes have yet been uploaded to the firewall, the cOS Core Setup Wizard will start automatically to take a new user through the essential steps for cOS Core setup and establishing Internet access.

	Important: Switch off popup blocking
	Popup blocking must be disabled in the web browser to allow the cOS Core Setup Wizard to run since this appears in a popup window.

The wizard can be terminated and setup up done as a series of separate steps through the Web Interface if desired or alternatively through the CLI. Initial setup and the wizard are described in detail in the relevant Getting Started Guide for the computing platform being used.

Multi-language Support

It may occasionally be the case that an upgrade of cOS Core can contain features that temporarily lack a complete non-English translation because of time constraints. In this case the original English will be used as a temporary solution in place of a translation to the selected language.

The Web Browser Interface

	Note: Security policies control remote management access
	Access to the Web Interface is regulated by the configured remote management policy. By default, the system will only allow web access from the internal network. For more information about this topic, see Section 2.1.2, Configuring Network Management Access.

Interface Layout

	Tip: Hover over textual items for additional information
	Many of the textual items in the Web Interface have the ability to present additional information about the item if the screen cursor is held over them. For example, the screenshot below shows the information displayed when the cursor hovers over the Primary Retry Interval field text in the RADIUS settings.

The Web Interface Quick Search Feature

Figure 2.4. Initial Display of the Web Interface Quick Search Feature

As text is entered, the complete configuration list is reduced to objects that have paths containing the entered text. Note that the text entered uses spaces as a wildcard. For example, entering "network-ipsec" will display only objects with paths that contain the text "network-ipsec". Entering "network ipsec" will display objects with paths that contain both "network" and then later "ipsec". This is shown in the example below.

Figure 2.5. Web Interface Quick Search Filtering

Quick search becomes hidden when it loses focus.

Displaying Reference Documentation from the Web Interface

Activating Configuration Changes

cOS Core will then perform a reconfigure operation which might cause only a slight, brief delay to current data traffic. To prevent a change locking out the administrator, cOS Core will revert to the old configuration if communication is lost with the web browser after a fixed time delay (30 seconds by default). This delay is discussed further in Section 2.1.2, Configuring Network Management Access.

	Note: Examples in this guide assume activation will be performed
	Most of the examples in this guide deal with editing cOS Core configurations. The final activation step is usually not explicitly stated.

Using CA Signed Certificates

Device:/> set Settings RemoteMgmtSettings 
			HTTPSCertificate=HostA
			HTTPSRootCertificates=RootA2,RootA1,RootA3

These same CA signed certificates are also used by the cOS Core SSL VPN feature when a user is connecting for the first time and a dialog of options is displayed.

	Caution: Do not expose the management interface
	The above examples are provided for illustrative purposes only. It is never advisable to expose any management interface to access from the Internet.

Restarting cOS Core with the Web Interface

Logging out from the Web Interface

Management Traffic Routing with VPN Tunnels

If no specific route is set up for the management interface then all management traffic coming from cOS Core will automatically be routed into the VPN tunnel. If this is the case then a route should be added by the administrator to route management traffic destined for the management network to the correct interface.

Changing the Device Name

By default, this name is always System but this can be changed to another identifier by going to System > Device > Name in the Web Interface. A comment can also be entered along with a device name.

Changing the device name from the default can be very useful when an administrator is managing multiple firewalls and needs a reminder of which device they are working with.

This section describes the methods for accessing the cOS Core Command Line Interface (CLI) and these are:

The authentication aspects of these methods will also be discussed. How the CLI is used is described later in Section 2.1.6, Using the CLI.

Local Console CLI Access

Note that in a virtual environment, a physical connection is not needed since the local console corresponds to the console of the hypervisor.

Note that on the RSG-400, the cOS Core local console connection is via the Computer RS232 connection available on the physical X15 interface.

In summary, the physical local console setup prerequisites required for Clavister NetWall hardware are the following:

To physically connect a terminal to the console port, follow these steps:

Local Console Login Credentials for Virtual Environments

Local Console Login Credentials for ARM Based (64 bit) Hardware

Resetting a Forgotten Console Password

It can happen that the administrator forgets the console password. The possible options to deal with this circumstance are described in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/324735754

Changing the Local Console Port Line Speed

If required, the console line speed can be changed either through the Web Interface or through the CLI, as shown in the example below. Note that changing the speed is only relevant where the local console port has a serial (RS-232) connection.

Example 2.7. Setting the Console Line Speed

In this example the console line speed is set to 19200 bps.

Command-Line Interface

Device:/> set COMPortDevice COM1 BitsPerSecond=19200

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Go to: System > Advanced Settings > Com Port Devices

Click the console port line, configure the speed and then click OK

	Note: Restart cOS Core after changing the console speed
	After changing the local console port speed, the new setting will only come into effect after restarting cOS Core which can be done with the command: Device:/> shutdown A shutdown always restarts cOS Core.

SSH (Secure Shell) CLI Access

SSH access is controlled by SSH Management objects in cOS Core. Management SSH access is enabled by default with a predefined object called mgmt_ssh already existing in the default cOS Core configuration. This object allows SSH access on the default management interface with authentication being performed using the predefined local user database called AdminUsers.

Disabling SSH access can be done by deleting the relevant SSH Management object.

Device:/> add RemoteManagement RemoteMgmtSSH my_ssh_access
			Network=LAN_net
			Interface=LAN
			LocalUserDatabase=AdminUsers

Additional SSH Management Options

SSH Access Using IPv6

SSH Algorithm Selection

The algorithms included for the Recommended and Legacy settings are not listed here, but are displayed in the Web Interface page for the SSH Management object when each setting is selected. In addition, the RemoteMgmtSSH entry in the separate CLI Reference Guide lists the Recommended algorithms as the default property values.

Automatic Public SSH Key Authentication

Authentication in this way requires that the public key file of a public/private key pair is uploaded to cOS Core and associated with the relevant User object. Both the public and private key files are installed in the connecting SSH client.

SSH key authentication is enabled with the following steps:

Note that the setup procedure for SSH with keys is also described in a detailed article (including screenshots) in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/354852760

Device:/> cc LocalUserDatabase AdminUsers

Device:/AdminUsers> set User admin SSHKeys=my_public_ssh_key

Device:/AdminUsers> cc
Device:/> 

Logging Into the CLI

When accessing the CLI remotely through SSH, cOS Core will respond with a login prompt. Enter the username and press the Enter key, followed by the password and then Enter again. After the first startup, cOS Core will allow administrator login with the username admin and the password admin. This default password should be changed as soon as possible.

After a successful login, the CLI command prompt will appear:

Device:/> 

If a welcome message has been set then it will be displayed directly after the login. For security reasons, it is advisable to either disable or anonymize the CLI welcome message.

Changing the admin User Password

To change the password to, for example, my-password the following CLI commands are used. First we must change the current category to be the LocalUserDatabase called AdminUsers (which exists by default):

Device:/> cc LocalUserDatabase AdminUsers

We are now in AdminUsers and can change the password of the admin user:

Device:/AdminUsers> set User admin Password="my-password"

Finally, return the current category to the top level:

Device:/AdminUsers> cc

The Console Password Is Sometimes A Separate Password

For the Clavister NetWall 100, 300, 500 and 6000 hardware products, RSG-400, the console username and password is the same as the admin user in the default local database. By default, this will be admin and admin. Local console access is controlled by a predefined object called Local Management. The console password can be disabled if desired by changing the Local Management object.

cOS Core provides a Command Line Interface (CLI) for administrators who prefer or require a command line approach to administration, or who need more granular control of system configuration. The CLI is available either directly via the local console or remotely via an Ethernet interface using the Secure Shell (SSH) protocol from an SSH client. CLI access is discussed in the preceding Section 2.1.5, CLI Access.

The CLI provides a comprehensive set of commands that allow the display and modification of configuration data as well as allowing runtime data to be displayed and system maintenance tasks to be performed.

The CLI is case-sensitive. However, the tab-completion feature of the CLI does not require the correct case to perform completion and will alter the typed case if it is required.

This section only provides a summary for using the CLI. For a complete reference for all CLI commands, see the separate Clavister CLI Reference Guide.

The essential CLI commands for adding and manipulating configuration objects are the following:

CLI Command Structure

	<command> <object_category> <object_type> <object_name>

Device:/> show Address IP4Address my_address

The Object Category Can Be Omitted

Device:/> show IP4Address my_address

The same object name could be used within two different categories or types although this is best avoided in order to avoid ambiguity when reading configurations.

	Note: The terms Category and Context
	When describing the CLI, the terms object category and object context are used interchangeably.

A command like add can also include object properties. To add a new IP4Address object with an IP address of 10.49.02.01, the command would be:

Device:/> add Address IP4Address my_address Address=10.49.02.01

The object type can be optionally preceded by the object category. A category groups together a set of types and mainly used with tab completion which is described below.

CLI Help

	Tip: How to display help about help
	Typing the CLI command: Device:/> help help will give information about the help command itself.

The CLI Command History

Tab Completion

For example, when creating an IP Policy object, the command line might begin:

Device:/> add IPPolicy

If the tab key is now pressed, the mandatory space is inserted and if the tab key is pressed again the mandatory parameters are displayed:

A value is required for the following properties:

 DestinationInterface  Name     SourceInterface
 DestinationNetwork    Service  SourceNetwork

The following might be now be entered, with DestinationInterface incomplete:

Device:/> add IPPolicy DestinationI

If the tab key is now pressed, the property name is completed by cOS Core to become:

Device:/> add IPPolicy DestinationInterface=

Note that completion would not be possible for just Destination because this is still ambiguous and the "I" needs to be added so the first few characters can uniquely identify the property.

The tab key can then be used like this to help complete all the mandatory properties:

Device:/> add IPPolicy	SourceInterface=If2
			SourceNetwork=all-nets
			DestinationInterface=If2
			DestinationNetwork=all-nets
			Service=all_services
			Name=my_example_policy

	Note: CLI commands in this guide may be reformatted
	In order to make the individual elements of CLI commands in this publication clearer, they are sometimes broken into indented separate lines, like the example above. In an actual console window they would appear as a single continuous line which folds at the right margin.

Optional Parameters Are Tab Completed Last

Optional properties, if no value is specified the default is used:

 Action      Comments                Index        Schedule
 AppControl  DestAddressTranslation  LogEnabled   SourceAddressTra
 Attribute   DestinationGeoFilter    LogSeverity  SourceGeoFilter

Getting the Default or Current Property Value

Device:/> add LogReceiver LogReceiverSyslog log_example
	Address=example_ip
	LogSeverity=.<tab>

Device:/> add LogReceiver LogReceiverSyslog example
	Address=example_ip
	LogSeverity=Emergency,Alert,Critical,Error,Warning,Notice,Info

This same sequence can be used to get the current property value in a Set command. For example:

Device:/> set LogReceiver LogReceiverSyslog log_example Address=.<tab>

This will display the current value for the Address property.

Appending Property Values

For example, the following unfinished command may have been typed:

Device:/> set Address IP4Address If1_ip Address=

If a period "." followed by a tab is now entered, cOS Core displays the current value for Address. If that value were the IPv4 list 10.6.58.10,192.168.2.1 then the unfinished command line will automatically become:

Device:/> set Address IP4Address If1_ip Address=10.6.58.10,192.168.2.1

The displayed values can then be added to or changed with the backspace and back arrow keys before completing the command.

Object Categories

If a command such as add is entered and then the tab key is pressed, cOS Core displays all the available categories. By choosing a category and then pressing tab again all the object types for that category is displayed. Using categories means that the user has a simple way to specify what kind of object they are trying to specify and a manageable number of options are displayed after pressing tab.

Not all object types belong in a category. The object type UserAuthRule is a type without a category and will appear in the category list after pressing tab at the beginning of a command.

The category is sometimes also referred to as the CLI context. The category does not have to be entered for the command to be valid but always appears when using tab completion. As discussed later, when commands are created automatically using CLI scripting, cOS Core omits the category in the commands it creates.

Selecting Object Categories

Suppose a route is to be added to the routing table main. The first command would be:

Device:/> cc RoutingTable main
		
Device:/main> 

Notice that the command prompt changes to indicate the current category. The route can now be added:

Device:/main> add Route Name=new_route1 Interface=lan Network=If1_net

To deselect the category, the command is cc on its own:

Device:/main> cc
		
Device:/> 

The categories that require an initial cc command before object manipulation have a "/" character following their names when displayed by a show command. For example: RoutingTable/.

Specifying Multiple Property Values

		AccountingServers=server1,server2,server3

Inserting into Rule Lists

Referencing by Name

The CLI Reference Guide lists the parameter options available for each cOS Core object, including the Name= and Index= options.

Using Unique Names

The CLI will enforce unique naming within an object type. For reasons of backward compatibility to earlier cOS Core releases, an exception exists with IP rules which can have duplicate names, however it is strongly recommended to avoid this. If a duplicate IP rule name is used in two IP rules then only the Index value can uniquely identify each IP rule in subsequent CLI commands. Referencing an IP rule with a duplicated name will fail and result in an error message.

Changing the CLI Prompt and Device Name

Device:/> 

Device:/> set device name="my-prompt"

	Tip: The CLI prompt is the Web Interface device name
	When the command line prompt is changed to a new string value, this string also appears as the new device name in the top level node of the Web Interface navigation tree.

Activating and Committing Changes

Device:/> activate

Device:/> commit

	Tip: Examples in this guide assume activation will be performed
	Most of the examples in this guide deal with editing cOS Core configurations. The final activation step is usually not explicitly stated.

If the commit command is not entered after the activate command within a given time period (the default is 30 seconds) then the changes are automatically undone and the old configuration restored. This topic is discussed further in Section 2.1.2, Configuring Network Management Access.

	Caution: CLI commits can terminate Web Interface sessions
	A possible side-effect of committing changes via the CLI is that a logged in Web Interface session will require that user to log in again. This is because the Web Interface configuration view may no longer be valid.

Restarting and Rebooting cOS Core with the CLI

Device:/> shutdown

The shutdown command can be followed by an integer between 0 and 60 which is a delay in seconds before the command is executed. For example:

Device:/> shutdown 30

The default value for the delay is 5 seconds.

To shut down and restart both cOS Core and completely reinitialize the system, including the cOS Core loader (equivalent to switching the hardware off then on), use the command:

Device:/> shutdown -reboot

The -reboot option is rarely needed in normal circumstances and because it requires more time for the restart it is best not to use it. When cOS Core is upgraded the -reboot option is executed automatically during the upgrade process.

The same restart functions can be performed through the Web Interface by selecting the option: Status > Maintenance > Reset & Restore > Restart.

Initiating cOS Core Reconfiguration with the CLI

Device:/> reconf

Unlike the system restart described above, a reconfiguration does not usually affect current connections or VPN tunnels. However, with some IPsec tunnel changes, a reconfiguration will mean the tunnels are lost and have to be reestablished because the tunnel SAs are no longer valid.

Checking Configuration Integrity

Device:/> show -errors

Logging Out from the CLI

Configuring Remote Management Access on an Interface

First, we set the values for the IPv4 address objects for If2 which already exist in the cOS Core address book, starting with the interface IP:

Device:/> set Address IP4Address InterfaceAddresses/If2_ip
			Address=10.8.1.34

The network IP address for the interface must also be set to the appropriate value:

Device:/> set Address IP4Address InterfaceAddresses/If2_net
			Address=10.8.1.0/24

In this example, local IP addresses are used for illustration but these could be public IPv4 addresses instead. It is also assumed that the default address objects for the configuration are stored in an address book folder called InterfaceAddresses.

Next, create a remote HTTP management access object, in this example called HTTP_If2:

Device:/> add RemoteManagement RemoteMgmtHTTP HTTP_If2
			Interface=If2
			Network=all-nets
			LocalUserDatabase=AdminUsers
			AccessLevel=Admin
			HTTP=Yes

If we now activate and commit the new configuration, remote management access via the IPv4 address 10.8.1.34 is now possible using a web browser. If SSH management access is required then a RemoteMgmtSSH object should be added.

The assumption made with the above commands is that an all-nets route exists to the ISP's gateway. In other words, Internet access has been enabled for the firewall.

Managing Management Sessions with sessionmanager

The command without any options gives a summary of currently open sessions:

Device:/> sessionmanager
		
Session Manager status
----------------------
Active connections          :      3
Maximum allowed connections :     64
Local idle session timeout  :    900
Netcon idle session timeout :    600

To see a list of all sessions use the -list option. Below is some typical output showing the local console session:

Device:/> sessionmanager -list

User     Database         IP         Type    Mode     Access
-------- ---------------- ---------  ------- -------  --------
local    <empty>          0.0.0.0    local   console  admin

If the user has full administrator privileges, they can forcibly terminate another management session using the -disconnect option of the sessionmanager command.

The sessionmanager command options are fully documented in the CLI Reference Guide.

To allow the administrator to easily store and execute sets of CLI commands, cOS Core provides a feature called CLI scripting. A CLI script is a predefined sequence of CLI commands which can be executed after they are saved to a file and the file is then uploaded to the Clavister firewall.

The steps for creating a CLI script are as follows:

The CLI script command is the tool used for script management and execution. The complete syntax of the command is described in the CLI Reference Guide and specific examples of usage are detailed in the following sections. See also Section 2.1.6, Using the CLI.

	Note: Uploaded scripts are lost after a restart
	Uploaded CLI script files are not held in permanent memory and will disappear after system restarts.

Only Four Commands are Allowed in CLI Scripts

If any other command appears in a script file it is ignored during execution and a warning message is output. For example, the ping command will be ignored.

Executing Scripts

Device:/> script -execute -name=my_script.sgs

Script Variables

$1, $2, $3, $4......$n

The values substituted for these variable names are specified as a list at the end of the script -execute command line. The number n in the variable name indicates the variable value's position in this list. $1 comes first, $2 comes second and so on.

	Note: The symbol $0 is reserved
	Notice that the name of the first variable is $1. The variable $0 is reserved and is always replaced before execution by the name of the script file itself.

For example, a script called my_script.sgs is to be executed with IP address 126.12.11.01 replacing all occurrences of $1 in the script file and the string If1 address replacing all occurrences of $2.

The file my_script.sgs contains the single CLI command line:

add Address IP4Address If1_ip Address=$1 Comments=$2

To run this script file after uploading, the CLI command would be:

Device:/> script -execute -name=my_script.sgs 126.12.11.01 "If1 address"

When the script file runs, the variable replacement would mean that the file becomes:

add Address IP4Address If1_ip Address=126.12.11.01 Comments="If1 address"

Escaping Characters

Script Validation and Command Ordering

Although this approach might seem illogical, it is done to improve the readability of scripts. If something always has to be created before it is referred to then this can result in confused and disjointed script files and in large script files it is often preferable to group together related CLI commands.

Error Handling

For example, to run a script file called my_script2.sgs in this way so that errors do not terminate execution, the CLI command would be:

Device:/> script -execute -name=my_script2.sgs -force

If -force is used, the script will continue to execute even if errors are returned by a command in the script file.

Script Output

Device:/> script -execute -name=my_script2.sgs -verbose

Saving Scripts

For example, to move my_script.sgs to non-volatile memory, the command would be:

Device:/> script -store -name=my_script.sgs

Alternatively, all scripts can be moved to non-volatile memory with the command:

Device:/> script -store -all

Removing Scripts

Device:/> script -remove -name=my_script.sgs

Listing Scripts

Device:/> script
		
Name            Storage       Size (bytes)
--------------  ------------  --------------
my_script.sgs   RAM           8
my_script2.sgs  Disk          10

To list the content of a specific uploaded script file, for example my_script.sgs the command would be:

Device:/> script -show -name=my_script.sgs

Creating Scripts Automatically

If a configuration already exists that contains the objects that need to be copied, then running the script -create command on that configuration provides a way to automatically create the required script file. This script file can then be downloaded to the local management computer and then uploaded to and executed on other firewalls to duplicate the configuration objects.

For example, suppose the requirement is to create the same set of IP4Address objects on several firewalls that already exist on a particular firewall. The administrator would issue the following CLI command on the firewall that is to be copied:

Device:/> script -create Address IP4Address -name=new_script.sgs

This creates a script file called new_script_sgs which contains all the CLI commands necessary to create all IP4Address address objects in the configuration. The created file's contents might look something like the following:

add Address IP4Address If1_ip Address=10.6.60.10
add Address IP4Address If1_net Address=10.6.60.0/24
add Address IP4Address If1_br Address=10.6.60.255
add Address IP4Address If1_dns1 Address=141.1.1.1
		"
		"
		"

The file new_script_sgs can then be downloaded with SCP to the local management computer and then uploaded and executed on the other Clavister firewalls. The end result is that all firewalls will have the same IP4Address objects in their address book.

The following should be noted for automatically created scripts:

	Tip: Listing created script commands on the console
	To list the created CLI commands on the console instead of saving them to a file, leave out the option -name= in the script -create command.

Commenting in Script Files

# The following line defines the If1 IP address
add Address IP4Address If1_ip Address=10.6.60.10

Scripts Running Other Scripts

		script -execute -name my_script2.sgs

Running Scripts from the Web Interface

The script does not need to have a filetype of .sgs for this feature to be used. Any filetype is acceptable.

To upload and download files to or from the Clavister firewall, the Web Interface could be used in most cases. An alternative method of file transfer is to use the secure copy (SCP) protocol and an appropriate SCP client. SCP is based on the SSH protocol and many freely available SCP clients exist for most platforms. The SCP command line examples in this section are based on a typical command format for client software.

	Note: SFTP and some SCP functions not supported
	Currently, cOS Core does not support SFTP which means that transfers with later versions of the OpenSSH client may fail. This is solved by including the OpenSSH -O legacy option. Also, some extended SCP functions are not supported. For example, the file listing function found in WinSCP is not supported.

SCP Command Format

An example of how upload might be performed is using the command:

> scp <local_filename> <destination_gateway>

An example of how download might be performed is using the command:

> scp <source_gateway> <local_filename>

The source or destination firewall is usually of the form:
<user_name>@<firewall_ip_address>:<filepath>.

For example: admin@10.62.11.10:config.bak. The <user_name> must be a defined cOS Core user in the administrator user group.

	Note: SCP examples do not show the password prompt
	SCP will normally prompt for the user password after the command line but that prompt is not shown in the examples given in this document.

The following table summarizes the operations that can be performed between an SCP client and cOS Core.

The cOS Core Folder Structure

The resulting output is shown below:

Device:/> ls
		
HTTPALGBanners/
HTTPAuthBanners/
certificate/
config.bak
full.bak
license.lic
script/
sshpublickeys/

Apart from the individual files, the objects types listed are:

Examples of SCP Uploading and Downloading

When uploading, these files contain a unique header which identifies what they are. cOS Core checks this header and ensures the file is stored only in the root (all files do not have a header).

If an administrator username is admin1 and the IPv4 address of the Clavister firewall is 10.5.62.11 then to upload a configuration backup, the SCP command would be:

> scp config.bak admin1@10.5.62.11:

To download a configuration backup to the current local directory, the command would be:

> scp admin1@10.5.62.11:config.bak .

To upload a file to an object type under the root, the command is slightly different. If there is a local CLI script file called my_script.sgs then the upload command could be the following

> scp my_script.sgs admin1@10.5.62.11:script/

If we have the same CLI script file called my_scripts.sgs stored on the firewall then the download command would be:

> scp admin1@10.5.62.11:script/my_script.sgs .

Activating Uploads

Uploads of firmware upgrades (packaged in .upg files) or a full system backup (full.bak) are the exception. Both of these file types will result in an automatic system reboot. The other exception is for script uploads which do not affect the configuration.

Overview

The NetWall 100, 300, 500 and 6000 Series Have a Different Boot Menu

Accessing the Local Console Boot Menu

Once cOS Core has fully started, the boot menu cannot be displayed and a restart is required to have another opportunity to display it. When navigating the boot menu, the up/down arrow keys combined with the enter key can be used to select menu options. The <Esc> key can be used to return to the previous boot menu screen.

The Boot Menu Options Without a Password Set

Menu Changes After Setting a Console Password

After a successful console login, the boot menu is then displayed with the following extra options:

Reset Menu Options

Using the Console for CLI Commands

If a console password has been set and a login has not yet been performed then cOS Core will prompt for the console password before CLI commands can be entered and it is therefore recommended the console password is enabled as soon as possible in order to prevent unauthorized access.

	Note: Output buffer limitations
	The only limitation with issuing CLI commands through the local console is that there is a finite buffer allocated for output. This buffer limit means that a large volume of console output may be truncated. This happens rarely and usually only with data dumps from certain diagnostic commands. In such cases it is better to issue the commands using an SSH client instead.

This section covers the boot menu for the Clavister NetWall 100, 300, 500 and 6000 Series hardware products which is accessible through the local console on those appliances. The boot menu for cOS Core in a virtualized environment and on older Clavister hardware products is covered by Section 2.1.9, The Local Console Boot Menu.

Accessing the Local Console Boot Menu

Once cOS Core has fully started, the boot menu cannot be displayed and a restart is required to have another opportunity to display it.

The Boot Menu Options

For system management tasks in the default cOS Core configuration, the administrator logs in to the Web Interface or CLI via SSH using a username and password that are checked against the credentials stored in a local cOS Core database.

An alternative to using a local database is to have cOS Core perform authentication of the entered credentials against an external RADIUS server. This is done by changing the properties of the Remote Management object mgmt_http for Web Interface access and/or the properties of the mgmt_ssh object for CLI access via SSH. Configuring either of these objects for RADIUS authentication consists of the following steps:

	Important: Group membership must be defined on the server
	It is important to note that all management users authenticated by a RADIUS server must have their group membership defined on the RADIUS server. They cannot be authenticated without group membership which cOS Core matches against the Admin Groups and Audit Groups properties.

	Note: Set the RADIUS Vendor ID for group membership
	If the RADIUS server sends the group membership, it is necessary to use the Clavister-User-Group vendor specific attribute when configuring the server. The Clavister Vendor ID is 5089 and the Clavister-User-Group is defined as vendor-type 1 with a string value type.

The Login Message Changes for a Group Mismatch

However, there is one exception. When the user credentials are correct but the group name returned by the RADIUS server does not match any group in the Admin Groups or Audit Groups, then the Web Interface or CLI will display the following message:

	You do not have permission to access this device.

Generated Log Event Messages

Below are some typical examples of log event messages:

event=admin_login authsystem=HTTP interface=If1 username=jdoe
usergroups=sys_admins access_level=administrator authsource=RADIUS
userdb=radius_auth1 server_ip=192.168.1.1 server_port=80
client_ip=192.168.1.30 client_port=6132

event=admin_authorization_failed action=disallow_admin_access
authsystem=HTTP interface=If1 username=jdoe usergroups=sys_admins
authsource=RADIUS	userdb=radius_auth1 server_ip=192.168.1.1
server_port=80 client_ip=192.168.1.30 client_port=6042

event=admin_authsource_timeout authsystem=HTTP interface=If1 username=jdoe
authsource=RADIUS server_ip=192.168.1.1 server_port=80
client_ip=192.168.1.30 client_port=5987

The Local Console is a Fallback Option

Device:/> set RemoteManagement RemoteMgmtHTTP rmgmt_http
			AuthSource=RADIUS
			AuthOrder=LocalFirst
			RadiusServers=radius_auth1,radius_auth2
			AdminGroups=sys_admins

To ensure system security, cOS Core has a global option to enforce the use of strong passwords for users in any local user databases. This option is only available in cOS Core version 11.10.00 and later.

A strong password is defined by cOS Core as follows:

Enabling Strong Passwords

If it is not disabled in the setup wizard then the wizard will require a conforming strong password to be entered to replace the default weak admin password. If running the setup wizard is skipped and the strong password option is left enabled, cOS Core will not allow configuration changes to be activated until the admin password conforms to the strong password rules.

If setting up cOS Core for the first time, it is strongly recommended that the first step taken is to change the admin user password from the default weak value of admin to a password that conforms to the strong password rules.

Checking of Strong Passwords

Apart from the user admin, a fresh cOS Core configuration will also have a pre-existing user called audit with the default password audit. The audit user password will remain weak until the administrator changes it to a password that conforms to the strong password rules listed above.

Upgrading Older cOS Core Versions

However, all passwords for users created before the upgrade will be flagged as not having strong passwords, even if the strong password option is enabled later. If a weak password for a user from the old configuration is to be made strong then the password for that user should be changed to a strong password after the upgrade. If the strong passwords option is enabled, cOS Core will make sure that the new password conforms to the strong password rules when it is entered.

Checking User Password Status

Device:/> set Settings MiscSettings EnforceStrongPasswords=No

Under the Remote Management section of the Web Interface or InControl a number of advanced settings can be found. These are:

SSH Before Rules

Default: Enabled

WebUI Before Rules

Default: Enabled

Validation Timeout

Default: 30

WebUI HTTP port

Default: 80

WebUI HTTPS port

Default: 443

HTTPS Certificate

Default: HTTPS

Configuration Objects

Object Types

Object Organization

In the CLI, similar configuration object types are grouped together in a category. These categories are different from the structure used in the Web Interface to allow quick access to the configuration objects in the CLI. The IP4Address, IP4Group and EthernetAddress types are, for instance, grouped in a category named Address, as they all represent different addresses. Consequently, Ethernet and VLAN objects are all grouped in a category named Interface, as they are all interface objects. The categories have actually no impact on the system configuration; they are merely provided as means to simplify administration.

The following examples show how to manipulate objects.

Device:/> show Service

Device:/> show Service ServiceTCPUDP telnet
						
          Property  Value
 -----------------  -------
             Name:  telnet
 DestinationPorts:  23
             Type:  TCP
      SourcePorts:  0-65535
         SYNRelay:  No
   PassICMPReturn:  No
              ALG:  <empty>
      MaxSessions:  1000
         Comments:  Telnet

Device:/> set Service ServiceTCPUDP telnet Comments="Modified Comment"

Device:/> show Service ServiceTCPUDP telnet
						
          Property  Value
 -----------------  -------
             Name:  telnet
 DestinationPorts:  23
             Type:  TCP
      SourcePorts:  0-65535
         SYNRelay:  No
   PassICMPReturn:  No
              ALG:  <empty>
      MaxSessions:  1000
         Comments:  Modified Comment

	Important: Configuration changes must be activated
	Changes to a configuration object will not be applied to a running system until the new cOS Core configuration is activated.

Device:/> add Address IP4Address myhost Address=192.168.10.10

Device:/> show Address IP4Address myhost
						
              Property  Value
 ---------------------  -------------
                 Name:  myhost
              Address:  192.168.10.10
       UserAuthGroups:  <empty>
 NoDefinedCredentials:  No
             Comments:  <empty>

Device:/> delete Address IP4Address myhost

Device:/> undelete Address IP4Address myhost

Listing Modified Objects

Device:/> show -changes
						
    Type           Object
    -------------  ------
 -  IP4Address     myhost
 *  ServiceTCPUDP  telnet

Activating and Committing a Configuration

	Important: Committing IPsec Changes
	The administrator should be aware that if any changes that affect the configurations of live IPsec tunnels are committed, then those live tunnels connections will be terminated and must be reestablished.

If the new configuration is validated, cOS Core will wait for a short period (30 seconds by default) during which a connection to the administrator must be reestablished.

If a lost connection could not be re-established then cOS Core will revert to using the previous configuration. This is a fail-safe mechanism and, amongst other things, can help prevent a remote administrator from locking themselves out.

Device:/> activate

Device:/> commit

	Note: Changes must be committed
	The configuration must be committed before changes are saved. All changes to a configuration can be ignored simply by not committing a changed configuration.

Configuration Revision Numbers

The first part of the number, nn, is incremented every time a new configuration is activated through a non-InControl interface such as the Web Interface or CLI. The second part of the number, mm, is incremented every time a new configuration is activated through an InControl client. In the Web Interface, only the first part is displayed as the Configuration number in the start page.