F5 NGINX 제품에 영향을 미치는 HTTP/2 Rapid Reset 공격

이 블로그 게시물은 최근 발견된 HTTP/2 프로토콜과 관련된 취약점에 초점을 맞추고 있습니다. 특정 조건 하에서 이 취약점은 HTTP/2 사양의 서버 측 부분을 구현하는 NGINX Open Source, NGINX Plus 및 관련 제품에 대한 서비스 거부 공격을 실행하는 데 악용될 수 있습니다. 이 공격으로부터 시스템을 보호하려면 NGINX 구성을 즉시 업데이트하는 것이 좋습니다.

HTTP/2 스트림 재설정의 문제

HTTP/2 프로토콜은 서버와 연결을 설정한 후 클라이언트가 데이터 교환을 위한 동시 스트림을 시작할 수 있도록 허용합니다. 이전 프로토콜과는 달리, 최종 사용자가 페이지를 벗어나거나 다른 이유로 데이터 교환을 중단하기로 결정한 경우 HTTP/2는 스트림을 취소하는 방법을 제공합니다. 이는 서버에 RST_STREAM 프레임을 발행하여 불필요한 작업 실행을 방지함으로써 가능합니다.

이 취약점은 확립된 연결을 통해 많은 수의 HTTP/2 스트림을 시작하고 빠르게 취소하여 서버의 동시 스트림 최대치를 우회함으로써 악용됩니다. 이는 들어오는 스트림이 후속 스트림이 도착하는 것보다 더 빨리 재설정되어 클라이언트가 구성된 임계값에 도달하지 않고도 서버에 과부하가 걸릴 수 있기 때문에 발생합니다.

NGINX에 미치는 영향

성능과 리소스 소비의 이유로 NGINX는 동시 스트림 수를 기본값 128로 제한합니다( http2_max_concurrent_streams 참조). 또한, NGINX는 네트워크와 서버 성능의 균형을 최적화하기 위해 HTTP keepalive( keepalive_requests 참조)를 사용하여 기본적으로 클라이언트가 최대 1000개의 요청에 대해 HTTP 연결을 유지할 수 있도록 허용합니다.

NGINX는 기본 keepalive 한도를 사용하여 이러한 유형의 공격을 방지합니다. 이러한 제한을 우회하기 위해 추가 연결을 생성하면 표준 레이어 4 모니터링 및 알림 도구를 통해 나쁜 행위자를 노출시킬 수 있습니다.

그러나 NGINX가 기본 및 권장 설정보다 훨씬 높은 keepalive로 구성된 경우 공격으로 인해 시스템 리소스가 고갈될 수 있습니다. 스트림 재설정이 발생하면 HTTP/2 프로토콜은 해당 스트림에서 후속 데이터가 클라이언트로 반환되지 않도록 요구합니다. 일반적으로 재설정은 취소를 원활하게 처리하는 작업의 형태로 무시할 수 있는 서버 오버헤드를 발생시킵니다. 그러나 NGINX의 스트림 임계값을 우회하면 클라이언트가 이 오버헤드를 이용하여 수천 개의 스트림을 빠르게 시작하여 이를 증폭할 수 있습니다. 이로 인해 서버 CPU 사용량이 급증하여 정상적인 클라이언트에 대한 서비스가 거부됩니다.

비정상적으로 높은 keepalive 한도로 인해 HTTP/2 스트림을 설정한 후 스트림이 취소되어 서비스 거부가 발생합니다.

공격 노출 완화를 위한 단계

모든 기능을 갖춘 서버 및 프록시인 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 Rapid Reset 공격에 대한 자세한 내용은 https://www.cve.org/CVERecord?id=CVE-2023-44487을 참조하세요.

감사의 말

우리는 이러한 취약성을 발견하고 완화하기 위해 협력한 Cloudflare, Amazon, Google에 감사드리고 싶습니다.