Security Architecture

The security elements of each Pandora FMS component are described, according to regulations such as PCI/DSS, ISO 27001, ENS, LOPD and similar.

In addition, a specific description of the security mechanisms of each Pandora FMS element is included, as well as the possible risks and the way to mitigate them, using the tools available in Pandora FMS or other possible mechanisms.

• Pandora FMS components have documented their input and output ports, so it is possible to secure by means of firewalls all the accesses to and from its components.
• Secure traffic through encryption and certificates: Pandora FMS, at all levels (user operation, communication between components), supports SSL/TLS encryption and certificates at both ends.
• Dual access authentication system: A double authentication system can be implemented. The first, at the access level (HTTPS) integrated with any Opensource or commercial token system.
• Third party authentication system: At the application level, it is managed by Pandora FMS, which can be authenticated against LDAP or Active Directory.
• SSO (Single Sign-On), with SAML.
• Security policies in user management: User management is bounded by policies at both the user profile level and at the operations visibility profile level, defined as the system ACL Extended.
• Possibility of audits on the actions of monitored elements: Pandora FMS audits all user actions, including information about altered or deleted fields. In addition, it includes a signature validation system for these records.
• Transfer of audit data to external log handlers: Audit logs are available for export via SQL and can be integrated into a third source for greater security, in near real time.
• Physical separation of components: They provide an interface to the user and the information containers (filesystem). Both the data stored in the DB and the filesystem that store the monitoring configuration information can be on separate physical machines, in different networks, protected through perimeter systems.
• Active password policy: Enabling to enforce a strict password management policy for access to application users to (Web console).
• Encryption of sensitive data: The system allows the most sensitive data, such as access credentials, to be stored in an encrypted and safe manner.

• The server needs root permissions and can be installed (with limitations) with non root permissions (only on GNU/Linux systems).
• The server needs direct access (read and write) to the agents' remote configuration files, which are propagated when the agents contact the server, periodically. These files are protected by filesystem, with standard permissions.
• The server as such does not listen to any port. It is the Tentacle server which listens on a port, the server only accesses the files that it leaves on disk.
• The server has its own detailed event log.
• The server connects to the main database via a standard MySQL/TCP connection.
• Part of the code can be requested under specific contract conditions (for customers only).

• Unauthorized access to agent configuration files.

Solution: Implement an external secured container for external configuration files, via NFS.

• Insertion of commands in the remote agents through the manipulation of the configuration files stored in the configuration container.

Solution: Disable remote configuration on particularly sensitive agents after configuration and leave them running without being able to alter anything remotely, for absolute security. Remote monitoring - without agents - of the most sensitive devices.

• Vulnerability to information falsification attacks, simulating agents that are not registered in the system or supplanting their identity. To avoid this several mechanisms can be used:

1. Password protection mechanism (which works per group).
2. Limiting the self-creation of agents, and creating them manually.
3. Limiting the ability to auto-detect changes in the agent and not taking new information from the XML to the existing one.

• Malicious capture of communication between server and console (network traffic capture).

Solution: Enable TLS communication between server and MySQL database.

• Tentacle is an official Internet service, documented as such by IANA. This means that it can be easily protected with any perimeter security tool.
• No root user or special privileges are required.
• It has four security levels: No encryption (default), Basic SSL/TLS, SSL/TLS with certificate at both ends, and SSL/TLS with certificate and CA validation (recommended).
• Specifically designed to give no clues to potential intruders in error messages and with specific timeout periods (timeouts) to discourage brute force attacks.
• It has its own audit log.
• 100% of the code is accessible (under Opensource GPL2 license).

• Attacks on filesystem. Access the configuration container.

Solution: It is protected in the same way as the server, by means of a secured external NFS system.

• DoS attacks by overload.

Solutions: Build a HA solution on the TCP service offered for balancing, or an active/active cluster. Any available hardware or software solution is acceptable as it is a standard TCP service.

• It does not require root, it installs with an unprivileged user.
• You must have access to the agent configuration repository (filesystem).
• Listen on standard HTTP or HTTPS ports.
• Logs all requests through HTTP request logging.
• It offers a public API via HTTP/HTTPS, secured with credentials and list of IP addresses allowed in advance.
• There is an application-specific audit, which records the activity of each user on each item in the system.
• Each user's access to any section of the application can be restricted, and even administrators with restricted permissions can be created.
• The application incorporates a double authentication system.
• The application incorporates a delegated authentication system (LDAP, AD).
• A read-only system can be built, without access to device configurations.
• Confidential information (passwords) can be stored in encrypted form in the DB.
• The application connects to the main DB through a standard MySQL/TCP connection.
• Part of the code can be requested under specific contract conditions (for customers only).
• There is a strong implementation of security policies regarding passwords (length, forced change, history, type of valid characters, etc.).

