Jochen's Blog

DRAFT, wird noch überarbeitet. 11 Aug 2024

Voraussetzungen

Wir starten mit einer vorinstallierten Minimal-Installation von Rocky Linux 9. Zum Zeitpunkt dieses Beitrags ist dies Version 9.4, bereitgestellt auf einem Server von netcup.de. Eine Minimal-Installation ist ideal für Server-Umgebungen, da sie nur die nötigsten Pakete enthält, was den Ressourcenverbrauch minimiert und die Angriffsfläche reduziert.

EPEL-Repository installieren

Das EPEL-Repository (Extra Packages for Enterprise Linux) bietet zusätzliche Softwarepakete, die in den Standard-Repositories nicht enthalten sind. Obwohl wir das EPEL-Repository vielleicht nicht direkt benötigen, enthält es Pakete, die potenziell nützlich sein könnten. Da Zabbix auch im EPEL-Repository vorhanden ist und wir es aus dem offiziellen Zabbix-Repository installieren möchten, werden wir es im EPEL-Repository deaktivieren, um Konflikte zu vermeiden.

Schritt 1: CRB-Repository aktivieren

Zuerst aktivieren wir das CRB-Repository (CodeReady Builder), das zusätzliche Pakete für die Softwareentwicklung bereitstellt:

sudo dnf config-manager --set-enabled crb

Schritt 2: EPEL-Repository installieren

Nun installieren wir das EPEL-Repository:

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

Schritt 3: Zabbix-Pakete im EPEL-Repository deaktivieren

Um sicherzustellen, dass wir nur die Zabbix-Pakete aus dem offiziellen Repository nutzen, müssen wir die entsprechenden Pakete im EPEL-Repository deaktivieren. Dazu bearbeiten wir die Konfigurationsdatei:

sudo vi /etc/yum.repos.d/epel.repo

Füge im Block `[epel]` die folgende Zeile hinzu:

excludepkgs=zabbix*

Das EPEL-Repository sollte jetzt wie folgt aussehen:

[epel]
name=Extra Packages for Enterprise Linux $releasever - $basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever&arch=$basearch&infra=$infra&content=$contentdir
enabled=1
gpgcheck=1
countme=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever
excludepkgs=zabbix*

Fail2Ban installieren und konfigurieren

Bevor wir weitermachen, installieren wir fail2ban, ein Tool, das uns dabei hilft, Brute-Force-Angriffe zu verhindern. Wenn ein neuer Server ins Netz geht, dauert es oft nicht lange, bis er Ziel von automatisierten Angriffsversuchen wird. Fail2Ban erkennt solche Versuche und blockiert die IP-Adressen der Angreifer.

Schritt 1: Installation von Fail2Ban

Installiere fail2ban zusammen mit dem Firewalld-Modul, das es ermöglicht, IP-Adressen direkt in die Firewall-Regeln aufzunehmen:

sudo yum install fail2ban-firewalld -y

Schritt 2: Aktivieren und Starten von Fail2Ban

Nach der Installation aktivieren und starten wir fail2ban mit den Standardeinstellungen:

sudo systemctl enable fail2ban
sudo service fail2ban start

Zabbix-Server installieren

Nun installieren wir das Zabbix-Repository und die notwendigen Komponenten.

Schritt 1: Zabbix-Repository hinzufügen

Füge zuerst das offizielle Zabbix-Repository hinzu:

sudo rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rocky/9/x86_64/zabbix-release-7.0-5.el9.noarch.rpm
sudo dnf clean all

Schritt 2: Zabbix-Komponenten installieren

Installiere nun die notwendigen Pakete für den Zabbix-Server:

sudo dnf install zabbix-server-pgsql zabbix-web-pgsql zabbix-apache-conf zabbix-sql-scripts zabbix-selinux-policy zabbix-agent -y

PostgreSQL 16 installieren und einrichten

Für die Datenbank nutzen wir PostgreSQL 16, um langfristig auf dem neuesten Stand zu bleiben.

Bezüglich möglicher Versionen verweise ich auf https://www.zabbix.com/documentation/current/en/manual/installation/requirements

Schritt 1: PostgreSQL-Repository hinzufügen

Zuerst fügen wir das PostgreSQL-Repository hinzu, um die neueste Version zu installieren:

sudo dnf update -y
sudo dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm -y

Schritt 2: Eingebaute PostgreSQL-Module deaktivieren

