cOS Core 14.00.13 Administration Guide

The cOS Core architecture is centered around the concept of state-based connections. Traditional IP routers or switches commonly inspect all packets and then perform forwarding decisions based on information found in the packet headers. With this approach, packets are forwarded without any sense of context which eliminates any possibility to detect and analyze complex protocols and enforce corresponding security policies.

Stateful Inspection

The stateful inspection approach additionally provides high throughput performance with the added advantage of a design that is highly scalable. The cOS Core subsystem that implements stateful inspection will sometimes be referred to in documentation as the cOS Core state-engine.

The basic building blocks in cOS Core are interfaces, logical objects and various types of rules (or rule sets).

Interfaces

The following types of interface are supported in cOS Core:

Interface Symmetry

Logical Objects

Another example of logical objects are services which represent specific protocol and port combinations. Also important are the Application Layer Gateway (ALG) objects which are used to define additional parameters on specific protocols such as HTTP, FTP, SMTP and H.323.

cOS Core Rule Sets

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

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.

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.

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

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.

SSH Access Using IPv6

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, 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

SSH Idle Timeout

Default: 900

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.

Correctly setting the date and time is important for cOS Core to operate properly. Time scheduled policies, auto-update of the IDP and Anti-Virus databases, and other product features such as digital certificates require that the system clock is accurately set.

In addition, log messages are tagged with timestamps in order to indicate when a specific event occurred. Not only does this assume a working clock, but also that the clock is correctly synchronized with other equipment in the network.

The Local System Clock

Methods of Setting the Time

Current Date and Time

Device:/> time -set YYYY-mm-DD HH:MM:SS

Device:/> time -set 2008-04-27 09:25:00

	Note: A reconfigure is not required
	A new date and time will be applied by cOS Core as soon as it is set. There is no need to reconfigure or restart the system.

Time Zones

Setting the Location and Enabling Daylight Saving Time (DST)

By default, the Location property is set to a value of ClavisterHQ (in other words, Stockholm time). The DST (daylight saving time) property is also enabled by default which means that the daylight saving rules for the given location will be automatically followed.

The Location property can be changed from the default at any time by the administrator. However, it can also be changed in one of the steps in the Startup Wizard which will run when cOS Core is started up for the first time.

Device:/> set DateTime Location=Asia/Tokyo

cOS Core is able to adjust the system time automatically using information received from one or more external time servers. These servers provide a highly accurate time, usually using atomic clocks. Using time servers is recommended as it ensures cOS Core will have its date and time aligned with other network devices.

Time Synchronization Protocols

Methods of Configuring Time Servers

Configuring these two types of server is described next.

Configuring the Clavister Time Server

Note that at least one external DNS server must be configured in cOS Core so that the FQDN of the Clavister's time server can be resolved.

Device:/> set DateTime TimeSynchronization=Clavister

Configuring Custom Time Servers

When specifying the IP address of custom time servers, there are only two ways this can be done:

Device:/> set DateTime TimeSynchronization=custom
			TimeSyncServer1=ntp1_fqdn
			TimeSyncServer2=ntp2_fqdn
			TimeSyncInterval=86400

Device:/> time -sync
Attempting to synchronize system time...

Server time: 2008-02-27 12:21:52 (UTC+00:00)
Local time:  2008-02-27 12:24:30 (UTC+00:00) (diff: 158)

Local time successfully changed to server time.

Maximum Time Adjustment

For example, assume that the maximum adjustment value is set to 60 seconds and the current cOS Core time is 16:42:35. If a time server responds with a time of 16:43:38 then the difference is 63 seconds. This is greater than the maximum adjustment value so no update occurs for this response.

Device:/> set DateTime TimeSyncMaxAdjust=40000

Sometimes it might be necessary to override the maximum adjustment. For example, if time synchronization has just been enabled and the initial time difference is greater than the maximum adjustment value. It is then possible to manually force a synchronization and disregard the maximum adjustment parameter.

Device:/> time -sync -force

Synchronization Intervals

Below is a summary of the key properties for date and time:

Time Zone Location

Default: ClavisterHQ (Stockholm)

DST

Default: Enabled

Time Sync Server Type

Default: SNTP

Primary Time Server

Default: None

Secondary Time Server

Default: None

tertiary Time Server

Default: None

Interval between synchronization

Default: 86400

Max time drift

Default: 600

Group interval

Default: 10

