웹방화벽 우회 공격에 대한 대응 전략

By PLURA

🌐 웹방화벽(WAF)은 여전히 웹 시스템 보호의 핵심입니다.
하지만 그 말은 곧, 공격자도 WAF를 가장 먼저 연구한다는 뜻이기도 합니다.

지금의 웹 공격은 단순히 SQL Injection 문자열 하나를 던지고 끝나지 않습니다.
WAF의 시그니처와 예외 정책을 먼저 파악한 뒤,
이를 우회하는 방식으로 요청을 바꾸고, 분산하고, 숨깁니다.

즉, WAF를 설치했다고 끝나는 것이 아니라
WAF가 놓친 요청까지 다시 볼 수 있어야 실제 방어가 가능합니다.

WAF 우회 공격 대응

1. WAF는 왜 우회당하는가

WAF는 웹 애플리케이션 계층에서 발생하는 공격을 탐지하고 차단하는 데 매우 유용합니다.
특히 SQL Injection, XSS, 파일 업로드 악용, 관리자 페이지 공격 같은 웹 문맥 기반 공격을 보는 데 강합니다.

하지만 한계도 분명합니다.

WAF가 우회당하는 대표 이유

  • 시그니처 부재
    새로운 공격 패턴이나 우회 변형이 아직 룰에 반영되지 않음
  • 예외 정책 누적
    오탐을 줄이기 위해 추가한 예외가 공격자의 통로가 됨
  • 정상처럼 보이는 요청
    완전히 비정상적인 문자열이 아니라, 정상 요청처럼 보이도록 위장
  • API / Bot / Low & Slow 공격 증가
    전통적인 웹 페이지 기준 룰만으로는 해석하기 어려움

즉, 문제는 WAF가 무의미하다는 것이 아니라,
WAF가 보는 기준을 공격자가 먼저 공부하고 있다는 점입니다.

2. 실제로 어떤 식으로 우회하는가

이 부분이 중요합니다.
“우회 공격”이라는 표현만으로는 실무 감각이 잘 오지 않습니다.

실제 우회는 대체로 다음 방식으로 나타납니다.

1) 인코딩 / 대소문자 / 공백 우회

  • 특수문자 인코딩
  • 대소문자 혼합
  • 공백, 주석, 분리 문자 변형

같은 공격 의도를 유지하면서도
시그니처가 기대하는 문자열 패턴만 피해 갑니다.

2) HTTP Parameter Pollution

같은 파라미터를 여러 번 보내거나,
배열/중첩 구조로 변형해
애플리케이션과 WAF가 서로 다르게 해석하게 만듭니다.

3) JSON / XML / API 본문 우회

과거 WAF는 주로 URL 파라미터 중심으로 설계된 경우가 많았습니다.
하지만 지금은 공격이 JSON body, GraphQL 요청, REST API payload 안쪽에 숨어 들어갑니다.

즉, 본문(body) 을 보지 못하면
애초에 공격 의도를 읽기 어려운 경우가 많습니다.

4) Chunked / 분할 요청 / Low & Slow

한 번에 강한 공격을 넣지 않고,
작게 나누어 천천히 보내
탐지 임계값과 운영자의 눈을 동시에 피합니다.

5) 정상 기능 악용

  • 로그인 반복 시도
  • 비정상 API 호출 패턴
  • 관리자 기능 탐색
  • 파일 업로드 기능 남용

이런 공격은 “이상한 문자열”보다
행위 패턴으로 드러납니다.

3. 2026년 기준으로는 무엇이 더 중요해졌나

웹 보안은 이제 단순한 페이지 보호를 넘어섰습니다.

1) 웹 보안은 API 보안을 포함합니다

OWASP는 API Security Top 10 2023을 별도로 운영할 만큼,
API 보안 문제를 독립된 영역으로 다루고 있습니다.
특히 Broken Object Level Authorization, Broken Authentication은
현실적인 API 공격의 핵심입니다.

2) Broken Access Control과 Misconfiguration은 여전히 핵심입니다

OWASP Top 10 2025에서도
Broken Access Control이 1위, Security Misconfiguration이 2위입니다.
즉, 지금도 가장 큰 문제는 고급 해킹 기술 이전에
권한 통제 실패와 잘못된 설정입니다.

3) Bot과 자동화 공격이 더 중요해졌습니다

클라우드 WAF는 이제 custom rules, rate limiting, bot score 같은 기능을 기본 축으로 제공합니다.
이는 단순 시그니처 기반 차단만으로는 부족하다는 현실을 보여 줍니다.

즉, 지금의 WAF 우회 대응은
문자열 탐지만이 아니라
본문 + API + Bot + 행위 패턴까지 봐야 현실과 맞습니다.

4. 우회 공격에 효과적으로 대응하려면?

핵심은 단순합니다.

차단된 공격만 보지 말고,
차단되지 않았지만 이상한 요청을 봐야 합니다.

4-1. 왜 일반 액세스 로그만으로는 부족한가

