방화벽·pfSense·ModSecurity·CRS의 처리 과정

01개념과 구성 요소

• 네트워크 방화벽주소·포트·프로토콜·연결 상태를 기준으로 네트워크 통과를 결정한다.
• WAFHTTP 요청·응답의 헤더·본문·파라미터를 응용 문맥에서 검사한다.
• 구성 요소배치 위치·TLS 종료·ModSecurity phase·SecRule·CRS 점수·모드가 실제 처리와 차단을 결정한다.

02ModSecurity의 HTTP 처리 단계

1. Phase 1: 요청 헤더요청 헤더를 검사한다. 아직 본문 파싱 전이므로 본문 필드가 필요한 규칙을 대신하지 못한다.
2. Phase 2: 요청 본문설정된 body processor와 접근·크기 조건에 따라 본문·파라미터를 검사한다.
3. Phase 3: 응답 헤더서버가 만든 응답 헤더를 검사한다. 이 시점에 응답 본문 전체가 준비되었다고 가정하지 않는다.
4. Phase 4: 응답 본문활성화한 응답 본문 검사를 수행한다. 백엔드의 상태 변경이 이미 진행되었을 가능성은 따로 남는다.
5. Phase 5: 기록거래와 규칙 결과를 로그에 남긴다. 기록 자체가 앞선 요청을 차단했다는 뜻은 아니다.

03네트워크 방화벽과 WAF가 보는 대상

• 방화벽과 WAF네트워크 방화벽은 출발지·목적지 주소, 프로토콜·포트, 인터페이스·방향과 연결 상태 등을 기준으로 전달을 통제한다. WAF는 HTTP 요청·응답을 해석한 문맥에서 URI·헤더·파라미터·본문 등을 검사한다.
• 호스트 접근통제SELinux처럼 프로세스의 자원 접근을 제한하는 통제와도 대상이 다르다.
• pfSense 기반pfSense는 FreeBSD와 PF 기반 방화벽·라우터 플랫폼이다. Linux 배포판도 아니고 Snort를 실행하기 위한 전용 GUI만도 아니다.
• 선택적 센서Snort·Suricata 패키지를 추가해 IDS/IPS를 구성할 수 있지만 패키지의 분석 경로와 기본 PF 정책은 각각 확인한다.
• 구성과 적용 범위Cisco ASA는 별도의 보안 장비 제품군이다. WAF·SELinux·pfSense는 각각 검사 계층·배치·운영 역할이 달라 같은 기술의 다른 이름으로 볼 수 없다.

04Stateful 처리: 첫 패킷·상태표·반환 트래픽

• 첫 패킷·State상태 기반 방화벽은 허용한 흐름의 주소·포트·프로토콜과 필요한 프로토콜 상태를 추적한다. 첫 패킷이 규칙을 통과해 state가 만들어지면 같은 연결의 반환 패킷을 상태와 대조해 처리할 수 있다.
• UDP 상태UDP도 전송 프로토콜의 연결 협상은 없지만 방화벽에서 흐름과 타임아웃을 추적할 수 있다.
• 기존 State규칙을 수정했는데 이미 연결된 SSH가 계속 동작하는 것은 기존 state가 남아서일 수 있다. 신규 연결과 기존 연결을 따로 시험하고 필요한 상태만 범위를 정해 제거한다.
• 초기화 영향전체 state 초기화는 관계없는 사용자 연결도 끊을 수 있으므로 단순 검증의 기본 동작으로 쓰지 않는다.
• 비대칭 경로비대칭 경로로 요청과 응답이 서로 다른 stateful 장비를 통과하면 상태 정보가 없는 쪽에서 응답을 버릴 수 있다. 규칙 표만 보지 말고 실제 진입 인터페이스·반환 경로·NAT·state를 함께 확인한다.
• 상태 증거방화벽의 정상 상태는 특정 서비스 인증·앱 동작의 정상까지 의미하지 않는다.

1. 새 흐름 평가상태표에 없는 트래픽을 적용되는 인터페이스·방향·정책에 따라 평가한다.
2. 허용과 상태 생성허용된 첫 패킷으로 연결 문맥과 필요한 변환 관계를 상태표에 만든다.
3. 후속 패킷 처리후속·반환 패킷은 기존 상태와 일치하는지 평가한다. UDP도 방화벽 내부에서 시간 제한 상태를 유지할 수 있다.
4. 상태 종료연결 종료나 timeout으로 상태가 사라진다. 정책 변경만으로 기존 상태가 즉시 같은 방식으로 재평가된다고 가정하지 않는다.

