서버 스펙
- SpringBoot 2.3.4
- jdk 1.8
- AWS EC2 + cloundFront + ALB
이슈

원래의 GET 요청을 'TRACE'같은 서버 내 미지원 메소드 삽입하여 요청 시,
응답값에 서버 버전이 header에 그대로 노출 되는 이슈가 있다.
서버 버전 정보가 응답 헤더에 노출되면 공격자가 시스템을 식별 및 분석하여 취약점을 노릴 수 있으므로 공개하면 안되기 때문이다.
문제점
- 공격자 편의 제공
- 버전이 노출되면 시스템 구성의 핵심 힌트가 되어 공격자가 표적을 좁히는 데 사용된다.
- 불필요한 단서를 제거하면 공격자가 추측해야 할 변수가 줄어든다.
- 타깃화된 공격 위험 증가
- 알려진 취약점이 존재하는 특정 버전이 확인되면, 공격자는 그 버전에만 초점을 맞춘 공격(제로데이, 패치 미적용 공격)이 가능하다.
- 사회공학/추가 정보 수집에 악용
- 버전과 구성 정보는 내부 구조 및 운영 절차를 유추하는 데 도움을 주어, 추가 공격 벡터를 열어준다.
- 신뢰성 저하
- 외부에 불필요한 내부 정보를 노출하면 서비스 신뢰도나 보안 관리 수준에 대한 부정적인 인식을 준다.
서버 응답 헤더에 제품명과 버전이 표시되면, 공격자는 이를 바탕으로 취약점 스캐너를 돌리거나 알려진 익스플로잇(취약점을 실제로 뚫을 수 있게 도와주는 도구/방법)을 시도할 수 있다.
따라서 운영 환경에서는 불필요한 서버 식별 정보를 제거해 공격 표면을 줄여야 한다.
1. 원인
원인이랄 것도 없다.
그냥 저 서버 버전 정보가 노출되는건 기본인데, 노출 차단하는 로직이나 설정이 되어 있지 않을 뿐.
2-1. 해결과정
1) application.properties 설정
server.server-header=
응답값 내 서버 버전이 ' Server: Apache-Coyote/1.1 '와 같이 노출된다면,
SpringBoot 2.2 이상에서 application.properties 설정파일 내 위와 같이 header를 빈 값으로 지정하면 Server 헤더가 아예 제거된다고 한다.
하지만 나는 Apache가 아니라 awselb 값이 노출되기에 위와 같은 형식으로 서버 버전 정보를 제거할 수 없다.
2) CloudFront 내 Function 세팅
function handler(event) {
var response = event.response;
var headers = response.headers;
// Server 헤더 제거
delete headers['server'];
return response;
}

- AWS 사이트 > CloudFront 콘솔 > Functions > 새 Function 생성
- 이벤트 타입 : Viewer Response
- 위 코드 삽입 후 Publish > 배포된 배포판(Distribution)에 연결
CloudFront Function으로 처리한다면 미지원 메소드 요청에 대해 ELB가 서버 버전을 붙여도,
CloudFront가 응답을 가로채고 최종 사용자에게는 Server 헤더가 없는 상태로 내려가게 된다.
그러나, 나는 AWS 내에서 뭔가를 자유롭게 설정할 수 있는 권한이 없다.
이 방법밖에 없다면 고려하겠으나, 이 방법은 최후의 수단으로 남겨두기로 한다.
3) ALB 설정 변경 (채택)

- AWS Console > EC2 > 로드 밸런서 > 운영서버 alb 선택
- 상단 메뉴 내 '속성' 탭 클릭
- HTTP 헤더 수정 항목 찾기 > Server Header 옵션 내 'routing.http.response.server.enabled 기본값 true에서 false로 변경'
우선 나는 로드밸런서 관련 세팅을 자유롭게 할 권한이 없다.
그리고 내가 선택한 서버의 속성 화면에는 HTTP 헤더 수정 기능은 보이지 않았다.
알고보니 리전을 대한민국 서울이 아닌, 미국으로 설정하여 로드밸런서가 보이지 않았다.

실제 인스턴스가 있는 리전은 미국이 아닌, 대한민국 서울이므로 아래와 같이 '서울'로 리전을 변경해주면 된다.

