InControl 3.17.02 Administration Guide

	Note: This document is also available in other formats
	A PDF version of this document along with all current and older documentation in PDF format can be found at https://my.clavister.com. It is also available in a framed HTML version.

Introduction

The Client/Server Architecture

The server acts as a central repository for all cOS Core configuration data and mediates all management communication between the InControl client and devices under InControl control. The diagram above illustrates a possible deployment of InControl with its components distributed across separate computers connected by the Internet. The optional Clavister InControl Logging Agent (ILA) component is a cOS Core log server provided with InControl. All InControl components could reside on the same computer.

Compatible cOS Core Versions

An error message will appear when trying to add a firewall if it is running a version of cOS Core that cannot be managed by InControl.

Management Tasks Performed through InControl

Uploading Multiple Configurations

Comparison with the Web Interface

The most important difference with the Web Interface is that a single Web Interface browser window can be used to manage one firewall at a time. The Web Interface does not therefore provide the ability to share configuration objects between firewalls and define objects that are common to a number of firewalls.

Various other features are also not provided by the Web Interface and include InControl's version control.

Restricting Management Privileges

Other types of user accounts can be created that have varying degrees of lesser access privileges. A new client account may be defined, for example, that is allowed to only perform real-time monitoring tasks. This topic is discussed further in Chapter 20, User Accounts and Groups.

The InControl SDK

This manual does not discuss the SDK further. More information on this topic can be found at http://www.clavister.com and in the separate InControl SDK Guide PDF document. The InControl API is based on the Windows Communication Foundation (WCF) interface which allows code development to be done using any one of a number of programming languages and platforms.

Other InControl Documentation

https://kb.clavister.com

References to specific articles in the Knowledge Base along with a link to those articles can be found throughout this administration guide.

This section describes the installation of the InControl server, client and ILA. Further details about ILA installation, particularly on a separate computer, can be found in Section 23.2, The ILA.

Hardware and Software Resource Requirements

The InControl Installation Executable

The InControl installer for versions 3.00 and later consists of a single Windows executable file with the following filename format:

		clavister-incontrol-<version>-setup.exe

The Installer Assumes Internet Access is Available

https://kb.clavister.com/343412798

Notes About Running the Installer

The Installer Visual Interface

The installer offers the choice of installing any combination of the client, server and ILA components. For a first-time installation it is recommended that at least the InControl server and the InControl client are installed on the same computer. This means that the client can be opened immediately after installation and will have local access to the server.

The columns on the left show what previous installations, if any, have been detected by the installer. Pressing the Install button for a component will select that component for installation and also provide the opportunity to change the default installation paths. An example for the server is shown below.

The Install button will be disabled if the installer cannot upgrade a previously installed component. Note that each component provides the choice between Install, Uninstall and No Change. The default is No Change so another button must be pressed for a component if any action is to be taken.

Once the installer actions for all components have been selected, the administrator can then press the Apply button at the bottom of the dialog and agree to the license conditions. This will launch the selected actions with separate progress bars showing the state of execution. Note that the second bar (labeled InControl followed by the version number) shows progress for installation of the installer itself (so it can opened later to make changes).

After completion, press the Done button to close the installer.

Uninstalling and Running the Installer Later

Starting the installer later can be done by opening the Windows Apps & Features list, finding the InControl entry and pressing the Modify button. An example of this is shown below.

An alternative way to do this is by opening the Windows Control Panel and selecting Programs & Features.

However, new InControl versions cannot be installed using the current installer and a new .exe file will have to be downloaded and executed for upgrades.

Enhancing Security with a New Local User for Running Services

To enhance the security of the InControl services, it is strongly recommended to create a new, local user account and then log into this account to perform installation of InControl components. Such user accounts are sometimes referred to as Service Accounts. These keep critical services completely separate from normal user accounts.

	Important: Use the same local user for ILA services
	When the two ILA services (logging agent and log receiver) are running on the same computer, they must both be installed using the same local user. However, in the case of multiple ILA instances, each pair of ILA services for each instance can run under different user accounts.

Once server installation is complete, the Windows service ICS.exe should then be set up in Windows to run under the new, local account (select the Log On tab in the properties of the service and specify the account).

To additionally enhance security, InControl server database file access should be restricted to this account only.

Client Installation and Remote Updating on a Separate Computer

From InControl version 3.00 onwards, it is possible to update an existing client installation remotely from the InControl server over a network connection. When the client starts, it automatically queries the server if there is a newer version of the client software available. If there is because the server has been updated but not the client, the newer version can be automatically downloaded from the server and installed. This means that a InControl update needs only a single central installation and then remote clients can be easily updated. However, this remote updating feature is not possible with versions of the InControl client prior to 3.00.

Importantly, it should be noted that InControl versions after 3.03.01 use a different and improved method for communication between the client and server. This means that a client with a version number of 3.03.01 or earlier cannot be updated remotely from a server with a version above 3.03.01. Such a client will have to be initially upgraded locally to a version above 3.03.01, but remote upgrading from the server will then be possible again after that.

Installing MSI Files

Windows Services

	Important: Restrict access to the server hardware
	Access to the InControl server management interface is not protected by any security mechanisms. Physical access to the computer on which the server is running also means possible access to the server interface. It is therefore important to restrict access to this computer.

Solving Service Start Timeout Problems

https://kb.clavister.com/354851828

Locations of Log Files

https://kb.clavister.com/354850220

When new releases of InControl are made available, these can be downloaded by logging in as a customer to http://www.clavister.com and selecting the relevant download. InControl updates are packaged as a set of four Windows executable .exe files which run an installation wizard. There is one installation executable file each for the client, server and ILA components plus a fourth file called clavister-incontrol-n-nn-nn-bundle-setup.exe which allows all components to be upgraded together (where n-nn-nn is the InControl version number).

	Important: Upgrade all InControl components together
	Although InControl releases include separate installation executables for the upgrade of the client, server and ILA, they should be viewed as a single upgrade. One component should not be upgraded without the others since dependencies may exist. For this reason, it is recommended to run the bundle-setup.exe file.

Uninstallation of existing versions is not required and the order of installation is not important. However, upgrading from version 1.10 has special requirements which are described later in this section.

Before installing, both the client and server management interfaces should be closed. The server installation will automatically stop the relevant services and then restart them.

The InControl server database is not normally affected by upgrading. Even a complete uninstall of the server will leave the database intact and remaining files must be deleted from the installation directory manually to completely remove the database.

Creating a Database Backup

		%appdata%\Clavister\InControl\Server\

A backup file created by the installer can be restored by using the Database > Load menu option in the InControl Server Settings management interface. This will automatically stop and restart the InControl services.

The server settings interface and saving or restoring the InControl database is discussed further in Chapter 4, Server Management.

Upgrading from InControl 1.10

Important: Back up the old LQS files

Uninstallation of 1.10 will preserve most of the old server database (including the audit logs) as well as the LQS log database files. These can then be manually transferred into the new InControl version's file structure as described below. However, the LQS configuration file lqs.xml is deleted during LQS uninstallation and a copy will be needed if the new ILA configuration is to replicate the old LQS configuration. This file is found in the Clavister\InControl\LQS folder.

For the filepaths used in the description below, the Windows variable %programfiles% is assumed to be the root path for the old InControl version installation. The variable %appdata% is assumed to be the root path for the new installation and this usually defaults to be the current user's application data folder. Both roots may have been changed when LQS was installed.

A. Moving server files

The InControl server installer provides the option to specify the location of the new InControl server database. The location chosen can be the same as the old installation directory.

If it is the same, the installer will not overwrite the old database and it will therefore become the database for the new version.

B. Moving LQS log files

The InControl server management interface provides a number of options for management of the server. These are discussed in this chapter.

Displaying the Server Management Interface

The InControl server runs as a Windows service and appears in the Windows process list as ICS.exe. It will be started automatically after initial installation and after hardware restart and will only be stopped by choosing the File > Service > Stop menu option in the server management interface (or alternatively, stopping it through the Windows process manager).

	Note: Log into the account under which the server runs
	To access the server interface, it is necessary to login as the user under which the server runs. If, as recommended, a local account has been created for this purpose then it is this account that must be logged into.

Stopping and Pausing the Server

The server may also be paused with the Pause/Resume menu option. This option translates directly into a Windows service pause. In this state, no updates are performed on the database and it is therefore useful if a backup of the database is to be done using a normal Windows utility instead of through the server management interface. The same menu option can then be selected to resume the server after a pause.

During a database backup initiated through the server management interface (described further below) the server process is automatically paused.

	Warning: Logout all clients before stopping the server
	No clients should be performing any configuration changes or related activities during an operation that stops the InControl server such as: Manually stopping the server. A server database backup or restore operation. A server software upgrade. One of the effects of a client working on a checked-out configuration when the server is stopped is that all changes will be lost.

Setting the Audit Level

It is important to remember that the server log messages being discussed here are totally separate from the log messages generated by cOS Core and relate only to server activity, not the activity of connected firewalls.

The server audit files can be viewed with a text editor but should not be edited in any way. Their format needs to be preserved, otherwise they cannot be viewed through the InControl client.

Configuring a Syslog Server

The Server Interface Console

Applying and Saving Server Changes

These options function as follows:

The configuration file for the server is called ICS.exe.config in the server installation directory and this is where server parameter values are stored.

Once any unsaved change is made to the server configuration, this is indicated by an asterisk ("*") appearing to the right of the management interface window title as shown below.

Server Database Backups

Backing up does not require that InControl client activity stops. The server will, however, delay client responses until the backup process is complete. This means that client users may experience a slight delay after sending a request to the server during backup.

The following methods can be used for performing a backup:

The above options will now be discussed in detail.

1. Backup initiated through the server management interface

In the server management interface, select the menu option Database > Save.

By default, backups are stored in a single file of filetype .ics with a filename that shows the date and time when the backup was created. For example, db2015-02-26_153521.ics might be the default filename created by the interface, where the filename format is:

			dbyyyy-mm-dd_hhmmss.ics

The above file naming convention is, however, not mandatory and can be changed in the file chooser but is recommended as a useful way to keep track of when backup files were created. When a command line is used (as described below) this file naming convention is always used and cannot be changed.

When a backup or restore is performed via the server settings management interface, the InControl server will be automatically stopped and restarted

2. Backup initiated through the command line

It is possible to also create backup files through a Windows console command. The command takes the form:

> Server Settings.exe -backup <directory>

If the database backup is being saved to a directory called backup_1 then the command would be:

> Server Settings.exe -backup backup_1

The command should be issued when the current console directory is the InControl server installation directory. The backup filename used has the default naming format described above and cannot be changed before performing the backup.

When using the Server Settings command to perform a backup or restore, the InControl server will be automatically stopped and restarted.

3. Using a script to schedule automatic backups

A key advantage of backing up using a console command is the ability to use Windows to create a scheduled service that will automatically run a script file containing the command on a regular basis. Creating such a script as well as an example script template can be found in a Clavister knowledge base article at the following link:

https://kb.clavister.com/324735442

Restoring the Database

> Server Settings.exe -restore <path>

When a database restore is complete, the InControl server will restart automatically and any connected clients will be automatically updated to reflect the configuration data in the new version of the database. Database updates or deployments initiated by clients during the restore process will be rejected by the server.

	Note: Backup files are automatically compressed
	When using the InControl server settings interface or command to create a database backup file, the file is automatically compressed using GZIP to conserve disk space. Decompression is automatic when a backup is restored in the same way.

