웹방화벽(WAF)에 대한 이해

By PLURA

🔍 온프레미스 환경에서 웹 애플리케이션 보안을 강화하기 위해 웹방화벽(WAF)은 필수적으로 사용됩니다.
그런데 WAF는 “도입 여부”만큼이나 어떤 방식으로 배포하느냐가 중요합니다.

특히 온프레미스 환경에서는 여전히 인라인 모드가 널리 사용되지만,
실제 운영과 공격 대응 관점에서는 리버스 프록시 모드가 더 안전한 경우가 많습니다.

핵심은 단순합니다.

WAF의 문제는 제품 그 자체보다,
배포 방식과 운영 구조에서 더 자주 발생합니다.

waf

먼저 요점만 정리하면

  • 인라인 WAF는 배포가 쉽지만, 과부하·우회·Fail-open 위험을 함께 가질 수 있습니다.
  • 리버스 프록시 WAF는 오리진 IP를 숨기고, Direct-to-Origin 공격면을 줄이기 쉽습니다.
  • 인라인이든 프록시든 운영 미스가 있으면 우회 경로는 생깁니다.
  • 따라서 중요한 것은 “어떤 제품인가”보다
    어떤 구조로 배치하고, 어떤 정책으로 운영하는가입니다.

1. 웹방화벽의 두 가지 대표 배포 모드

✅ 인라인 모드 (Inline Mode)

인라인 모드는 네트워크 경로에 직접 배치되어
웹 트래픽을 통과시키면서 검사하는 방식입니다.

장점

  • 네트워크 경로에 바로 넣을 수 있어 배포가 상대적으로 간단
  • 기존 구조를 크게 바꾸지 않고 빠르게 적용 가능
  • 통과 트래픽을 실시간으로 차단 가능

단점

  • 장애 발생 시 서비스 전체 트래픽에 직접 영향
  • 과부하 시 병목이 되기 쉬움
  • 구성에 따라 Fail-open 위험 존재
  • L7 범위를 넘어서는 L3/L4(대량 SYN/UDP 등) 이나
    비웹 포트(SSH/RDP 등) 공격은 별도 통제가 필요

즉, 인라인은 편리하지만
그 편리함 뒤에 가용성과 우회 리스크가 숨어 있습니다.

✅ 리버스 프록시 모드 (Reverse Proxy Mode)

리버스 프록시는 클라이언트와 오리진 서버 사이에서
트래픽을 중개하는 방식입니다.

장점

  • 외부에 보이는 것은 프록시/VIP
  • 오리진(웹서버) IP를 숨기기 쉬움
  • SSL 종료, 로드 밸런싱 등 추가 기능 활용 가능
  • WAF 다운 시 Fail-close 설계가 상대적으로 수월
  • Direct-to-Origin 공격면 축소

주의점

  • 잘못된 설정이 있으면 우회 가능성은 여전히 존재
  • 남아 있는 A레코드, 테스트 도메인, 과도한 SG 개방, 헬스체크 직접 접근, Host 헤더 우회 등은 오리진 노출 경로가 됨

즉, 리버스 프록시는 더 안전한 선택일 수 있지만,
운영 실수까지 자동으로 없애주지는 않습니다.

2. 인라인 vs 리버스 프록시를 한눈에 보면

항목 인라인 리버스 프록시
배포 편의성 높음 상대적으로 낮음
오리진 IP 노출 대체로 공개 비공개(설정 미스 시 유출 가능)
Direct-to-Origin 공격 가능(차단 장치 필요) 원칙적으로 차단 가능
장애 시 동작 Fail-open/close 구성에 따라 달라짐 Fail-close 설계가 상대적으로 용이
디도스 내성 장비가 병목이 되기 쉬움 상단 보호·오프로딩 연계 유리
운영 난이도 초기 도입은 쉬움 구조 설계가 더 중요
보안성 보완 통제가 필수 일반적으로 더 유리

중요한 점
Fail-open / Fail-close는 배포 모드 자체와 1:1로 고정되지 않습니다.
장비, 설정, HA 구조에 따라 달라지며, 리버스 프록시는 진입점 특성상 Fail-close 채택이 쉬운 편입니다.

3. 아키텍처로 보면 왜 차이가 날까

인라인 WAF 구조

