Difference between revisions of "Pandora: Documentation en: Recon Server"

From Pandora FMS Wiki
Jump to: navigation, search
Line 82: Line 82:

Revision as of 09:30, 13 June 2017

Go back to Pandora FMS documentation index

1 Automatic Network Discovery by a Recon Server

1.1 Introduction

The Pandora FMS Recon Server was introduced the first time in version 1.3. Henceforth, it had received several updates and improvements. The Recon Server was created to explore the network by using ICMP (Ping) by user-defined tasks in order to find new systems which are getting identified by their IP address. Subsequently, they're added to the supervision by using the 'plugin templates' to assign modules automatically to the new agent. In this way, a new system is absorbed and a new set of network modules get assigned to it in order to be monitored by itself.

It's important to add that the Recon Server utilizes the IP address in order to identify which agents are already supervised by Pandora FMS. This is the reason for why the Pandora FMS 1.3 agents were able to hold more than one IP address.

The Recon Server also allows to detect the topology of the newly discovered systems by adding these systems to the last known host to the new host in the path of Pandora FMS. It also identifies all the intermediate hosts by their IPs, defining the father of the new monitored system as the last known host before moving on to the new system.

The Recon Server sets up a system for Operating System detection by using 'Xprobe2' (if installed) along with an optional detection of open ports (via NMAP), which allows to identify and recognize any specific system (e.g. 'Solaris with port 23 open' or 'Windows with ports 139 and 445 open').

1.2 Recon Tasks

Template warning.png

Before defining a new Recon Task, you're required to have a Recon Server started on the system. To be able to assign new agents to a network server automatically, you're also required to start a Network Server before doing so.


All Recon Tasks are defined in Servers -> Recon task.


You may create a new task on the screen by clicking on 'Create'. You may also edit already existing ones by clicking on their names:


If you choose to edit or create a new task of network reconnaissance, you're required to fill out the appropriate fields so the task is getting processed properly.

Task Name:
The Name of the discovery task. It's just a descriptive value for being able to distinguish the task in case there are several of them, bearing different filer values or templates.

Recon Server:
The Recon Server which is assigned to the task. If you have several Recon Servers, you're required to select which of them you want to conduct the recon task here.

The task mode to choose between 'network scanning' and 'custom script'. The first mode is the conventional network recognition task, and the second is the manner in which the task is associated to a custom script.

The network in which you want the recognition to be conducted. Please use the network format or bit mask when conducting the recognition. The IP of '' is a class C address which includes all addresses from '' to ''.

The repetition interval of the system's search. It's recommended not to use very short intervals, because the Recon Server explores a network by sending one ping to each address. If you intend to assign very large networks (for example a class A network) in combination with very short intervals (e.g. 6 hours) to the Recon Task, the effect you're going to get is that Pandora FMS will always flood the network with countless pings, thereby straining it and Pandora FMS unnecessarily.

Template warning.png

Successive runs of a recon task may update existing agents and modules. If this is not what you want, set the interval to manual and let the recon task run just once.


Module Template:
The plug-ins template to add the discovered systems. If it detects a system which fits to the parameters for this task (e.g. OS or ports), it's going to register it and assigns all included modules contained in the defined plug-in template.

The operating system to recognize. If you select one instead of 'any', it's only going to add the systems which use this operating system. Under some circumstances, please keep in mind that Pandora FMS can make a mistake when detecting systems. These types of 'guesses' are conducted by statistic patterns, which depend on certain other factors which could sometimes fail (e.g. networks with filters, security software, modified versions of the system). To use this methods safely, it's recommended to have 'Xprobe2' installed on your system.

It's intended to define some specific ports or range, e.g. '22,23,21,80-90,443,8080'. If you use this field, only the detected hosts which have at least one of the mentioned ports open, are going to be detected and added to the system. If one host is detected without at least one of the ports opened, it's going to be ignored. This, along with the 'filter by OS' type of filter allows you to detect the systems that are interesting, e.g. detecting that it's a router, because the ports 23 and 57 are opened. The system therefore recognizes it as a 'BSD' kind of operating system.

It's the group in which it's recommended to add the discovered systems. It's forced to assign the new systems to one group. If it doesn't already have one specific group to locate the unclassified agents assigned, it's recommended to assign it here.

It's intended to define whether to create an incident because of discovering a new system or not. It's going to create one incident for each task - not just one for the detected machine, but to summarize all the newly detected systems. It's going to create it within the predefined group automatically.

SNMP Default Community:
The default SNMP community intended to be used to discover new systems.

Comments: The comments about the network discovery task.

OS Detection:
By using this option, the scan is going to detect the OS.

Name Resolution:
By using this option, the agent will be created by the name of its host computer (if a name was assigned to it). If not, please take the IP address for the agent's name after creating it.

Parent Detection:
By enabling this option, the function is going to detect whether the detected computers are connected to others themselves. If so, they are recognized and created as children during the exploring process.

Parent Recursion:
It indicates the maximum number of recursions with which agents gain the ability of generating parents and children after the completion of the scanning process.


