개념 사전 · 관리체계

취약점 진단

Vulnerability assessment · 취약점 평가 · 취약점 점검

은 허가된 범위의 자산·설정·기능을 조사해 재현 가능한 보안 약점을 확인하고 개선 근거를 만드는 과정이다. 발견·추정·실제 영향 확인을 서로 다른 결론으로 기록한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

  • 대상·권한·시간·허용 행위의 범위를 정한다.
  • 자동 도구의 후보를 구성·응답·권한 조건과 대조한다.
  • 재현 조건과 수정 후 재시험 방법을 전달한다.

02어떤 순서로 동작하나

  1. 도달·포트 상태 관찰

    SYN/ACK·RST··무응답을 캡처 위치와 함께 읽는다. 무응답에는 필터·손실·프로토콜 조건이 섞일 수 있다.

  2. 프로토콜 식별

    서비스 probe와 응답 패턴을 비교한다. 먼저 배너를 보내는 서비스와 요청 이후 응답하는 서비스를 구분한다.

  3. 제품·버전 근거 수집

    배너와 스택 특성 등 서로 다른 단서를 연결한다. 프록시·호환 구현·변경 배너로 인한 오판 가능성을 남긴다.

  4. 취약 조건 대조

    CVE·제품 권고·패치와 실제 기능·설정을 대조한다. 버전 문자열만으로 backport나 비활성 기능을 무시하지 않는다.

  5. 영향·수정·재시험 기록

    관찰 사실과 추정을 나누고 동일 조건에서 수정 효과를 다시 확인할 수 있는 보고서를 작성한다.

03먼저 알아둘 용어와 구성요소

시험이 허가된 대상·기능·기간·행동의 범위.
증거와 조건을 갖춘 진단 결과 항목.
결론을 지지하는 설정·요청·응답·로그 등의 자료.
수정 뒤 같은 조건으로 재현 여부와 정상 기능을 다시 확인하는 작업.
LEARN THROUGH PRACTICE

FTP 배너와 HTTP 응답에서 서비스 식별 근거 만들기

포트 열림·서비스 식별·취약점 확인을 다른 증거 단계로 나눈다.

실습 구성과 전제

  • 허가된 격리 장비에서 얻은 서비스 탐지 PCAP를 작업 사본으로 연다.
  • 사진 속 주소에 다시 접속하지 않고 저장된 요청·응답을 읽는다.
  1. 연결 확인과 서비스 대화를 구분한다

    • 사진에서는 초기 SYN·SYN/ACK 뒤 RST가 있는 연결과, 별도 출발지 포트로 3-way handshake를 완료한 연결이 이어진다.
    • 포트 응답은 서비스가 대화할 수 있는 후보임을 보여 준다. 실제 서비스 식별은 연결 안의 배너나 응답 내용으로 보완한다.
    Nmap 스캔 응답과 포트 판독 · Version/OS 스캔 실습원본 크기로 보기 ↗
    • 21번 포트 연결에서 220 응답과 vsFTPd 3.0.5 문자열이 보인다.
    • 초기 확인 연결과 배너를 받은 연결의 출발지 포트가 다르다. 한 TCP 연결로 합치면 순서 해석이 틀린다.
    확인 기준

    5튜플과 .stream을 기준으로 연결을 분리한다.

  2. 응답 헤더를 제품 정보의 후보로 읽는다

    • HTTP의 Server와 X-Powered-By는 노출된 문자열이지 패키지 패치 상태 전체가 아니다. 관리자가 감추거나 변경할 수 있으며 배포판은 보안 패치를 백포트할 수 있다.
    • 응답 상태와 제품 후보·버전을 적고, 그에 대응하는 공식 권고와 설치 패키지 정보를 별도로 확인한다.
    Nmap 스캔 응답과 포트 판독 · Version/OS 스캔 실습원본 크기로 보기 ↗
    • GET / HTTP/1.0에 HTTP/1.1 200 OK가 돌아오고 Server·X-Powered-By 헤더가 표시된다.
    • 후속 연결도 계속 나타나며 요청 종류에 따라 연결이 새로 생성됨을 볼 수 있다.
    확인 기준

    버전 문자열 하나만으로 CVE 영향 여부를 확정하지 않는다.

  3. 발견 사항을 재시험 가능한 형태로 적는다

    • 증거에는 대상 역할·허가 범위·도구 버전·시각·포트·응답 필드·판단 한계를 남긴다. 서비스 노출과 실제 취약 기능을 분리한다.
    • 조치 후에는 같은 조건의 응답과 패키지 상태를 확인하고 정상 서비스가 유지되는지도 시험한다.
    text
    tcp.port == 21 || http.response
    Follow → TCP Stream

    표시 필터와 연결 재조립 기능으로 저장된 PCAP를 조회한다.

    확인 기준

    '취약함' 대신 현재 증거로 확정할 수 있는 문장을 쓴다.

실습에서 확인한 동작 원리

  • 배너는 서비스 식별의 증거지만 취약점 성공 증거는 아니다.
  • 서로 다른 출발지 포트의 연결은 분리해서 읽는다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 열린 22/ 포트는 SSH 서비스 후보의 단서지만 모든 SSH 취약점에 영향받는다는 결과는 아니다.
  • 정상 계정과 다른 소유자의 문서를 비교하는 경우 요청 ID·권한·문서 소유·응답 범위를 함께 기록한다.
  • 수정 뒤 공격 조건이 거부되어도 정상 사용자의 동일 기능이 실패하면 수정의 완성도를 다시 평가한다.

05혼동하기 쉬운 점과 확인 기준

  • 자동 스캐너의 발견 문구를 제품 버전·설정·실제 증거 없이 그대로 확정 결과로 옮기지 않는다.
  • 보고서에는 불필요한 비밀번호·전체 세션 토큰·개인 자료를 넣지 않고 재시험에 필요한 최소 증거를 남긴다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.