94. Port Scan

Network Scan PORT Soc 네트워크 패킷 분석 보안관제 포트 · 프로토콜 분석

네트워크 · 패킷 분석

목록 보기

94/300

📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 94편
이전 글: 93. 서비스와 포트 매핑 — 포트 번호만으로 서비스를 단정하면 안 되는 이유 · 다음 글: 95. Firewall Log의 Port

1. 개념

포트 스캔(Port Scan) 은 대상 호스트의 어떤 포트가 열려 있는지 확인하기 위해 여러 포트에 연결을 시도하는 행위입니다. 정상 접속은 이미 알고 있는 서비스 포트에 연결해서 실제로 서비스를 이용하는 행위입니다.

두 행위는 같은 TCP 3-Way Handshake, 같은 포트 번호를 사용하므로 패킷 한두 개로는 구분되지 않습니다. 차이는 "연결을 왜 만들었는가" 에서 생기고, 그 목적의 차이가 포트 개수·연결 완성도·데이터 양·서비스 로그에 흔적으로 드러납니다.

이 글은 포트 관점에서 둘을 구분하는 기준만 다룹니다. 스캔 유형별 패킷 특징과 탐지는 05. 네트워크 스캔 징후 분석 영역(201. 네트워크 스캔이란 무엇인가부터)에서 깊게 다룹니다.

구분	목적	관심 대상
정상 접속	서비스 이용(웹 조회, 로그인, 파일 전송)	응답 내용
포트 스캔	열린 포트 파악	응답 유무와 종류(SYN/ACK, RST, 무응답)

2. 동작 원리

같은 서버의 22번 포트에 대해 정상 접속과 스캔이 남기는 흐름을 비교하면 다음과 같습니다.

[정상 접속]  192.168.10.10 → 192.168.10.20:22
  SYN → SYN/ACK → ACK            (연결 수립)
    ↓
  SSH 버전 교환 → 키 교환 → 인증 → 세션 (수 KB 이상, 수 초~수 시간)
    ↓
  FIN 교환으로 종료 → sshd 로그에 인증 성공/실패 기록

[포트 스캔]  192.168.10.10 → 192.168.10.20:20~25, 80, 443 ...
  22: SYN → SYN/ACK → RST        (열림 확인 후 바로 끊음, 데이터 없음)
  23: SYN → RST/ACK               (닫힘)
  25: SYN → (무응답)               (필터링)
    ↓
  수 초 안에 여러 포트 → 서비스 로그에는 거의 남지 않음

연결을 끝까지 수립하는 스캔(TCP Connect 방식)은 SYN/ACK 뒤에 ACK까지 보내고 바로 종료하므로, 서비스에 따라 "연결했지만 아무 데이터도 보내지 않았다"는 기록이 남기도 합니다. 각 스캔 방식의 차이는 05 영역 207. TCP Connect Scan, 208. SYN Scan에서 다룹니다.

3. 주요 특징

포트 관점의 구분 기준입니다.

기준	정상 접속	포트 스캔
목적지 포트 수	1개(또는 서비스에 필요한 소수)	여러 개, 연속·무작위
닫힌 포트 시도	드묾(오설정 제외)	많음 → RST/ACK, ICMP 응답 다수
연결 수립	대부분 완료	미완료(SYN만, SYN/ACK 후 RST) 비율 높음
세션당 데이터	서비스에 맞는 양	0 또는 매우 적음
세션 지속 시간	서비스 특성에 따름	매우 짧음
서비스(앱) 로그	요청·인증 기록이 남음	거의 없음, 또는 "데이터 없이 종료" 류의 기록
시간 분포	사용자 행동에 따라 불규칙	짧은 시간에 몰리거나, 의도적으로 느리게 분산

스캔처럼 보이는 정상 트래픽도 많습니다. 단정하기 전에 출발지를 먼저 확인합니다.

정상 트래픽	스캔처럼 보이는 이유	구분 방법
모니터링·헬스체크	포트에 연결만 하고 끊음(SYN → SYN/ACK → RST 또는 즉시 종료)	출발지가 모니터링 서버, 일정 주기, 고정된 포트
인가된 취약점 점검	실제로 스캔함	점검 일정·점검 서버 IP 사전 공유
자산관리·NAC 솔루션	여러 호스트의 여러 포트 확인	솔루션 서버 IP 목록
서비스 탐색 프로토콜	여러 호스트로 멀티캐스트·브로드캐스트	5353, 1900, 5355 등 탐색용 포트
NAT·프록시 공인 IP	여러 사용자의 접속이 한 IP로 합쳐짐	목적지 포트가 서비스 포트에 한정됨
방화벽 뒤 서비스 장애	SYN 재전송·무응답이 반복	같은 포트, 같은 출발지 포트의 재전송

