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

By PLURA 2025-01-31

🔍 온프레미스 환경에서 웹 애플리케이션 보안을 강화하기 위해 웹방화벽(WAF)이 필수적으로 사용됩니다. 웹방화벽의 배포 방식에는 대표적으로 인라인 모드와 리버스 프록시 모드가 존재하며, 기업들은 각 환경에 맞춰 적절한 방식을 채택합니다. 그렇다면 실제로 온프레미스 환경에서 인라인 WAF는 얼마나 많이 사용되고 있을까요?

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

✅ 인라인 모드 (Inline Mode) – 하지만 위험할 수도 있다!

🔥 장점: 네트워크 경로에 직접 배치되어 추가적인 라우팅 설정이 필요 없습니다.
🚨 단점: 장애 발생 시 트래픽 차단 위험, 네트워크 병목 가능성, 디도스 공격 시 취약성이 존재합니다.
L7(WAF) 범위를 넘어서는 L3/L4(대량 SYN/UDP 등)나 비웹 포트(SSH/RDP 등) 공격은 방화벽·ACL·세그먼테이션 등 별도 통제가 필요합니다.
디도스 공격 시, 인라인 모드의 WAF가 다운되면 웹 서비스 전체가 마비될 위험이 큽니다.
실제로 인라인 방식 사용 중 과부하로 인해 WAF가 장애를 겪고 서비스가 중단된 사례가 적지 않습니다.

Inline

✅ 리버스 프록시 모드 (Reverse Proxy Mode) – 더 안전한 선택!

🔥 장점: 높은 유연성, 장애 발생 시 트래픽 우회 가능, 디도스 방어에 유리!
클라이언트와 서버 사이에서 트래픽을 중개하는 방식입니다.
SSL 종료, 로드 밸런싱 등 추가 성능 최적화가 가능합니다.
일반적으로 외부에서 보이는 것은 프록시/VIP이며, 오리진(웹서버) IP는 숨길 수 있어 Direct-to-Origin 공격면을 축소합니다.
WAF가 다운될 경우 트래픽을 차단(Fail-close) 하는 구성이 쉬워 공격이 직접 웹 서버에 전달되지 않도록 할 수 있습니다.

📌 그러나 주의할 점:

일부 환경에서는 Fail-open(우회) 설정이 되어 있으면, WAF가 다운될 때 웹 서버로 직접 트래픽이 전달될 수도 있습니다.
운영 미스로 남아 있는 A레코드/테스트 도메인, 과도한 SG/방화벽 개방, 헬스체크의 직접 접근, Host 헤더 우회 등은 오리진 노출·우회 경로가 될 수 있습니다.

reverse_proxy

1.2 IP 노출과 공격면(Attack Surface) 관점 비교

요지: 리버스 프록시는 오리진(웹서버) IP를 숨겨 직접공격(Direct-to-Origin) 을 어렵게 하지만, 절대 안전을 보장하지는 않습니다.
인라인은 배포가 간단하지만 오리진이 외부에 공개되는 경우가 많아 주변 보안통제가 필수입니다.

✅ 인라인

오리진 IP 노출 가능성: 투명 브리지/라우팅형 구성에서는 클라이언트가 보통 오리진의 공인 IP로 접속합니다. → 스캐닝/디도스/직접공격 대상이 될 수 있습니다.
보호 범위의 한계: WAF는 주로 L7(HTTP/HTTPS) 방어에 특화되어 있어, L3/L4 대역이나 비웹 포트(SSH·RDP 등) 는 별도 방화벽·ACL·세그먼테이션이 필요합니다.
운영 보완책: Direct-to-Origin 차단 ACL, 관리 포트 비공개망, RTBH/Flowspec, L4/LB 연동 Rate-limit, 이중화(HA)+바이패스 정책 점검.

✅ 리버스 프록시

