gRPC DoS 공격 NGINX App Protect로 방어

오늘 포스트에서는 gRPC DoS 공격으로부터 gRPC 앱 보호에 대한 이야기를 다룰 것입니다. 먼저 NGINX App Protect DoS를 사용하여 gRPC DoS 공격을 방어하는 내용에 대해 살펴보겠습니다. NGINX App Protect는 NGINX Plus용 경량 보안 소프트웨어 모듈입니다.

목 차

1. gRPC 란?
2. gRPC 앱에서 DoS 공격을 식별하는 것이 어려운 이유
3. NGINX App Protect DoS 사용 이유
4. 결론

1. gRPC 란?

지난 2년 동안 제품 및 서비스에 대한 고객의 요구는 조직이 쉽게 확장하고 더 빠르게 혁신하는 것이 얼마나 중요한지 강조하여 많은 조직이 모놀리식에서 클라우드 네이티브 아키텍처로의 움직을 가속하도록 이끌었습니다. 최근 F5 보고서인 The State of Application Strategy 2021 에 따르면 애플리케이션을 현대화하는 조직의 수가 작년 한 해에만 133% 증가했습니다. 클라우드 기반 애플리케이션은 모듈식으로 설계되어 자동화된 방식으로 분산, 배포 및 관리됩니다. 기존 모놀리식 애플리케이션을 간단히 Lift and Shift 하는 것이 가능하지만 그렇게 하면 비용이나 유연성 측면에서 이점이 없습니다. 클라우드 컴퓨팅 서비스가 제공하는 분산 모델의 이점을 얻을 수 있는 가장 좋은 방법은 모듈식으로 생각하는 것입니다.

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

개발자는 항상 효율성을 높이고 애플리케이션 배포를 촉진할 방법을 찾고 있습니다. API는 소프트웨어 간 통신을 가능하게 하고 개발을 위한 빌딩 블록을 제공합니다. HTTP를 사용하여 서버에서 데이터를 요청하기 위해 웹 개발자는 원래 요청 세부 정보를 XML 문서로 보내는 SOAP를 사용했습니다. 그러나 XML 문서는 크기가 크고 상당한 오버헤드가 필요하며 개발하는 데 오랜 시간이 걸리는 경향이 있습니다.

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

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

개발자는 gRPC로 마이크로서비스를 구축하는 것이 짧은 대기 시간, 다국어 지원, 치밀한 데이터 표현 및 실시간 스트리밍으로 인해 RESTful API 사용에 대한 매력적인 대안임을 알게 되었습니다. 저대역폭 네트워크. gRPC는 더 높은 안정성과 확장성, 클라이언트와 서버 모두에 대한 언어 독립성으로 새로운 서비스를 빠르고 효율적으로 구축하기 쉬우므 때문에 인기가 많아졌습니다.

gRPC 프로토콜의 개방성은 몇 가지 긍정적인 이점을 제공하지만, 표준은 DoS 공격이 애플리케이션에 미칠 수 있는 영향으로부터 어떠한 보호도 제공하지 않습니다. gRPC 애플리케이션은 여전히 ​​기존 애플리케이션과 같 유형의 DoS 공격을 받을 수 있습니다.

2. gRPC 앱에서 DoS 공격을 식별하는 것이 어려운 이유

마이크로서비스와 컨테이너는 개발자에게 새로운 기능을 고객에게 신속하게 릴리스할 수 있는 더 많은 자유와 자율성을 제공하지만 새로운 취약점과 악용 기회도 생기기 마련입니다. 일반적 사이버 공격 유형 중 하나는 DoS(서비스 거부) 공격으로, 최근 몇 년 동안 gRPC 요청의 부적절한 처리로 인해 발생하는 CVE(일반적인 취약성 및 노출)의 수가 증가했습니다. 애플리케이션 및 API에 대한 7계층 DoS 공격은 최근 몇 년 동안 20% 급증했으며 영향의 규모와 심각도는 거의 200% 증가했습니다.

