NGINX 보안 취약점 완화 방안

오늘날 많은 서비스들이 NGINX를 의존하는 것을 고려할 때 NGINX 보안 취약점은 서비스의 큰 위협이 됩니다. 그들이 오늘날 인터넷에서 매우 보편화된 CVE(Common Vulnerabilities and Exposure)와 같은 보안 취약점 에 대한 수정 사항이 있는 최신 버전을 실행하는 것의 중요성에 대해 별로 생각하지 않는다는 사실에 놀랐습니다.

물론 NGINX 보안 취약점 으로부터 보호하는 것에 대해 생각하는 것만으로는 충분하지 않습니다. NGINX 보안 취약점 을 추적하고 보호 기능을 사용할 수 있는 잘 정의된 프로세스를 구현해야 합니다. Open Source 소프트웨어의 경우처럼 모든 작업을 직접 수행해야 하는 경우 얼마나 많은 시간과 노력이 소요될 수 있는지 예상하기 어렵습니다. 실제로 보안 취약점으로부터 자신을 빠르고 쉽게 보호하는 것은 NGINX Plus와 같은 상업적으로 지원되는 소프트웨어의 이점 중 하나입니다.

이 포스트에서는 Open Source 소프트웨어 보호하는 문제를 살펴보고 NGINX Plus가 CVE 및 기타 NGINX 보안 취약점 을 훨씬 빠르고 쉽게 완화하는 방법에 대해 설명합니다.

목차

1. Open Source 소프트웨어의 취약점 처리
1-1. NGINX 보안 취약점 보고
1-2. NGINX 및 CVEs
2. NGINX Plus가 보안 취약점 을 보호하는 방법
2-1. NGINX는 NGINX Plus 구독자에게 패치에 대해 사전에 알립니다.
2-2. 공격을 받고 있는 NGINX Plus 구독자에게 실시간 도움말을 제공합니다.
2-3. NGINX App Protect 애플리케이션 보호 향상
2-4. NGINX Plus는 JWT 기반 및 OpenID Connect 인증을 지원합니다.
2-5. NGINX Plus 구독자는 즉시 패치를 받습니다.
3. NGINX 보안 취약점 해결 방안, 결론

1. Open Source 소프트웨어의 취약점 처리

모든 개발자들이 완벽한 코드를 작성한다고 생각하는 만큼, 버그가 없는 소프트웨어는 없습니다. 개발자는 개발 중에 대부분의 버그가 감지되기를 바라며, 애플리케이션 수명 동안 정상적인 사용에서 몇 가지만 발견됩니다. 최악의 경우 나쁜 의도를 가진 악의적인 사용자가 버그를 발견할 수도 있습니다.

버그의 결과는 여러 Open Source 도구, 프로그래밍 언어 및 플랫폼에서 애플리케이션 스택을 구성할 때 크게 복잡해집니다. 버그가 없는지 확인하려면 각 구성 요소를 개별적으로 검토해야 합니다. Open Source 소프트웨어에서 버그가 발견되면 이를 검증, 테스트 및 가능한 경우 수정하기 위한 정책을 정의하는 것이 중요합니다.

Open Source 소프트웨어에 대한 정책에는 최소한 세 가지 프로세스가 포함되어야 합니다.

  1. 정기적인 검토 및 테스트
  2. 취약점 추적 및 내부 보고
  3. 취약점을 적시에 해결

1-1. NGINX 보안 취약점 보고

보안 취약점이 발견되면 이를 공개하기 위한 표준 이벤트 시퀀스가 있습니다. 첫 번째 단계는 소프트웨어 작성자 또는 공급업체에 상세 보고서를 제출하는 것입니다. 보고자와 작성자는 일반적으로 CVE(Common Vulnerabilities and Exposures) 데이터베이스의 레코드 형식인 취약점을 공개하는 방법과 시기를 함께 결정합니다. 관례적으로 저자는 공개 전에 문제를 해결하는 데 90일이 주어지지만 더 많은 시간을 협상할 수 있습니다.

1-2. NGINX 및 CVEs

Open Source 소프트웨어 제공 업체이자 상용 소프트웨어 공급업체인 NGINX는 NGINX Open Source 및 NGINX Plus뿐만 아니라 다른 상용 제품에 영향을 미치는 CVE 및 기타 취약점에 대한 보고 및 수정 프로세스에 적극적으로 참여합니다. NGINX Management Suite, NGINX App Protect, NGINX Ingress Controller, 그리고 NGINX Service Mesh, NGINX Unit이 포함된 무료 Open Source 제품을 포함합니다.

