Security and Protection#

Your IT documentation is the memory of your organization -- it contains network diagrams, credentials, contract details, and infrastructure knowledge. An attacker who gains access to your CMDB effectively has a blueprint of your entire IT. That is why i-doit deserves the same level of protection as any other critical system.

This article follows the classic protection goals: confidentiality, integrity, availability, authenticity, and authorization. The measures are organized by timing -- before installation, after installation, and during ongoing operation.

Before installation#

Before you install i-doit, you should harden the underlying system. The examples refer to Debian GNU/Linux or Ubuntu but can be adapted to other distributions.

Minimal Operating System#

Install only what is necessary for operation: Apache, PHP, and MariaDB. The less software running, the smaller the attack surface.

1
2
3
4
5

# Show running services:
systemctl list-units --type=service --state=running

# Check open ports:
sudo ss -tulpen

Disable and remove unnecessary services:

1
2
3

# Example: remove printer service
sudo systemctl disable --now cups.service
sudo apt purge cups

The principle of minimalism also applies to Apache and PHP -- disable unnecessary modules:

1
2

sudo a2dismod proxy status
sudo phpdismod xdebug

Less Privileges Is More#

Never work permanently as superuser (root). Use sudo for commands that require root privileges. Services like Apache run under their own users (e.g., www-data) -- this limits the damage if a service is compromised.

Secure SSH#

SSH, alongside Apache, is often the only externally accessible service. The configuration is located at /etc/ssh/sshd_config.

Disable root login:

1

PermitRootLogin no

Set up public key authentication:

1
2

ssh-keygen -t ed25519 -f ~/.ssh/idoit-server -C "admin@company.com"
ssh-copy-id -i ~/.ssh/idoit-server.pub idoitadm@i-doit.example.org

Disable password login (only after key-based login is working!):

1
2

PubkeyAuthentication yes
PasswordAuthentication no

Then restart the SSH service:

1

sudo systemctl restart ssh.service

Updates, Updates, Updates#

Keep the entire system up to date -- this includes i-doit itself, the operating system, and all connected third-party systems. Security vulnerabilities in outdated software are one of the most common attack vectors.

For automatic security updates on Debian/Ubuntu, Unattended Upgrades is a good choice:

1
2

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

Secure MariaDB#

First, run mysql_secure_installation -- this removes test databases, anonymous users, and sets a root password.

Then check the configured users:

1

SELECT user, host FROM mysql.user;

Delete unwanted entries (e.g., wildcards % or external addresses). Only localhost, 127.0.0.1, and ::1 should be allowed. Make sure the default port 3306 is not accessible from the outside.

Secure PHP#

Always keep PHP on the latest patch level. The settings required for i-doit can be found in the system settings. Additional hardening can be achieved via a dedicated configuration file:

1

sudo nano /etc/php/8.2/mods-available/zz_security.ini

1
2
3
4
5
6
7
8

;; Restrict file access to i-doit and temp:
open_basedir = "/var/www/html/:/tmp/"

;; Disable unnecessary functions:
disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority

;; Do not expose PHP version in HTTP headers:
expose_php = Off

Enable:

1
2

sudo phpenmod zz_security
sudo systemctl restart apache2.service

Backup and Restore#

Backups are your last line of defense -- against attacks, human error, and hardware failures. Read the article on backing up and restoring data.

Equally important: Test restores regularly. A backup that cannot be restored is worthless.

Encrypt backups: When backups are stored on external media or in the cloud, encrypt them -- e.g., with gpg:

1

mysqldump -u idoit -p idoit_data | gzip | gpg --symmetric --cipher-algo AES256 -o backup_$(date +%F).sql.gz.gpg

For emergencies, a second, independent instance is recommended -- e.g., an exported VM in OVF format on a USB drive in a fireproof safe.

Transport Encryption (TLS)#

Secure the communication between browser and server with TLS so that credentials and CMDB data are not transmitted in plain text over the network.

Let's Encrypt (Recommended)#

The easiest way to obtain a trusted certificate is Let's Encrypt with the ACME client Certbot:

1
2

sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d cmdb.company.com

Certbot automatically configures Apache and sets up certificate renewal via cronjob. Test the renewal:

1

sudo certbot renew --dry-run

Apache TLS Configuration#

If you use your own certificates, use a modern TLS configuration. Use the Mozilla SSL Configuration Generator for a current configuration tailored to your Apache version.

Example for Apache with security headers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

<IfModule mod_headers.c>
    # Redirect HTTP to HTTPS
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
    # Prevent clickjacking
    Header always set X-Frame-Options "SAMEORIGIN"
    # Prevent MIME sniffing
    Header always set X-Content-Type-Options "nosniff"
    # Restrict referrer
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    # Hide server version
    Header unset Server
</IfModule>

ServerSignature Off
ServerTokens    Prod

<IfModule mod_ssl.c>
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
    SSLHonorCipherOrder     off
    SSLCompression          off
    SSLSessionTickets       off

    SSLUseStapling          on
    SSLStaplingCache        shmcb:/var/run/ocsp(128000)
    SSLStaplingResponderTimeout 5
</IfModule>

<VirtualHost *:443>
    ServerName cmdb.company.com
    DocumentRoot /var/www/html/

    <Directory /var/www/html/>
        Options FollowSymLinks
        AllowOverride All
    </Directory>

    SSLEngine on
    SSLCertificateFile      /etc/letsencrypt/live/cmdb.company.com/fullchain.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/cmdb.company.com/privkey.pem

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# HTTP → HTTPS Redirect
<VirtualHost *:80>
    ServerName cmdb.company.com
    Redirect permanent / https://cmdb.company.com/
</VirtualHost>

Check your configuration with:

• SSL Labs by Qualys -- Evaluate TLS configuration
• securityheaders.io -- Check security headers

Client Certificates#

A step further is securing access via client certificates: not only does the browser verify the server certificate, but the web server also verifies the client. This is a strong additional authentication layer but requires distributing and managing client certificates.

Data Encryption#

Full disk encryption protects against theft. On GNU/Linux, dm-crypt/LUKS is widely used -- many distributions offer this during installation. On Windows, BitLocker and VeraCrypt are available.

This is especially relevant when the hardware is not located in your own data center or when i-doit runs on a laptop.

After installation#

File System Permissions#

Set restrictive file permissions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

cd /var/www/html/

# Give Apache ownership:
sudo chown www-data:www-data -R .

# Restrict to read and execute:
sudo find . -type d -exec chmod 550 {} \;
sudo find . -type f -exec chmod 440 {} \;

# Write permissions only for directories that need them:
for dir in log/ imports/ temp/ upload/; do
    sudo find "$dir" -type d -exec chmod 770 {} \;
done

Before an update, temporarily relax the restrictions:

1
2
3

cd /var/www/html/
sudo find . -type d -exec chmod 775 {} \;
sudo find . -type f -exec chmod 664 {} \;

Secure Passwords#

Set secure passwords for all accounts from the start. The default passwords after installation are publicly known -- change them immediately.

Default Users in i-doit#

The users admin, reader, author, and editor have the password set to the same as the username by default. This is the most important point after installation:

• Change all default passwords
• Create a dedicated person object for each real user
• Archive the default users after setup

Admin Center Password#

You can change the password in the Admin Center under Config or directly in the file src/config.inc.php.

MySQL Users#

1

ALTER USER 'idoit'@'localhost' IDENTIFIED BY 'ASecurePassword!2026';

Also store the new password in the system database:

1
2
3

UPDATE idoit_system.isys_mandator
SET isys_mandator__db_pass = 'ASecurePassword!2026'
WHERE isys_mandator__db_user = 'idoit';

Additionally, update it in src/config.inc.php or in the Admin Center under Config.

Linux Users#

1

passwd

Enable CSRF Protection#

Cross-Site Request Forgery (CSRF) is an attack where a user unknowingly performs actions in i-doit because they clicked a manipulated link. Enable protection in the Admin Center under:

System Settings > Security > CSRF Token > Yes

Two-Factor Authentication#