Da Rocky Linux standardmäßig mit älteren PostgreSQL-Modulen kommt, deaktivieren wir diese, um Konflikte zu vermeiden:

sudo dnf -qy module disable postgresql

Schritt 3: PostgreSQL 16 installieren

Installiere dann PostgreSQL 16:

sudo dnf install postgresql16-server -y

Schritt 4: PostgreSQL initialisieren und starten

Initialisiere die Datenbank und starte den PostgreSQL-Dienst:

sudo /usr/pgsql-16/bin/postgresql-16-setup initdb
sudo systemctl enable postgresql-16
sudo systemctl start postgresql-16

Schritt 5: Passwort für den postgres-Benutzer festlegen

Der postgres-Benutzer hat standardmäßig kein Passwort, was ein Sicherheitsrisiko darstellt. Setze deshalb ein Passwort:

sudo -u postgres psql

Gib im psql-Interface den folgenden Befehl ein:

\password postgres

Postgresql fragt hierbei 2x nach dem neuen Passwort, dieses merken wir uns am besten in einem Passwortmanager. Nach Eingabe verlassen wir psql wieder mittels

\q

Schritt 6: PostgreSQL-Zugriffsrichtlinien anpassen

Ändere die Authentifizierungsmethode von peer auf md5, um die Sicherheit zu erhöhen:

sudo vi /var/lib/pgsql/16/data/pg_hba.conf

Ersetze die Zeile:

local all all peer

durch:

local all all md5

Lade anschließend PostgreSQL neu:

sudo systemctl reload postgresql-16

Wenn wir uns jetzt mit psql anmelden ist eine Passworteingabe notwendig.

PostgreSQL für Zabbix konfigurieren

Zabbix benötigt eine eigene Datenbank und einen eigenen Benutzer.

Schritt 1: Datenbankbenutzer und Datenbank erstellen

Erstelle den Zabbix-Datenbankbenutzer:

sudo -u postgres createuser --pwprompt zabbix

(Achtung, hier werden wir 2x nach dem Passwort für den Zabbix-Datenbankbenutzer, und danach 1x nach dem Passwort von Postgresql gefragt!)
Erstelle die Zabbix-Datenbank:

sudo -u postgres createdb -O zabbix zabbix

Hier ist wieder das Passwort für den Benutzer Postgresql gefragt.

Schritt 2: Initiales Schema importieren

Importiere das Zabbix-Schema und die initialen Daten:

zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbix

TimescaleDB installieren und konfigurieren

TimescaleDB ist eine Erweiterung für PostgreSQL, die optimierte Funktionen für zeitserienbasierte Daten bietet. Sie ist besonders nützlich für Zabbix, um die Leistung bei der Verarbeitung großer Datenmengen zu steigern.

Grundsätzliche Infos zu der TimescaleDB und Kompatibilitäten findet man hier: https://docs.timescale.com/self-hosted/latest/upgrades/upgrade-pg

