208. SYN Scan

Ids Network Scan Soc 네트워크 스캔 징후 분석 네트워크 패킷 분석 보안관제

네트워크 · 패킷 분석

목록 보기

208/300

📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 208편
이전 글: 207. TCP Connect Scan · 다음 글: 209. UDP Scan

1. 개념

SYN Scan(Half-open Scan) 은 각 포트에 SYN만 보내고, SYN/ACK가 오면 열림, RST가 오면 닫힘으로 판단한 뒤 연결을 완성하지 않는 방식입니다. Raw 패킷을 만들 수 있는 관리자 권한이 필요하며, 권한이 있을 때 많은 스캔 도구의 기본 방식입니다.

공격자 입장에서 이 방식이 선호되는 이유는 대상 서비스가 연결을 받아들이지 않기 때문에 애플리케이션 로그에 거의 남지 않는다는 점입니다. 따라서 방어자는 서비스 로그가 아니라 네트워크 계층(방화벽, IDS, 패킷)에서 흔적을 찾아야 합니다. 패킷 필드 수준의 식별 방법은 143. SYN Scan Packet 분석에서 다뤘습니다.

비교	SYN Scan	TCP Connect Scan
열린 포트의 세 번째 패킷	RST (ACK 플래그 없음)	ACK
서비스 프로세스의 연결 수락	없음	있음
서비스 로그	거의 없음	짧은 연결 기록 가능
주 탐지 위치	방화벽·IDS·NDR·패킷	방화벽 + 서비스 로그

2. 동작 원리

[열린 포트]
 스캐너 ── SYN ─────→ 서버          서버 커널: SYN 대기열에 반쯤 열린 연결 등록
 스캐너 ←── SYN/ACK ── 서버
 스캐너 ── RST ─────→ 서버          서버 커널: 반쯤 열린 연결 삭제
                                    (서비스 프로세스는 연결을 받지 않음 → 앱 로그 없음)
[닫힌 포트]
 스캐너 ── SYN ─────→ 서버
 스캐너 ←── RST/ACK ── 서버
[필터링]
 스캐너 ── SYN ─────→ 방화벽 DROP (무응답, 일정 시간 후 재전송 1회 정도)
        ↓
방어 측 흔적: 방화벽 SYN 차단 로그 / 미완성 세션 / IDS 임계치 Alert / 패킷의 SYN→SYN/ACK→RST

열린 포트에서 스캐너가 보내는 RST는 SYN/ACK에 대한 거절이므로 ACK 플래그 없이 RST만 설정되고, 순서 번호는 SYN/ACK의 확인 번호와 같습니다. 정상 연결 도중의 RST와 구분하는 패킷 단서입니다.

3. 주요 특징

서비스 로그 공백: 서버의 SSH·웹 로그에 아무 기록이 없어도 SYN Scan이 없었다고 단정할 수 없습니다.
Stateful 방화벽의 미완성 세션: 허용 정책 포트에서는 SYN으로 세션이 만들어졌다가 Handshake가 완료되지 않고 끝납니다. 장비에 따라 "incomplete", "세션 미수립", "timeout" 같은 형태로 기록됩니다(표현은 장비마다 다름).
짧은 시간 다수 포트: 연결 수립 비용이 없어 매우 빠르게 진행되므로, 초당 이벤트 수가 급격히 늘어납니다.

SYN 패킷이 대량으로 보인다는 점에서 SYN Flood(서비스 거부 공격) 와 혼동하기 쉽습니다.

기준	SYN Scan	SYN Flood
목적	열린 포트 확인	연결 대기열 고갈(서비스 거부)
목적지 포트	여러 포트, 포트당 1~2회	소수 서비스 포트에 집중
출발지	보통 실제 주소 1개(응답을 받아야 하므로)	위조된 다수 주소인 경우가 많음
SYN/ACK 이후	스캐너가 RST 전송	응답 없음(위조 주소) → 반쯤 열린 연결 누적
서버 영향	거의 없음	연결 지연·실패, SYN 쿠키 동작

4. 예시

실습 예시 — 본인 소유 실습망에서 SYN Scan 흔적을 확인하는 방어 측 명령입니다(Rocky/Ubuntu 공통, 값은 환경마다 다름).

