NGINX App Protect DoS로 심각한 DoS 공격으로부터 gRPC 앱 보호

지난 2년간 상품과 서비스에 대한 고객 수요는 조직이 손쉽게 확장하고 더 빠르게 혁신하는 것이 얼마나 중요한지를 분명히 보여주었으며, 이에 따라 많은 조직이 모놀리식 아키텍처에서 클라우드 네이티브 아키텍처로의 전환을 가속화하고 있습니다. 최근 F5 보고서인 2021년 애플리케이션 전략 현황에 따르면, 애플리케이션을 현대화하는 조직의 수가 지난 한 해에만 133% 증가했습니다. 클라우드 지원 애플리케이션은 모듈식 분산 구조로 설계되며, 자동화된 방식으로 배포 및 관리됩니다. 기존 모놀리식 애플리케이션을 단순히 리프트 앤 시프트 방식으로 이전할 수도 있지만, 그렇게 해서는 비용이나 유연성 측면에서 아무런 이점을 얻을 수 없습니다. 클라우드 컴퓨팅 서비스가 제공하는 분산 모델의 이점을 최대한 활용하려면 모듈식으로 접근해야 합니다. 바로 마이크로서비스입니다.

마이크로서비스는 개발자가 서로 간에 그리고 기반 플랫폼과 구조적으로 독립된 경량 애플리케이션 서비스의 집합으로 애플리케이션을 구축할 수 있게 해주는 아키텍처 접근 방식입니다. 각 마이크로서비스는 고유한 프로세스로 실행되며, 명확하게 정의되고 표준화된 API를 통해 다른 서비스와 통신합니다. 각 서비스는 소규모 독립 팀이 개발하고 배포할 수 있습니다. 이러한 유연성 덕분에 조직은 성능, 비용, 확장성 및 신속한 혁신 역량 측면에서 더 큰 이점을 얻을 수 있습니다.

개발자는 효율성을 높이고 애플리케이션 배포를 가속화할 방법을 끊임없이 모색합니다. API는 소프트웨어 간 통신을 지원하고 개발에 필요한 구성 요소를 제공합니다. 웹 개발자는 HTTP를 사용하여 서버에 데이터를 요청하기 위해 처음에는 요청 세부 정보를 SOAP 형식의 XML 문서로 전송하는 방식을 사용했습니다. 하지만 XML 문서는 용량이 큰 편이고 상당한 오버헤드가 발생하며 개발하는 데 오랜 시간이 걸립니다.

그 이후 많은 개발자가 REST로 전환했습니다. REST는 상태 비저장 방식의 신뢰할 수 있는 웹 API를 만들기 위한 아키텍처 스타일이자 일련의 지침입니다. 이러한 지침을 준수하는 웹 API를 RESTful API라고 합니다. RESTful 웹 API는 일반적으로 HTTP 메서드를 기반으로 URL 인코딩된 매개변수를 통해 리소스에 액세스하며, 데이터 전송에는 JSON 또는 XML을 사용합니다. RESTful API를 사용하면 애플리케이션을 더 빠르게 개발할 수 있고 오버헤드도 줄어듭니다.

기술의 발전은 애플리케이션 설계를 개선할 새로운 기회를 제공합니다. 2015년 Google은 어떤 환경에서도 실행할 수 있는 최신 오픈 소스 RPC 프레임워크인 Google Remote Procedure Call(gRPC)을 개발했습니다. REST가 HTTP 1.1 프로토콜을 기반으로 요청-응답 통신 모델을 사용하는 반면, gRPC는 전송에 HTTP/2를 사용하고 클라이언트-응답 통신 모델을 채택하며, 서비스와 데이터를 기술하는 데 사용되는 인터페이스 정의 언어(IDL)로 프로토콜 버퍼(protobuf)를 사용해 이를 구현합니다. Protobuf는 구조화된 데이터를 직렬화하는 데 사용되며 단순성과 성능을 고려해 설계되었습니다. Protobuf의 효율성과 HTTP/2 사용 덕분에 gRPC는 REST보다 데이터 수신 시 약 7배, 데이터 전송 시 약 10배 더 빠릅니다. 또한 gRPC는 스트리밍 통신을 지원하며 여러 요청을 동시에 처리합니다.

