NGINX Plus를 사용하여 보안 취약점을 빠르고 쉽게 완화하기

NGINX Plus를 통해 보안 취약점을 신속하고 쉽게 완화하기

NGINX는 전 세계적으로 수백만 개의 조직이 우리의 소프트웨어를 신뢰하여 웹사이트와 애플리케이션 배포 인프라를 운영하는데 자부심을 가지고 있습니다.

사용자들이 NGINX에 의존하고 있는 만큼, 보안 취약점에 대한 패치를 적용한 최신 버전을 운영하는 것의 중요성을 간과하는 경우가 많다는 사실에 놀랄 때가 있습니다.특히 오늘날 인터넷에서는 공통 취약점 및 노출(Common Vulnerabilities and Exposures, CVEs)과 같은 보안 취약점이 매우 흔하게 발생합니다.

물론 보안 위협에 대한 방어를 고려하는 것만으로는 충분하지 않습니다.취약점을 추적하고 패치가 제공되면 즉시 보호 조치를 취할 수 있는 명확한 프로세스를 구현해야 합니다.모든 작업을 스스로 처리해야 하는 오픈 소스 소프트웨어의 경우,
이러한 작업에 소요되는 시간과 노력을 과소평가하기 쉽습니다.사실, 보안 위협으로부터 빠르고 쉽게 보호할 수 있는 것은 상용 소프트웨어,특히 NGINX Plus와 같은 상용 소프트웨어의 종종 간과되는 이점입니다.

이 블로그에서는 오픈 소스 소프트웨어의 보안 문제를 처리하는 것에 대한 어려움과 NGINX Plus가 CVE 및 기타 보안 위협을 신속하고 쉽게 완화하는 방법에 대해 설명합니다.

오픈 소스 소프트웨어에서 취약점 처리하기

모든 개발자들은 자신이 완벽한 코드를 작성한다고 생각하지만, 어떤 소프트웨어도 버그가 없는 것은 아닙니다.
개발자들은 대부분의 버그가 개발 과정에서 발견되기를 바라며, 애플리케이션의 사용 중 일부 버그만 발생한다고 예상합니다. 최악의 경우, 악의적인 사용자가 버그를 발견할 수 있습니다. 여러 오픈 소스 도구, 프로그래밍 언어 및 플랫폼을 사용하여 애플리케이션 스택을 구성할 때 버그의 결과는 크게 악화됩니다. 각 구성 요소를 별도로 검토하여 버그가 없는지 확인해야 합니다. 오픈 소스 소프트웨어에서 버그가 발견되면, 이를 검증하고 테스트하며 (가능한 경우) 수정하는 정책을 갖추는 것이 중요합니다.

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

1. 정기적인 검토 및 테스트
2. 취약점 추적 및 내부 보고
3. 시기 적절한 취약점 수정

취약점 보고

보안 취약점이 발견되면, 이를 공개하는 표준 절차가 있습니다. 첫 단계는 소프트웨어의 저자나 공급자에게 상세한 보고서를 제출하는 것입니다. 보고자와 저자는 함께 취약점 공개 방식과 시점을 결정하며, 일반적으로 공통 취약점 및 노출(CVE) 데이터베이스에 기록됩니다. 관례적으로 저자는 공개 전 90일 이내에 문제를 해결해야 하지만, 더 많은 시간을 협상할 수도 있습니다.

NGINX와 CVE

오픈 소스 소프트웨어 제공업체이자 상용 소프트웨어 공급업체로서,

NGINX는 NGINX Open Source 및 NGINX Plus와 기타 상용 제품 (현재 F5 NGINX Management Suite로 알려진 NGINX Controller, NGINX App Protect, NGINX Ingress Controller), 무료 오픈 소스 제공 제품(NGINX Service Mesh, NGINX Unit, NGINX Amplify)에 영향을 미치는 CVE 및 기타 취약점의 보고 및 수정 과정에 적극적으로 참여하고 있습니다.