# SYN만 설정된 패킷(연결 시도) 캡처
sudo tcpdump -nn -i ens33 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

# 캡처 파일에서 "ACK 없는 RST"를 보낸 출발지 확인 (열린 포트 확인 후 거절한 쪽)
tshark -r /tmp/syn.pcapng -Y 'tcp.flags.reset == 1 && tcp.flags.ack == 0' \
  -T fields -e ip.src -e tcp.dstport | sort | uniq -c | sort -rn | head

Wireshark에서 한 스트림이 SYN → SYN/ACK → RST로 끝나는지 보려면 tcp.flags.syn == 1 || tcp.flags.reset == 1 필터를 걸고 같은 tcp.stream 번호로 묶어 봅니다.

tshark 결과 형식 예시(값은 환경마다 다름):

      1 192.168.10.50   22
      1 192.168.10.50   80
      1 192.168.10.50   3306

같은 시간대 방화벽 로그 형식 예시(일부 필드 생략):

kernel: DROP IN=ens33 SRC=192.168.10.50 DST=192.168.10.20 PROTO=TCP SPT=40112 DPT=135 WINDOW=1024 SYN
kernel: DROP IN=ens33 SRC=192.168.10.50 DST=192.168.10.20 PROTO=TCP SPT=40112 DPT=139 WINDOW=1024 SYN

관찰	해석
출발지가 22·80·3306에 ACK 없는 RST 1회씩	세 포트가 열림으로 확인된 뒤 연결을 거절
차단 로그의 SPT 고정, DPT만 변화	도구가 같은 출발지 포트를 재사용하는 모양(도구·설정에 따라 다름)
서버 sshd·웹 로그에 기록 없음	연결 미수립으로 앱 로그 공백

5. 보안 관점

SYN Scan은 서비스 로그에 남지 않으므로, 네트워크 계층 로그를 수집하지 않는 환경에서는 정찰 자체를 놓칩니다. 방화벽 차단 로그를 샘플링 없이 보관하고 IDS 스캔 탐지를 켜 두는 것이 기본 대응입니다.
결과로 얻는 정보는 Connect 방식과 같으므로, 대응 우선순위는 여전히 열림으로 확인된 포트와 이후 접속 시도입니다.
관리자 권한이 필요한 방식이므로, 내부 단말에서 발생했다면 해당 단말에서 권한 상승이나 관리자 계정 사용이 있었는지도 확인할 가치가 있습니다.

6. SOC 관점

흔적 위치	확인 내용
방화벽	다수 포트 SYN 차단, 미완성 세션 기록
IDS/NDR	출발지별 SYN 임계치 초과 Alert, 도구 특징 시그니처
패킷 캡처	스트림당 2~3패킷, ACK 없는 RST
서비스 로그	기록 없음(없다는 사실 자체가 단서)

관제자가 확인할 질문

SYN만 보내고 데이터 교환이 없는 스트림이 한 출발지에서 몇 개 포트에 걸쳐 있는가?
대상이 SYN/ACK로 답한 포트는 무엇이며, 외부 노출이 의도된 포트인가?
스캔 이후 같은 출발지가 열린 포트로 실제 연결을 수립했는가?

오탐 주의: 서버 장애로 SYN/ACK가 돌아오지 않을 때 정상 클라이언트의 SYN 재전송이 쌓이면 스캔처럼 보일 수 있습니다. 이 경우 목적지 포트가 하나이고 같은 출발지 포트로 재전송된다는 점이 다릅니다. SYN Flood와의 구분은 위 표의 포트 분포와 출발지 수로 판단합니다.

7. 핵심 정리

SYN Scan은 SYN을 보내고 응답만 확인한 뒤 연결을 완성하지 않는 방식으로, 관리자 권한이 필요합니다.
서비스가 연결을 받아들이지 않아 애플리케이션 로그에 거의 남지 않으므로 네트워크 계층 로그가 핵심입니다.
열린 포트에서는 SYN → SYN/ACK → ACK 없는 RST, 닫힌 포트에서는 RST/ACK 응답이 보입니다.
SYN Flood와는 목적지 포트 분포, 출발지 수, SYN/ACK 이후 동작으로 구분합니다.
대응 우선순위는 열림으로 확인된 포트와 그 포트로의 후속 연결 여부로 정합니다.

changseop lee

코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다