Moving the Server Between Computers

Disk Space Management

These settings are used as follows:

	Caution: The VacuumDatabase option may consume resources
	The VacuumDatabase option may require significant amounts of processing resources to complete, depending on database size. It should therefore be enabled with caution since the server may become unresponsive during a database rebuild.

The SQLite setting will be used for a future feature and should not be changed. This setting is totally separate from the database settings for the ILA server.

Installing a Custom Certificate for Client/Server Communication

If the administrator would like to use their own certificate, this can be done by installing it into the "Personal" certificate store for the user that runs the InControl server ("System account"). This must be followed by changing the certificate thumbprint in InControl server settings to match the thumbprint of the certificate to use. The detailed steps are as follows:

Before a NetWall firewall can be brought under InControl control, a Remote Management object that allows that control usually must be created in the firewall's cOS Core configuration. This chapter describes how that object is created and configured.

	Note: Skip this chapter if using the zero touch feature
	If adding a NetWall firewall automatically to InControl using the zero touch feature, no cOS Core preparation is necessary except for making sure that the cOS Core version is no earlier than 12.00.16 and has a default configuration. This chapter can therefore be skipped. Using zero touch is fully described in Chapter 8, Zero Touch.

Creating a Remote Management Object

This will open up the properties display for the new InControl Management object. This is shown below with some example values already entered.

The configured properties are the following:

The Device Initiated Netcon Option

The additional properties for device initiated Netcon are the following:

	Important: HA cluster devices must have unique IDs
	When setting up a high availability cluster, each device (the master and the slave) must have a unique value for the Remote Management ID property. If this is not true then device initiated NetCon will fail for the cluster.

When to Use Device Initiated Netcon

	Note: The InControl server IP type does not matter
	With the above method of adding a firewall through the InControl client, it does not matter if the InControl server has a public IP address or is behind a NATing device with a private IP. However, the IP address of the firewall should be static. Any changes to the firewall's IP address must also be made to the firewall's properties in InControl.

Steps for Setting Up Device Initiated Netcon

Once the firewall is added using device initiated Netcon, it can be managed just like a firewall that is added to InControl in the normal way.

Device Initiated Netcon of HA Clusters Using a Single Public IP

https://kb.clavister.com/324736183

The next task after installation of InControl is usually adding on or more NetWall devices (either physical or virtual) so that they come under InControl management. This can be done in one of two ways:

Manually adding a firewall consists of the following key steps:

To add a firewall to InControl using the InControl client, press the Firewalls button in the main ribbon toolbar.

This opens the Firewalls tab in the client's central panel.

Before any firewalls are added, the tab contains only the Global Domain which is the parent for all sub-domains or devices. The Global Domain has its own set of configuration values which can be applied to all of its children.

	Tip: Only add to the Global Domain when necessary
	For the fastest InControl response times, only keep objects in the Global Domain when necessary. If an object is only used in one firewall, keep the object just in that firewall's configuration.

Above the tab, is a new toolbar for firewall specific operations. Press the plus button followed by selecting the Firewall option in the menu to add the new device.

Alternatively, this step could be done by right-clicking the Global domain node in the Firewalls tab and choosing Firewall from the Create menu.

The New Firewall dialog will now appear and the properties of the firewall can be entered. In this example, the new device will be called My_FW.

The name, IP address and secret key of the device is entered along with a comment. The new device doesn't need to be online at this point but it is more straightforward if it is so that any failure to connect can be seen immediately. Note that the name of the device can only be changed later using the CLI console command set Device Name=. InControl will then automatically update its interface.

The default parent for a new device is the Global Domain but it could be any subdomain that has been previously defined.

	Tip
	To move between sections of the IP address field, use the right and left arrow keys.

By clicking the icon next to the IP address field, it is possible to instead enter a URL for the firewall.

If the firewall is being added using Device Initiated Netcon (the firewall initiates the addition) then the Firewall Initiated option (shown below) should be selected and the Remote Management ID that is specified in the corresponding Remote Management object in cOS Core should be used instead of the IP address. This is discussed further in the previous Chapter 6, Preparing cOS Core.

The Secret Key is the hexadecimal Netcon key required by cOS Core for communication with InControl (Netcon is a secured Clavister proprietary protocol). This key must be the same value as the Passphrase property of the Pre-Shared Key object in cOS Core which is used with the Remote Management object that allows InControl control. Obtaining this key is explained further in Appendix B, Netcon Key Generation.

When the key is obtained, it should be copied to the Windows system clipboard and then pasted into the secret key field of the new firewall dialog.

After completing the dialog and adding the new device, it will appear in the Firewalls tab under its parent domain. The global domain will be the parent if no other domain is specified in the new firewall dialog.

Note that if a new device is added and it does not have a valid license, this will be indicated by an alarm appearing.

How Device Naming Works with InControl

However, if after adding a firewall to InControl, the device name is later changed directly on the firewall (outside of InControl) then this new name will overwrite the name in the InControl database.

Potential InControl and cOS Core Version Mismatches are Flagged

Binding a License

Editing the Configuration

The tab title text in the example above is My_FW - Revision 30:5. The numbers "30:5" represent the number of times this firewall's configuration has been edited via InControl and non-InControl means. The number to the left of the colon is the number of times the configuration has been edited by non-InControl means. The number on the right is the number of times it has been edited using InControl.

The navigation tree to the left of the tab shows the object hierarchy of the configuration. This will be structured differently between a cOS Core version and an earlier CorePlus version.

	Note: InControl must parse a configuration on initial opens
	The very first time an added firewall's configuration is opened and read by InControl, there will be a brief delay while the configuration is parsed and loaded into the server database. The delay will depend on the processor speed of the InControl server. Subsequent opens will not have this delay.

Key Aspects of Configurations

All of the above features are fully described further in the cOS Core Administrators Guide. An example of editing a configuration is described later in Chapter 10, Editing Configurations.

Deleting Devices

A confirmation dialog is displayed before the delete is finalized.

It is important to be certain about wanting to delete the firewall since there is no undelete following confirmation.

Switching from Online to Offline

Switching Back to Online from Offline

Overview

Benefits of Using Zero Touch

It should be noted that the zero touch feature is not supported on virtual cOS Core firewalls. It is also only supported on certain Clavister hardware models and these are discussed next.

Supported Clavister Hardware Models

Note also that a version of cOS Core that supports the zero touch feature (12.00.16 or later) must be installed on the hardware and the device must have its default cOS Core configuration. All the prerequisites for the feature will now be discussed in detail.

Setup Prerequisites for Zero Touch

Caution: A full hardware reset will undo version upgrades

A full hardware reset to the factory defaults will undo any cOS Core version upgrades and this option should therefore not be chosen. Resetting to the default cOS Core configuration is all that is required after upgrading. However, any existing configuration will be lost after this reset. Note also that saving any local configuration changes after a configuration reset will disable the zero touch feature in the hardware since cOS Core will no longer have its default configuration.

The sections that follow will describe in detail how to set up the zero touch feature.

Initial Setup Steps in MyClavister for Zero Touch

Adding a New Device Using Zero Touch

Replacing Existing Device Hardware Using Zero Touch

The setup steps for replacement are almost identical to the procedure for adding a new device, which is described above. However, there are some small differences. The MyClavister setup is first performed in the same way when adding a new device or replacing an old one. Most importantly, the license for the replacement hardware should have the zero touch option enabled.

Note that if a device is being replaced with dissimilar hardware (where the Ethernet interface names and/or number are different) then a new and modified firewall configuration must be created in InControl based on the old configuration. Performing this additional step is described in Chapter 28, Dissimilar Hardware Replacement.

Below is the complete list of InControl steps for zero touch device replacement. Screenshots have been left out because they are mostly identical to those used previously in the description for device addition.

Using the Unbind Option

Using the Deploy Option

Indicators in the Firewalls Tab

When the actual hardware becomes accessible and the zero touch operation can commence, a progress bar will appear next to the shadow appliance to indicate progress, as shown below.

After the zero touch operation completes, the zero touch indicator in the Status column will disappear. If the zero touch operation could not complete because of an error, a red triangle will appear next to the shadow appliance, as shown below. Performing a mouse over of the device will show more information in the tooltip that appears.

Note that the red triangle may also appear momentarily between state transitions during the execution of a zero touch addition or replacement. This is normal behavior and does not indicate an error.

Demo Mode and Lockdown Mode Have No Effect

Demo mode and lockdown mode are described further in the separate cOS Core Administration Guide.

Local Console Messages Generated by cOS Core

The initial zero touch related message on the console will be the following:

 Generating a Zero Touch ID

This will be followed by:

 Generating a Netcon PSK

And the final message that indicates that an attempt is being made to contact the InControl server:

 New Reverse Netcon connection

How Zero Touch Functions

Revision Management is the ability to save and track changes made to cOS Core configurations and is an important tool for managing firewalls. Revision management allows the administrator to keep track of what was changed in configurations, when it was changed, who made the changes and provides the ability to roll back to older configuration versions. These features are also sometimes referred to as configuration version control.

Two key features of revision management with InControl are:

Check Out and Check In

A configuration in the InControl database can be either "checked in" or "checked out". The default is "checked in" and an administrator accessing a configuration in this mode will find that it is read-only and no modifications can be made. Several administrators may access the same "checked in" configuration simultaneously in read-only mode from different clients.

	Note: InControl and Web Interface version control are separate
	If version control is performed through InControl, the Web Interface should not be used to upload previously backed up configuration versions. Web Interface backups are independent of InControl. Once InControl version control is adopted, version control through the Web Interface should not be used.

Checking Out a Configuration

Checking out can be done separately by pressing the check out button in either the Firewalls tab toolbar or the toolbar for the individual firewall's tab.

	Tip: A keyboard shortcut exists for check in/out
	A range of InControl operations can be executed with a keyboard shortcut. For both check out and check in, the shortcut is Ctrl+Shift+C after selecting the target in the Firewalls tab. All available shortcuts are listed in Appendix D, Keyboard Shortcuts.

The administrator who performs the checking out, now gets exclusive write access to the configuration. As long as the configuration remains checked out, all attempts to check out the configuration by other management clients will fail. This prevents two InControl clients editing the same configuration simultaneously.

In a multi-administrator environment with multiple InControl clients, the best practice is to try and ensure a configuration is not left checked out for any longer than is absolutely necessary.

Already Checked Out Devices

Since the checking out of a firewall is an exclusive operation, it cannot be done on an already checked out device and this option will be disabled in the InControl client interface.

Alarms

Open the Alarms tab to investigate this further. In the above example, the status of the firewall is Unreachable which may be the cause for the alarm. This topic is discussed further in Chapter 14, Alarms.

Automatic Check Out

Checking In a Configuration

If a firewall's configuration has been changed, this is shown by an asterisk appearing next to the firewall's name in the Firewalls tab.

Check in can be done by pressing the Check In button for the firewall.

A dialog appears to confirm and complete the check in. It is recommended that the administrator add a comment for each check in. This provides an easy way to identify changes in the revision history.

This dialog also provides the option to automatically deploy the configuration at the same time that the check in occurs. This option is disabled by default but enabled in the example above.

Deploying Changes

Using deploy will cause all configuration changes since check out to be deployed to the relevant firewalls. The progress of the actual upload of configurations to the hardware units is indicated by progress bars that appear in a bottom panel in the client interface.