개발자들은 gRPC가 짧은 지연 시간, 다중 언어 지원, 간결한 데이터 표현, 실시간 스트리밍을 제공하므로 RESTful API를 대신해 마이크로서비스를 구축할 수 있는 매력적인 대안이라고 생각합니다. 이러한 특성 덕분에 gRPC는 마이크로서비스 간 통신과 저전력·저대역폭 네트워크를 통한 통신에 특히 적합합니다. 또한 클라이언트와 서버 모두에서 특정 언어에 종속되지 않으면서도 안정성과 확장성이 뛰어난 새로운 서비스를 빠르고 효율적으로 구축하기가 더 쉬워 gRPC의 인기가 높아지고 있습니다.

gRPC 프로토콜의 개방성은 여러 이점을 제공하지만, 이 표준은 DoS 공격이 애플리케이션에 미칠 수 있는 영향으로부터 어떠한 보호 기능도 제공하지 않습니다. gRPC 애플리케이션도 기존 애플리케이션과 동일한 유형의 DoS 공격으로 피해를 입을 수 있습니다.

gRPC 앱에서 DoS 공격을 식별하기 어려운 이유

마이크로서비스와 컨테이너는 개발자가 더 큰 자유와 자율성을 바탕으로 새로운 기능을 고객에게 신속하게 출시할 수 있도록 해 주지만, 새로운 취약점과 악용 가능성도 초래합니다. 최근 널리 확산된 사이버 공격 유형 중 하나는 서비스 거부(DoS) 공격입니다. 최근 몇 년간 DoS 공격과 관련된 공통 취약점 및 노출(CVE)이 증가했으며, 그중 상당수는 gRPC 요청을 부적절하게 처리하여 발생했습니다. 최근 몇 년간 애플리케이션과 API를 겨냥한 레이어 7 DoS 공격은 20% 급증했으며 그 영향의 규모와 심각도는 약 200% 증가했습니다.

DoS 공격은 일반적으로 정상적인 것처럼 보이는 대량의 트래픽을 전송하여 애플리케이션의 리소스를 고갈시키고 응답하지 못하게 합니다. 일반적인 DoS 공격에서 악의적인 공격자는 웹사이트나 애플리케이션에 막대한 트래픽을 집중시켜 서버가 모든 요청을 감당하지 못하고 멈추거나 심지어 다운되게 합니다. DoS 공격은 시스템이나 네트워크의 속도를 저하시키거나 완전히 마비시켜 필요한 사용자가 접근할 수 없도록 설계됩니다. 공격이 완화될 때까지 전자상거래 사이트, 이메일, 온라인 계정 등 해당 시스템이나 네트워크에 의존하는 서비스를 사용할 수 없습니다.

최근에는 HTTP 및 HTTP/2 요청이나 API 호출을 이용해 애플리케이션 계층(계층 7)을 공격하는 DoS 공격이 점점 더 늘고 있습니다. 이는 주로 계층 7 공격이 최신 애플리케이션 아키텍처를 방어하도록 설계되지 않은 기존 방어 체계를 우회할 수 있기 때문입니다. 공격자들이 네트워크 계층(계층 3 및 4)을 노리는 기존의 대규모 트래픽 공격에서 계층 7 공격으로 전환한 이유는 무엇일까요? 가장 저항이 적은 경로를 택한 것입니다. 인프라 엔지니어들은 수년간 계층 3 및 계층 4 공격에 대한 효과적인 방어 메커니즘을 구축해 왔으며, 그 결과 이러한 공격은 차단하기가 더 쉬워지고 성공 가능성도 낮아졌습니다. 이로 인해 이러한 공격을 감행하는 데 드는 비용과 시간이 모두 증가했고, 결국 공격자들은 다른 공격 방식으로 옮겨 갔습니다.

gRPC 애플리케이션에 대한 DoS 공격을 탐지하는 것은 매우 어렵습니다. 특히 자동으로 스케일 아웃되는 최신 환경에서는 더욱 그렇습니다. gRPC 서비스는 대량의 트래픽을 처리하도록 설계되지 않았을 수 있으므로 공격자가 쉽게 중단시킬 수 있습니다. 또한 gRPC 서비스는 h2load와 같은 도구를 이용한 HTTP/2 플러드 공격에도 취약합니다. 이뿐만 아니라 공격자가 protobuf 명세에 올바르게 선언된 데이터 정의를 악용할 경우 gRPC 서비스가 손쉽게 공격 대상이 될 수 있습니다.

