개념 사전 · 개념

WAF

Web Application Firewall · 웹 애플리케이션 방화벽

는 HTTP 요청·응답의 경로·헤더·본문 등을 해석하여 웹 보안 정책을 적용하는 방어 계층이다. 웹 서버 앞 또는 내부에 배치되며 종료 지점과 본문 파싱 조건이 검사 범위를 결정한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

  • HTTP 특화 입력과 응답을 검사한다.
  • 공통 취약점 패턴·프로토콜 이상·요청 크기 정책을 적용한다.
  • 위험 요청과 정상 요청의 차이를 로그로 남겨 조정한다.

02어떤 순서로 동작하나

  1. HTTP 자료 확보

    ·웹 서버 모듈 등 배치 위치에서 요청을 받는다. HTTPS 내용을 검사하려면 종료 등으로 HTTP를 읽을 수 있는 경계가 있어야 한다.

  2. 구조와 입력 해석

    메서드·URL·헤더·본문을 파싱하고 필요한 정규화를 적용한다. 프록시·백엔드가 같은 바이트를 다르게 해석하면 검사와 실제 처리 사이에 차이가 생긴다.

  3. 정책 평가

    규칙과 이상 점수·허용 조건을 조합해 요청을 분류한다. 본문 검사 여부·크기 한도·파일 형식에 따라 실제로 읽은 범위가 달라진다.

  4. 허용·차단·기록

    집행 모드에 따라 백엔드로 전달하거나 차단하고 판단 근거를 기록한다. 탐지 전용 모드는 기록만 남길 수 있으며 응답 단계 차단은 이미 일어난 서버 변경을 되돌리지 않는다.

  5. 오탐과 누락 검토

    정상 업무 표본과 탐지 표본을 함께 비교한다. 사용자별 객체 권한 같은 업무 정책은 규칙만으로 완전히 대신할 수 없다.

03먼저 알아둘 용어와 구성요소

암호화된 연결을 끝내고 HTTP 내용을 볼 수 있게 되는 지점.
JSON·폼·multipart 등 본문 형식을 해석하는 구성 요소.
경보를 관찰하면서 실제 차단을 별도 제어하는 실행 모드.
코드 수정 전 입력 경계에서 취약 경로를 제한하는 완화책.
헤더·본문·URL을 구조화된 요청·응답으로 해석하는 구성 요소.
클라이언트 요청을 받아 뒤의 서버로 전달하는 중계 배치.
정상 요청이 공격으로 잘못 분류되는 결과.
LEARN THROUGH PRACTICE

인라인 차단 설정과 Apache 요청 로그를 다른 증거로 읽기

네트워크 차단 경로와 HTTP 내용 검사가 어떤 관찰 자료를 남기는지 구분한다.

실습 구성과 전제

  • 격리 ·웹 서버의 설정과 기존 로그를 읽는다.
  • 설정 화면과 스캔 로그는 서로 다른 환경의 비교 자료다. 한 제품이 같은 요청을 차단한 앞뒤 증거로 연결하지 않는다.
  1. 설정된 차단 방식의 위치를 확인한다

    • 화면은 패키지의 Block Offenders와 Mode를 보여 준다. Inline 모드는 실제 패킷 경로와 NIC 지원 조건을 요구한다.
    • 선택 상자가 켜져 있다는 사실과 드롭이 발생했다는 사실은 다르다. 경보·차단 테이블·클라이언트 결과를 연결해야 한다.
    7/21 - pfsense · 실습·개념 참고 화면 1원본 크기로 보기 ↗
    • Block Offenders가 체크돼 있고 IPS Mode는 Inline Mode로 선택돼 있다.
    • 설명에는 Legacy가 복제 패킷을 보고 Inline은 패킷을 직접 검사한다고 적혀 있으며 지원 NIC 조건도 함께 나온다.
    확인 기준

    현재 실행 모드·인터페이스·드롭 규칙을 확인한 뒤 차단 효과를 판정한다.

  2. 접근 로그가 보는 HTTP 결과를 읽는다

    • access log의 요청 경로·상태 코드·시각·User-Agent를 분리한다. 스캔 표식 문자열이 있다고 실제 코드 실행이 일어났다고 단정하지 않는다.
    • 404는 해당 경로의 HTTP 응답 상태다. 로그 처리 과정의 취약한 해석이나 다른 부작용까지 안전하다는 뜻은 아니다.
    ModSecurity 요청·로그 해석 · Nessus로 발생하는 로그에 대한 분석원본 크기로 보기 ↗
    • 여러 CGI·PHP 경로에 대한 GET과 대부분의 404, 별도 HEAD 요청의 200이 보인다.
    • User-Agent 부분에는 스캐너 표식이 반복된다. 화면 하단의 '대부분 실패' 평가는 실제 취약점 부작용까지 증명하지 못한다.
    확인 기준

    감사 로그의 규칙 ID·매치 변수·액션을 추가로 확인한다.

  3. 요청 ID로 탐지와 차단을 대조한다

    • 의 탐지는 변수·연산자·변환·액션 조건으로 결정된다. access log의 상태만 보지 않고 동일 요청의 감사 로그와 응답을 연결한다.
    • 관찰 모드에서는 규칙이 맞아도 요청이 통과할 수 있다. 정상 표본도 함께 시험해 오탐을 좁히고 규칙 전체 비활성화를 첫 해결책으로 삼지 않는다.
    shell
    apachectl -t
    journalctl -u apache2 --since today --no-pager

    설정 문법과 서비스 오류를 조회하는 예시. 배포판에 따라 httpd 서비스와 도구를 사용한다.

    확인 기준

    탐지 로그 존재·disruptive action·사용자 응답을 각각 기록한다.

실습에서 확인한 동작 원리

  • 차단 설정 화면은 차단 성공 증거를 대신하지 않는다.
  • 404 응답과 미탐·취약점 비영향 여부는 다른 판정이다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • JSON 필드의 위험 문자열을 검사하려면 해당 본문 파서가 활성화되고 크기·깊이 제한 안에서 내용이 해석되어야 한다.
  • 정상 게시물에 관련 단어가 포함되어 차단될 수 있으므로 규칙 ID와 필드 단위로 조정한다.
  • 를 끝내지 않는 수동 관측 위치에서는 암호화된 HTTP 본문을 일반 평문 규칙으로 검사할 수 없다.

05혼동하기 쉬운 점과 확인 기준

  • 가 존재해도 사용자 A가 B의 문서를 조회하는 업무 오류를 자동으로 모두 이해하지 못한다.
  • 전체 을 끄거나 모든 입력을 예외 처리하면 오탐은 줄어 보여도 보호 범위가 함께 사라질 수 있다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.