Like many other options, a deploy can also be initiated by right-clicking the firewall in the Firewalls tab and selecting the option in the context menu.

If the InControl client is closed before configuration changes are deployed, those changes are still saved between client sessions. When that same InControl client is started up, undeployed changes will still be visible in the client's view of the configuration.

Exiting the Client with Checked-out Configuration

If the client does exit with a checked-out configuration then after opening the client again with that same username, the checked-out state will remain along with any uncommitted changes. However, if the InControl server is restarted, all check-outs and any pending changes are lost.

Clients Can Cancel an Existing Checkout

However, it is not possible to use this function to undo a checkout performed by another username. Only an InControl server restart will undo all checkouts.

Checking for Deployment Problems

However, some configuration problems are not so serious that they prevent deployment but still result in a warning message. These warnings are also shown in the Deployment Log Dialog but this time it is not shown automatically. Instead, the log can be viewed at any time after deployment by pressing the Deploy Log button in the toolbar.

This option can also be selected through the context menu for a firewall in the Firewalls tab.

An example of the Deployment Log Dialog is shown below. This shows warning messages relating to issues with the IPsec tunnels MyTunnel and MyTunnelTwo.

If a deployment has any errors or warnings, a single alarm will be generated and this will appear in the Alarms tab. The deployment log can also be viewed by right-clicking this alarm and selecting the View Deployment Log option.

Deployment logs are always fetched directly from a firewall so the deployment may have been initiated from the Web Interface or CLI. Also, the log only relates to the last deployment made for a firewall.

Deploying Multiple Configurations

This will display a dialog that lists the changed configurations that are yet to be deployed so that individual entries in the list can be selected for deployment. By default, all the changed firewalls are selected in the displayed list.

Undoing Check Out

The following dialog is displayed if this option is chosen:

Forcing Undo Check Out

Checking In Domains Changes

When a domain is checked in and one or more firewall configurations inherit changed objects from the domain, an alarm is raised for the affected firewalls. These firewalls then need to have their configurations manually deployed to have the domain changes take effect (deployment does not need a firewall to be also checked out).

If a firewall that inherits changes is checked out then such a deployment cannot take place. In this case, any inherited changes will be queued on the InControl server. The next time the firewall has its configuration deployed following check-in, the queued changes are applied.

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. Both numbers will start at 1. The most recent configuration version is therefore associated with the highest version number from either number.

Whenever a firewall configuration is changed through a non-InControl interface, any connected InControl server will be automatically notified that there is a configuration change and what the new version number is. All clients connected to the server will then be informed of this change.

Concurrent Changes Made Outside InControl

By using the CLI or Web Interface, another user could change the configuration outside the direct supervision of InControl. However, when such configuration changes are made, the InControl server will detect them and any InControl client that has checked out that configuration will present a warning message to tell the user that something has changed. The message gives the user the option to update their view of the configuration and this is the recommended action.

However, it is strongly recommended when using InControl that all configuration changes are made through the InControl client and using the Web Interface or CLI is avoided. This will also mean that the InControl audit log correctly reflect all configuration changes made.

Revision History

Selecting this brings up the Revision History tab which lists all the configuration changes made.

By selecting a particular revision, a summary of that revision can be displayed at the bottom of the Revision History tab.

The button Check Out and Open allows any revision in the history to be opened. It can then be viewed, even changed and then it can be deployed to the firewall. If it is deployed, it becomes the current configuration and moves to the top of the list in the Revision History tab.

By selecting the Difference tab, the difference between the selected configuration and its predecessor can be seen.

Additions and deletions are marked as such. A change appears in blue and the old and revised values are shown in their respective columns. Expanding the node at the left can reveal more details about the change.

By holding the Ctrl key down, multiple, possibly non-sequential revisions can be selected in the Revision History tab and the differences between them is displayed in multiple columns in the Difference tab. In the example below, three revisions have been selected for comparison.

The Statistics tab provides the ability to see graphical representations of revision changes by date or by user. An example of a typical bar chart presentation is shown below.

Revision History Node ID Changes for HA Clusters

The value of the Node ID reflects which unit in the cluster was changed first. Zero indicates the master and one indicates the slave. If all changes are performed under the control of InControl, the Node ID will remain constant.

However, if changes are made outside of InControl then the Node ID can change in the revision history. Such changes might be made with the Web Interface or the CLI but may also come from cOS Core version changes performed outside of InControl.

This chapter will look at editing the configurations of firewalls under InControl control. The example of creating a new IP rule set entry will be used to illustrate the steps involved. The rule set entry will be an IP Policy that allows the firewall to respond to incoming ICMP Ping requests.

"Pinging" a firewall from any computer is a quick and simple way to check if the firewall is up and running. When cOS Core starts for the first time only a predefined IP rule set called main will exist and it will not contain an entry that allows ICMP Pings so they will be dropped.

IP Policy Setup Example Assumptions

	Note
	You will have to substitute the information above with the actual interface name and IP addresses of a specific installation.

When InControl is started, the firewall My_FW will appear in the Firewalls tab.

All ICMP Traffic is Initially Dropped

To do this, open a standard Windows command console on the management computer and leave InControl running. At the command prompt, given the assumptions explained above, type:

> ping 192.168.101.240

The command should return output similar to that shown below.

The above output shows that cOS Core is ignoring the ICMP protocol packets, and the Ping command returns the Request timed out message.

Adding an IP Policy

The audit log shows that the two operations of check in and deploy have taken place.

Alternatives for Deploying Configuration Changes

Configuration Errors and Warnings

The issues can be one of the following types:

Clicking either Errors or Warnings will expand the pane to provide a more detailed explanation of the issues. Shown below is an example of this after Errors has been clicked. Here, a value has not been specified for an address object.

Verifying that Ping Works

> ping 192.168.101.240

If the Ping command returns a Request timed out message, the InControl connection to the firewall did not succeed. Refer to Chapter 27, Troubleshooting Connections for possible reasons.

Editing an Existing Object

The drawback to in-cell editing is that not all object properties are displayed and only the displayed ones can be changed with this method.

Using Objects Inherited From InControl Domains

Favorites Buttons

This section deals with the options found in the Device Maintenance submenu that is accessed by right-clicking a firewall in the Firewalls tab.

The Upload Firmware Option

Creating Firewall Backups with the Create Backup Option

This creates a backup of either the configuration or the entire system including the current cOS Core version plus the configuration. The backup is saved to a new, separate file on local disk.

The InControl database is not used for the creation of the backup. Instead, the backup file data comes directly from the firewall itself. This means that the process is exactly equivalent to creating a backup through the Web Interface.

Creating Firewall Backups from the InControl Database

The Set Console Password Option

The only other way of changing the serial console password is in the boot menu which can be entered from the serial console during startup. The InControl option offers a way to change the password without disruption to traffic.

If the serial console password had never been set previously, this option will set it for the first time.

The Changing Management Keys Option

The keys are used to ensure secure communication between InControl and the firewall. They should be changed if it is felt the existing key could have been compromised.

The Deployment Log Option

Depending on the hardware platform, the additional statistic localcfgver may be shown. This is the number of times the configuration has been changed outside of InControl.

The Technical Support Option

The file is created as a text file on local disk so that it can be easily mailed to support personnel. The file name has a default format, for example techsupport-20111201.txt and it is recommended to retain this.

Using this option is equivalent to the CLI command:

Device:/> techsupport

The System Error Reports Option

When the option is selected, a dialog is presented which lists the available crash dump files (always with the filetype of .dmp). The desired files can be selected and then downloaded to the client computer by pressing the Download button.

The Restart Device Option

With the default value of 5 seconds, this is equivalent to the CLI command:

Device:/> shutdown 5

This executes the shutdown of cOS Core after a waiting period of 5 seconds. The shutdown will reload cOS Core and then the current configuration but not reload the firmware loader. All connections and VPN tunnels will be closed gracefully.

The License Option

This section explains how to use InControl to upgrade the version of cOS Core in the firewalls under its control. Device upgrades can be performed on one device at a time, or in a batch of multiple devices and the upgrades can be initiated immediately, at a scheduled time, or when required.

The steps to perform an upgrade on one or many devices at once are the following:

The Firmware Upgrade Jobs Tab

The Firmware Upgrade Jobs tab shows all the defined upgrade jobs that are waiting to be manually started, are currently in progress, are scheduled to be executed, or have already completed. Initially, the job list will be empty.

A new upgrade job can now be created by pressing the Create (plus) button in the toolbar ribbon, which is shown below.

This will open the New job dialog. Below is an example of the upper portion of the New job dialog with example values specified for the input fields.

Beginning with a suitable name for the job, the New job dialog shown above has the following additional components:

Selecting the Job Execution Time

The time when the job is run can be one of the following choices:

Note that any scheduled job that is waiting in the job list could be manually started at any time, before its scheduled start.

Matching .upg Files to Devices

Upgrading a Domain

If the domain does not have recursive permissions to upgrade all of its child devices, InControl will automatically uncheck the checked domain and instead check the individual devices within it that can be upgraded. The individual devices will not be grayed out so this individual device selection can be changed.

Upgrading HA Clusters

Running Upgrade Jobs

Note that the job list can also be viewed and managed using the Library Browser The list is found in the browser's Firmware Upgrade Jobs folder. The browser is discussed further in Chapter 24, The Library Browser.

If a job is of the Manually Triggered or Scheduled type then it can be run at any time by selecting it in the list and then pressing the Start button in the upgrade toolbar ribbon. If not manually started in this way, scheduled jobs will run automatically at their scheduled time.

A progress bar in each line in the job list indicates the job's progress. This progress bar summarizes the progress for all the upgrades performed by the job. An example of this is shown below.

The green portions of the progress bars indicate successful upgrades and the red portions failures. If an orange portion is seen, this indicates a successful upgrade but with warnings which can be examined in the Progress dialog (discussed below).

Even if the Firmware Upgrade tab is not visible, upgrade job progress will also be displayed by the InControl client in its progress pane at the bottom of the window. An example of this is shown below.

Note that the ordering with which individual devices within a running job are upgraded is random and is not determined by the ordering of devices in the New job dialog.

Viewing the Progress Dialog

Viewing the Upgrade Log After Completion

In addition to the Log part of the completed Progress dialog, the lower System state part of the dialog can be expanded to show the old and new states of the upgraded devices, including techsupport command output. An example portion of this system state information is shown below.

Availability of Devices During Upgrades

Canceling a Running Job

Upgrading Directly From the Firewalls Tab

This will open the Firmware Upgrade tab and then the New job dialog directly. The job name will be filled in automatically by InControl with the text string made up of the device name and time, as shown in the example below.

The Immediate option in the New job dialog will also be automatically selected so that when the dialog is closed, the Progress dialog will open straight away and the upgrade will commence. Any of these default New job options could be changed before closing the dialog.

However, it should be noted that it is not possible to directly select a domain and upgrade all the devices it contains in this way. Instead, an upgrade job must be created and then the domain is selected within the job.

Ignore the Local Changes Detected Alarm

		Local changes have been detected on device.

This alarm is also discussed in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/332441418

Overview

An Alarm's Components

Alarm Actions

The Alarm Indicator Icon

When any alarms are active, this icon changes as shown below:

In this example, the display indicates there are two active alarms for this InControl client.

The Alarms Tab

InControl will now display a summary of alarms for this client:

Further detail for each alarm is provided by selecting a particular alarm. The details displayed for the final alarm above is shown below.