05pfSense의 NAT·규칙 평가와 관측 위치

• 규칙 적용 방향인터페이스 탭 규칙은 일반적으로 그 인터페이스로 들어오는 트래픽을 기준으로 읽는다. WAN port forward는 목적지 변환 이후 주소에 대해 필터 규칙을 평가하므로 연결된 허용 규칙의 목적지가 내부 서버 주소가 될 수 있다.
• Port ForwardWAN의 외부 주소만 조건에 넣고 실제 변환 순서를 무시하면 예상과 다른 정책이 된다.
• LAN 송신 경로LAN에서 시작한 일반적인 흐름은 LAN 진입 정책과 WAN 출구 NAT 등 관련 단계를 거친다. NAT·규칙·라우팅·상태 처리의 관계는 패킷 방향과 구성에 따라 달라진다.
• Floating 규칙과 quickFloating·group·interface 규칙, 자동 규칙과 quick 설정이 영향을 주며 quick이 없는 floating 규칙은 마지막 일치가 적용될 수 있다.
• 캡처 위치패킷 캡처는 진입과 출구에서 각각 다른 주소를 볼 수 있다. 내부 10.0.0.10:50000이 외부 문서용 주소 198.51.100.10:62000으로 변환되는 설명용 예에서 두 캡처를 같은 주소로만 검색하면 반쪽만 찾게 된다.
• 변환 관계state에 기록된 변환 관계와 시간을 사용해 동일 흐름을 연결한다.

06센서 배치·HA·관리 경로

• 내부 통신 가시성LAN 스위치 내부에서 직접 오가는 트래픽은 pfSense를 거치지 않으면 해당 인터페이스 센서가 볼 수 없다. HOME_NET 값을 넓혀도 보이지 않던 패킷이 생성되지 않는다.
• 센서 위치passive IDS, inline IPS, 탐지 후 주소 차단의 지연과 적용 경로를 구분한다.
• CARP·동기화고가용성 구성에서 CARP는 가상 IP 전환, pfsync는 state 동기화, XMLRPC는 설정 동기화의 역할을 한다. 같은 VIP를 사용한다는 이유만으로 모든 연결 상태와 장비별 인터페이스 설정이 자동으로 동일해지는 것은 아니다.
• 전환 시험전환 시험에서 신규·기존 연결과 노드별 관리 경로를 확인한다.
• XML 백업config.xml에는 계정·인증서·VPN 등 민감한 설정이 포함될 수 있다. 관리 UI 접근, 백업 보관과 복원 권한을 제한하고 패키지 업데이트와 기반 시스템 업데이트를 구분한다.
• 관리 경로장애 때 fail-open 또는 fail-close인지도 제품 이름 하나로 결정하지 말고 실제 배치·동작 모드·우회 경로로 확인한다.

07WAF의 배치와 TLS 종료 지점

• TLS 종료WAF는 reverse proxy, 웹 서버 모듈, 클라우드 edge 형태로 배치할 수 있다. 암호화된 TLS 본문을 검사하려면 TLS 종료 지점에서 평문 HTTP를 보거나 별도로 복호화한 요청을 전달받아야 한다.
• 암호화된 통과단순히 HTTPS 포트를 통과시키는 것만으로 SQLi·XSS 본문 검사 기능이 생기지 않는다.
• ConnectorNginx는 웹 서버·reverse proxy, ModSecurity는 트랜잭션 검사 엔진, OWASP CRS는 범용 탐지 규칙 집합이다. connector와 엔진 버전·서버 구성에 따라 지원 기능과 설정이 다르다.
• 실제 구성엔진 설치, connector 연결, 규칙 로드, 실제 검사 대상 경로를 각각 확인한다.
• 두 TLS 구간origin 서버에 직접 접근할 수 있으면 WAF를 우회하는 경로가 남는다. origin의 접근 통제와 TLS 재암호화, 신뢰한 프록시의 실제 클라이언트 주소 전달을 설계한다.
• 앱 취약점WAF 통과가 애플리케이션의 인가·prepared statement·출력 인코딩·패치 책임을 대신하지 않는다.

08ModSecurity의 다섯 처리 단계

