이 페이지에서

3 웹 서버

3 웹 서버

개요

이 섹션에는 안전한 방법으로 웹 서버를 설정하기 위한 모범 사례가 포함되어 있습니다.

루트 URL에서 Zabbix SSL로 리다이렉트 강제 설정

RHEL 기반 시스템에서는 Apache 구성(/etc/httpd/conf/httpd.conf)에 가상 호스트를 추가하고 문서 루트에서 Zabbix SSL URL로의 영구 리다이렉트를 설정합니다. example.com은 실제 서버 이름으로 바꾸어야 합니다.

# Add lines:

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

변경 사항을 적용하려면 Apache 서비스를 재시작합니다:

systemctl restart httpd.service

웹 서버에서 HTTP Strict Transport Security (HSTS) 활성화

프로토콜 다운그레이드 공격으로부터 Zabbix 프론트엔드를 보호하려면 웹 서버에서 HSTS 정책을 활성화하는 것을 권장합니다.

Apache 구성에서 Zabbix 프론트엔드에 대한 HSTS 정책을 활성화하려면 다음 단계를 따르세요:

1. 가상 호스트의 구성 파일을 찾습니다:

RHEL 기반 시스템: /etc/httpd/conf/httpd.conf
Debian/Ubuntu: /etc/apache2/sites-available/000-default.conf

2. 가상 호스트의 구성 파일에 다음 지시문을 추가합니다:

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

3. 변경 사항을 적용하기 위해 Apache 서비스를 재시작합니다:

# RHEL 기반 시스템:
systemctl restart httpd.service

# Debian/Ubuntu
systemctl restart apache2.service

Zabbix에서 Secure 및 SameSite 세션 쿠키 적용하기

Zabbix를 구성할 때 보안을 강화하고 사이트 간 요청 위조(CSRF) 공격을 방지하기 위해 세션 쿠키에 secure 및 SameSite 속성을 적용하는 것이 필수적입니다. 하지만 SameSite=Strict를 적용하면 다음과 같은 특정 시나리오에서 문제가 발생할 수 있습니다:

동일 도메인 iframe을 임베드할 때 대시보드 URL 위젯에서 "사용자가 로그인되지 않음" 표시
사용자가 HTTPS 대신 HTTP를 통해 대시보드에 액세스할 때 로그인 문제 발생 가능
특정 Zabbix 메뉴 섹션이나 호스트에 대한 URL 공유 불가능

이러한 문제를 완화하기 위해 사용자는 SameSite 정책을 조정할 수 있는 방법이 있어야 합니다.

1. Secure 쿠키

secure 플래그를 설정하면 쿠키가 HTTPS를 통해서만 전송되어 암호화되지 않은 연결을 통한 노출을 방지할 수 있습니다.

Zabbix에서 secure 쿠키를 활성화하려면 웹 서버 구성에서 다음 설정을 추가하거나 수정하세요:

Apache의 경우:

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

Nginx의 경우:

proxy_cookie_path / "/; Secure";

Zabbix 프론트엔드가 HTTPS를 통해 액세스되는지 확인하세요. 그렇지 않으면 Secure 플래그가 있는 쿠키는 전송되지 않습니다.

2. SameSite 속성 구성

웹 서버 설정에서도 SameSite 속성을 적용할 수 있습니다:

Apache의 경우:

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

Nginx의 경우 (버전 1.19.3+):

proxy_cookie_flags ~ samesite=Strict; # 구체적으로 지정하려면 ~를 'zbx_session'으로 교체

웹 서버에서 Content Security Policy (CSP) 활성화

Cross Site Scripting (XSS), 데이터 주입 및 유사한 공격으로부터 Zabbix 프론트엔드를 보호하려면 웹 서버에서 Content Security Policy를 활성화하는 것이 좋습니다. 이를 위해 HTTP 헤더를 반환하도록 웹 서버를 구성하세요.

다음 CSP 헤더 구성은 기본 Zabbix 프론트엔드 설치 및 모든 콘텐츠가 사이트 도메인(하위 도메인 제외)에서 제공되는 경우에만 해당됩니다. 예를 들어 사이트의 하위 도메인 또는 외부 도메인의 콘텐츠를 표시하도록 URL 위젯을 구성하거나, OpenStreetMap에서 다른 지도 엔진으로 전환하거나, 외부 CSS 또는 위젯을 추가하는 경우 다른 CSP 헤더 구성이 필요할 수 있습니다. Duo Universal Prompt 다단계 인증 방법을 사용하는 경우 가상 호스트의 구성 파일에서 CSP 지시문에 "duo.com"을 추가해야 합니다.

Apache 구성에서 Zabbix 프론트엔드에 대해 CSP를 활성화하려면 다음 단계를 따르세요:

1. 가상 호스트의 구성 파일을 찾으세요:

RHEL 기반 시스템: /etc/httpd/conf/httpd.conf
Debian/Ubuntu: /etc/apache2/sites-available/000-default.conf

2. 가상 호스트의 구성 파일에 다음 지시문을 추가하세요:

<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. 변경 사항을 적용하기 위해 Apache 서비스를 재시작하세요:

# RHEL 기반 시스템:
systemctl restart httpd.service

# Debian/Ubuntu
systemctl restart apache2.service

웹 서버 정보 노출 비활성화

보안 향상을 위해 모든 웹 서버 시그니처를 비활성화하는 것이 권장됩니다.

기본적으로 웹 서버는 소프트웨어 시그니처를 노출하고 있습니다:

Apache 구성 파일에 다음 매개변수를 추가하여 시그니처를 비활성화할 수 있습니다:

ServerSignature Off
ServerTokens Prod

PHP 시그니처(X-Powered-By HTTP 헤더)는 php.ini 구성 파일을 변경하여 비활성화할 수 있습니다(기본적으로 시그니처는 비활성화되어 있습니다):

expose_php = Off

구성 파일 변경사항을 적용하려면 웹 서버를 재시작해야 합니다.

추가적인 보안을 위해 Apache와 함께 mod_security 도구(패키지 libapache2-mod-security2)를 사용할 수 있습니다. 이 도구를 사용하면 서버 시그니처에서 버전만 제거하는 대신 서버 시그니처를 완전히 제거할 수 있습니다. mod_security를 설치한 후 "SecServerSignature"를 원하는 값으로 설정하여 서버 시그니처를 다른 값으로 변경할 수 있습니다.

소프트웨어 시그니처를 제거하거나 변경하는 방법에 대한 도움을 얻으려면 웹 서버 문서를 참조하십시오.

웹 서버 기본 오류 페이지 비활성화

정보 노출을 방지하기 위해 기본 오류 페이지를 비활성화하는 것이 권장됩니다.

기본적으로 웹 서버는 내장된 오류 페이지를 사용합니다:

이러한 기본 오류 페이지는 교체하거나 제거해야 합니다. 예를 들어, Apache 웹 서버의 경우 "ErrorDocument" 지시문을 사용하여 사용자 정의 오류 페이지/텍스트를 정의할 수 있습니다.

기본 오류 페이지를 교체하거나 제거하는 방법에 대한 도움말은 사용 중인 웹 서버의 문서를 참조하시기 바랍니다.

웹 서버 테스트 페이지 제거

정보 노출을 방지하기 위해 웹 서버 테스트 페이지를 제거하는 것이 권장됩니다.

기본적으로 Apache 웹 서버의 webroot에는 index.html 테스트 페이지가 포함되어 있습니다:

기본 테스트 페이지를 제거하는 방법에 대한 도움말은 웹 서버의 문서를 참조하시기 바랍니다.

X-Frame-Options HTTP 응답 헤더 설정

기본적으로, Zabbix는 X-Frame-Options HTTP 헤더 사용 매개변수가 SAMEORIGIN으로 설정되어 구성됩니다. 이는 콘텐츠가 페이지 자체와 동일한 출처를 가진 프레임에서만 로드될 수 있음을 의미합니다.

외부 URL에서 콘텐츠를 가져오는 Zabbix 프론트엔드 요소(즉, URL 대시보드 위젯)는 모든 샌드박싱 제한이 활성화된 샌드박스에서 검색된 콘텐츠를 표시합니다.

이러한 설정은 Zabbix 프론트엔드의 보안을 강화하고 XSS 및 클릭재킹 공격으로부터 보호를 제공합니다. 최고 관리자 사용자는 필요에 따라 iframe 샌드박싱 사용 및 X-Frame-Options HTTP 헤더 사용 매개변수를 수정할 수 있습니다. 기본 설정을 변경하기 전에 위험과 이점을 신중하게 고려하시기 바랍니다. iframe 샌드박싱 또는 X-Frame-Options HTTP 헤더를 완전히 끄는 것은 권장되지 않습니다.

일반적인 비밀번호 목록 파일 숨기기

비밀번호 무차별 대입 공격의 복잡성을 높이기 위해 ui/data/top_passwords.txt 파일에 대한 접근을 제한하는 것이 권장됩니다. 이 파일은 가장 일반적이고 상황별 비밀번호 목록을 포함하며, (비밀번호 정책에서 추측하기 쉬운 비밀번호 방지 매개변수가 활성화된 경우) 사용자가 그러한 비밀번호를 설정하는 것을 방지합니다.

top_passwords.txt 파일에 대한 접근을 제한하려면 웹 서버 구성을 수정하세요.

Apache에서는 .htaccess 파일을 사용하여 파일 접근을 제한할 수 있습니다:

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

NGINX에서는 location 지시어를 사용하여 파일 접근을 제한할 수 있습니다:

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

다음 단계는?

2 Configuration best practices