일반적으로 gRPC 서비스가 의도치 않게 오용되는 사례로는 스크립트의 버그로 인해 서비스에 과도한 요청이 발생하는 경우가 있습니다. 예를 들어 자동화 스크립트가 특정 조건이 충족될 때 API 호출을 실행하며, 설계자는 이 조건이 2초마다 충족될 것으로 예상한다고 가정해 보겠습니다. 하지만 조건 정의의 오류로 인해 스크립트가 2밀리초마다 호출을 실행하면 백엔드 gRPC 서비스에 예기치 않은 부하가 발생합니다.

gRPC 애플리케이션에 대한 DoS 공격의 다른 예는 다음과 같습니다:

• gRPC 메시지에 악성 필드를 삽입하면 애플리케이션에 장애가 발생할 수 있습니다.
• Slow POST 공격은 gRPC 헤더에 불완전한 요청을 전송합니다. 애플리케이션 또는 서버는 요청의 나머지 부분이 도착할 것으로 예상하여 연결을 열린 상태로 유지합니다. 이로 인해 동시 연결 풀이 가득 차서 클라이언트의 추가 연결 시도가 거부될 수 있습니다.
• HTTP/2 설정 플러드(CVE-2019-9515)는 공격자가 빈 SETTING 프레임을 gRPC 프로토콜로 전송하여 NGINX 리소스를 소모시킴으로써 새로운 요청을 처리할 수 없게 만드는 공격입니다.

동적 사용자 및 사이트 행동 분석의 강력한 기능을 활용하여 NGINX App Protect DoS로 gRPC DoS 공격 완화

오늘날의 DoS 공격으로부터 애플리케이션을 보호하려면 현대적인 접근 방식이 필요합니다. 복잡하고 변화에 유연하게 대응하는 애플리케이션을 보호하려면 사용자 및 사이트 동작을 기반으로 매우 정밀하고 동적인 보호 기능을 제공하고, 신속한 애플리케이션 개발과 경쟁 우위 확보를 지원하는 동시에 보안 팀의 부담을 덜어 주는 솔루션이 필요합니다.

F5 NGINX App Protect DoS는 F5의 시장 선도적인 WAF 및 행동 기반 보호 기술을 토대로 구축된 NGINX Plus용 경량 소프트웨어 모듈입니다. NGINX App Protect DoS는 가장 정교한 계층 7 DoS 공격까지 방어하도록 설계되었으며, 고유한 알고리즘을 사용해 적응형 머신 러닝과 자동화된 보호 기능을 제공하는 동적 통계 모델을 생성합니다. 완화 효과를 지속적으로 측정하고 변화하는 사용자 및 사이트 행동에 맞게 조정하며, 선제적인 서버 상태 점검을 수행합니다. 자세한 내용은 블로그의 진화하는 공격 환경에 NGINX App Protect 서비스 거부 방지 기능이 적응하는 방식을 참조하세요.

기존 HTTP 앱과 최신 HTTP/2 앱 헤더 모두에 대해 행동 분석이 제공됩니다. NGINX App Protect DoS는 시그니처와 악성 행위자 식별을 모두 기반으로 공격을 완화합니다. 초기 시그니처 완화 단계에서 NGINX App Protect DoS는 비정상적인 행동과 관련된 속성을 프로파일링하여 동적 시그니처를 생성하고, 이후 이 행동과 일치하는 요청을 차단합니다. 공격이 지속되면 NGINX App Protect DoS는 악성 행위자 완화 단계로 전환합니다.

통계적 이상 탐지를 기반으로 NGINX App Protect DoS는 소스 IP 주소와 TLS 지문을 통해 악의적 행위자를 정확히 식별하고, 이러한 특정 공격 트래픽 패턴을 자동으로 식별하고 완화하는 동적 시그니처를 생성하여 배포할 수 있습니다. 이 접근 방식은 트래픽 양이 임계값을 초과할 때 이를 탐지하는 기존의 일반적인 DoS 솔루션과는 다릅니다. NGINX App Protect DoS는 요청이 완전히 정상적으로 보이고 각 공격자가 생성하는 트래픽이 일반적인 정상 사용자의 평균 트래픽보다 적은 경우에도 공격을 차단할 수 있습니다.

다음 Kibana 대시보드는 NGINX App Protect DoS가 gRPC 애플리케이션에 대한 DoS 플러드 공격을 신속하게 자동으로 탐지하고 완화하는 방법을 보여줍니다.