Right-clicking an alarm will cause a context menu to appear from which a number of actions can be chosen:

Clearing Alarms

Many alarms will eventually be cleared by InControl itself. For example, if the alarm is caused by a failure to connect to an offline firewall, then when the firewall comes back online, InControl will clear the alarm itself.

After choosing the clear option, a dialog is shown so that a reason for clearing the alarm can be given and stored in the alarm history.

When an alarm is cleared, either by InControl itself or explicitly by the user, it is removed from the standard alarm list and stored in the Alarm History.

Acknowledging Alarms

The acknowledgement dialog includes two further options:

Acknowledged alarms are not stored in the Alarm History but will be stored by InControl until they are eventually cleared, even though they aren't displayed.

An acknowledged alarm must be cleared before it disappears into the alarm history and this can happen due to a clear being done by InControl. Alternatively, the user can clear the alarm explicitly by using the filtering option in the client to display find it and then applying a clear operation to it.

Alarm Uniqueness

The Alarm History

Changes made to firewall configurations, as well as a variety of other actions performed by InControl clients, are logged on the InControl server and are retained as an Audit Trail which consists of a database of Audit Log Messages.

The current audit trail is displayed by pressing the Audit button.

This opens the Audit Trail tab which displays a list of the current trail. An example list is shown below.

Each entry in the trail shows what action was performed by who, on what and if it succeeded. By default, the audit log shows only the entries for the last hour of client usage. This can be changed by using the filters in the toolbar.

Displaying Audit Details

Filtering Audit Log Messages

The filtering features of the Audit toolbar allow the display selection to be customized.

By default, the last hour of all audit logs are displayed. As shown above, different time intervals or a custom filter can be created.

A custom filter can involve choosing values for several parameters. A typical filter is shown below.

Domains Allow Configuration Object Sharing

Important: Try to keep the Global Domain small

Although it may seem convenient to keep as much as possible in the global domain, this is not recommended since InControl operations such as opening configurations and deployment can become much slower. The recommended approach is to only place objects in the Global Domain or sub-domains when they absolutely have to be there. If an object is only needed in one firewall then keep it as a locally defined object unique to that firewall's configuration.

Domains are Specific to InControl

However, it is still possible to switch to managing configurations using those other interfaces even though they were originally configured using domains.

Domains are Initially Empty

Adding Domains

This results in a dialog being displayed so that the name of the new domain can be entered and the parent of the domain selected.

The default parent for a new domain is the Global Domain as shown below.

However, it is then possible to create further sub-domain levels. The screenshot below shows a domain called My_Subdomain defined under My_Domain which is itself defined under the global domain.

Once defined, any new domain has a set of objects which are similar to the set found in the global domain. This object set then applies only to the devices defined within that domain and takes precedence over the same objects found at higher levels. Below is the object navigation tab for My_Subdomain.

	Tip: Configuration revision numbers
	The revision number for the above tab is 0:1. This means that these configuration objects have been edited once by InControl (the initial creation) and zero times by the Web Interface or by the CLI via SSH.

The domain arrangement means that:

Name Duplication

For example, a Service object called my_service in the global domain cannot coexist with another Service called my_service in a domain or device at a lower level.

Checking Domains Out and In

When a domain is checked out, only the domain itself is checked out Any subdomains or firewalls within that domain are not also automatically checked out.

When the domain is checked in, any changes made to objects in the domain that are used by devices under the domain are deployed by the InControl server. In other words, the configurations affected by changes in their parent domains are automatically updated.

Editing Domain Objects Directly or Indirectly

However, when editing a firewall configuration that contains objects inherited from a domain, it can be inconvenient to exit the firewall configuration just to open and edit the domain. In the firewall editing interface, InControl provides the ability to directly edit inherited objects without opening the parent domain. This is done by clicking the inherited object which will open a new pane to show its current value. Pressing the Edit button will allow these values to be changed. This is shown below for an inherited IP object which is being used in a firewall IP rule set.

Applying Domain Changes to Checked Out Devices

Resolving Object Collisions

Such collisions could occur because of a name change or new object creation in a firewall or a domain.

Note: Some upgrades require extra measures for collisions

In some cases of upgrading InControl, the object collision resolution mechanism described above will be unable to deal with certain collision problems where a domain object name is the same as the name on a firewall. This can occur specifically when the two colliding objects are at different hierarchy levels in the domain and firewall. For example, one object is in an address book folder in the domain but is at the top level of the address book on the firewall. A symptom of this is alert messages continue to appear, one alert for the collision in the domain and a separate alert for the collision in the firewall. In this case, the actions to take are as follows: Change the object name manually on the firewall. This will remove the collision alert for the firewall but not the alert for the domain. Edit the colliding domain object name but do not change it or enter OK. Instead, press the Cancel button to leave editing. This will remove the remaining alert for the domain.

Unlike firewalls, imported domains do not also require a cOS Core upgrade procedure to be applied as the second step. Domain objects can therefore be accessed and edited directly after the import. However, any objects from the domain that are used in an imported firewall get automatically duplicated in the child firewall configuration. After the firewall cOS Core version is upgraded but before it can be deployed, the Resolve Collision dialog described above will appear in order to choose which duplicate to keep.

Viewing Inherited Objects in Configurations

When enabled, the configuration display will include inherited objects. The screenshot below shows an example cOS Core address book on a given firewall where the inherited domain folder called MyDomainFolder is displayed along with the inherited objects that the folder contains (note that all inherited rows are in italics).

Like non-inherited objects, it is possible to open an edit pane for an inherited object, but this will provide a link to edit the parent domain instead of allowing the object to be changed directly.

Flagging Unused Domain Objects

One reason for this warning is the 8.nn import procedure mentioned above. After an 8.nn datasource is imported but before any devices in the datasource are upgraded, imported domain objects can be edited but they will not appear to be used yet in the child firewalls. The warning is a reminder of this.

This warning message can be disabled by clicking the checkbox in the message or clicking a checkbox in the Client Settings dialog (see Chapter 5, The Client Interface).

Domains and the Local Firewall Configurations

The CLI is only used to directly manipulate objects in a single configuration on a single firewall and therefore cannot be used to manipulate domains. In addition, if a domain object is not used by a particular firewall within that domain, then the object will not exist in the firewall's configuration and cannot be manipulated using the CLI.

Deleting Firewalls from a Domain

Deleting such read-only objects is discussed in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/336137021

It is possible to set up shared IP policies so that an IP rule set defined within an InControl domain can be shared across multiple firewalls within that domain. This means that any changes made to the shared rule set will be automatically reflected in all the firewalls that share it. This feature is also sometimes referred to as Shared IP Rule Sets.

A Summary of Setup Steps

A detailed example that shows how these steps are applied is given at the end of this chapter.

Specifying Interface Names in Shared IP Rule Sets

If a zone name is to be used, that zone must already be defined in the global domain or the subdomain and it must also be assigned to the relevant interface in the firewall configuration that will use the shared IP rule set. In summary, a zone is simply a logical name that can be assigned to any cOS Core interface so that it is possible to have a common designation for Ethernet interfaces with similar usage on dissimilar computing platforms.

For example, all the Ethernet interfaces on a set of dissimilar firewalls that are connected to the Internet might be assigned the zone called wan_zone. Using zones in cOS Core is described further in the Zones section of the separate cOS Core Administration Guide.

Shared IP Rule Set Processing

When shared IP rules sets are set up in this way, InControl keeps a master copy of the rule set in the global domain or a subdomain but it also loads a copy of the rule set into each firewall that shares it. This means that there is no need to go back to the InControl server to scan the shared rule set and so there is no performance penalty when using shared rule sets.

It also means that these shared rule sets are visible in the firewall configuration if they are examined locally, outside of InControl, and they will remain present if the firewall is removed from InControl management.

Notes About Usage

An Example of Setting Up Shared IP Policies

InControl can be used to quickly create a Software Defined Wide Area Network (SD-WAN). InControl SD-WANs consist of groups of firewalls connected by IPsec tunnels. These tunnels connect together networks which are attached to any of the firewalls in an SD-WAN grouping (in other words, LAN to LAN connections).

The basic architecture of InControl SD-WAN groupings is the hub and spoke pattern. This is where a single firewall (the hub) is connected to one or more other firewalls (the spokes). Networks on the spokes will then be able to securely communicate with other networks via the hub. These other networks might include the Internet, a network local to the hub, or a network local to another spoke.

The hub and spoke pattern is intended to reflect the common organizational structure where a hub is located at a central location, such as a head office, and spokes are located at multiple remote locations, such as branch offices. This network topology is illustrated in the diagram below.

	Note: At least cOS Core version 13.00.04 is required
	The firewalls involved in an SD-WAN group must all be running cOS Core version 13.00.04 or later. Having all of them running the same cOS Core version is recommended as well as all having the latest version.

A Summary of SD-WAN Setup Steps

The above steps are expanded in the detailed setup example given later in this section.

Notes About Using the SD-WAN Feature

A Detailed SD-WAN Setup Example

Editing an Existing SD-WAN

The SD-WAN configuration tool is accessed by right clicking the domain in which the SD-WAN resides and selecting the SD-WAN > Configure existing... menu option.

A dialog will be presented to choose the SD-WAN of interest, even if there is only one in the domain.

After choosing the domain, the SD-WAN editing dialog will open. This is the same dialog that was seen before when adding spokes to a new SD-WAN. In this case, the purpose will be to make further changes to the SD-WAN, such as adding more spokes or deleting existing spokes under the Existing Spokes tab.

The Delete SD-WAN tab provides a tool for deleting the entire SD-WAN from the domain. Both the options provided will delete the SD-WAN but only when the spokes are also deleted will the actual firewall configurations be changed. In other words, by not selecting the spokes it is possible to leave all the firewall level SD-WAN objects intact and just delete the SD-WAN object in InControl. However, this will mean that any further SD-WAN configuration will need to be done manually and the SD-WAN configuration tool can no longer be used.

As with creating an SD-WAN, all SD-WAN edits must also be manually deployed in InControl.

Creating Additional IP Rule Set Entries to Allow Specific Types of Traffic

The shared IP rule set associated with an SD-WAN can found in the configuration associated with the containing domain under the Additional IP Rule Sets folder, which is shown below.

An IP rule set created by the SD-WAN feature will have a name of the following form:

			SDN<number>Rules

This is the rule set to which all new entries, such as IP policies, should be added to control traffic flowing through the IPsec tunnels. This rule set is automatically populated by a number of entries which allow ICMP messages to flow between components in the SD-WAN. A typical set of these entries is shown below.

It is recommended to not change these default entries for ICMP traffic since ICMP messaging is needed for the SD-WAN to function correctly. Instead, new entries should be added.

It is recommended to use the automatically assigned zone names when referencing interfaces in new rule set entries. The zone objects that are automatically created by an SD-WAN are located in the configuration of the domain that contains the SD-WAN. The following zone to interface assignments are automatically made:

As an example, consider the requirement that all Internet traffic from the local networks on all spokes is to be allowed through the tunnels to the hub which is already set up with Internet access. Two rule set entries would be needed with the filters (the SD-WAN name of SDN001 is assumed).

Routing of Internet traffic from spokes is dealt with automatically provided that the All traffic option has been selected in the Routing from spokes option when setting up the SD-WAN.

Referencing the Hub's Local Network Interface

Referencing SD-WAN Networks

