WAF(웹 방화벽) 소개

WAF (Web Application Firewall)

WAF는 웹 애플리케이션으로 들어오는 트래픽을 모니터링 및 필터링하여 악성 요청으로 의심되는 요청들을 차단하고 웹 앱을 보호하고 승인되지 않은 데이터가 앱에서 나가는 것을 방지한다.

 

방화벽 (Firewall)과의 차이점

일반적인 방화벽과의 차이점은, 방화벽은 OSI 7 Layer 중 L4 수준에서의 트래픽을 관리 및 차단한다. 구체적으로 이야기 하자면, IP와 Port를 기준으로 트래픽을 허용할지 차단할지 설정한다. 방화벽에 의해 차단되는 경우, 실제 애플리케이션까지 트래픽이 도달하지 않기 때문에 클라이언트에서는 타임아웃이 발생한다.

 

반면에 WAF는 OSI 7 Layer 중 L7 수준에서의 트래픽을 관리 및 차단한다. 그 중에서 HTTP 정보를 기반으로 트레픽을 관리 및 차단하기 때문에 Request Header, Request Body, URI, Method 등의 정보를 기반으로 트래픽을 허용할지 차단할지 설정한다. WAF에 의해 차단되는 경우, 웹서버(WAF) 까지 트래픽이 도달하기 때문에 타임아웃은 나지 않지만, WAF에서 에러를 리턴함으로써 트래픽을 실제로 처리하지 못하도록 차단한다.

 

구체적으로 어떤 요청을 차단하는 데 사용할까?

방화벽은 특정 위치에 있는 클라이언트만 요청을 허용하는 것으로 예상치 못한 외부 요청에 대해 보호하는 데 의의가 있다. 그런데 보통 외부로 서비스 하는 시스템은 인터넷 상으로 노출되어야 하며, 그렇기 때문에 모든 사람들이 해당 서비스에 접근할 수 있다. 그리고 보통은 서버에서는 특정 기능을 제공하기 위해 API를 만들어 배포한다. 여기서 API는 어떻게 요청하면 되는지에 대해 문서로 명세가 되어있는 경우도 있지만, 따로 명세가 되어있지 않지만 프론트엔드에서 요청하기 위해 만드는 API도 있다.

 

여기서 문제는 웹 API는 개발자 도구만 열어보면 어떻게 요청할 수 있는지 대략적으로 파악이 가능하고, API가 사람이 만든 것이다 보니 보안 측면에서 구멍이 있는 API가 있을 수 있다. 웹 API는 접근방식이 쉽기 때문에 보안의 허점도 많이 알려져있는데, 대표적으로 XSS (Cross Site Scripting), SQL Injection 등의 공격이 있다.

 

이러한 공격방식은 요청에 대한 특정 패턴이 존재하며, 애플리케이션 내에서 해당 패턴을 차단하거나 무효화 시킴으로써 공격을 방어할 수 있는데, WAF에서 이러한 공격패턴이 들어오면 요청을 차단하게 할 수 있다.

 

WAF 배포 방식

WAF는 여러 형태로 존재할 수 있는데, 크게는 두 가지가 있다.

• Cloud 상에서 상품으로써 제공 - 대표적으로 AWS WAF가 있는데 ALB 앞에 상품이 깔려있고, WAF에서 차단되지 않은 요청만 ALB로 접근할 수 있으며 요청이 처리된다.
  
• On-Prem에 직접 배포 - WAF 기능을 제공하는 오픈소스를 사용하여 직접 배포하고, 차단 룰을 설정하여 WAF를 직접 관리할 수 있다. (Cloud와 비슷, 그림 예시는 Istio를 Ingress로 사용하는 경우 coraza waf를 istio ingressgateway에 주입하는 경우이다.)

 

WAF를 사용해야 하는 이유

예전에는 모놀로식 아키텍쳐 형식으로 웹 애플리케이션을 서빙하였다. 모놀로식의 특징이라면 하나의 큰 서비스에 대한 비즈니스 로직들을 하나의 서버에다가 전체적으로 관리하는 형식으로, 하나의 웹 애플리케이션이 하나의 큰 서비스를 통째로 서빙하는 구조이다. 이러한 구조라면 하나의 웹 애플리케이션에서 웹 공격에 대해 차단하는 필터를 구현해도 크게 상관이 없을 것이다.

 

하지만, 요즘은 모놀로식에서 마이크로서비스 아키텍처로 전환하거나 처음부터 마이크로서비스 아키텍처를 기반으로 설계하여 배포하는 서비스도 많다. 마이크로서비스 아키텍처의 경우에는 하나의 큰 서비스를 여러 도메인으로 쪼개 독립적인 여러 웹 애플리케이션으로 분할하여 배포하는 구조로 되어있다.

 

즉, 여러개의 웹 애플리케이션이 하나의 큰 서비스를 서빙하는 구조로 보면 되는데, 웹 애플리케이션이 많기 떄문에 각 웹 애플리케이션마다 웹 공격에 대해 차단하는 필터를 구현하고 관리하는데 힘들 수 있다. 필터가 변경되어야 하는 경우 모든 마이크로서비스에게 신경을 써야하고, 신규 마이크로서비스를 추가하여 배포할 때 필터가 있는지 보장이 되지 않기 때문이다.

 

각 웹 애플리케이션마다 웹 공격에 대해 차단하는 필터를 구현하고 관리하기 힘들다면 API Gateway에만 적용하는 방법 또한 있다. 이 경우에는 위의 경우보다는 그래도 관리하기 편해 보인다.

 

하지만 필터를 구현하는 것 자체가 힘들 수 있다. API Gateway의 역할 중 하나가 보안 정책을 시행하는 것이긴 한데, 필터 등으로 직접 구현하기 위해서는 보안과 관련된 지식이 어느정도 풍부해야 한다. 수많은 공격에 대응하기 위해 필터를 관리하는 것이 공수가 들 가능성이 크고, 잘못된 정책을 추가한다면 에러를 유발하여 장애까지 번질 수 있다.

 

만약 직접 구현하지 않고 WAF를 사용한다면 직접 구현하는 것 보다는 진입 장벽이 낮을 것으로 보인다. 클라우드 상품을 사용하는 경우라면, 전문적인 클라우드일수록 WAF 상품에 대한 신뢰도가 있을 것이고, Coraza와 같은 WAF 오픈소스를 사용하여 직접 구축하는 경우라도, 어떤 방식으로 보안 룰을 갖춰야 할지에 대한 가이드라인을 오픈소스 문서에서 배우고 사용할 수 있기 때문에 WAF를 사용하는 것이 더 효과적일 수 있다.

 

마무리

이번 글에서는 WAF에 대해 소개하였고, 다음 글에서는 Coraza와 같은 WAF 오픈소스에 대해 소개하고 사용 방법 등을 작성하려고 한다.