📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 233편
이전 글: 232. SSH Brute Force · 다음 글: 234. Firewall에서 Scan 흔적 찾기
1. 개념
관제 화면에서 "한 출발지에서 짧은 시간에 연결이 많다"는 이벤트는 두 가지 전혀 다른 행위일 수 있습니다. Scan은 "무엇이 열려 있는가"를 묻는 정찰이고, Brute Force는 "이 문을 열 수 있는가"를 시도하는 인증 공격입니다. 둘을 잘못 분류하면 우선순위가 뒤집힙니다. 스캔은 대부분 기록·감시로 끝나지만, 대입 공격은 계정 탈취 여부 확인이 반드시 필요합니다.
| 구분 | Scan | Brute Force |
|---|---|---|
| 질문 | 어떤 호스트·포트·서비스가 있는가 | 어떤 계정·비밀번호가 맞는가 |
| 목적지 포트 | 여러 포트(또는 여러 호스트의 한 포트) | 인증 서비스 1개 포트에 집중 |
| 세션 | 짧거나 미완성(SYN만, RST 종료) | 연결 수립 후 인증 교환까지 진행 |
| 데이터량 | 거의 없음 | 연결마다 일정량(키 교환·인증 메시지) |
| 서비스 로그 | 거의 없음 또는 배너 확인 흔적 | 인증 실패 로그 다수 |
| 위험 판단 기준 | 열린 포트·후속 활동 | 성공 로그인 여부 |
2. 동작 원리
두 행위를 가르는 판단 흐름입니다. 첫 번째 기준은 목적지 포트 분포, 두 번째는 세션이 인증 단계까지 갔는가입니다.
"한 출발지, 짧은 시간, 연결 多" 이벤트
↓
[1] 목적지 포트가 여러 개인가?
├─ 예 → 수직 스캔 (한 호스트 × 多 포트)
└─ 아니오 (한 포트) ↓
[2] 목적지 호스트가 여러 개인가?
├─ 예, 호스트당 1~2회 → 수평 스캔(스윕)
└─ 호스트당 多회 ↓
[3] 세션이 수립되고 데이터가 오갔는가? 서비스에 인증 실패 로그가 있는가?
├─ 예 → Brute Force (호스트가 여럿이면 여러 서버 대상 대입)
└─ 아니오 → 반복 연결 확인·배너 확인 → 스캔 또는 장애·헬스체크 검토3. 주요 특징
수평 스캔과 다수 서버 대입이 가장 헷갈립니다. 둘 다 "여러 호스트 × 22번 포트"로 보이기 때문입니다. 차이는 호스트당 연결 횟수와 서비스 로그에 있습니다.
| 지표 | 22번 수평 스캔 | 여러 서버 대상 SSH 대입 |
|---|---|---|
| 호스트당 연결 수 | 1~2회 | 수십 회 이상 |
| 세션 길이 | 1초 미만, SYN만인 경우 多 | 수 초, 인증 교환 포함 |
| 서버 → 클라이언트 바이트 | 0 또는 배너 정도 | 연결마다 수 KB 수준 |
| sshd 로그 | 배너 교환 없이 끊긴 연결 흔적 가능 | Failed password 다수 |
- 배너만 확인하고 끊는 스캔은 sshd 로그에 인증 없이 연결이 닫혔다는 메시지를 남길 수 있습니다(예: 식별 문자열을 받지 못했다는 메시지,
[preauth]연결 종료). 정확한 문구는 OpenSSH 버전에 따라 다릅니다. - 순서가 이어지는 경우도 많습니다. 스캔으로 열린 22번을 찾은 뒤 같은 출발지가 대입을 시작하면, 두 이벤트를 하나의 사건으로 묶어야 합니다(245. Scan과 공격의 연관성 분석).
4. 예시
같은 출발지에 대한 방화벽 세션 로그 집계 형식 예시입니다(값은 환경마다 다름).
# 형식 예시 — 출발지 203.0.113.80, 10분간 22/tcp 세션 요약
목적지 세션 수 평균 지속 평균 수신 바이트(서버→클라이언트)
192.168.20.11 1 0.2초 0
192.168.20.12 1 0.3초 41
192.168.20.13 148 4.1초 2,960분석 방법 — .11과 .12는 호스트당 1회, 데이터가 없거나 배너 크기뿐이므로 스캔의 모양입니다. .13은 148회 연결에 연결마다 수 KB가 오가므로 인증 단계까지 진행된 대입의 모양입니다. .13의 인증 로그를 반드시 확인합니다.
실습 예시 — 본인 소유 실습 환경의 Suricata flow 이벤트에서 출발지의 목적지별 연결 수와 응답 바이트를 집계하는 방어 측 명령입니다(필드 구성은 버전·설정에 따라 다를 수 있음).
sudo jq -r 'select(.event_type=="flow" and .src_ip=="203.0.113.80" and .dest_port==22)
| [.dest_ip, .flow.bytes_toclient] | @tsv' /var/log/suricata/eve.json \
| awk '{c[$1]++; b[$1]+=$2} END{for(h in c) print h, c[h], b[h]/c[h]}' | sort -k2 -rn| 결과 모양 | 분류 | 다음 확인 |
|---|---|---|
| 목적지 多, 연결 1회, 바이트 0 | 수평 스캔 | 열린 호스트 목록, 후속 접속 |
| 목적지 1, 연결 多, 바이트 일정 | 대입 | 인증 로그의 계정·성공 여부 |
| 둘 다 순차적으로 발생 | 스캔 → 대입 연계 | 하나의 사건으로 묶어 타임라인 작성 |
5. 보안 관점
- 대입은 성공하면 곧바로 침해입니다. 스캔으로 분류해 종결한 이벤트 속에 대입이 섞여 있지 않은지 호스트당 연결 수로 다시 확인합니다.
- 반대로 모든 반복 연결을 대입으로 보고 계정 조치를 요청하면 운영 부서의 신뢰를 잃습니다. 서비스 로그의 인증 기록이 판단 근거입니다.
- 암호화된 서비스(SSH, HTTPS 로그인)는 네트워크만으로 성공·실패를 구분할 수 없으므로 호스트 로그 수집 범위가 판단 가능 범위를 결정합니다.
6. SOC 관점
관제자가 확인할 질문
- 목적지 포트 수와 호스트 수는? 호스트당 연결 횟수는?
- 세션이 인증 단계까지 진행했는가(지속 시간, 서버 응답 바이트)?
- 대상 서비스 로그에 인증 실패·성공 기록이 있는가?
- 스캔과 대입이 시간 순서로 이어지는가?
오탐 주의: 모니터링 시스템의 포트 헬스체크(여러 서버 × 한 포트, 짧은 연결)는 수평 스캔과 비슷하고, 잘못 설정된 자동화 계정은 대입과 비슷합니다. 출발지 자산 확인이 분류보다 먼저입니다. 탐지 규칙에서 두 패턴을 다르게 세는 방법은 291. Port Scan 탐지, 292. Brute Force 탐지를 참고합니다.
7. 핵심 정리
- Scan은 무엇이 열려 있는지 묻는 정찰, Brute Force는 인증을 통과하려는 공격으로 대응 우선순위가 다릅니다.
- 1차 기준은 목적지 포트·호스트 분포, 2차 기준은 세션이 인증 단계까지 진행되었는가입니다.
- 22번 수평 스캔과 여러 서버 대상 대입은 호스트당 연결 수, 세션 길이, 응답 바이트, sshd 로그로 구분합니다.
- 스캔 뒤 같은 출발지의 대입이 이어지면 하나의 사건으로 묶어 분석합니다.
- 대입으로 분류되면 성공 로그인 여부 확인이 필수입니다.
