지난 2년 동안 상품과 서비스에 대한 고객 수요는 조직이 쉽게 확장하고 더 빠르게 혁신하는 것이 얼마나 중요한지 강조해 주었으며, 많은 조직이 모놀리식 아키텍처에서 클라우드 네이티브 아키텍처로의 전환을 가속화하게 되었습니다. 최근 F5 보고서인 '2021 애플리케이션 전략 현황' 에 따르면, 애플리케이션을 현대화하는 조직의 수가 작년 한 해 동안만 133% 증가했습니다. 클라우드 기반 애플리케이션은 모듈식으로 설계되어 자동화된 방식으로 분산, 배포 및 관리됩니다. 기존의 모놀리식 애플리케이션을 간단히 리프트 앤 시프트 방식으로 이전할 수는 있지만, 비용이나 유연성 측면에서 아무런 이점이 없습니다. 클라우드 컴퓨팅 서비스가 제공하는 분산 모델의 이점을 얻는 가장 좋은 방법은 모듈식으로 생각하는 것입니다. 바로 마이크로서비스 입니다.
마이크로서비스는 개발자가 서로 구조적으로 독립적이고 기본 플랫폼에도 독립적인 일련의 가벼운 애플리케이션 서비스로 애플리케이션을 구축할 수 있도록 하는 아키텍처적 접근 방식입니다. 각 마이크로서비스는 고유한 프로세스로 실행되며, 잘 정의되고 표준화된 API를 통해 다른 서비스와 통신합니다. 각 서비스는 소규모 독립 팀이 개발하고 배포할 수 있습니다. 이러한 유연성은 조직에 성과, 비용, 확장성, 신속한 혁신 능력 측면에서 더 큰 이점을 제공합니다.
개발자들은 항상 효율성을 높이고 애플리케이션 배포를 신속하게 진행할 수 있는 방법을 찾고 있습니다. API는 소프트웨어 간 통신을 가능하게 하고 개발을 위한 기본 요소를 제공합니다. HTTP를 사용하여 서버에 데이터를 요청하기 위해 웹 개발자는 원래 SOAP를 사용했습니다. SOAP는 요청 세부 정보를 XML 문서로 전송합니다. 그러나 XML 문서는 일반적으로 크고, 상당한 오버헤드가 필요하며, 개발하는 데 시간이 오래 걸립니다.
그 이후로 많은 개발자들이 REST 로 전환했습니다. REST는 상태 비저장, 안정적인 웹 API를 만드는 아키텍처 스타일이자 가이드라인입니다. 이러한 지침을 따르는 웹 API를 RESTful이라고 합니다. RESTful 웹 API는 일반적으로 URL로 인코딩된 매개변수를 통해 리소스에 액세스하고 JSON 또는 XML을 사용하여 데이터를 전송하는 HTTP 메서드를 기반으로 합니다. RESTful API를 사용하면 애플리케이션을 더 빨리 개발할 수 있고 오버헤드도 줄어듭니다.
기술의 발전은 애플리케이션 디자인을 발전시키는 새로운 기회를 가져다줍니다. 2015년에 Google은 어떤 환경에서도 실행될 수 있는 최신 오픈소스 RPC 프레임워크인 Google Remote Procedure Call( gRPC )을 개발했습니다. REST는 HTTP 1.1 프로토콜을 기반으로 하며 요청-응답 통신 모델을 사용하는 반면, gRPC는 전송을 위해 HTTP/2를 사용하고 클라이언트-응답 통신 모델을 사용하며 이는 서비스와 데이터를 설명하는 데 사용되는 인터페이스 설명 언어(IDL)인 프로토콜 버퍼 (protobuf)에 구현됩니다. Protobuf는 구조화된 데이터를 직렬화하는 데 사용되며 단순성과 성능을 염두에 두고 설계되었습니다. gRPC는 protobuf의 효율성과 HTTP/2 사용으로 인해 데이터를 수신할 때는 REST보다 약 7배, 데이터를 보낼 때는 10배 더 빠릅니다. 또한 gRPC는 스트리밍 통신을 허용하고 여러 요청을 동시에 처리합니다.
개발자들은 gRPC를 사용하여 마이크로서비스를 구축하는 것이 RESTful API를 사용하는 것에 비해 매력적인 대안이라고 생각합니다. gRPC는 낮은 대기 시간, 여러 언어 지원, 컴팩트한 데이터 표현, 실시간 스트리밍 등의 장점을 가지고 있기 때문에 마이크로서비스 간 통신과 저전력, 저대역폭 네트워크 통신에 특히 적합합니다. gRPC는 클라이언트와 서버 모두에서 언어에 구애받지 않고 더 빠르고 효율적으로 새로운 서비스를 구축하기 쉽고 안정성과 확장성이 더 뛰어나기 때문에 인기가 높아지고 있습니다.
gRPC 프로토콜의 개방적 특성은 여러 가지 긍정적인 이점을 제공하지만 이 표준은 DoS 공격이 애플리케이션에 미칠 수 있는 영향으로부터 어떠한 보호 기능도 제공하지 않습니다. gRPC 애플리케이션은 기존 애플리케이션과 마찬가지로 동일한 유형의 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 공격의 다른 예는 다음과 같습니다.
POST
공격은 gRPC 헤더에 부분적인 요청을 보냅니다. 나머지 요청이 도착할 것을 예상하여 애플리케이션이나 서버는 연결을 계속 열어 둡니다. 동시 연결 풀이 가득 차면 클라이언트의 추가 연결 시도가 거부될 수 있습니다.SETTING
프레임을 보내는 HTTP/2 설정 플러드 ( CVE-2019-9515 ) 공격은 NGINX 리소스를 소모하여 새로운 요청을 처리할 수 없게 만듭니다.오늘날의 DoS 공격으로부터 애플리케이션을 보호하려면 현대적인 접근 방식이 필요합니다. 복잡하고 적응형 애플리케이션을 보호하려면 사용자 및 사이트 동작을 기반으로 매우 정확하고 동적인 보호 기능을 제공하고, 보안 팀의 부담을 덜어주면서 신속한 애플리케이션 개발과 경쟁 우위를 지원하는 솔루션이 필요합니다.
F5 NGINX App Protect DoS는 F5의 시장 선도적 WAF와 행동 보호 기술을 기반으로 구축된 NGINX Plus용 경량 소프트웨어 모듈입니다. 가장 정교한 7계층 DoS 공격도 방어하도록 설계된 NGINX App Protect 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분에 DPS가 급격히 상승하면 공격의 시작을 알립니다. 빨간색 경보 벨은 NGINX App Protect DoS가 공격이 진행 중이라고 확신하고 완화 단계를 시작하는 시점을 나타냅니다.
그림 2는 단계적 완화 접근 방식을 사용하여 비정상적인 동작을 감지하고 gRPC DoS 플러드 공격을 차단하는 과정에서의 NGINX App Protect DoS를 보여줍니다. 빨간색 스파이크는 글로벌 속도 완화 단계 동안 모든 클라이언트에 전송된 HTTP/2 리디렉션 수를 나타냅니다. 보라색 그래프는 비정상적인 동작을 모델링한 서명과 요청이 일치할 때 특정 클라이언트에 전송되는 리디렉션을 나타냅니다. 노란색 그래프는 IP 주소와 TLS 지문으로 식별된 특정 악성 행위자에게 전송된 리디렉션을 나타냅니다.
그림 3은 머신 러닝을 기반으로 하는 NGINX App Protect DoS가 생성한 동적 서명을 보여주며, 이 gRPC 플러드 공격의 비정상적인 동작과 관련된 속성을 프로파일링합니다. 서명은 초기 서명 완화 단계에서 일치하는 요청을 차단합니다.
그림 4는 공격이 지속될 때 NGINX App Protect DoS가 서명 기반 완화에서 악의적 행위자 완화로 어떻게 전환되는지 보여줍니다. NGINX App Protect DoS는 사용자 동작을 분석하여 여기에 표시된 소스 IP 주소와 TLS 지문을 통해 나쁜 행위자를 식별했습니다. 비정상적인 동작을 나타내는 구체적인 서명에 대한 모든 요청을 살펴보는 대신, 여기에서는 특정 공격자에게 서비스를 거부합니다. 이를 통해 특정 공격 패턴을 식별하고 자동으로 완화하는 동적 시그니처를 생성할 수 있습니다.
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 공격으로부터 현대 앱 보호하기' 백서를 확인하세요.
"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."