NGINX Open Source 사용자는 NGINX Plus가 기반이 되어 있는 사실로 인해 혜택을 받습니다. 우리는 NGINX Plus 고객을 위한 기업 수준의 지원 및 프로세스 표준을 준수하고 있으며, 이러한 표준에는 버그 수정 및 테스트 절차를 포함하는 서비스 수준 계약(SLA)이 포함되어 있습니다. SLA는 고객이 규정 준수를 달성하고 취약점 악용 위험을 최소화하도록 돕습니다.

NGINX Open Source의 경우, 많은 제3자 기술이 이를 활용하고 제품에 내장하고 있습니다.이러한 기술 제공업체는 취약점이 발견될 때 공개 및 패치 프로세스를 따릅니다. 다음 섹션에서 논의할 내용처럼, NGINX Open Source에 대한 패치 출시와 제3자 기술에 대한 대응 패치 사이에는 종종 상당한 지연이 발생할 수 있습니다.

NGINX Plus가 구독자를 보호하는 방법

NGINX 소프트웨어의 취약점 처리: 조기 경고와 패치 배포

취약점이 NGINX 소프트웨어에 영향을 미칠 때, 우리는 보통 해당 취약점이 공개적으로 CVE(Common Vulnerabilities and Exposures)로 발표되기 전에 알림을 받습니다. 이 조기 경고를 통해 우리는 공개 발표 전에 패치를 준비할 수 있으며, 일반적으로 공개 발표 당일 또는 며칠 이내에 패치를 출시합니다. NGINX Plus 고객에게는 패치된 바이너리 형태로 제공되며, NGINX Open Source 사용자에게는 수정된 소스 코드와 지원되는 운영 체제를 위한 패치된 바이너리 형태로 제공됩니다. 하지만, 앞서 언급했듯이 NGINX Open Source 사용자에게는 직접적으로 알리는 방법이 없습니다.

제3자 기술의 패치 지연

NGINX Open Source를 활용하거나 내장한 제3자 기술은 취약점 공개 전에는 이를 인식하지 못할 수 있습니다. 만약 인식하더라도, 제3자 기술의 패치는 종종 NGINX의 패치보다 몇 개월 지연될 수 있습니다. 이는 자원봉사자들이 유지 관리하는 오픈 소스 소프트웨어의 경우 이해할 수 있지만, 취약점이 공개된 후에는 인프라가 보호되지 않고 해커의 악용에 노출될 수 있습니다.

사례: HTTP/2 취약점

예를 들어, 2018년 가을에 HTTP/2와 관련된 두 가지 취약점(CVE-2018-16843 및 CVE-2018-16844)이 발견되었습니다. 우리는 NGINX Plus R16과 NGINX Open Source 1.15.6에 대한 보안 패치를 적용했습니다. 하지만, NGINX Open Source를 기반으로 일부 기능을 제공하는 인기 있는 OpenResty 소프트웨어는 2019년 3월 3일에야 이 패치를 포함한 릴리스 후보를 발표했습니다. 이는 NGINX 패치 발표 후 4개월이 지난 시점입니다. OpenResty 위에 구축된 솔루션은 일반적으로 더 오랜 시간이 소요될 수 있습니다.

ModSecurity 취약점

때때로 취약점의 상태가 명확하지 않거나 소프트웨어 제공자가 패치가 필요하지 않다고 판단할 수도 있습니다. 2020년에 발생한 상황에서는 가장 널리 사용되는 오픈 소스 WAF 소프트웨어인 ModSecurity와 관련된 취약점이 있었습니다. OWASP ModSecurity Core Rule Set (CRS) 팀은 ModSecurity v3의 전역 정규 표현식 매칭 방식이 서비스 거부 취약점(CVE-2020-15598)을 초래할 수 있다고 발견했습니다. 그러나 ModSecurity를 유지 관리하는 Trustwave는 이 동작이 보안 문제라고 보지 않으며, 패치를 발행하지 않기로 결정했습니다.