i-doit offers built-in two-factor authentication (2FA). This requires users to provide an additional code from an authenticator app in addition to their password. Especially recommended for admin accounts and users with write access.

Additional authentication mechanisms can be set up via the Apache web server, e.g., via Single Sign-On (SSO).

Configure Session Timeout#

By default, sessions in i-doit remain active for a very long time. For security-critical environments, you should shorten the session timeout so that forgotten browser windows do not remain open indefinitely.

The setting can be found in the expert settings under session.time -- the value is specified in seconds. A sensible value for production environments is 3600 (1 hour).

Secure the API#

The JSON-RPC API is a powerful tool -- and an attractive attack target. If you use the API, you should secure it specifically:

• Keep the API key secret -- the key grants full access. Treat it like a password.
• Restrict access by IP -- allow API access only from known systems. You can do this via the Apache configuration or a firewall rule:

1
2
3
4

<Location "/src/jsonrpc.php">
    Require ip 192.168.1.0/24
    Require ip 10.0.0.50
</Location>

• Create a dedicated API user -- do not use the admin account for API access. Create a dedicated user with minimal permissions.
• Disable the API if it is not needed -- the add-on can be deactivated in Administration.

Firewall and Network#

Minimize Open Ports#

Every closed port reduces the attack surface. For i-doit, the following ports are typically sufficient:

MariaDB (3306) should never be accessible from the outside.

A simple firewall with ufw:

1
2
3
4
5
6

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 443/tcp
sudo ufw allow 22/tcp
sudo ufw enable

For Apache, there is also the web application firewall mod_security, which detects and blocks attack patterns in HTTP requests.

Firewall Rules for i-doit#

For i-doit to download updates, verify licenses, and use online repositories, the following destinations must be reachable:

Interfaces to Third-Party Applications#

Trusted Network#

• No direct internet access -- place i-doit behind a reverse proxy or in an internal network. Use an HTTP proxy for updates.
• Dedicated admin network -- allow SSH only from the management network so that only the core function (HTTPS) is accessible from the office network.

IPv4 vs. IPv6#

If IPv6 is not used in your network, disable it on the server. If it is used, firewall rules and service configurations must cover both protocols -- a firewall with only IPv4 rules does not protect against IPv6 access.

Security Frameworks#

On GNU/Linux, SELinux and AppArmor provide additional protection against unauthorized actions. They allow you to confine Apache so that it can only access specific directories -- even if an attacker exploits a vulnerability in PHP.

Automatically Block Attacks#

fail2ban analyzes log files and automatically blocks IP addresses after repeated failed login attempts:

1

sudo apt install fail2ban

Pre-configured rules exist for SSH, Apache, and MariaDB. For i-doit itself, you can create a custom rule that detects failed logins in the Apache logs.

Monitoring and Logs#

Monitor the System#

Monitor the system with a network monitoring solution like Checkmk or Nagios. Important metrics:

• CPU and memory utilization
• Available disk space
• Apache and MariaDB processes
• Certificate validity (TLS)
• Backup success

Evaluate Logs#

The i-doit log files are located in the log/ directory of the installation. Evaluate them regularly -- especially after updates and when unexpected behavior occurs.

For automatic log monitoring, Logwatch is suitable:

1

sudo apt install logwatch

Logwatch analyzes logs from Apache, SSH, and other services and sends a daily report via email.

If the system needs to send emails, set up an SMTP relay -- e.g., with msmtp.

Regular Security Audits#

Security is not a one-time project but an ongoing process. Conduct regular audits (e.g., quarterly):

High Availability#

For increased availability, you can run the services on dedicated systems: Apache behind a load balancer, MariaDB in a cluster (e.g., with MaxScale), files in distributed storage.

On a smaller scale, RAID, ECC RAM, and redundant power supplies on different power phases (ideally with a UPS) help.

Further Reading#

• BSI IT-Grundschutz -- Systematic IT security
• Mozilla SSL Configuration Generator -- Generate TLS configurations
• CIS Benchmarks -- Hardening guidelines for operating systems and services