The folder contains address objects for referencing both hub networks and referencing spoke networks as well as referencing collections of these networks. An explanation of the address object's contents is automatically inserted into the Comments property of each object when they are added as part of SD-WAN creation. They can be used as needed by the administrator when new IP rules set entries are added.

Specifying Specific IPsec Tunnels in Rule Set Entries

Notice how they are similarly named except for the hub of spoke postfix. This indicates that they are opposite ends of the same tunnel.

Viewing Firewall Membership in SD-WANs

To answer this question quickly, open the Firewalls tab. The column with the title SD-WAN shows the SD-WAN membership for each firewall. An example of this from the Firewalls tab is shown below.

Where a firewall is a member of many SD-WANs so that the column cannot show all of them, mousing over the column entry will show a tooltip that displays all the parent SD-WANs in a tooltip. This column is automatically enabled but can be turned off or on using the tab's customization option. This customization is described further in Section 5.3, Using the Client.

An issue that can complicate administration of multiple firewalls is that different cOS Core versions offer different feature sets and, in some cases, different ways of configuring a cOS Core feature. In addition, cOS Core configuration object properties may get renamed in a new version. The InControl Domain Feature Levels can provide a solution to these issues.

The Domain Feature Levels option allows a cOS Core version level to be assigned to any InControl Domain (the default is the most recent cOS Core version). The domain then presents a view of its contained configuration objects that corresponds to the assigned version.

If different feature levels are used between domains, or between domains and the firewalls they contain, InControl will perform object conversion when needed.

In a scenario where there are various firewalls with different versions of cOS Core the best practice for using this feature is as follows:

For example, in a mixed environment with devices running 11.04 and 11.10, the global domain needs to be set to 11.04 and a subdomain should be set to 11.10 in order to contain the 11.10 devices. The global domain would not support any new 11.10 features. Those features would be configured within the 11.04 subdomain.

The recommended setup is that a subdomain and all its contained firewalls have matching feature levels and versions. When upgrading, it is recommended to first upgrade the actual device, then the device's feature level in InControl and lastly the feature level of the parent subdomain.

For forward planning, if firewalls with newer versions of cOS Core are to be added to InControl, it is advised to create a new subdomain for containing those firewalls. In this example, with a global domain feature level of 11.03, to add a firewall with cOS Core version 11.10, perform the following:

The result will be that the top-level global domain configuration will apply features from 11.03, then convert them across to the new 11.10 subdomain to agree with its feature level, along with all firewalls inside that subdomain.

A typical series of steps for implementing feature levels would be the following:

Supported cOS Core Versions

Some Objects Need to be Checked-In Manually

If the combinations shown below are involved in a conversion then a manual check-out and check-in must be performed on the domain or firewall if the parent domain has been upgraded or any configuration objects have been added, changed or deleted.

The cOS Core User Database

The InControl User Database

Even when opening a CLI console in the InControl client, access is controlled by this central database.

Listing Users

The Users tab will open to display a current user list.

Only a single user with the name admin and default password admin is predefined in InControl. This user belongs to the predefined User Group called Administrator whose members have full read and write permissions. Another user group called Auditor can contain new users that have read-only access. It is group membership which determines which permissions that a user has.

Creating New Users

This starts the New User wizard which begins by asking for a unique name, for example admin2, along with a password.

In the final wizard step, the user is assigned to a pre-existing Group. As mentioned previously, group membership determines the permissions that a user has. InControl provides two groups by default, the Administrator group and the Auditor group. In the example shown below, the Administrator group is chosen and the user then inherits its permissions from that group.

Listing Current Groups

The Groups tab will open to display a current group list.

Against each group entry is shown a summary of permissions along with member users. The user admin2 that was added earlier is shown in the above example.

The Administrator group allows full access to all functions. The Auditor group allows the least permissions which means read-only access to certain data. Creating new groups that have sets of permissions between these extremes is discussed next.

Creating New Groups

This starts the New Group wizard and the first step is to specify how the group read/write permissions will be determined. This is shown below.

The wizard provides the following options for determining the read/write permissions:

Next, specify a group name, in the example below this is server_admin. Also specify what InControl Server Permissions the group will have. In the example below, the privilege to change server settings is selected.

The next step is to specify what permissions this group has in relation to individual firewalls.

The top panel in this wizard step is used to specify which types of InControl objects in the tree that the permissions will be applied to.

By default, the permissions are specified for the root of the entire tree and this is specified with Inheritance enabled. This means that the same permissions apply to lower tree levels where inheritance can be applied. Alternatively, the permissions could be applied to particular lower level objects within the tree.

Note that permissions are divided into two categories, those that are directly applicable to the type of object selected and permissions that are inherited by children when the Inheritance option is selected.

In the final step, the wizard allows particular local users to be moved into this group. This allows users that already exist to be moved into the group. This step should be skipped if this group is only for Active Directory authentication. In the example below, the user admin2 is being added into the new group.

The user admin2 now belongs to two groups. When this happens, the permissions of all the groups a user belongs to are combined to determine what the user can do. In this case, admin2 is already a member of the administrator group so it is probably better to remove them from that group so they have the limited privileges of the server_admin group.

This example also illustrates how group membership can be determined when a user is defined or when a group is defined.

Additional Steps for Active Directory Authentication

After setup, the user only needs to press the Login button in the initial login dialog for AD to be used.

This chapter describes the Remote Console feature of InControl. The console is used to provide CLI access to cOS Core from within the InControl environment.

To open a console, select the target firewall in the Firewalls tab and press the Remote Console button in the toolbar.

Alternatively, right-click the firewall and select the console option from the context menu.

A new tab then opens that contains the console session.

This console can now be used for issuing cOS Core CLI commands, just as a Secure Shell (SSH) console over a network or a console connected directly to the firewall's local console port might be used. Commands are entered in the line at the bottom and the output is displayed in the area above. The display area can hold up to 5,000 lines of output.

Commands can be entered like any other console method. Tab completion can be used and the command can be executed by pressing the Enter key. The command line will then clear and the command plus output will appear in the output window above it. For example, here is the output from an ifstat command to list all interfaces.

For a complete list of CLI commands, refer to the separate CLI Reference Guide.

Shortcuts for Navigating Output

Multiple Console Sessions

This is allowed by cOS Core but should be avoided. When each CLI console session saves and activates its changes then those changes are immediately applied to the current configuration.

Console Logging

Note that logging will only be done for a console that is opened after the path is specified. If a console is already open when a path is specified, logging will not be done for that console. Similarly, if the path is removed and logging has already begun for a console, logging will continue for that console until the console is closed.

With a filepath set, a unique log file is created for each console opened, and it is never deleted. The filenames of the log files created will have the following format:

		<device-name>_yyyy-mm-dd_hh-mm_Tab_n.log

For example, My_FW_2017-04-26_10-18_Tab_1. The Tab_1 indicates that it was the first console tab opened during that minute.

Note that if administrator privileges are needed for writing files to the specified log folder and the InControl client is not running with those privileges then no log files will be written.

Console Timeout

This time-out value can be changed, for example to 3600 seconds (one hour), with the CLI command:

Device:/> set RemoteManagement RemoteMgmtSSH AllowSSH SessionIdleTime=3600

Alternatively, the time-out can be disabled for all InControl console sessions using an option in the Console tab of the InControl Settings dialog.

When the timeout occurs, the following message will appear.

Pressing the Enter key will cause a reconnect to the firewall with full administration rights.

Note: Snooping and the console number limit

By default, cOS Core allows only 4 CLI consoles to be opened at once so InControl cannot have more than this number of console windows open at once on a single firewall. However, if any cOS Core "snooping" commands are issued (for example, the arpsnoop command) InControl will execute this by opening a new console in the background just for that command. Therefore, each snoop command issued for a firewall from InControl will use up one extra console out of the allowed console limit.

The Alternative Console Dark Theme

The console is now displayed as light text on a dark background and with other color changes for operations such as selecting text.

Issuing Ping Commands and the Ping Tool

Instead of issuing the ping command in the remote console, InControl provides a more convenient way to do this in the remote console tab. This is called the Ping Tool and it is opened by pressing the ping button in the remote console toolbar.

This will open the ping tool at the top of the remote console window, as shown below.

The values for a ping command can then be entered. As described in the ping section of the cOS Core Administration Guide, the ping command can also be used to simulate incoming traffic in order to test the configured IP rule set and routing table. Packet simulation is enabled by specifying a value for the Source Interface in the dialog. This will be the interface that will receive the simulated packets.

Once the values for ping are entered, the command is initiated by pressing the button on the right of the dialog.

The output from the command along with the command itself are then displayed in the remote console window, as shown in the example below. Note that the ping command executed in this way always includes the -verbose option.

For individual firewalls there are two types of monitoring available:

22.1. Dashboard Monitoring

Dashboard Monitoring provides a way to set up dashboards for one of more firewalls to see activity in real-time. It is opened by selecting the Dashboard Monitoring function in the Home ribbon.

Dashboard Monitoring Overview

InControl Real-time Dashboard Monitoring allows monitoring of one or more Clavister firewalls using a variety of controls arranged in the style of a Dashboard. Two examples of typical dashboards are shown below to illustrate what is possible with this feature.

The image above illustrates a dashboard consisting of Gauge monitoring controls in various styles. Each Gauge is monitoring a single parameter in a cOS Core installation.

The image below shows a dashboard consisting of a List control at the top, a Bar Chart in the middle, with a Line Chart control at the bottom. The List and Chart are each being used to monitor a number of different parameters in a cOS Core installation at the same time.

Real-time Monitoring Components

When using Real-time Monitoring, the essential components are:

• Monitoring Controls

  Monitoring Controls are graphical displays which can show the current value of a cOS Core operating parameter for a firewall. Some controls monitor only one parameter (Gauge), some can monitor multiple parameters (Chart or List). A range of control styles are available and almost any style can be associated with any cOS Core parameter.

• Dashboards

  A Dashboard is a set of one of more controls that are displayed together for monitoring a group of cOS Core parameters. Different controls in a single dashboard can monitor just one or many firewalls. monitoring controls of any type can be placed anywhere on a dashboard and they can be scaled to any size.

Monitoring Control Types

The following types of monitoring controls are available:

Generic Monitoring Controls

These fall into two categories:

Gauges

A Gauge is a graphical display which can show the current value of a single cOS Core operating parameter on a single firewall. A range of Gauge styles are available and any style can be associated with any cOS Core parameter.

Chart and List

As an extension of a Gauge, the Chart and List are Gauges that can display multiple parameters in a single graphical unit and provide a simple means to do comparisons. A Chart is available in two forms: a Bar Chart and a Line Chart.

Predefined Controls

InControl includes special controls that have been created to monitor specific cOS Core parameters. The Web Content Filtering control is an example of this.

Layout Controls

These consist of the Label control for adding text and/or images to a dashboard, and the Group control for creating groups of related controls within a dashboard.

Design Mode and Monitor Mode

Real-time Monitoring functions in one of two modes:

Design mode

In this mode, the editor is used to create individual dashboards which can be saved and re-edited later. Real-time monitoring is not activated while in Design mode.

Monitor mode

In this mode, a specific dashboard associated with one or more firewalls is used for live monitoring.

	Tip
	Toggling between the design and monitor modes can be done with the F5 function key.

Designing Dashboards

By using the Design Mode editor, custom dashboards can be created which contain the monitoring controls that are desired for monitoring particular cOS Core installations.

Starting a New Dashboard

