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 검증)를 그대로 따르면 안전하게 취약점을 제거하고 검증 자료를 확보할 수 있습니다.

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

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

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

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

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

3. 조치: `TraceEnable Off` 설정 적용

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

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

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

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

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

사전 확인

구현

검증

맺음말(마무리)

레드햇 Container Day 세미나 – 컨테이너와 AI 솔루션 소개

이것이 좋아요:

오픈마루

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

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

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

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

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

3. 조치: TraceEnable Off 설정 적용

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

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

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

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

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

사전 확인

구현

검증

맺음말(마무리)

이것이 좋아요:

오픈마루

3. 조치: `TraceEnable Off` 설정 적용