WAF
Web Application Firewall · 웹 애플리케이션 방화벽
는 HTTP 요청·응답의 경로·헤더·본문 등을 해석하여 웹 보안 정책을 적용하는 방어 계층이다. 웹 서버 앞 또는 내부에 배치되며 종료 지점과 본문 파싱 조건이 검사 범위를 결정한다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- HTTP 특화 입력과 응답을 검사한다.
- 공통 취약점 패턴·프로토콜 이상·요청 크기 정책을 적용한다.
- 위험 요청과 정상 요청의 차이를 로그로 남겨 조정한다.
02어떤 순서로 동작하나
- HTTP 자료 확보
·웹 서버 모듈 등 배치 위치에서 요청을 받는다. HTTPS 내용을 검사하려면 종료 등으로 HTTP를 읽을 수 있는 경계가 있어야 한다.
- 구조와 입력 해석
메서드·URL·헤더·본문을 파싱하고 필요한 정규화를 적용한다. 프록시·백엔드가 같은 바이트를 다르게 해석하면 검사와 실제 처리 사이에 차이가 생긴다.
- 정책 평가
규칙과 이상 점수·허용 조건을 조합해 요청을 분류한다. 본문 검사 여부·크기 한도·파일 형식에 따라 실제로 읽은 범위가 달라진다.
- 허용·차단·기록
집행 모드에 따라 백엔드로 전달하거나 차단하고 판단 근거를 기록한다. 탐지 전용 모드는 기록만 남길 수 있으며 응답 단계 차단은 이미 일어난 서버 변경을 되돌리지 않는다.
- 오탐과 누락 검토
정상 업무 표본과 탐지 표본을 함께 비교한다. 사용자별 객체 권한 같은 업무 정책은 규칙만으로 완전히 대신할 수 없다.
03먼저 알아둘 용어와 구성요소
- 암호화된 연결을 끝내고 HTTP 내용을 볼 수 있게 되는 지점.
- JSON·폼·multipart 등 본문 형식을 해석하는 구성 요소.
- 경보를 관찰하면서 실제 차단을 별도 제어하는 실행 모드.
- 코드 수정 전 입력 경계에서 취약 경로를 제한하는 완화책.
- 헤더·본문·URL을 구조화된 요청·응답으로 해석하는 구성 요소.
- 클라이언트 요청을 받아 뒤의 서버로 전달하는 중계 배치.
- 정상 요청이 공격으로 잘못 분류되는 결과.
인라인 차단 설정과 Apache 요청 로그를 다른 증거로 읽기
네트워크 차단 경로와 HTTP 내용 검사가 어떤 관찰 자료를 남기는지 구분한다.
실습 구성과 전제
- 격리 ·웹 서버의 설정과 기존 로그를 읽는다.
- 설정 화면과 스캔 로그는 서로 다른 환경의 비교 자료다. 한 제품이 같은 요청을 차단한 앞뒤 증거로 연결하지 않는다.
설정된 차단 방식의 위치를 확인한다
- 화면은 패키지의 Block Offenders와 Mode를 보여 준다. Inline 모드는 실제 패킷 경로와 NIC 지원 조건을 요구한다.
- 선택 상자가 켜져 있다는 사실과 드롭이 발생했다는 사실은 다르다. 경보·차단 테이블·클라이언트 결과를 연결해야 한다.
원본 크기로 보기 ↗- Block Offenders가 체크돼 있고 IPS Mode는 Inline Mode로 선택돼 있다.
- 설명에는 Legacy가 복제 패킷을 보고 Inline은 패킷을 직접 검사한다고 적혀 있으며 지원 NIC 조건도 함께 나온다.
확인 기준현재 실행 모드·인터페이스·드롭 규칙을 확인한 뒤 차단 효과를 판정한다.
접근 로그가 보는 HTTP 결과를 읽는다
- access log의 요청 경로·상태 코드·시각·User-Agent를 분리한다. 스캔 표식 문자열이 있다고 실제 코드 실행이 일어났다고 단정하지 않는다.
- 404는 해당 경로의 HTTP 응답 상태다. 로그 처리 과정의 취약한 해석이나 다른 부작용까지 안전하다는 뜻은 아니다.
원본 크기로 보기 ↗- 여러 CGI·PHP 경로에 대한 GET과 대부분의 404, 별도 HEAD 요청의 200이 보인다.
- User-Agent 부분에는 스캐너 표식이 반복된다. 화면 하단의 '대부분 실패' 평가는 실제 취약점 부작용까지 증명하지 못한다.
확인 기준감사 로그의 규칙 ID·매치 변수·액션을 추가로 확인한다.
요청 ID로 탐지와 차단을 대조한다
- 의 탐지는 변수·연산자·변환·액션 조건으로 결정된다. access log의 상태만 보지 않고 동일 요청의 감사 로그와 응답을 연결한다.
- 관찰 모드에서는 규칙이 맞아도 요청이 통과할 수 있다. 정상 표본도 함께 시험해 오탐을 좁히고 규칙 전체 비활성화를 첫 해결책으로 삼지 않는다.
shellapachectl -t journalctl -u apache2 --since today --no-pager설정 문법과 서비스 오류를 조회하는 예시. 배포판에 따라 httpd 서비스와 도구를 사용한다.
확인 기준탐지 로그 존재·disruptive action·사용자 응답을 각각 기록한다.
실습에서 확인한 동작 원리
- 차단 설정 화면은 차단 성공 증거를 대신하지 않는다.
- 404 응답과 미탐·취약점 비영향 여부는 다른 판정이다.
04예제로 따라가기
- JSON 필드의 위험 문자열을 검사하려면 해당 본문 파서가 활성화되고 크기·깊이 제한 안에서 내용이 해석되어야 한다.
- 정상 게시물에 관련 단어가 포함되어 차단될 수 있으므로 규칙 ID와 필드 단위로 조정한다.
- 를 끝내지 않는 수동 관측 위치에서는 암호화된 HTTP 본문을 일반 평문 규칙으로 검사할 수 없다.
05혼동하기 쉬운 점과 확인 기준
- 가 존재해도 사용자 A가 B의 문서를 조회하는 업무 오류를 자동으로 모두 이해하지 못한다.
- 전체 을 끄거나 모든 입력을 예외 처리하면 오탐은 줄어 보여도 보호 범위가 함께 사라질 수 있다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.