DoS 공격은 일반적으로 합법적으로 보이는 대량의 트래픽을 전송하여 애플리케이션의 리소스를 고갈시키고 응답하지 않게 만듭니다. 일반적인 DoS 공격에서 공격자는 수많은 트래픽으로 웹사이트나 애플리케이션을 넘치게 하여 서버가 모든 요청에 ​​압도되어 중단되거나 충돌을 일으킵니다. DoS 공격은 시스템이나 네트워크를 느리게 하거나 완전히 비활성화하여 필요한 사람들이 액세스할 수 없도록 설계되었습니다. 공격이 완화될 때까지 전자상거래 사이트, 이메일 및 온라인 계정과 같은 시스템 또는 네트워크에 의존하는 서비스는 사용할 수 없습니다.

점점 더 많은 DoS 공격이 애플리케이션 계층( 7계층 )을 공격하기 위해 HTTP 및 HTTP/2 요청 또는 API 호출을 사용하는 것이 목격되었습니다. 그 이유는 대부분 계층 7 공격이 최신 애플리케이션 아키텍처를 방어하도록 설계되지 않은 기존 방어를 우회할 수 있기 때문입니다. 공격자가 네트워크 계층( 3계층 및 4계층 )의 기존 볼륨 공격에서 7계층 공격으로 전환한 이유는 무엇일까? 그들은 저항이 가장 적은 길을 공략하기 때문입니다. 인프라 엔지니어들은 3 계층 및 4계층 공격에 대한 효과적인 방어 메커니즘을 구축하여 차단하기가 더 쉽고 공격에 성공할 가능성이 습니다.이로 인해 공격을 시작하는 데 더 비용과 시간이 들기 때문에 공격자들이 전환하였습니다.

특히 확장이 자동으로 수행되는 최신 환경에서 gRPC 애플리케이션에 대한 DoS 공격을 감지하는 것은 매우 어렵습니다. gRPC 서비스는 대량 트래픽을 처리하도록 설계되지 않았으므로 공격자가 쉽게 타겟팅 할 수 있습니다. 또한 gRPC 서비스는 h2load와 같은 도구를 사용한 HTTP/2 Flood 공격에도 취약합니다. 그리고 gRPC 서비스는 공격자가 protobuf 사양에서 올바르게 선언된 데이터 정의를 악용할 때 쉽게 표적이 될 수 있습니다.

의도하지 않은 gRPC 서비스의 일반적인 오용은 스크립트의 버그로 인해 서비스에 대한 과도한 요청이 생성되는 경우입니다. 예를 들어 디자이너가 2초마다 발생할 것으로 예상하는 특정 조건이 발생할 때 자동화 스크립트가 API 호출을 발행한다고 가정합니다. 그러나 조건 정의 오류로 인해 스크립트가 2ms마다 호출을 발행하여 백엔드 gRPC 서비스에 예기치 않은 부담을 줍니다.

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

  • gRPC 메시지에 악의적인 필드를 삽입하면 애플리케이션이 실패할 수 있습니다.
  • Slow POST attack은 gRPC 헤더에서 부분 요청을 보냅니다. 요청의 나머지 부분이 도착할 것으로 예상하면 애플리케이션이나 서버는 연결을 열린 상태로 유지합니다. 동시 연결 풀이 가득 차서 클라이언트의 추가 연결 시도가 거부될 수 있습니다.
  • 공격자가 빈 프레임을 gRPC 프로토콜로 보내는 HTTP/2 Settings Flood ( CVE-2019-9515 ) 는 NGINX 리소스를 소비하여 새로운 요청을 처리할 수 없게 만듭니다.

3. NGINX App Protect DoS 사용 이유

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

NGINX App Protect DoS 는 시장을 선도하는 F5의 WAF 및 동작 보호를 기반으로 구축된 NGINX Plus용 경량 소프트웨어 모듈입니다. 가장 정교한 Layer 7 DoS 공격도 방어하도록 설계된 NGINX App Protect DoS 는 고유한 알고리즘을 사용하여 적응형 기계 학습 및 자동화된 보호를 제공하는 동적 통계 모델을 생성합니다. 완화 효과를 지속해 측정하고 변화하는 사용자 및 사이트 동작에 적응하며 선제적인 서버 상태 검사를 수행합니다.

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

