Don't have an account? Register now!

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 analysis.


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.

CPU load

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 wrong.


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 so on. 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.
Xenguard management system
contact Xenguard
Xenguard services
Xenguard software
Xenguard news
Xenguard library
Copyright © 2019 by Xenguard Corporation. All rights reserved.