WAF는 어떻게 취약점을 완화하나요?
곧 출간될 2018년 애플리케이션 제공 현황 보고서에서는 웹 애플리케이션 방화벽(WAF) 사용이 수년간 꾸준히 증가하고 있음을 알 수 있습니다. 이는 좋은 일입니다. 오늘날 앱은 고객 및 기업 데이터에 대한 게이트웨이이며 네트워크 계층에서 액세스를 제어하는 기존 방법으로는 충분하지 않기 때문입니다. 그 이유는 점점 더 많은 악의적인 행위자가 디지털 골드를 채굴하기 위해 신원과 애플리케이션 자체를 표적으로 삼고 있기 때문입니다.
그렇다면 WAF는 정원의 잡초처럼 계속 생겨나는 모든 취약점을 어떻게 완화할 수 있을까요? WAF가 웹 공격을 탐지하고 차단하는 데 사용하는 주요 방법은 세 가지입니다. 요청 거부/허용, 검사 및 거부, 서명입니다.
각각 살펴보도록 할까요?
요청 거부/허용
요청 거부/허용 방법은 네트워크 방화벽에서 사용하는 기존의 도어웨이 모델과 매우 유사합니다. 요청은 이용 가능한 정보에 따라 거부되거나 허용됩니다. 해당 정보는 IP 주소와 같이 간단할 수도 있고, OPTIONS나 METHODS와 같이 HTTP에 대한 더 복잡하고 구체적인 정보일 수도 있습니다.
- 거부/허용 목록
특정 IP 주소나 IP 주소 범위에서 나쁜 행위자가 유입되고 있다면, 해당 행위자를 차단하세요. 특정 IP 주소 또는 IP 주소 범위에서만 요청을 수신하도록 애플리케이션이 승인된 경우 해당 요청만 허용하세요. 이것은 가장 간단한 보호 방법이며, 요청이 와야 하는 IP 주소/범위와 같은 상당히 정적인 정보 집합에 의존합니다.
네트워크 방화벽을 사용하면 어떨까 생각하시나요? 결국, 그게 그들이 하는 일이잖아요. 온프레미스에서는 아주 잘 작동합니다. 하지만 퍼블릭 클라우드에서 보호해야 할 앱이 있는 경우 이는 선택 사항이 아닐 수 있습니다. 2018년 애플리케이션 제공 현황 설문 조사에 참여한 사람 중 59%가 이미 2~6개의 다른 클라우드 공급업체에 투자했다면, 공급업체 전체에서 네트워크 방화벽 정책이 동일할 것이라고 기대할 수 없습니다. 물론 여러 클라우드에 동일한 규칙을 구현할 수는 있지만, WAF에서 규칙을 시행하면 여러 환경의 동일한 WAF에서 동일한 정책을 사용할 수 있습니다. 일관성은 보안의 성공과 확장에 중요합니다. - 옵션 제한
HTTP는 일련의 헤더를 사용하여 앱 플랫폼(및 앱)에 사용자가 원하는 작업을 지시합니다. 예를 들어 HTTP 메소드는 리소스를 GET, PUT, POST, DELETE하는 데 사용할 수 있습니다. OPTIONS 필드 역시 WAF에서 쉽게 제어할 수 있는 RFC 제한 값 집합을 갖습니다. Optionsbleed와 같은 일부 취약점은 이러한 필드를 악용합니다. 이러한 취약점을 악용할 수 있는 기능을 제거하려면 WAF를 사용하여 적절한 애플리케이션 실행에 필요한 값으로만 가능한 값을 제한할 수 있습니다. 어떤 경우에는 WAF가 기본적으로 이러한 값을 제한합니다. 예를 들어, BIG-IP ASM(F5 WAF)은 기본적으로 HTTP OPTIONS 방법을 전혀 허용하지 않습니다.
서명
서명은 다양한 보안 솔루션에서 공통적으로 사용되는 또 다른 보호 방법입니다. 바이러스 백신 및 맬웨어 방지 서비스는 바이러스 및 맬웨어의 증거를 빠르게 검사하여 플래그를 지정할 수 있는 서명을 사용합니다. IPS/IDS 역시 WAF와 마찬가지로 이 방법에 크게 의존합니다. 서명에는 사용자 정의 서명과 공급업체 관리 서명의 두 가지 종류가 있습니다.
- 공급업체 관리
공급업체가 관리하는 서명은 일반적으로 공급업체가 자동으로 유지 관리하는 "데이터베이스"에 보관됩니다. 여기에는 고유한 디지털 서명을 통해 새로운 취약점을 식별할 수 있는 경우 데이터베이스를 업데이트하는 것이 포함됩니다. WAF는 들어오는 요청을 데이터베이스에서 스캔하고 데이터베이스의 서명과 일치하는 내용이 발견되면 그에 따라 조치를 취합니다. 서명은 순전히 일반 텍스트일 수도 있지만, 원격 실행 기능을 작동시키거나 앱 플랫폼을 손상시켜 서비스에 대한 액세스를 제공하거나 거부하는 악성 코드를 나타내는 모호한 문자열의 복잡한 조합인 경우가 더 많습니다. - 사용자 정의
사용자 정의 서명을 사용하면 운영자가 데이터베이스에 서명을 신속하게 추가할 수 있습니다. 이 기능은 새로운 취약점에 대한 신속한 대응(많은 경우 제로데이)을 보장하는 데 중요하며, 공급업체에서 관리하는 서명이 아직 발행되지 않은 취약점을 완화하는 데도 중요합니다.
점검
마지막으로, 요청(및 응답)에 대한 완벽한 제어를 보장하기 위해 검사가 포함되었습니다. 요청을 검사하면 WAF가 요청의 정보를 알려진 양호/불량 문자열 및 값과 비교하여 요청이 악성인지 합법적인지 확인할 수 있습니다. HTTP 애플리케이션(현재 인터넷의 대부분 애플리케이션)의 경우 이는 WAF가 제공해야 하는 가장 중요한 기능입니다. WAF가 프로그래밍 가능한 검사를 제공하지 않는 경우 해당 선택을 재고해야 합니다. HTTP는 텍스트 기반이고 확장 가능하기 때문에 요청을 검사하는 데 사용할 수 있는 옵션과 메서드의 포괄적인 "체크박스" 목록을 제공할 방법이 사실상 없습니다. 제한된 옵션을 가진 HTTP 헤더는 거의 없어서, 헤더에 무엇을 넣을 수 있고 무엇을 넣을 수 없는지 제한하기가 매우 어렵습니다. 즉, 헤더나 페이로드 자체에 내장된 악성 코드를 찾아내기 위해서는 종종 검사가 필요하다는 의미입니다. 검사를 사용하는 방법에는 알려진 헤더와 페이로드의 두 가지가 있습니다.
- 알려진 헤더
모든 HTTP 요청에는 잘 정의된 헤더 세트가 포함되어 있습니다. 호스트, 사용자 에이전트, 콘텐츠 유형 등은 거의 어디에나 존재합니다. 각각은 텍스트 문자열에 불과하며, 조합의 폭이 너무 넓어 값을 허용 목록에 추가하기 어렵고 대신 악의적인 값을 개별적으로 검사해야 합니다. 일반적으로 WAF는 HTTP 헤더를 매우 빠르게 구문 분석하여 검사할 수 있습니다. 이러한 악성 코드는 모든 요청의 시작 부분에 있으며 앱 플랫폼을 대상으로 다양한 공격을 저지르는 데 사용된 것으로 알려져 있습니다. 아파치킬러, 옵션 블리드, 그리고 아파치 스트럿츠 잘 알려진 취약점 중 하나입니다. - 탑재물 검사
페이로드 검사는 말 그대로입니다. 취약성을 악용하려는 시도를 나타내는 알려진 영숫자 데이터 조합을 찾기 위해 첫 바이트부터 마지막 바이트까지 전체 페이로드를 검사합니다. 페이로드 검사를 통해 운영자는 사용자 지정 HTTP 헤더와 요청 본문을 검사하여 악성 활동의 특정 지표를 파악할 수 있습니다. 이렇게 하려면 WAF가 먼저 요청의 전체 내용을 보관해야 합니다. 패킷이 저장할 수 있는 데이터의 양이 제한되어 있고, 악성 데이터가 두 패킷에 걸쳐 있는 경우 패킷 단위로만 검사하는 서비스에서는 발견되지 않을 수 있기 때문에 이 작업이 필요합니다. WAF는 전체 페이로드를 검사하여 악성 데이터가 어디에 발생하든 상관없이 이를 찾아내어 대상에 도달하는 것을 방지합니다.
WAF는 애플리케이션을 보호하기 위해 취약점을 완화하는 데 그치지 않고 더 많은 역할을 할 수 있습니다. 많은 기능에는 봇 감지, 속도 제한, DDoS 방지 등 다양한 기능이 포함되어 있습니다. 하지만 WAF의 핵심 목적은 취약점을 완화하여 애플리케이션을 보호하는 것입니다. SQLi, XSS, CSRF가 주로 언급되지만, 이 시점에서는 거의 "옛날 이야기"에 가깝습니다. 악의적인 행위자들은 앱의 명백한 취약점을 넘어 플랫폼을 표적으로 삼기 시작했습니다. 그 이유는 해당 플랫폼이 훨씬 더 많은 피해자를 확보할 수 있는 기반을 제공하기 때문입니다. HTTP 및 프레임워크의 플랫폼 취약성은 엔터프라이즈급 WAF가 제공하는 보호 기능을 활용하는 침해의 증가하는 원인입니다.
WAF는 전체 요청(및 응답)을 검사하는 기능을 갖춘 기존의 거부/허용 및 서명 기반 검사를 채택함으로써 오늘날 기업이 자체와 고객을 안전하게 보호하는 데 필요한 보호 기능을 제공합니다.