HTTP/2 Continuation Flood 공격 완벽 분석 및 방어 전략

최근 웹 서버 관리자들 사이에서 새로운 서비스 거부(DoS) 공격인 "continuation flood"에 대한 우려가 커지고 있습니다. 이 공격은 특히 HTTP/2를 사용하는 서버를 겨냥하며, 기존의 DoS 방어 시스템으로는 탐지하기 어려운 특성을 지니고 있습니다. 이번 글에서는 이 공격의 작동 방식부터 서버를 안전하게 보호하기 위한 방어 전략까지, 구체적으로 알아보겠습니다.

HTTP/2 Continuation Flood 공격 완벽 분석 및 방어 전략

 

 

1. continuation flood 공격이란?

"continuation flood"는 HTTP/2의 구조적 특성을 악용한 새로운 DoS 공격 방식입니다. 공격자는 서버로 끊임없는 HTTP 헤더 스트림을 전송하여 서버 자원을 소모시키고, 이를 통해 서버를 느리게 하거나 다운시킵니다. 이 공격은 2009년 발생한 Slowloris 공격과 비슷하지만, HTTP/2 프로토콜에 맞춰진 특수한 방식으로 진화한 형태입니다.

 

1.1 공격 방식

1. 무한한 HTTP 헤더 전송: 공격자는 대상 서버로 끝없이 이어지는 HTTP 헤더 스트림을 전송합니다.
2. 연속적인 프레임 전송: HTTP/2의 특성을 이용해 연속 프레임(continuation frames)을 지속적으로 보내 서버의 자원을 점점 고갈시킵니다.
3. 서버 자원 소모: 이로 인해 서버는 가용 메모리가 소진되고, 요청이 끝나지 않기 때문에 서버가 멈추거나 다운됩니다.

 

1.2 기존 DoS 공격과의 차이점

전통적인 DoS 공격은 주로 많은 요청을 동시에 보내서 서버에 과부하를 일으키는 방식으로 동작합니다. 반면 continuation flood는 적은 수의 요청으로도 서버 자원을 고갈시킬 수 있어, 기존의 DoS 방어 도구로는 탐지하고 방어하기 어려운 특성을 가집니다.

1.3 취약한 서버는?

현재 확인된 바에 따르면, HTTP/2를 지원하는 주요 웹 서버들이 이 공격에 취약한 것으로 보고되고 있습니다. 다음과 같은 서버들이 취약한 서버 목록에 포함됩니다:

- Apache HTTP Server
- Node.js
- Go 표준 라이브러리 기반 서버

이 외에도 다양한 HTTP/2 지원 서버들이 이 공격에 영향을 받을 수 있으며, 이러한 서버를 운영하는 경우 보안 조치가 시급합니다.

 

2. continuation flood에 대한 대응 방안

서버를 안전하게 보호하기 위해서는 아래와 같은 다양한 대응 방안을 결합하여 사용하는 것이 좋습니다. 각각의 방안은 서버의 상황에 맞게 조정될 수 있으며, 다층적인 방어 체계를 구축하는 것이 중요합니다.

 

2.1 헤더 크기 제한 설정

서버가 처리할 수 있는 HTTP 헤더 블록의 크기를 제한하는 것이 첫 번째 방어 수단입니다. HTTP/2 표준에서는 서버가 처리 가능한 헤더의 크기를 설정할 수 있도록 허용하고 있습니다. 이를 통해 공격자가 무한정으로 헤더를 전송하는 것을 방지할 수 있습니다.

 

2.2 연속 프레임 제한

HTTP/2의 연속 프레임(continuation frames) 전송 수를 제한하는 것도 중요한 방어책입니다. 예를 들어, nghttp2 라이브러리는 하나의 요청에 대해 최대 8개의 연속 프레임만 허용하도록 기본 설정되어 있습니다. 이러한 제한을 통해 서버가 무한히 헤더를 처리하지 않도록 할 수 있습니다.

 

2.3 타임아웃 설정

HTTP 헤더가 일정 시간 내에 완료되지 않으면 연결을 강제로 끊는 타임아웃 설정도 효과적입니다. 이를 통해 서버가 끝없는 요청을 계속 대기하지 않도록 하여 자원을 보호할 수 있습니다.

 

2.4 동시 연결 수 제한

단일 IP 주소에서 발생하는 동시 연결 수를 제한하여 공격자가 하나의 IP로 여러 연결을 동시에 시도하는 것을 방지할 수 있습니다. 이를 통해 서버의 연결 수가 폭주하는 상황을 예방할 수 있습니다.

 

2.5 적절한 로깅

완료되지 않은 요청도 서버 로그에 기록되도록 적절한 로깅 설정이 필요합니다. 이를 통해 공격이 감지되지 않더라도, 서버 로그를 분석하여 조기에 공격 징후를 발견할 수 있습니다.

 

2.6 테스트 강화

서버의 취약성을 사전에 확인하고 방어하기 위해 h2spec과 같은 도구를 사용하여 HTTP/2의 적합성 테스트를 진행해야 합니다. 이를 통해 서버의 보안 설정을 점검하고 개선할 수 있습니다.

 

2.7 퍼즈 테스팅

Google의 OSS-fuzz와 같은 퍼즈 테스팅 도구를 활용하여 다양한 입력에 대해 서버의 반응을 테스트하고, 그 과정에서 서버의 취약점을 찾아내어 수정할 수 있습니다.

 

2.8 프로토콜 구현 주의