리전을 서울로 변경 후, 로드 밸런서 리스트가 정상적으로 확인되는지 확인한다.
또한, 로드밸런서 관련 권한이 있어야 확인 후 편집이 가능하다.
클라이언트사에서 로드밸런서 관련 권한을 나중에 추가해주셔서 로드밸런서 편집 단계를 확인할 수 있었다.
결과적으로 해당 방법이 최종적으로 채택되어 운영서버에 반영하였다.
4) Filter 파일 생성
스프링부트 웹 프로젝트 내 filter 파일을 따로 만들어서 HTTP 요청 내 모든 헤더 내 서버 정보를 노출시키지 않는 방법은 정상적으로 반영되지 않은 방법이다.
애초에 'Server: awselb/2.0'은 AWS Application Load Balancer(ALB)에서 기본적으로 삽입되는 헤더이기 때문에 application.properties나 filter.java를 생성하여 소스코드로 해결할 수 있는 부분이 없기 때문이다.
✅참고자료
2-2. 해결
AWS 콘솔 내에서 작업하는 협력사가 따로 존재하기에,
해당 서버 담당자분께 관련 작업 요청드리는 메일을 작성하였다.
응답값 내에서 노출되는 ‘Server: awselb/2.0’은 AWS Application Load Balancer(ALB)에서 기본적으로 삽입되는 헤더로,
웹개발 영역 내 소스코드로 미노출 처리할 수 있는 부분 아님.
따라서 AWS 콘솔 내에서 처리 필요.
해당 부분 조치 가능 여부 확인 요청.
---------------------------------------------------
이후 아래와 같이 서버 응답 헤더가 비활성화되었다.
AWS 콘솔 > EC2 > 로드밸런서 > 운영서버-ALB > 리스너 > 속성 > ALB 서버 응답 헤더 비활성화 > 저장
EC2 > 로드밸런서 > 운영서버-alb > 리스너

운영서버-alb 내 모든 리스너들에 대하여 서버 응답 헤더를 off 처리해야 한다.
각 프로토콜: 포트마다 편집해주면 된다.
리스너 모두 개별씩 클릭 > 속성 > 편집

ALB 서버 응답 헤더 > OFF > 변경 내용 저장

기존에는 'ALB 서버 응답 헤더' 내 '서버 헤더' 영역이 ON 되어있어서 서버 응답 헤더 내 서버 버전이 노출되었다.
해당 부분을 OFF 처리한 후 저장해야 한다.
+) 참고로 ALB 서버 응답 헤더 OFF 후 저장해도 운영 서버 내 접속에는 아무런 이상이 없었다.

2-3. 확인
위의 과정을 거쳐 운영서버의 응답 헤더 내 서버 버전이 미노출 처리되었다.

▶️참고) 도메인 대상 로드밸런서 확인 방법
위 링크(예시)에 대해서 확인이 필요할 때, testsite.co.kr 도메인이 바라보는 로드밸런서를 확인하는 방법.
확인필요사항
✔️testsite.co.kr 서비스 트래픽이 실제로 어떤 ALB를 거쳐서 들어오는지
Route 53 > 호스팅 영역 > testsite.co.kr > testsite.co.kr > 값/트래픽 라우팅 대상

해당 호스팅 영역 이름이 도메인과 일치하면 도메인 클릭

도메인 testsite.co.kr 중에서 A 레코드 영역 내 '값/트래픽 라우팅 대상' 값이 'dualstack.test-waf-123456.(생략)'일 때,
ALB는 로드 밸런서 내에서 test-waf를 찾으면 된다.
EC2 > 로드 밸런서 > test-waf

이때 test-waf처럼 로드 밸런서 뒤에 '-ALB'가 붙지 않아도 (예시 : test-waf-alb) 로드 밸런서 유형이 'application'이라면 서비스 ALB가 맞다.
이후 해당 ALB 대상으로 작업 진행 시 'testsite.co.kr 도메인 접속 > 미지원 메소드 삽입 > 응답값 내 서버 버전 미노출'이 반영되어 있을 것이다.
'[Project] > 업무일지' 카테고리의 다른 글
| [AWS/CloudWatch/RDS] 가용메모리 및 CPU 사용률 지표 확인 (0) | 2025.10.23 |
|---|---|
| [에러 핸들링] 파라미터 내 처리 불가 데이터 삽입 시 톰캣 기본 에러페이지 내 서버 버전 미노출 처리 (0) | 2025.09.17 |
| [카카오 로그인 API] 테스트앱 설정 (2) | 2025.08.12 |
| [Oracle 12c] SQL Error [1502] [72000]: ORA-01502: 인덱스 또는 인덱스 분할영역은 사용할 수 없는 상태입니다 (0) | 2025.07.29 |
| [Ajax/Get요청] GET 400 (Bad Request) (2) | 2025.07.21 |