2 Best practices voor veilige Zabbix-installatie

Overzicht

Deze sectie bevat de beste praktijken die gevolgd moeten worden om Zabbix op een veilige manier op te zetten.

De hier vermelde praktijken zijn niet vereist voor de werking van Zabbix. Ze worden aanbevolen voor een betere beveiliging van het systeem.

Toegangscontrole

Het principe van minste privilege

Het principe van minste privilege moet te allen tijde worden toegepast voor Zabbix. Dit betekent dat gebruikersaccounts (in de Zabbix-frontend) of procesgebruikers (voor Zabbix-server/proxy of agent) alleen die rechten hebben die essentieel zijn om de beoogde functies uit te voeren. Met andere woorden, gebruikersaccounts moeten te allen tijde worden uitgevoerd met zo min mogelijk rechten.

Bij het implementeren van het principe van minste privilege voor gebruikersaccounts moet rekening worden gehouden met de gebruikerstypen van de Zabbix-frontend. Het is belangrijk om te begrijpen dat hoewel een "Admin" gebruikerstype minder rechten heeft dan het "Super Admin" gebruikerstype, het administratieve machtigingen heeft om de configuratie te beheren en aangepaste scripts uit te voeren.

Veilige gebruiker voor Zabbix-agent

In de standaardconfiguratie delen Zabbix-server- en Zabbix-agent-processen één 'zabbix'-gebruiker. Als u wilt zorgen dat de agent geen toegang heeft tot gevoelige gegevens in de serverconfiguratie (bijvoorbeeld inloggegevens voor de database), moet de agent worden uitgevoerd als een andere gebruiker:

1. Maak een veilige gebruiker aan.
2. Specificeer deze gebruiker in het configuratiebestand van de agent (parameter 'User').
3. Herstart de agent met beheerdersrechten. De rechten zullen worden overgedragen naar de opgegeven gebruiker.

UTF-8-codering

UTF-8 is de enige codering die door Zabbix wordt ondersteund. Het staat bekend om zijn probleemloze werking zonder enige beveiligingsproblemen. Gebruikers dienen zich ervan bewust te zijn dat er bekende beveiligingsproblemen zijn bij het gebruik van sommige andere coderingen.

Paden van Windows-installatieprogramma's

Bij het gebruik van Windows-installatieprogramma's wordt aanbevolen om de standaard paden te gebruiken die door het installatieprogramma worden geboden. Het gebruik van aangepaste paden zonder de juiste rechten kan de beveiliging van de installatie in gevaar brengen.

Zabbix beveiligingsadviezen en CVE-database

Zie Zabbix beveiligingsadviezen en CVE-database.

SSL instellen voor Zabbix-frontend

Op RHEL, installeer het mod_ssl-pakket:

dnf install mod_ssl

Maak een directory voor SSL-sleutels:

mkdir -p /etc/httpd/ssl/private
       chmod 700 /etc/httpd/ssl/private

Maak een SSL-certificaat aan:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/private/apache-selfsigned.key -out /etc/httpd/ssl/apache-selfsigned.crt

Vul de prompts passend in. De belangrijkste regel is degene die het Common Name aanvraagt. Hier moet je de domeinnaam invoeren die je met je server wilt associëren. Je kunt in plaats daarvan het openbare IP-adres invoeren als je geen domeinnaam hebt. We gebruiken in dit artikel example.com.

