📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 234편
이전 글: 233. Brute Force와 Scan 구분 · 다음 글: 235. IDS에서 Scan Alert 확인
1. 개념
방화벽은 스캔 흔적이 가장 넓게 남는 장비입니다. IDS 센서가 없는 구간이나 서비스 로그가 남지 않는 SYN 스캔도, 방화벽을 지나거나 막혔다면 기록이 있습니다. 방화벽 로그의 필드 구조와 일반 분석은 272. Firewall Log 구조, 273. Firewall Log 분석에서 다루고, 이 글은 스캔을 찾기 위한 집계 방법에 집중합니다.
스캔 흔적은 두 종류의 로그에 나뉘어 남습니다.
| 로그 | 스캔에서 알려 주는 것 | 한계 |
|---|---|---|
| 차단(Deny/Drop) 로그 | 스캔의 규모(시도한 포트·호스트 수) | 공격자가 얻은 정보는 알 수 없음 |
| 허용(Allow) 세션 로그 | 스캔이 통과한 포트(공격자가 볼 수 있었던 서비스) | 허용 로그를 남기지 않는 설정이 많음 |
즉 차단 로그는 "얼마나 두드렸나", 허용 로그는 "무엇이 보였나"를 알려 줍니다. 대응 우선순위는 허용 쪽에서 나옵니다.
2. 동작 원리
방화벽 로그에서 스캔을 찾는 집계 흐름입니다.
방화벽 로그 (시간 창: 예 10분)
↓
[1] 출발지별 그룹화
↓
[2] 출발지마다 계산: 고유 목적지 포트 수 / 고유 목적지 IP 수 / 차단 비율
↓
[3] 패턴 분류
├─ 한 목적지 × 多 포트 → 수직 스캔
├─ 多 목적지 × 한 포트 → 수평 스캔
└─ 多 × 多 → 블록 스캔
↓
[4] 같은 출발지의 "허용" 세션 추출 → 통과한 포트 = 노출 확인된 서비스
↓
[5] 이후 시간대의 같은 출발지 활동 검색 → 후속 공격 여부3. 주요 특징
- TCP 플래그: 호스트 방화벽(iptables·nftables LOG) 로그에는
SYN,ACK,FIN,RST같은 플래그가 기록됩니다. SYN만 있는 차단이 여러 포트로 퍼져 있으면 연결 시도형 스캔이고, 플래그 조합이 비정상(FIN만, 플래그 없음 등)이면 특수 스캔을 의심합니다(219. Null Scan, 220. XMAS Scan). - 출발지 포트 고정: 많은 자동화 도구가 한 번의 스캔에서 같은 출발지 포트를 재사용하므로, SPT가 같고 DPT만 바뀌는 차단 로그는 스캔의 전형적인 모양입니다(도구·설정에 따라 다름).
- 로그 양 제한: 호스트 방화벽 로깅은 보통 속도 제한(limit)을 두므로 로그 건수가 실제 패킷 수보다 적을 수 있습니다.
호스트 방화벽 로그 위치는 배포판과 도구에 따라 다릅니다.
| 환경 | 차단 로그 확인 위치(일반적) | 비고 |
|---|---|---|
| Ubuntu + UFW | /var/log/ufw.log, 커널 로그 | [UFW BLOCK] 접두어 |
| Rocky + firewalld | 저널·/var/log/messages | 거부 로그는 --set-log-denied 설정 필요 |
| iptables/nftables LOG 규칙 | 커널 로그(저널, kern.log) | 접두어는 규칙에서 지정 |
4. 예시
UFW 차단 로그 형식 예시입니다(값은 환경마다 다름, 일부 필드 생략).
[UFW BLOCK] IN=ens33 OUT= SRC=203.0.113.90 DST=192.168.10.20 PROTO=TCP SPT=51544 DPT=23 WINDOW=1024 SYN URGP=0
[UFW BLOCK] IN=ens33 OUT= SRC=203.0.113.90 DST=192.168.10.20 PROTO=TCP SPT=51544 DPT=445 WINDOW=1024 SYN URGP=0
[UFW BLOCK] IN=ens33 OUT= SRC=203.0.113.90 DST=192.168.10.20 PROTO=TCP SPT=51544 DPT=3389 WINDOW=1024 SYN URGP=0실습 예시 — 본인 소유 실습 서버에서 출발지별 고유 목적지 포트 수를 세는 방어 측 명령입니다.
# Ubuntu (UFW)
sudo grep "UFW BLOCK" /var/log/ufw.log \
| grep -oE "SRC=[0-9.]+|DPT=[0-9]+" | paste - - | sort -u \
| awk '{print $1}' | uniq -c | sort -rn | head
# Rocky (firewalld 거부 로그를 켠 경우, 저널에서 조회)
sudo firewall-cmd --get-log-denied
sudo journalctl -k --since "1 hour ago" | grep -E "REJECT|DROP" | grep -oE "SRC=[0-9.]+" | sort | uniq -c | sort -rn | head첫 명령은 (출발지, 목적지 포트) 쌍을 중복 제거한 뒤 출발지별로 세므로, 결과 숫자가 고유 포트 수입니다. 거부 로그의 접두어(REJECT, DROP 등)는 firewalld 버전과 백엔드에 따라 다를 수 있으므로 실제 로그를 먼저 확인하고 패턴을 맞춥니다.
| 집계 결과 | 해석 | 다음 단계 |
|---|---|---|
| 한 출발지, 고유 포트 900개 | 수직 스캔 | 허용 세션에서 통과 포트 확인 |
| 한 출발지, 목적지 IP 200개 × 445 | 수평 스캔 | 445 허용 호스트 확인 |
| 차단 로그만 있고 허용 없음 | 정찰 실패 | 기록, 반복 시 차단 목록 |
5. 보안 관점
- 허용 로그를 남기지 않으면 스캔이 무엇을 발견했는지 알 수 없습니다. 최소한 외부 공개 서비스의 허용 세션은 기록하도록 권고합니다.
- 차단 로그가 많다는 것은 방화벽이 제 역할을 한다는 뜻이기도 합니다. 정책 관점에서 확인할 것은 스캔 결과에 드러난 불필요한 허용 포트입니다.
- 방화벽 로그가 저장 용량 때문에 샘플링되거나 짧게 보관되면 느린 스캔을 놓칩니다. 보관 기간과 수집 누락을 주기적으로 점검합니다.
6. SOC 관점
관제자가 확인할 질문
- 출발지의 고유 목적지 포트·IP 수는? 수직·수평·블록 중 어떤 모양인가?
- 같은 출발지의 허용 세션은 어떤 포트였는가? 그 포트는 외부 공개가 의도된 서비스인가?
- 스캔 직후 같은 출발지가 허용 포트에 데이터를 주고받는 세션을 만들었는가?
- 방향이 내부 → 내부라면 출발 단말의 감염 여부를 확인했는가?
방화벽 차단 로그 집계 → 스캔 출발지 목록
↓ 허용 세션 조회
통과 포트 없음 → 기록·감시 (반복 시 차단 목록 검토)
통과 포트 있음 → 서비스 로그·IDS Alert와 연계 (235편)오탐 주의: 방화벽 뒤 서버의 재시작 직후 클라이언트 재접속, NAT 장비 뒤 여러 사용자가 한 공인 IP로 보이는 경우, 인터넷 연구용 스캐너(공개적으로 알려진 조사 기관)는 스캔처럼 보입니다. 인터넷 연구용 스캔은 위험도가 낮지만, 노출 서비스를 점검하는 계기로 삼습니다.
7. 핵심 정리
- 방화벽은 서비스 로그가 남지 않는 스캔까지 기록하는 가장 넓은 흔적 위치입니다.
- 차단 로그는 스캔의 규모를, 허용 로그는 공격자에게 보인 서비스를 알려 줍니다.
- 출발지별 고유 목적지 포트·IP 수로 수직·수평·블록 스캔을 분류합니다.
- SPT 고정·DPT 변화, 비정상 TCP 플래그는 스캔의 전형적인 로그 모양입니다.
- 대응 우선순위는 통과 포트와 그 포트로의 후속 세션으로 정합니다.