• Phase 1·2ModSecurity 규칙은 언제 실행되는지에 따라 볼 수 있는 데이터가 다르다. phase 1은 요청 헤더 시점으로 아직 요청 본문 파싱 결과를 기대하지 않는다.
• 본문 파싱phase 2는 요청 본문 처리 단계이고 SecRequestBodyAccess와 body processor, content type·크기 제한에 따라 실제 검사 범위가 달라진다.
• Phase 3·4·5phase 3은 응답 헤더, phase 4는 응답 본문, phase 5는 로깅 단계다. 응답 본문 검사는 접근 설정·MIME 유형·크기 제한·connector 지원에 영향을 받는다.
• 응답 차단 한계응답을 차단할 때에는 backend가 이미 요청을 처리했을 수 있으므로 DB 변경까지 되돌린다고 생각하지 않는다.
• Body ProcessorJSON·multipart·일반 form 데이터가 모두 같은 방식으로 ARGS에 나타난다고 가정하지 않는다. 파서가 선택되지 않았거나 본문이 잘렸으면 규칙이 실행되어도 필요한 값이 없을 수 있다.
• 검사 크기body parse error와 limit 처리 정책도 감사 로그에서 확인한다.

09SecRule: 변수·연산자·변환·액션을 분리해서 읽기

• 변수·연산자·액션SecRule은 검사 변수, 비교 연산자, 실행 액션을 조합한다. ARGS는 파싱된 파라미터 값, ARGS_NAMES는 이름, REQUEST_HEADERS:User-Agent는 특정 헤더, TX는 현재 트랜잭션의 변수 집합이다.
• 컬렉션 개수&ARGS는 컬렉션의 원소 수이며 문자열 길이 전체를 뜻하지 않는다.
• 문자열·정규식@streq는 정확한 문자열 비교, @rx는 정규표현식, @pm은 여러 패턴, @ipMatch는 주소 범위를 검사한다. @detectSQLi·@detectXSS도 탐지 휴리스틱과 구현 조건을 가지며 모든 공격의 정확한 판별기가 아니다.
• Capture정규식이 매칭되었다는 사실은 입력이 악성이라는 확정과 구분한다.
• Transformationt:none과 t:lowercase 같은 변환은 검사에 사용할 값을 준비한다. URL 디코딩·공백 처리·소문자화의 순서와 애플리케이션 파서가 다르면 오탐·미탐이 생길 수 있다.
• 다중 디코딩규칙이 본 값을 로그로 대조하며 원본 요청을 무조건 똑같이 바꿔 backend에 보낸다고 이해하지 않는다.

SecRule REQUEST_HEADERS:X-Course-Check "@streq block-me" \
 "id:1100001,phase:1,t:none,deny,status:403,log,msg:'Course WAF check'"

무해한 시험 헤더를 정확히 비교하는 학습용 규칙이다. id는 예시이며 기존 규칙과 충돌 여부를 확인한다. DetectionOnly에서는 차단 대신 관찰에 사용된다.

10액션·chain·상태 저장

• Deny·DetectionOnlydeny는 차단 결정, status는 응답 코드, log는 기록, id·msg·tag·rev는 식별·설명에 쓰인다. pass는 해당 규칙의 비차단 동작이며 뒤 모든 규칙을 자동 통과시키는 뜻이 아니다.
• Allow·Skipallow·skip 계열은 뒤 검사를 생략할 수 있어 광범위하게 적용하면 검사 공백을 만든다. drop을 모든 connector에서 항상 특정 FIN 패킷을 보내는 기능이라고 단정하지 않는다.
• Chainchain은 뒤따르는 조건을 결합한다. capture는 정규식 매칭 그룹을 TX 변수에 보관하는 기능이며 로그에 매칭 데이터를 남기거나 Filebeat로 전송하기 위한 보편적인 필수 조건은 아니다.
• Capture와 수집로그 포맷과 수집 파서가 어떤 필드를 보존하는지 별도로 확인한다.
• 빈도 상태 조건로그인 빈도 제한에는 상태 초기화와 LOGIN_COUNT 비교뿐 아니라 실패 판정, 카운터 증가, 집계 키, 만료 조건이 필요하다. 비교 규칙만 있어서는 실제 횟수가 누적되지 않는다.
• 증가·만료상태 저장의 범위·동시성·엔진 지원, 신뢰한 클라이언트 IP, 실패 이벤트의 정의와 시간 창이 필요하다. User-Agent에 도구 이름이 있다는 이유만으로 공격이나 행위자 신원을 확정하지 않는다.

11CRS: 개별 탐지와 최종 차단 점수

