NGINX Plus로 보안 취약성을 빠르고 쉽게 완화

NGINX에서는 전 세계 수백만 개의 기업이 자사 웹사이트와 앱 전송 인프라를 구동하기 위해 당사 소프트웨어를 신뢰한다는 사실을 자랑스럽게 생각합니다. 사용자가 NGINX에 얼마나 크게 의존하는지 생각해보면, 오늘날 인터넷에서 흔해진 CVE(Common Vulnerabilities and Exposures) 등의 보안 취약점에 대한 수정 사항이 포함된 최신 버전을 실행하는 것의 중요성에 대해 많은 생각을 하지 않았다는 것을 사용자가 인정하는 것은 놀랍습니다.

물론 보안 위협에 대비하는 것만으로는 충분하지 않습니다. 취약성을 추적하고 취약성이 발견되는 즉시 보호 조치를 실행하기 위한 잘 정의된 프로세스를 구현해야 합니다. 오픈 소스 소프트웨어의 경우와 마찬가지로, 모든 것을 스스로 해야 한다면 얼마나 많은 시간과 노력이 필요한지 과소평가하기 쉽습니다. 실제로 NGINX Plus와 같은 상업적으로 지원되는 소프트웨어의 종종 간과되는 이점 중 하나는 보안 위협으로부터 자신을 빠르고 쉽게 보호할 수 있다는 것입니다.

이 블로그에서는 오픈 소스 소프트웨어를 보호하는 데 따르는 과제를 살펴보고 NGINX Plus가 CVE 및 기타 보안 위협을 훨씬 더 빠르고 쉽게 완화하는 데 어떤 도움을 주는지 설명합니다.

오픈소스 소프트웨어의 취약점 처리

모든 개발자가 자신이 완벽한 코드를 작성한다고 생각하기는 하지만, 어떤 소프트웨어도 버그가 없는 것은 아닙니다. 개발자들은 대부분의 버그가 엄격한 품질 준수 프로세스의 일환으로 개발 중에 감지되기를 바라며, 앱 수명 동안 정상적인 사용에서 몇 가지 버그만 표면화되기를 바랍니다. 최악의 경우, 버그는 나쁜 의도를 가진 악의적인 사용자에 의해 발견됩니다.

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

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

1. 정기적인 검토 및 테스트
2. 취약점 추적 및 내부 보고
3. 시기적절하게 취약점을 수정합니다

취약점 보고

보안 취약점이 발견되면 이를 공개하기 위한 표준적인 일련의 이벤트가 있습니다. 첫 번째 단계는 소프트웨어 제작자나 공급업체에 자세한 보고서를 제출하는 것입니다. 보고자와 작성자는 취약점을 언제, 어떻게 공개할지 함께 결정하며, 일반적으로 이는 CVE( Common Vulnerabilities and Exposures ) 데이터베이스에 기록하는 형태입니다. 관례에 따라 저자는 공개하기 전에 90일 이내에 문제를 해결해야 하지만, 협상을 통해 더 많은 시간을 확보할 수 있습니다.

NGINX 및 CVE

오픈소스 소프트웨어 공급자이자 상용 소프트웨어 판매업체인 NGINX는 NGINX Open Source 및 NGINX Plus 와 기타 상용 제품(이 글을 쓰는 시점에서는 NGINX Controller [현재 F5 NGINX Management Suite ] , NGINX App Protect , NGINX Ingress Controller가 포함됨) 및 무료 오픈소스 제품( NGINX Service Mesh , NGINX Unit , NGINX Amplify 포함)에 영향을 미치는 CVE 및 기타 취약점에 대한 보고 및 수정 프로세스에 적극적으로 참여합니다.

NGINX 오픈 소스 사용자는 NGINX Plus가 NGINX 오픈 소스를 기반으로 한다는 사실에서 이점을 얻을 수 있습니다. NGINX Plus 고객을 위해 엔터프라이즈 수준의 지원과 프로세스 표준을 제공하기 위해 노력하고 있기 때문입니다. 이러한 표준에는 핵심 소프트웨어, 종속성 및 지원 모듈에 대해 패치가 준수해야 하는 버그 수정 및 테스트 절차를 명시하는 고객과의 서비스 수준 계약(SLA)이 포함됩니다. SLA는 고객이 규정을 준수하고 취약성 악용에 노출될 위험을 최소화하는 데 도움이 됩니다.

NGINX 오픈 소스의 또 다른 특징은 많은 타사 기술이 이를 활용하고 자사 제품에 내장한다는 것입니다. 이러한 기술 제공자는 소프트웨어 취약점이 발견되면 이를 공개하고 패치하는 자체 프로세스를 갖추고 있습니다. 다음 섹션 에서 설명하겠지만, NGINX 오픈 소스 패치를 출시하는 것과 타사 기술에 대한 해당 패치를 출시하는 것 사이에 때로는 상당한 시간 차이가 발생하는 경우가 있습니다.

NGINX Plus가 가입자를 취약점으로부터 보호하는 방법

