
Nmap
Network Mapper · 엔맵
은 네트워크 호스트·포트·서비스의 응답을 관찰해 노출 상태를 식별하는 도구다. 열린 포트와 추정 버전은 조사 단서이며 취약점이 실제로 성립한다는 결론과는 다르다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
로고: Nmap project 공식 자료. 제품 식별을 위해 표시하며 각 상표의 권리는 권리자에게 있습니다.
01무엇이고, 어떤 일을 하나
- 허가된 범위의 노출 포트와 필터링 상태를 파악한다.
- 와 응답 패턴으로 서비스 후보를 좁힌다.
- 발견 자료를 제품 권고·설정·후속 검증에 연결한다.
02어떤 순서로 동작하나
- 도달·포트 상태 관찰
SYN/ACK·RST··무응답을 캡처 위치와 함께 읽는다. 무응답에는 필터·손실·프로토콜 조건이 섞일 수 있다.
- 프로토콜 식별
서비스 와 응답 패턴을 비교한다. 먼저 배너를 보내는 서비스와 요청 이후 응답하는 서비스를 구분한다.
- 제품·버전 근거 수집
배너와 스택 특성 등 서로 다른 단서를 연결한다. 프록시·호환 구현·변경 배너로 인한 오판 가능성을 남긴다.
- 취약 조건 대조
CVE·제품 권고·패치와 실제 기능·설정을 대조한다. 버전 문자열만으로 backport나 비활성 기능을 무시하지 않는다.
- 영향·수정·재시험 기록
관찰 사실과 추정을 나누고 동일 조건에서 수정 효과를 다시 확인할 수 있는 보고서를 작성한다.
03먼저 알아둘 용어와 구성요소
- 해당 스캔 방식에서 연결 또는 응답을 제공하는 서비스가 관찰된 상태.
- 필터링 등의 이유로 포트의 개방 여부를 판정하기 어려운 상태.
- 서비스를 식별하기 위해 보내는 정해진 시험 입력.
- Scripting Engine으로 확장된 발견·검사 기능을 제공하는 구성 요소.
- 응답은 관찰되지만 해당 방식에서 수신 대기 서비스가 없는 것으로 판정된 상태.
- 무응답 등으로 열림과 필터링을 구별하지 못한 상태.
- 시험 입력의 응답 특징으로 프로토콜·제품·버전 후보를 추정하는 절차.
FTP 배너와 HTTP 응답에서 서비스 식별 근거 만들기
포트 열림·서비스 식별·취약점 확인을 다른 증거 단계로 나눈다.
실습 구성과 전제
- 허가된 격리 장비에서 얻은 PCAP를 작업 사본으로 연다.
- 사진 속 주소에 다시 접속하지 않고 저장된 요청·응답을 읽는다.
연결 확인과 서비스 대화를 구분한다
- 사진에서는 초기 SYN·SYN/ACK 뒤 RST가 있는 연결과, 별도 출발지 포트로 3-way handshake를 완료한 연결이 이어진다.
- 포트 응답은 서비스가 대화할 수 있는 후보임을 보여 준다. 실제 서비스 식별은 연결 안의 배너나 응답 내용으로 보완한다.
원본 크기로 보기 ↗- 21번 포트 연결에서 220 응답과 vsFTPd 3.0.5 문자열이 보인다.
- 초기 확인 연결과 배너를 받은 연결의 출발지 포트가 다르다. 한 TCP 연결로 합치면 순서 해석이 틀린다.
확인 기준5튜플과 .stream을 기준으로 연결을 분리한다.
응답 헤더를 제품 정보의 후보로 읽는다
- HTTP의 Server와 X-Powered-By는 노출된 문자열이지 패키지 패치 상태 전체가 아니다. 관리자가 감추거나 변경할 수 있으며 배포판은 보안 패치를 백포트할 수 있다.
- 응답 상태와 제품 후보·버전을 적고, 그에 대응하는 공식 권고와 설치 패키지 정보를 별도로 확인한다.
원본 크기로 보기 ↗- GET / HTTP/1.0에 HTTP/1.1 200 OK가 돌아오고 Server·X-Powered-By 헤더가 표시된다.
- 후속 연결도 계속 나타나며 요청 종류에 따라 연결이 새로 생성됨을 볼 수 있다.
확인 기준버전 문자열 하나만으로 CVE 영향 여부를 확정하지 않는다.
발견 사항을 재시험 가능한 형태로 적는다
- 증거에는 대상 역할·허가 범위·도구 버전·시각·포트·응답 필드·판단 한계를 남긴다. 서비스 노출과 실제 취약 기능을 분리한다.
- 조치 후에는 같은 조건의 응답과 패키지 상태를 확인하고 정상 서비스가 유지되는지도 시험한다.
texttcp.port == 21 || http.response Follow → TCP Stream표시 필터와 연결 재조립 기능으로 저장된 PCAP를 조회한다.
확인 기준'취약함' 대신 현재 증거로 확정할 수 있는 문장을 쓴다.
실습에서 확인한 동작 원리
- 배너는 서비스 식별의 증거지만 취약점 성공 증거는 아니다.
- 서로 다른 출발지 포트의 연결은 분리해서 읽는다.
04예제로 따라가기
- 관찰 값: 가상 서비스 응답에 제품 이름과 버전 2.4가 보였다고 가정한다. 우선 응답 원문·포트·시각· 조건을 보존한다.
- 식별 수준: 이 제품을 식별했는지, 단지 프로토콜 계열만 추정했는지 구분한다. 프록시가 대신 반환한 배너일 가능성도 남긴다.
- 설치 대조: 권한 있는 점검 환경에서 실제 패키지 버전·빌드·공급자 정보를 대조한다. 배너가 설치 상태와 다르면 추정 결과를 수정한다.
- 조건 확인: 제품 권고의 영향 버전·기능 활성화·설정·패치 정보를 비교한다. 같은 표기 버전이라도 배포판의 보안 패치가 다를 수 있다.
- 결론 범위: 조건이 미확인이라면 취약 확정 대신 추가 확인이 필요한 후보로 기록한다. 서비스 발견·제품 식별·취약 검증을 별도 결과로 남긴다.
05혼동하기 쉬운 점과 확인 기준
- 시간 예산: 대기시간과 실제 서버 응답시간을 비교한다. timeout은 응답 부재를 관찰한 것이며 서비스 부재와 같지 않다.
- 중간 장비: ··프록시가 재설정·오류 페이지·속도 제한을 반환했는지 센서 위치별 패킷을 비교한다.
- 상태 의존: SNI·가상 호스트·인증·연결 순서가 응답을 바꾸는지 본다. 다른 상태의 결과를 같은 요청으로 취급하지 않는다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.