NGINX App Protect DoS 는 통계적 이상 탐지를 기반으로 Source IP 주소 및 TLS fingerprints으로 공격자를 성공적으로 식별하여 이러한 특정 공격 트래픽 패턴을 자동으로 식별하고 완화하는 동적 서명을 생성하고 배포할 수 있습니다. 이 접근 방식은 볼륨 임계 값이 초과 때 이를 감지하는 시중의 기존 DoS 솔루션과 다릅니다. NGINX App Protect DoS 는 요청이 완전히 합법적인 것처럼 보이고 각 공격자가 평균적이 합법적인 사용자보다 적은 트래픽을 생성할 수 있는 공격을 차단할 수 있습니다.

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

그림 1은 DoS 플러드 공격이 발생한 gRPC 애플리케이션을 보여줍니다. gRPC와 관련하여 중요한 메트릭은 초당 메시지 비율에 해당하는 초당 데이터그램(DPS)입니다. 이 이미지에서 노란색 곡선은 학습 프로세스를 나타냅니다. Baseline DPS 예측이 Incoming DPS 값(파란색)으로 수렴되면 NGINX App Protect 는 이 애플리케이션의 “normal” 트래픽이 어떤 모습인지 학습했습니다. 12:25:00에 DPS가 급격히 상승하면 공격 시작을 알립니다. 빨간색 알람 벨은 NGINX App Protect DoS 가 공격이 진행 중임을 확신하고 완화 단계를 시작하는 시점을 나타냅니다.

DoS 공격을 받는 gRPC 애플리케이션

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

그림 2는 NGINX App Protect DoS가 비정상적인 동작을 감지하고 단계적 완화 접근 방식을 사용하여 gRPC DoS 플러드 공격을 저지하는 과정을 보여줍니다. 빨간색 스파이크는 전역 속도 완화 단계 동안 모든 클라이언트에 전송된 HTTP/2 리다이렉션수를 나타냅니다. 보라색 그래프는 요청이 비정상적인 동작을 모델링하는 서명과 일치할 때 특정 클라이언트로 전송되는 리다이렉션을 나타냅니다. 노란색 그래프는 IP 주소 및 TLS fingerprint으로 식별된 특정 악성 행위자에게 전송된 리다이렉션을 나타냅니다.

gRPC DoS 플러드 공격을 저지하기 위해 단계적 완화 접근 방식을 사용하는 NGINX 앱 보호 DoS

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

그림 3은 기계 학습을 기반으로 하는 NGINX App Protect DoS 에서 생성한 동적 서명을 보여주고 이 gRPC 플러드 공격의 비정상적인 동작과 관련된 특성을 프로파일링합니다. 서명은 초기 서명 완화 단계에서 일치하는 요청을 차단합니다.

동적 서명

그림 3: 동적 서명

그림 4는 공격이 지속될 때 NGINX App Protect DoS 가 서명 기반(signature‑based) 완화에서 불량 행위자(bad‑actor mitigation) 완화로 어떻게 이동하는지 보여줍니다. NGINX App Protect DoS 는 사용자 행동을 분석하여 여기에 표시된 Source IP 주소와 TLS fingerprints으로 악의적인 행위자를 식별했습니다. 비정상적인 동작을 나타내는 특정 서명에 대한 모든 요청을 살펴보는 대신 여기에서 특정 공격자에 대한 서비스가 거부됩니다. 이를 통해 이러한 특정 공격 패턴을 식별하고 자동으로 완화하는 동적 서명을 생성할 수 있습니다.

NGINX 앱 보호 DoS는 IP 주소 및 TLS 지문으로 악의적 행위자를 식별합니다.

그림 4: NGINX App Protect DoS 는 IP 주소 및 TLS fingerprints으로 악의적 행위자를 식별합니다.

4. 결론

gRPC API를 사용하면 gRPC 인터페이스를 사용하여 형식 라이브러리(IDL) 파일과 protobuf에 대한 proto 정의 파일에 보안 정책을 설정할 수 있습니다. 이는 zero-touch 보안 정책 솔루션을 제공합니다. 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일 평가판을 시작하거나 당사에 연락하여 사용 사례에 대해 논의하십시오.

사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.