필수 Nginx 보안: 모범 사례 및 문제 해결 FAQ

필수 Nginx 보안은 단일 설정이나 하나의 마법 같은 헤더가 아닙니다. 이는 신중한 기본값들의 모음입니다: HTTPS, 엄격한 파일 접근, 안전한 프록시 동작, 제한된 노출, 그리고 문제가 커지기 전에 발견하는 데 도움이 되는 로그입니다.

이 FAQ는 팀이 Nginx를 온라인에 올린 후 기본 구성이 시작점에 불과하다는 것을 깨달았을 때 일반적으로 묻는 질문들을 다룹니다.

가장 먼저 검토해야 할 Nginx 보안 설정은 무엇인가요?

우발적인 노출을 줄이는 기본 사항부터 시작하세요. 이러한 설정은 고급 공격이 아닌 일반적인 실수로부터 보호합니다.

먼저, 버전 토큰을 비활성화하세요:

server_tokens off;

이렇게 하면 Nginx가 오류 페이지와 헤더에 버전을 표시하지 않습니다. 서버를 완전히 숨기지는 않지만 불필요한 세부 정보를 제거합니다.

둘째, 문서 루트가 올바른지 확인하세요. 일반적인 실수는 root를 공개 빌드 디렉토리 대신 프로젝트 디렉토리로 지정하는 것입니다. 이로 인해 소스 파일, 환경 예제 또는 개인 자산이 노출될 수 있습니다.

정적 사이트의 경우 다음과 같이 설정하는 것이 좋습니다:

root /var/www/example.com/public;

다음과 같이 설정하지 마세요:

root /var/www/example.com;

셋째, 애플리케이션이 실제로 필요로 하지 않는 한 숨김 파일을 차단하세요:

location ~ /\.(?!well-known) {
    deny all;
}

이렇게 하면 인증서 검증에 사용되는 .well-known 경로는 허용하면서 .env, .git, .htpasswd와 같은 파일은 차단합니다.

마지막으로 업로드 제한을 검토하세요. 사이트에서 대용량 업로드를 허용하지 않는 경우 client_max_body_size를 적당히 유지하세요. 이렇게 하면 우발적인 대용량 요청의 피해 범위를 줄일 수 있습니다.

Nginx는 HTTPS를 어떻게 처리해야 하나요?

HTTPS는 공개 웹사이트와 API의 기본 경로여야 합니다. 일반 HTTP를 HTTPS로 리디렉션하고, 유효한 인증서를 사용하며, 오래된 프로토콜 설정을 피하세요.

간단한 리디렉션 서버 블록은 다음과 같습니다:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

HTTPS 서버 블록은 인증서 파일을 참조하고 최신 TLS 설정을 포함해야 합니다. 많은 팀이 Certbot 또는 관리형 로드 밸런서를 사용하여 인증서를 처리합니다. 중요한 점은 갱신을 자동화하고 모니터링하는 것입니다.

보안 헤더는 브라우저가 더 안전한 결정을 내리는 데 도움이 될 수 있습니다:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Content Security Policy는 주의해서 사용하세요. 강력하지만, 테스트 없이 엄격한 정책을 적용하면 스크립트, 글꼴, 분석 도구 또는 임베디드 콘텐츠가 손상될 수 있습니다. 가능하면 보고 전용 모드로 시작하세요.

HTTPS에 대한 실습 안내는 Nginx로 HTTPS 보안 설정하기를 참조하세요.

Nginx를 리버스 프록시로 어떻게 보호하나요?

Nginx가 트래픽을 앱으로 프록시할 때, 클라이언트 입력을 맹목적으로 신뢰하지 않고 올바른 요청 정보를 보존해야 합니다.

일반적인 프록시 헤더는 다음과 같습니다:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

이러한 헤더는 업스트림 애플리케이션이 원래 요청을 이해하는 데 도움이 됩니다. 로깅, 리디렉션, 속도 제한 및 보안 검사에 유용합니다.

Nginx가 다른 신뢰할 수 있는 프록시나 로드 밸런서 뒤에 있는 경우 실제 IP 처리를 신중하게 구성하세요. 알려진 프록시 주소만 신뢰하세요:

set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

공개 인터넷에서 오는 X-Forwarded-For는 신뢰하지 마세요. 클라이언트가 해당 헤더를 위조할 수 있습니다. 요청이 로드 밸런서, CDN 또는 내부 프록시에서 오는 경우에만 신뢰하세요.

또한 업스트림 구현 세부 정보를 숨겨야 합니다. 앱이 필요하지 않은 프레임워크별 헤더를 반환하는 경우 프록시 또는 애플리케이션 계층에서 제거하세요.

속도 제한을 사용해야 하나요?

속도 제한은 로그인 페이지, 검색 엔드포인트, 비용이 많이 드는 API 및 공격자가 저렴하게 남용할 수 있는 모든 경로에 유용합니다. 애플리케이션 보안을 대체하지는 않지만 무차별 대입 시도와 시끄러운 트래픽을 늦출 수 있습니다.

예시:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location /login {
        limit_req zone=login burst=10 nodelay;
        proxy_pass http://app_backend;
    }
}

이렇게 하면 클라이언트 IP를 키로 하는 공유 메모리 영역이 생성되고 로그인 경로에 대한 요청이 제한됩니다. 정확한 값은 사용자에 따라 다릅니다. 기업 대시보드는 일반적으로 모바일 네트워크의 공개 소비자 앱보다 더 엄격한 제한을 견딜 수 있습니다.

속도 제한을 신중하게 테스트하세요. 사이트가 프록시 뒤에 있고 실제 클라이언트 IP 처리를 구성하지 않은 경우 모든 사용자가 동일한 주소에서 오는 것처럼 보일 수 있습니다. 이로 인해 합법적인 트래픽이 차단될 수 있습니다.

여전히 의심스러운 요청이 보이는 이유는 무엇인가요?

공개 Nginx 서버는 지속적인 배경 소음을 받습니다: 오래된 관리자 패널, PHP 파일, WordPress 경로 및 노출된 환경 파일에 대한 스캔입니다. 로그에서 이러한 요청을 본다고 해서 항상 침해당했다는 의미는 아닙니다.

중요한 것은 서버가 어떻게 응답하는지입니다. WordPress가 아닌 사이트에 대한 /wp-admin 요청은 404 또는 403을 반환해야 합니다. /.env에 대한 요청은 절대 비밀을 반환해서는 안 됩니다. 이상한 경로의 요청은 내부 관리 서비스로 프록시되어서는 안 됩니다.

액세스 로그에서 다음을 검토하세요:

반복되는 401 또는 403 응답
하나의 IP에서 많은 요청
큰 요청 본문
숨김 파일 탐색
비정상적인 사용자 에이전트
499, 502 또는 504 응답의 급증

광범위한 문제 해결은 Nginx 일반 오류를 참조하세요.

보안 도움을 요청해야 할 때

Nginx가 고객 데이터, 인증, 결제 흐름, 개인 API 또는 내부 관리 도구를 보호할 때 보안 엔지니어나 경험이 풍부한 DevOps 컨설턴트를 참여시키세요. 또한 침해가 의심되거나, 예상치 못한 파일 노출이 발생하거나, 가용성에 영향을 미치는 반복적인 공격 트래픽이 있을 때 도움을 받아야 합니다.

구성이 CDN, 로드 밸런서, Nginx, 서비스 메시 및 애플리케이션 프레임워크와 같은 여러 계층에 걸쳐 있을 때 전문가 검토가 가치 있습니다. 안전한 Nginx 파일도 다른 곳의 잘못된 신뢰 경계로 인해 약화될 수 있습니다.

불필요한 노출을 제거하고, HTTPS를 강제하며, 프록시 헤더를 신중하게 처리하고, 로그를 모니터링하여 Nginx를 안전하게 유지하세요. 더 안전해지기 위해 거대한 구성이 필요하지 않습니다. 명확한 기본값, 테스트된 변경 사항 및 서버가 실제로 제공하는 것을 확인하는 습관이 필요합니다.