오리진 IP 은닉: 외부에서 보이는 것은 프록시/VIP이며, 오리진 IP는 일반적으로 비공개로 운영합니다.
주의할 우회/노출 경로: 남아 있는 A레코드·테스트 도메인, 보안그룹 과다 개방, 헬스체크의 직접 접근, Host 헤더 우회, Any-to-Origin 허용 등.
운영 보완책: 오리진 방화벽을 프록시 IP만 화이트리스트, mTLS(프록시↔오리진), 고정 Host/SNI, 헬스체크 전용 네트·IP 분리, 불필요 공인 IP 폐기.
오해 바로잡기: “다른 어떤 공격으로부터 완전히 안전”하진 않습니다. 프록시를 경유한 L7 취약점, API 남용, 세션/인증 탈취, WAF 우회, SSRF 등은 여전히 위협입니다.

항목	인라인	리버스 프록시
오리진 IP 노출	대체로 공개	비공개(설정 미스 시 유출 가능)
Direct-to-Origin 공격	가능(차단 장치 필요)	원칙적으로 차단(프록시·ACL로 제한)
비웹 포트 노출	네트워크 설계에 좌우	직접 경로 없음(원칙)
장애 시 동작	Fail-open/close 구성에 의존, 병목 위험	Fail-close/오프로드 구성 용이
디도스 내성	장비가 병목 되기 쉬움	상단 보호·오프로딩 연동 유리

메모: Fail-open/Fail-close는 “배포 모드”와 1:1로 묶이지 않습니다. 장비/설정/HA 구조에 따라 달라지며, 리버스 프록시는 트래픽 진입점 특성상 Fail-close 채택 비중이 높은 편입니다.

1.3 인라인 전수 분석이 깨지는 대표 시나리오

(1) Oversize/Streaming 바디

요청 바디가 WAF의 바디 제한(메모리/디스크 버퍼)을 넘으면, 장비/규칙에 따라 부분 검사(ProcessPartial) 후 통과하거나, 우회 경로로 빠질 수 있습니다.
Chunked 전송, 멀티파트, 대용량 업로드 등에서 흔합니다. 공격 페이로드를 바디 깊숙이 숨기면 탐지 누락 위험이 커집니다.
벤더 주의: 일부 제품은 요청 바디 64KB(리소스 유형에 따라 기본 8–16KB, 최대 64KB)까지만 검사하고, 상한 초과 시 Oversize handling = Continue(부분 우회/bypass) 로 동작하도록 설정할 수 있습니다. 이 경우 상한을 넘는 구간에 숨겨진 페이로드가 검사를 우회할 수 있습니다.

(2) 부하/자원 고갈 시 Fail-open

CPU/메모리/큐 포화 시 일부 장비는 가용성 보호를 위해 검사 기능 강등 또는 Fail-open(우회 통과) 로 전환합니다.
NIC의 하드웨어 바이패스(퓨즈/릴레이) 옵션이 켜져 있으면 전원/링크 이슈 때 물리 우회가 일어납니다.

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

인라인 L2/L3 통과만 하고 TLS를 종단(종료)하지 않으면 실제 페이로드는 복호화되지 않아 헤더 수준만 보게 됩니다.
HTTP/3(QUIC) 은 L7 프록시가 QUIC을 종단하지 않으면 의미 있는 검사 불가입니다.

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

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

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

학습/탐지 전용 모드, 과도한 신뢰 IP 화이트리스트, X-Forwarded-For 조작 허용 등으로 실질적 우회가 발생합니다.

(3)-A. 왜 인라인에서는 문제가 발생하나요? (기술 배경)

PFS/TLS 특성상 수동 복호화 불가
현대 TLS(1.2 ECDHE, 1.3)는 Perfect Forward Secrecy가 기본이라 서버 개인키만으로 중간 복호화가 불가합니다. → 인라인이 종단(=서버 역할) 이 아니면 애플리케이션 페이로드를 볼 수 없습니다(SNI 등 일부 메타만 확인).
QUIC(HTTP/3)는 더 강한 ‘엔드포인트 의존’
QUIC은 UDP 기반 + TLS 1.3 통합 구조로, 스트림·패킷 번호·다수 헤더까지 보호합니다. → 인라인이 QUIC을 종단하지 않으면 사실상 L7 검사 불가입니다.
‘TLS 미종단’ = 사실상 L3/L4 장비
TLS를 끝내지 않으면 세션 재조립/본문 검사/규칙 적용을 제대로 못 하거나, 성능 이슈 시 부분 검사/바이패스 같은 보호 강등이 발생할 수 있습니다.
예외
인라인 장비가 TLS를 실제로 종단(복호화) 한다면 가능한데, 그 순간 역할은 사실상 프록시(브릿징이 아닌 L7 종단) 가 됩니다. 외부 고객 대상 서비스에서는 중간자 인증서를 쓸 수 없으니 일반 공용 서비스에 적용하기 어렵고(사내 프록시/차단 게이트웨이는 별개 맥락) 현실적 제약이 큽니다.