The ability to log and analyze system activities is an essential feature of cOS Core. Logging enables not only monitoring of system status and health, but also allows auditing of network usage and assists in troubleshooting.

Log Message Generation

Log events are always generated for some aspects of cOS Core processing such as buffer usage, DHCP clients, High Availability and IPsec. The generation of events for some cOS Core subsystems, such as IP rule set usage, can be disabled or enabled as required.

Whenever an event message is generated, it can be filtered and distributed to a variety of Event Receivers, including Syslog and SNMP Trap receivers. Up to eight event receivers can be defined per firewall, with each receiver having its own customizable event filter.

Log Message Analysis Using InCenter

More information about the InCenter Cloud service can be found in the separate InCenter Cloud Administration Guide and companion InCenter Cloud Getting Started Guide. To begin using the InCenter cloud, request a subscription to the product by selecting the option after logging into the relevant MyClavister account.

The InCenter product is also available as an "on-premises" option so that the administrator can run the software on their own private server and the log messages from firewalls can be sent to this server instead of the cloud. This product is further described in the separate InCenter On-Premises Administration Guide. To obtain a license for this software, contact a Clavister sales office.

InCenter will not be discussed further in this section.

Event Types

The conn_open event, for example, is a typical high-level event that generates an event message whenever a new connection is established, given that the matching security policy rule has defined that event messages should be generated for that connection.

An example of a low-level event would be the startup_normal event, which generates a mandatory event message as soon as the system starts up.

Message Format

A list of all event messages can be found in the separate cOS Core Log Message Reference Guide. The beginning of that publication describes the design of log messages, and the various parameters that can appear in them.

Event Severity

By default, cOS Core sends any generated messages of level Info and above to any configured log servers but the level required for sending can be changed by the administrator. The Debug severity is intended for system troubleshooting only and is not normally used. All individual log messages with their meaning are described in the separate cOS Core Log Reference Guide.

Event Message Timestamping

The exception to this is log messages which are displayed using the local Memlog feature. These are always time stamped with the current, local system time.

The event messages generated by cOS Core can be sent to one or more log receivers. For cOS Core to send log messages, it is necessary to configure in cOS Core one or more such log receiver objects. Each log receiver object is configured with properties that specify which events to capture and where to send them (for example, an Syslog external server).

cOS Core can distribute event messages to different types of receivers and these are enabled by creating any of the following types of Log Receiver objects.

Overview

Viewing and Saving the Memlog Contents in the Web Interface

Viewing with the CLI

InControl can also be used to view the memlog buffer and this is described further in the separate InControl Administrator Guide.

Memlog has Limited Capacity

When the allocated memory is filled up with log messages, the oldest messages are discarded to make room for newer incoming messages. This means that when cOS Core is creating large numbers of messages in systems with, for example, large numbers of VPN tunnels, the memlog information becomes less meaningful since it reflects a limited recent time period.

All memlog buffers are emptied by a restart of cOS Core but a reconfiguration operation will leave them unaffected.

Memlog Timestamps

Disabling and Enabling Memlog

Further memlog Discussion

https://kb.clavister.com/354851504

Overview

Syslog Message Format

Feb 5 2000 09:45:23 firewall.example.com

Feb 5 2000 09:45:23 firewall.example.com EFW: DROP:

In order to facilitate automated processing of all messages, cOS Core writes all log data to a single line of text. All data following the initial text is presented in the format name=value. This enables automatic filters to easily find the values they are looking for without assuming that a specific piece of data is in a specific location in the log entry.

	Note: The Prio and Severity fields
	The Prio= field in SysLog messages contains the same information as the Severity field for Clavister Logger messages. However, the ordering of the numbering is reversed.

Setting the Facility

Device:/> add LogReceiver LogReceiverSyslog my_syslog
			IPAddress=192.168.6.1
			LogSeverity=Emergency,Alert
			Facility=local1

	Note: The Syslog server itself must be correctly configured
	The external Syslog server itself may have to be configured to correctly receive log messages from cOS Core. Refer to the documentation for the specific Syslog server being used in order to do this.

RFC-5424 Compliance

InCenter Compliance

The InCenter product is discussed further in the separate InCenter Administration Guide and InCenter Cloud Administration Guide.

Setting the Hostname

If RFC-5424 compliance is enabled, it is also possible to set the hostname to a specific value. The example below shows how this is done.