To begin a new dashboard, press the upper part of the Monitoring button in the Home tab.

This opens a new Design Mode tab with the default name Dashboard1 and a blank dashboard.

Changing the Dashboard Visual Theme

When just the dashboard background is selected (and this is the case when a new dashboard is created), there are Appearance settings for the entire dashboard displayed in the left-hand panel (an example is shown below). The Theme option can be used to change from the default white theme to a darker theme called Graphite (this is the theme used for the example dashboard shown at the beginning of this chapter).

Disabling the option DoubleBuffering can increase drawing performance but result in loss of smoothness. The option AutoScaleMode will change the drawing area to fit the controls added. The "Design" settings are for internal use only and need not be changed.

Monitoring Controls

InControl provides a range of Monitoring Controls in different styles which are listed in a menu on the left of the design tab.

It is up to the administrator to decide the style that best suits the presentation needs for the value to be monitored. If it is preferable to have a single control monitor more than one parameter, a Bar Chart, Line Chart or List control could be used.

The Speedometer Gauge has been selected above. That control will now appear in an area dragged out with the mouse in the cross-hatched design space. Alternatively, it is possible to drag the control from the control menu directly into the design space, in which case a default size is used.

All monitoring control styles can be scaled further, smaller or larger, by dragging their edges at the marked points while their positions can be changed by dragging their borders.

New Controls are Not Connected

The text "Not Connected" appears in a new control to indicate that a firewall and the cOS Core parameter it will monitor on that firewall have not yet been selected for the control. Binding a control to a firewall parameter is described later in the section.

Monitoring Control Properties

Once selected, any of the Properties of this control can be set using the properties display which is shown below:

For each control, both the lower and maximum value of the monitored quantity can be specified. For some controls that can monitor several parameters, such as a Bar Chart or List, several parameters can be defined and the parameters can be for different firewalls.

Dynamic Maximums

Sometimes it can be difficult to predict the maximum value of a parameter and if this is the case then the Dynamic Maximum Value can be set to True. This will mean that the control will extend its range and repaint itself automatically if the upper limit is exceeded (conversely it will reduce its range if the value falls back below the upper limit).

The Data Binding Property

One of the properties that must be set for a control to perform monitoring is the Data Binding. This is the combination of a firewall plus the cOS Core parameter within that firewall that is to be monitored.

Selecting the Data Binding property will cause the dialog shown below to appear. On the left of the dialog are the firewalls which have been located automatically by InControl, on the right are the individual cOS Core parameters which can be monitored in each firewall.

Once the control is associated with a parameter, the parameter's name will appear on the control, as shown below.

	Note: Controls without a binding do nothing
	If a control is not associated with a cOS Core parameter, it will still appear in a dashboard but will not do anything in monitor mode.

Changing Design Mode to Monitor Mode

In order to have a new dashboard become "live" and start monitoring a firewall, it is necessary to switch from Design Mode to Monitor Mode. This is done by pressing the Run button.

As soon as monitor mode is active, the currently displayed dashboard will appear as a live display and begin showing live values retrieved from a firewall.

When the Stop button is pushed, the dashboard returns to design mode.

	Tip
	Toggling between design and monitor modes can be done by pressing the F5 function key.

Adding Text Captions

Text Captions can be placed anywhere in a dashboard and can contain either text or an image. Their purpose is purely cosmetic and they provide a means to add helpful annotations or graphics such as a company logo to a dashboard. Like Monitoring controls, their size can be dragged larger or smaller, and properties such as the font can be changed.

Defining a Group

A Group is a display area that has a textual caption and several related controls can be placed into a Group's display area. By dragging its corners, a Group display area can be made smaller or bigger. A Group can be similarly dragged around the overall dashboard display area and when this is done all the controls it contains will be dragged with it.

Saving a Dashboard

Once a dashboard has been created, it can be saved by pressing the Save button in the tab's toolbar.

The dashboard is given a user defined name and saved. Dashboards are not saved as normal files in the local file system. Instead, they are saved as an entry in the main InControl server database.

A checkbox at the bottom of the save dialog determines if the dashboard is available to all clients.

Once saved, the dashboard can be opened at any time by using the shortcut Ctrl-O to open the dashboard selection dialog.

Managing Dashboards with the Library Browser

All dashboards are saved in the library of the InControl server database. This library also contains other saved objects such as ILA database queries. The Library Browser is a generalized feature for managing any of these saved objects, allowing them to be renamed, deleted, grouped into subfolders and activated.

For example, the dashboard called My_GW_Dashboard would appear in the library browser as shown below. Double clicking will activate it and a Monitor Mode tab will appear containing the dashboard.

The library browser is fully described in Chapter 24, The Library Browser.

Activating from the Dashboard Button

As an alternative to activating a saved dashboard through the library browser, if a firewall is selected in the Firewalls tab, pressing the lower part of the Dashboard Monitoring button in the Home toolbar brings up a list of available saved dashboards.

In the example below, the dashboard called My_GW_Dashboard is available for selection.

Using Quick Monitor

InControl provides a single predefined dashboard that can be displayed using the Quick Monitor button in the Firewalls toolbar.

Below is an example of how this default dashboard looks.

22.2. Rules Monitoring

It is possible to see the rule usage of cOS Core IP rule set entries. This is done by selecting the Rules Monitoring option from a firewall's context menu in the Firewalls tab.

The function can also be selected using the Rules Monitoring option in the Firewalls tab toolbar ribbon. Below is some example output from the option.

Disk Icon Colors

The example above shows the entries in the IP rule set and indicates with a green disk icon those rules that are being used and the number of matches on those rules since the last reconfiguration of cOS Core. The disk icon can have the one of the following behaviors:

• Red

  The IP rule entry exists in the InControl config but not on the firewall. An updated configuration may not yet have been deployed.

• Yellow

  More than one IP rule set entry with the same name and it is not possible to differentiate between the entries. All entries with the same name will see the same hits.

• Green

  This indicates the IP rule set entry has triggered and flashes (then fades out) every time the counter for that entry is incremented.

Expanding the Graph

Note that it is possible to expand the usage graph in the default display by dragging that column to the right.

Resetting the Hit Totals

The hot totals in the usage display information starts, by default, from the last cOS Core reconfiguration. However, the totals can be reset at any time by clicking on the Reset Statistics link at the bottom right of the display.

Exporting the Information

The usage display can be save to a file in CSV format by clicking on the Export link at the bottom left of the display.

cOS Core generates Log Event Messages on a regular basis when certain events occur, such as the triggering of an IP rule set entry. These log messages can be captured and then examined and analyzed using InControl.

The following methods can be used for looking at log event messages:

A full description of cOS Core log message generation and all log capture options can be found in the cOS Core Administrators Guide.

23.1. Quick Real-Time Monitoring

All log event messages generated by cOS Core are stored for a limited period in local memory. This is known as Memlog logging in cOS Core. The InControl client can display the log messages being written to a firewall's Memlog database in real-time and this is referred to as Quick Real-Time Monitoring. A tab for this display in the client interface is labeled RTLog.

To display the RTLog for a firewall, first select the firewall so its Firewalls tab is displayed, the press the Log Forensics button and select the Quick Real-time option from the menu choices, as shown below.

A tab is then opened with the same name as the firewall and the Memlog log messages are displayed in real-time as they are stored in memory on the device. An example of this is shown below:

Changing Formatting Options

By right-clicking anywhere in the Real-time Log, a menu is displayed that provides an option for wrapping lines so that all information appears in the windows without needing to scroll and another option for showing the timestamp for messages. By default, both of these options are disabled.

Message Timestamping

If the timestamp option is enabled in the above menu, a timestamp appears at the beginning of each message line. This is not the time the message was generated by cOS Core. The timestamp indicates the time when the message was received by the InControl client and is followed by the local time offset so that UTC can be calculated if required.

And example of how a log message is displayed with both word wrap and timestamp enabled is shown below.

Searching Messages

The messages are stored temporarily by the InControl client in raw form and a filtering capability is provided using basic text searching criteria.

For a more sophisticated logging tool, using a InControl Logging Agent (ILA) is recommended and this is described in the next section.

23.2. The ILA

A more sophisticated logging facility than Memlog is provided by the proprietary Clavister InControl Logging Agent (ILA). This software component comes with the InControl installation package and functions as an optional separate, independent server for receiving and storing cOS Core log event messages.

The ILA can capture the raw log messages generated by any number of firewalls that are managed by InControl. The ILA log event database can then be analyzed through report generating features integrated into the InControl client. The log messages are sent to the ILA in a proprietary binary file format with the filetype .fwl and these will be referred to as "raw log messages" in this document.

The diagram below shows how ILA fits into InControl usage. Several firewalls can send messages to the ILA and InControl clients manage it, as well as send log queries to it, via the InControl server. All communication between clients and the ILA are mediated by the InControl server. The ILA and the InControl server could be installed on separate computers or the same computer and could be on the same or separate networks.

Creating Multiple ILA Instances

To separate the log messages coming from different firewalls or groups of firewalls, it is also possible to create multiple ILA instances with separate log messages databases. This can be particularly useful in a cloud computing environment. Doing this is discussed in Section 23.3, Running Multiple ILAs. However, reading this section first is recommended to understand basic ILA installation and operation.

ILA Installation

ILA installation can be performed as part of running the InControl installer and can be installed together with the server and client on the same computer. However, the installer also allows ILA to be installed separately on a different computer. components.

The ILA is always installed on the same computer as the files which store received raw log messages. If installed on a separate computer, the ILA must have a network connection to its associated InControl server. This connection can be local or could be made remotely over the public Internet.

More than one ILA installation can be fed by messages from a single firewall. Similarly, one ILA installation can receive log messages from multiple firewalls. This is determined by what log servers cOS Core is configured to send messages to.

ILA Network Communication Uses Port 5555

If the InControl server and the ILA are running on the same computer, there will be no problem with port usage and communication between them.

However, if the ILA runs on a separate computer then that computer must allow incoming TCP and UDP connections on port 5555. TCP port 5555 is used when adding an ILA and/or deploying ILA configurations. UDP port 5555 is used when the InControl server polls the ILA for online status.

ILA Windows Services

The ILA runs as two separate windows services which are constantly running. These two services are:

• LogReceiver.exe

  This process performs the logging function of the ILA. It receives log messages and stores them in ILA's raw log database.

  The Status column of the Logging Agent tab in the InControl client does not indicate the status of this process.

• ILA.exe

  If the Log Analyzer feature is enabled, this process builds the log analyzer database. This analyzer database is separate from the log receiver's raw log database.

  The process also performs all query functions. That is to say, all queries launched from either the Log Explorer or Log Analyzer features in the InControl client.

  If a query is launched and this service is not running, the client will return an error message.

  The Status column of the Logging Agent tab in the InControl client does indicate the status of this process.

	Important: ILA services must run under same Windows account
	By default, the services LogReceiver.exe and ILA.exe will run under the same Windows user account. This should not be changed. If they run under two different accounts, the ILA will not function.

The reason for having two services for the ILA is to allow the LogReceiver.exe service to be as efficient and robust as possible. If any execution bottlenecks occur in the ILA.exe service, they will not affect log message processing.

If either of the ILA processes stops running for some reason, Windows will wait one minute before it automatically tries to restart the service.

Restarting ILA Services

Unlike the InControl server, the ILA does not have its own graphical user interface to stop or start its Windows services. If the ILA services might not be running then the status should be checked. One symptom is this if the logging agent has a status of offline in the client. Another symptom is if log queries are failing to execute.

