WAF

Web Application Firewall

웹 애플리케이션을 노린 공격으로부터 보호하기 위해 HTTP/HTTPS 트래픽을 검사하고 차단하는 보안 장비이다. 일반적인 방화벽이나 IDS/IPS가 네트워크 계층(L3~L4)을 중심으로 동작한다면, WAF는 애플리케이션 계층(L7) 에서 웹 요청의 의미까지 들여다본다.

이름 그대로 "웹 애플리케이션 전용 방화벽"이며, SQL Injection, XSS, CSRF처럼 일반 방화벽이 잡지 못하는 웹 특화 공격을 막는 것이 주 역할이다. North-South 트래픽에서 perimeter 방어의 마지막 한 겹을 담당하며, 외부에 공개되는 모든 웹 서비스가 사실상 필수로 도입하는 보안 계층이다.

일반 방화벽, IDS/IPS와의 차이

세 보안 장비를 비교하면 검사 깊이와 대상이 다르다.

구분	방화벽	IDS/IPS	WAF
검사 계층	L3~L4	L3~L7	L7 (HTTP/HTTPS 전용)
검사 대상	IP, 포트, 프로토콜	패킷 페이로드, 패턴	HTTP 헤더, URL, 파라미터, 쿠키, 본문
차단 기준	정책 룰 (allow/deny)	시그니처, 이상 행위	웹 공격 패턴, 애플리케이션 행위
막는 공격	포트 스캔, 무차별 접근	알려진 공격 패턴, 악성코드	SQL Injection, XSS, CSRF, 파일 업로드 공격
비유	출입증 검사	가방 안 검사	의도와 행동 패턴까지 분석

방화벽이 "이 IP에서 이 포트로 들어오는 트래픽은 허용한다"고 결정하면, WAF는 "허용된 그 HTTP 요청 안의 SQL 쿼리가 정상인지" 까지 한 번 더 들여다본다. 그래서 WAF는 보통 방화벽 안쪽 또는 웹 서버 앞단에 배치된다.

막아내는 대표 공격

WAF가 주로 방어하는 공격은 OWASP Top 10에 정리된 웹 보안 위협들이다.

공격	설명
SQL Injection	입력값에 SQL 구문을 끼워 넣어 DB를 조작하는 공격 (`' OR 1=1 --` 등)
XSS (Cross-Site Scripting)	웹 페이지에 악성 스크립트를 주입해 다른 사용자의 세션을 탈취
CSRF (Cross-Site Request Forgery)	사용자가 의도하지 않은 요청을 강제로 발생시킴
Path Traversal	`../../etc/passwd` 같은 경로 조작으로 시스템 파일 접근
Command Injection	입력값에 OS 명령을 끼워 넣어 서버에서 실행
File Upload 공격	악성 파일을 업로드해 원격 코드 실행
HTTP Flood / Application DDoS	대량의 정상 형태 요청으로 애플리케이션을 마비
Bot / Scraping	자동화된 크롤러나 봇으로부터 보호
API Abuse	API 남용, 비정상 호출 패턴 차단

동작 방식

WAF는 보통 다음 순서로 트래픽을 검사한다.

[클라이언트]
    │
    │ HTTP Request
    ▼
┌─────────────────────────────┐
│  WAF                        │
│  1. 요청 파싱 (URL, 헤더,      │
│     파라미터, 본문 분리)        │
│  2. 정책/시그니처 검사          │
│  3. 허용 / 차단 / 챌린지        │
└─────────────────────────────┘
    │
    ▼
[웹 서버 / 애플리케이션]

검사 룰은 크게 두 모델로 나뉜다.

Negative Security Model (블랙리스트)

알려진 공격 패턴을 모아둔 시그니처 데이터베이스와 매칭한다. 시그니처에 걸리면 차단.

장점: 빠르게 도입 가능. 운영 부담 적음
단점: 새로운 공격(zero-day)에 약함
대표 룰셋: OWASP ModSecurity Core Rule Set (CRS)

Positive Security Model (화이트리스트)

각 엔드포인트, 파라미터, 헤더의 정상 형태를 명시적으로 정의해두고, 그 외의 요청은 모두 차단한다.

장점: 알려지지 않은 공격까지 방어 가능
단점: 애플리케이션마다 정책을 세밀히 정의해야 해서 운영 부담 큼