Device:/> add LogReceiver LogReceiverSyslog my_syslog
			IPAddress=192.168.5.1
			RFC5424=Yes
			Hostname=my_host1
			LogSeverity=Emergency,Alert

As described in Section 2.3.4, The Memory Log Receiver (memlog), there is a basic ability to monitor and view the log messages stored in the system memlog buffer through the Web Interface or InControl. The logsnoop CLI command extends this ability so that log messages generated by cOS Core can be viewed in any of the following ways:

Switching Real-time Logsnooping On and Off

Device:/> logsnoop -on

LOG: 2014-01-13 13:53:39 SYSTEM prio=Alert id=03200021 rev=1
event=demo_mode action=shutdown_soon shutdown=halt time=7200

Device:/> logsnoop

Real time log snooping is enabled. Filter: All

Device:/> logsnoop -off

Filtering Log Messages

A complete list of command parameters can be found in the entry of logsnoop in the separate cOS Core CLI Reference Guide. Alternatively, the following the CLI command can be used:

Device:/> help logsnoop

Stopping logsnoop is also discussed in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/324736057

Filtering Wildcards and Free-text Filtering

For example, to find the text warning followed somewhere by udp, the command would be:

Device:/> logsnoop -on -pattern=*warning*udp*

The -pattern parameter specifies a free-text text filter for log messages. Wildcarding can also be used with other filtering parameters and is not limited to -pattern.

Limiting Log Message Numbers

Examining Memlog

For example, the entire contents of the memlog buffer can be examined using the command:

Device:/> logsnoop -on -source=memlog

Even though the -on parameter must be used, this command does not switch on real-time logging and a matching command with the -off parameter is therefore not needed later.

Examining Memlog Plus New Log Messages

Device:/> logsnoop -on -source=both

If -source=both is used, a second command with the -off parameter will be needed later to switch off real-time logging.

Specifying a Time Range

The time value itself can be specified in the following formats:

When not looking at memlog, setting the times will act as a way of turning logsnoop on and off at specified future times. If the -source=memlog option is used, the start and end times are used to look at a specific period in the memlog history.

Overview

The intended purpose of this feature is to provide a means of quickly alerting the administrator of any important cOS Core events so the selected level of severity for the events sent in this way will usually be very high.

Mail Alerting Object Properties

Event Trigger Mode

Advanced Options

Mail Alerting Processing Flow

Assume that since sending its last email, 6 log events occur that are eligible for mailing and these occur over a 6 minute period of time. The diagram below divides the 6 minutes into 2 minute sections for clarity and shows when the events occur.

The processing flow is as follows:

Sending Test Emails

Device:/> smtp -sendmail -logreceiver=<mail-alerting-object-name>

This is message #1 sent to test the Mail Alerting object "my_mail_alert"

In the Web Interface, the test button can be pushed even while the Mail Alerting object is being created and before the configuration change is activated and saved. This is not true with the equivalent CLI test mail function.

Sending to Multiple Email Addresses

Mail Size Limit

 message(s) have been discarded because of because of email body size limit

If more than one Mail Alerting object is created, each will have its own piece of memory allocated for building emails.

Device:/> add LogReceiver MailAlerting my_mail_alert
			IPAddress=203.0.113.10
			Receiver=admn@example.com
			Sender=device1
			Subject="Log message summary"
			LogSeverity=Emergency,Alert

The Clavister Logger refers to the proprietary Clavister logging method that uses the proprietary FWLog message format for sending log data. A receiving server for this format is also sometimes referred to as a FWLog Receiver. The ILA server component of the separate Clavister InControl™ management product is such a logger and this is the primary usage of the FWlog format.

Configuring the log receiver can be done in InControl or it could be done through the Web Interface or CLI.

Device:/> add LogReceiver LogReceiverFWLog my_fwlog
			IPAddress=192.168.4.1
			Port=999
			LogSeverity=Emergency,Alert

For each log receiver it is possible to impose rules on what log message categories and severities are sent to that receiver. It is also possible to lower or raise the severity of specific events.

The Severity Filter

Log Message Exceptions

The SNMP protocol

SNMP Traps in cOS Core

The file CLAVISTER-TRAP.mib defines the SNMP objects and data types that are used to describe an SNMP Trap received from cOS Core.

This file is contained within cOS Core itself and can be extracted to a management computer's local disk either using the Web Interface or Secure Copy (SCP). Doing this is described further in Section 2.5, SNMP.

