InCenter 2.2.2 Cloud Administration Guide

Table of Contents

1. Overview
2. Using the WebUI
2.1. Starting the WebUI
2.2. Activating InCenter Changes
3. Monitoring NetWall Nodes
3.1. Setting Up Monitoring
3.1.1. Adding NetWall Nodes with the WebUI
3.1.2. Configuring a Log Receiver in NetWall Nodes
3.1.3. Configuring a VPN Tunnel in NetWall Nodes
3.2. Node Dashboards
3.2.1. Overview Dashboard
3.2.2. Network Allowed
3.2.3. Network Denied
3.2.4. Threats Unhandled
3.2.5. Threats Denied
3.2.6. VPN
3.2.7. Communication
3.2.8. OneConnect
3.2.9. Log Analyzer
3.3. The Health Display
3.4. CyberSecurity Score
3.5. Reporting
3.6. Alerting
3.7. Device Monitoring
3.8. NetEye Monitoring
4. Managing Users
4.1. Managing Users with the WebUI
5. Node Groups
5.1. Managing Groups with the WebUI
A. Third Party Software

Chapter 1: Overview

[Note] 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

It also available in a framed HTML version.

The Clavister InCenter cloud product is an administrative tool for the remote centralized monitoring of one or many NetWall systems using a Web User Interface (WebUI) running in a standard web browser. The browser connects to an instance of the InCenter server running in a cloud environment and the server then mediates communications between the WebUI and the NetWall systems. This is illustrated below.

Firewalls Monitored by the InCenter Cloud

Figure 1.1. Firewalls Monitored by the InCenter Cloud

Note that a NetWall system will be referred to generically as a node in the context of InCenter.

When a NetWall node is added to InCenter, it means that the node continues to be managed locally but InCenter is able to act as a log server that receives log messages from the node. The received logs messaged can then be analyzed using InCenter dashboards.

History Storage Times

The following should be noted about the default length of time that the log messages data received from nodes are stored by the InCenter cloud service:

  • Complete log message data is retained for a period of 3 days.

  • Aggregated log message data is retained for a period of 30 days. This means that drill down to the log message level is not possible. However, the aggregated data can still be broken down by node or time range.

To extend these default time periods, contact your local Clavister sales representative.

Chapter 2: Using the WebUI

The InCenter WebUI is a graphical interface that allows interaction with the InCenter server through a standard web browser. It can be used for performing a range of administration and monitoring tasks.

The WebUI Language

The interface language used in the InCenter WebUI comes from the default language used in the web browser, but will only change from English if the browser's language is available in InCenter. Currently, the languages available in InCenter are:

  • English (abbreviation: "en").

  • Japanese (abbreviation: "ja").

The WebUI language cannot be changed once the interface has opened. To switch language, the WebUI should be closed, the browser's default language changed and then the WebUI reopened.

Alternatively, the language can be selected by adding the parameter:


to the URL that opens the initial login page (it will not change the language mid-session, after login). The possible <language-abbreviation> values are given in the preceding language list.

For example, to open the login dialog in English:


To open the login dialog in Japanese:


Note that once the WebUI is opened with a particular language, it will open for the next session with that same language if no language parameter is specified in the URL. The language can only be changed by explicitly specifying the language parameter at the end of the URL.

2.1. Starting the WebUI

The WebUI is available through any modern web browser. The only prerequisite is that the browser can access the InCenter server using HTTPS.

Connecting to the WebUI

After opening a browser, the InCenter WebUI is started by entering the IP address of the InCenter server in the browser's navigation field.

Logging In

After successful connection to the InCenter server, a login dialog will be displayed in the browser, as shown below.

WebUI Login Dialog

Figure 2.1. WebUI Login Dialog

  • Username: admin

  • Password: admin

Note that the second time the administrator logs in with these credentials, they will be prompted to change the password to one that conforms to the system's password policy settings.

The Overview Page

After successfully logging into the WebUI, the Overview dashboard is displayed which provides a graphical summary of activity for all the nodes currently communicating with InCenter. An example is shown below.

Initial WebUI Overview Dashboard

Figure 2.2. Initial WebUI Overview Dashboard

If no nodes have been added previously, the first step a new administrator will probably want to take is to add one or more InCenter. Doing this is described in Section 3.1.1, Adding NetWall Nodes with the WebUI

2.2. Activating InCenter Changes

None of the changes that are made using the WebUI, either to the InCenter or to nodes, are made permanent until they are committed. If any pending uncommitted changes exist, this is indicated by an orange disk appearing over the changes icon in the top right of the display with a number indicating the number of pending changes.

The example below shows the changes icon with single change is waiting for activation by the administrator.

The Activation Pending Icon

Figure 2.3. The Activation Pending Icon

