Xenguard Server software
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
A person record contains a list of devices that they own or use (MAC). A
person may be associated with an organization.
A MAC address is the physical identifier of a hardware interface. It is associated with one or more ARPs (IP addresses that are
used by the device). Each MAC has a list of other MAC addresses that it has communicated with.
ARPs are locally-detected MAC-to-IP-address mappings. Note that we often cannot obtain an ARP for a remote IP address on
somebody elses network - that is, we dont know the MAC address of the remote IP address (this would generally require a Xenguard
system listening at both ends). When an ARP is detected, this verifies that a particular MAC address is associated with a
particular IP address.
Each IP4 address has a list of peers that it communicates with. We capture time-stamps of the times a particular IP address is
used on a particular subnet. We also gather details about the registered owner of the IP address, and the Autonomous System
Number (ASN) it is associated with.
The Xenguard system captures each of the protocols utilized by a particular IP address (most commonly, TCP, UDP and ICMP).
The Xenguard system captures details on the owner organization for internet ASNs.
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.
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.
High CPU load (over load 1 in most cases) is often a sign of serious
problems with a device and/or bad resource management. While there are
cases where a server will be at 100% utilization continuously for a
considerable duration (cryptography, video rendering), these cases are
rare for general-purpose servers. While > 1 load does not necessarily
mean things are going to blow up, it does mean that functionality to the
users accessing these services is degraded (a load of 5.0 generally
means that processes run at 20% of their normal speed). We recommend
warning on a per-core load over 1.0, and alerting on a per-core load
over 5.0. Memory exhaustion is of course a frequent cause of server
failures. Memory utilization on Linux is actually a bit tricky to
monitor, because of the way it rapidly utilizes memory for I/O caches
(improving performance) but the kernel does give us a sure-fire
indicator of issues swap utilization. There are very complex ways to
control memory utilization and swappiness but in simple terms, the
kernel won't swap until it really needs to (memory needed by user
processes, not I/O caches). So we can simply watch for swap utilization
and trigger at > 1% utilization. It's normal for the swap to be a little
bit allocated but > 1% means that service is degrading and something is
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.
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.
In this example we are viewing vehicles in the busy Toronto 401 highway
at rush hour.
Toronto 401 at rush hour, vehicles only
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
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.
By default, no personally identifiable information is collected by the
Xenguard system. Users must opt-in their devices in order to collect any
personally identifiable information such as Facebook ID, photographs,
e-mail address etc. Once users have opted-in a device, youre able to use
the people layer to track individual persons and organizations. Until a
device has been opted-in by a user, it will appear as a device rather
than a person. For example, a user might register a fleet of vehicles in
the system or a specific group of mobile phones to employees. The user
is then able to track the movements and behaviors of the registered
individuals. End-users may also opt in via mobile portals for example
via in-store marketing campaigns or web sites.