포트·취약점 스캐닝의 해석 | 정보보안기사 필기

1. 포트 상태는 응답을 해석한 관찰값이다

대표 스캐너는 포트를 다음과 같이 세분화할 수 있다.

상태	의미
`open`	응용이 TCP 연결, UDP 데이터그램 등 해당 전송을 받을 수 있다는 응답 근거가 있음
`closed`	호스트와 포트까지 도달했지만 수신 중인 응용이 없다는 응답 근거가 있음
`filtered`	필터링 또는 응답 부재로 open/closed를 판정할 수 없음
`unfiltered`	프로브가 포트까지 도달한 것으로 보이나 open/closed는 판정하지 못함
`open\|filtered`	응답 부재 때문에 open과 filtered를 구분하지 못함
`closed\|filtered`	특수한 방식에서 closed와 filtered를 구분하지 못함

closed는 “호스트가 안전하다”는 뜻이 아니다. 해당 시점에 해당 포트에 수신 중인 서비스가 없다는 의미다. 다른 포트·프로토콜·내부 경로·클라이언트 취약점은 별도 문제다.

filtered도 “방화벽이 완벽하게 보호한다”는 뜻이 아니다. 특정 프로브에 대해 판정할 수 없었다는 뜻이며, 다른 출발지·프로토콜·허용 규칙·응용 경로에서는 결과가 달라질 수 있다.

2. TCP Connect Scan과 SYN Scan

TCP Connect Scan

TCP Connect Scan은 운영체제의 일반 connect() 기능으로 완전한 TCP 연결을 시도한다.

열린 포트

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

Scanner → Target : SYN
Scanner ← Target : SYN+ACK
Scanner → Target : ACK
연결 수립 후 종료

닫힌 포트

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

Scanner → Target : SYN
Scanner ← Target : RST 또는 RST+ACK

장점은 일반 사용자 권한에서도 구현하기 쉽고 운영체제의 TCP 처리를 이용해 결과가 명확하다는 점이다. 단점은 연결을 실제로 완성하므로 서비스 로그, 접근 로그, 인증 전 단계 로그에 더 쉽게 남을 수 있고 응용에 더 많은 상호작용을 만들 수 있다는 점이다.

TCP SYN Scan

SYN Scan은 3-way handshake의 첫 단계인 SYN을 보내고 응답을 확인한 뒤 정상 응용 세션까지 완성하지 않는다. 흔히 half-open scan이라고 부른다.

대상 응답	일반적 해석
`SYN+ACK`	`open`
`RST` 또는 `RST+ACK`	`closed`
반복 후 응답 없음	`filtered` 가능성
관리적 차단 등을 나타내는 ICMP 오류	`filtered`

열린 포트에서 SYN+ACK를 받으면 스캐너 측은 대개 RST로 연결 시도를 정리한다. 마지막 ACK를 보내 응용 세션을 정상 수립하지 않았다는 뜻이지 탐지되지 않는다는 뜻은 아니다. 방화벽·IDS·호스트 로그는 짧은 시간에 반복되는 SYN, 낮은 handshake 완료율, 여러 목적지 포트 패턴을 탐지할 수 있다.

3. UDP Scan은 무응답 해석이 어렵다

UDP에는 TCP와 같은 연결 handshake가 없다. 스캐너가 UDP 데이터그램을 보낸 뒤 얻는 대표 결과는 다음과 같다.

응답	일반적 해석
대상 포트의 UDP 응답	`open`
ICMP Destination Unreachable - Port Unreachable	`closed`
다른 종류의 도달 불가·관리적 차단 ICMP	`filtered`
반복 후 아무 응답 없음	`open\|filtered`

열린 UDP 서비스가 빈 데이터그램이나 형식이 틀린 요청에 아무 답도 하지 않을 수 있다. 방화벽도 조용히 패킷을 버릴 수 있다. 따라서 무응답만으로 open과 filtered를 구분할 수 없다.

프로토콜에 맞는 요청을 사용하면 응답 가능성을 높일 수 있지만, 다음 한계가 남는다.

서비스가 인증된 요청에만 응답할 수 있다.
ICMP 오류에 rate limit이 적용되어 closed 포트도 늦게 판정될 수 있다.
UDP 응답이 중간 방화벽이나 NAT에서 차단될 수 있다.
서비스별 메시지 형식이 달라 하나의 범용 payload로 모두 확인하기 어렵다.

따라서 UDP 무응답 = 열린 포트 또는 UDP 무응답 = 방화벽 차단으로 단정하지 않는다.

4. FIN·NULL·Xmas Scan의 원리와 한계

이 방식들은 정상 연결의 SYN이 아닌 비정상적인 TCP flag 조합을 보낸 뒤 응답을 관찰한다.

FIN Scan: FIN 설정
NULL Scan: 주요 제어 flag를 설정하지 않음
Xmas Scan: FIN·PSH·URG 등을 함께 설정

일부 TCP 구현은 닫힌 포트에 이러한 세그먼트가 오면 RST를 보내고, 열린 포트에서는 응답하지 않는다. 이 경우 다음처럼 해석한다.

응답	일반적 해석
RST	`closed`
응답 없음	`open\|filtered`
관리적 차단 ICMP	`filtered`

그러나 모든 운영체제와 장비가 같은 방식으로 반응하지 않는다. 열린 포트에도 RST를 보내는 구현이 있고, 현대 stateful firewall과 IDS는 이러한 비정상 flag 패턴을 탐지·차단할 수 있다. 따라서 다음 표현은 틀리다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