By pressing the changes icon, the Changes display will open with a list of pending changes. This can also be opened by selected the Changes option from the System menu in the navigation pane.

The Changes Menu Option

Figure 2.4. The Changes Menu Option

An example of the Changes display is shown below, with a single pending change which is the addition of a new standalone node called my-node1.

Pending InCenter Changes

Figure 2.5. Pending InCenter Changes

The administrator now has one of the following choices:

  • Press the Commit Changes button to commit all changes. It should be noted that a commit operation is all or nothing. A selective commit is not possible.

  • Press the Reject all button to reject all the changes. This will discard any pending changes made since the last commit operation.

  • Select a single change to see its details and optionally reject just that change.

Also note that filters can be applied to the pending list to show specific types of changes.

If the administrator chooses to commit changes, a final dialog appears for confirmation and provides the opportunity to enter a comment into the history for the commit.

Confirming InCenter Changes

Figure 2.6. Confirming InCenter Changes

Finally, the WebUI will display a message indicating completion of activation.

The Activation Complete Message

Figure 2.7. The Activation Complete Message

Chapter 3: Monitoring NetWall Nodes

3.1. Setting Up Monitoring

This section describes how to set up a NetWall node for monitoring by InCenter. Monitoring means that the node will send log event messages to InCenter so that its activity can be analyzed and presented graphically in the InCenter WebUI.

For monitoring to function, the following two steps are required:

  1. The node must be added to InCenter. Doing this is described in Section 3.1.1, Adding NetWall Nodes with the WebUI.

  2. The NetWall node must be set up to send log messages back to InCenter. Doing this is described in Section 3.1.2, Configuring a Log Receiver in NetWall Nodes.

  3. To make log message sending secure, a VPN tunnel should be set up between the node and InCenter. Doing this is described in Section 3.1.3, Configuring a VPN Tunnel in NetWall Nodes.

3.1.1. Adding NetWall Nodes with the WebUI

Any NetWall node with cOS Core software version 13.00.00 or later installed can be monitored using InCenter.

To add a NetWall node to InCenter for monitoring, select the Nodes option from the Manage section in the navigation pane, as shown below.


Figure 3.1. s

Press the Add button and select Node.


Figure 3.2.  Option

This starts the new node wizard which will go through the following steps:

  1. Properties

    Select the NetWall option and specify a logical name for the node with an optional comment.

    Node Wizard - Properties

    Figure 3.3.  Node Wizard - Properties

    [Important] Important: The InCenter name must match the firewall name

    The node name specified in InCenter must match the local node name on the firewall itself. In addition, the firewall name should not be duplicated within InCenter. Therefore, the name may need to be changed locally to a new value in cOS Core before performing the addition in InCenter.

  2. Done

    In the last step, a summary is displayed to confirm the details of the addition.

    Wizard - Done

    Figure 3.4.  Wizard - Done

  3. Pressing the Done button will now close the wizard and the added node will appear in the node list.

This change to InCenter now needs to be activated and doing this is described in Section 2.2, Activating InCenter Changes.

3.1.2. Configuring a Log Receiver in NetWall Nodes

For a NetWall node to send log messages to InCenter, a log receiver object needs to be locally configured on the node. Doing this using the node's local WebUI or CLI is described below.

Configuring a Log Receiver with the WebUI

To configure a Syslog log receiver in the node's WebUI, open the WebUI in a browser and go to: System > Device > Log Receivers. Then press the Add button and select the option Syslog Receiver.

Add Syslog Receiver

Figure 3.5. Add Syslog Receiver

The dialog for this new object can then be filled in, as shown in the example below.

Add Syslog Receiver Dialog

Figure 3.6. Add Syslog Receiver Dialog

Note that the IP address specified is the same IP address that is used for SSH management access for InCenter.

The option to make log messages InCenter compatible must also be enabled and this is found in the Advanced tab. Note that this setting can only be found in NetWall nodes running the software version 12.00.16 or later.

Enabling Log Message Compatibility

Figure 3.7.  Enabling Log Message Compatibility

Configuring a Log Receiver with the CLI

The node CLI could be used instead to configure the log receiver. The following is an example of a command to do this where the destination IP for log messages is

Device:/> add LogReceiver LogReceiverSyslog my-syslog-receiver

3.1.3. Configuring a VPN Tunnel in NetWall Nodes

When using the InCenter Cloud service, Syslog messages must be sent from firewalls to the cloud through a VPN tunnel and this tunnel must be locally defined in the node's configuration using a LAN to LAN VPN object. Doing this with the node's WebUI or CLI is described next.

Note that where multiple firewalls are sending log messages to the same InCenter Cloud instance, either each firewall can have its own tunnel, or multiple firewalls can route log messages via a single edge firewall through a single VPN tunnel.

Configuring a VPN Tunnel with the WebUI