Zabbix ist zum aktuellen Zeitpunkt nur bis Version 2.15x freigegeben. (https://www.zabbix.com/documentation/current/en/manual/installation/requirements), neuere Versionen kann man testen, muss dann aber in der zabbix_server.conf Datei die Option „AllowUnsupportedDBVersions“ auf 1 setzen.

Schritt 1: TimescaleDB-Repository hinzufügen

Zuerst installieren wir das TimescaleDB-Repository:

sudo yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-$(rpm -E %{rhel})-x86_64/pgdg-redhat-repo-latest.noarch.rpm

An dieser Stelle müssen wir aufpassen das wir uns nicht die Library libpq aus dem original Repository überschreiben. Wir editieren daher die Datei /etc/yum.repos.d/pgdg-redhat-all.repo und fügen als letzte Zeile zu dem Block [pgdg-common] folgende Zeile ein:

exclude=libpq*

Der Dateiinhalt sollte anschliessend ungefähr wie folgt aussehen:

Anschliessend legen wir das Repositoryfile von Hand an:

sudo tee /etc/yum.repos.d/timescale_timescaledb.repo <<EOL
[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/$(rpm -E %{rhel})/\$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/timescale/timescaledb/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
EOL

Im Anschluss machen wir ein update:

sudo yum update

sudo yum install timescaledb-2-postgresql-16 -y

Schritt 2: Auswählen der richtigen Versionsnummer

Da wir TimescaleDB in einer bestimmten Version wollen, wird es jetzt etwas knifflig.

Um eine bestimmte Version zu installieren, müssen wir als erstes schauen welche Versionen verfügbar sind:

sudo yum --showduplicates list timescaledb-2-postgresql-16 | expand

Die Ausgabe sieht dann ungefähr so aus:

Die letzte Version aus der für Zabbix freigegebenen 2.15.x ist die Version 2.15.3-0.
Wir adressieren diese indem wir die Versionsnummer mit Bindestrich an den Paketnamen anhängen, z.B. „timescaledb-2-postgresql-16-2.15.3-0.el9„.

Jetzt sollten wir prüfen ob es weitere timescaledb abhängige Pakete gibt welche in dieser Version vorliegen sollten:

sudo yum deplist timescaledb-2-postgresql-16-2.15.3-0.el9

Die Ausgabe zeigt uns in diesem Fall das auch der Loader Versionsabhängig ist, wir sollten auch diesen in der passenden Version installiere.

Die „richtige“ Installation lautet daher:

sudo yum install timescaledb-2-postgresql-16-2.15.3-0.el9 timescaledb-2-loader-postgresql-16-2.15.3-0.el9

Jetzt ergibt sich leider das Problem, das bei einem YUM oder DNF Update doch wieder das neuere Paket installiert würde:

Dies gilt es zu verhindern, wir installieren daher das plugin versionlock:

yum install python3-dnf-plugin-versionlock

Mit Versionlock können wir yum jetzt mitteilen das keine höheren Versionen installiert werden sollen:

yum versionlock timescaledb-2-loader-postgresql-16-2.15.*
yum versionlock  timescaledb-2-postgresql-16-2.15.*

Wichtig, wir sollten regelmäßig prüfen ob neuere Versionen in Zabbix zugelassen sind und dann entsprechend updaten. hierzu sind die Befehle

• yum versionlock list (listed alle Einträge)
  • yum versionlock clear (löscht alle Einträge)
• yum versionlock delete package_name (löscht bestimmte Einträge)

hilfreich.

Abhängig von unserer Hardware können wir postgresql/timescaledb jetzt noch bezüglich der Einstellungen optimieren. Starten wir hierzu:

sudo timescaledb-tune --pg-config=/usr/pgsql-16/bin/pg_config

timescaledb-tune installiert das timescaledb modul und schlägt, anhand der vorgefundenen Umgebung, Änderungen an den postgresql parametern vor.

Ich persönlich folge diesen Empfehlungen immer und bestätige alle Änderungen und Anpassungen. Anschliessend benötigen wir noch einmal einen restart von postgresql.

sudo systemctl restart postgresql-16

Installieren wir jetzt die timescaledb extension in unserer Zabbix Datenbank:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

Anschliessend werden die zusätzlichen, fpr zabbix notwendigen, Datenbankinformationen eingespielt:

cat /usr/share/zabbix-sql-scripts/postgresql/timescaledb/schema.sql | sudo -u zabbix psql zabbix

Festlegen der libpq für Zabbix

Mit der Installation von Postgresql 16 hat postgresql auch eigene Libraries installiert, diese befinden sich unter /usr/pgsql-16/lib/.

Leider kommt die vorkompilierte Version des Zabbix-Servers für Postgresql aus dem Zabbix Repository damit nicht klar, sie erwartet die original Library aus dem RockyLinux Repository und gibt daher immer eine Fehlermeldung aus:

Um diesen Fehler zu umgehen müssen wir dem Zabbix-Server vor dem Start mitteilen wo er die Library suchen soll. Zum Glück ist Zabbix-Server über das Alternatives System eingebunden, die Umstellung gestaltet sich daher einfach.

Schritt 1: Wir erstellen eine neue Datei /usr/sbin/zabbix_server_pgsql_wrapper.sh mit folgendem Inhalt:

sudo tee /usr/sbin/zabbix_server_pgsql_wrapper.sh << EOL
#!/bin/bash
export LD_PRELOAD=/lib64/libpq.so.5
/usr/sbin/zabbix_server_pgsql \$*
EOL

Schritt 2: Wir geben der neuen Shelldatei die richtigen Rechte:

chown root.root /usr/sbin/zabbix_server_pgsql_wrapper.sh
chmod u+rwx,g+rx-w,o+rx-w /usr/sbin/zabbix_server_pgsql_wrapper.sh

Schritt 3: Wir hängen unser neues Shell-Script in den Alternatives Mechanismus ein und aktivieren es gleichzeitig.

update-alternatives --install /usr/sbin/zabbix_server zabbix-server /usr/sbin/zabbix_server_pgsql_wrapper.sh 80

Wir können die Konfiguration auch jederzeit ändern bzw. kontrollieren mittels

update-alternatives --config zabbix-server

Wenn wir jetzt Zabbix-Server aufrufen sehen wir das unsere obige Fehlermeldung verschwunden ist:

Abschluss der Zabbix-Server Konfiguration

Es hat sich für mich bewährt die original Konfigurationsdateien in Ruhe zu lassen und nur die Abweichungen in einer extra Datei zu konfigurieren.

sudo echo "Include=/etc/zabbix/zabbix_server_local.conf" >> /etc/zabbix/zabbix_server.conf

sudo echo 'DBPassword=replacemewithpassword' >> /etc/zabbix/zabbix_server_local.conf

Auch weitere Anpassungen werden nur in dieser Datei vorgenommen, analog verfährt man mit dem zabbix_agent oder proxy.
Zum Schluss wird die Datei noch gesichert gegen unberechtigtes Lesen oder verändern:

sudo chmod u+r-w-x,g+r-w-x,o-rwx /etc/zabbix/zabbix_server_local.conf
sudo chown root.zabbix /etc/zabbix/zabbix_server_local.conf

Im Abschluss wird zabbix und der websever neu gestartet und enabled.

sudo systemctl restart zabbix-server zabbix-agent httpd php-fpm
sudo systemctl enable zabbix-server zabbix-agent httpd php-fpm

Wenn sie jetzt von Aussen auf den Webserver zugreifen wollen, so werden sie diesen wahrscheinlich nicht ereichen. Das liegt daran das dieser in der Firwall nicht freigegeben ist, hierzu benötigen wir noch:

sudo firewall-cmd --zone=public --permanent --add-service=http
sudo firewall-cmd --zone=public --permanent --add-service=https
sudo firewall-cmd --reload

Abschluss, gehe auf webseite für weitere konfig https:<<fqdn>>/zabbix, Standartzugang ist Admin/zabbix und sollte SOFORT geändert werden.

Im Standard lässt Zabbix (Version 3.4) 5 Loginversuche zu bevor weitere Logins für 30 Sekunden gesperrt werden.

Wer die entsprechenden Einstellungen in den Konfigurationsdateien sucht wird enttäuscht, man muss an den Sourcecode der WebGUI ran.

Hierzu öffnet man mit einem beliebigen Editor die Datei include/defines.inc.php im WebGUI Verzeichnis, bei mir ist das /usr/share/zabbix/include/defines.inc.php .

Neben vielen anderen interessanten Einträgen die man sich unbedingt mal anschauen sollte interessieren uns hier folgende 2:

define('ZBX_LOGIN_ATTEMPTS', 5);
define('ZBX_LOGIN_BLOCK', 30); // sec

ZBX_LOGIN_ATTEMPTS gibt an wie viele Loginversuche man hat und ZBX_LOGIN_BLOCK wie lange man gesperrt wird.

Nach der Sperrzeit kann man direkt die nächsten 5 Versuche starten ohne das die Sperrzeit z.B. exponential wächst, das sind bei schneller Leitung für ein Script ca. 8 Versuche pro Minute, immerhin fast 500 Versuche pro Stunde und über 11500 pro Tag. Bei einem guten Passwort reicht das um sicher zu sein, aber mir ist das zuviel.

Ich habe bei mir die Werte auf

define('ZBX_LOGIN_ATTEMPTS', 3);
define('ZBX_LOGIN_BLOCK', 3600); // sec

geändert. Das reduziert die Anzahl der Versuche auf 72 pro Tag ohne das ich in der Praxis ein Problem habe (wenn mir beim dritten mal das Passwort nicht eingefallen ist dann weis ich es auch beim fünften mal nicht).

Für den Fall das man sich tatsächlich ausgesperrt hat, aber noch über einen Shellzugang mit Datenbankzugriff verfügt so kann man die Sperre in der Datenbank natürlich wieder löschen.

Beispiel (Zabbix 3.4, postgresql, User Admin):

update users set attempt_ip='',attempt_failed=0,attempt_clock=0 where alias like 'Admin';