포트 스캔은 응답한 호스트에서 어떤 포트가 열려 있거나 필터링되는지, 어떤 서비스가 응답하는지를 파악합니다. 취약점 스캔은 운영체제·응용 프로그램·버전·패치·구성 정보를 알려진 취약점 자료와 대조해 취약점 후보를 찾으려는 검사입니다.
포트가 열렸다는 사실만으로 취약점이 확정되지는 않습니다. 서비스 식별도 배너나 기본 포트 추정에 의존할 수 있고, 취약점 스캐너의 결과에도 오탐·미탐 가능성이 있습니다. 아래 사례와 연습문제는 교육용으로 새로 만든 것이며 공식 기출이나 판매 카드 문항이 아닙니다.
포트 스캔은 통신 창구와 응답을 살핍니다
NIST SP 800-115은 포트·서비스 식별을 사용해 응답 호스트의 포트와 서비스, 때로는 서비스가 실행하는 응용 프로그램까지 알아보는 기법으로 설명합니다. 이 글에서 ‘포트가 열려 있다’는 말은 점검 시점과 관측 위치에서 스캐너가 해당 포트의 응답을 열린 상태로 분류했다는 뜻입니다. 항상 인터넷 전체에서 접근 가능하다거나 그 포트의 서비스가 안전하지 않다는 뜻은 아닙니다. 방화벽과 네트워크 경로가 다르면 같은 포트가 다른 상태로 보일 수 있고, 꺼져 있거나 응답이 막힌 장비는 목록에서 빠질 수 있습니다. 포트 번호에 익숙한 서비스 이름을 붙이는 일도 실제 서비스를 확인하는 일과 같지 않습니다. 포트 80이라고 해서 언제나 표준 웹 서버가 있다고 단정하지 말고, 점검 도구가 어떤 응답을 근거로 서비스나 버전을 적었는지 살펴야 합니다.
취약점 스캔은 식별 정보를 알려진 약점과 대조합니다
취약점 스캐너는 호스트와 포트도 찾아낼 수 있지만, 그 정보에 더해 운영체제·주요 응용 프로그램·버전 등을 취약점 데이터베이스의 알려진 정보와 비교합니다. 패치 누락이나 잘못된 구성을 표시할 수도 있습니다. 따라서 두 검사는 완전히 별개 도구라고만 볼 수 없습니다. 포트·서비스 식별이 취약점 스캔의 입력이 되기도 하고, 한 제품이 두 작업을 함께 수행하기도 합니다. 구별해야 할 것은 프로그램 이름이 아니라 결과가 말하는 내용입니다. ‘443/tcp 응답’은 관측한 네트워크 상태에 관한 결과입니다. ‘특정 구성요소가 취약 버전과 일치할 수 있음’은 자산 특성과 알려진 취약점 정보를 대조한 후보입니다. 후자는 영향을 받는 정확한 버전, 실제 설치 구성, 패치 여부, 취약 코드의 사용 여부를 추가 확인해야 합니다. NIST 문서는 취약점 스캔의 알려진 취약점 식별 기능과 함께 오탐 가능성도 명시합니다. OWASP가 설명하는 DAST는 실행 중인 웹 애플리케이션의 인터페이스에 요청을 보내는 앱 검사입니다. 이 사례는 검사 층위가 여러 가지임을 보여 주지만, DAST의 결과를 포트 상태와 같은 것으로 볼 수는 없습니다.
가상 서버 점검표에서 확인 수준을 나눠 봅니다
| 관찰 결과 | 여기까지 말할 수 있는 내용 | 아직 말할 수 없는 내용 |
|---|---|---|
| 외부 점검 위치에서 TCP 443 응답 | 그 위치·시점의 점검에서 443 포트가 응답함 | 내부망에서도 같은 상태인지, 어떤 서비스인지 확정 |
| TLS 웹 서비스로 보이는 응답과 버전 문자열 | 서비스 식별기가 특정 웹 서버 버전을 보고함 | 문자열이 진짜 버전인지, 취약 코드가 작동하는지 확정 |
| 스캐너가 오래된 구성요소 취약점 후보 표시 | 도구의 지식베이스와 관측 정보가 후보로 일치함 | 해당 구성요소가 실제로 취약 상태인지 확정 |
| 담당자가 설치 버전·패치·설정과 영향 조건 확인 | 확인한 자산과 조건에 한정한 분석 근거를 기록할 수 있음 | 확인하지 않은 다른 호스트까지 같은 결론을 확대 |
이 표를 읽을 때는 각 행이 어떤 질문에 답하는지 보세요. 첫 행은 연결 상태, 둘째는 서비스 식별, 셋째는 알려진 취약점과의 대조, 마지막 행은 맥락 확인입니다. 한 단계의 결과를 다음 단계의 확정 결론으로 바꾸면 근거가 점프합니다. 보고서에는 점검 날짜와 위치, 대상 범위, 도구가 관측한 사실, 추가로 확인한 사항을 구분해 쓰는 편이 정확합니다.
결과를 읽을 때는 네 단계를 따라갑니다
- 먼저 대상과 관측 조건을 확인합니다. 어떤 주소 범위, 네트워크 위치, 시간에 얻은 결과인지 모르면 ‘열려 있다’의 범위도 모릅니다.
- 포트 상태와 서비스 식별을 분리합니다. 열린 포트는 응답 상태이며, 서비스명과 버전은 별도 식별 근거가 있는지 확인합니다.
- 취약점 후보는 어떤 자산 속성·버전·패치·구성 정보와 어떤 알려진 자료가 맞물렸는지 확인합니다.
- 마지막으로 실제 자산의 구성과 취약 조건을 대조하고, 확인하지 못한 내용은 후보·미확인으로 남깁니다.
흔한 실수는 열린 포트에서 곧바로 취약점을 결론내는 것입니다
‘443이 열려 있으니 서버가 취약하다’는 문장은 포트 상태와 취약점 판단을 섞었습니다. 안전한 서비스도 443에서 응답할 수 있고, 취약점 여부는 구성요소·버전·패치·설정 등 별도 조건을 봐야 합니다. 반대로 포트 스캔에서 보이지 않았다고 취약점이 없다고 말할 수도 없습니다. 필터링, 네트워크 경로, 응답 제한으로 관측되지 않았을 수 있기 때문입니다. 또 스캐너가 자동으로 서비스나 버전을 알아냈다고 해도 배너가 수정되거나 서비스가 비표준 포트에서 동작할 수 있습니다. NIST 가이드는 2008년 발행된 기술 문서이므로 여기서는 기법의 목적을 이해하는 근거로만 사용했습니다. 최신 제품의 동작이나 국내 기준의 공식 정의를 보장하는 자료로 확대하지 않습니다.
회상 연습: 결과 문장을 어디까지 고칠까요?
예시 답: ‘점검 위치에서 TCP 443이 응답했고, 취약점 스캐너가 관측한 서비스 정보와 알려진 자료를 대조해 취약점 후보를 표시했다. 실제 영향 여부는 대상 버전·패치·구성 및 취약 조건을 추가 확인해야 한다.’ 이 답은 포트 응답, 스캐너의 결과, 미확정인 영향 판단을 차례로 분리합니다. 질문을 받으면 먼저 관측 사실을 적고, 그 다음 도구가 수행한 대조를 설명한 뒤, 추가 확인이 필요한 조건을 밝혀 보세요. 세 부분이 섞이지 않으면 근거를 넘지 않는 단답을 만들 수 있습니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
포트 스캔에서 22/tcp가 응답했다는 사실만으로 SSH 취약점이 확인되었다고 쓸 수 없는 이유를 답하시오.
정답과 해설 확인
22/tcp 응답은 점검 위치와 시점의 포트 상태를 보여 줄 뿐이다. 취약점 여부는 실제 서비스·버전·패치·구성 및 취약 조건을 별도로 대조해야 한다.NIST SP 800-115은 포트·서비스 식별과 취약점 스캔을 구분하고, 서비스 식별은 추정이나 배너에 의존할 수 있으며 취약점 스캔도 알려진 취약점 자료와의 대조 결과라고 설명한다.