flowchart LR
    USER["사용자"] --> FW["경계 방화벽"]
    FW --> WAF["인라인 WAF"]
    WAF --> ORIGIN["오리진 웹서버"]

waf

이 구조는 단순하고 빠르지만,
외부에서 오리진을 직접 겨냥할 수 있는 가능성이 상대적으로 큽니다.
또한 WAF 자체가 트래픽 경로의 병목이 될 수 있습니다.

리버스 프록시 WAF 구조

flowchart LR
    USER["사용자"] --> PROXY["리버스 프록시 WAF"]
    PROXY --> ORIGIN["오리진 웹서버"]
    ORIGIN --> XDR["로그 / XDR 분석"]
    PROXY --> XDR

waf

이 구조에서는 외부 사용자가 직접 보는 것은 프록시뿐이며,
오리진은 내부망 또는 제한된 네트워크에 둘 수 있습니다.
또한 WAF 이벤트와 오리진 로그를 함께 분석하면
차단 실패 이후의 행위까지 추적할 수 있습니다.

4. 인라인 전수 분석이 실제로 깨지는 대표 시나리오

인라인 WAF가 “모든 웹 공격을 전부 완벽하게 본다”고 생각하기 쉽지만,
실제 운영에서는 다음과 같은 공백이 자주 발생합니다.

(1) Oversize / Streaming Body

  • 요청 바디가 장비의 검사 한계를 넘으면
    부분 검사 후 통과하거나 사실상 우회될 수 있습니다.
  • Chunked 전송, Multipart, 대용량 업로드에서 자주 발생합니다.
  • 공격 페이로드를 바디 깊숙이 숨기면 탐지 누락 위험이 커집니다.

(2) 부하 시 Fail-open

  • CPU, 메모리, 큐가 포화되면
    일부 장비는 가용성을 위해 검사 기능을 강등하거나 Fail-open 으로 전환합니다.
  • 하드웨어 바이패스 옵션이 켜져 있으면
    전원/링크 이슈 때 물리적으로 우회가 일어날 수도 있습니다.

(3) TLS / HTTP3(QUIC) 미종단

  • 인라인 장비가 TLS를 실제로 종단하지 않으면
    본문을 제대로 보지 못하고 헤더 수준만 보는 경우가 생깁니다.
  • HTTP/3(QUIC)는 더 강합니다.
    QUIC을 종단하지 않으면 사실상 의미 있는 L7 검사가 어렵습니다.

(4) 비대칭 라우팅 / 세션 재조립 실패

  • 요청과 응답 경로가 다르거나
    Fragment / Out-of-order 패킷이 많으면
    세션 재조립 실패로 탐지 공백이 생길 수 있습니다.

(5) 정책 / 예외에 의한 사실상 우회

  • 탐지 전용 모드
  • 과도한 화이트리스트
  • X-Forwarded-For 조작 허용
  • 광범위한 예외 정책

등은 장비가 살아 있어도 실질적으로 우회된 상태를 만듭니다.

5. 왜 이런 문제가 생기나? (기술 배경)

PFS/TLS 특성

현대 TLS(1.2 ECDHE, 1.3)는 Perfect Forward Secrecy가 기본입니다.
즉, 서버 개인키만으로는 중간 복호화가 되지 않습니다.
결국 인라인 장비가 실제로 TLS를 종단하지 않으면 애플리케이션 페이로드를 볼 수 없습니다.

QUIC(HTTP/3)의 구조

QUIC은 UDP 기반이며 TLS 1.3이 통합되어 있습니다.
스트림·패킷 번호·다수 헤더까지 보호되므로,
종단하지 않으면 사실상 L7 검사 자체가 어렵습니다.

‘TLS 미종단 = 사실상 L3/L4 장비’

TLS를 끝내지 않으면 세션 재조립, 본문 검사, 정교한 규칙 적용에 한계가 생깁니다.
즉, 장비가 WAF처럼 보이더라도 실제로는
L3/L4 수준의 통제에 가까워질 수 있습니다.

6. 인라인은 편리하지만, 왜 리버스 프록시가 더 안전한가

많은 기업들이 인라인을 택하는 이유는 분명합니다.

  • 빠른 도입
  • 네트워크 변경 최소화
  • 즉시 차단 가능
  • 운영팀이 익숙함

