3 Serwer WWW

Przegląd

Ta sekcja zawiera najlepsze praktyki dotyczące bezpiecznej konfiguracji serwera WWW.

Wymuszanie przekierowania głównego URL do Zabbix SSL

W systemach opartych na RHEL dodaj virtual host do konfiguracji Apache (/etc/httpd/conf/httpd.conf) i ustaw stałe przekierowanie dla katalogu głównego dokumentów do adresu URL Zabbix SSL. Zwróć uwagę, że example.com należy zastąpić rzeczywistą nazwą serwera.

# Dodaj linie:

<VirtualHost *:*>
    ServerName example.com
    Redirect permanent / https://example.com
</VirtualHost>

Uruchom ponownie usługę Apache, aby zastosować zmiany:

systemctl restart httpd.service

Włączanie HTTP Strict Transport Security (HSTS) na serwerze WWW

Aby chronić frontend Zabbix przed atakami obniżenia wersji protokołu, zalecamy włączenie polityki HSTS na serwerze WWW.

Aby włączyć politykę HSTS dla frontend Zabbix w konfiguracji Apache, wykonaj następujące kroki:

1. Zlokalizuj plik konfiguracyjny swojego hosta wirtualnego:

  • /etc/httpd/conf/httpd.conf w systemach opartych na RHEL
  • /etc/apache2/sites-available/000-default.conf w Debian/Ubuntu

2. Dodaj następującą dyrektywę do pliku konfiguracyjnego swojego hosta wirtualnego:

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

3. Uruchom ponownie usługę Apache, aby zastosować zmiany:

# On RHEL-based systems:
systemctl restart httpd.service

# On Debian/Ubuntu
systemctl restart apache2.service

Wymuszanie bezpiecznych i SameSite cookies sesji w Zabbix

Podczas konfigurowania Zabbix należy wymusić atrybuty secure i SameSite dla cookies sesji, aby zwiększyć bezpieczeństwo i zapobiegać atakom typu cross-site request forgery (CSRF). Jednak wymuszenie SameSite=Strict może powodować problemy w niektórych scenariuszach, takich jak:

  • Widgety URL na pulpicie wyświetlające komunikat „użytkownik nie jest zalogowany” podczas osadzania iframe z tej samej domeny.
  • Użytkownicy uzyskujący dostęp do pulpitu przez HTTP zamiast HTTPS mogą napotkać problemy z logowaniem.
  • Brak możliwości udostępniania adresów URL do określonych sekcji menu Zabbix lub hostów.

Aby ograniczyć te problemy, użytkownicy powinni mieć możliwość dostosowania polityki SameSite.

1. Bezpieczne cookies

Ustawienie flagi secure zapewnia, że cookies są przesyłane wyłącznie przez HTTPS, co zapobiega ich ujawnieniu przez niezaszyfrowane połączenia.

Aby włączyć bezpieczne cookies w Zabbix, dodaj lub zmodyfikuj następujące ustawienie w konfiguracji serwera WWW:

Dla Apache:

Header always edit Set-Cookie ^(.*)$ $1;Secure

Dla Nginx:

proxy_cookie_path / "/; Secure";

Upewnij się, że dostęp do frontend Zabbix odbywa się przez HTTPS; w przeciwnym razie cookies z flagą Secure nie będą wysyłane.

2. Konfigurowanie atrybutu SameSite

Ustawienia serwera WWW mogą również wymuszać atrybut SameSite:

Dla Apache:

<IfModule mod_headers.c>
    Header onsuccess edit Set-Cookie (.*) "$1; SameSite=Strict"
</IfModule>

Dla Nginx (wersja 1.19.3+):

proxy_cookie_flags ~ samesite=Strict; # Zastąp ~ przez 'zbx_session', aby zwiększyć precyzję

Włączanie Content Security Policy (CSP) na serwerze WWW

Aby chronić frontend Zabbix przed atakami typu Cross Site Scripting (XSS), wstrzykiwaniem danych i podobnymi zagrożeniami, zalecamy włączenie Content Security Policy na serwerze WWW. W tym celu skonfiguruj serwer WWW tak, aby zwracał nagłówek HTTP.

Poniższa konfiguracja nagłówka CSP dotyczy wyłącznie domyślnej instalacji frontendu Zabbix oraz przypadków, gdy cała zawartość pochodzi z domeny witryny (z wyłączeniem subdomen). Inna konfiguracja nagłówka CSP może być wymagana, jeśli na przykład konfigurujesz widżet URL tak, aby wyświetlał zawartość z subdomen witryny lub domen zewnętrznych, przełączasz się z OpenStreetMap na inny silnik map albo dodajesz zewnętrzny CSS lub widżety. Jeśli używasz metody uwierzytelniania wieloskładnikowego Duo Universal Prompt, pamiętaj, aby dodać „duo.com” do dyrektywy CSP w pliku konfiguracji virtual hosta.

