📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 207편
이전 글: 206. Ping Scan · 다음 글: 208. SYN Scan
1. 개념
TCP Connect Scan 은 운영체제의 일반 연결 기능(connect 시스템 호출)을 사용해 각 포트에 3-Way Handshake를 끝까지 완료해 보고, 연결 성공 여부로 포트 상태를 판단하는 방식입니다. 관리자 권한이 필요 없어서 일반 사용자 권한으로 실행된 스캔 도구의 기본 방식이 되는 경우가 많습니다(203. Nmap이란 무엇인가).
방어자에게 이 방식의 특징은 흔적이 가장 많이 남는다는 점입니다. 연결이 실제로 수립되므로 방화벽의 허용 세션, 대상 서비스의 접속 기록, 호스트의 연결 감사 로그까지 남습니다. 패킷 모양 자체는 143. SYN Scan Packet 분석에서 SYN 방식과 비교했으므로, 이 글은 로그에 남는 흔적에 집중합니다.
| 항목 | TCP Connect Scan |
|---|---|
| 필요 권한 | 일반 사용자 |
| 열린 포트 | SYN → SYN/ACK → ACK 완료 후 곧바로 종료 |
| 닫힌 포트 | SYN → RST/ACK |
| 필터링 | 무응답(재전송) 또는 ICMP Unreachable |
| 서비스 로그 | 짧은 연결 기록이 남을 수 있음 |
2. 동작 원리
[열린 포트 22]
스캐너 ── SYN ──────────→ 서버
스캐너 ←── SYN/ACK ─────── 서버
스캐너 ── ACK ──────────→ 서버 ← 연결 수립 (서비스 프로세스가 accept)
스캐너 ── RST 또는 FIN ─→ 서버 ← 데이터 없이 즉시 종료 (구현에 따라 다름)
↓
방화벽: 허용 세션 생성·종료 기록 (전송 바이트 극소, 지속 시간 거의 0)
서비스: "데이터 없이 끊긴 연결" 기록 가능
[닫힌 포트 23]
스캐너 ── SYN ──→ 서버, 스캐너 ←── RST/ACK ── 서버
↓
방화벽: 허용 정책이면 세션 시도 기록, 차단 정책이면 DROP 기록연결이 수립되면 서버의 서비스 프로세스가 연결을 받아들이므로, SSH처럼 연결 직후 배너를 보내는 서비스는 서버가 먼저 몇십 바이트를 보낸 뒤 끊기는 모양이 됩니다.
3. 주요 특징
| 흔적 위치 | 열린 포트에서 남는 것 | 닫힌·차단 포트에서 남는 것 |
|---|---|---|
| 방화벽 세션 로그 | 허용 세션, 바이트 극소, 지속 시간 0~1초 | 차단(DROP/REJECT) 이벤트 |
| 서비스 로그 | 인증·요청 없이 끊긴 연결 | 없음 |
| Zeek conn.log | 연결 수립 후 데이터 0에 가까움 | conn_state REJ(RST 응답), S0(무응답) |
| 호스트 감사 로그 | Windows 이벤트 5156(연결 허용, 감사 정책 설정 시) | 5152·5157(차단, 감사 정책 설정 시) |
- SYN 방식과의 구분: 열린 포트에서 세 번째 패킷이 ACK이면 Connect 방식, RST이면 SYN 방식입니다. 로그만 볼 때는 "허용 세션이 생성되었는가"로 판단할 수 있습니다(208. SYN Scan).
- 출발지 포트가 연결마다 바뀝니다. 운영체제가 일반 연결처럼 임시 포트를 할당하므로, 정상 클라이언트와 출발지 포트 모양이 비슷합니다. 판단은 목적지 포트 수와 세션당 데이터로 합니다.
- 서비스 로그가 핵심 증거가 됩니다. 스캔 흔적이 방화벽에서 누락되더라도 대상 서버의 서비스 로그에 짧은 연결이 남아 있을 수 있습니다.
4. 예시
실습 예시 — 본인 소유 실습망 서버에서 Connect 방식 흔적을 찾는 방어 측 명령입니다. 값은 환경마다 다릅니다.
# sshd 로그에서 인증 없이 끊긴 연결 확인
# Rocky: /var/log/secure 또는 journalctl -u sshd Ubuntu: /var/log/auth.log 또는 journalctl -u ssh
sudo journalctl -u sshd --since "1 hour ago" | grep -Ei "preauth|identification|kex_exchange"
# Zeek를 운영하는 경우: 출발지별 REJ(닫힌 포트) 연결 수
zeek-cut id.orig_h id.resp_p conn_state < conn.log | awk '$3=="REJ" {print $1}' | sort | uniq -c | sort -rnsshd 로그 형식 예시(OpenSSH 버전에 따라 문구가 다름, 값은 환경마다 다름):
sshd[2210]: Connection closed by 192.168.10.50 port 51844 [preauth]
sshd[2213]: kex_exchange_identification: Connection closed by remote host방화벽 세션 로그 형식 예시(장비마다 필드명이 다름):
action=allow src=192.168.10.50 sport=51844 dst=192.168.10.20 dport=22 bytes=180 duration=0
action=allow src=192.168.10.50 sport=51846 dst=192.168.10.20 dport=80 bytes=120 duration=0
action=deny src=192.168.10.50 sport=51848 dst=192.168.10.20 dport=445 bytes=0 duration=0| 관찰 | 해석 |
|---|---|
| 허용 세션이 수 초 안에 여러 포트 | 여러 서비스에 연결만 해 봄 |
| bytes 극소, duration 0 | 데이터 교환 없음 |
| sshd preauth 종료 | 인증 시도 전 끊김 → 서비스 존재 확인 목적 가능 |
5. 보안 관점
- Connect 방식은 흔적이 많아 탐지는 쉽지만, 일반 사용자 권한으로 실행되므로 관리자 권한이 없는 감염 단말에서도 발생할 수 있습니다. 내부 단말에서 이 흔적이 보이면 스캔 도구를 실행한 프로세스를 추적해야 합니다.
- 서비스가 연결을 실제로 받아들이므로, 서비스의 동시 연결 한도가 낮거나 연결 처리 비용이 큰 경우 대량 스캔만으로도 부하가 생길 수 있습니다.
- 서비스 로그에 짧은 연결이 반복되고 이어서 인증 실패가 쌓이면 스캔 → 무차별 대입으로 넘어간 흐름일 수 있습니다(233. Brute Force와 Scan 구분).
6. SOC 관점
관제자가 확인할 질문
- 같은 출발지가 짧은 시간에 몇 개의 서로 다른 목적지 포트로 허용 세션을 만들었는가?
- 허용 세션들의 바이트 수와 지속 시간은 정상 서비스 이용과 비교해 어떤가?
- 대상 서비스 로그에 인증·요청 없이 끊긴 기록이 같은 시간대에 있는가?
- 내부 출발지라면 EDR에서 어떤 프로세스가 연결을 만들었는가?
오탐 주의: 로드밸런서·모니터링의 TCP 헬스체크는 "연결 후 즉시 종료"라는 같은 모양을 만듭니다. 차이는 고정된 소수 포트, 일정한 주기, 등록된 출발지입니다. 또 연결이 많은 클라이언트가 서버 장애로 연결 직후 끊기는 경우도 비슷해 보이므로, 목적지 포트가 여러 개인지부터 확인합니다.
7. 핵심 정리
- TCP Connect Scan은 운영체제 연결 기능으로 Handshake를 완료한 뒤 곧바로 끊어 포트 상태를 확인합니다.
- 관리자 권한이 필요 없어 일반 사용자 권한 스캔의 기본 방식이 되는 경우가 많습니다.
- 열린 포트마다 방화벽 허용 세션과 서비스 로그의 짧은 연결이 남아 흔적이 가장 많습니다.
- 세 번째 패킷이 ACK인지 RST인지, 허용 세션이 생성되었는지로 SYN 방식과 구분합니다.
- 헬스체크와는 포트 수·주기·출발지로 구분하고, 스캔 후 인증 실패가 이어지는지 확인합니다.