하지만 보안성만 놓고 보면
리버스 프록시 방식은 다음 점에서 더 유리합니다.

  • 오리진 은닉
  • Direct-to-Origin 차단
  • Fail-close 설계 용이
  • 상단 DDoS 보호 연계
  • 정책과 인증을 한곳에서 통제

즉,
인라인은 “편리한 선택”일 수 있지만,
리버스 프록시는 더 자주 “안전한 선택”이 됩니다.

7. 그래서 언제 무엇을 선택해야 할까?

인라인이 어울리는 경우

  • 기존 온프레미스 구조를 크게 바꾸기 어려움
  • 빠른 도입이 필요함
  • 비교적 단순한 웹 서비스
  • 별도의 Direct-to-Origin 차단과 L3/L4 보완 통제가 이미 있음

리버스 프록시가 더 적합한 경우

  • 인터넷 노출 서비스가 핵심 자산임
  • 오리진 은닉이 중요함
  • 대규모 서비스 또는 공격 표면이 큼
  • DDoS, API 보호, 인증 통제를 함께 강화해야 함
  • 가용성과 보안성을 동시에 높여야 함

한 줄로 정리하면

“빨리 넣을 것인가”보다
“어디까지 안전하게 운영할 것인가”를 먼저 결정해야 합니다.

8. 비용 관점에서 보면

온프레미스에서 리버스 프록시 WAF를 새로 구축하려면
네트워크 구조 변경, 추가 장비, 운영 설계 비용이 발생할 수 있습니다.

반면 클라우드 기반 WAF는 상대적으로:

  • 초기 구축 부담이 적고
  • 오리진 은닉 구조를 만들기 쉽고
  • 글로벌/원격 운영에 유리하며
  • 업데이트와 운영 자동화 측면에서 강점을 가집니다

이 점에서 PLURA 클라우드 WAF와 같은 접근은
온프레미스 인라인 WAF의 구조적 한계를 줄이는
현실적인 대안이 될 수 있습니다.

또한 WAF만으로 끝나는 것이 아니라,
차단·허용·우회 흔적을 이후 PLURA-XDR과 연결해
행위 분석과 사고 대응까지 확장할 수 있습니다.

즉, 중요한 것은
배포 방식 선택 + 로그/XDR 연계를 함께 보는 것입니다.

9. 결론

✅ 온프레미스 환경에서 인라인 WAF는 여전히 널리 사용됩니다.
✅ 그러나 디도스 대응, 장애 내성, Direct-to-Origin 공격면 축소 관점에서는
리버스 프록시 방식이 더 유리한 경우가 많습니다.
✅ 인라인의 장점을 살리려면
Direct-to-Origin 차단, L3/L4 보호, HA/바이패스 점검 같은 보완 통제가 반드시 필요합니다.
✅ 최적의 선택은
조직의 네트워크 구조, 가용성 목표, 공격 노출면, 운영 여건을 종합적으로 검토해 결정해야 합니다.

결론적으로,
인라인은 “쉽게 넣을 수 있는 WAF”이고,
리버스 프록시는 “더 안전하게 설계할 수 있는 WAF”입니다.

부록: 빠른 체크리스트

인라인 도입 시

  • 외부 → 오리진 직접 경로 차단(Direct-to-Origin ACL)
  • L3/L4 디도스 보호(상단 방화벽/ISP 스크러빙/RTBH)
  • 관리 포트(SSH/RDP) 전용망·VPN만 허용
  • HA(Active-Standby) 및 바이패스 정책 정기 점검
  • WAF/L4/LB 헬스체크 Rate-limit 및 격리
  • Oversize / Chunked / Multipart 정책 점검
  • TLS/HTTP3 종단 여부 확인

리버스 프록시 도입 시

  • 오리진 보안그룹/방화벽: 프록시 IP만 화이트리스트
  • 오리진 공인 IP 제거 또는 비공개 서브넷 배치
  • mTLS + 고정 Host/SNI 적용
  • 직통 A레코드/테스트 도메인/옛 IP 완전 제거
  • 헬스체크 전용 네트워크/소스 IP 분리
  • WAF 이벤트와 오리진 로그의 XDR 연계 구성

Tags