To check the ILA services in Windows, open the Windows services management tool. Look for Logging Agent and Log Receiver in the list.

The status for both should be Started if the services are running normally. If the status for either is Stopped then they can be restarted by right clicking the service line and selecting the menu option Action > Start.

Using a Local User Account

Like the installation of the InControl server, if running on a separate computer, it is recommended to use the same, separate, local user account for the ILA installation and running ILA. A local account cannot be logged into remotely, thereby increasing security.

	Important: The ILA service needs administrator privileges
	After ILA installation, the Windows service ILA.exe should be run under the local user account and this account should have administrator privileges over the ILA raw log database folder. Administrator privileges allow the ILA server to create new raw log message files.

Installing Over Older Versions

When installing over an older version of the ILA, there is no requirement for uninstalling the old version first. In addition, the ILA servers does not require that its Windows service is halted first. This occurs automatically.

ILA Server and InControl Server Communication

Communication between the InControl server and the ILA is achieved using the Clavister proprietary, secure Netcon protocol. Netcon requires that an agreed Secret Key is used by both sides of the communication.

By default, the ILA and server use an agreed, predefined secret key. This is displayed in the ILA configuration dialog available through the InControl client and which is discussed later in this section.

If the ILA server is running on the same PC as InControl, the IP address for access is 127.0.0.1.

Configuring cOS Core for ILA Logging

For each firewall, cOS Core should be configured to specify which loggers to send messages to and which messages to send. The term Logging Agent is used to refer to an ILA server.

To specify a new ILA server, first press the Logging Agents button in the ribbon toolbar of the Home tab.

This will open the Logging Agents tab. To define a new ILA server, press the Add button and a new Logging Agent dialog will open.

In the example shown above, a symbolic name of My_ILA_server is given for the server. The IP address is given a default value of 127.0.0.1 (the loopback IP address) which will be correct if the ILA server is on the same computer as the InControl server.

The secret key is unique for each ILA instance and must be filled in manually. The key can be found and copied into the system clipboard by opening the separate Logging Agents Manager application and opening the properties for the ILA instance. The first ILA instance is always called "Default". Using the Logging Agents Manager software is described further in Section 23.3, Running Multiple ILAs and it is installed automatically along with other InControl components.

After clicking OK, this server definition will now appear in the Logging Agents tab.

The Online field indicates that connection to this ILA server by the InControl server was successful. The Locked by field indicates any client that is currently editing the properties of this server.

Editing the ILA Server Configuration

The Logging Agents tab also provides the ability to configure the ILA server since, unlike the InControl server, there is no separate graphical interface for doing this.

This brings up the ILA configuration dialog.

Here, the Management IP is the source IP address for management connections to the ILA server. The management IP address of the ILA server itself is specified in the ILA Properties dialog.

To configure the ILA to accept and store log messages coming from a particular firewall, select the Registered Firewalls tab and press the plus "+" button.

After selection, the chosen firewall will appear in the Registered Firewall list and the IP Address value for the firewall will default to the management IP address of the firewall and this is the address from which the ILA will expect log messages.

If necessary, this address can be changed by selecting the firewall line, pressing the edit button in the dialog and entering a new value, as shown in the example below where the firewall called My_FW will send log messages from the IP address 10.6.40.52.

The ILA configuration dialog has the option to deploy immediately after the dialog closes Alternatively, the deployment can be done using the separate deploy button in this tab's toolbar. Deployment means that the new settings are sent via the InControl server to the ILA server.

If the ILA server configuration has been changed but not deployed, an alarm will be created in the alarm list to indicate this.

Finally, the firewall itself must be configured to send log messages directly to the ILA server. This is done by selecting System then Log and Event Receivers and adding an FWLog Receiver.

The log receiver should be configured with the IP address and port number that is configured for the ILA server. Below, the defaults are specified.

Changing the Secret Key

Changing the secret key of the ILA server is a two-step process where the key has to be changed first on the ILA server and then the local client:

1. Press the Configure button, change the secret key in the ILA server configuration and deploy the new configuration to the server.

2. Right-click the ILA server in the server list and select Properties to display the properties dialog. Now, set the secret key to the same value that was deployed to the server in the previous step and close the dialog.

Troubleshooting ILA Setup Problems

Troubleshooting problems with ILA setup and successful operation is discussed further in a Clavister Knowledge Base article which can be found at the following link:

https://kb.clavister.com/324735475

ILA Raw Log Database Management

The ILA raw log database management options are found in ILA configuration dialog. Access this by selecting the ILA server in the Logging Agents tab and pressing the Properties button in the tab's toolbar.

Now select the Log Receiver tab in the dialog.

The following parameters are relevant to the raw log database:

• File Size (Mb)

  This value specifies the maximum file size of the individual files that store log data. The maximum size for this setting is limited to 200 MBytes. It is not related to the total size of the raw log database since the database consists of many of these files. However, the maximum size can affect search speeds.

  The raw log database structure consists of a folder for each firewall that is generating logs. Within each firewall folder there is a folder for all the raw log files for each month. At the start of a new day, a new daily log file is created in the relevant month folder. When this daily file reaches the configured maximum size it is closed, compressed using the GZIP algorithm and an additional raw log file is started for that day.

  The advantage of this scheme is in searching logs. Each storage file begins with the start and end time of the logs it contains. This means that logs for a particular time interval can be found quickly provided the individual log files are not too large.

• Maintenance Hour

  This parameter specifies the time of day when routine maintenance will take place. In the example shown above, 3.00 in the morning has been specified.

• Retention Time

  When the routine maintenance process runs, it deletes any files that are older than this numbers of days. This setting is the principle means of controlling the disk space occupied by the ILA raw log database.

  Note: Setting the ILA retention time value

  It is up to the administrator to determine an appropriate value for the retention time setting. It should be based on the amount of free disk space available and the expected rate of increase in the raw log files. A useful exercise for making this determination is to observe the size expansion over a few days of typical system usage. If an ILA instance is running on the same computer as the InControl server, the ILA raw log database size will contribute to the alert that the InControl server generates should free disk space fall below the configured value.

• Log Files Path

  This is the file system location used to initially store the incoming raw log messages being sent by monitored firewalls. The log messages sent by cOS Core are in a special .fwl binary format and should not be read outside of InControl. To examine the received messages, the InControl Log Explorer tab must be opened, an ILA instance selected from the list and the Open > Log Files option selected.

Raw Log Folders and File Naming

As discussed above, ILA keeps raw log messages in files that have a configured maximum size. These files are organized in the following way:

• For each month of operation, a folder is created with a folder name made up of the current year and month. For example, the folder name used for the log files created during August 2011 is "201108".

• The messages received for each new day within a month are placed in that month's folder and each log file created is given a name of the form:

  			<day>-<suffix>

  For example, the first log file created on the first of any month has the name "1-0.fwl". The first file created for the second day of any month is "2-0.fwl".

• When files reach the configured size limit and a new log file is created for that day, the filename is the same except for the suffix which becomes "-1", "-2" and so on for subsequent files. For example, when the first file for the first of the month reaches the configured limit, the second file created for that day is given the name "1-1.fwl". At the same time, the previous file is compressed using GZIP and its name is changed to "1-0.gz".

• All raw log files for a particular firewall are stored in a folder dedicated to that firewall and these are stored within the ILA main database folder. Each firewall folder name is created from the unique firewall ID number (since the firewall name can change). The configuration file ILA.xml contains a mapping of a firewall's ID number to its IP address.

Optimizing InControl Log File Storage

The administrator has various options to best optimize InControl log file storage. These are discussed in a Clavister Knowledge Base article which can be found at the following link:

https://kb.clavister.com/324735449

ILA Logging Without InControl Management

Sometimes there may be a requirement to have a firewall send log messages to an ILA server but not give InControl management rights over the firewall.

When InControl can manage a firewall it means its NetCon Keys have been added to InControl and any InControl client then has the potential to read and change the configuration. If the aim is just to enable ILA logging, then this can be done without giving the keys to InControl using the following steps:

1. Open the InControl client and select the Firewalls tab.

2. Add the firewall and give it a name but mark the firewall as being Offline. This means that InControl will not try to contact the firewall.

3. In the Logging Agents tab, bring up the Configuration dialog of the target ILA server, select the Registered Firewalls tab and add the newly defined firewall.

   If the Log Analyzer function is also to be used, the firewall should be added under the Analysis tab (this can be done later).

   When the dialog's OK button is pressed, this ILA configuration is deployed to the ILA server.

4. Stop both ILA Windows services. This is done in Windows by starting the utility services.msc in a command console. Locate the LogReceiver and ILA service then stop them. Leave the utility open to restart the service later.

5. The ILA configuration file ila.xml now needs to be manually altered. This file is located in the following folder depending on the version history of InControl:

   • For an InControl installation that has been upgraded to InControl version 1.83 or later, the file is located within the path %appdata%\Clavister\InControl\LoggingAgent\Config. Where %appdata% represents the user account that performed the initial installation of InControl.

   • For a new installation of InControl from version 1.83 or later, the file can be found within the path %programdata%\Clavister\InControl\LoggingAgent\Config.

   Under the above path's Config folder is a separate configuration files folder for each logging agent instance that has been created and with the name of that instance. If no extra instances have been created then only the default folder called Default will exist within the Config folder.

   After opening the relevant ila.xml file in a text editor, change the firewall's IP from the default of 0.0.0.0 to the actual IP address of the firewall. Save this change.

   Every time the a new ILA configuration is deployed, this setting will be reinitialized to 0.0.0.0 and this step must therefore be repeated.

6. Now restart LogReceiver and ILA services then close the services.msc utility.

In a later version of InControl these steps will not be required and it will be possible to enable this option through a simple checkbox selection.

23.3. Running Multiple ILAs

When a full installation of InControl is performed, a single instance of the ILA is always installed along with a full installation of InControl and working with this instance is described in Section 23.2, The ILA. It could also be installed separately using the individual ILA installation .exe file. This ILA instance is known as the Default instance.

Multiple ILA Instances and the Logging Agents Manager

Sometimes, there can be a use case to have multiple ILAs running on the same server so that logging information is divided up, with different firewalls or groups of firewalls sending their log messages to different ILA instances. InControl provides this feature through a separate piece of software called the Logging Agents Manager.

The Logging Agents Manager is installed as part of the standard InControl installation. If it is started by selecting it via the Windows Start menu, a graphical user interface is displayed. A typical example of this is shown below.

Each line in the display shows details for an individual ILA instance along with its current status. The default ILA instance will be shown with the name "Default".

	Note: Logging Agents Manager requires administrator privileges
	The Windows user that runs the Logging Agents Manager must have administrator privileges. This is to allow new Windows services to be created.

Steps for Configuring a New ILA Instance

The following steps are needed when configuring a new ILA instance:

1. Create a new named instance in the Logging Agents Manager and manually start the two services associated with an instance. Doing this is fully described in this section.

2. Using the InControl client, associate one or more firewalls with the new ILA instance. Doing this is described in Section 23.2, The ILA under the heading Configuring cOS Core for ILA Logging.

3. Also using the InControl client, set the user permissions that allow the collected data to be read and reports generated from it. This is also described in this section.

Adding a New ILA Instance in the Logging Agents Manager

A new ILA instance is added by pressing the plus button in the instance manager interface. A dialog is displayed for entering the instance's parameters. An example of this is shown below.