NGINX ModSecurity WAF는 ModSecurity v3를 기반으로 한 NGINX Plus의 동적 모듈입니다. NGINX 팀은 CVE-2020-15598에서 설명된 동작이 DoS 취약점을 초래할 가능성이 충분히 있다고 판단하여 2020년 9월에 패치를 발행했습니다. 블로그에서 설명한 대로, 오픈 소스 ModSecurity 빌드를 사용하는 NGINX Open Source 사용자들은 OWASP CRS 팀의 패치를 적용하거나 Trustwave의 미패치 소프트웨어를 사용하고 Trustwave가 제안하는 완화 변경 사항을 구현할지 스스로 결정해야 합니다. NGINX Open Source를 활용하거나 내장한 제3자 기술은 취약점을 공개 전에 인식하지 못할 수 있습니다.

인식하더라도, 그들의 패치는 종종 NGINX 패치보다 몇 개월 지연될 수 있습니다. 이는 직접적으로 유지 관리하는 오픈 소스 소프트웨어에서는 이해할 수 있지만, 취약점 공개 후에는 인프라가 보호되지 않고 해커에게 노출될 수 있습니다. 예를 들어, 2018년 가을에 HTTP/2의 취약점에 대한 두 개의 CVE(CVE-2018-16843 및 CVE-2018-16844)가 발견되었습니다.

NGINX Plus R16과 NGINX Open Source 1.15.6에 대해 보안 패치를 적용했습니다.
NGINX Plus의 기능을 제공하는 오픈 소스 소프트웨어인 OpenResty는 2019년 3월 3일 패치를 포함한 릴리스 후보를 발표했습니다. 이는 NGINX 패치 후 4개월이 지나서였습니다. OpenResty 위에 구축된 솔루션은 보통 더 오랜 시간이 걸립니다.

때때로 취약점의 상태가 불확실하거나 소프트웨어 제공자가 패치가 필요하지 않다고 생각할 수도 있습니다.

2020년에는 ModSecurity라는 가장 널리 사용되는 오픈 소스 WAF 소프트웨어와 관련된 상황이 있었습니다. OWASP ModSecurity Core Rule Set(CRS) 팀은 ModSecurity v3의 전역 정규 표현식 매칭 방식이 서비스 거부 취약점(CVE-2020-15598)을 초래할 수 있다고 발견했습니다. ModSecurity를 유지 관리하는 Trustwave는 이 동작이 보안 문제라고 보지 않으며 패치를 발행하지 않기로 결정했습니다. NGINX ModSecurity WAF는 ModSecurity v3를 기반으로 한 NGINX Plus의 동적 모듈입니다.

NGINX 팀은 CVE-2020-15598에서 설명된 동작이 DoS 취약점을 초래할 가능성이 충분히 있다고 판단하고, 2020년 9월에 패치를 발행했습니다. 블로그에서 설명한 대로, 오픈 소스 ModSecurity 빌드를 사용하는 NGINX Open Source 사용자는
OWASP CRS 팀의 패치를 적용하거나 Trustwave의 미패치 소프트웨어를 사용하고 제안된 완화 변경 사항을 구현해야 합니다. [편집자 주 – NGINX ModSecurity WAF는 2022년 4월 1일에 판매 종료되었으며, 2024년 3월 31일에 수명 종료 예정입니다. 자세한 내용은 블로그에서 확인하십시오.]

결론

오늘날의 경쟁이 치열한 비즈니스 환경에서는 소프트웨어 팀이 신속하게 새 코드와 업데이트를 제공해야 하는 압박을 받고 있습니다. 동시에 인프라 및 애플리케이션에 대한 정교한 공격의 증가로 인해 취약점을 추적하고 신속히 완화하는 것이 필수적입니다. 이는 번거롭고 시간 소모적인 작업입니다. NGINX Plus 구독자는 이러한 부담을 덜 수 있으며, 애플리케이션 팀은 코드 배포에 집중하면서 조직은 보안 취약점으로부터 보호받을 수 있습니다.

NGINX Plus의 모든 고급 기능을 직접 체험해 보세요

– 오늘 무료 30일 체험판을 시작하거나, 사용 사례에 대해 논의하기 위해 연락해 주세요.

NGINX Korea