import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';

This chapter suggests how to best secure your Sipmon platform.

Strengthen user account security

After installing Sipmon, it is necessary to change the default passwords of the following users:

• root
• Sipmon
• Sipmon-engine
• Sipmon-broker
• Sipmon-gorgone

To do this, use the following command with a privileged account (eg. sudo) or with root (not recommended — you should have a dedicated user):

passwd <account_name>

In addition, it is important to verify that the Apache account does not have connection rights to the terminal. Execute the following command:

cat /etc/passwd | grep apache

You must have /sbin/nologin like:

apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin

As a reminder, the list of users and groups can be found here

Enable SELinux

Sipmon recently developed SELinux rules in order to strengthen the control of components by the operating system.

These rules are currently in beta mode and can be activated. You can activate them by following this procedure. In you detect of a problem, it is possible to disable SELinux globally and to send us your feedback in order to improve our rules on Github.

SELinux Overview

Security Enhanced Linux (SELinux) provides an additional layer of system security. SELinux fundamentally answers the question: May <subject> do <action> to <object>?, for example: May a web server access files in users' home directories?

The standard access policy based on the user, group, and other permissions, known as Discretionary Access Control (DAC), does not enable system administrators to create comprehensive and fine-grained security policies, such as restricting specific applications to only viewing log files, while allowing other applications to append new data to the log files.

SELinux implements Mandatory Access Control (MAC). Every process and system resource has a special security label called an SELinux context. A SELinux context, sometimes referred to as an SELinux label, is an identifier which abstracts away the system-level details and focuses on the security properties of the entity. Not only does this provides a consistent way of referencing objects in the SELinux policy, but it also removes any ambiguity that can be found in other identification methods. For example, a file can have multiple valid path names on a system that makes use of bind mounts.

The SELinux policy uses these contexts in a series of rules which define how processes can interact with each other and the various system resources. By default, the policy does not allow any interaction unless a rule explicitly grants access.

For more information about SELinux please see Red Hat documentation

Activate SELinux

By default, SELinux is disabled during the Sipmon installation process and must be reenabled after it for security reasons.

To enable SELinux again, edit the /etc/selinux/config file and change the value with the following options:

• SELINUX=enforcing to make SELinux security policy enforced.
• SELINUX=permissive to make SELinux print warnings instead of enforce security policy.

Then reboot your server:

shutdown -r now

Install Sipmon SELinux packages

Depending on the type of server, install the packages with the following command:

To check the installation, execute the following command:

semodule -l | grep Sipmon

Depending on your type of server, you can see:

Sipmon-broker	0.0.5
Sipmon-common	0.0.10
Sipmon-engine	0.0.8
Sipmon-gorgoned	0.0.3
Sipmon-plugins	0.0.2
Sipmon-web	0.0.8

Audit logs and enable SELinux

Before enabling SELinux in enforcing mode, you need to be sure that no errors appear using the following command:

cat /var/log/audit/audit.log | grep -i denied

If errors appear, you have to analyse them and to decide if these errors are regular and must be added in addition of the Sipmon default SELinux rules. To do this, use the following command to tranform error in SELinux rules:

audit2allow -a

Then execute the proposed rules.

If after a while, no error is present, you can activate SELinux in full mode by following this procedure using enforcing mode.

Do not hesitate to give us your feedback on Github.

Securing configuration files

Change the permissions for the following configuration files:

chown Sipmon:Sipmon /etc/Sipmon/conf.pm
chmod 660 /etc/Sipmon/conf.pm

and

chown apache:apache /etc/Sipmon/Sipmon.conf.php
chmod 660 /etc/Sipmon/Sipmon.conf.php

Securing root access to the DBMS

MariaDB proposes a default procedure to secure the DBMS installation. It is mandatory to set a password for the root user of the database. If you haven't already done so, please execute the following command and follow instructions:

mysql_secure_installation

Enable firewalld