NGINX Plus 고객을 위한 엔터프라이즈 수준의 지원 및 프로세스 표준에 전념하고 있기 때문에 NGINX Open Source 사용자는 NGINX Plus를 기반으로 한다는 점에서 혜택을 받고 있습니다. 이러한 표준에는 핵심 소프트웨어, 종속성 및 지원되는 모듈에 대해 패치가 준수해야 하는 버그 수정 및 테스트 절차를 규정하는 고객과의 서비스 수준 계약(SLA: Service-Level Agreement)가 포함됩니다. SLA는 고객이 규정을 준수하여 취약점 악용에 대한 노출 위험을 최소화하도록 지원합니다.

NGINX Open Source에 대한 추가적인 문제점은 많은 타사 기술이 이를 활용하여 제품에 포함한다는 것입니다. 이러한 기술 제공 업체는 소프트웨어 취약점이 발견되었을 때 이를 공개하고 패치하는 자체 프로세스를 가지고 있습니다. 다음 섹션에서 설명하듯이 NGINX Open Source 용 패치 릴리스와 타사 기술용 해당 패치 릴리스 사이에 상당한 지연이 있는 경우가 있습니다.

2. NGINX Plus가 보안 취약점 을 보호하는 방법

소개에서 NGINX Plus의 자주 간과되는 이점은 고객이 취약점으로부터 자신을 더 빠르고 쉽게 보호할 수 있는 방법이라고 언급했습니다. Open Source 소프트웨어의 취약점을 처리하는 것은 생각하는 것보다 훨씬 더 많은 시간과 비용이 소요될 수 있습니다.

다음 섹션에서는 NGINX Plus가 취약점을 더 빠르고 쉽게 해결할 수 있는 5가지 구체적인 방법에 대해 설명합니다.

2-1. NGINX는 NGINX Plus 구독자에게 패치에 대해 사전에 알립니다.

NGINX Open Source 및 NGINX Plus에 대한 보안 패치를 출시할 때 이메일을 통해 NGINX Plus 고객에게 사전에 알립니다. 또한 대부분의 패치를 이용할 수 있다는 것을 알리는 포스트를 게시하지만 NGINX Open Source 사용자에게 직접 연락할 방법이 없습니다. 따라서 CVE 및 기타 취약성 데이터베이스를 모니터링하고 정기적으로 포스트를 확인해야 하는 부담이 있습니다.

2-2. 공격을 받고 있는 NGINX Plus 구독자에게 실시간 도움말을 제공합니다.

NGINX Plus 구독자분이 공격을 당하면 실시간 지원을 제공합니다. 신속하게 공격을 완화하고 백업 및 실행을 지원합니다. 공격이 중지된 후에도 계속해서 귀하와 협력합니다.

2-3. NGINX App Protect 애플리케이션 보호 향상

NGINX App Protect는 NGINX Plus 동적 모듈로 배포되는 엔터프라이즈급 웹 애플리케이션 방화벽(WAF)입니다. 백엔드 애플리케이션 서버에서 더 많은 CVE에 대한 애플리케이션별 보호 기능을 통해 NGINX Plus의 Layerl 7 보안을 강화합니다. NGINX는 특정 공격 캠페인과 관련된 서명을 제공하기 위해 최선을 다하고 있습니다. NGINX App Protect는 NGINX Plus 구독자가 자체 서명을 작성하고 여러 오탐지를 처리할 수 있도록 합니다.

2-4. NGINX Plus는 JWT 기반 및 OpenID Connect 인증을 지원합니다.

패치가 필요한 특정 취약점이 없는 경우에도 정교한 인증 프로토콜을 통해 악의적인 공격자가 애플리케이션과 인프라에 액세스하지 못하도록 방지할 수 있습니다. NGINX Open Source에서 사용할 수 있는 방법 외에도 NGINX Plus는 웹 및 API 클라이언트에 대해 JSON Web Token(JWT) 및 OpenID Connect 기반 인증을 지원합니다.

2-5. NGINX Plus 구독자는 즉시 패치를 받습니다.