• Anomaly ScoreCRS anomaly scoring은 여러 탐지 규칙의 기여 점수를 트랜잭션에 모으고 별도의 평가 단계에서 임계값과 비교한다. 따라서 어떤 rule ID가 매칭되었다는 로그와 최종 요청 차단은 구분해야 한다.
• 점수 문맥요청과 응답의 점수·차단 경계도 별개이다.
• 임계값 예설명용으로 임계값이 5이고 두 탐지가 각각 3과 2점을 더하면 합계 5에서 차단 조건에 도달한다. 이는 설정을 이해하는 예이며 모든 rule의 점수가 같거나 모든 설치의 임계값이 5라는 뜻은 아니다.
• 개별 규칙실행 모드·early blocking·예외 규칙에 따라 실제 처리도 확인한다.
• Paranoia LevelParanoia Level은 활성화되는 탐지 규칙의 범위·엄격함과 관련되며 경보 severity나 확정된 공격 위험도와 같은 숫자가 아니다. 레벨을 높이면 정상 입력의 오탐도 늘 수 있다.
• 조정 근거정상 요청과 공격 재현을 함께 비교해 path·parameter·rule ID 단위로 필요한 예외를 제한한다.

15원본 Apache 스캔 로그: 404는 안전 판정이 아니다

• 원본 요청 로그원본 이미지에는 JNDI 형태 문자열과 여러 경로 요청이 보인다. 이것은 요청이 기록되었다는 근거이며 실제 취약한 라이브러리가 문자열을 평가했는지, 외부 조회·코드 실행이 발생했는지는 다른 증거가 필요하다.
• 시도와 영향문자열이 악성 시도의 후보라는 판단과 침해 성공이라는 결론을 분리한다.
• 404의 한계404는 요청한 자원을 찾지 못했다는 HTTP 결과다. 로그 기록은 그 전후에 발생할 수 있으므로 404만으로 취약점 시도가 실패했다고 보장할 수 없다.
• 200의 한계반대로 200도 공격 성공의 증거가 아니다. 요청 ID·시각으로 WAF audit, 앱 오류, DNS·네트워크와 프로세스 흔적을 대조한다.

수업 원본 자료

원본 Apache 로그의 관찰과 해설을 분리해 읽기

원본 크기로 보기 ↗

이 자료에서 읽어낼 것

1. 요청 URI, 상태 코드, User-Agent/Referer 위치 등에 같은 형태의 JNDI 문자열이 반복된다. 스캔으로 보이는 행위의 단서이지만 로그 문자열만으로 실제 원격 코드 실행을 입증하지 않는다.
2. 이미지 아래의 “404=대부분 실패”는 정정한다. 404는 HTTP 자원 처리 결과이며, 그 이전이나 별도 경로의 취약한 로깅 처리가 안전했음을 보증하지 않는다.
3. nessus.org 문자열과 테스트용 패턴은 사용한 도구의 단서다. 헤더 값은 요청자가 넣을 수 있으므로 도구·행위자 신원을 확정하는 증거는 아니다.
4. 이 화면에는 ModSecurity rule ID, intervention, CRS 누적 점수와 최종 차단 결정이 없다. WAF audit log·애플리케이션 로그·DNS/외부 연결 흔적을 대조해야 한다.

16관찰 모드에서 운영 정책으로 전환하기

• 관찰 모드처음에는 SecRuleEngine DetectionOnly와 필요한 audit 설정으로 정상 요청의 baseline을 확보한다. DetectionOnly는 규칙이 매칭되더라도 실제 차단을 하지 않으므로 “경보가 났다=방어됐다”로 보고하지 않는다.
• 본문 조건정상 로그인·업로드·API JSON·큰 본문 등 서비스의 실제 기능을 시험한다.
• 오탐 예외오탐을 재현하고 최소 범위 예외를 적용한 뒤 정상·비정상 시험을 반복하고 조치·되돌릴 절차를 정해 blocking으로 전환한다. 엔진·CRS 버전, paranoia level과 예외에 담당자·사유·검토 기한을 남긴다.
• 좁은 제외일부 URL의 동작을 살리려고 WAF 전체를 끄면 다른 경로의 보호도 사라진다.
• 최종 처리 결과최종 검증은 요청이 어느 경로를 지났는지, 어떤 rule이 무엇을 매칭했는지, 점수와 최종 action이 무엇인지, 앱에 전달되었는지와 정상 기능 영향까지 포함한다. wafw00f의 응답 지문은 제품 추정 단서이며 확정적인 구성 증거는 아니다.