FIN·NULL·Xmas Scan은 어떤 운영체제에서도 정확하다.  → 틀림
SYN이 없으므로 방화벽과 IDS에 보이지 않는다.       → 틀림
무응답이면 반드시 열린 포트다.                     → 틀림

이 기법의 핵심은 “비정상 flag에 대한 TCP stack의 반응 차이”이지, 보편적인 은폐 수단이 아니다.

5. ACK Scan은 열린 포트를 찾는 방식이 아니다

ACK Scan은 ACK flag를 설정한 패킷을 보내 필터링 정책의 단서를 얻는 데 사용된다.

응답	일반적 해석
RST	`unfiltered`
응답 없음 또는 특정 ICMP 차단 응답	`filtered`

TCP stack은 open·closed 포트 모두에서 예상하지 못한 ACK에 RST를 보낼 수 있다. 따라서 ACK Scan에서 RST가 왔다고 그 포트가 열린 것은 아니다. 이 방식은 주로 해당 방향의 패킷이 필터를 통과하는지, stateful 정책이 어떻게 보이는지를 추정하는 데 사용한다.

6. 포트 스캔과 취약점 스캔의 차이

구분	포트·서비스 스캔	취약점 스캔
핵심 질문	어떤 호스트·포트·서비스가 응답하는가?	알려진 약점·오구성·패치 누락 후보가 있는가?
주요 입력	IP, 프로토콜, 포트, probe	자산·서비스·버전·설정·자격증명·취약점 DB
주요 출력	open/closed/filtered, 서비스·버전 추정	취약점 ID·근거·심각도·권고·확신 수준
상호작용	비교적 적은 패킷부터 서비스 probe까지	더 많은 요청, plugin·정책·credential 검사 가능
한계	취약점 존재를 직접 확정하지 못함	오탐·미탐, 위험도 맥락 부족, 운영 영향 가능

포트 스캐너는 “노출된 문과 표지판”을 찾는 데 가깝고, 취약점 스캐너는 “그 문과 내부 구성에 알려진 약점 후보가 있는지”를 점검한다. 어느 쪽도 결과 해석을 자동으로 끝내 주지 않는다.

7. 스캐닝 징후를 로그와 패킷에서 찾는다

대표 관찰값

단일 source가 짧은 시간에 많은 destination port로 SYN 전송
여러 destination host의 같은 port로 반복 접속
SYN 대비 ACK 완료율이 낮고 RST가 다수 발생
ICMP Port Unreachable, administratively prohibited 응답 증가
존재하지 않는 주소·포트에 일정한 간격의 probe
FIN·NULL·Xmas 같은 비정상 flag 조합
서비스 banner·version probe로 보이는 짧은 연결 반복
여러 source가 대상을 나누어 천천히 확인하는 분산 패턴

가상 로그 해석 예시

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

10:00:01  SRC 203.0.113.50 → DST 192.0.2.20:21   SYN  denied
10:00:01  SRC 203.0.113.50 → DST 192.0.2.20:22   SYN  allowed, RST
10:00:02  SRC 203.0.113.50 → DST 192.0.2.20:23   SYN  denied
10:00:02  SRC 203.0.113.50 → DST 192.0.2.20:25   SYN  denied
10:00:03  SRC 203.0.113.50 → DST 192.0.2.20:53   SYN  denied

짧은 시간에 한 목적지의 여러 포트를 순서대로 확인했으므로 수직 TCP 스캔 가능성이 있다. 그러나 다음을 확인하기 전에는 악성으로 확정하지 않는다.

203.0.113.50이 승인된 취약점 스캐너 주소인가?
해당 시간이 정기 점검 창인가?
대상 범위와 포트가 승인 계획에 포함되는가?
실제 연결 완료·인증 시도·취약 요청까지 이어졌는가?
동일 source가 다른 자산에서도 같은 패턴을 만드는가?

8. 스캐닝과 취약점 노출에 대한 대응

공격 표면을 줄인다

사용하지 않는 서비스와 포트를 종료한다.
관리 포트는 인터넷에 직접 노출하지 않고 관리망·VPN·allowlist로 제한한다.
host firewall과 network firewall에서 필요한 source·destination·protocol·port만 허용한다.
네트워크를 역할별로 분리하고 lateral movement 경로를 제한한다.
기본 계정·불필요한 기능·약한 암호 프로토콜을 제거한다.
서비스와 운영체제를 패치하고 취약한 버전을 교체한다.

배너 숨김은 정보 노출을 줄일 수 있지만 패치·접근제어를 대체하지 않는다. 제품명이 보이지 않아도 응답 특성과 취약 행동으로 식별될 수 있다.

탐지와 차단을 계층적으로 적용한다

위치	역할
경계 방화벽	불필요한 inbound 접근 차단, 관리 포트 제한, deny 로그 생성
host firewall	서버 역할에 맞는 최소 포트만 허용, 내부 스캔 경로 통제
IDS/IPS/NDR	포트 다양성, 비정상 flag, 반복 probe, service fingerprint 패턴 탐지
SIEM	방화벽·서버·스캐너·자산 정보를 시간축으로 상관분석
취약점 관리	승인 스캔 결과를 자산·패치·예외·재점검과 연결

모든 스캔을 즉시 source IP 하나로 영구 차단하는 방식은 한계가 있다. 분산 출발지, 클라우드 주소 변경, 정상 연구·점검, NAT 사용자를 오탐할 수 있다. 악성 의도가 명확하면 차단하되, 자산 노출과 근본 취약점도 함께 줄여야 한다.