• Attacks on filesystem. The configuration container must be accessed.

Solution: It is protected in the same way as the server, by means of a secured external NFS system.

• Brute force or dictionary attacks against user authentication.

Solutions:

1. Implement a complex password policy.
2. Implement a double authentication mechanism.

• Traffic capture (eavesdropping) of traffic to the console.

Solution: Implement SSL/TLS.

• Traffic capture (eavesdropping) of the traffic to the database.

Solution: Implement SSL/TLS.

• SQL injection attacks to obtain confidential information from the application's DB.

Solution: Implement encrypted data storage.

• Misuse (intentional or unintentional) by users of the application.

Solutions:

1. Activate the audit log and show users that it exists and its accuracy.
2. Activate the extended ACL system to restrict the roles of each user as much as possible.
3. Export the audit log to an external system on a regular basis.

• Execution of malicious code in local console tools, replacing binary files.

Solution: Strengthening (hardening) of the server containing the application.

• It can be run without superuser permissions (with limited features).
• Remote management of the agent can be disabled (locally and remotely), so that the impact of an intrusion on the central system can be minimized.
• The agent does not listen to network ports, it only connects to Pandora FMS server.
• There is a record of each execution.
• Configuration files are protected by default, by means of filesystem permissions. Only a user with super administrator permissions can modify them.
• 100% of the code is accessible (under Opensource GPL2 license).

• Intrusion in the central system that allows distributing execution of malicious commands to the agents.

Solutions:

1. Limit which users may perform these policy or configuration modifications (via ordinary console ACL or extended ACL).
2. Activate the read-only mode (readonly) of the agents (do not allow remote modifications of their configuration), for those particularly sensitive systems.

• Weakness in the filesystem that allows files to be modified.

Solution: Correct permission configuration.

• Execution of plugins or malicious commands.

Solutions:

1. Limit which users may upload executables (though ordinary console ACL or extended ACL).
2. Perform an audit of newplugins.

• It is a standard product (MySQL).

• Eavesdropping (network traffic capture).

Solution: Implementation of a secure TLS connection. MySQL supports it.

• Incorrect permissions.

Solution: Correct configuration of access permissions.

• Known MySQL vulnerabilities: An update plan for the MySQL server should be established in which the server can be kept as up to date as possible, and thus avoid possible vulnerabilities due to having old versions.

System hardening is a key point in a company's overall security strategy.

As manufacturers, we issue a series of recommendations to perform a safe installation of all Pandora FMS components, based on a standard RHEL 8 or Ubuntu server platform.

These same recommendations are valid for any other GNU/Linux based monitoring system.

To access the system, nominative access users will be created, without privileges and with access restricted to the needs they have.

Ideally, each user's authentication should be integrated with a double authentication system based on tokens. There are free and safe alternatives such as Google Authenticator® that can be integrated into GNU/Linux and are beyond the scope of this guide. Seriously consider using them.

If it is necessary to create other users for applications, they must be users without remote access (to do so, disable their Shell or equivalent method).

In case certain users need to have administrator permissions, the sudo command is used.

You only need to be connected to the Internet or configure the dnf or apt system to use a proxy server.

This command can cause potential problems with changing libraries, configurations, and so on. It is important to update the operating system before putting the system into production. If you are overhauling an already active production system, you may only need to upgrade critical components, for example those that have a vulnerability.

For example to upgrade only MySQL on a RHEL system: dnf update mysql-server.

Updating the operating system is a process that should be performed periodically. Vulnerable versions can be queried and emergency updates can be executed by means of the system package inventory.

It is necessary to have the security log /var/log/secure active and monitor those logs with monitoring.

By default this is enabled, if it is not, check the file /etc/rsyslog.conf or /etc/syslog.conf.

It is recommended that the logs of the audit system be carried and collected with an external log management system. Pandora FMS can do it and it will be useful to establish alerts or review them in a centralized way in case of need.