Aby włączyć CSP dla frontendu Zabbix w konfiguracji Apache, wykonaj następujące kroki:

1. Zlokalizuj plik konfiguracji virtual hosta:

  • /etc/httpd/conf/httpd.conf w systemach opartych na RHEL
  • /etc/apache2/sites-available/000-default.conf w Debian/Ubuntu

2. Dodaj następującą dyrektywę do pliku konfiguracji virtual hosta:

<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. Uruchom ponownie usługę Apache, aby zastosować zmiany:

# W systemach opartych na RHEL:
systemctl restart httpd.service

# W Debian/Ubuntu
systemctl restart apache2.service

Wyłączanie ujawniania informacji o serwerze WWW

Aby zwiększyć bezpieczeństwo, zaleca się wyłączenie wszystkich sygnatur serwera WWW.

Domyślnie serwer WWW ujawnia sygnaturę oprogramowania:

Sygnaturę można wyłączyć, dodając następujące parametry do pliku konfiguracyjnego Apache:

ServerSignature Off
ServerTokens Prod

Sygnaturę PHP (nagłówek HTTP X-Powered-By) można wyłączyć, zmieniając plik konfiguracyjny php.ini (domyślnie sygnatura jest wyłączona):

expose_php = Off

Aby zmiany w plikach konfiguracyjnych zostały zastosowane, wymagane jest ponowne uruchomienie serwera WWW.

Dla dodatkowego bezpieczeństwa można użyć narzędzia mod_security z Apache (pakiet libapache2-mod-security2). To narzędzie umożliwia usunięcie sygnatury serwera zamiast usuwania jedynie wersji z sygnatury serwera. Sygnaturę serwera można zmienić na dowolną wartość, ustawiając "SecServerSignature" na żądaną wartość po zainstalowaniu mod_security.

Aby uzyskać pomoc dotyczącą usuwania/zmiany sygnatur oprogramowania, zapoznaj się z dokumentacją swojego serwera WWW.

Wyłączanie domyślnych stron błędów serwera WWW

Aby uniknąć ujawnienia informacji, zaleca się wyłączenie domyślnych stron błędów.

Domyślnie serwer WWW używa wbudowanych stron błędów:

Te domyślne strony błędów należy zastąpić/usunąć. Na przykład dyrektywy „ErrorDocument” można użyć do zdefiniowania niestandardowej strony/tekstu błędu dla serwera WWW Apache.

Aby uzyskać informacje o tym, jak zastąpić/usunąć domyślne strony błędów, zapoznaj się z dokumentacją swojego serwera WWW.

Usuwanie strony testowej serwera WWW

Aby uniknąć ujawnienia informacji, zaleca się usunięcie strony testowej serwera WWW.

Domyślnie katalog główny serwera WWW Apache zawiera testową stronę index.html:

Aby uzyskać informacje o tym, jak usunąć domyślne strony testowe, zapoznaj się z dokumentacją swojego serwera WWW.

Ustaw nagłówek odpowiedzi HTTP X-Frame-Options

Domyślnie Zabbix jest skonfigurowany z parametrem Use X-Frame-Options HTTP header ustawionym na SAMEORIGIN. Oznacza to, że zawartość może być ładowana tylko w ramce, która ma to samo pochodzenie co sama strona.

Elementy frontend Zabbix, które pobierają zawartość z zewnętrznych adresów URL (a mianowicie widżet URL na pulpicie), wyświetlają pobraną zawartość w piaskownicy z włączonymi wszystkimi ograniczeniami sandbox.

Ustawienia te zwiększają bezpieczeństwo frontend Zabbix i zapewniają ochronę przed atakami XSS oraz clickjacking. Użytkownicy Super admin mogą w razie potrzeby zmienić parametry Use iframe sandboxing i Use X-Frame-Options HTTP header. Przed zmianą ustawień domyślnych należy dokładnie rozważyć ryzyko i korzyści. Nie zaleca się całkowitego wyłączania iframe sandboxing ani nagłówka odpowiedzi HTTP X-Frame-Options.

Ukrywanie pliku z listą najczęściej używanych haseł

Aby zwiększyć złożoność ataków brute force na hasła, zaleca się ograniczenie dostępu do pliku ui/data/top_passwords.txt. Plik ten zawiera listę najczęściej używanych oraz specyficznych kontekstowo haseł i uniemożliwia użytkownikom ustawianie takich haseł (jeśli parametr Avoid easy-to-guess passwords jest włączony w polityce haseł).

Aby ograniczyć dostęp do pliku top_passwords.txt, zmodyfikuj konfigurację swojego serwera WWW.

W Apache dostęp do pliku można ograniczyć za pomocą pliku .htaccess:

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

W NGINX dostęp do pliku można ograniczyć za pomocą dyrektywy location:

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