Country Name (2 letter code) [XX]:
       State or Province Name (full name) []:
       Locality Name (eg, city) [Default City]:
       Organization Name (eg, company) [Default Company Ltd]:
       Organizational Unit Name (eg, section) []:
       Common Name (eg, your name or your server's hostname) []:example.com
       Email Address []:

Bewerk de Apache SSL-configuratie:

/etc/httpd/conf.d/ssl.conf
       
       DocumentRoot "/usr/share/zabbix"
       ServerName example.com:443
       SSLCertificateFile /etc/httpd/ssl/apache-selfsigned.crt
       SSLCertificateKeyFile /etc/httpd/ssl/private/apache-selfsigned.key

Herstart de Apache-service om de wijzigingen toe te passen:

systemctl restart httpd.service

Verharding van de webserver

Zabbix inschakelen op de hoofdmap van de URL

Voeg een virtuele host toe aan de Apache-configuratie en stel een permanente omleiding in voor de document root naar de Zabbix SSL-URL. Vergeet niet example.com te vervangen door de werkelijke naam van de server.

/etc/httpd/conf/httpd.conf
       
       #Voeg de volgende regels toe
       
       <VirtualHost *:*>
           ServerName example.com
           Redirect permanent / https://example.com
       </VirtualHost>

Herstart de Apache-service om de wijzigingen toe te passen:

systemctl restart httpd.service

HTTP Strict Transport Security (HSTS) inschakelen op de webserver

Om Zabbix frontend te beschermen tegen aanvallen waarbij het protocol wordt gedowngraded, raden we aan om een HSTS (HTTP Strict Transport Security) beleid in te schakelen op de webserver.

Bijvoorbeeld, om het HSTS-beleid in te schakelen voor je Zabbix frontend in de Apache-configuratie:

/etc/httpd/conf/httpd.conf

voeg de volgende opdracht toe aan de configuratie van je virtuele host:

<VirtualHost *:443>
          Header set Strict-Transport-Security "max-age=31536000"
       </VirtualHost>

Herstart de Apache-service om de wijzigingen toe te passen:

systemctl restart httpd.service

Enabling Content Security Policy (CSP) on the web server

To protect Zabbix frontend against Cross Site Scripting (XSS), data injection, and similar attacks, we recommend enabling Content Security Policy on the web server. To do so, configure the web server to return the HTTP header.

To enable CSP for your Zabbix frontend in Apache configuration, follow these steps:

1. Locate your virtual host's configuration file:

• /etc/httpd/conf/httpd.conf on RHEL-based systems
• /etc/apache2/sites-available/000-default.conf on Debian/Ubuntu

2. Add the following directive to your virtual host's configuration file:

<VirtualHost *:*>
           Header set Content-Security-Policy: "default-src 'self' *.openstreetmap.org; script-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; img-src 'self' data: *.openstreetmap.org; style-src 'self' 'unsafe-inline'; base-uri 'self'; form-action 'self';"
       </VirtualHost>

3. Restart the Apache service to apply the changes:

# On RHEL-based systems:
       systemctl restart httpd.service
       
       # On Debian/Ubuntu
       systemctl restart apache2.service

Uitschakelen van blootstelling van webserverinformatie

Het wordt aanbevolen om alle handtekeningen van de webserver uit te schakelen als onderdeel van het proces van het verharden van de webserver. De webserver geeft standaard de softwarehandtekening weer:

De handtekening kan worden uitgeschakeld door twee regels toe te voegen aan het configuratiebestand van Apache (als voorbeeld):

ServerSignature Off
       ServerTokens Prod

De PHP-handtekening (X-Powered-By HTTP-header) kan worden uitgeschakeld door het php.ini-configuratiebestand te wijzigen (de handtekening is standaard uitgeschakeld):

expose_php = Off

Het is nodig om de webserver opnieuw op te starten om de wijzigingen in het configuratiebestand toe te passen.

Er kan een extra beveiligingsniveau worden bereikt door gebruik te maken van mod_security (pakket libapache2-mod-security2) met Apache. mod_security maakt het mogelijk om de serverhandtekening te verwijderen in plaats van alleen de versie uit de serverhandtekening te verwijderen. De handtekening kan worden aangepast naar elke gewenste waarde door "SecServerSignature" te wijzigen in de gewenste waarde na het installeren van mod_security.

Raadpleeg de documentatie van je webserver voor hulp bij het verwijderen/wijzigen van softwarehandtekeningen.

Uitschakelen van standaard webserverfoutpagina's

Het wordt aanbevolen om standaard foutpagina's uit te schakelen om informatieblootstelling te voorkomen. De webserver gebruikt standaard ingebouwde foutpagina's:

Standaard foutpagina's moeten worden vervangen/verwijderd als onderdeel van het proces van het verharden van de webserver. De "ErrorDocument"-richtlijn kan worden gebruikt om een aangepaste foutpagina/tekst te definiëren voor de Apache-webserver (als voorbeeld gebruikt).

Raadpleeg de documentatie van je webserver voor hulp bij het vervangen/verwijderen van standaardfoutpagina's.

Verwijderen van de webserver testpagina

Het wordt aanbevolen om de webserver testpagina te verwijderen om informatieblootstelling te voorkomen. Standaard bevat de webroot van de webserver een testpagina genaamd index.html (Apache2 op Ubuntu wordt hier als voorbeeld gebruikt):

De testpagina moet worden verwijderd of ontoegankelijk worden gemaakt als onderdeel van het proces om de webserver te beveiligen.

Stel de X-Frame-Options HTTP-responsheader in

Standaard is Zabbix geconfigureerd met de X-Frame-Options HTTP-responsheader ingesteld op SAMEORIGIN, wat betekent dat inhoud alleen kan worden geladen in een frame met dezelfde oorsprong als de pagina zelf.

Zabbix frontend-elementen die inhoud ophalen van externe URL's (namelijk de URL dashboardwidget) tonen opgehaalde inhoud in een sandbox met alle sandbox-beperkingen ingeschakeld.

Deze instellingen verbeteren de beveiliging van de Zabbix frontend en bieden bescherming tegen XSS- en clickjacking-aanvallen. Super Admins kunnen wijzigingen aanbrengen in de parameters voor iframe sandboxing en X-Frame-Options HTTP-responsheader zoals nodig. Weeg de risico's en voordelen zorgvuldig af voordat u de standaardinstellingen wijzigt. Het volledig uitschakelen van sandboxing of X-Frame-Options wordt niet aanbevolen.

Schrijftoegang tot SSL-configuratiebestand intrekken in Windows

De Zabbix Windows-agent die is gecompileerd met OpenSSL, probeert toegang te krijgen tot het SSL-configuratiebestand in c:\openssl-64bit. De map "openssl-64bit" op schijf C: kan worden aangemaakt door niet-bevoegde gebruikers.

Dus voor het beveiligen van de beveiliging is het nodig om deze map handmatig aan te maken en de schrijftoegang voor niet-beheerdersgebruikers in te trekken.

Houd er rekening mee dat de mappennamen verschillend zullen zijn op 32-bits en 64-bits versies van Windows.

Cryptografie

Het verbergen van het bestand met de lijst van veelvoorkomende wachtwoorden

Om de complexiteit van wachtwoord-brute force-aanvallen te vergroten, wordt voorgesteld om de toegang tot het bestand ui/data/top_passwords.txt te beperken door de webserverconfiguratie aan te passen. Dit bestand bevat een lijst van de meest voorkomende en contextspecifieke wachtwoorden, en wordt gebruikt om gebruikers te weerhouden dergelijke wachtwoorden in te stellen als de parameter Vermijd makkelijk te raden wachtwoorden is ingeschakeld in het wachtwoordbeleid.

Bijvoorbeeld op NGINX kan de bestandstoegang beperkt worden met behulp van de location-directive:

location = /data/top_passwords.txt {
           deny all;
           return 404;
       }

Op Apache kan dit worden gedaan met behulp van een .htaccess-bestand:

<Files "top_passwords.txt">  
         Order Allow,Deny
         Deny from all
       </Files>