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