2. 인라인 방식은 편리하지만, 리버스 프록시 방식이 더 안전하다

💡 많은 기업들이 인라인 방식을 선택하는 이유는 배포가 간단하고, 네트워크 변경 없이 빠르게 적용할 수 있기 때문입니다. 또한, 모든 트래픽을 실시간으로 검사하여 즉각적인 차단이 가능하다는 점도 장점으로 꼽힙니다. 그러나 보안 측면에서 인라인 방식은 치명적인 단점을 가질 수 있습니다.

📊 온프레미스 WAF 배포 방식 선호도 (현장 체감 기준)

인라인 모드: 배포 간편성 등 이유로 여전히 널리 사용됩니다.
리버스 프록시 모드: 고가용성/보안성 요구가 높은 환경에서 도입 증가 추세입니다.
※ 실제 비중은 조직·업계·벤더·망 구조에 따라 편차가 큽니다.

⚠️ 인라인 방식의 보안 위험

디도스 공격이 발생하면 WAF가 과부하로 다운될 위험이 높음.
WAF가 다운되면 모든 트래픽이 웹 서버로 그대로 전달될 수 있음(구성에 따라 Fail-open).
공격자가 이를 노리고 SQL 인젝션, XSS 등 추가적인 웹 공격을 시도할 가능성이 커짐.
L3/L4·비웹 포트 공격은 별도 통제가 없으면 노출.

🔄 리버스 프록시 방식의 보안적 우위

클라이언트 요청이 프록시를 반드시 거치므로, WAF가 다운되면 정상 요청과 공격 트래픽 모두 오리진에 도달하지 않도록 Fail-close 설계가 수월합니다.
오리진과 직접 통신하지 않게 설계할 수 있어 Direct-to-Origin 공격면 축소.
📌 주의: 운영 미스(Fail-open, 남은 A레코드, 과도한 SG 등) 시 우회 가능성이 존재 → 프록시 IP만 화이트리스트, mTLS, 고정 Host/SNI 등으로 보완.

📌 결론적으로, 인라인 방식은 편리함 때문에 많이 사용되지만, 보안성을 고려한다면 리버스 프록시 방식이 더 나은 선택이 될 수 있습니다.

3. 비용 고려: 리버스 프록시 방식의 단점

💰 기존 망에서 리버스 프록시 WAF를 설치하는 경우, 비용이 높을 수 있습니다.

온프레미스 환경에서 리버스 프록시 WAF를 새로 구축하려면 네트워크 구조를 변경해야 할 수도 있으며, 추가적인 하드웨어(WAF 장비) 및 설정 비용이 발생할 수 있습니다.
반면, 클라우드 기반 WAF(예: AWS WAF, Cloudflare, Akamai)는 구축 비용이 상대적으로 낮습니다.

💡 PLURA-XDR: 클라우드 기반 WAF를 제공하여, 기업의 서버와 클라우드 리소스를 안전하게 보호해 줍니다.

4. 결론

✅ 온프레미스 환경에서 인라인 WAF는 여전히 널리 사용되며, 리버스 프록시 모드는 고가용성과 보안 요구가 큰 환경에서 점차 선호되고 있습니다.
✅ 디도스 대응·장애 내성·직접공격면 축소 관점에서 리버스 프록시가 설계상 유리합니다.
✅ 인라인의 장점(간편한 배포)을 살리려면 Direct-to-Origin 차단·L3/L4 보호·HA/바이패스 점검 등 보완 통제가 필수입니다.
✅ 최적의 선택은 조직의 네트워크 구조·가용성 목표·보안 정책을 종합적으로 검토해 결정해야 합니다.

부록: 빠른 체크리스트

인라인 도입 시

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

리버스 프록시 도입 시

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