Before configuring the VPN tunnel itself, a Pre-shared Key object must first be created that contains the pre-shared key value for the tunnel. To configure this, go to Objects > Key Ring, press the Add button and select the Pre-Shared Key option.

Add Pre-Shared Key

Figure 3.8. Add Pre-Shared Key

The dialog for the pre-shared key can then be filled in, as shown in the example below. The name can be any suitable text but the key must set to the type Hexadecimal key and the key value copied from the cloud details page and pasted into the Passphrase field. The size should be left at the default value of 512.

Add Pre-Shared Key Dialog

Figure 3.9. Add Pre-Shared Key Dialog

To configure a VPN tunnel in the node's WebUI, open the WebUI in a browser and go to: Network > Interfaces and VPN > IPsec. Then press the Add button and select the option LAN to LAN VPN.

Add VPN Tunnel

Figure 3.10. Add VPN Tunnel

The first part of this dialog for this new tunnel object can then be filled in, as shown in the example below.

Add VPN Tunnel Dialog

Figure 3.11. Add VPN Tunnel Dialog

The following values must be entered:

  • Name - Any suitable name for the tunnel object.
  • Remote Endpoint - This is the IP address of the remote tunnel endpoint which is provided on a customer's web access information page for the InCenter cloud. An IP address can be entered directly. However, if an FQDN is used then an FQDN Address object must be created first and then that object is used in this field.

  • Local Network - This can be any local IP address. Using the IP address object for the local Ethernet interface is recommended, as shown in the example screenshot above.

  • Remote Network - This is the IP address of the log receiver which is also provided on the web access information page. It is the same IP address that is specified for the Syslog receiver object.

  • Add route statically - This option must be enabled (by default, it is) so that Syslog traffic is routed through the tunnel.

The second part of the dialog specifies the authentication used for the tunnel. The method should be set to Pre-shared Key and the value of the key should be set to the pre-shared key object created previously.

Add VPN Tunnel Dialog - Authentication

Figure 3.12. Add VPN Tunnel Dialog - Authentication

Activate All Changes

All the changes made to the cOS Core configuration should now be activated and committed by selecting the Save and Activate option from the toolbar.

Activate and Save Configuration Changes

Figure 3.13. Activate and Save Configuration Changes

Configuring a VPN Tunnel with the CLI

Alternatively, the following CLI commands could be used instead. First, to configure the pre-shared key:

Device:/> add PSK my-psk Type=HEX PSKHex=<paste key here>

Next, to configure the tunnel:

Device:/> add Interface LANtoLANVPN my_incenter_tunnel

Configuring a Lan to Lan VPN object is described further in the separate cOS Core Administration Guide.

3.2. Node Dashboards

For each node that sends logs to InCenter, a number of dashboards are available in the WebUI which provide both details and a summary of node activity. These dashboards provide information in both a graphical and numerical way.

nodes should first be correctly configured to send log messages to InCenter. The node configuration steps are described in Section 3.1, Setting Up Monitoring. In addition, a node should also have been added to InCenter and doing this is described in Section 3.1.1, Adding NetWall Nodes with the WebUI. It is not necessary for a node to be under full centralized control by InCenter for monitoring to function.

The No-Logs Message

When trying to display dashboards for the first time, the message shown below might appear to indicate that no log messages are available for dashboard display.

The No-Logs Message

Figure 3.14. The No-Logs Message

The above message appears for one of the following reasons:

  • InCenter aggregates log messages every five minutes and so the first log messages received may not have been aggregated yet. Waiting a few minutes before refreshing the dashboard should resolve this issue.

  • InCenter has not received any logs from any nodes. The actions given in the no-logs message should be followed to troubleshoot this problem.

Dashboard Types

A dashboard can display information for a single node or a summary for multiple nodes. All dashboards are accessed by selecting the Analyze option in the navigation pane and can then be selected by type, as shown below.

Dashboard Type Menu

Figure 3.15. Dashboard Type Menu

Each dashboard provides numeric and graphical summaries of the historical activity for the nodes that have been added to InCenter. Every dashboard has common controls for filtering the information displayed. This filtering can be by:

  • Node

    A particular node can be selected from a drop-down menu.


    Figure 3.16.  Menu

    Multiple nodes can be selected in this way to view the aggregated events from those nodes. The Clear All Filters button can be used to clear all the dashboard filters and return to the default settings.

  • Time Period

    The most recent period of time can be selected from a drop-down list. This period can range from the last 5 minutes to the last 30 days. Note, however, that the default time of keeping log messages is 3 days and only aggregated data is kept for up to 30 days.

    Dashboard Period Selection

    Figure 3.17. Dashboard Period Selection

  • Refresh Interval

    The refresh interval determines how often the dashboard will be automatically refreshed by InCenter. This can be switched off or set at different refresh intervals up to a maximum of one hour.

    Dashboard Refresh Interval

    Figure 3.18. Dashboard Refresh Interval

  • View Mode

    The administrator has a choice of viewing dashboards in a view mode of Fast or Rich. The Fast option makes use of aggregated log message data. The slower Rich option makes use of the raw log message data but also allows drill-down into that data.

    Dashboard View Mode

    Figure 3.19. Dashboard View Mode

    The following should be noted about using these options:

    1. Since the Fast mode relies on aggregated data and because data aggregation by InCenter takes time to complete, using this mode with a short time window of five minutes or less may result in the dashboard display being empty and not showing any node activity.

    2. Log message data is kept for a maximum of 3 days. If the Rich option is selected in conjunction with a time period greater than 3 days, only data from the first 3 days will be displayed. The period beyond the three days will be empty with no indication of activity.