The following properties can be set for an ILA instance:

• Name

  A symbolic name for the instance. This is only used for displaying instance information in the instance manager. Note that this name cannot be changed once it is assigned.

• IP Address

  This is the IPv4 address or addresses of the network cards in the local computing environment on which incoming messages will be accepted. This is 0.0.0.0 by default (all networks) which is the normal setting with the default ILA instance.

  The usual reason for changing this setting from the default of all networks is if there are multiple network cards that could receive messages, such as in a cloud computing environment.

• ILA TCP Port

  The TCP port on which the instance will listen. This must be unique for each ILA instance and by default, the manager will set this to the next available port number. However, the manager cannot know about other applications that might use the port number it chooses so the administrator can set a specific port if that is required.

• ILA PSK

  By default, the instance manager will pick a random PSK to use for security between the ILA instance and firewalls. Pressing the Random button will generate a different random PSK. Alternatively, a PSK could be entered manually.

• Database

  The type of database used by the ILA instance. By default, this is set to SQLite.

  Selecting another database type, such as MySQL, may require additional settings, in which case the dialog will expand to allow entry of those settings. Database choices are discussed further in Section 23.7, The Log Analyzer.

• Username and Password

  This is the Windows username under which the instance will run. The drop-down box provides the option to select from the following alternatives, which do not require a password:

  • NT Authority\LocalService (the default)

  • NT Authority\NetworkService

  • .\LocalSystem

  Another arbitrary username can also be entered for the instance, in which case an associated password must also be entered. The instance manager will then automatically create the associated Windows folders for this user and the services for the ILA instance will run under this username. This will ensure total separation in Windows between the ILA instances and their associated data.

After defining the settings of the new instance, press the OK button to close the dialog and add the instance to the manager list. Each new instance has two new Windows services associated with it. The following should be noted about these services:

• Directly after adding a new instance, the two associated service processes must be started manually by pressing the two start buttons on the right hand side of the line displaying the instance in the manager display. Using these buttons is discussed later in this section.

• The two services only need to be started manually directly after creating the new instance. The services are set to always start automatically after a complete restart of Windows.

• The two services will always have the same names in the Windows process list for all instances, and these are ILA.exe and LogReceiver.exe.

• The processes will continue to function, regardless if the instance manager is open or not. The instance manager can therefore be closed once any instance additions or changes are made.

Setting User Permissions

Once a new ILA instance is setup, the final step is to enable the necessary permissions in InControl. The following permissions will need to be set:

• The LogAgentAdmin permission needs to be enabled for administrators so they can add or delete ILA instances in InControl.

• For users, the Read and ExecuteLogQuery permissions need to be enabled so that the logs collected by ILA instances can be read and analyzed.

Setting permissions is described further in Chapter 20, User Accounts and Groups.

Stopping and Restarting ILA Services

ILA services for all defined instances will be automatically started during Windows system startup. The instance manager has two columns in its display which show the current status for both the ILA service (ILA.exe) and the Log Receiver service (LogReceiver.exe) for each instance.

In order to stop and/or restart any of these services, the columns in the display also include buttons for each instance to allow the administrator to do this. An example is shown below.

Note that the order of starting the services is important but the administrator does not need to worry about this since one start button will be automatically disabled if the other start button needs to be pressed first.

Editing an ILA Instance

To edit an ILA instance, select the line for the instance in the manager display and press the Edit button. A dialog similar to the one used for creating a new instance will be displayed, allowing any of the instance's parameters to be changed.

	Important: Properties may also need to be changed in the client
	If a property of an instance that affects communication with firewalls is changed (for example, the log agent port number) then this must also be changed for the ILA definition in the InControl client. Otherwise, communication between relevant firewalls and the ILA instance will be lost.

After editing an ILA instance, the services need to be restarted for the changes to take effect so the manager presents a confirmation dialog for this to be done automatically, as shown below.

Note that during the services restart there will be a short period during which any log messages sent to the ILA instance will be lost. If the services are not restarted immediately then any changes made to an ILA instance will come into effect following a later restart.

Deleting an ILA Instance

To delete an ILA instance, select the line for the instance in the manager display and press the red crossed delete button .

A confirmation dialog will be displayed to make sure this is what the administrator wants to do. On deletion, the instance's service processes will be stopped and all the related instance files, including the database files, will be deleted.

23.4. The Log Explorer

The InControl client provides extensive tools for looking at both real-time ILA logging and examining the log event history kept in the ILA database. To start doing either, press the top part of the Log Explorer button.

Provided an ILA instance exists, the Log Explorer tab will open.

Building Log Queries

The Query Builder is displayed as part of the Log Explorer tab and it allows log queries to be constructed and saved.

Select the Add option to choose which firewalls will be included in the query. In the example below, only one firewall is selectable and it is called SG50-492.

When selected, this firewall now becomes part of the query.

Multiple firewalls can be added to the list of firewalls for the query.

Displaying ILA Log Messages in Real-time

To show the logging that is taking place to an ILA server from the selected firewalls in real-time, press the Change link for Time Span and select Real Time from the menu.

Running the Query

The above steps defined a simple query which was showing real-time logging for a particular firewall. Once a query is defined, it needs to be executed and this is done by pressing the Run button in the toolbar.

The results of the query are then displayed in a list. Below is an example of this output.

	Tip: Different severities have different background colors
	Different severities are shown with different background colors. For example, events with severity Error appears with an orange background and severity Warning has a yellow background.

By clicking on any line in the query output, the details of the individual log message can be displayed in a separate lower pane. Below is an example which corresponds to the highlighted line in the previous image.

In addition, it is possible to copy to the clipboard information relating to a particular value in the details pane by right-clicking it and choosing one the options from the context menu that is displayed. Below is an example.

Note that the context menu feature will not work on all message fields, only those which make data available such as IP address fields.

Also note that the under the log message detail pane is a status line that displays useful summary information about the query, both while it runs and after it completes. This includes information about the amount of data processed and the time window that was scanned.

If required, the hex version of the log message can be viewed by selecting the Packet Dump tab. An example is shown below.

Displaying Logs Using Relative Time

Instead of the real-time option, relative time can be selected.

This view of log messages looks backwards from the current time. A drop-down menu is used to select the desired unit of time and a slider control is used to select the number of the chosen time unit.

Displaying Logs Using a Time Span

The time span option allows the display of all logs in a specific time range.

This view of log messages looks backwards to a specific time range which is specified using two date fields.

Adding Filters

Except for real-time log display, other options have the potential to display large numbers of log messages. This is usually always the case if the All Logs option is chosen.

To refine the displayed logs further, the Filter option can be chosen so that one of more filter data types can be matched against specific criteria. When the option is chosen, a data type can be selected from a large menu of choices.

After a filter data type is chosen, a boolean operator and a value can then be specified. In the example below, the action must equal Allow for the log message to be displayed.

The applied filter can consist of several boolean expressions for different types of data. Below, a second condition to be added to filter out messages that have a severity equal to Warning.

If there is than one filter condition, they can be combined either with a logical AND or a logical OR depending on the selection made from the combination choices.

Creating Queries from IP Rule Set Entries

An alternative, and sometimes more convenient method of creating a log explorer query is directly from cOS Core IP rule set entries. This is done with the following steps:

1. Right click an IP rule set entry and select the New Log Query option.

2. A dialog opens which allows any of the properties of the IP rule set entry to be selected to create a new log explorer query.

3. After confirming the dialog above, the selection is displayed in the normal query builder so it can be run or modified further.

Setting the Time Zone

When using the log explorer, the datestamp times shown on log messages will be displayed in terms of the Log Explorer tab's current Time Zone setting. Similarly, a time interval in a query should be specified in terms of this time zone.

By default, a Log Explorer tab's current time zone is taken from the InControl client's host Windows system. However, the time zone can be changed so that the times on log messages are displayed in terms of an alternative zone and any time ranges entered in queries can also be entered in terms of that new zone. The current time zone is displayed by a drop-down box in the toolbar ribbon for the log explorer, along with the alternative choices.

The following should be noted about the log explorer time zone setting:

• The time zone selected will apply only to the Log Explorer tab in which it is selected. Multiple Log Explorer tabs could use different time zones. A new Log Explorer tab will always default to the time zone of the host Windows system.

• The selected time zone is saved along with a saved log explorer query and that time zone will be used whenever the saved query is executed.

• Log explorer queries that were saved in an InControl version prior to 3.10.00 will always use UTC+0 as the time zone when run using version 3.10.00 or later.

Country Flags on IP Addresses

It should be noted that when displaying IP addresses in the log explorer query results, InControl will automatically attempt to place a country flag next to the IP address. As shown in the example below, a generic gray network flag is used for private IP addresses.

In some instances the country flag may not be visible, or only visible for certain IP addresses. An article in the Clavister Knowledge Base describes why this may happen and it can be found at the following link:

https://kb.clavister.com/324735457

Exporting Log Query Results to a File

Once a query has run, the results of that query can then be exported to a file in one of a number of formats.The export option can be found in the log explorer's toolbar ribbon.

The options available are:

• FWL format - This is Clavister's proprietary binary format intended to only be viewed inside InControl.

• CSV format - A format that is easily importable to a variety of analysis tools, such as Microsoft Excel™.

• Syslog format - The standard Syslog text file format.

• Aggregated Statistics - This is a text file which provides a summary of the number of log events that were retrieved of various types. For example, the number of events that contained each source IP address or the number of events for each log category.

When exporting to a file, selections of certain report rows can be made first by using mouse clicks with the Ctrl button depressed. When the export is performed, the InControl client will now ask if only the selected rows should be exported or the entire report.

Saving a Log Explorer Query

The most recent log explorer query can be saved so that it can be quickly run again. This is done by selecting the Save option in the toolbar ribbon, or alternatively the Save as option.

The following should be noted about saving queries:

• Queries are stored in the InControl server database. They cannot be saved to external files.

• The name given to a saved query is arbitrary and does not require a specific format and does not get a default name.

• When saving a new query for the first time, the Save and Save as options do the same thing and will open the same file chooser dialog for assigning a name to the saved query.

  The file chooser dialog (shown below) displays the InControl server's own file system and it is possible to save a query anywhere but it is recommended to store them in the Log Explorer folder so they can be included in the Open submenu. It also possible to create new a new folder for storing queries.

  Note that the InControl's server's internal file system can be browsed at any time by pressing the Library Browser button in the Home toolbar ribbon.

• Once a query is initially saved, selecting the Save option again will just overwrite the previously saved query and the naming dialog will not be displayed. The Save as option should be selected if the query has been modified and the new version is to be saved using a different name.

How to open a saved query is discussed next.

Opening a Saved Query or Saved Report

The Open button in the log explorer toolbar ribbon provides the ability to open a previously saved query or a report saved in the proprietary .fwl format.

In more detail, the two menu options are:

• FWL File

  This allows the user to browse and read the raw log data that has been received from firewalls associated with an ILA instance. These are stored using a Clavister proprietary file format that has the suffix .fwl. This is a binary format intended to be viewed only inside InControl.

• Log Query

  This displays a further choice between saved Log Analyzer reports and saved Log Explorer queries. An example submenu for the Log Explorer option is shown below. This displays all the queries saved in the Log Explorer folder of the InControl server's internal file system.

Note that, like log analyzer queries, log explorer queries can also be opened through the Library Browser which is described in Chapter 24, The Library Browser.