취약점 보고에 설명된 대로 NGINX 보안 취약점 이 NGINX 소프트웨어에 영향을 미치는 경우 일반적으로 CVE로 공개되기 전에 알림을 받습니다. 사전 경고를 통해 공개 전에 패치를 준비할 수 있으며 일반적으로 공개 당일(또는 경우에 따라 며칠 내) 패치를 릴리스합니다. 수정 사항은 패치된 바이너리 형태로 NGINX Plus 고객에게 제공됩니다. NGINX Open Source 사용자는 지원되는 OS에 대해 수정된 소스 코드 및 패치된 바이너리 형태로 사용할 수 있지만 위에서 언급한 바와 같이 NGINX Open Source 사용자에게 직접 알릴 방법이 없습니다.

NGINX Open Source를 활용하거나 타사 기술 포함한 경우 공개되기 전에 NGINX 보안 취약점 을 인식하지 못할 수 있습니다. 우리의 경험에 따르면 그들의 패치는 NGINX 패치보다 몇 달 뒤처질 수 있습니다. 이것은 특히 자주 유지 관리하는 Open Source 소프트웨어의 경우 이해할 수 있지만 취약점이 공개된 후 인프라가 보호되지 않고 해커에 의해 악용될 수 있습니다.

예를 들어, 2018년 가을에 HTTP/2의 취약점에 대한 두 개의 CVE(CVE-2018-16843 및 CVE-2018-16844)가 발견되었습니다. 이에 대응하여 NGINX Plus R16 및 NGINX Open Source 1.15.6에 보안 패치를 적용했습니다. NGINX Plus의 일부 기능을 제공하기 위해 NGINX Open Source를 기반으로 하는 인기 있는 OpenResty 소프트웨어는 NGINX에서 패치를 적용한 지 4개월 만인 2019년 3월 3일에 이러한 패치를 통합한 릴리스 후보를 처음 발표했습니다. OpenResty 위에 구축된 솔루션은 일반적으로 코드 베이스를 패치하는 데 훨씬 더 오래 걸립니다.

때때로 NGINX 보안 취약점 의 상태가 명확하지 않거나 소프트웨어 공급자가 잠재적인 공격 벡터를 구성하더라도 패치가 필요하지 않다고 생각합니다. 이러한 상황은 가장 널리 사용되는 Open Source WAF 소프트웨어인 ModSecurity로 2020년에 발생했습니다. OWASP ModSecurity Core Rule Set(CRS)을 유지 관리하는 팀은 ModSecurity v3가 정규 표현식의 글로벌 매칭을 수행하는 방식이 OWASP CRS 팀이 서비스 거부 취약점(CVE-2020-15598)으로 간주하는 결과를 초래할 수 있음을 발견했습니다. ModSecurity 자체를 유지 관리하는 조직인 Trustwave는 이러한 행위가 보안 문제라고 반박하며 패치를 거부했습니다.

NGINX ModSecurity WAF는 ModSecurity v3에 구축된 NGINX Plus 용 동적 모듈입니다. NGINX 팀은 CVE-2020-15598에 설명된 동작이 DoS 취약점을 유발할 수 있는 충분한 잠재력이 있다고 판단하여 2020년 9월에 패치를 발표했습니다. Open Source ModSecurity Build( NGINX Open Source 사용자 포함)는 OWASP CRS 팀의 패치를 적용할지 아니면 Trustwave의 패치되지 않은 소프트웨어를 고수하고 Trustwave에서 제안한 완화 변경 사항을 구현할지 여부를 스스로 결정해야 합니다.

3. NGINX 보안 취약점 해결 방안, 결론

갈수록 경쟁이 치열해지는 오늘날의 비즈니스 환경에서 소프트웨어 팀은 가장 혁신적인 서비스를 제공하기 위해 가능한 한 빨리 새롭고 업데이트된 코드를 제공해야 한다는 압박을 받고 있습니다. 동시에 인프라 및 애플리케이션에 대한 정교한 공격이 증가함에 따라 NGINX 보안 취약점 을 추적하고 가능한 한 빨리 이를 완화하는 것이 중요해졌습니다.

NGINX Plus 구독은 이러한 부담을 덜어주기 때문에 애플리케이션팀이 NGINX 보안 취약점 으로부터 조직을 보호하면서 코드를 더 빠르게 제공하는 주요 업무에 집중할 수 있습니다.

NGINX Plus를 구독하여 테스트 해보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.