The SSH server allows remote connection to GNU/Linux systems for command execution, so it is a critical point and must be ensured by paying attention to the following points (to do so, edit the file /etc/ssh/sshd_config and then restart the service).

• Modify the default port:

#Port 22     ->     Port 31122

• Disable the login to the superuser root login:

#PermitRootLogin yes        ->    PermitRootLogin no

• Disabling port forwarding:

#AllowTcpForwarding yes        ->    AllowTcpForwarding no

• Disabling tunneling:

#PermitTunnel no        ->    PermitTunnel no

• Remove SSH keys for remote access from root. Assuming that there is only one valid user for remote access (e.g. pfms), if there are others, they should also be checked. To do this, check the contents of the file /home/pfms/.ssh/authorized_keys and check which machines they belong to. Delete it if you think there should be none.

• Set up a standard remote access notice explaining that the server is private access and that anyone without credentials should disconnect:

Banner /etc/issue.net

If MySQL only provides services to an internal element, verify with netstat that it only listens on localhost:

netstat -an | grep 3306 | grep LIST
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN

In the previous example you are listening without restrictions, edit the file /etc/my.cnf, section [mysqld], adding the following line:

bind-address = 127.0.0.1

After restarting the service, check the listening port again.

MySQL password

Connect to the MySQL console with a privileged user:

mysql -h host -u root -p

Verify that the password is complex and that you requested a password. If not, it is set with the command:

mysqladmin password

This security measure is essential to protect databases not only against external attacks but also against misuse by internal users.

ServerTokens Prod

Add the above line to hide the web server version (Apache, Nginx) in the server information headers:

• /etc/httpd/conf/httpd.conf (RHEL).
• /etc/apache2/conf-enabled/pandora_security.conf (Ubuntu server).

To secure the application engine on which Pandora FMS runs, it may be necessary, in some particularly security-sensitive environments, to secure access to the application so that session cookies are only transmitted with SSL.

To do this, the following configuration tokens must be included in the php.ini file:

session.cookie_httponly = 1
session.cookie_secure = 1

This technique, which can be very thorough, consists of removing everything unnecessary on the system. This avoids possible problems in the future with misconfigured applications that are not really needed. To simplify the approach to this practice, consider only those applications that have an open port on the machine, for that run: netstat -tulpn.

Each port should be investigated and the application behind it should be known. To do this you can use the lsof command, which must be installed with dnf or apt.

Those services listening on localhost (127.0.0.1) are safer than those listening to all IP addresses (0.0.0.0.0) and some of them, if they are listening on an open port, you should try to correct them to listen only to localhost.

By means of Pandora FMS process inventory system, it should be verified that no new processes are started over time.

It is recommended to configure system time synchronization on a RHEL system:

dnf install ntpdate
echo "ntpdate 0.us.pool.ntp.org"> /etc/cron.daily/ntp
chmod 755 /etc/cron.daily/ntp

The system should have an Pandora FMS Software Agent installed and executed in PFMS server. For MS Windows® operating system, from version 761 onwards, the installation executables are digitally signed.

The following active checks are recommended in addition to the standard checks:

• Security plugin active.
• Complete system inventory (especially users and installed packages).
• System log collection and security:

module_plugin grep_log_module /var/log/messages Syslog \.\*
module_plugin grep_log_module /var/log/secure Secure \.\*

Once the Software Agent is installed, at least the following information must be manually defined in the agent tab:

• Description.
• IP address (if you have several, enter them all).
• Group.
• Department, responsible and physical location (custom fields).

The official plugin allows to proactively monitor security in the agent, at each execution, almost in real time, offering some checks that can alert of some relevant events.

This plugin is intended to run only on modern GNU/Linux machines. It contains a custom build of John the ripper 1.8 + Contrib patches with static 32-bit and 64-bit binaries. The main concept of the plugin is to be monolithic, detect what can be hardened and try to resolve differences between distributions without asking anything to the administrator, so the deployment could be the same for any system, ignoring versions, distro or architecture.

This plugin will check:

• Auditing user passwords, using the dictionary (provided) with the 500 most common passwords. If you have hundreds of users, you will probably need to customize the plugin to run only every 2 to 6 hours. You may customize the password dictionary by adding your organization's typical password in the “basic_security/password-list” file.
• SSH does not run on the default port.
• SSH does not allow root access.
• That FTP does not run on the default port.
• Check if there is a MySQL server running without the root password defined.
• Other checkups.

Back to Pandora FMS Documentation Index