배포 직전 서버 점검에서 자주 빠지는 항목이 응답에 남아 있는 서버 정보입니다. Server 헤더에 nginx/1.18.0 같은 버전이 그대로 보이기도 하고, 존재하지 않는 경로를 요청하면 에러 페이지 하단에 같은 정보가 다시 나오기도 합니다. 공격자는 이 정보를 보고 해당 버전의 알려진 취약점을 먼저 떠올리므로, 노출 범위를 줄이는 것은 점검의 기본입니다.
이 글에서는 Nginx와 Apache 설정 파일을 기준으로 세 가지를 확인합니다. Server 헤더의 버전 정보, 디렉터리 리스팅, 에러 페이지 노출입니다. 점검 명령과 설정 예시, 반영 순서를 차례로 다루고, 마지막에 자주 묻는 질문을 정리합니다.
응답에서 무엇이 보이는지 먼저 확인합니다
설정을 바꾸기 전에 외부에서 보이는 모습부터 기록해 둡니다. 설정을 먼저 고치면 전후 비교가 어렵고, 무엇이 실제로 바뀌었는지 증적으로 남기기도 힘듭니다. 점검은 로컬 파일이 아니라 운영 도메인을 기준으로 하고, 점검 PC에서 curl -I 명령으로 응답 헤더를 받아 보세요.
Server 값에 nginx/1.18.0처럼 제품명과 버전이 함께 나오면 노출입니다. 배포판 정보가 뒤에 붙는 경우도 있습니다. 헤더가 깔끔하더라도 에러 페이지에서 같은 정보가 나올 수 있으니, 헤더 확인만으로 점검을 끝내지 않습니다.
예를 들어 사내 쇼핑몰 서버를 배포 전에 점검한다고 해 봅시다. 응답 헤더의 Server 값은 Apache/2.4.41 (Ubuntu)로 보였습니다. 그런데 없는 경로를 요청하자 에러 페이지 하단에 Apache/2.4.41 Server at 도메인 Port 443 문구가 그대로 나왔습니다. 헤더만 고쳐서는 끝나지 않는다는 것을 이 사례가 보여줍니다.
Nginx: server_tokens와 autoindex 확인
Nginx는 기본 설정에서 Server 헤더와 기본 에러 페이지에 버전을 표시합니다. 전체 설정은 nginx -T 명령으로 펼쳐서 보는 것이 가장 확실합니다. include로 불러온 파일까지 한 번에 나오므로 여러 파일에 흩어진 설정도 빠뜨리지 않고 찾을 수 있습니다.
server_tokens 끄기
출력에서 server_tokens를 찾고, 값이 없거나 on이면 http 블록 안에 server_tokens off; 한 줄을 넣습니다. 그러면 Server 헤더는 nginx로만 나오고, 기본 에러 페이지의 버전 표기도 함께 사라집니다. 제품명 자체를 바꾸려면 headers-more 같은 추가 모듈이 필요합니다.
autoindex 확인
디렉터리 리스팅은 index 파일이 없는 경로에서 파일 목록을 그대로 보여주는 기능입니다. Nginx의 autoindex는 기본값이 off이지만, 특정 location 블록에 autoindex on;이 들어 있으면 그 경로는 목록이 노출됩니다. nginx -T 출력에서 autoindex를 검색해 on으로 된 블록이 없는지 확인하세요.
Apache: ServerTokens, ServerSignature, Options 확인
Apache는 설정이 여러 파일과 디렉터리 블록에 나뉘어 있어 위치부터 찾아야 합니다. Debian·Ubuntu 계열은 /etc/apache2, RHEL 계열은 /etc/httpd 아래가 기본입니다. apachectl -S로 로드된 가상 호스트를 확인하고, grep으로 ServerTokens, ServerSignature, Options 값을 모아 보세요.
ServerTokens는 Server 헤더에 담길 정보의 양을 정하며, Prod로 두면 Apache만 표시됩니다. ServerSignature는 에러 페이지와 디렉터리 목록 하단에 서버 정보를 넣을지 정하며, Off가 일반적입니다. 두 값은 서버 또는 가상 호스트 설정에 두는 것이 기준입니다.
디렉터리 리스팅 막기
Apache에서 목록이 보이는 이유는 해당 디렉터리의 Options에 Indexes가 남아 있기 때문입니다. Options -Indexes로 끄고, Options 줄이 여러 곳에 중복되지 않는지 확인합니다. 최종 값은 설정 파일 검색보다 실제 요청 결과로 확인하는 편이 정확합니다.
두 웹서버 설정 한눈에 비교
아래 표는 점검 때 같은 기준으로 판단하기 위한 정리입니다. 지시어 이름과 적용 범위가 다르므로 한쪽 설정을 그대로 옮기면 항목을 놓치기 쉽습니다. 점검표에는 항목별로 Nginx와 Apache 열을 함께 적어 두세요.
| 점검 항목 | Nginx | Apache |
|---|---|---|
| Server 헤더 버전 | server_tokens off (http 블록) | ServerTokens Prod (서버 설정) |
| 에러 페이지 버전 표기 | server_tokens off로 함께 숨김 | ServerSignature Off |
| 디렉터리 리스팅 | autoindex off (location 확인) | Options -Indexes (디렉터리 블록 확인) |
| 에러 페이지 대체 | error_page 지시어 | ErrorDocument 지시어 |
| 점검 명령 | nginx -T | apachectl -S 및 grep |
에러 페이지 노출을 따로 확인합니다
에러 페이지는 헤더보다 놓치기 쉬운 노출 지점입니다. 존재하지 않는 경로를 요청해 응답 본문에 서버 이름, 버전, 내부 경로가 보이는지 확인합니다. curl -i 뒤에 도메인과 임의의 경로를 붙이면 되고, 결과를 파일로 저장해 두면 조치 전후를 비교하기 쉽습니다.
에러 페이지를 바꿀 때는 Nginx에서 error_page 404 /404.html; 형태로, Apache에서는 ErrorDocument 404 /404.html 한 줄로 일반 안내 페이지를 지정합니다. 애플리케이션이 직접 내보내는 스택 트레이스나 내부 IP는 웹서버보다 앱 설정이 먼저입니다. 운영 모드에서 디버그 출력을 끄고, 필요하면 Nginx의 proxy_intercept_errors 같은 설정도 검토하세요.
바로 해 볼 점검 순서
- 운영 도메인에 curl -I를 실행해 Server 헤더를 기록하고, 없는 경로 요청의 응답 본문도 파일로 저장합니다.
- nginx -T 또는 Apache 설정 경로의 grep으로 server_tokens, ServerTokens, ServerSignature, autoindex, Options 위치를 모두 찾습니다.
- 설정을 고친 뒤 문법을 검사합니다. Nginx는 nginx -t, Apache는 apachectl configtest를 씁니다.
- 트래픽이 적은 시간에 reload합니다. Nginx는 systemctl reload nginx, Apache는 apache2 또는 httpd 서비스를 reload하고 에러 로그를 함께 확인합니다.
- 1단계와 같은 명령을 다시 실행해 전후 결과를 비교하고, 날짜와 결과를 점검표에 증적으로 남깁니다.
자주 묻는 질문
버전을 숨기면 취약점 공격을 막을 수 있나요?
막을 수 없습니다. 버전 숨김은 공격자가 대상을 특정하는 데 드는 시간을 늘리는 정도의 효과입니다. 실제로 중요한 것은 보안 패치 적용 주기와 지원이 끝난 버전을 쓰고 있는지입니다. 숨김은 기본 설정으로 두고, 패치 관리 항목과 함께 점검하세요.
설정을 고쳤는데 헤더가 그대로 보입니다. 왜 그런가요?
먼저 reload가 실제로 반영됐는지 서비스 상태와 로그로 확인합니다. 다음으로 앞단의 CDN이나 로드밸런서가 Server 헤더를 다시 붙이는지 봐야 합니다. 마지막으로 include나 다른 가상 호스트에서 같은 지시어가 덮어쓰고 있지 않은지 nginx -T, apachectl -S 출력으로 확인하세요.
디렉터리 리스팅을 껐더니 403이나 404가 납니다. 문제인가요?
목록 대신 403이나 404가 나오는 것은 의도한 동작입니다. 다만 목록에 의존하던 다운로드 경로가 있었다면 그 경로가 막혔는지 실제 화면에서 확인해야 합니다. 필요한 파일은 직접 경로로 접근하도록 안내하고, 나머지 경로는 목록을 닫아 두는 방식이 안전합니다.
정리
- Server 헤더, 에러 페이지, 디렉터리 리스팅은 서로 다른 지시어로 나뉘어 있어 셋을 따로 확인해야 합니다.
- Nginx는 server_tokens와 autoindex, Apache는 ServerTokens, ServerSignature, Options를 nginx -T와 apachectl -S로 펼쳐 봅니다.
- 설정 변경 후에는 문법 검사, reload, 외부 재확인을 한 세트로 실행하고 결과를 증적으로 남깁니다.
오늘 할 일: 운영 도메인 한 곳에 curl -I를 실행해 Server 헤더 값을 점검표에 기록하세요.
댓글