3. WAF(Web Application Firewall) 이해하기

네트워크 보안

WAF(Web Application Firewall) 이해하기 — ‘HTTP를 이해하는 방화벽’의 역할과 한계

WAF는 웹 공격을 HTTP 레벨에서 필터링합니다. 하지만 최종 해답은 ‘취약점 수정’이며, WAF는 그 시간을 벌어주는 장치입니다.

핵심 HTTP 레벨관점 탐지→차단실무 룰/예외연계 SIEM/진단

이 글의 목표
WAF(Web Application Firewall)를 ‘웹 전용 방화벽’으로 이해하시도록, 무엇을 막을 수 있고(장점), 무엇을 못 막는지(한계)를 실무 관점에서 정리합니다.

1) WAF는 왜 방화벽과 별도로 필요할까요?

일반 방화벽이 주로 IP/포트/세션 중심이라면, WAF는 HTTP/HTTPS 요청의 의미를 보고 판단합니다.

• 예: 같은 443(HTTPS)라도, 요청 URI/파라미터/바디 안에 공격 페이로드가 들어갈 수 있습니다.
• 웹 공격은 ‘포트 차단’으로 해결되지 않는 경우가 많습니다.

 

WAF는 보통 ‘역방향 프록시’ 형태로 웹 앞단에서 HTTP 요청을 검사합니다

2) WAF가 주로 다루는 공격 유형(대표)

• SQL Injection: 입력값으로 DB 쿼리를 왜곡
• XSS: 스크립트를 주입해 세션 탈취/피싱 유도
• 파일 업로드 악용: 웹셸 업로드, 확장자 우회, 실행 경로 오남용
• 디렉터리 트래버설: 경로 조작으로 민감 파일 접근
• 봇/스크래핑: 자동화 접근으로 크롤링/브루트포스/재고 털이

3) 운영 모드: ‘차단’보다 먼저 ‘탐지’부터

WAF는 초기 오탐이 흔합니다. 그래서 일반적으로 다음 순서가 안전합니다.

1. 탐지(모니터링) 모드로 공격/오탐 패턴 수집
2. 정상 트래픽 특성(업무 API, 파일 업로드, 특수문자 등) 파악
3. 예외 룰은 최소 범위로(특정 URI/파라미터로 좁히기)
4. 검증된 룰만 단계적으로 차단 전환

4) (예시) WAF 룰 한 줄이 의미하는 것

※ 아래는 개념 이해를 위한 예시입니다. 실환경에서는 룰셋/앱 동작을 함께 검증하셔야 합니다.

# 예시(ModSecurity 스타일): 특정 파라미터에 위험 패턴이 보이면 차단(deny)
SecRule ARGS "@rx (?i)(union\s+select|or\s+1=1|sleep\()"
  "id:10001,phase:2,deny,status:403,log,msg:'SQLi pattern (example)'"

5) WAF 로그에서 ‘이것만은’ 먼저 보시면 좋습니다

• 차단 사유(룰 ID/룰셋 이름)와 대상 URI
• 공격 원본(소스 IP/국가/ASN)과 반복 패턴(봇/스캔)
• 차단이 많아진 시간대(캠페인 공격, 신규 취약점 공개 직후 등)
• 차단으로 인한 정상 서비스 영향(오탐) — 예외 적용 전 반드시 재현

중요한 한계
WAF는 ‘가드레일’입니다. 애플리케이션의 취약점 수정(패치/코드 개선)을 대체하지 않습니다. 즉, WAF로 시간을 벌되, 원인은 반드시 제거하시는 접근이 가장 안전합니다.

마무리 체크리스트

• WAF가 웹 앞단에 배치되었나요(Reverse Proxy/CDN/WAF)?
• 탐지 모드 → 차단 모드로 단계적으로 전환하고 있나요?
• 예외 규칙에 근거/만료일이 남아 있나요?
• WAF 로그가 SIEM/티켓으로 연결되어 ‘대응’으로 이어지나요?
• 웹 취약점 점검(진단/패치) 프로세스와 함께 굴러가고 있나요?

참고 레퍼런스

• OWASP — Web Application Firewall (WAF)
• OWASP — ModSecurity Core Rule Set (CRS)
• OWASP Top 10 (최신 버전 확인 페이지)
• ModSecurity (프로젝트/문서)
• NIST SP 800-44 — Guidelines on Securing Public Web Servers (PDF)