HTTP TRACE method 보안취약점 관련 실무적 대응 방법

아래에서는 실무에서 어떻게 확인하고, 어떤 설정을 넣어 적용하며, 어떻게 검증하는지를 사용하신 명령어와 결과를 포함해 단계적으로 설명합니다.

HTTP TRACE method 보안취약점 관련 실무적 대응 방법

HTTP TRACE 메서드와 실무적 대응 — 진단부터 차단, 검증까지

HTTP 프로토콜에는 표준적으로 여러 메서드가 정의되어 있습니다. 그중 TRACE는 본래 진단(디버깅)을 위해 만들어진 메서드로, 서버에 도달한 요청 메시지를 그대로 응답 본문으로 되돌려 주는 동작을 합니다. 이 자체는 진단에는 편리하지만, 잘못 노출되면 민감한 요청 헤더(예: 세션 쿠키, 인증 토큰)를 공격자가 회수할 수 있어 보안상 문제가 됩니다. 실제로 OWASP 같은 보안 가이드에서도 TRACE는 운영 환경에서는 비활성화하도록 권고하고 있습니다.

아래에서는 실무에서 어떻게 확인하고, 어떤 설정을 넣어 적용하며, 어떻게 검증하는지를 사용하신 명령어와 결과를 포함해 단계적으로 설명합니다. 이 글을 통해 보안 담당자는 본인의 서버에서 같은 절차로 조치할 수 있습니다.

1. 어떤 설정 파일이 실제로 적용되는지 확인하는 방법

  • 서버에서 어떤  httpd.conf 가 실제로 사용되는지 확인하는 것이 우선입니다. Apache(여기서는 JBCS 배포)를 어떻게 기동했는지 프로세스 라인으로 확인하면 명시된 설정 파일 경로를 알 수 있습니다. 출력 예시는 다음과 같습니다.
[root@httpd test01]# ps -ef | grep httpd
root     1951529       1  3 09:42 ?        00:00:00 /svc/web/jbcs-httpd24-2.4/httpd/sbin/httpd -d /svc/web/instances/test01 -f /svc/web/instances/test01/conf/httpd.conf -E /svc/web/instances/test01/logs/httpd.log -k start

위 프로세스 라인에서 -f /svc/web/instances/test01/conf/httpd.conf  옵션이 보이듯 실제 적용되는 메인 설정파일은 /svc/web/instances/test01/conf/httpd.conf  입니다. 이 파일을 편집하면 해당 인스턴스에 즉시 적용됩니다 (재시작 또는 graceful reload 필요).

2. TRACE 활성화 여부(취약) 확인 — curl로 직접 테스트

TRACE 메서드의 동작을 직접 확인하려면 curl -v -X TRACE 로 요청을 보내 보면 됩니다. 적용 전 (취약) 과 적용 후 (비활성화) 상황을 비교하면 효과가 명확합니다. 예시는 다음과 같습니다.

TRACE 활성화(조치 전) — 서버가 요청을 그대로 반송함 (취약)