Adding a Filter

It is possible to narrow the log messages being analyzed by adding a filter to a dashboard. This is done by selecting the Add a Filter option. This opens a dialog which allows a field in log messages to be specified along with a string value to match against plus a logical operator that links the two. Below is an example of a filter that specifies only log messages where the source IP address matches are to be included.

Add Dashboard Filter

Figure 3.20. Add Dashboard Filter

Alternatively, it is possible to build complex queries using the query DSL search language by clicking the Edit Query DSL option.

Note that this filter type is not removed if the Remove All Filters button is pressed. Instead, the delete "cross" button on the filter must be pressed to remove it.

3.2.1. Overview Dashboard

When the InCenter interface is first opened, the default Overview dashboard is presented. This is an overall summary of recent activity for all monitored firewalls. This summary can be displayed at any later time by selecting the Overview option.

Overview Option Button

Figure 3.21. Overview Option Button

Below is an example of the information presented by the first part of the summary.

Overview Dashboard Example

Figure 3.22. Overview Dashboard Example

The second part of the summary provides further graphical represenations of the overall node activity plus a tabular summary of the 10 most active active nodes in terms of data volumes.

Continued Overview with Top Nodes by Data Volume

Figure 3.23. Continued Overview with Top Nodes by Data Volume

3.2.2. Network Allowed

The Network Allowed dashboards present an overview of traffic sources that have been allowed by the IP policies of monitored firewalls. An example of the initial dashboard display is shown below.

Network Allowed Dashboard - Overview Example

Figure 3.24. Network Allowed Dashboard - Overview Example

The various tabs in this dashboard present the following information:

  • Applications

    This summarizes the allowed connections that have been processed by application control.

Network Allowed - Applications Dashboard Example

Figure 3.25. Network Allowed - Applications Dashboard Example

  • Network & Policies

    This presents the source IP addresses that were allowed.

Network Allowed - Network Dashboard Example

Figure 3.26. Network Allowed - Network Dashboard Example

  • Web

    This summarizes the types of URLs that were allowed by web content filtering.

Network Allowed - Web Dashboard Example

Figure 3.27. Network Allowed - Web Dashboard Example

  • Log

    This is a list of the log messages received.

Network Allowed - Log Dashboard Example

Figure 3.28. Network Allowed - Log Dashboard Example

3.2.3. Network Denied

The Network Denied dashboards present the sources of traffic that has not been allowed by IP policies. It can be viewed as the opposite of the Networks Allowed dashboards. The tabs also present the denied networks by type, corresponding to the same tabs in the Network Allowed dashboard.

Network Denied Dashboard Example

Figure 3.29. Network Denied Dashboard Example

3.2.4. Threats Unhandled

The Threats Unhandled dashboards are similar to the Threats Denied dashboards but provide an overview of threats that were detected in the "high risk" or "very high risk" categories but which were not blocked.

It may be often desirable to introduce security policies which first audit threats instead of blocking them straight away. This dashboard can give the administrator a way to gauge the effect of changing policies from auditing to blocking.

Threats Unhandled Dashboard Example

Figure 3.30. Threats Unhandled Dashboard Example

3.2.5. Threats Denied

The Threats Denied dashboards present an overview of threats that have been blocked by monitored firewalls. An example is shown below where a time range of 24 hours has been selected.

Threats Denied Dashboard Example

Figure 3.31. Threats Denied Dashboard Example

The following tabs allow a further breakdown of the denied data:

  • Anti-Malware

    This summarizes connections dropped by anti-virus scanning.

  • Botnet

    This summarizes connections dropped by botnet protection.

  • DoS

    This summarizes connections dropped by DoS (denial of service protection).

  • IDP

    This summarizes connections dropped by the intrusion detection prevention (IDP) subsystem.

  • Scanner

    This summarizes connections dropped by scanner protection.

3.2.6. VPN

The VPN dashboards present a summary of activity related to IPsec, L2TP and PPTP tunnels. Selecting one of the protocol specific tabs provides more detailed information about each protocol.

