WAF는 취약점을 어떻게 완화하나요?

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

곧 발간될 『2018 애플리케이션 딜리버리 현황』 보고서에서 언급했듯이, 웹 애플리케이션 방화벽(WAF)의 사용은 수년간 꾸준히 증가해 왔습니다. 이는 바람직한 현상입니다. 오늘날 애플리케이션은 고객 및 기업 데이터로 통하는 관문이며, 네트워크 계층에서 액세스를 제어하는 기존 방식만으로는 충분하지 않기 때문입니다. 악의적인 공격자들이 이러한 디지털 자산을 노리고 ID와 애플리케이션 자체를 표적으로 삼는 사례가 갈수록 늘고 있습니다.

그렇다면 WAF는 정원의 잡초처럼 끊임없이 생겨나는 수많은 취약점을 정확히 어떻게 완화할까요? WAF가 웹 공격을 탐지하고 방지하는 주요 방법에는 요청 거부/허용, 검사 및 거부, 시그니처의 세 가지가 있습니다.

각각의 방법을 자세히 살펴볼까요?

요청 거부/허용

요청 거부/허용 방식은 네트워크 방화벽에서 사용하는 전통적인 출입구 모델과 매우 유사합니다. 요청은 사용 가능한 정보를 바탕으로 거부되거나 허용됩니다. 이 정보는 IP 주소처럼 단순할 수도 있고, OPTIONS나 METHODS처럼 더 복잡하고 HTTP에 특화된 정보일 수도 있습니다.

• 차단/허용 목록
  악의적인 행위자가 특정 IP 주소 또는 IP 주소 범위에서 접근한다는 사실을 알고 있다면 차단하십시오. 애플리케이션이 특정 IP 주소 또는 IP 주소 범위에서 오는 요청만 수신하도록 허용되어 있다면 해당 요청만 허용하십시오. 이는 가장 간단한 보호 방법으로, 요청이 들어와야 하거나 들어오지 않아야 하는 IP 주소/범위라는 비교적 정적인 정보 집합에 의존합니다.
  
  그렇다면 네트워크 방화벽을 사용하면 되지 않느냐고 생각할 수 있습니다. 결국 네트워크 방화벽이 하는 일이 바로 그것이기 때문입니다. 온프레미스 환경에서는 매우 효과적입니다. 하지만 퍼블릭 클라우드에서 보호해야 할 앱이 있다면 네트워크 방화벽을 사용하지 못할 수도 있습니다. 또한 당사의 2018년 애플리케이션 딜리버리 현황 설문조사에서 이미 2~6개의 서로 다른 클라우드 제공업체에 투자한 59%에 해당한다면, 제공업체마다 네트워크 방화벽 정책이 동일할 것이라고 기대할 수 없습니다. 물론 여러 클라우드에 동일한 규칙을 구현할 수 있지만, WAF에서 규칙을 적용하면 여러 환경에서 동일한 WAF의 동일한 정책을 사용할 수 있습니다. 일관성은 보안을 성공적으로 구현하고 확장하는 데 핵심적인 요소입니다.
• 옵션 제한
  HTTP는 사용자가 수행하려는 작업을 앱 플랫폼(및 앱)에 전달하기 위해 일련의 헤더를 사용합니다. 예를 들어 HTTP 메서드인 GET, PUT, POST, DELETE를 사용하여 리소스를 처리할 수 있습니다. OPTIONS 필드에도 RFC에서 제한한 값 집합이 있으며, WAF를 통해 이를 손쉽게 제어할 수 있습니다. Optionsbleed와 같은 일부 취약점은 이러한 필드를 악용합니다. 이러한 취약점이 악용될 가능성을 차단하려면 WAF를 사용하여 애플리케이션의 정상적인 실행에 필요한 값만 허용하도록 제한할 수 있습니다. 경우에 따라 WAF는 기본적으로 이러한 값을 제한합니다. 예를 들어 BIG-IP ASM(F5 WAF)은 기본적으로 HTTP OPTIONS 메서드를 전혀 허용하지 않습니다.

시그니처

시그니처는 다양한 보안 솔루션에서 일반적으로 사용되는 또 다른 보호 방식입니다. 안티바이러스 및 안티멀웨어 서비스는 시그니처를 사용하여 바이러스와 멀웨어의 흔적을 신속하게 검사하고 탐지합니다. IPS/IDS와 WAF 역시 이 방식에 크게 의존합니다. 시그니처에는 사용자 정의 시그니처와 공급업체 관리형 시그니처의 두 가지 유형이 있습니다.

• 공급업체 관리형
  공급업체 관리형 시그니처는 일반적으로 공급업체가 자동으로 유지 관리하는 “데이터베이스”에 보관됩니다. 여기에는 고유한 디지털 시그니처로 식별할 수 있는 새로운 취약점이 발견될 때 데이터베이스를 업데이트하는 작업이 포함됩니다. WAF는 수신 요청을 데이터베이스와 대조하여 검사하고, 데이터베이스의 시그니처와 일치하는 항목을 발견하면 그에 따라 조치합니다. 시그니처는 단순한 일반 텍스트일 수도 있지만, 원격 코드 실행 기능을 유발하거나 앱 플랫폼을 손상시켜 액세스를 허용하거나 서비스를 거부하게 만드는 악성 코드를 나타내는 난해한 문자열의 복잡한 조합인 경우가 더 많습니다.