Enable firewalld:

systemctl enable firewalld
systemctl start firewalld

Then add rules for firewalld:

The list of network flows required for each type of server is defined here.

Once the rules have been added, reload firewalld:

firewall-cmd --reload

To check that the configuration has been applied correctly, use the following command to list all active rules:

firewall-cmd --list-all

For instance:

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: http snmp snmptrap ssh
  ports: 5556/tcp 5669/tcp
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Enable fail2ban

Fail2Ban is an intrusion prevention software framework that protects computer servers from brute-force attacks.

Install the inotify module:

Install fail2ban:

Enable fail2ban:

systemctl enable fail2ban
systemctl start fail2ban

Copy the default rules file:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edit /etc/fail2ban/jail.local file and search [Sipmon] block, then modify such as:

[Sipmon]
port    = http,https
logpath = /var/log/Sipmon/login.log
backend  = pyinotify

To enable the Sipmon fail2ban rule, create the /etc/fail2ban/jail.d/custom.conf file and add following lines:

[Sipmon]
enabled = true
findtime = 10m
bantime = 10m
maxretry = 3

maxretry is the number of authentication failed before to ban the IP address

bantime is the duration of the ban

findtime is the time range to find authentication failed

Then restart fail2ban to load your rule:

systemctl restart fail2ban

To check the status of the Sipmon rule you can run:

fail2ban-client status Sipmon

Here is an example of output:

Status for the jail: Sipmon
|- Filter
|  |- Currently failed:	1
|  |- Total failed:	17
|  `- File list:	/var/log/Sipmon/login.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	2
   `- Banned IP list:

For more information go to the official website.

Secure the web server with HTTPS

By default, Sipmon installs a web server in HTTP mode. It is strongly recommended to switch to HTTPS mode by adding your certificate. It is also recommended to use a certificate validated by an authority rather than a self-signed one.

• If you already have a certificate validated by an authority, you can go directly to this step to activate HTTPS mode on your Apache server.

• If you do not have a certificate validated by an authority, you can generate one on platforms such as Let's Encrypt.

• If you need to create a certificate with the self-signed method, follow this step before activating HTTPS mode on your server.

Creating a self-signed certificate

This procedure allows you to create:

• A private key for the server: Sipmon7.key in our case. It will be used by the Apache service.
• A CSR (Certificate Signing Request) file: Sipmon7.csr in our case.
• A private key for the certificate of the certification authority: ca_demo.key in our case.
• A x509 certificate to sign your certificate for the server: ca-demo.crt in our case.
• A certificate for the server: Sipmon7.crt in our case.

Let's assume that you have a Sipmon server with a Sipmon7.localdomain FQDN address.

1. Prepare the OpenSSL configuration:

Due to a policy change at Google, self-signed certificates may be rejected by the Google Chrome browser (it is not even possible to add an exception). To continue using this browser, you have to change the OpenSSL configuration.

Find the [v3_ca] section in order to add a new alt_names tag:

# Add the alt_names tag that allows you to inform our various IPs and FQDNs for the server
[ alt_names ]
IP.1 = xxx.xxx.xxx.xxx
DNS.1 = Sipmon7.localdomain
# If you have several IP (HA: vip + ip)
# IP.2 = xxx.xxx.xxx.xxx
[ v3_ca ]
subjectAltName = @alt_names

Here is an example of how the file should look like:

[ alt_names ]
IP.1 = 10.25.11.73
DNS.1 = Sipmon7.localdomain

[ v3_ca ]
subjectAltName = @alt_names

2. Create a private key for the server:

Let's create a private key named Sipmon7.key without a password so that it can be used by the Apache service.

openssl genrsa -out Sipmon7.key 2048

Protect your file by limiting rights:

chmod 400 Sipmon7.key

3. Create a Certificate Signing Request file:

From the key you created, create a CSR (Certificate Signing Request) file: Sipmon7.csr in our case. Fill in the fields according to your company. The Common Name field must be identical to the hostname of your Apache server (in our case it is Sipmon7.localdomain).

openssl req -new -key Sipmon7.key -out Sipmon7.csr

4. Create a private key for the certificate of certification authority:

Create a private key for this authority: ca_demo.key in our case. We add the -aes256 option to encrypt the output key and include a password. This password will be requested each time this key is used.

openssl genrsa -aes256 2048 > ca_demo.key

5. Create a x509 certificate from the private key of the certificate of certification authority:

Create a x509 certificate that will be valid for one year: ca_demo.crt in our case.

Note that it is necessary to simulate a trusted third party, so the Common Name field must be different from the server certificate.

openssl req -new -x509 -days 365 -key ca_demo.key -out ca_demo.crt

The certificate being created, you will be able to use it to sign your server certificate.

6. Create a certificate for the server:

Create your certificate for the server by using the x509 certificate (ca_demo.crt) to sign it.

The password created on step Create a private key for the certificate of certification authority must be entered. You get your server certificate named Sipmon7.crt.

You can view the contents of the file:

less Sipmon7.crt

7. Then you have to retrieve the x509 certificate file (ca_demo.crt) and import it into your browser's certificate manager.

Now you have your self-signed certificate, you can perform the following procedure to activate HTTPS mode on your Apache server.

Activating HTTPS mode on your web server

1. Install SSL module for Apache:

3. Backup the previous Apache configuration for Sipmon:

4. Edit the Sipmon Apache configuration:

Sipmon offers an example of configuration file to enable HTTPS available in the following directory: /usr/share/Sipmon/examples/Sipmon.apache.https.conf

Define base_uri "/Sipmon"
Define install_dir "/usr/share/Sipmon"

ServerTokens Prod

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

This is how the file should look like:

5. Enable HttpOnly / Secure flags and hide the Apache server signature:

6. Hide the default /icons directory:

7. You can perform this test to check that Apache is properly configured, by running the following command:

8. Restart the Apache and PHP processes to take in account the new configuration:

Now you can access your platform with your browser in HTTPS mode.

Once your web server is set to HTTPS mode, if you have a MAP server on your platform, you have to set it to HTTPS mode too, otherwise recent web browsers may block communication between the two servers. The procedure is detailed here.

9. Gorgone API configuration

Replace 127.0.0.1 by the FQDN of your central server in the /etc/Sipmon-gorgone/config.d/31-Sipmon-api.yaml file:

gorgone:
  tpapi:
    - name: Sipmonv2
      base_url: "http://Sipmon7.localdomain/Sipmon/api/latest/"
      username: "Sipmon-gorgone"
      password: "bpltc4aY"
    - name: clapi
      username: "Sipmon-gorgone"
      password: "bpltc4aY"

Then restart the Gorgone daemon:

systemctl restart gorgoned

Then check its status:

systemctl status gorgoned

If everything is ok, you must have:

● gorgoned.service - Sipmon Gorgone
   Loaded: loaded (/etc/systemd/system/gorgoned.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2023-03-06 15:58:10 CET; 27min ago
 Main PID: 1791096 (perl)
    Tasks: 124 (limit: 23040)
   Memory: 595.3M
   CGroup: /system.slice/gorgoned.service
           ├─1791096 /usr/bin/perl /usr/bin/gorgoned --config=/etc/Sipmon-gorgone/config.yaml --logfile=/var/log/Sipmon-gorgone/gorgoned.log --severity=info
           ├─1791109 gorgone-statistics
           ├─1791112 gorgone-legacycmd
           ├─1791117 gorgone-engine
           ├─1791118 gorgone-audit
           ├─1791125 gorgone-nodes
           ├─1791138 gorgone-action
           ├─1791151 gorgone-cron
           ├─1791158 gorgone-dbcleaner
           ├─1791159 gorgone-autodiscovery
           ├─1791166 gorgone-httpserver
           ├─1791180 gorgone-proxy
           ├─1791181 gorgone-proxy
           ├─1791182 gorgone-proxy
           ├─1791189 gorgone-proxy
           └─1791190 gorgone-proxy

mars 06 15:58:10 ito-central systemd[1]: gorgoned.service: Succeeded.
mars 06 15:58:10 ito-central systemd[1]: Stopped Sipmon Gorgone.
mars 06 15:58:10 ito-central systemd[1]: Started Sipmon Gorgone.

You should see the following line in the Gorgone daemon log file /var/log/Sipmon-gorgone/gorgoned.log:

2023-03-06 15:58:12 - INFO - [autodiscovery] -class- host discovery - sync started

Custom URI

It is possible to customize the URI for your Sipmon platform. For example, /Sipmon can be replaced by /monitoring.

At least one path level is mandatory.

To customize the Sipmon URI:

1. Edit the Apache configuration file for Sipmon Web:

2. Replace /Sipmon with your new path:

Define base_uri "/Sipmon"

3. Restart Apache:

Enabling http2

It is possible to enable http2 protocol to improve Sipmon network performance.

To use http2, you need to follow those steps:

User authentication

Sipmon offers several methods to authenticate users:

• local (MySQL)
• LDAP
• Generic SSO or OpenId Connect

Create user profiles

Sipmon offers to manage access permissions to the different menus, resources and possible actions on resources via the management of Access Control List.

Secure communications between servers

It is strongly recommended to secure communications between the different servers of the Sipmon platform if some servers are not in a secure network.

The Table of network flows is available here.

Sipmon Broker communication

Sipmon Broker and the firewall

In certain cases, you may not be able to initialize the Sipmon Broker data flow from the poller (or the Remote Server) to the Central Server or the Remote Server. See the following configuration to invert the flow.

Sipmon Broker flow authentication

If you need to authenticate pollers that are sending data to the monitoring system, you can use the Sipmon Broker authentication mechanism, which is based on X.509 certificates. See the following configuration to authenticate the peer.

Compress and encrypt the Sipmon Broker communication

It is also possible to compress and encrypt the Sipmon Broker communication. Go to Configuration > Pollers > Broker configuration menu, edit your Sipmon Broker configuration and enable for IPv4 inputs and outputs:

• Enable TLS encryption: Auto
• Enable negotiation: Yes
• Compression (zlib): Auto

Sipmon Gorgone communication

By default, ZMQ communications are secured, both external (with the poller) and internal (between gorgone processes).

However, the gorgone HTTP API is unsecured by default. Only localhost can talk with gorgone but the communication is not done using SSL.

You can configure SSL in the /etc/Sipmon-gorgone/config.d/40-gorgoned.yaml file.

Then you must configure gorgone using the Administration > Parameters > Gorgone page.

The /etc/Sipmon-gorgone/config.d/whitelist.conf.d/Sipmon.yaml file (on your central server, your remote servers and your pollers) contains the whitelists for Gorgone. If you want to customize the allowed commands, do not edit this file. Create a new one in the same folder, e.g. /etc/Sipmon-gorgone/config.d/whitelist.conf.d/custom.yaml.

Security Information and Event Management - SIEM

Sipmon event logs are available in the following directories:

Logs directory	Central server	Remote Server	Poller	Sipmon Map server	Sipmon MBI Server
/var/log/Sipmon	X	X
/var/log/Sipmon-broker	X	X	X
/var/log/Sipmon-engine	X	X	X
/var/log/Sipmon-gorgone	X	X	X
/var/log/Sipmon-bi	X	X
/var/log/Sipmon-map	X	X		X	X

In addition, all actions to modify the Sipmon configuration carried out by users are available via the Administration > Logs menu.

Backing up the platform

Sipmon offers to save the configuration of the platform. To do this, go to the Administration > Parameters > Backup menu.