이 블로그 게시물은 최근 HTTP/2 프로토콜과 관련하여 발견된 취약점을 중심으로 작성되었습니다. 특정 조건에서 이 취약점은 HTTP/2 사양의 서버 측 부분을 구현하는 NGINX 오픈 소스, NGINX Plus 및 관련 제품에 대한 서비스 거부 공격을 실행하는 데 악용될 수 있습니다. 이 공격으로부터 시스템을 보호하려면 NGINX 구성을 즉시 업데이트할 것을 권장합니다.
HTTP/2 스트림 재설정의 문제
서버와 연결을 설정한 후 HTTP/2 프로토콜은 클라이언트가 데이터 교환을 위한 동시 스트림을 시작할 수 있도록 합니다. 이전 프로토콜의 반복과 달리 최종 사용자가 페이지를 벗어나거나 다른 이유로 데이터 교환을 중단하기로 결정한 경우 HTTP/2는 스트림을 취소할 수 있는 방법을 제공합니다. 이는 서버에 RST_STREAM 프레임을 발행하여 불필요한 작업 실행을 방지하는 방식으로 이루어집니다.
이 취약점은 설정된 연결을 통해 대량의 HTTP/2 스트림을 시작하고 빠르게 취소하여 서버의 동시 스트림 최대치를 우회하는 방식으로 악용됩니다. 이는 수신 스트림이 후속 스트림이 도착하는 속도보다 빠르게 리셋되어 클라이언트가 구성된 임계값에 도달하지 않고도 서버에 과부하가 걸릴 수 있기 때문에 발생합니다.
NGINX에 미치는 영향
성능 및 리소스 소비를 위해 NGINX는 동시 스트림 수를 기본값인 128개로 제한합니다(http2_max_concurrent_streams 참조). 또한 네트워크와 서버 성능의 균형을 최적으로 맞추기 위해 NGINX는 클라이언트가 HTTP Keep-Alive 를 사용하여 기본적으로 최대 1000개의 요청에 대해 HTTP 연결을 유지할 수 있도록 합니다(keepalive_requests 참조).
기본 Keep-Alive 제한에 의존함으로써 NGINX는 이러한 유형의 공격을 방지합니다. 이 제한을 우회하기 위해 추가 연결을 생성 하면 표준 레이어 4 모니터링 및 알림 도구를 통해 악의적인 공격자가 노출됩니다.
그러나 기본 및 권장 설정보다 훨씬 높은 Keep-Alive 설정으로 NGINX를 구성한 경우 공격으로 인해 시스템 리소스가 고갈될 수 있습니다. 스트림 재설정이 발생하면 HTTP/2 프로토콜은 해당 스트림의 클라이언트에 후속 데이터가 반환되지 않도록 요구합니다. 일반적으로 재설정은 취소를 정상적으로 처리하는 작업의 형태로 무시할 수 있는 서버 오버헤드를 발생시킵니다. 그러나 NGINX의 스트림 임계값을 우회하면 클라이언트가 이 오버헤드를 이용하여 수천 개의 스트림을 빠르게 시작함으로써 오버헤드를 증폭시킬 수 있습니다. 이로 인해 서버 CPU가 급증하여 정상적인 클라이언트에 대한 서비스가 거부됩니다.
HTTP/2 스트림을 설정하여 서비스 거부를 한 후 비정상적으로 높은 Keep-Alive 제한으로 스트림을 취소합니다..
공격 노출을 완화하기 위한 단계
모든 기능을 갖춘 서버 및 프록시인 NGINX는 관리자에게 서비스 거부 공격을 완화할 수 있는 강력한 도구를 제공합니다. 이러한 기능을 활용하려면 서버의 공격 표면을 최소화하기 위해 NGINX 구성 파일에 다음과 같은 업데이트를 수행해야 합니다:
- keepalive_requests는 기본 설정인 1000개의 요청으로 유지해야 합니다.
- http2_max_concurrent_streams는 기본 설정인 128 스트림으로 유지해야 합니다.
- 또한 이러한 안전 조치를 모범 사례로 추가하는 것이 좋습니다:
- limit_conn은 단일 클라이언트에서 허용되는 연결 수에 제한을 적용합니다.
- 이 지시어는 애플리케이션 성능과 보안의 균형을 고려하여 합리적인 설정으로 추가해야 합니다.
- limit_req는 단일 클라이언트로부터 주어진 시간 내에 처리할 요청 수를 제한합니다. 이 지시어는 애플리케이션 성능과 보안의 균형을 맞추는 합리적인 설정으로 추가해야 합니다.
대응 방법
당사는 다양한 완화 전략을 실험하여 이 공격이 광범위한 고객과 사용자에게 어떤 영향을 미칠 수 있는지 파악하는 데 도움이 되었습니다. 이 조사를 통해 NGINX가 이미 공격을 방지하는 데 필요한 모든 도구를 갖추고 있음을 확인했지만, 권장 사양 이상으로 NGINX를 구성해야 하는 사용자가 이를 수행할 수 있도록 추가 조치를 취하고 싶었습니다.
조사를 통해 이론적으로 HTTP/2 프로토콜을 통해 가능한 다양한 형태의 플러드 공격에서 서버 복원력을 개선할 수 있는 방법을 찾아냈습니다. 그 결과 이러한 조건에서 시스템 안정성을 높이는 패치를 발표했습니다. 이러한 위협으로부터 보호하기 위해 NGINX 오픈 소스 사용자는 최신 코드베이스에서 바이너리를 다시 빌드하고, NGINX Plus 고객은 즉시 최신 패키지(R29p1 또는 R30p1)로 업데이트할 것을 권장합니다.
패치 작동 방식
이 패치는 NGINX에 대한 폭주 공격을 조기에 탐지하기 위해 하나의 이벤트 루프 내에서 도입할 수 있는 새 스트림 수에 제한을 둡니다. 이 제한은 http2_max_concurrent_streams 지시어를 사용하여 구성된 값의 두 배로 설정됩니다. 이 제한은 요청을 보낸 직후 스트림이 재설정되는 경우(이 공격의 경우처럼)와 같이 최대 임계값에 도달하지 않은 경우에도 적용됩니다.
영향을 받는 제품
이 취약점은 NGINX HTTP/2 모듈(ngx_http_v2_module)에 영향을 미칩니다.
영향을 받을 수 있는 특정 NGINX 또는 F5 제품에 대한
자세한 내용은 https://my.f5.com/manage/s/article/K000137106 을 참조하세요.
CVE-2023-44487 - HTTP/2 래피드 리셋 공격에 대한 자세한 내용은 다음을 참조하세요:
https://www.cve.org/CVERecord?id=CVE-2023-44487
감사
이 취약점을 발견하고 완화하는 데 도움을 준 Cloudflare, Amazon, Google에 감사의 말씀을 드립니다.
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
이 블로그 게시물은 최근 HTTP/2 프로토콜과 관련하여 발견된 취약점을 중심으로 작성되었습니다. 특정 조건에서 이 취약점은 HTTP/2 사양의 서버 측 부분을 구현하는 NGINX 오픈 소스, NGINX Plus 및 관련 제품에 대한 서비스 거부 공격을 실행하는 데 악용될 수 있습니다. 이 공격으로부터 시스템을 보호하려면 NGINX 구성을 즉시 업데이트할 것을 권장합니다.
HTTP/2 스트림 재설정의 문제
서버와 연결을 설정한 후 HTTP/2 프로토콜은 클라이언트가 데이터 교환을 위한 동시 스트림을 시작할 수 있도록 합니다. 이전 프로토콜의 반복과 달리 최종 사용자가 페이지를 벗어나거나 다른 이유로 데이터 교환을 중단하기로 결정한 경우 HTTP/2는 스트림을 취소할 수 있는 방법을 제공합니다. 이는 서버에 RST_STREAM 프레임을 발행하여 불필요한 작업 실행을 방지하는 방식으로 이루어집니다.
이 취약점은 설정된 연결을 통해 대량의 HTTP/2 스트림을 시작하고 빠르게 취소하여 서버의 동시 스트림 최대치를 우회하는 방식으로 악용됩니다. 이는 수신 스트림이 후속 스트림이 도착하는 속도보다 빠르게 리셋되어 클라이언트가 구성된 임계값에 도달하지 않고도 서버에 과부하가 걸릴 수 있기 때문에 발생합니다.
NGINX에 미치는 영향
성능 및 리소스 소비를 위해 NGINX는 동시 스트림 수를 기본값인 128개로 제한합니다(http2_max_concurrent_streams 참조). 또한 네트워크와 서버 성능의 균형을 최적으로 맞추기 위해 NGINX는 클라이언트가 HTTP Keep-Alive 를 사용하여 기본적으로 최대 1000개의 요청에 대해 HTTP 연결을 유지할 수 있도록 합니다(keepalive_requests 참조).
기본 Keep-Alive 제한에 의존함으로써 NGINX는 이러한 유형의 공격을 방지합니다. 이 제한을 우회하기 위해 추가 연결을 생성 하면 표준 레이어 4 모니터링 및 알림 도구를 통해 악의적인 공격자가 노출됩니다.
그러나 기본 및 권장 설정보다 훨씬 높은 Keep-Alive 설정으로 NGINX를 구성한 경우 공격으로 인해 시스템 리소스가 고갈될 수 있습니다. 스트림 재설정이 발생하면 HTTP/2 프로토콜은 해당 스트림의 클라이언트에 후속 데이터가 반환되지 않도록 요구합니다. 일반적으로 재설정은 취소를 정상적으로 처리하는 작업의 형태로 무시할 수 있는 서버 오버헤드를 발생시킵니다. 그러나 NGINX의 스트림 임계값을 우회하면 클라이언트가 이 오버헤드를 이용하여 수천 개의 스트림을 빠르게 시작함으로써 오버헤드를 증폭시킬 수 있습니다. 이로 인해 서버 CPU가 급증하여 정상적인 클라이언트에 대한 서비스가 거부됩니다.
HTTP/2 스트림을 설정하여 서비스 거부를 한 후 비정상적으로 높은 Keep-Alive 제한으로 스트림을 취소합니다..
공격 노출을 완화하기 위한 단계
모든 기능을 갖춘 서버 및 프록시인 NGINX는 관리자에게 서비스 거부 공격을 완화할 수 있는 강력한 도구를 제공합니다. 이러한 기능을 활용하려면 서버의 공격 표면을 최소화하기 위해 NGINX 구성 파일에 다음과 같은 업데이트를 수행해야 합니다:
대응 방법
당사는 다양한 완화 전략을 실험하여 이 공격이 광범위한 고객과 사용자에게 어떤 영향을 미칠 수 있는지 파악하는 데 도움이 되었습니다. 이 조사를 통해 NGINX가 이미 공격을 방지하는 데 필요한 모든 도구를 갖추고 있음을 확인했지만, 권장 사양 이상으로 NGINX를 구성해야 하는 사용자가 이를 수행할 수 있도록 추가 조치를 취하고 싶었습니다.
조사를 통해 이론적으로 HTTP/2 프로토콜을 통해 가능한 다양한 형태의 플러드 공격에서 서버 복원력을 개선할 수 있는 방법을 찾아냈습니다. 그 결과 이러한 조건에서 시스템 안정성을 높이는 패치를 발표했습니다. 이러한 위협으로부터 보호하기 위해 NGINX 오픈 소스 사용자는 최신 코드베이스에서 바이너리를 다시 빌드하고, NGINX Plus 고객은 즉시 최신 패키지(R29p1 또는 R30p1)로 업데이트할 것을 권장합니다.
패치 작동 방식
이 패치는 NGINX에 대한 폭주 공격을 조기에 탐지하기 위해 하나의 이벤트 루프 내에서 도입할 수 있는 새 스트림 수에 제한을 둡니다. 이 제한은 http2_max_concurrent_streams 지시어를 사용하여 구성된 값의 두 배로 설정됩니다. 이 제한은 요청을 보낸 직후 스트림이 재설정되는 경우(이 공격의 경우처럼)와 같이 최대 임계값에 도달하지 않은 경우에도 적용됩니다.
영향을 받는 제품
이 취약점은 NGINX HTTP/2 모듈(ngx_http_v2_module)에 영향을 미칩니다.
영향을 받을 수 있는 특정 NGINX 또는 F5 제품에 대한
자세한 내용은 https://my.f5.com/manage/s/article/K000137106 을 참조하세요.
CVE-2023-44487 - HTTP/2 래피드 리셋 공격에 대한 자세한 내용은 다음을 참조하세요:
https://www.cve.org/CVERecord?id=CVE-2023-44487
감사
이 취약점을 발견하고 완화하는 데 도움을 준 Cloudflare, Amazon, Google에 감사의 말씀을 드립니다.
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기