웹 애플리케이션 방화벽(WAF)의 탐지 엔진 구조와 필터링 원리

WAF 탐지 엔진의 핵심 계층 구조

웹 애플리케이션 방화벽의 탐지 엔진은 단일 필터가 아닌, 다중 계층으로 구성된 심층 방어 체계입니다. 구형 시스템일수록 단일 패턴 매칭에 의존하는 경우가 많아 우회가 쉬운 반면, 현대 WAF는 각 계층이 상호 보완하며 위협을 차단합니다, 이 구조를 이해하지 못하면 정책 설정 오류로 인해 정상 트래픽이 차단되거나, 심각한 공격이 탐지되지 않는 보안 허점이 발생할 수 있습니다.

패턴 매칭 (시그니처 기반) 계층

가장 기본적이면서도 필수적인 계층으로, 알려진 공격 패턴의 데이터베이스(시그니처)와 입력 값을 비교합니다. 이와 같은 sQL 인젝션, 크로스사이트 스크립팅(XSS) 등 공격의 정형화된 패턴을 빠르게 탐지하는 데 특화되어 있습니다. 그렇지만 이 계층만으로는 시그니처가 등록되지 않은 제로데이 공격이나 변종 공격을 탐지할 수 없다는 한계가 명확합니다.

어노말리 (이상 탐지) 계층

정상적인 트래픽의 기준(베이스라인)을 학습한 후, 이를 벗어나는 이상 행위를 탐지합니다. 예를 들어, 일반 사용자가 로그인 시도는 분당 1~2회가 정상이라면, 분당 100회의 시도는 ‘비정상’으로 판단합니다. 이 계층은 알려지지 않은 새로운 공격 기법에 대응할 수 있는 가능성을 제공그러나, 학습 기간 설정과 기준치 설정이 매우 중요합니다, 설정이 잘못되면 너무 많은 오탐(false positive) 또는 미탐(false negative)을 유발합니다.

파싱 및 정규화 계층

공격자가 WAF를 우회하기 위해 사용하는 인코딩 변조, 중복 파라미터, NULL 바이트 삽입 등의 기법을 해제하고 원본 데이터를 복원하는 과정입니다. %3Cscript%3E를 <script>로 디코딩하거나, sel/**/ect에서 주석을 제거하여 select로 만드는 작업이 이 계층에서 이루어집니다. 이 처리가 제대로 이루어지지 않으면, 이후의 모든 탐지 계층이 왜곡된 데이터를 검사하게 되어 방어 체계가 무력화됩니다.

실시간 요청 필터링의 4단계 작동 원리

WAF가 HTTP/HTTPS 요청 하나를 처리하는 과정은 네트워크 패킷 수준부터 애플리케이션 로직 수준까지 연속적인 필터링 단계를 거칩니다. 각 단계는 이전 단계의 결과에 의존하므로, 파이프라인 상의 어떤 결함도 전체 보안 성능을 저하시킵니다.

1단계: 프로토콜 검증 및 전처리

요청이 표준 HTTP 프로토콜 규격(RFC)을 준수하는지 검사합니다. 여기서 차단되는 위반 사항은 대부분 저수준 공격이나 비정상적인 클라이언트를 나타냅니다.

1. 요청 메서드 검증: GET, POST, PUT 등 허용된 메서드 목록과 비교, debug, trace 같은 위험한 메서드는 기본적으로 차단 대상.
2. 헤더 구조 검사: 중복 헤더, 과도하게 긴 헤더 값, 필수 헤더 누락 여부 확인.
3. 콘텐츠 길이 검증: content-length 헤더 값과 실제 전송된 바디 데이터의 일치 여부를 체크하여 버퍼 오버플로우 공격 시도를 탐지.

2단계: 입력 값 정규화 및 토큰화

전처리된 요청에서 파라미터, 쿠키, 헤더 값 등을 추출하고, 공격 탐지를 위해 표준 형태로 정규화합니다. 이 단계의 정확도가 전체 탐지율을 결정합니다.

1. 문자셋 정규화: UTF-8, EUC-KR 등 다양한 인코딩을 시스템 표준 인코딩으로 통일.
2. 공격 시그니처 은닉 기법 해제: URL 인코딩(%XX), Unicode 인코딩, HTML 엔티티(<), 16진수/8진수 표현 등을 원본 문자로 복원.
3. 구문 토큰화: SQL 문장이나 스크립트 코드로 의심되는 문자열을 키워드(SELECT, UNION), 연산자(=, --), 문자열 리터럴 등으로 분해하여 분석 준비.

3단계: 다중 탐지 엔진 병렬 검사

정규화된 데이터를 앞서 설명한 패턴 매칭, 어노말리 탐지 등 모든 활성화된 탐지 엔진에 동시 또는 순차적으로 투입합니다, 현대 waf는 여기에 휴리스틱 분석(의심 지표 점수화)이나 머신러닝 모델을 추가로 적용하기도 합니다.

• 긍정 탐지(true positive) 향상: 하나의 요청이 여러 엔진에서 위협으로 판단될수록 공격 확신도가 높아짐. (예: 특정 패턴 매칭 + 이상 트래픽 점수 초과)
• 부정 탐지(False Negative) 감소: 한 엔진이 놓친 위협을 다른 엔진이 보완할 가능성 증가.

각 엔진의 판단 결과와 심각도(낮음, 중간, 높음, 치명적)는 중앙 의사결정 엔진으로 전달됩니다.

4단계: 의사결정 및 액션 실행

