📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 293편
이전 글: 292. Brute Force 탐지 · 다음 글: 294. 비정상 Network Traffic 탐지
1. 개념
Web Attack 탐지는 웹 서버·웹 애플리케이션을 노리는 요청(SQL Injection, XSS, 경로 조작, 명령 삽입, 웹 셸 업로드 등)을 HTTP 요청의 내용에서 찾아내는 것입니다. 웹 스캔과 디렉터리 스캔의 흔적은 05 영역 230. Web Scan, 231. Directory Scan에서, HTTP 이상징후 패킷 분석은 03 영역 145. HTTP 메서드와 상태코드로 보는 이상징후에서 다뤘습니다.
이 글은 탐지 규칙이 HTTP의 어느 필드를 보는지, 그리고 Alert가 났을 때 성공 여부를 어떻게 판단하는지를 다룹니다.
| 공격 유형(개념) | 규칙이 주로 보는 위치 | 탐지 근거의 성격 |
|---|---|---|
| SQL Injection | URI 파라미터, 요청 본문 | SQL 구문 키워드·연산자 조합 |
| XSS | URI 파라미터, 본문, 일부 헤더 | 스크립트 태그·이벤트 속성 |
| 경로 조작(Path Traversal) | 원본 URI | 상위 디렉터리 이동 표기, 인코딩된 변형 |
| 명령 삽입 | 파라미터, 본문 | 셸 구분자와 시스템 명령 조합 |
| 웹 셸 업로드·접근 | 업로드 본문, 요청 경로, 응답 본문 | 스크립트 파일 업로드, 알려진 웹 셸 문자열 |
| 자동화 도구 | User-Agent, 요청 패턴 | 알려진 스캐너 식별 문자열 |
2. 동작 원리
웹 공격 탐지의 흐름입니다. 핵심은 정규화 후 검사와 응답 확인입니다.
HTTP 요청 (TLS라면 복호화 지점 이후에서만 내용 확인 가능)
↓
[HTTP 파서] 메서드·URI·헤더·본문 분리
↓
[정규화] URL 디코딩, 경로 정리, 대소문자 등 → 정규화 버퍼 (http.uri)
│ 원본 유지 → 원본 버퍼 (http.uri.raw)
↓
[규칙 매칭] 필드별 content·pcre 조건
↓ 일치 → Alert (요청 시점)
↓
[응답 관찰] 같은 흐름의 상태 코드·응답 크기·응답 본문
↓
관제자: 요청이 "시도"였는가, 서버가 "처리"했는가- 정규화 버퍼는 인코딩 변형을 하나로 모아 주므로 탐지에 유리합니다. 반면 경로 정리 과정에서 상위 디렉터리 표기가 정리되어 사라질 수 있어, 경로 조작 탐지 규칙은 원본 버퍼를 쓰는 경우가 있습니다(엔진 버전·설정별 정규화 범위 확인 필요).
- HTTPS는 IDS가 내용을 볼 수 없습니다. 이 경우 복호화하는 지점(리버스 프록시, WAF, 로드 밸런서)의 로그나 웹 서버 로그가 주요 탐지원이 됩니다.
3. 주요 특징
웹 공격 Alert는 요청만 보고 판단하면 오판하기 쉽습니다. 응답을 함께 봅니다.
| 응답 정보 | 해석 경향 | 주의 |
|---|---|---|
| 404 | 대상 경로 없음, 자동화 탐색 가능성 | 웹 셸 경로 탐색의 일부일 수 있음 |
| 403 / WAF 차단 페이지 | 차단됨 | 차단 전 다른 요청이 통과했는지 확인 |
| 400 / 500 | 요청 오류·서버 오류 | 500은 입력이 서버 로직에 도달했다는 뜻일 수 있음 |
| 200 + 평소와 다른 응답 크기 | 처리됨, 결과 반환 가능성 | 응답 본문·서버 로그 확인 필요 |
| 200 + 평소와 같은 크기 | 입력이 무시되었을 가능성 | 단정하지 말고 로그로 확인 |
- 대부분의 웹 공격 Alert는 인터넷의 자동화 탐색입니다. 대상 서버에 해당 기술(예: 특정 CMS, 특정 언어)이 없다면 영향 가능성이 낮습니다.
- 반대로 같은 출발지의 요청이 점점 구체적으로 바뀌거나, 응답 크기가 변하는 요청이 섞여 있다면 사람이 직접 진행하는 공격일 수 있습니다.
4. 예시
URI 필드에서 SQL 구문 조합을 찾는 탐지 규칙의 형식 예시입니다(Suricata 문법, 값은 환경마다 다름, 실제 운영에는 검증된 배포 규칙 사용 권장).
# 형식 예시 — 정규화된 URI에 "union" 뒤 "select"가 이어지면 Alert
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL possible SQLi keywords in URI"; flow:established,to_server; http.uri; content:"union"; nocase; content:"select"; nocase; distance:0; classtype:web-application-attack; sid:1001701; rev:1;)분석 방법 — distance:0은 두 번째 content가 첫 번째 뒤 어디든 있으면 된다는 뜻입니다. 이 규칙은 넓은 편이라 검색 기능에 해당 단어를 입력한 정상 요청에도 일치할 수 있습니다. Alert가 나면 같은 flow_id의 http 이벤트와 웹 서버 로그를 대조합니다.
# 형식 예시 — 웹 서버 접근 로그 (combined 형식, 요청 경로는 생략 표기)
203.0.113.81 - - [30/Sep/2026:14:02:11 +0900] "GET /item.php?id=(탐지된 요청) HTTP/1.1" 500 612 "-" "Mozilla/5.0"
203.0.113.81 - - [30/Sep/2026:14:02:15 +0900] "GET /item.php?id=(탐지된 요청) HTTP/1.1" 200 48210 "-" "Mozilla/5.0"평소 /item.php 응답이 수 KB인데 한 요청의 응답만 크게 늘었다면 데이터가 추가로 반환되었을 가능성을 조사합니다.
5. 보안 관점
- 웹 공격 탐지는 IDS 단독으로 완결되지 않습니다. TLS 종료 지점, WAF, 웹 서버·애플리케이션 로그가 함께 있어야 판단할 수 있습니다.
- 공격자는 인코딩 중첩, 대소문자 혼합, 주석 삽입, 요청 본문 사용으로 URI 규칙을 피하려 합니다. 정규화와 본문 검사 범위를 확인합니다.
- 웹 셸은 업로드 순간보다 이후 접근(특정 경로로의 반복 POST, 작은 요청에 큰 응답)에서 드러나는 경우가 많습니다.
6. SOC 관점
관제자가 웹 공격 Alert를 볼 때 확인할 질문
- 대상 서버에 규칙이 노리는 기술·경로가 존재하는가?
- 응답 코드와 응답 크기는? 평소 같은 경로의 응답과 비교하면?
- 같은 출발지의 요청 흐름이 탐색 → 구체화 → 반복으로 바뀌고 있는가?
- WAF가 차단했는가, 통과시켰는가? 웹 서버 로그에도 같은 요청이 있는가?
웹 공격 Alert
↓ 대상 기술 확인 → 해당 없음: 자동화 탐색으로 기록
↓ 해당 있음
↓ 응답 코드·크기 확인 (IDS http 이벤트, 웹 서버 로그)
403·404 위주 → 시도, 출발지 감시·차단 검토
200·500 + 이상 크기 → 서버 처리 의심 → 애플리케이션·DB 로그 확인 → 에스컬레이션오탐 주의: 검색창·게시판에 SQL·스크립트 관련 단어를 입력하는 정상 사용자, 개발자의 API 테스트, 승인된 웹 취약점 점검이 흔한 오탐 원인입니다. 점검 일정과 출발지를 먼저 대조합니다.
7. 핵심 정리
- 웹 공격 탐지 규칙은 HTTP의 URI·파라미터·본문·헤더 등 필드별로 공격 구문의 특징을 찾습니다.
- 정규화 버퍼는 인코딩 변형 탐지에, 원본 버퍼는 인코딩·경로 표기 자체 탐지에 쓰입니다.
- HTTPS 구간은 IDS가 내용을 볼 수 없어 복호화 지점과 웹 서버 로그가 주요 탐지원입니다.
- Alert 판단은 요청이 아니라 응답 코드·응답 크기·서버 로그로 서버 처리 여부를 확인해 내립니다.
- 대상 기술의 존재 여부와 같은 출발지의 요청 흐름 변화로 자동화 탐색과 표적 공격을 구분합니다.