VPN Dashboard Example

Figure 3.32. VPN Dashboard Example

Note that SSL VPN traffic monitoring is covered by Section 3.2.8, OneConnect.

3.2.7. Communication

The Communication dashboard presents a summary of the traffic that is passing through nodes between external hosts and devices. An example of the first part of the communication summary page is shown below.

Communication Dashboard Overview - Summary

Figure 3.33. Communication Dashboard Overview - Summary

The second part of the communication summary page provides a tabular summary of the IP rule set entries that are triggering within nodes in order to allow traffic. Columns within this table provide detailed information on how many connections are being allowed for each listed rule set entry and how much traffic is flowing.

Communication Dashboard Overview - Policies

Figure 3.34. Communication Dashboard Overview - Policies

3.2.8. OneConnect

The OneConnect dashboard presents the activity of users who are connecting to a NetWall node over SSL VPN using the OneConnect client. Below is an example of the first part of the summary for OneConnect.

OneConnect Overall Summary

Figure 3.35. OneConnect Overall Summary

The second part of the summary page presents the top users in terms of connections, failed connections, traffic and session time.

OneConnect Users Summary

Figure 3.36. OneConnect Users Summary

3.2.9. Log Analyzer

The Log Analyzer dashboard presents a summary of the log event messages that InCenter is receiving from configured firewalls. The graph at the top provides a graphical summary of the different categories of logs received.

Log Analyzer Dashboard Example

Figure 3.37. Log Analyzer Dashboard Example

3.3. The Health Display

The Health display for each firewall summarizes the overall health of the node by displaying the recent levels for CPU load, memory usage, data volume and concurrent connections.

The health display is different from dashboards in that the source data is node generated telemetry data that is always sent every 5 minutes, regardless of what configuration objects exist in the firewall.

To display the health of any firewall, select the node in the node list and then press the Health button.

Select Health Button

Figure 3.38. Select Health Button

The health display will open up. The screenshots below show examples of the graphs displayed.

Example Health Display - CPU

Figure 3.39. Example Health Display - CPU

Example Health Display - Connections

Figure 3.40. Example Health Display - Connections

Example Health Display - Memory

Figure 3.41. Example Health Display - Memory

Example Health Display - Data

Figure 3.42. Example Health Display - Data

The health display uses machine learning software to track the values of the health telemetry and indicate any anomalies with a red line on the graphs and add these to an anomaly list at the bottom of the page.

An Example Health Anomalies List

Figure 3.43. An Example Health Anomalies List

3.4. CyberSecurity Score

InCenter provides the Clavister CyberSecurity Score option with the monitoring feature of NetWall nodes. This option generates a set of "score" displays which are easily understood, snapshot summaries of the current security status for individual or groups of NetWall nodes, or an overall summary for all monitored nodes.

Scores can be displayed by selecting one of the menu options under the CyberSecurity Score heading in the navigation pane of the InCenter WebUI.

CyberSecurity Score Menu Options

Figure 3.44. CyberSecurity Score Menu Options

Log Data Collection and Score Calculation Frequency

The CyberSecurity Score feature works by calculating score parameters each day at midnight using the previous 24 hours of log messages received from monitored NetWall nodes. In other words, the score information presented by InCenter is a summary of the security status during the previous day. Note that the "midnight" time when the calculations are performed is determined by the time zone used by the InCenter server and not using the timezone in which individual nodes are located.

If InCenter has not yet received sufficient data, it will display the following message when a score display is requested.

The Insufficient Data Message

Figure 3.45. The Insufficient Data Message

The above message may also be displayed when the score display is requested for a particular node that has insufficient data but there is sufficient data for other nodes.

The Overview Option

The score Overview option will provide a summary for all monitored NetWall nodes. Below is an example of a typical summary display for all nodes.

CyberSecurity Score Summary View

Figure 3.46. CyberSecurity Score Summary View

By using the drop-down box on the upper-right, this display can be recalculated for individual nodes or node groups.

On the left side of this display is an alphabetical score between A (the highest level) and F (the lowest). This provides a quick indicator of overall security status.

On the right side is a threat indicator that takes a percentage value between 0 (the lowest threat level) and 100 (the highest threat level). Unlike the other measures which are averages, the threat indicator value is the highest value found among all the nodes or among those that are currently selected.

In between are colored bar meters that provide a score level between A and F for the following individual security categories:

  • Protection

    This score highlights problems due to node configurations. For example, features are disabled leaving the network open for potential attacks. It will also highlight if nodes are not using the latest software version.

  • Health

    This score highlights the health of nodes in terms of performance and connectivity.

  • Behavior

    This highlights threats from internal hosts. If threats are seen from specific nodes then it could be wise to review how these nodes are allowed to communicate on the network.

  • Users

    This highlights identity and authentication issues that may impact the availability. It will also highlight high ratios of non-authenticated traffic, which make it harder to track down the original source of threats.

  • Connections

    This score highlights the level of protection and security on VPN connections

  • Node

    This score highlights the level of protection and security status of nodes.