중앙 엔진은 사전 정의된 보안 정책과 위협의 심각도, 신뢰도를 종합하여 최종 액션을 결정합니다. 이 과정은 단순 차단/통과가 아닌 세분화된 대응이 가능합니다.

1. 액션 평가: 정책은 일반적으로 “감지만 로깅”. “차단 및 로깅”, “captcha 챌린지 발행”, “요청 지연”, “ip 주소 일시 차단” 등 계층화된 액션을 정의.
2. 컨텍스트 고려: 동일한 <script> 태그라도 게시판 글쓰기 요청에서는 xss 공격으로 차단되지만, 관리자 콘텐츠 관리 시스템(cms) 페이지에서는 정상적인 입력으로 허용될 수 있음. 이를 위해 특정 URL(URI)이나 사용자 역할(롤)을 조건으로 하는 정책 설정이 필수.
3. 액션 실행: 결정된 액션을 실시간으로 적용. 차단 시 클라이언트에는 403 Forbidden 또는 사용자 정의 차단 페이지를 응답.

탐지 정확도 극대화를 위한 시스템 최적화 설정값

WAF를 단순히 설치하는 것만으로는 충분하지 않습니다. 배포 환경과 보호 대상 애플리케이션에 맞춰 엔진을 세밀하게 튜닝해야 오탐을 최소화하면서도 보안 효율을 극대화할 수 있습니다. 지금 당장 작동하는 해결책이 가장 훌륭한 기술적 자산입니다.

학습 모드 운영 및 베이스라인 구축

어노말리 탐지 계층의 핵심은 정확한 기준치 설정입니다. 초기 배포 시 최소 2주에서 4주 동안은 반드시 ‘학습 모드’ 또는 ‘모니터링 모드’로 운영해야 합니다.

1. 정상 트래픽 수집: 이 기간 동안 WAF는 모든 트래픽을 차단 없이 통과시키며, 파라미터 길이, 값 분포, 접근 빈도, 소스 IP 등의 정상 패턴을 학습.
2. 베이스라인 리포트 분석: 학습 기간 종료 후 시스템이 생성한 기준치 리포트를 검토. 비즈니스에 맞지 않는 이상치(예: 특정 국가에서의 갑작스러운 접근)가 기준에 포함되었다면 수동 조정.
3. 정책 적용 전 테스트: 학습된 기준으로 생성된 초기 정책을 ‘차단 모드’로 전환하기 전, 중요 기능에 대한 정상 이용이 가능한지 철저히 테스트.

시그니처 관리 및 커스터마이징

벤더에서 제공하는 기본 시그니처 세트는 폭넓은 공격을 커버하지만, 특정 애플리케이션에서는 오탐을 유발할 수 있습니다, 능동적인 시그니처 관리가 필요합니다.

• 오탐 발생 시그니처 비활성화: 특정 규칙이 정상 기능(예: 검색엔진의 복잡한 쿼리)을 지속적으로 차단한다면, 해당 규칙 id를 확인하여 해당 url 경로에 대해서만 비활성화. 전체 비활성화는 보안 허점을 만듦.
• 커스텀 시그니처 작성: 자체 개발 애플리케이션의 고유한 취약점이나, 특정 경로에 대한 비정상 접근 패턴(예: /admin/backup.zip 다운로드 시도)을 탐지하기 위한 정규 표현식 기반의 커스텀 규칙을 작성 추가.
• 시그니처 업데이트 주기 설정: 자동 업데이트를 주기적으로 수행하되, 주요 업데이트 후에는 스테이징 환경에서 호환성 테스트를 반드시 진행.

성능과 보안의 균형점 설정

과도한 검사는 응답 지연을 유발하고, 너무 느슨한 검사는 보안을 약화시킵니다. 다음 설정값을 조정하여 균형을 찾아야 합니다.

1. 요청/응답 본문 검사 깊이 제한: 대용량 파일 업로드 시 전체 파일을 검사하지 않도록, 예를 들어 처음 8KB만 검사하도록 설정. 이는 대부분의 공격 시그니처가 페이로드 앞부분에 위치한다는 경험적 근거에 기반함.
2. 파일 업로드 필터링: 확장자 필터링과 함께, 파일 시그니처(매직 넘버) 검사를 활성화하여 위장 확장자 공격을 방지.
3. 세션 기반 보호: 로그인 후 발급된 세션 토큰과 사용자 ID를 연계하여, 인증된 사용자의 비정상 행위(권한 상승 시도, 데이터 무단 접근)를 더 정확하게 탐지할 수 있도록 연동 설정.

동일 문제 재발 방지를 위한 전문가 팁: 로그 분석 자동화
WAF의 가장 큰 가치는 방어 자체보다 상세한 공격 로그에 있습니다. 매일 403 차단 로그, 어노말리 탐지 로그를 수집하여 자동 분석 스크립트를 구축하십시오. 단순 반복 시도는 자동으로 IP 차단 목록에 추가하고, 새로운 패턴의 공격 시도는 주간 보안 보고서로 추출하여 검토하십시오. 이 과정을 자동화하지 않으면 WAF는 단순한 ‘차단기’에 불과하며, 진화하는 공격 패턴에 대응할 수 있는 능동적인 보안 자산으로 기능하지 못합니다. 특히, 패치 지원 종료(EoS)된 레거시 애플리케이션을 보호하는 경우, WAF 로그는 알려지지 않은 취약점에 대한 공격 시도를 조기에 발견할 수 있는 유일한 조기 경보 시스템이 됩니다.