방화벽에 여러 포트를 향한 접속 시도가 쌓여도 그 기록만으로 침입이 성공했다고 판단할 수는 없다. 포트 스캔은 대상의 통신 포트에 탐색 패킷을 보내 응답을 비교하고, 접근 가능한 서비스를 추정하는 행위다. 자산 점검에도 쓰이지만 공격자가 다음 공격 대상을 찾는 데도 활용한다.
관제에서 중요한 것은 접속 시도의 양보다 목적지의 분포, 응답, 관측 위치다. 같은 서버의 여러 포트를 확인했는지, 여러 서버의 같은 포트를 확인했는지, 실제 연결과 후속 행위가 있었는지를 구분해야 한다.
1. 포트가 열려 있다는 판단의 범위
포트 번호는 호스트 안에서 통신을 전달할 서비스의 접점을 구분한다. TCP와 UDP는 별개의 포트 공간을 사용하므로 같은 번호라도 상태가 같다고 볼 수 없다. 또한 포트 번호만으로 실제 서비스의 종류나 버전을 확정할 수 없다.
스캔 결과는 특정 출발지에서 특정 시점에 확인한 접근 가능성이다. 외부에서는 차단된 포트가 내부에서는 접근 가능할 수 있다. 방화벽, 주소 변환, 로드밸런서가 경로에 있다면 관측한 응답이 원본 서버의 상태를 그대로 보여주지 않을 수도 있다.
따라서 열린 포트는 취약점이나 침해 성공과 구분해야 한다. 정상 서비스도 포트를 열고 동작한다. 점검의 초점은 업무에 필요한 서비스인지, 허용해야 할 출발지에만 노출됐는지, 인증과 패치가 적절한지에 있다.
2. TCP와 UDP에서 달라지는 응답 해석
IETF의 RFC 9293이 설명하는 일반적인 TCP 연결 수립은 SYN, SYN/ACK, ACK 순서로 진행된다. SYN은 연결 요청, ACK는 확인을 나타내는 제어 비트다. RST는 연결을 재설정하거나 거절할 때 사용된다.
Nmap 공식 문서에 따르면 SYN 스캔은 연결을 끝까지 수립하지 않고 응답으로 상태를 판별한다. 반면 TCP connect 스캔은 열린 포트에 대한 연결을 수립하므로 서비스 측에 연결 기록이 남을 가능성이 더 크다. SYN 스캔도 네트워크 센서에는 관측될 수 있다.
| 탐색 방식 | 관측한 반응 | 기본적인 해석 |
|---|---|---|
| TCP SYN | SYN/ACK | 열린 포트로 판단 |
| TCP SYN | RST | 닫힌 포트로 판단 |
| TCP SYN | 재시도 뒤에도 무응답 | Nmap은 filtered로 분류 |
| UDP | UDP 응답 | 열린 포트로 판단 |
| UDP | IPv4 ICMP Port Unreachable | 닫힌 포트로 판단 |
| UDP | 재시도 뒤에도 무응답 | Nmap은 open|filtered로 분류 |
UDP는 연결 수립 절차가 없어 무응답만으로 열림과 필터링을 구분하기 어렵다. ICMP 오류의 종류에 따라서도 분류가 달라진다. 위 표는 기본적인 응답 해석이며, 패킷 손실이나 중간 장비의 응답까지 고려해야 한다. filtered를 방화벽 차단이 확정됐다는 뜻으로 읽어서는 안 된다.
3. 탐지의 핵심은 목적지의 분포
한 출발지가 한 서버의 여러 목적지 포트에 접근하는 형태는 수직 스캔, 여러 서버의 같은 목적지 포트에 접근하는 형태는 수평 스캔으로 구분할 수 있다. 전자는 한 자산의 서비스 구성을, 후자는 특정 서비스가 존재하는 자산의 범위를 확인하는 패턴이다.
관제 분석에서는 다음 항목을 함께 비교하는 것이 유용하다.
- 같은 출발지와 목적지 조합에서 나타난 서로 다른 목적지 포트 수
- 같은 출발지와 목적지 포트 조합에서 나타난 서로 다른 목적지 IP 수
- 연결 미완료·거절의 비중과 실제 데이터 교환 여부
- 평소 통신 대상, 승인된 점검 일정, 자산 역할과의 차이
같은 포트로 반복한 재전송을 모두 별개의 탐색으로 세면 장애를 스캔으로 오인하기 쉽다. 재시도하는 업무 프로그램이나 여러 서버를 확인하는 헬스체크도 비슷한 흔적을 만들 수 있다. 패킷 수와 목적지의 다양성은 별도로 계산해야 한다.
짧은 시간 동안 같은 출발지만 보는 규칙은 간격이 긴 탐색이나 여러 출발지에 분산된 패턴을 놓칠 수 있다. 반대로 집계 시간을 무작정 늘리면 정상 업무가 누적돼 오탐이 늘 수 있다. 짧은 구간의 급증과 긴 구간의 분포 변화를 함께 검토하되, 자산 역할에 맞는 기준을 정하는 편이 낫다.
Suricata의 threshold 문서는 시간 구간과 추적 기준에 따른 규칙 매치·경보 제어를 설명한다. 이런 매치 횟수 설정만으로 서로 다른 목적지 포트 수가 자동 집계되는 것은 아니다. 탐지 조건을 검토할 때는 무엇을 한 건으로 세는지부터 확인해야 한다.
4. 장비마다 남는 흔적과 보이지 않는 구간
방화벽에서는 출발지·목적지 주소와 포트, 프로토콜, 허용·차단 결과, 적용 정책을 확인한다. 다만 모든 패킷이나 세션이 기록되는지는 장비 설정에 달려 있다. 차단 기록만 보면 허용된 탐색을 놓칠 수 있고, 세션 종료 시점에 기록하는 구성에서는 확인이 늦어질 수 있다.
네트워크 분석 도구는 연결 상태와 패킷 흐름을 보완한다. Zeek의 연결 로그 필드 문서에서 conn_state의 S0는 연결 시도만 관측하고 응답을 보지 못한 상태, REJ는 연결 시도가 거절된 상태를 뜻한다. 이 값 자체가 스캔 판정은 아니다. 목적지 분포와 시간 흐름을 결합해야 의미가 생긴다.
예를 들어 외부 센서에서는 탐색 패킷이 보이고 방화벽 뒤에서는 보이지 않는다면 차단 결과를 함께 확인할 수 있다. 그러나 내부 센서에 기록이 없다는 사실만으로 차단을 확정해서는 안 된다. 비대칭 경로, 패킷 수집 누락, 센서의 감시 범위도 가능한 원인이다.
애플리케이션 로그에 흔적이 없다는 이유로 탐색 자체를 부정하는 것도 위험하다. 연결이 수립되기 전에 끝난 시도는 애플리케이션 요청 기록까지 도달하지 않을 수 있다. 반대로 연결 기록이 있다는 사실만으로 로그인이나 명령 실행까지 성공했다고 볼 수는 없다.
5. 스캔 경보를 조사로 연결하는 순서
다음은 앞의 원리를 운영에 적용한 분석 절차다. 보편적인 차단 임계값을 제시하기보다 조직의 자산과 업무 맥락을 확인하는 데 목적이 있다.
- 최초·최종 관측 시각, 출발지, 목적지 범위, 프로토콜을 정리하고 장비 간 시각을 맞춘다.
- 목적지 IP 수와 포트 수를 나눠 집계하고 재전송·중복 수집이 결과를 부풀렸는지 확인한다.
- 허용·차단 결과와 응답을 대조해 어느 구간까지 도달했는지 확인한다.
- 승인된 점검 서버·시간·대상 범위와 일치하는지 확인한다. NAT 환경에서는 출발지 IP만으로 실제 단말이나 사용자를 확정하지 않는다.
- 탐색 이후 인증 시도, 취약점 공격 징후, 의심스러운 프로세스 실행이 이어졌는지 조사해 대응 우선순위를 정한다.
MITRE ATT&CK의 T1046은 공격자가 네트워크 서비스를 탐색하는 행위를 다룬다. 내부 단말에서 평소 없던 탐색이 시작됐다면 그 단말의 프로세스와 계정 활동을 함께 확인할 이유가 있다. 다만 탐색 흔적만으로 해당 단말의 감염을 확정하지는 않는다.
승인된 점검도 출발지 IP 전체를 영구 예외 처리하기보다 일정·대상·담당자를 연결해 관리하는 편이 낫다. 점검 서버가 오용되거나 승인 범위를 벗어난 활동을 하는 경우까지 놓치지 않기 위해서다. 인력이 적은 조직은 자산 목록과 점검 일정부터 정리하고, 그 위에 탐지 조건을 보완하는 접근이 현실적이다.
6. 경보 건수보다 확인 가능한 근거를 남긴다
포트 스캔 경보를 처리할 때는 실제 서비스 노출, 승인 여부, 후속 행위를 확인할 수 있어야 한다. 분석 결과에는 “여러 포트 접근을 관측함”, “방화벽 차단을 확인함”, “로그인 성공 여부는 미확인”처럼 관측과 판단의 범위를 구분해 남기는 것이 좋다.
다음 점검에서는 승인된 범위의 테스트 트래픽이 센서·방화벽·관제 화면에 각각 어떻게 남는지 대조해 볼 수 있다. 탐지 기능이 켜져 있다는 사실보다, 필요한 근거를 수집하고 설명할 수 있는지가 운영 품질을 보여준다.