Under the score display is a list of Top 3 Suggested Improvements which indicates suggested ways that the overall score could be improved.

The Details Option

The Details menu option presents a more detailed view of the score for each node.

The CyberSecurity Score Details View

Figure 3.47. The CyberSecurity Score Details View

An individual node can now be selected to provide a drill-down into the individual indicators that went into how the scores were calculated.

Drill-down of the CyberSecurity Score Details View

Figure 3.48. Drill-down of the CyberSecurity Score Details View

The colored bar on the right side of each indicator gives a measurement for the contribution of that factor to the overall score for that node. A red bar shows that the indicator made a significantly negative contribution and green shows a marginally negative contribution. The indicators are initially ordered with the most negative contributors first. The recommendation is for the administrator to address the most negative indicator first in order to improve the overall score for that node.

Using the Date Picker to See Earlier Scores

When a cybersecurity score is displayed, an earlier average score on a particular day can be displayed by using the date picker. The date picker is a drop-down box above all score displays.

The CyberSecurity Score Date Picker

Figure 3.49. The CyberSecurity Score Date Picker

Clicking the picker presents a day by day calendar which shows historial summary score values. By clicking on a day in the calendar, the complete score details for that day will be displayed.

The CyberSecurity Score Date Picker Calendar

Figure 3.50. The CyberSecurity Score Date Picker Calendar

3.5. Reporting

The Reporting section of the InCenter system allows dashboards to be turned into PDF reports that can be automatically sent to a list of email recipients. The creation of reports can be done at a chosen point in time, either at the beginning of the day, week or month.

To create a new report, select the Configure option from the Reporting menu in the navigation pane. (The Preview option duplicates the information from the dashboard displays.)

Reporting Menu

Figure 3.51. Reporting Menu

Next, press the Add button to define a new report.

Add Report Button

Figure 3.52. Add Report Button

The new report dialog will be displayed. The first information to enter is a name for the report along with selecting the firewalls which will contribute the data for the report. The firewalls must have been previously added to InCenter for them to appear in the drop down list. The list also includes any groups that have been previously defined.

Add Report Dialog - Name

Figure 3.53. Add Report Dialog - Name

In the next part of the dialog, select the dashboards that will be included in this report.

Add Report Dialog - Dashboards

Figure 3.54. Add Report Dialog - Dashboards

Define the frequency that the report will be generated. This can be either at the beginning of each day or each week or each month.

Add Report Dialog - Schedule

Figure 3.55. Add Report Dialog - Schedule

Next, the recipient(s) of the report can be entered as a comma separated list of email addresses along with text for the subject line and text for the email body (the report PDF will be an attachment to emails).

Add Report Dialog - Recipients

Figure 3.56. Add Report Dialog - Recipients

After clicking the Save button at the bottom of the dialog, this report will now appear as one line in the report list and can be edited or deleted at any time.

Reporting List

Figure 3.57. Reporting List

3.6. Alerting

InCenter provides the ability for the administrator to be made aware when certain events occur, including the option to receive alarms for specified events via email. In describing the alerting subsystem. the following terms will be used:

  • Ticket Type

    A ticket type corresponds to a particular log event message that can be generated by a node. All ticket types are predefined in InCenter. Ticket types can be set to a state of either being enabled or disabled. When they are disabled, InCenter will ignore them if they occur. By default, all types are enabled.

  • Ticket

    This collects together all the occurrences of a given ticket type for a given node. When a ticket is created it is initially in an unacknowledged state and must be explicitly acknowledged by the administrator before it moves to an acknowledged state.

  • Alarm

    An alarm consists of an email that is sent when selected ticket types occur.

The alerting feature is managed through the Alerting menu options in the navigation pane, which are shown below.

Alerting Menu Options

Figure 3.58. Alerting Menu Options

When the Ticket Types option is selected, a list of all available ticket types is presented. An example of the first few lines of this list is shown below.

Alerting - Ticket Types List

Figure 3.59. Alerting - Ticket Types List

Each line in the list corresponds to a particular event or ticket type that InCenter will create a ticket for from incoming log messages. The slider on the right allows the administrator to choose if that ticket type should be monitored or not. By default, all ticket types are enabled. The pencil icon on the left indicates an On/Off change that has not yet been activated.

When a monitored event occurs, it is added to the Open Tickets list and the number of unacknowledged tickets in the list is indicated by a number next to the alerts icon in the toolbar.

Alerts Icon with Unacknowledged Tickets

Figure 3.60. Alerts Icon with Unacknowledged Tickets

