NGINX Plus로 보안 취약점을 빠르고 간편하게 완화하기

Laurent Pétroque

NGINX는 전 세계 수백만 개의 조직이 웹사이트와 애플리케이션 제공 인프라를 운영하기 위해 당사의 소프트웨어를 신뢰한다는 사실을 자랑스럽게 생각합니다. 사용자들이 NGINX에 크게 의존하고 있다는 점을 고려하면, 오늘날 인터넷에서 매우 흔해진 CVE(Common Vulnerabilities and Exposures, 공통 취약점 및 노출)와 같은 보안 취약점에 대한 수정 사항이 포함된 최신 버전을 실행하는 것이 얼마나 중요한지 별로 생각해 보지 않았다는 말을 들을 때 놀라지 않을 수 없습니다.

물론 보안 위협에 대비해야 한다고 생각하는 것만으로는 충분하지 않습니다. 취약점을 추적하고 보호 조치가 제공되는 즉시 적용할 수 있도록 명확하게 정의된 프로세스를 구현해야 합니다. 오픈 소스 소프트웨어처럼 이 모든 작업을 직접 해야 하는 경우, 얼마나 많은 시간과 노력이 필요한지 과소평가하기 쉽습니다. 실제로 보안 위협으로부터 빠르고 손쉽게 보호할 수 있다는 점은 NGINX Plus와 같이 상용 지원이 제공되는 소프트웨어에서 흔히 간과되는 이점입니다.

이 블로그에서는 오픈 소스 소프트웨어를 보호할 때 직면하는 과제를 살펴보고, NGINX Plus를 통해 CVE 및 기타 보안 위협을 훨씬 더 빠르고 쉽게 완화할 수 있는 방법을 설명합니다.

오픈 소스 소프트웨어의 취약점 대응

모든 개발자는 자신이 완벽한 코드를 작성한다고 믿고 싶어 하지만, 버그가 전혀 없는 소프트웨어는 없습니다. 개발자들은 엄격한 품질 준수 절차를 통해 대부분의 버그가 개발 과정에서 발견되고, 앱의 수명 주기 동안 정상적으로 사용하는 중에는 극히 일부만 드러나기를 바랍니다. 최악의 경우에는 악의적인 사용자가 버그를 발견하기도 합니다.

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

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

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

취약점 신고

보안 취약점이 발견되면 이를 공개하기 위한 표준 절차를 따릅니다. 첫 번째 단계는 해당 소프트웨어의 개발자나 공급업체에 상세한 보고서를 제출하는 것입니다. 제보자와 개발자는 취약점을 언제 어떤 방식으로 공개할지 함께 결정하며, 일반적으로 Common Vulnerabilities and Exposures(CVE) 데이터베이스에 기록하는 형태로 공개합니다. 관례상 개발자에게는 공개 전에 문제를 해결할 수 있도록 90일이 주어지지만, 협의를 통해 기간을 연장할 수도 있습니다.

NGINX와 CVE

오픈 소스 소프트웨어 제공업체이자 상용 소프트웨어 공급업체인 NGINX는 NGINX Open Source 및 NGINX Plus뿐만 아니라 기타 상용 제품에 영향을 미치는 CVE 및 기타 취약점의 보고 및 해결 절차에 적극적으로 참여합니다. 이 글을 작성하는 시점에 해당 상용 제품에는 NGINX Controller [현재 F5 NGINX Management Suite], NGINX App Protect, NGINX Ingress Controller가 포함되며, 무료 오픈 소스 제품에는 NGINX Service Mesh, NGINX Unit, NGINX Amplify가 포함됩니다.

NGINX Plus는 NGINX Open Source를 기반으로 하며, 당사는 NGINX Plus 고객을 위해 엔터프라이즈급 지원 및 프로세스 표준을 준수하고 있으므로 NGINX Open Source 사용자도 그 혜택을 누릴 수 있습니다. 이러한 표준에는 고객과 체결한 서비스 수준 계약(SLA)이 포함되며, 이 계약은 핵심 소프트웨어, 종속 항목 및 지원되는 모듈 모두에 대해 패치가 준수해야 하는 버그 수정 및 테스트 절차를 규정합니다. SLA는 고객이 규정을 준수하고 취약점 악용에 노출될 위험을 최소화하는 데 도움이 됩니다.

NGINX Open Source의 경우, 많은 타사 기술이 이를 활용하여 자사 제품에 내장한다는 점이 문제를 더욱 복잡하게 만듭니다. 이러한 기술의 공급업체는 소프트웨어 취약점이 발견되었을 때 이를 공개하고 패치하기 위한 자체 프로세스를 갖추고 있습니다. 다음 섹션에서 설명하듯이, NGINX Open Source용 패치가 출시된 시점과 타사 기술용 해당 패치가 출시되는 시점 사이에는 상당한 시간 차이가 발생하기도 합니다.

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