There is one generic trap object called OSGenericTrap, that is used for all traps. This object includes the following parameters:

This information can be cross-referenced to the separate Log Reference Guide using the ID.

Using SNMP2c or SNMPv3

Configuring Event Receivers

Repeat Count

If, for example, the Repeat Count property is set to 3 then a particular event will be sent only for the first three times that it occurs since the last system startup (a system restart will initialize the count). This can prevent a constantly repeating event sending an unnecessary quantity of the same message to the receiver.

Interface Up/Down Events

SNMPv3 Security Options

Device:/> add LogReceiver EventReceiverSNMPv3 my_snmp_receiver
			IPAddress=192.168.3.1
			Username=my_name
			Password=myunguessablepassword
			Snmp3SecurityLevel=authPriv
			LogSeverity=Emergency,Alert

The following advanced settings for cOS Core event logging are available to the administrator:

Send Limit

The administrator must make a case by case judgment about the message load that log servers can deal with. This can often depend on the server hardware platform being used and if the resources of the platform are being shared with other tasks.

The Send Limit setting is global but affects each log receiver individually.

	Note: The send limit is not shared between log receivers
	If multiple log receivers are configured, the send limit is calculated for each log receiver before any log events are sent to the log receivers. As an example: If two log receivers are configured and the limit is 2000, it means that 2000 log messages can be sent to each log receiver.

If the send limit is reached, a log message about throttling will be generated describing how many log messages that were lost. Example:

03200400;;Warning;SYSTEM;log_messages_lost_due_to_throttling;
249 messages lost due to throttling

Default: 2000

Alarm Repeat Interval

Minimum 0, Maximum 10,000.

Default: 60 (one minute)

Most cOS Core status and operational statistics are available to InControl for graphical display in a variety of display formats. This is achieved by InControl routinely polling cOS Core to gather the latest values of operational parameters. Note that the values from some subsystems, such as Web Content Filtering, are not available to InControl.

The following counters are available:

Throughput Statistics

CPU – The percentage load on the firewall CPU.

Forwarded bps - The number of bits forwarded through the firewall per second.

Forwarded pps - The number of packets forwarded through the firewall per second.

Buf use – Percentage of firewall packet buffers used.

Conns – The number of connections opened via Allow or NAT rules. No connections are opened for traffic allowed via FwdFast rules; such traffic is not included in this statistic.

Timers – The amount of timers used by the system.

Total mem usage – Percentage of the RAM memory that is currently being used.

Connection Rate Statistics

Conns opened per sec – The number of connections opened per second.

Conns closed per sec – The number of connections closed per second.

State Engine Statistics

ICMP Connections - Total number of ICMP connections.

UDP Connections - Total Number of UDP connections.

OPEN TCP - Total number of open TCP connections.

TCP SYN - Total number of TCP connections in the SYN phase.

TCP FIN - Total number of TCP connections in the FIN phase.

Other - Total number of other connection types such as IPsec.

TCP Buffer Statistics

Total small receive window usage - The number of small TCP receive windows currently being used.

Total large receive window usage - The number of large TCP receive windows currently being used.

Total small send window usage - The number of small TCP send windows currently being used.

Total large send window usage - The number of large TCP send windows currently being used.

Rule Usage Statistics

Each of the rules in a rule set has a counter associated with it which has the same name as the rule type. These counters indicate the number of matches that have taken place for each rule. The rule sets that exist are:

Interface/VLAN/VPN Statistics

Rx/Tx Ring counters - Some drivers support plotting of FIFO-errors, saturation, flooding and other values depending on the driver.

Pps counters – The number of packets received, sent and summed together.

Bbs – The number of bits received, sent and summed together.

Drops – The number of packets received by this interface that were dropped due to rule set decisions or failed packet consistency checks.

IP errors – The number of packets received by this interface that were mutilated so badly that they would have had difficulty passing through a router to reach the Clavister firewall. They are therefore unlikely to be the result of an attack.

Send Fails – The number of packets that could not be sent, either due to internal resource starvation caused by heavy loading or hardware problems or congested half-duplex connections.

Frags received – The number of IP packet fragments received by this interface.

Frag reass – The number of complete packets successfully reassembled from the fragments received.

Frag reass fail – The number of packets that could not be reassembled, either due to resource starvation, illegal fragmentation, or just packet loss.

Active SAs - Current active number of SAs in use (VPN only).