일반적인 access.log는 보통 다음 정도만 남깁니다.

  • URI
  • 메서드
  • 상태 코드
  • 응답 크기
  • User-Agent
  • IP

하지만 이것만으로는 부족합니다.

왜냐하면 우회 공격은 종종 다음 안에 숨어 있기 때문입니다.

  • 요청 본문(Request Body)
  • JSON 필드
  • API payload
  • 쿠키/세션 패턴
  • 응답 결과와의 관계

즉, 본문이 없으면 공격 의도가 사라집니다.

4-2. 로그에서 봐야 하는 실제 포인트

우회 공격 대응에서 중요한 것은 아래와 같습니다.

  • 정상 응답(200)인데 요청이 이상한 경우
  • 같은 출발지의 반복 호출 패턴
  • 특정 API에만 집중되는 변형 요청
  • 관리자 기능 또는 민감 URI에 대한 시간대별 접근
  • 실패가 아니라 성공 응답 뒤 이어지는 이상 행위

즉, 차단 실패를 봐야 다음 룰을 만들 수 있습니다.

5. PLURA가 여기서 가지는 의미

이 지점에서 중요한 것은 “WAF를 대체한다”가 아닙니다.
오히려 정반대입니다.

WAF는 필요합니다.
다만 WAF만으로 끝나면 부족하다는 것입니다.

PLURA의 강점은
WAF가 놓쳤거나, WAF만으로 설명되지 않는 구간을
본문 로그와 이후 행위 분석으로 이어서 본다는 점에 있습니다.

예를 들어 이런 흐름을 볼 수 있습니다

  • 요청 본문에서 비정상 파라미터 조합 확인
  • 같은 세션에서 반복 우회 시도 발생
  • 응답은 200인데 이후 서버에서 비정상 프로세스 실행
  • 직후 외부 연결 또는 계정 행위 변화 발생

이 경우 단순 웹 이벤트가 아니라
WAF 우회 시도 → 서버 내부 행위 → 침해 진행 가능성으로 봐야 합니다.

즉, PLURA의 의미는
“본문 로그를 더 본다”가 아니라
본문 로그를 시작점으로 실제 침해 흐름까지 연결해 본다는 데 있습니다.

6. 현실적인 대응 전략: WAF + 로그 + XDR

WAF 우회 대응에서 가장 현실적인 구조는 다음과 같습니다.

1) WAF로 1차 차단

  • 기본 룰셋
  • 커스텀 룰
  • 관리자 URI 보호
  • API 정책
  • rate limiting
  • bot 대응

2) 본문 로그와 요청 흐름 분석

  • 차단되지 않은 의심 요청 검토
  • JSON body / API payload 분석
  • 정상 응답 뒤 이어지는 이상 패턴 확인

3) XDR로 내부 행위까지 연결

  • 비정상 프로세스 실행
  • 계정 권한 사용 변화
  • 외부 연결
  • 파일 생성 또는 변경
  • 추가 확산 징후

즉, 구조는 이렇게 정리할 수 있습니다.

단계 역할 핵심 질문
WAF 웹 공격 1차 차단 들어오는 요청이 이상한가?
본문 로그 분석 우회 시도 추적 차단되지 않았지만 이상한가?
PLURA-XDR 내부 행위 분석 실제 침해로 이어졌는가?

핵심은 “더 많은 장비”가 아니라
공격의 앞단과 뒷단을 연결해 보는 것입니다.

7. 지금 당장 점검할 체크리스트

✅ WAF 운영 체크

  1. 커스텀 룰이 실제로 운영되고 있는가?
  2. 관리자 페이지와 민감 API가 별도 보호되고 있는가?
  3. Bot / Credential Stuffing / rate limiting 대응이 있는가?
  4. 오탐 예외가 과도하게 누적돼 있지 않은가?

✅ 로그 분석 체크

  1. 요청 본문을 저장하거나 분석할 수 있는가?
  2. 200 응답이지만 이상한 요청을 따로 보고 있는가?
  3. 차단 실패 요청을 다음 룰의 입력으로 쓰고 있는가?

✅ 사고 대응 체크

  1. 웹 공격 이후 서버 내부 행위까지 추적 가능한가?
  2. 비정상 프로세스, 계정, 외부 연결과 연결해서 보는가?
  3. 주말/야간 공격 시 자동 알림과 대응 체계가 있는가?

8. 결론

WAF는 여전히 중요합니다.
하지만 공격자도 WAF를 잘 압니다.
그래서 이제 질문은 “WAF가 있는가?”가 아니라
“WAF를 우회한 요청까지 보고 있는가?” 가 되어야 합니다.

웹 보안의 현실적인 대응은 다음과 같습니다.

  • WAF로 1차 차단
  • 본문 로그로 우회 시도 파악
  • XDR로 이후 행위까지 연결 분석

결국 중요한 것은
차단 장비를 하나 더 두는 것이 아니라,
차단 실패와 침해 진행을 얼마나 빨리 알아차리는가입니다.

WAF가 막지 못한 요청을 다시 보지 않으면,
우회 공격은 결국 성공한 공격이 됩니다.

Tags