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