서론에서 언급했듯이, NGINX Plus의 장점 중 흔히 간과되는 한 가지는 고객이 취약점으로부터 더 빠르고 쉽게 스스로를 보호할 수 있도록 해준다는 점입니다. 오픈 소스 소프트웨어의 취약점에 대응하는 데는 많은 사람이 생각하는 것보다 훨씬 더 많은 시간이 들 수 있으며, 그만큼 비용도 많이 듭니다.

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

NGINX는 NGINX Plus 구독자에게 패치 정보를 선제적으로 안내합니다

NGINX Open Source 및 NGINX Plus용 보안 패치를 출시할 때는 NGINX Plus 고객에게 이메일로 해당 사실을 선제적으로 알립니다. 또한 대부분의 패치가 제공되면 이를 알리는 블로그 게시물을 게시하지만, NGINX Open Source 사용자에게 직접 연락할 방법은 없습니다. 따라서 사용자가 직접 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의 레이어 7 보안을 강화합니다. NGINX와 F5는 특정 공격 캠페인과 관련된 시그니처를 제공하기 위해 최선을 다하고 있습니다. 그 결과 NGINX App Protect는 NGINX Plus 구독자가 직접 시그니처를 만들고 수많은 오탐을 처리해야 하는 부담을 덜어줍니다.

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

패치가 필요한 특정 취약점이 없더라도 정교한 인증 프로토콜을 사용하면 악의적인 사용자가 앱과 인프라에 액세스하는 것을 방지할 수 있습니다. NGINX Open Source에서 제공되는 방식 외에도 NGINX Plus는 JSON 웹 토큰(JWT) 및 OpenID Connect 기반 인증을 지원하며, 웹 클라이언트와 API 클라이언트 모두에 적용할 수 있습니다.

NGINX Plus 구독자는 패치를 즉시 받을 수 있습니다

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

NGINX Open Source를 활용하거나 내장하는 타사 기술은 취약점이 공개되기 전에 해당 취약점을 인지하지 못할 수 있습니다. 인지하더라도, 저희 경험에 따르면 해당 기술의 패치는 NGINX 패치보다 몇 달 늦게 제공될 수 있습니다. 특히 자원봉사자가 유지 관리하는 경우가 많은 오픈 소스 소프트웨어라면 이는 이해할 수 있는 일이지만, 취약점이 공개된 후에도 인프라가 보호되지 않아 해커의 공격에 악용될 수 있습니다.

예를 들어, 2018년 가을에 HTTP/2 취약점과 관련된 두 건의 CVE가 발견되었습니다(CVE-2018-16843 및 CVE-2018-16844). 이에 대응하여 NGINX Plus R16과 NGINX Open Source 1.15.6에 보안 패치를 적용했습니다. NGINX Open Source를 기반으로 NGINX Plus의 일부 기능을 제공하는 인기 소프트웨어인 OpenResty는 NGINX 패치가 나온 지 무려 4개월이 지난 2019년 3월 3일에야 이러한 패치가 포함된 첫 번째 릴리스 후보 버전을 내놓았습니다. OpenResty를 기반으로 구축된 솔루션은 일반적으로 코드베이스를 패치하는 데 이보다 더 오랜 시간이 걸립니다.

취약점의 상태가 명확하지 않거나, 잠재적인 공격 경로가 될 수 있음에도 소프트웨어 제공업체가 패치가 필요하지 않다고 판단하는 경우가 있습니다. 2020년에는 가장 널리 사용되는 오픈 소스 WAF 소프트웨어인 ModSecurity에서 이러한 상황이 발생했습니다. OWASP ModSecurity 핵심 규칙 세트(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 Open Source 사용자 포함)는 OWASP CRS 팀의 패치를 적용할지, 아니면 Trustwave의 패치되지 않은 소프트웨어를 계속 사용하면서 Trustwave가 제안한 완화 조치를 구현할지 직접 결정해야 합니다.

[편집자 – NGINX ModSecurity WAF는 2022년 4월 1일부로 공식 판매 종료되었으며, 2024년 3월 31일부로 지원 종료될 예정입니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF 지원 종료 전환 안내<.htmla>를 참조하세요.]

결론

오늘날 갈수록 경쟁이 치열해지는 비즈니스 환경에서 소프트웨어 팀은 가장 혁신적인 서비스를 제공하기 위해 신규 및 업데이트된 코드를 최대한 신속하게 배포해야 한다는 압박을 받고 있습니다. 동시에 인프라와 애플리케이션을 겨냥한 정교한 공격이 증가하면서 취약점을 추적하고 가능한 한 빨리 완화하는 일이 필수적이 되었지만, 이는 번거롭고 많은 시간이 소요되는 작업입니다.

NGINX Plus 구독은 이러한 부담을 덜어 주어 애플리케이션 팀이 핵심 임무인 신속한 코드 제공에 집중할 수 있도록 하는 동시에, 조직을 보안 취약점으로부터 안전하게 보호합니다.

NGINX Plus의 모든 고급 기능을 직접 사용해 보세요. 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.

작성자 소개

Laurent Pétroque

Laurent Pétroque의 다른 블로그 게시물