Xenguard® web API
The Xenguard web control panel offers a robust, easy-to-use management platform. This is
the interface you see when you log in to Xenguards web site. The control panel is
written in Python, for fast and easy integration. Use our example code to develop your
own applications. Host the code wherever you like. Use the Xenguard Server as your
front-end web server, or something else.
The Xenguard web interface provides centralized tracking of critical metrics on every
sensor node on your network. With an intuitive GUI, superior analytics, mobile device
support and a powerful integration API, Xenguard provides network security
administrators with a single tool, capable of protecting large-scale and complex
architectures. Network security personnel around the world benefit from the power of
Xenguard in a way that far exceeds any other network security solution. The Xenguard web
interface provides a centralized point to facilitate rapid diagnostics and data
retention, automatically respond to conditions such as hard disc failures, stack
overflows, etc. Alerts of critical conditions are generated -- nodes down, services not
running, overheating, disc failures etc. The data is easy to understand and presented in
graphical form. This eliminates guesswork and speeds resolution of problems because the
situation is proven, allowing management to take decisive action such as resource
provisioning or disabling misbehaving software components. The Xenguard system features
an advanced target data processing engine, which maintains a comprehensive history of
your network traffic for real-time or on-demand analysis.
contacts
A person record contains a list of devices that they own or use (MAC). A person may be
associated with an organization. The Xenguard Server contains integrated contact
management features for single-sign-on (SSO) authentication, authorization, and access
control. Access control groups are used to simplify the delegation of access privileges.
Each user may be placed into one or more access groups access policies are managed
group-wide. The Server makes it easy to generate and maintain authentication credentials
including passwords, SSH keys and TLS certificates. Contacts may be associated with one
or more devices, from which the user may authenticate.
devices
The Xenguard device management area allows you to easily and efficiently manage the
nodes on your network. A device can be a physical or virtual server, a printer, a
switch, PDA, firewall or any other independent network entity. A list of registered
nodes will be presented. You can select specific groups or classes of node to filter the
node list accordingly. The action selector allows you to perform various action against
a list of selected nodes for example start, stop, or reset. Select the desired action
and click the continue button to proceed.
To register a new device, select the create device option from the navigation menu. To
edit the details of a node, click the node's name in the list.
The node group selector allows you to define group membership, for administrative and
access control purposes. When a node is included in a group, any user who is a member of
that group is allowed access to any node belonging to that group. Groups can be used
flexibly to arrange your network resources in whatever way suits you by client, project,
geographic location or any other criteria.
Select a device ID to view details. Here we've chosen a random mobile device from Tim
Horton's. We are always careful to protect personal privacy, so we will remove
information of a potentially sensitive nature. However, in the real world, you simply
can't protect a wireless network without being aware of all the devices that are active,
and being able to identify potential security threats.
The device class indicates how the device is managed.
The device type indicates what kind of device.
The device model identifies the exact model number or name.
The device vendor identifies the organization which made the device.
The device serial uniquely identifies the device. The exact data source used for this
unique identifier varies by device.
The device name is it's host name.
The device role indicates if it is a wireless client (STATION) or an access point (AP).
The device owner identifies the person who uses the device.
The touch indicator identifies devices which have been in very close proximity to a
Xenguard sensor. This will generally be triggered when a device is within 6 feet of a
Xenguard sensor. This feature allows you to quickly tag devices of interest, simply by
touching them.
The current network shows which network the devices is connected to right now.
The time seen stamps indicate the time when the device was first detected by the
Xenguard system, and when the device was last "seen".
The notes field allows users to add informational text to device records.
The OS template selector defines the type of operating system the node runs. Xenguard
uses this to fine-tune it's management functions for different versions of Linux, BSD,
Solaris or Windows. You can create various templates to suit your needs for example you
could have WINDOWS TEST BOX, LAMP SERVER or EXECUTIVE LAPTOP. The selected template is
then used as a skeleton when creating new virtual machines, minimizing the effort
required to deploy nodes to suit various functional roles.
Clusters are groups of nodes which provide a particular service, such as DNS, DHCP or IP
routing. By defining a cluster for a high-availability service such as a corporate web
service, the operator can easily manage large numbers of individual servers from one
central control point.
The Xenguard Server's monitoring engine is used to continuously evaluate the health of
the individual nodes within a cluster. If any one of them fails, it is automatically
removed from the cluster, ensuring the remaining nodes are available to deliver services
to users.
To create a new cluster, select create under clusters in the left navigation menu. Enter
the cluster's name, and select the service type that the cluster provides. To modify a
cluster, click it's name in the list. Select the appropriate role for each available
node in the cluster. Depending on your cluster type (master/slave versus multi-master),
nodes can be members (equal participants), masters or slaves.
The devices tab provides a device-oriented view of your network. Xenguard is the perfect
tool for monitoring the health of your wireless network, and rapidly diagnosing problems
when they emerge.
The time selector allows you to choose the time window in which devices have been
active.
The role selector lets you select between mobile devices, and access points. Here we've
chosen STATION (mobile devices).
The search box allows you to easily locate devices on a specific network of interest.
Here we've selected Starbucks WiFi. The system shows us all devices which are currently
connected to that network. In general you can enumerate an organization's entire
wireless network just by typing in it's name.
Click the network name to get full details on that particular network (including all
devices which have ever connected to that network).
The device list is color-coded by class, allowing you to easily notice devices of
interest. Here we've detected a potential threat device on the Starbucks network. The
Xenguard system can detect various threat activities including web sites visited, apps
installed, networks visited and so on. By defining triggers, you can automatically
classify different groups of mobile devices based on their properties or online
activities. In this particular case, the device is marked as a threat because it cannot
be properly identified -- someone probably wants to hide from us. Despite the best
efforts of hackers, the Xenguard system generally provides enough information to
accurately identify every device, even one that's been hacked or masqueraded.
project management (ITSM)
The integrated project management tools help you track and manage the resolution of
incidents. Incidents may be assigned to appropriate teams for investigation.
metrics
Metrics are data items that are monitored by the Xenguard system. A metric can be
anything from an SNMP OID to a video camera. Each sensor is associated with a node,
which is the host that the sensor is connected to. Some sensors are real-time (such as
syslog or camera classes), and others are polled (such as web or file classes). A
metric's group indicates which group of contacts owns a sensor who is authorized to
access sensor information and/or manage their configuration. Individual sensors may have
related alerts enabled or disabled (for example, when performing maintenance on a
device). The metrics dialog displays a summary list of configured metrics. Metrics in a
problematic state are highlighted in red. Use the node class and node selector to filter
the sensor list by it's node and node class (server, portable computer). Use the metric
class selector to filter the sensor list by class (SNMP, video etc.) Click the edit
button to make changes to a sensor. Click the name of the metric to access detailed
monitoring statistics. A metric type indicates the sort of data we expect the sensor to
give us. A class of sensors can have one or more sensor types applicable to it for
example memory is applicable to routers, switches, servers and so on. A sensor is
monitored via polls and/or real-time event handling (traps). If a proxy node is defined,
the Xenguard system will conduct probes via this proxy. For example, devices on a
non-routable private network cannot be directly monitored from the internet without an
intermediary host (proxy). Streams are real-time data feeds like cameras and MQTT
subscriptions. Triggers allow you to launch simple or complex operations based on
pre-defined logical conditions. You can define a series of if/then/else parameters which
must be met in order for the trigger to fire. For example, if a customer walks into our
location, and the location is one of our stores, and the customer is female, and the
customers stays ten minutes, then send this e-mail after one hour. A trigger action is a
procedure to be executed when a trigger fires. Xenguard provides a number of scripts
that can be used to easily implement out-of-the-box monitoring of common metrics such as
CPU load, storage device health etc.
Sensors are data sources which are monitored by the Xenguard system. A sensor can be
anything from an SNMP OID to a video camera. Each sensor is associated with a node,
which is the host that the sensor is connected to. Some sensors are real-time (such as
syslog or camera classes), and others are polled (such as web or file classes). A
sensor's group indicates which group of contacts owns a sensor who is authorized to
access sensor information and/or manage their configuration. Individual sensors may have
related alerts enabled or disabled (for example, when performing maintenance on a
device). The sensors dialog displays a summary list of configured sensors. Sensors in a
problematic state are highlighted in red. Use the node class and node selector to filter
the sensor list by it's node and node class (server, portable computer). Use the sensor
class selector to filter the sensor list by class (SNMP, video etc.) Click the edit
button to make changes to a sensor. Click the name of the sensor to access detailed
monitoring statistics. A sensor type indicates the sort of data we expect the sensor to
give us. For example many devices/sensors provide thermal sensors, and many also have
RAM. A class of sensors can have one or more sensor types applicable to it for example
memory is applicable to routers, switches, servers and so on. A sensor is monitored via
polls and/or real-time event handling (traps). If a proxy node is defined, the Xenguard
system will conduct probes via this proxy. For example, devices on a non-routable
private network cannot be directly monitored from the internet without an intermediary
host (proxy). The notes field contains miscellaneous notes about the device. For user
convenience, a number of standard sensor templates are provided for most common types of
sensors.
Events (SIEM)
Events are individual firings of a trigger, detected by the Xenguard Server.
Events are incidents where a non-normal reading has been detected from any of the
system's sensors. Events may be imported to the Xenguard Server directly (for example,
via syslog), or the Xenguard Server will generate events internally when any sensor
registers a non-normal value. Several filtering options are used to select events. The
event class can be problem (a sensor has returned a non-normal value), or recovery (a
sensor has returned to normal value). Each event is associated with one or more nodes
these are the monitoring hosts to which the sensors are connected. Events may be
selected via the sensor class for example syslog, video, or SNMP.
The system log (syslog) facility contains a wealth of valuable information on almost any
device type. Automated syslog event monitoring is an amazingly effective technique! It
can detect disc errors, crashing applications, memory exhaustion, firewall violations
and almost anything worth knowing about a device.
storage
The Xenguard Server offers some basic content management features. Each content item is
assigned a serial number for tracking purposes. Multiple content classes are supported.
Select create content to insert a new content item. Enter the content item's title and
HTML code. Press OK to submit the new content. If a mailing list is defined for the
zone, the content will be automatically sent to that list (see sending mail to a
distribution list).
Maps (GIS)
The Xenguard Server mapping feature gives you a spatial overview of the resources on
your network. Unlike conventional mapping products oriented towards point-to-point
navigation, the Xenguard Server maps provide a real-time view of objects in the
environment printers, sensors, cameras, vehicles, access points, and of course mobile
devices like smart phones and tablets. Data captured by the Xenguard Agent products is
analyzed by the Xenguard Server and presented to the user in the form of a map.
The Xenguard Server mapping feature gives you a spatial overview of the resources on
your network. Unlike conventional mapping products oriented towards point-to-point
navigation, the Xenguard Server maps provide a real-time view of objects in the
environment printers, sensors, cameras, vehicles, access points, smart phones and
tablets. Data captured by the Xenguard Agent products is analyzed by the Xenguard Server
and presented to the user in the form of a map.
Scroll around the map with the mouse. Use the zoom buttons at the top left to zoom in or
out. Data objects are organized in layers, based on the object's characteristics. Use
the pop-out layer selection tool at the top left of the map to select which types of
objects you wish to see.
For demonstration, have marked certain types of vehicle as targets of interest in this
case a specific fleet of Toronto public service vehicles. Amazingly, a handful of
Xenguard sensors is able to track vehicle traffic flows with a high degree of accuracy
and reliability compared to conventional monitoring techniques. A conventional sensor
can tell you how many vehicles pass through a checkpoint, but not where those vehicles
have come from, how frequently they visit and so on.
The system can differentiate different types and models of vehicles. The system can
track public transit, public service, consumer vehicles, drones, cameras, digital
signage, phones, smart watches, printers, tablets and so on.
By clicking on an object, a pop-up appears with an overview about that object its type
and class, when it was first and last seen, who made the device and what state it is in.
Select the details field to access the complete details of the object for example its
model and serial numbers, its travel routes, which networks it has been connecting to,
etc.
You can see what routes are popular at different times of day, where traffic jams have
occurred, which retailers the vehicles visit along the way, where emergency events occur
and so on. Retailers may seek intelligence about where customers are coming from or
going to, at specific times or via specific routes.
Scroll around the map with the mouse. Use the zoom buttons at the top left to zoom in or
out. Data objects are organized in layers, based on the objects characteristics. Use the
pop-out layer selection tool at the top left of the map to select which types of objects
you wish to see.
Now lets look at mobile devices. By selecting the mobile check-box, we see the mobile
device layer as well as the vehicles layer. Were able to see clearly where the main
traffic routes and congestion points are.
For demonstration, have also marked certain types of vehicle as targets of interest in
this case a specific fleet of Toronto public service vehicles. Amazingly, a handful of
Xenguard sensors is able to track vehicle traffic flows with a high degree of accuracy
and reliability compared to conventional monitoring techniques. A conventional sensor
can tell you how many vehicles pass through a checkpoint, but not where those vehicles
have come from, how frequently they visit and so on. The system can differentiate
different types and models of vehicles. The system can track public transit, public
service, consumer vehicles, drones, cameras, digital signage, phones, smart watches,
printers, tablets basically any IoT-enabled device. By clicking on an object, a pop-up
appears with an overview about that object its type and class, when it was first and
last seen, who made the device and what state it is in. Select the details field to
access the complete details of the object for example its model and serial numbers, its
travel routes, which networks it has been connecting to and so on.
|