• 사용자 정의
  사용자 정의 시그니처를 사용하면 운영자가 데이터베이스에 시그니처를 신속하게 추가할 수 있습니다. 이 기능은 새로운 취약점에 빠르게 대응하고(대부분의 경우 제로데이 대응), 공급업체 관리형 시그니처가 아직 제공되지 않은 취약점을 완화하는 데 중요합니다.

검사

마지막으로, 요청(및 응답)을 완벽하게 제어할 수 있도록 검사가 포함됩니다. 요청 검사를 통해 WAF는 요청에 포함된 정보를 정상 또는 악성으로 알려진 문자열 및 값과 비교하여 해당 요청이 악성인지 정상인지 판단할 수 있습니다. HTTP 애플리케이션(오늘날 인터넷상의 대다수 애플리케이션)에서 이는 WAF가 제공해야 할 가장 중요한 기능입니다. WAF가 프로그래밍 가능한 검사 기능을 제공하지 않는다면 해당 제품의 선택을 재고해야 합니다. HTTP는 텍스트 기반이며 확장 가능하므로 요청 검사에 사용할 수 있는 옵션과 방법을 포괄적인 ‘체크박스’ 목록으로 제공하는 것은 사실상 불가능합니다. 허용되는 옵션이 제한된 HTTP 헤더는 극히 드물기 때문에 헤더에 넣을 수 있는 내용과 없는 내용을 제한하기가 매우 어렵습니다. 따라서 헤더나 페이로드 자체에 삽입된 악성 코드를 탐지하려면 검사가 필요한 경우가 많습니다. 검사에는 알려진 헤더 검사와 페이로드 검사라는 두 가지 방법이 있습니다.

• 알려진 헤더
  모든 HTTP 요청에는 잘 정의된 일련의 헤더가 포함됩니다. Host, User-Agent, Content-Type 등은 거의 모든 요청에서 사용됩니다. 각 헤더는 단순한 텍스트 문자열에 불과하지만 조합이 매우 다양하므로 값을 허용 목록으로 관리하기가 어렵습니다. 따라서 악성으로 의심되는 값이 있는지 각 헤더를 개별적으로 검사해야 합니다. 일반적으로 WAF는 HTTP 헤더를 매우 빠르게 파싱하여 검사할 수 있습니다. 헤더는 모든 요청의 시작 부분에 있으며, 애플리케이션 플랫폼을 대상으로 한 다양한 공격에 악용된 것으로 알려져 있습니다. 대표적으로 ApacheKiller, Optionsbleed, Apache Struts 등의 잘 알려진 취약점이 있습니다.
• 페이로드 검사
  페이로드 검사는 말 그대로 첫 바이트부터 마지막 바이트까지 전체 페이로드를 검사하여 취약점 악용 시도를 나타내는 알려진 영숫자 데이터 조합을 찾아냅니다. 페이로드 검사를 통해 운영자는 사용자 지정 HTTP 헤더와 요청 본문에서 악의적인 활동을 나타내는 특정 지표를 확인할 수 있습니다. 이를 위해서는 WAF가 먼저 요청의 전체 내용을 보관해야 합니다. 패킷에 담을 수 있는 데이터의 양은 제한되어 있으므로, 악성 데이터가 두 패킷에 걸쳐 있으면 패킷 단위로만 검사하는 서비스에서는 이를 놓칠 수 있기 때문입니다. WAF는 전체 페이로드를 검사함으로써 악성 데이터가 어디에 있든 찾아내어 대상에 도달하지 못하도록 차단합니다.

WAF는 취약점을 완화하여 애플리케이션을 보호하는 것 외에도 훨씬 더 많은 기능을 수행할 수 있습니다. 많은 WAF가 봇 탐지, 속도 제한, DDoS 방어 등의 기능도 제공합니다. 하지만 WAF의 핵심 목적은 취약점을 완화하여 애플리케이션을 보호하는 것입니다. 일반적으로 SQLi, XSS, CSRF가 언급되지만, 이제 이러한 공격은 거의 ‘구식’이 되었습니다. 악의적인 공격자들은 명백한 애플리케이션 취약점을 넘어 플랫폼을 표적으로 삼기 시작했습니다. 플랫폼은 공격자가 노릴 수 있는 훨씬 더 많은 피해자를 제공하기 때문입니다. HTTP와 그 프레임워크에 존재하는 플랫폼 취약점은 보안 침해의 원인으로 점점 더 큰 비중을 차지하고 있으며, 엔터프라이즈급 WAF가 제공하는 보호 기능을 통해 이러한 위협에 대응할 수 있습니다.

WAF는 기존의 차단/허용 방식과 시그니처 기반 검사를 활용하고 전체 요청(및 응답)을 검사함으로써, 오늘날 기업이 자사와 고객을 안전하게 보호하는 데 필요한 보안 기능을 제공합니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물