Displaying the Ticket List

The current ticket list is displayed either by clicking the alters icon in the toolbar or by selecting the Tickets option in the navigation menu. As shown in the example below, the list displays how many times that ticket type's log event has occurred for a given node in the Events column. The Created column shows when the ticket first occurred for that node and the Updated column shows when it last occurred for the node.

Alerting - Open Tickets List

Figure 3.61. Alerting - Open Tickets List

The ticket list can be extensive so filtering is possible by type, severity or node. Below, only the tickets with Medium severity are being selected.

Alerting - Ticket Filters

Figure 3.62. Alerting - Ticket Filters

Each open ticket line corresponds to a given ticket type for a given node. Tickets remain in the Open list until they are acknowledged. This is done by first selecting a line in the Open list to open the Ticket Details dialog. An example of this dialog is shown below.

Alerting - Ticket Details Dialog

Figure 3.63. Alerting - Ticket Details Dialog

By pressing the Acknowledge button, the entire ticket is moved to the Acknowledged list (accessed through the Acknowledged tab). The acknowledged tickets will persist as an historical record for 30 days before being automatically deleted by InCenter.

Unacknowledged Tickets Limit

There is a limit of 1000 unacknowledged tickets across all ticket types and nodes. When this is reached, the oldest unacknowledged ticket will be auto-acknowledged when a new ticket occurs. Similarly, the maximum number of unacknowledged tickets across all ticket types and nodes is 1000. When the maximum is reached, the oldest acknowledged ticket is deleted when a new ticket acknowledgement occurs.

Viewing Log Messages

The Events link in the dialog shown above allows the administrator to view the individual received log messages that caused the event count for this ticket type and this node to be incremented. However, not all logs may be saved by InCenter. Some may be discarded when they duplicate previous log events or do not add extra information to them.

Alerting - Ticket Details Events

Figure 3.64. Alerting - Ticket Details Events

The Information link will provide a brief summary description of the ticket type, as shown in the example below.

Alerting - Ticket Details Information

Figure 3.65. Alerting - Ticket Details Information

Setting Up Alarms

If an email is to be sent when a specific event occurs, an alarm can be created by selecting Alarms from the Alerting menu and then pressing the Add button.

Alerting - Adding an Alarm

Figure 3.66. Alerting - Adding an Alarm

The new alarm dialog is then presented. An example of this is shown below.

Alerting - Adding an Alarm Dialog

Figure 3.67. Alerting - Adding an Alarm Dialog

In the above dialog, the administrator can select the ticket types for which alarms are to be generated and the email addresses of the recipients. An email is generated whenever any of the selected tickets occurs and sent to all the recipients.

Note that an alarm is only sent the first time a ticket is generated for a given ticket type and node. In other words, only once per ticket type per node. If that ticket is then acknowledged by the administrator, it becomes possible for the same alarm to be sent again if the same ticket types occurs again.

3.7. Device Monitoring

The Devices menu option presents the available data about the types of user devices which are connecting to all the NetWall nodes being monitored by InCenter. This is achieved by cOS Core performing device fingerprinting on the traffic from from devices as they connect.

Note that the term "device" in the context of InCenter refers to client equipment such as smartphones, tablets and laptop computers. It should be contrasted with the firewalls through which they are connecting which are referred to as "nodes" in InCenter.

This display is accessed via the Devices menu option and then choosing the Details option.

Devices Menu Option

Figure 3.68. Devices Menu Option

The devices that are fingerprinted are only those where the node is acting as a DHCP server to the device (or it is relaying DHCP server traffic to the device). The complete details of how cOS Core fingerprinting functions is discussed further in the Device Intelligence section of the separate cOS Core Administration Guide.

Below is an example of how the detailed device list is displayed.

Devices Details List

Figure 3.69. Devices Details List

Note that each line gets an arbitrary logical name from InCenter, which appears in the Name column. For example, device7. However, this name is used only as a unique identification by InCenter and is not used by the device itself or the node.

A textual description of the Type column icon will appear in a tooltip when hovering the cursor over the icon. An example of this is shown below.

Device Type Icon Tooltip Explanation

Figure 3.70. Device Type Icon Tooltip Explanation

The type classification comes from the Fing™ device database, which cOS Core uses to identify a device.

3.8. NetEye Monitoring

Clavister NetEye is a standalone product that performs high performance virus scanning, which includes SSL inspection. NetEye is available either as a cloud service or running on dedicated local hardware.

InCenter can be used to collect and analyze log messages generated by NetEye but, at this time, only a NetEye cloud instance is capable of sending log messages to an InCenter cloud instance. Both the NetEye cloud instance and associated InCenter cloud instance must be registered to the same MyClavister account.