[root@session-web sbin]# curl -v -X TRACE http://192.168.170.201/test/
*   Trying 192.168.170.201...
* TCP_NODELAY set
* Connected to 192.168.170.201 (192.168.170.201) port 80 (#0)
> TRACE /test/ HTTP/1.1
> Host: 192.168.170.201
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 18 Sep 2025 01:20:07 GMT
< Server: Apache
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: message/http
<
TRACE /test/ HTTP/1.1
Host: 192.168.170.201
User-Agent: curl/7.61.1
Accept: */*

이 정상 응답(200 OK) 안에 요청 메서드/헤더가 그대로 포함되어 반환되는 것을 볼 수 있습니다. 여기에는 민감한 헤더가 포함될 가능성이 있으므로 보안상 문제가 됩니다.

3. 조치: TraceEnable Off 설정 적용

위험을 제거하려면 Apache 설정에 TraceEnable Off 를 추가하면 됩니다. 적용 대상은 앞서 확인한 인스턴스의 httpd.conf 입니다. 예시 내용은 다음과 같습니다.서 

vim /svc/web/instances/test01/conf/httpd.conf
...
# Disable HTTP TRACE method
TraceEnable Off

설정 변경 후에는 Apache를 재시작하거나 graceful로 재적용해야 합니다.

4. 적용 후 검증 — TRACE가 차단되어 405가 반환되는지 확인

설정 반영(재기동) 이후 동일한 테스트를 반복하면 TRACE가 차단되어 405 응답이 내려와야 합니다. 검증 결과는 아래와 같습니다. 

TRACE 비활성화(조치 후) — 서버가 405를 반환함 (차단 성공)

[root@session-web sbin]# curl -v -X TRACE http://192.168.170.201/test/
*   Trying 192.168.170.201...
* TCP_NODELAY set
* Connected to 192.168.170.201 (192.168.170.201) port 80 (#0)
> TRACE /test/ HTTP/1.1
> Host: 192.168.170.201
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 405 Method Not Allowed
< Date: Thu, 18 Sep 2025 01:14:59 GMT
< Server: Apache
< Allow:
< Content-Length: 222
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for this URL.</p>
</body></html>
* Closing connection 0

위와 같이 405 Method Not Allowed 와 함께 The requested method TRACE is not allowed for this URL. 문구가 내려오면 TRACE 비활성화가 정상 적용된 상태입니다.

5. 해당 설정 적용 시 서비스 영향도 및 주의사항은?

TRACE는 디버깅 목적의 메서드이며, 정상 서비스 (일반적인 웹 애플리케이션 트래픽: GET/POST 등) 의 동작과는 관련이 없습니다. TRACE를 비활성화함으로써 운영중인 서비스에는 영향이 거의 없습니다. 다만 다음 두 가지는 반드시 확인해야 합니다.

  • 내부진단 도구 의존성

내부 운영팀이나 특정 레거시 모니터링/디버깅 도구에서 의도적으로 TRACE를 사용하는 경우, 비활성화 시 그 도구에 영향이 있을 수 있으므로 사전 협의가 필요합니다.

  • 중간 장비(프록시/로드밸런서)에서의 동작

클라이언트→로드밸런서→웹서버 체인에서 TRACE가 로드밸런서에서 차단되지 않고 백엔드로 전달될 가능성이 있으므로, 프런트엔드 장비에도 동일 정책을 적용해 다층적으로 방어하는 것이 좋습니다.

이 점을 사전에 확인하면 서비스 영향을 최소화하면서 보안 취약점을 제거할 수 있습니다.

6. 추가 조치 권고사항 — 응답 헤더 정보 노출 최소화

TRACE 차단과 별개로, 응답 헤더에 서버 소프트웨어·버전 정보가 노출되는 것도 보안상 권장하지 않습니다. 운영에서는 httpd.conf 파일에 아래 항목들의 설정을 함께 검토하시기 바랍니다.

  • ServerTokens Prod — Server: 헤더에 제품명만 남기거나 최소화합니다.
  • ServerSignature Off — 에러 페이지 하단의 서버 서명 출력 비활성화.
  • mod_headers로 Server·X-Powered-By 헤더를 완전 제거
<IfModule mod_headers.c>
    Header unset Server early
    Header always unset Server
    Header always unset X-Powered-By
</IfModule>

위 블록을 전역 (httpd.conf 맨 아래) 과 각 VirtualHost
블록의 맨 끝 (특히 default vhost)에도 추가하면, 에러 응답 및 프록시 패스가 있는 경우까지 커버할 수 있습니다.

참고로 헤더를 완전히 제거하는 것과는 다르지만, SecServerSignature (ModSecurity) 같은 설정으로Server: 값을 덮어쓰는 방법도 있습니다.

7. 실무 주의사항 및 점검 체크리스트

사전 확인

  • TRACE를 사용하는 내부·외부 툴이 있는지 운영팀에 확인합니다.
  • 설정 파일이 실제 적용되는 경로인지 ps -ef 로 확인합니다 (예: f /svc/web/instances/test01/conf/httpd.conf).

구현

  • 대상 httpd.conf에 TraceEnable Off 추가.
  • 전역/각 vhost에 mod_headers를 사용해 Server/X-Powered-By 제거(권장).
  • ServerTokens Prod, ServerSignature Off 적용.

검증

  • curl -v -X TRACE http://<host>/test/ — 405 반환 확인.
  • curl -I http://<host>/ — Server: 헤더 최소화 또는 부재 확인.
  • 프록시/LB 경유 시 도메인(VIP) 경유/직접 접속 결과 모두 확인.

맺음말(마무리)

TRACE 비활성화는 훨씬 더 큰 보안 개선으로 이어지는 작은 조치입니다. 운영 서비스의 정상 동작에는 거의 영향을 주지 않으므로, 점검 정책에 따라 빠르게 적용하되, 내부 진단 도구 의존성이나 앞단 네트워크 장비의 동작 여부는 반드시 확인하십시오. 위 절차(설정 → 재기동 → curl 검증)를 그대로 따르면 안전하게 취약점을 제거하고 검증 자료를 확보할 수 있습니다.

Dogfooding

Dogfooding – 사용자 입장에서 제품이나 서비스의 품질과 UX를 확인할 수 있습니다.

/카테고리: , , /작성자:
자세히 보기

오픈마루

04778 서울시 성동구 뚝섬로1길 31 906 호
(성수동1가, 서울숲M타워)
Tel : 02-469-5426 | Fax : 02-469-7247
Email : sales@openmaru.io

APM 서비스 포트 변경 방법 가이드