소개에서 NGINX Plus의 종종 간과되는 이점 중 하나는 고객이 취약점으로부터 자신을 보호하는 것을 더 빠르고 쉽게 만들어준다는 점이라고 언급했습니다. 오픈 소스 소프트웨어의 취약점을 해결하는 일은 많은 사람들이 생각하는 것보다 훨씬 더 많은 시간이 걸리고 따라서 비용도 많이 듭니다.

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

NGINX는 NGINX Plus 구독자에게 패치에 대해 적극적으로 알립니다.

NGINX 오픈 소스 및 NGINX Plus에 대한 보안 패치를 릴리스할 경우 NGINX Plus 고객에게 이메일을 통해 해당 내용을 사전에 알립니다. 또한 대부분의 패치의 출시를 알리는 블로그도 게시하고 있지만, NGINX 오픈 소스 사용자에게 직접 다가갈 방법은 없습니다. 그러면 CVE와 기타 취약성 데이터베이스를 모니터링하고 정기적으로 블로그를 확인해야 하는 부담이 그들에게 생깁니다.

F5 SIRT는 공격을 받는 NGINX Plus 구독자에게 실시간 도움말을 제공합니다.

NGINX Plus 가입자를 포함한 F5 고객이 공격을 받으면 F5 보안 사고 대응팀 (SIRT)이 실시간으로 지원을 제공합니다. SIRT는 공격을 효과적으로 완화하고 다시 업무를 수행할 수 있도록 신속하게 대응합니다. 공격이 중단된 후에도 그들은 계속해서 귀사와 협력합니다. 그들은 "보고된 사고를 넘어 조직의 전반적인 피해를 줄이는 동시에 미래의 위협을 이해하고 예상하고 억제합니다."

NGINX App Protect가 애플리케이션 보호 강화

NGINX App Protect는 F5의 20년 보안 경험을 바탕으로 한 엔터프라이즈급 웹 애플리케이션 방화벽(WAF)으로, NGINX Plus 동적 모듈로 배포됩니다. 백엔드 애플리케이션 서버에서 더 많은 CVE에 대한 애플리케이션별 보호 기능을 제공하여 NGINX Plus의 Layer 7 보안을 한 단계 강화합니다. NGINX와 F5는 특정 공격 캠페인과 관련된 시그니처를 제공하기 위해 노력하고 있습니다. 결과는? NGINX App Protect를 사용하면 NGINX Plus 가입자는 자체 시그니처를 작성하고 여러 가지 오탐지 문제를 처리할 필요가 없습니다.

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

패치가 필요한 구체적인 취약점이 없더라도 정교한 인증 프로토콜은 악의적인 행위자가 앱과 인프라에 액세스하는 것을 방지하는 데 도움이 됩니다. NGINX 오픈 소스에서 제공하는 방법 외에도 NGINX Plus는 웹 및 API 클라이언트에 대한 JSON 웹 토큰 (JWT) 및 OpenID Connect 기반 인증을 지원합니다.

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

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

NGINX 오픈 소스를 활용하거나 내장하는 타사 기술은 취약점이 공개되기 전까지는 취약점을 인식하지 못할 수도 있습니다. 그렇더라도 우리의 경험에 따르면 그들의 패치는 NGINX 패치보다 몇 달 정도 뒤처질 수 있습니다. 이는 특히 자원봉사자들이 자주 유지 관리하는 오픈소스 소프트웨어의 경우 이해할 만한 일이지만, 취약점이 공개적으로 공개되면 인프라가 보호되지 않고 해커에게 악용될 수 있습니다.

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

때로는 취약점의 상태가 명확하지 않거나, 소프트웨어 제공업체가 잠재적인 공격 벡터를 구성하더라도 패치가 필요하지 않다고 생각하는 경우가 있습니다. 이와 같은 상황은 2020년에 가장 널리 사용되는 오픈소스 WAF 소프트웨어인 ModSecurity에서 발생했습니다. 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월에 패치를 발표했습니다. 패치를 발표하는 블로그 에서 설명했듯이, 오픈 소스 ModSecurity 빌드의 사용자(NGINX 오픈 소스 사용자 포함)는 OWASP CRS 팀의 패치를 적용할지, 아니면 Trustwave의 패치되지 않은 소프트웨어를 사용하고 Trustwave가 제안한 완화 변경 사항을 구현할지 스스로 결정해야 합니다.

[ 편집자 - NGINX ModSecurity WAF는 2022년 4월 1 일부로 공식적으로 판매 종료 되었으며 2024년 3월 31일 부터 수명 종료 로 전환됩니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF가 수명 종료로 전환 중입니다<.htmla>를 참조하세요.]

결론

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

NGINX Plus 구독은 이러한 부담을 덜어주어 애플리케이션 팀이 주요 임무인 코드 전달 속도 향상에 집중할 수 있게 하면서도 조직은 보안 취약점으로부터 안전하게 보호받을 수 있습니다.

NGINX Plus의 모든 고급 기능을 직접 사용해보세요. 오늘 무료 30일 체험판을 시작하거나 저희에게 연락하여 사용 사례에 대해 논의해보세요 .