Once you're finished, please click on 'Update' if you intend to edit an already existing task or on 'Create' if you intend to create a new one.

The plug ins and assigned groups to the new host templates in this sweep allow you to conduct a network reconnaissance which explores large networks in hours or just minutes. You're also able to detect and start the monitoring of a complete network by just a few steps.

Once the Recon Task has been defined, it's recommended start it in order to obtain information from your network systems. Do do so, please go to Servers and Manage Servers menu as shown below.


To obtain information about the state of the servers, you may also click on the head element named 'All systems' which is going to lead you to the same window.


The window shown below contains information about the state of the Pandora FMS Servers:


Please look for Recon Server Configuration Details within the console and click on it. You're going to see a window which contains information about the state of the Recon Tasks as shown below.


It's recommended to click on the button on the right of the console to start the Recon Tasks. Once you've done this, the completion is going to take some time.

1.2.1 Network Topology

The Recon Server allows you not just to conduct a discovery of the host organization, but to conduct it in such a way to detect how they are connected to each other. This means: As long as it's well implemented, Pandora FMS is able to detect, monitor and represent its network with accuracy - regardless the number of systems your network consists of.

This is a snapshot of the systems in one of our development servers, which monitors about a 1000 systems by Pandora FMS:

Cool network map sample.jpg

To accomplish this successfully, you need to plan the monitoring by layers, as if it would be an onion. We recommend to conduct this in such a way that the levels which are closer to Pandora FMS are going to be detected first. In order to recognize them, it's going to detect the systems which are behind them. In this way, it could associate them to the already detected modules.

To do so, you're required to create network tasks for the more immediate communication systems and for the following ones, afterwards. Once you have detected the more basic systems, we recommend to create more complex Recon Tasks, based on architectures and systems (by application or by SO), and assign predefined network templates to them, well adapted to the systems it found, e.g. creating a template for web servers which monitor the server state by an advanced TCP checkup, verifying latency time, network response, and monitor service ports such as SSH or FTP. If you have defined any WMI checks or suitable plug ins, you may also add them to it.

If you apply a template which contains a module that isn't applicable to a system detected by the first scan, it's going to be considered 'not started' until it's going to be automatically deleted by the system's daily maintenance script. The modules which have never obtained any data (or were never started at all) are going to be deleted.

1.2.2 Examples of Use

Lets assume for a moment there would be four C type network servers and one B type, hosting several work stations, a plug-in template for any of these five networks will be defined, e.g.:

  • Template Number 1 is used for a Windows Server. It could contain the following five modules:

An SNMP module to learn the CPU usage on the Windows Server.
An SNMP module to learn the available memory on the Windows Server.
An SNMP module to learn the incoming network interface data.
An SNMP module to learn the outgoing network interface data.
An ICMP module to monitor whether it continues working or not.

  • Template Number 2 is used to check the UNIX HTTP Servers:

An ICMP module to monitor whether it continues working or not.
A TCP module to check whether port 80 is working and whether it responds to HTTP commands or not.
A TCP module to check whether port 22 is working and responds to SSH.
An SNMP module to learn about the CPU usage.
An SNMP module to learn about the incoming network interface data.
An SNMP module to learn about the outgoing network interface data.

  • Template Number 3 is used to check the UNIX Oracle Servers:

An ICMP module to check whether it's working or not.
A TCP module to check if a specific TCP port is working and responding to Oracle commands.
A TCP module to check whether a specific port is open or not.
An SNMP module to learn about the CPU usage.
An SNMP module to learn about the available memory.

  • Template Number 4 is used to check CIFS Windows Servers:

An ICMP module to check whether it's working or not.
An SNMP module to learn about the CPU usage.
An SNMP module to learn about the available memory.
Several TCP modules to check whether CIFS is available or not.
An SNMP module to learn about the incoming network interface data.
An SNMP module to learn about the outgoing network interface data.

  • Template number 5 is used to check the activity of all workstations:

An ICMP module to check whether it works or not.
A TCP module to check whether specifically 'forbidden' ports are closed, e.g. 21,22, 80, 8080, 5900, etc.

We recommend to create five supervision tasks: Four for each type of server in each network or subnetwork, assigned to these types of servers. Assign each task to a different group and its network profile to it. The last one is intended for the workstation, assigned to the all the B class devices and other different groups. We also suggest to use a shorter analysis interval (e.g. half a day or one day) for the workstations and a longer one for the servers (two to three days or one week).

The supervision servers use a ICMP internal analyzer to check whether the machine works or not. When an agent gets created, it attempts to resolve the IP address to assign a host name as the name of the agent.

1.3 Recon Scripts

1.3.1 Introduction

The new "ReconScripts" feature allows to conduct the recon in a much more flexible way than the network monitoring and the automatic discovery of the classical Recon Server did before. The Recon Scripts are developed individually along with completely specific targets, such as the network's or the agent's plug ins. Each Recon Script is unique and has only one purpose.