그림 1은 DoS 플러드 공격을 받고 있는 gRPC 애플리케이션을 보여 줍니다. gRPC에서 중요한 메트릭은 초당 메시지 전송률에 해당하는 초당 데이터그램 수(DPS)입니다. 이 이미지에서 노란색 곡선은 학습 과정을 나타냅니다. 즉, 기준 DPS 예측값이 수신 DPS 값(파란색)에 수렴하면 NGINX App Protect가 이 애플리케이션의 “정상” 트래픽이 어떤 형태인지 학습한 것입니다. 12:25:00에 DPS가 급격히 증가한 것은 공격이 시작되었음을 나타냅니다. 빨간색 경보 벨은 NGINX App Protect DoS가 공격이 진행 중이라고 확신하고 완화 단계를 시작하는 시점을 나타냅니다.

그림 1: DoS 공격을 받고 있는 gRPC 애플리케이션

그림 2는 NGINX App Protect DoS가 비정상 동작을 탐지하고 단계적 완화 방식을 사용하여 gRPC DoS 플러드 공격을 차단하는 과정을 보여 줍니다. 빨간색 급증 구간은 전역 속도 완화 단계에서 모든 클라이언트로 전송된 HTTP/2 리디렉션 수를 나타냅니다. 보라색 그래프는 요청이 비정상 동작을 모델링한 시그니처와 일치할 때 특정 클라이언트로 전송된 리디렉션을 나타냅니다. 노란색 그래프는 IP 주소와 TLS 지문을 통해 식별되어 탐지된 특정 악성 행위자에게 전송된 리디렉션을 나타냅니다.

그림 2: 단계적 완화 접근 방식을 사용하여 gRPC DoS 플러드 공격을 차단하는 NGINX App Protect DoS

그림 3은 머신 러닝을 기반으로 NGINX App Protect DoS가 생성한 동적 시그니처를 보여 줍니다. 이 시그니처는 해당 gRPC 플러드 공격에서 나타난 비정상 동작과 관련된 속성을 프로파일링하며, 초기 시그니처 완화 단계에서 일치하는 요청을 차단합니다.

그림 3: 동적 시그니처

그림 4는 공격이 지속될 때 NGINX App Protect DoS가 시그니처 기반 완화에서 악성 행위자 완화로 전환하는 방식을 보여줍니다. NGINX App Protect DoS는 사용자 행동을 분석하여 여기에 표시된 소스 IP 주소와 TLS 지문을 기준으로 악성 행위자를 식별했습니다. 비정상적인 행동을 나타내는 특정 시그니처가 있는지 모든 요청을 검사하는 대신, 여기서는 특정 공격자에 대한 서비스 제공을 차단합니다. 이를 통해 이러한 특정 공격 패턴을 식별하고 자동으로 완화하는 동적 시그니처를 생성할 수 있습니다.

그림 4: IP 주소와 TLS 지문을 통해 악의적 행위자를 식별하는 NGINX App Protect DoS

gRPC API에서는 gRPC 인터페이스를 사용하여 유형 라이브러리(IDL) 파일과 protobuf용 proto 정의 파일에 보안 정책을 설정합니다. 이를 통해 제로 터치 보안 정책 솔루션을 제공하므로 gRPC 서비스를 공격으로부터 보호하기 위해 protobuf 정의에 의존할 필요가 없습니다. gRPC proto 파일은 흔히 CI/CD 파이프라인의 일부로 사용되며, 보호를 자동화하고 전체 CI/CD 파이프라인 통합을 위한 코드형 보안을 지원함으로써 보안 팀과 개발 팀 간의 협업을 강화합니다. NGINX App Protect DoS는 보호 기능을 gRPC 애플리케이션에 원활하게 통합하여 애플리케이션이 항상 최신 보안 정책으로 보호되도록 함으로써 일관된 보안을 보장합니다.

gRPC는 개발자가 최신 애플리케이션을 설계하고 배포하는 데 필요한 속도와 유연성을 제공하지만, 프레임워크가 본질적으로 개방되어 있어 DoS 공격에 매우 취약합니다. 성능 저하, 애플리케이션 및 웹사이트 중단, 매출 손실, 고객 충성도 및 브랜드 훼손을 초래할 수 있는 심각한 레이어 7 DoS 공격에 선제적으로 대응하려면 최신 방어 체계가 필요합니다. 이러한 이유로 NGINX App Protect DoS는 최신 gRPC 애플리케이션에 필수적입니다.

NGINX Plus와 함께 NGINX App Protect DoS를 직접 사용해 보려면 지금 30일 무료 평가판을 시작하거나 문의하여 사용 사례에 대해 상담해 보세요.

자세한 내용은 다음 백서를 참조하세요. 「레이어 7 DoS 공격으로부터 최신 앱 보호하기」

---