When NetEye log messages are received by the InCenter server, they are stored in the same way as logs from a Clavister firewall and can be displayed in graphical form using the InCenter WebUI. This display is accessed via the NetEye menu option in the Analyze menu. Below is an example of the WebUI summary display forNetEye.

NetEye Monitoring Overview

Figure 3.71. NetEye Monitoring Overview

Setting Up Log Sending in NetEye

No configuration of InCenter is required in order to process incoming NetEye log messages. However, NetEye itself must be configured to send log messages to InCenter. This is done in the NetEye configuration page of the relevant MyClavister account and is described further in the Neteye Setup chapter of the separate InCenter NetEye Cloud Getting Started Guide.

Chapter 4: Managing Users

Any number of new InCenter user accounts can be created for administration and/or auditing purposes. Having a number of different users can be useful for logging purposes, where the username responsible for an action is included in that action's log message and history entry.

Authentication Methods

The following user authentication methods are available:

  • Authentication with Username/Password Credentials

    This default type of authentication involves the user entering credentials consisting of a username and password combination.

User Access Levels

Every InCenter user has one of the following two values for its AccessLevel property:

  • Administrator

    The user has full system access and can read or change any part of the configuration. InCenter will not allow the number of this type of user to fall below one.

  • Auditor

    The user has no ability to change the configuration or affect the operation of InCenter but has read-only access to the complete configuration.  

The access level does not have a default value so it must be specified for every user that is added to the system. Users that already existed prior to upgrading to a version with the access level feature will automatically get the Administrator level.

Conforming to the User Password Policy

By default, the password length must be not less than 8 characters and must contain at least one upper case, one lower case, one numeric plus one non-alphabetic/non-numeric character.

Simultaneous Access by Multiple Users

It is possible for more than one InCenter user to be logged in at the same time to the same InCenter server instance. It is also possible for the same user to be logged in at the same time from multiple client computers.

In the case of such multiple login sessions by an administrator user, all sessions will see and update the same configuration set. In other words, the changes made in one session will affect all other concurrent sessions.

In the case of an auditor user, they can see the changes being made by an administrator user but cannot activate or otherwise affect such changes.

Disabling Users

By default, a user is enabled. However, it is possible to disable a user account. This means that the user remains in the user database but their credentials will not be recognized at login.

4.1. Managing Users with the WebUI

To display all current system users names in the WebUI, first press the Admin button at the top right of the WebUI display and select Manage Users.

Selecting Manage Users

Figure 4.1. Selecting Manage Users

A list of current users will be presented. To add a new user, press the Add button.

Add User Selection

Figure 4.2. Add User Selection

The new user dialog will now be presented and the new user credentials can be entered.

New User Dialog

Figure 4.3. New User Dialog

In addition, the access level for the user can be set as either Administrator or Auditor.

When the user details have been entered, press the Save button to add the new user.

Unlike other configuration changes, modifying the user database does not require that the change is activated before it is applied. User database changes are applied immediately.

Chapter 5: Node Groups

A node can be assigned membership in a NodeGroup. The group concept provides the ability to apply administrative actions to a group instead of an individual node, where the action will apply to all the nodes within the group

No predefined groups exist in InCenter so they must be defined by the administrator and then assigned to nodes.

The Rules of Using Groups

The following rules should be noted when using groups:

  • A single node can only be a member of a single group.

  • A group can contain other groups.

  • Individual HA members cannot be group members, instead it is the HAPair object that is added and as a consequence the HA members are indirectly included in the group.

  • If a group is deleted, its members become children of any parent group. If there is no parent to the original group then the children will have no group membership after deletion.

5.1. Managing Groups with the WebUI

To define a new Group object, go to Manager > Groups and then press the Add Group button.

Groups Display

Figure 5.1. Groups Display

Press the Add button to bring up the new group dialog. The upper part of this is shown below. It is possible to specify an existing group which will have this new group is a member.

Add Group Dialog

Figure 5.2. Add Group Dialog

In the lower part of the dialog, the individual nodes can be added to the group. Other groups or HA pairs can also be added. With the same dialog, it is also possible to add members to the group from existing groups.

Add Group Members

Figure 5.3. Add Group Members

Appendix A: Third Party Software

The InCenter product makes use of various third party software. A list of all third party software and the associated licenses can be found in a single text file called acknowledgments.txt which is included with each release of the software.

The file can be downloaded by first pressing the About button at the top pane of the display.

The About Button

Figure A.1. The About Button

This displays the About dialog. The acknowledgements button in the dialog can then be pressed to download the acknowledgements file. This is shown in the example screenshot below.

Downloading the Third Party Software File

Figure A.2. Downloading the Third Party Software File

As can be seen in the above screenshot, the About dialog includes the release notes for the version of InCenter that is running. These notes are also displayed automatically after user login if there has been a version upgrade of InCenter since the last login.