3 Serwer WWW

Przegląd

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

Wymuszanie przekierowania adresu URL root do Zabbix SSL

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

# Dodaj wiersze:

<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 polegającymi na obniżeniu wersji protokołu, zalecamy włączenie polityki HSTS na serwerze WWW.

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

1. Znajdź plik konfiguracyjny swojego wirtualnego 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 konfiguracyjnego swojego wirtualnego hosta:

<VirtualHost *:*>
    Header set Strict-Transport-Security "max-age=31536000"
</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

Wymuszanie bezpiecznych i SameSite plików cookie sesji w Zabbix

Podczas konfigurowania Zabbix istotne jest wymuszenie atrybutów secure i SameSite dla plików cookie sesji, aby zwiększyć bezpieczeństwo i zapobiec atakom typu cross-site request forgery (CSRF). Jednak wymuszenie SameSite=Strict może powodować problemy w niektórych scenariuszach, takich jak:

• Widżety URL na pulpicie wyświetlające komunikat "user not logged in" podczas osadzania ramek 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 pliki cookie

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

Aby włączyć bezpieczne pliki cookie 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 frontend Zabbix jest dostępny przez HTTPS; w przeciwnym razie pliki cookie 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; # Replace ~ with 'zbx_session' for specificity

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

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

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

1. Znajdź plik konfiguracyjny swojego wirtualnego 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 konfiguracyjnego swojego wirtualnego 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 poprawić 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 zastosować zmiany w plikach konfiguracyjnych, 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 tylko wersji z sygnatury serwera. Sygnaturę serwera można zmienić na dowolną wartość, ustawiając "SecServerSignature" na wybraną wartość po zainstalowaniu mod_security.

Zapoznaj się z dokumentacją swojego serwera WWW, aby znaleźć informacje o tym, jak usuwać lub zmieniać sygnatury oprogramowania.

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 powinny zostać zastąpione/usunięte. Na przykład dyrektywa "ErrorDocument" może zostać użyta do zdefiniowania niestandardowej strony/tekstu błędu dla serwera WWW Apache.

Aby uzyskać pomoc dotyczącą zastępowania/usuwania domyślnych stron błędów, należy zapoznać 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 stronę testową index.html:

Aby uzyskać pomoc dotyczącą usuwania domyślnych stron testowych, zapoznaj się z dokumentacją swojego serwera WWW.

Ustaw nagłówek 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 ten sam origin co sama strona.

Elementy frontend Zabbix, które pobierają zawartość z zewnętrznych adresów URL (a konkretnie widget URL pulpitu), wyświetlają pobraną zawartość w piaskownicy z włączonymi wszystkimi ograniczeniami piaskownicy.

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

Ukrywanie pliku z listą popularnych 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 dla kontekstu 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;
}