실무에서는 두 모델을 혼합해 사용한다. 외부 트래픽은 negative 모델로 거르고, 결제처럼 민감한 엔드포인트만 positive 모델로 강하게 보호하는 식이다.

배치 방식

WAF는 어디에 두느냐에 따라 운영 방식이 달라진다.

Network 기반 (Inline Appliance)

데이터센터 입구에 전용 어플라이언스를 두고 트래픽을 가로챈다.

대표 제품: F5 BIG-IP ASM, Imperva SecureSphere, Citrix Web App Firewall
한 대로 여러 웹 서비스를 동시에 보호 가능

Host 기반 (Web Server Module)

웹 서버 안에 모듈로 동작한다.

대표 제품: ModSecurity (Apache, Nginx, IIS용 오픈소스 WAF가 가장 유명)
서버마다 설치/관리 필요

Cloud 기반 (Cloud WAF)

CDN/리버스 프록시 형태로 인터넷 경로 위에 위치한다. 트래픽이 데이터센터에 도달하기 전에 검사된다.

Cloudflare WAF
AWS WAF
Azure WAF (Front Door, Application Gateway)
Google Cloud Armor
Akamai Kona

오늘날 가장 빠르게 성장하는 형태이다. 사용자에게 가까운 edge에서 차단하므로 백엔드 부하도 줄이고 DDoS 흡수에도 유리하다.

배치 방식	위치	장점	단점
Network 기반	데이터센터 경계	통합 관리, 고성능	어플라이언스 비용
Host 기반	웹 서버 안	비용 저렴, 세밀한 제어	서버 자원 사용, 운영 부담
Cloud 기반	Edge / CDN	빠른 도입, DDoS 흡수, 확장성	외부 의존, 트래픽 우회 위험

운영 모드

WAF는 도입 직후 바로 차단 모드로 돌리지 않는 것이 일반적이다. 오탐(false positive)으로 정상 사용자를 막을 위험 때문이다.

모드	동작
Detection / Monitor 모드	의심 트래픽을 로그로만 남김. 차단 안 함
Blocking 모드	의심 트래픽을 즉시 차단
Challenge 모드	CAPTCHA, JavaScript 챌린지 등으로 사람/봇 구분

보통 도입 초반은 Detection 모드로 운영하면서 룰을 튜닝하고, 충분히 안정화된 후에 Blocking 모드로 전환한다. 이 단계를 튜닝(Tuning) 기간 이라고 부른다.

한계와 진화

한계

암호화 트래픽: HTTPS를 검사하려면 WAF가 TLS 종단점이 되어 복호화해야 함. 인증서 관리와 성능 부담 발생
오탐: 룰이 강하면 정상 사용자가 차단될 수 있음. 운영 인력의 지속적인 튜닝 필요
룰 유지보수 부담: 애플리케이션이 자주 바뀌면 WAF 룰도 따라 바뀌어야 함
Latency: Inline 위치에서 룰 매칭과 TLS 복호화 처리로 응답에 수 ms~수십 ms 수준의 지연이 추가됨

최근 흐름

머신러닝 기반 탐지: 시그니처를 넘어 정상 사용 패턴을 학습해 이상 행위를 식별
API Security 통합: REST/GraphQL API를 위한 별도 룰셋과 검사 로직
Bot 관리: WAF가 봇 탐지 기능을 흡수해 통합 제공
WAAP (Web Application and API Protection): WAF에 DDoS 방어, Bot 관리, API 보안을 합친 개념. Gartner가 정의한 카테고리이며 최근의 표준 흐름

대형 클라우드 사업자들의 보안 제품(Cloudflare, AWS, Akamai 등)은 이미 사실상 WAAP 형태로 통합되어 제공된다.

정리

WAF = 웹 애플리케이션 전용 보안 장비. L7에서 HTTP/HTTPS를 검사
방어 대상: SQL Injection, XSS, CSRF 같은 OWASP Top 10 위협
검사 모델: Negative (블랙리스트) + Positive (화이트리스트) 혼합
배치 방식: Network / Host / Cloud 세 가지. 최근은 Cloud WAF가 주류
운영: Detection → Blocking으로 단계적 도입. 튜닝이 핵심
최근 동향: WAAP로 통합. DDoS, Bot, API 보안과 합쳐짐