4. 예시

실습 예시 — ⚠️ 본인 소유 실습망에서만 수행합니다. 서버 VM(192.168.10.20)에서 패킷을 관찰하면서, 클라이언트 VM(192.168.10.10)에서 정상 접속 1회와 소수 포트 확인을 각각 실행해 흔적을 비교합니다.

# 서버 VM: 클라이언트와의 TCP 제어 패킷(SYN, RST)만 관찰 (인터페이스 ens33은 예시)
sudo tcpdump -nn -i ens33 'host 192.168.10.10 and tcp[tcpflags] & (tcp-syn|tcp-rst) != 0'

# 클라이언트 VM: 정상 접속
ssh user@192.168.10.20

# 클라이언트 VM: 소수 포트 확인 (본인 실습망에서만, Nmap 설치 필요)
# Rocky: sudo dnf install -y nmap   /   Ubuntu: sudo apt install -y nmap
nmap -sT -p 22,23,80 192.168.10.20

서버 측 tcpdump 출력 형식 예시(값은 환경마다 다름, 일부 생략):

# 정상 접속
192.168.10.10.51000 > 192.168.10.20.22: Flags [S], ...
192.168.10.20.22 > 192.168.10.10.51000: Flags [S.], ...
# (이후 데이터 교환은 필터에 의해 표시 안 됨)

# 포트 확인
192.168.10.10.51010 > 192.168.10.20.22: Flags [S], ...
192.168.10.20.22 > 192.168.10.10.51010: Flags [S.], ...
192.168.10.10.51010 > 192.168.10.20.22: Flags [R.], ...
192.168.10.10.51012 > 192.168.10.20.23: Flags [S], ...
192.168.10.20.23 > 192.168.10.10.51012: Flags [R.], ...
192.168.10.10.51014 > 192.168.10.20.80: Flags [S], ...
192.168.10.20.80 > 192.168.10.10.51014: Flags [R.], ...

관찰	해석
정상 접속: 22번 하나, 이후 데이터 교환	서비스 이용
포트 확인: 1초 안에 22·23·80	여러 포트 시도
22번: 수립 직후 클라이언트가 RST	데이터 없이 연결 종료
23·80번: 서버가 RST/ACK	닫힌 포트 응답

이때 서버의 sshd 로그(Rocky: /var/log/secure, Ubuntu: /var/log/auth.log, 또는 journalctl -u sshd / -u ssh)에는 정상 접속은 인증 기록이, 포트 확인은 OpenSSH 버전에 따라 "식별 문자열을 받지 못함"이나 kex_exchange_identification 관련 메시지 정도만 남거나 아무 기록도 남지 않을 수 있습니다. Nmap의 결과 상태(open·closed·filtered) 해석은 05 영역 204. Nmap 기본 사용법에서 다룹니다.

5. 보안 관점

포트 스캔은 공격의 정찰 단계입니다. 스캔 자체로 피해가 생기지는 않지만, 스캔 뒤에 열린 포트에 대한 접속·무차별 대입·취약점 공격이 이어지는지가 중요합니다(05 영역 245. Scan과 공격의 연관성 분석).
인터넷에 노출된 서버는 외부 자동화 스캔을 상시로 받습니다. 모든 외부 스캔에 대응하기보다, 노출하지 말아야 할 포트가 열려 있다고 응답했는지(SYN/ACK)를 우선 확인하는 것이 효율적입니다.
내부 출발지의 스캔은 외부 스캔보다 우선순위가 높습니다. 인가된 점검 서버가 아니라면 내부 호스트 장악 후 정찰일 수 있습니다(05 영역 228. 내부망 정찰).

6. SOC 관점

흔적 위치	정상 접속	포트 스캔
방화벽 로그	서비스 포트 허용 세션, 바이트 수 정상	다수 포트 차단, 허용 세션은 바이트 극소
IDS	서비스별 프로토콜 이벤트	스캔 탐지 룰(임계치 기반) Alert
서비스 로그	요청·인증 기록	거의 없음
서버 패킷	핸드셰이크 뒤 데이터	SYN/ACK 뒤 RST, 다수 RST/ACK