개념 사전 · 프로그램
ModSecurity
모드시큐리티
는 HTTP 처리 단계에서 변수·연산자·변환·action으로 규칙을 평가하는 웹 방화벽 엔진이다. 엔진과 실제 탐지 정책인 는 구분되며 웹 서버 연결 방식과 버전에 따라 지원 동작을 확인한다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 요청·응답 헤더와 본문을 단계별로 검사한다.
- 규칙 조건과 점수·차단·감사 기록을 연결한다.
- 정상 업무 입력의 오탐을 규칙·변수 단위로 좁힌다.
02어떤 순서로 동작하나
- 1: 요청 헤더
요청 헤더를 검사한다. 아직 본문 파싱 전이므로 본문 필드가 필요한 규칙을 대신하지 못한다.
- 2: 요청 본문
설정된 body processor와 접근·크기 조건에 따라 본문·파라미터를 검사한다.
- 3: 응답 헤더
서버가 만든 응답 헤더를 검사한다. 이 시점에 응답 본문 전체가 준비되었다고 가정하지 않는다.
- 4: 응답 본문
활성화한 응답 본문 검사를 수행한다. 백엔드의 상태 변경이 이미 진행되었을 가능성은 따로 남는다.
- 5: 기록
거래와 규칙 결과를 로그에 남긴다. 기록 자체가 앞선 요청을 차단했다는 뜻은 아니다.
03먼저 알아둘 용어와 구성요소
- 변수·연산자·action 목록으로 구성하는 기본 검사 규칙.
- 요청 헤더·요청 본문·응답 헤더·응답 본문·로깅 등 실행 단계.
- 비교 전에 입력 표현을 변환하는 처리.
- 연속 규칙의 조건을 묶어 판정하는 방식.
- 파싱된 요청 인수의 값들을 나타내는 변수 집합.
- 요청 헤더에 접근하는 변수 집합.
- 규칙 평가와 기록을 수행하면서 차단 동작을 집행하지 않는 모드.
- 의 선택한 부분과 탐지 정보를 남기는 상세 기록.
LEARN THROUGH PRACTICE
인라인 차단 설정과 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예제로 따라가기
- 1에서는 요청 헤더를 다룰 수 있지만 아직 처리되지 않은 요청 본문을 완전히 검사한 것처럼 볼 수 없다.
- 규칙에서 특정 변수와 연산자가 일치해도 action·실행 모드가 기록 전용이면 실제 요청이 차단되지 않을 수 있다.
- 빈도 제어는 컬렉션 초기화뿐 아니라 카운터 증가·만료·실제 실패 확인이 있어야 완성된다.
05혼동하기 쉬운 점과 확인 기준
- HTTP 404를 받았다는 사실은 안전 판정이 아니다. 요청이 어디까지 처리되었는지와 규칙·응용 로그를 대조한다.
- v2와 libmodsecurity v3·커넥터의 지원 범위를 확인하지 않고 동일 설정의 동일 효과를 가정하지 않는다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.