Its basic idea is based on 'detecting' things it recognizes on the system and to automatically establish one certain type of monitoring (network, plug in or WMI), so we're able to e.g. automatically conduct log-in requests on an Oracle database, detect new virtual hosts in a VMware which is managed by 'VirtualCenter' or to detect new requests in a WebLogic Application Server in a completely customized way. The Recon Server is also able to execute a script or application which performs the desired task and to schedule its execution.

All Recon Scripts are customized, very specific and intended for only one technology. We have developed one which is completely Open Source. We call it 'SnmpDevices'. This script can be found in '/usr/share/pandora_server/util/plugin_reconserver/snmpdevices.pl'.

This system allows to check a predefined IP's interval and to create agents for each SNMP system which answers to it (an SNMP community is implied here). It's also going to automatically create some network modules (via SNMP) depending on the results that it obtains. It's going to create the following four SNMP modules for each recognized host:

  • SysUptime: The system's uptime (in seconds since the system started).
  • SysName: The system's name.
  • Local InReceives: The received bytes in the system per second.
  • Local OutRequests: The transmitted bytes from the system per second.

And for each recognized interface (it's going to detect the interface's name automatically), three additional SNMP modules are going to be created within the host:

  • Status: The status (whether it works or not).
  • Inbound Bps: The incoming bytes on the interface per second.
  • Outbound Bps: The outgoing bytes on the interface per second.

1.3.2 Examples of Application

This script could be used in two different ways: By the Pandora FMS Console or by the command line. Application by the Command Line


./snmpdevices.pl <task_id> <group_id> <create_incident_flag> <custom_field1> <custom_field2>


./snmpdevices.pl 3 8 0 community2010

The example above conducts a Recon Task with ID 3 to which it's going to be associated to. The created agents are going to be assigned to the group with ID 8 (Databases). The incident creation has been deactivated by the third parameter ('0'). It's going to check the network under '' by the mask of '24', so the IPs from '' through '' are going to be checked. This example check is going to be performed by the community named 'community2010'. Application by the Pandora FMS Console

The first step to use a Recon Script on the Pandora Console is to go to Servers and Recon Scripts. In this section, we're going to associate all the scripts we want to use by adding the complete script paths one by one.

Recon script1.png

Once the example script has been added, we continue by creating a Recon Task which is going to get associated to it. If we select the 'custom script' mode in the Recon Task creating form, it's recommended to select some common data with a 'normal' Recon Task, e.g. the associated servers, the task execution interval, the group to which the created agents are going to belong to and the incidents and additional comments if they are created.

Apart from this information, it's recommended to configure a series of the script's own parameters, as the script of the previously added ones we intend to use (for us SNMP devices) and the customized fields that we're going to pass along to the script (up to 4).

We also recommend to pass the ID of the already created task to our script automatically. Regarding to the creation of form checks, it's the selected group and the flag which determines whether the incident is going to be created or not. In addition to the four possible customized fields, it's going to use the first two: The first one being the network from where it's going to track and the second one being the device's SNMP community from which we expect the results from.

Recon script2.png 800px

Once the two customized fields have been filled out, and the comments you might want to add, the Recon Task associated to the SNMP device's test script are going to be created. It's going to start the track. The agents and the previously explained modules are also going to be created.

1.3.3 SNMP L2 Recon Script

This script, present on 5.1 and higher versions, relies on SNMP to perform a layer-2 network scan. Routers and switches are queried via SNMP to extract interface and layer-2 information. Hosts which are still disconnected after the layer 2 scan are going to be connected via traceroute.

In order to perform an SNMP layer 2 scan, please create a new recon task, select the custom script called 'SNMP L2 Recon' and fill out the following parameters:

  • Network: A comma-separated list of networks to scan (e.g.,
  • Community: A comma-separated list of SNMP communities to try.
  • Router (optional): The router's IP within the network. It's not mandatory, but it makes it a lot easier to scan the network.
  • Optional Parameter (optional): Please set it to '-a' in order to add all network interfaces (by default, only interfaces which are considered up and running are added).

Snmp l2 recon task.png

In order to display the discovered network, please click on 'Operation' -> 'Network View' -> 'Network Map' and check the 'L2 Network Interfaces' check box.

Snmp l2 network map.png

Template warning.png

If most of the hosts do not respond to SNMP queries the scan will be very slow. For each SNMP community, each host is probed with a timeout of snmp_timeout seconds and snmp_checks retries (both defined in /etc/pandora/pandora_server.conf). With default values and two SNMP communities to be tried this means a delay of 30 minutes for a C class network where no host responds to SNMP queries (2communities x 1retries x 4seconds x 254 hosts). You can lower these values to make the scan faster, but this will affect other SNMP modules too.


1.3.4 WMI Recon Script

This script scans the network for hosts which respond to WMI queries and creates default modules for them.

In order to perform a WMI network scan, please create a new recon task, select the custom script called 'WMI Recon Script' and fill out the following parameters:

  • Network: A comma-separated list of networks to scan (e.g.,
  • WMI Auth: A comma-separated list of WMI authentication tokens in the format 'username%password' (e.g. 'Administrator%pass').

Wmi recon task.png

Go back to the Pandora FMS Documentation Index