HTTP/2 프로토콜은 상당히 복잡하므로, 이를 구현할 때 보안을 최우선으로 고려하는 것이 중요합니다. 공격 벡터를 줄이기 위해 표준을 철저하게 준수하고, 보안 관점을 우선시해야 합니다.

 

3. AWS WAF를 활용한 continuation flood 방어

AWS 기반의 서버를 운영 중이라면, AWS WAF를 사용하여 효과적으로 continuation flood 공격을 방어할 수 있습니다. AWS WAF는 다양한 기능을 제공하며, 다음과 같은 방법을 통해 공격을 차단할 수 있습니다.

 

3.1 요청 속도 제한 (Rate Limiting)

AWS WAF에서 rate-based rule을 사용하면 특정 시간 동안 허용되는 최대 요청 수를 제한할 수 있습니다. 예를 들어, 5분 동안 500개 이상의 요청을 보내는 IP 주소를 자동으로 차단하는 설정을 할 수 있습니다.

 

3.2 HTTP 헤더 검사

AWS WAF는 HTTP 헤더 검사 기능을 통해 비정상적인 헤더 패턴을 감지하고 차단할 수 있습니다. HTTP/2 프로토콜에서 사용하는 pseudo 헤더의 내용을 검사하여 헤더 크기나 구조가 비정상적인 요청을 걸러낼 수 있습니다.

 

3.3 지리적 제한 (Geo-blocking)

공격이 특정 국가나 지역에서 집중적으로 발생하는 경우, 지리적 차단(Geo-blocking)을 통해 해당 지역의 트래픽을 차단할 수 있습니다. 이를 통해 서버 자원을 공격으로부터 보호할 수 있습니다.

 

3.4 AWS Managed Rules 사용

AWS WAF에서 제공하는 관리형 규칙(AWS Managed Rules)을 사용하면 SQL 인젝션, XSS 등의 공격을 방어할 수 있으며, 일반적인 웹 공격 패턴을 탐지하고 차단하는 데 매우 유용합니다.

 

3.5 커스텀 규칙 생성

continuation flood 공격의 특성에 맞춰 커스텀 규칙을 생성할 수 있습니다. 예를 들어, 연속적인 헤더 프레임 수를 제한하는 규칙을 만들어 공격을 방어할 수 있습니다.

 

3.6 로깅 및 모니터링

AWS WAF의 로깅 및 모니터링 기능을 활용하여 비정상적인 트래픽 패턴을 분석하고 공격을 조기에 탐지할 수 있습니다. 이를 통해 서버의 방어 체계를 지속적으로 최적화할 수 있습니다.

 

3.7 AWS Shield Advanced 사용

AWS WAF와 통합된 AWS Shield Advanced는 대규모 DDoS 공격을 방어하는 데 효과적입니다. Shield Advanced는 자동화된 완화 기능을 제공하며, 더 강력한 방어 체계를 구축할 수 있도록 지원합니다.

 

4. HTTP/3 도입: 해결책인가?

HTTP/3는 HTTP/2의 한계를 보완하기 위해 등장한 프로토콜로, QUIC을 기반으로 합니다. 이를 통해 일부 DoS 공격에 대한 방어력을 향상시킬 수 있지만, continuation flood와 같은 특정 공격을 완전히 방어하는 데는 한계가 있을 수 있습니다.

 

4.1 QUIC 프로토콜의 장점

HTTP/3는 UDP를 기반으로 하여 스트림이 독립적으로 처리되므로, 하나의 연결에서 문제가 발생해도 다른 연결에 영향을 주지 않습니다. 이는 HTTP/2와의 주요 차이점이며, 서버 자원의 효율적 사용을 가능하게 합니다. 이러한 구조적 차이는 Continuation flood 공격의 영향을 줄일 수 있습니다.

 

4.2 헤더 조작 문제는 여전히 존재

그러나 HTTP/3도 헤더 기반 공격을 완전히 해결하지는 못합니다. 끝없이 이어지는 헤더 스트림 전송 같은 취약점은 여전히 악용될 수 있습니다. 헤더 크기나 연속 프레임 수를 제한하는 등의 추가적인 방어 조치가 HTTP/3에서도 필요합니다.

 

4.3 효율적인 패킷 복구

QUIC은 패킷 손실이 발생할 경우 효율적으로 복구하는 메커니즘을 제공하므로, 네트워크 지연에 따른 성능 저하를 최소화할 수 있습니다. 이는 일부 DoS 공격에 대한 방어 효과를 높여줄 수 있습니다.

 

4.4 HTTP/3 도입과 추가 방어 필요성

HTTP/3는 HTTP/2보다 더 강력한 보안과 성능을 제공하지만, 여전히 헤더 크기 제한, 프레임 수 제한, 타임아웃 설정 등의 추가적인 보안 조치가 필요합니다. 이를 통해 서버가 continuation flood 공격뿐만 아니라 기타 유사한 공격으로부터도 안전하게 보호될 수 있습니다.

 

5. 결론

"continuation flood"와 같은 HTTP/2 기반의 공격은 서버 자원을 고갈시켜 웹 서비스의 안정성을 위협하는 심각한 문제입니다. 이를 방어하기 위해서는 헤더 크기와 프레임 수 제한, 타임아웃 설정, AWS WAF와 같은 다양한 보안 도구를 적극적으로 활용해야 합니다. 또한 HTTP/3로의 전환을 통해 일부 성능과 보안 개선을 기대할 수 있지만, 지속적인 보안 테스트와 개선이 필수적입니다.