13년차의 서버실

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

[태그:] GVM

  • [보안] OpenVAS 활용 취약점 스캔 효율성 높이는 10가지 체크리스트

    [보안] OpenVAS 활용 취약점 스캔 효율성 높이는 10가지 체크리스트

    OpenVAS 활용 취약점 스캔 효율성 높이는 10가지 체크리스트

    OpenVAS 활용 이야기를 하면 생각보다 많은 분들이 비슷한 고민을 하시더라고요. 분명 취약점 스캔은 돌렸는데 결과가 너무 많아서 뭘 먼저 봐야 할지 모르겠고, 반대로 꼭 잡아야 할 이슈는 놓치는 경우도 있습니다. 저도 홈랩과 사내 테스트망에서 GVM(Greenbone Vulnerability Management, 그린본 취약점 관리)을 만지기 시작했을 때 딱 그랬습니다. 스캔은 도는데 성능은 답답하고, 결과는 많은데 우선순위는 안 보이고, 인증 스캔(Authenticated Scan, 계정 기반 점검)은 왜 이렇게 손이 많이 가나 싶었거든요. 그래서 오늘은 OpenVAS 활용 관점에서, 실제 운영 전에 꼭 챙겨야 할 체크리스트 10가지를 경험 기반으로 정리해보겠습니다.

    이 글은 제품 홍보용이 아니라, 취약점 스캔을 조금 더 현실적으로 잘 굴리기 위한 실전 메모에 가깝습니다. 특히 GVM으로 보안 점검을 자동화하려는 분, 내부 자산이 늘면서 네트워크 취약점 관리가 버거워진 분께 도움이 될 겁니다.

    OpenVAS 활용 전체 아키텍처와 GVM 구성요소를 보여주는 다이어그램

    OpenVAS 활용 흐름을 한눈에 볼 수 있도록, 스캐너와 매니저, 웹 UI, 대상 자산 관계를 정리한 개요 이미지입니다.

    1. 왜 OpenVAS 활용에서 효율이 갈리는가

    쉽게 말해 OpenVAS는 스캔 엔진만 잘 켠다고 끝나는 도구가 아닙니다. 어떤 자산을, 어떤 방식으로, 어느 시간대에, 어떤 계정으로, 어떤 정책으로 스캔하느냐에 따라 결과 품질이 완전히 달라집니다. 처음엔 이게 뭔가 싶었는데, 실제로 써보니까 스캔 정확도보다 먼저 스캔 설계가 중요하더라고요.

    제가 직접 해보니 가장 흔한 실패 패턴은 이렇습니다. 전 대역을 한 번에 돌린다, 인증 정보 없이 깊은 점검을 기대한다, 결과를 CSV로만 뽑아두고 안 본다, 그리고 다음 달에 또 같은 경고를 받습니다. 이 루프를 끊으려면 처음부터 체크리스트 기반으로 접근하는 게 훨씬 낫습니다.

    2. GVM과 OpenVAS 개념, 헷갈리는 부분부터 정리

    여기서 많이 헷갈리시는 포인트가 있더라고요. OpenVAS는 보통 취약점 스캐너를 가리키는 이름으로 많이 쓰이고, GVM은 이를 포함한 관리 프레임워크 전체를 뜻하는 경우가 많습니다. 쉽게 말해 OpenVAS가 엔진 쪽 느낌이라면, GVM은 스캔 관리, 결과 저장, 웹 인터페이스까지 묶어서 보는 그림에 가깝습니다.

    구분 역할 실무에서 보는 포인트
    OpenVAS 취약점 탐지 스캐너 포트, 서비스, 취약점 탐지 품질에 직접 영향
    GVM 관리 프레임워크 스캔 정책, 일정, 보고서, 자산 관리에 유리
    GSAD 웹 인터페이스 결과 확인과 운영 편의성 담당

    혹시 이런 경험 있으신가요? 분명 스캔은 했는데, 결과를 운영팀이 읽기 쉽게 전달하지 못해서 다시 수작업 정리하게 되는 경우요. 그래서 저는 이제 스캐너만 보는 게 아니라, 결과 소비 방식까지 포함해서 설계합니다.

    3. OpenVAS 활용 체크리스트 10가지

    1. 자산 목록(Asset Inventory, 자산 인벤토리)을 먼저 정리합니다. IP만 모아두지 말고 서버 역할, 담당자, 운영시간, 중요도를 함께 붙여두세요.
    2. 스캔 범위를 나눕니다. 서버망, 사용자망, DMZ(디엠지, 외부 공개 구간)를 한 번에 섞지 않는 게 좋습니다.
    3. 인증 스캔 여부를 구분합니다. 가능한 서버는 인증 스캔을 쓰고, 불가능한 장비는 비인증 스캔으로 별도 운영하세요.
    4. 포트 스캔 정책을 과하게 넓히지 않습니다. 처음부터 모든 포트를 깊게 보면 시간만 오래 걸리는 경우가 많습니다.
    5. 피드(Feed, 취약점 검사 데이터)를 최신 상태로 유지합니다. 검사 데이터가 오래되면 결과 해석 자체가 흔들립니다.
    6. 스캔 시간대를 운영 영향이 적은 시간으로 잡습니다. 특히 레거시 장비는 응답 지연이 생기더라고요.
    7. 동시성(Concurrency, 동시 실행 수)을 욕심내지 않습니다. 스캐너가 먼저 버벅이면 결과도 불안정해집니다.
    8. False Positive(오탐) 기준을 팀 내에서 합의합니다. 같은 항목을 매번 사람마다 다르게 처리하면 피곤합니다.
    9. 결과를 티켓화합니다. 보고서로 끝내지 말고 조치 담당자와 마감일을 연결하세요.
    10. 재스캔 정책을 미리 정합니다. 수정 후 확인 스캔이 없으면 개선 활동이 기록으로 남지 않습니다.

    여기서 중요한 포인트! OpenVAS 활용의 핵심은 더 많이 스캔하는 게 아니라, 더 잘 나눠서 반복 가능하게 운영하는 겁니다.

    4. 실전 구현: 설치 후 가장 먼저 확인할 것

    환경마다 패키지 구성은 조금씩 다릅니다. 저는 Debian 계열이나 Kali 계열에서 먼저 기본 상태를 확인하는 편입니다. 처음엔 서비스 이름이 헷갈려서 삽질 좀 했습니다. 그래도 아래 순서대로 보면 대부분 감이 옵니다.

    4-1. 설치 직후 상태 점검

    gvm-check-setup
    systemctl status gvmd
    systemctl status gsad
    systemctl status ospd-openvas

    gvm-check-setup는 말 그대로 기본 점검용입니다. 이 단계에서 인증서, 소켓 권한, 피드 동기화 상태 같은 기본 문제가 자주 드러납니다. 드디어 됐다 싶어도 여기서 한 번 더 보는 게 좋습니다.

    4-2. 피드 동기화 확인

    greenbone-feed-sync --type GVMD_DATA
    greenbone-feed-sync --type SCAP
    greenbone-feed-sync --type CERT

    배포판과 설치 방식에 따라 동기화 명령은 조금 다를 수 있습니다. 중요한 건 피드가 최신인지 확인하는 습관입니다. 예전엔 이걸 대충 넘겼다가, 분명 존재하는 취약점이 결과에서 안 보여서 한참 원인을 찾았던 적이 있거든요.

    4-3. 웹 UI 접속 전 기본 확인

    ss -lntp | grep 9392
    journalctl -u gsad --no-pager | tail -n 50

    GSAD 웹 포트가 열려 있는지, 로그에 인증이나 바인딩 오류가 없는지 먼저 봅니다. UI가 안 뜨면 무조건 브라우저부터 의심하기 쉬운데, 실제로는 서비스 바인딩이나 인증서 쪽 문제인 경우가 많더라고요.

    OpenVAS 활용을 위한 GVM 스캔 정책 설정 화면 이미지

    스캔 정책, 대상(Target), 스케줄(Schedule)을 어떻게 나누는지 감을 잡을 수 있도록 운영 화면 느낌의 이미지를 배치하는 구간입니다.

    5. 실전 구현: 효율을 높이는 스캔 정책 구성

    이제부터가 진짜입니다. 단순 설치보다 운영 정책이 훨씬 중요합니다. 저는 보통 아래처럼 나눕니다.

    정책 유형 추천 대상 운영 팁
    빠른 탐색 스캔 신규 자산 파악 전체 상태 파악용으로 먼저 사용
    일반 취약점 스캔 정기 점검 대상 서버 주간 또는 월간 반복에 적합
    인증 스캔 관리 가능한 Linux/Windows 서버 계정 권한과 접근 제어를 사전 검토
    민감 구간 저강도 스캔 레거시 장비, 네트워크 장비 운영 시간 외에 제한적으로 수행

    5-1. 대상 그룹 분리

    # 예시: 자산 목록 파일을 그룹별로 분리
    mkdir -p targets
    printf "192.168.10.10\n192.168.10.11\n" > targets/linux-servers.txt
    printf "192.168.20.10\n192.168.20.20\n" > targets/network-devices.txt

    실제로 써보니까 대상 그룹을 잘 나누는 것만으로도 운영 난도가 확 내려갑니다. 한 번 실패한 스캔이 전체 일정에 영향을 주는 일이 줄어드니까요.

    5-2. 인증 스캔 계정 관리

    인증 스캔(Authenticated Scan, 계정 기반 점검)은 결과 품질이 좋지만 관리가 까다롭습니다. 최소 권한 원칙을 지키면서도 필요한 패키지 정보와 설정 정보를 읽을 수 있어야 하거든요. 저는 운영계와 점검계를 분리하고, 스캔 계정의 사용 범위를 문서화하는 편입니다.

    # 예시: Linux 서버에서 점검 계정 연결 확인
    ssh [email protected] 'uname -a'
    ssh [email protected] 'dpkg -l | head'

    물론 이 명령 자체가 모든 배포판에서 동일하게 의미 있진 않습니다. 다만 원격에서 필요한 정보를 안정적으로 읽을 수 있는지 확인하는 흐름은 꼭 필요합니다.

    5-3. 스케줄 분리

    # 운영 메모 예시
    # 월요일 22:00 - 사용자망 빠른 스캔
    # 화요일 23:00 - 서버망 인증 스캔
    # 토요일 01:00 - DMZ 심화 점검

    이건 코드보다 운영 원칙이 중요합니다. 스캔은 결국 네트워크와 대상 시스템에 부하를 줍니다. 특히 오래된 장비는 예상보다 민감합니다. 저도 예전에 네트워크 장비 쪽을 평일 낮에 건드렸다가 응답 지연 때문에 식은땀 난 적이 있습니다.

    6. ⚠️ 자주 겪는 문제와 해결 방법

    여기부터는 제가 실제로 자주 부딪힌 문제들입니다. 문서만 보면 간단해 보였는데, 막상 현장에서는 여기서 시간이 많이 나갑니다.

    6-1. 스캔이 너무 오래 걸립니다

    • 대상 그룹을 더 작게 나눕니다.
    • 포트 범위를 업무 특성에 맞게 조정합니다.
    • 동시 실행 수를 낮춰 스캐너 병목을 줄입니다.

    처음엔 장비가 느린 줄 알았는데, 실제로는 스캐너 자원이 먼저 포화되는 경우가 꽤 있었습니다.

    6-2. 오탐이 많습니다

    • 비인증 스캔 결과를 바로 조치 대상으로 넘기지 않습니다.
    • 서비스 배너(Banner, 서비스 식별 문자열) 기반 추정인지 확인합니다.
    • 운영팀 검증과 재스캔 절차를 붙입니다.

    특히 배너 정보만으로 판단된 결과는 한 번 더 확인하는 게 좋습니다. 오탐 처리 기준이 없으면 보안팀과 운영팀 둘 다 지치더라고요.

    6-3. 인증 스캔이 실패합니다

    • 계정 권한 부족인지 확인합니다.
    • 방화벽과 접근 제어 목록을 점검합니다.
    • SSH 키 또는 비밀번호 정책 변경 여부를 확인합니다.

    저도 처음엔 스캐너 설정 문제만 의심했는데, 알고 보니 대상 서버 측 SSH 정책이 바뀐 경우가 있었습니다. 이런 건 로그를 같이 보지 않으면 놓치기 쉽습니다.

    OpenVAS 활용 중 인증 스캔 문제를 점검하는 트러블슈팅 다이어그램

    인증 스캔 실패, 오탐, 지연 문제를 어떤 순서로 점검하는지 한눈에 보여주는 트러블슈팅 이미지 자리입니다.

    7. 결과 검증: 무엇을 보고 성공이라고 할 것인가

    보안 점검은 결과 파일이 생성됐다고 끝난 게 아닙니다. 저는 아래 네 가지를 꼭 봅니다.

    1. 대상 커버리지: 스캔 대상이 실제 자산 목록과 맞는가
    2. 인증 성공률: 인증 스캔 대상 중 실제 인증이 적용된 비율은 어떤가
    3. 재현성: 같은 조건에서 다시 돌렸을 때 결과가 크게 흔들리지 않는가
    4. 조치 연결성: 결과가 티켓이나 작업 항목으로 이어졌는가

    여기서 중요한 포인트! 취약점 수가 많다고 무조건 스캔이 잘 된 건 아닙니다. 오히려 범위가 잘못 잡혀서 잡음만 늘어난 경우도 있거든요.

    # 보고서 검토 시 운영 메모 예시
    # - High/Medium 항목 중 인증 필요 여부 확인
    # - 동일 자산의 반복 경고 여부 확인
    # - 조치 완료 자산 재스캔 예약

    실제로 써보니까, 결과 검증 단계에서 OpenVAS 활용 수준이 확 갈립니다. 보는 항목이 정리된 팀은 시간이 갈수록 빨라지고, 그냥 보고서만 쌓아두는 팀은 계속 원점이더라고요.

    OpenVAS 활용 결과를 분석하는 취약점 스캔 대시보드 이미지

    스캔 결과를 심각도별로 분류하고, 조치 대상과 재스캔 대상을 나누는 대시보드 이미지를 넣기 좋은 구간입니다.

    8. 제가 정착한 운영 체크리스트 요약

    아래 표는 팀에 공유하기 좋게 정리한 버전입니다. 신규 담당자에게 넘길 때도 꽤 유용했습니다.

    체크 항목 확인 질문 중요도
    자산 분류 중요 자산과 일반 자산이 구분되어 있는가 높음
    스캔 방식 인증/비인증 기준이 정리되어 있는가 높음
    피드 상태 최근 동기화 상태를 확인했는가 높음
    운영 시간 업무 영향이 적은 시간대로 분리했는가 중간
    오탐 관리 재검증 절차가 있는가 높음
    후속 조치 결과가 티켓으로 연결되는가 높음

    이 표만 잘 굴려도 취약점 스캔 품질이 꽤 안정됩니다. 다음 글에서는 결과를 자산 관리 체계와 연결하는 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 수집 체계와 붙이면 더 편해지더라고요.

    9. 자주 묻는 질문 FAQ

    Q1. OpenVAS 활용 시 인증 스캔은 꼭 필요한가요?

    가능하면 권장합니다. 비인증 스캔만으로는 패키지 상태나 내부 설정을 충분히 확인하기 어려운 경우가 있기 때문입니다. 다만 모든 장비에 무리하게 적용할 필요는 없습니다.

    Q2. 네트워크 장비도 같은 정책으로 스캔해도 되나요?

    보통은 권장하지 않습니다. 레거시 장비나 민감한 장비는 저강도 정책으로 분리하는 게 안전합니다. 저도 처음엔 한 정책으로 밀어붙였다가 반응이 좋지 않았습니다.

    Q3. 결과가 너무 많을 때는 어디부터 봐야 하나요?

    자산 중요도, 외부 노출 여부, 인증 성공 여부를 먼저 보세요. 그 다음에 반복적으로 재현되는 항목부터 묶어서 처리하면 훨씬 수월합니다.

    OpenVAS 활용 10가지 체크리스트 요약 인포그래픽

    마무리 전에 핵심 체크리스트를 빠르게 복습할 수 있도록, 10가지 항목을 요약한 인포그래픽을 배치하는 자리입니다.

    10. 마무리: 많이 돌리는 것보다, 잘 설계하는 게 먼저입니다

    오늘 정리한 내용은 화려한 기능 소개보다 훨씬 현실적인 이야기입니다. 결국 GVM과 OpenVAS는 도입보다 운영이 더 중요합니다. 제가 직접 해보니, 처음부터 완벽한 정책을 만들겠다는 생각보다는 작은 범위에서 검증하고, 오탐 기준을 정하고, 인증 스캔 대상을 늘려가는 방식이 훨씬 안정적이었습니다.

    OpenVAS 활용은 도구 자체보다 운영 습관에서 성패가 갈립니다. 자산을 나누고, 스케줄을 나누고, 결과를 티켓으로 연결하고, 수정 후 재스캔까지 닫아보세요. 이 루프만 잡혀도 보안 점검 품질이 한 단계 올라갑니다. 혹시 지금 스캔 결과가 너무 많아서 막막하셨다면, 오늘 체크리스트 10개부터 하나씩 적용해보시면 좋겠습니다. 이거 진짜 편하더라고요. 🎉

  • [보안] OpenVAS 스캔 성능 저하? 흔한 문제 해결과 최적화 팁

    [보안] OpenVAS 스캔 성능 저하? 흔한 문제 해결과 최적화 팁

    [보안] OpenVAS 스캔 성능 저하? 흔한 문제 해결과 최적화 팁

    홈랩이든 사내 테스트망이든, 취약점 스캐너를 돌려놨는데 유독 OpenVAS 성능 저하가 심하게 느껴질 때가 있습니다. 스캔 하나 시작했을 뿐인데 CPU는 치솟고, 디스크 I/O는 바빠 보이고, 웹 UI는 굼떠지고, 결과는 한참 뒤에야 나오더라고요. 저도 처음엔 네트워크가 느린 줄 알았습니다. 근데 실제로 뜯어보니 네트워크보다 리소스 병목(resource bottleneck, 자원 병목), 피드 동기화 상태, 동시 작업 수 같은 기본 설정에서 문제가 생기는 경우가 훨씬 많더라고요. 이번 글에서는 제가 직접 겪었던 삽질을 바탕으로 OpenVAS 문제 해결과 취약점 스캔 최적화에 바로 써먹을 수 있는 포인트를 정리해보겠습니다.

    특히 Greenbone 기반 환경을 쓰시는 분들은 비슷한 흐름으로 점검하실 수 있습니다. 제품 패키징이나 서비스 이름은 배포판과 설치 방식에 따라 조금씩 다르지만, 원인은 대체로 비슷하거든요.

    OpenVAS 성능 저하 원인을 설명하는 전체 스캔 아키텍처 이미지

    OpenVAS 스캐너, 관리 데몬, 웹 UI, 피드 동기화, 대상 네트워크 사이의 흐름을 한눈에 보여주는 개요 이미지입니다.

    1. 왜 OpenVAS 성능 저하가 자주 생길까요?

    쉽게 말해 OpenVAS는 단순 포트 스캔만 하는 도구가 아닙니다. NVT(Network Vulnerability Test, 네트워크 취약점 테스트)를 아주 많이 실행하면서 대상 시스템에 대해 여러 프로토콜을 확인합니다. 그러다 보니 CPU, 메모리, 디스크, 네트워크, 심지어 DNS 응답 상태까지 영향을 줍니다.

    여기서 중요한 포인트! 느리다고 해서 무조건 스캐너 성능만 탓하면 안 됩니다. 실제로는 다음 네 가지가 가장 흔한 원인이었습니다.

    • 과도한 동시성(concurrency, 동시 실행) 설정
    • 메모리 부족(memory pressure, 메모리 압박)과 스왑 사용
    • 피드(feed, 취약점 테스트 데이터) 동기화 이상 또는 DB 부담
    • 대상 네트워크 응답 지연과 DNS/방화벽 영향

    제가 처음엔 이게 뭔가 싶었는데, 스캔 속도가 느린 문제가 사실상 한 가지가 아니라 여러 병목이 겹쳐서 나타나는 경우가 많았습니다. 그래서 증상만 보고 설정부터 막 바꾸면 오히려 더 느려질 수 있더라고요.

    2. OpenVAS 구조를 이해하면 문제 원인이 빨리 보입니다

    OpenVAS Scanner(스캐너)는 실제 테스트를 수행하고, gvmd(관리 데몬)는 작업과 결과를 관리하며, GSAD 웹 UI는 우리가 보는 화면을 제공합니다. 여기에 피드 데이터와 데이터베이스가 얹히죠.

    쉽게 말해 이런 구조입니다.

    구성요소 역할 성능 저하 시 보이는 증상
    Scanner 취약점 테스트 실행 CPU 사용량 급증, 스캔 시간 증가
    Manager 작업 스케줄링, 결과 저장 작업 대기, UI 반응 저하
    Database 결과 및 메타데이터 저장 보고서 생성 지연, 조회 느림
    Feed NVT/SCAP/CERT 데이터 제공 누락된 테스트, 비정상 동작 가능

    이 구조를 머릿속에 넣어두면, 어디부터 봐야 할지가 바로 잡힙니다. 예를 들어 스캔 자체가 느리면 스캐너와 시스템 자원부터, 결과 조회만 느리면 DB와 매니저 쪽부터 보는 식이죠.

    3. 실전 점검 1단계: 리소스 병목부터 확인해보세요

    저는 항상 제일 먼저 운영체제 레벨부터 봅니다. 이유는 간단합니다. 서비스 설정을 아무리 예쁘게 바꿔도 CPU가 꽉 차 있거나 디스크가 버벅이면 답이 없거든요.

    1. CPU와 메모리 사용량 확인
    2. 디스크 여유 공간과 I/O 확인
    3. 스왑 사용 여부 확인
    4. 로드(load average, 평균 부하)와 프로세스 상태 확인
    top
    free -h
    df -h
    iostat -xz 1
    vmstat 1

    ⚠️ 스왑(swap)이 적극적으로 사용되고 있다면 체감 성능이 확 떨어집니다. 제가 홈랩 VM 자원을 좀 아끼겠다고 메모리를 넉넉히 안 줬다가, 스캔 중간마다 UI가 멎는 것처럼 보이는 일을 겪었거든요. 그때 로그보다 먼저 메모리를 봤어야 했습니다 ㅎㅎ

    또 하나, 디스크도 중요합니다. 결과 DB와 피드 데이터가 같이 있는 환경에서 느린 스토리지를 쓰면, 스캔보다 보고서 생성에서 더 답답함이 크게 느껴질 수 있습니다. 특히 가상 디스크가 얇게 할당(thin provisioned)되어 있거나, 다른 VM과 I/O를 경쟁하면 금방 티가 납니다.

    OpenVAS 성능 저하 점검을 위한 CPU 메모리 디스크 I/O 확인 이미지

    CPU 사용률, 메모리 압박, 디스크 I/O 병목을 함께 확인하는 점검 흐름을 보여주는 이미지입니다.

    4. 실전 점검 2단계: 서비스 상태와 로그를 같이 봐야 합니다

    자원 사용량에 큰 문제가 없는데도 느리다면, 이제 서비스 상태를 봐야 합니다. 배포판에 따라 서비스 이름은 다를 수 있지만, 보통은 관리 데몬, 스캐너, 웹 UI 관련 프로세스를 확인하면 됩니다.

    systemctl status gvmd
    systemctl status ospd-openvas
    systemctl status gsad
    journalctl -u gvmd -n 100 --no-pager
    journalctl -u ospd-openvas -n 100 --no-pager

    여기서 제가 자주 봤던 증상은 이런 쪽이었습니다.

    • 피드 동기화 이후 캐시가 완전히 반영되지 않아 초기 응답이 매우 느린 경우
    • 스캔 작업이 겹치면서 큐(queue, 대기열)가 쌓이는 경우
    • 타깃 호스트가 응답을 늦게 하거나 차단해서 각 테스트가 타임아웃(timeout, 응답 대기 초과) 나는 경우

    OpenVAS 문제 해결에서 의외로 중요한 게 로그를 너무 무겁게 읽지 않는 겁니다. 모든 줄을 해석하려고 하면 지칩니다. 대신 반복되는 경고, 타임아웃, 연결 실패, DB 지연 같은 패턴만 먼저 찾으세요. 그게 훨씬 빠릅니다.

    5. 취약점 스캔 최적화: 제가 효과 봤던 설정 포인트

    이제 본격적으로 취약점 스캔 최적화 얘기를 해보겠습니다. 성능을 올리는 핵심은 무작정 많이 돌리는 게 아니라, 대상 범위(scope, 스캔 범위)와 동시 작업 수를 현실적으로 맞추는 겁니다.

    5-1. 한 번에 너무 많은 대역을 넣지 마세요

    처음엔 욕심이 나서 넓은 대역을 한 번에 넣기 쉽습니다. 저도 그랬습니다. 근데 실제로 써보니까 네트워크 구간, OS 종류, 중요도별로 타깃을 나누는 게 결과도 깔끔하고 성능도 안정적이더라고요.

    # 예시: 대상을 역할별로 나눠 관리
    # 192.168.10.0/24 : 서버 존
    # 192.168.20.0/24 : 사용자 PC 존
    # 192.168.30.0/24 : 테스트 존

    5-2. 동시 스캔 수를 환경에 맞게 낮춰보세요

    동시성을 높이면 빨라질 것 같지만, VM 자원이 작으면 오히려 전체 완료 시간이 늘어납니다. CPU 코어 수와 메모리에 비해 과한 병렬 처리(parallelism, 병렬 실행)를 주면 컨텍스트 스위칭과 I/O 대기가 늘어나거든요. 저는 작은 홈랩에서는 작업을 나눠서 순차적으로 돌리는 편이 훨씬 안정적이었습니다.

    5-3. DNS와 라우팅을 의심해보세요

    이건 은근히 많이 놓칩니다. 타깃 해석이 꼬이거나 역방향 조회(reverse lookup, 역방향 DNS 조회)가 늦으면 전체 체감 속도가 나빠집니다. 방화벽이 특정 프로브를 조용히 드롭(drop, 폐기)하는 환경도 마찬가지고요. 이런 경우는 스캐너 문제가 아니라 네트워크 응답 정책 문제인 경우가 많습니다.

    5-4. 피드 동기화 직후에는 상태를 한 번 더 확인하세요

    Greenbone VM 팁으로 하나 말씀드리면, 피드 동기화 이후에는 잠깐 정리 시간이 필요할 때가 있습니다. 바로 스캔을 몰아서 넣기보다 서비스 상태와 시스템 부하를 먼저 확인하는 게 안전합니다. 저는 동기화 직후 UI가 유독 굼뜬 날이 있었는데, 잠시 기다린 뒤 다시 시도하니 정상화된 적이 꽤 있었습니다.

    취약점 스캔 최적화와 OpenVAS 대상 분리 설정 이미지

    대상 네트워크 분리, 동시 작업 수 조절, 피드 동기화 타이밍 같은 최적화 포인트를 시각화한 이미지입니다.

    6. 자주 겪는 트러블슈팅 4가지

    여기는 진짜 실전 구간입니다. 제가 삽질 좀 했던 부분만 추려보겠습니다.

    6-1. 스캔이 유난히 오래 걸리고 끝나지 않는 느낌

    원인: 타임아웃이 많은 대상, 방화벽 드롭, 응답 느린 장비가 섞여 있을 가능성이 큽니다.

    해결: 대상을 분리하고, 느린 세그먼트를 따로 스캔하세요. 네트워크 장비나 프린터, IoT 장비가 섞여 있으면 유독 길어질 때가 있습니다.

    6-2. 웹 UI만 느리고 스캔은 도는 경우

    원인: DB 조회 부담이나 보고서 렌더링 지연일 수 있습니다.

    해결: 오래된 결과를 정리하고, 동시에 여러 보고서를 열지 마세요. 리소스가 작은 VM이라면 브라우저에서 체감 차이가 꽤 큽니다.

    6-3. 피드 동기화 후 이상하게 무거워진 경우

    원인: 캐시 반영이나 백그라운드 작업이 끝나지 않았을 수 있습니다.

    해결: 서비스 로그를 먼저 확인하고, 시스템 부하가 안정될 때까지 기다린 뒤 스캔을 시작합니다.

    6-4. 가상머신에서만 유독 느린 경우

    원인: CPU overcommit(오버커밋), 느린 스토리지, 메모리 부족이 흔합니다.

    해결: vCPU와 메모리를 재점검하고, 가능하면 스토리지 I/O 경쟁을 줄이세요. 이건 진짜 체감이 큽니다. 드디어 됐다! 싶은 순간이 여기서 오더라고요.

    증상 먼저 볼 것 우선 조치
    스캔 전체가 느림 CPU, 메모리, 타임아웃 대상 분리, 동시성 완화
    UI만 느림 DB, 보고서 조회 결과 정리, 동시 조회 감소
    동기화 직후 무거움 로그, 백그라운드 작업 상태 안정 후 스캔
    VM 환경만 느림 vCPU, RAM, 스토리지 리소스 재할당

    7. 검증은 이렇게 해보시면 됩니다

    튜닝하고 나서 정말 나아졌는지는 감으로 판단하면 안 됩니다. 같은 대상군으로 비교해보는 게 제일 좋습니다.

    1. 비슷한 규모의 대상 그룹을 고릅니다.
    2. 변경 전 스캔 시간과 시스템 부하를 기록합니다.
    3. 동시 작업 수, 대상 분리, 자원 조정 중 한 가지만 변경합니다.
    4. 다시 스캔해서 완료 시간과 체감 반응을 비교합니다.
    date
    uptime
    free -h
    journalctl -u gvmd -n 30 --no-pager

    제가 직접 해보니 한 번에 여러 설정을 바꾸는 것보다, 한 가지씩 바꾸고 비교하는 게 훨씬 정확했습니다. 사실 귀찮아 보여도 이게 제일 빠른 길입니다. 특히 OpenVAS 성능 저하는 원인이 복합적이라서, 바꾼 항목이 어떤 효과를 냈는지 분리해서 봐야 합니다.

    스캔 시간 비교, 시스템 부하 확인, 결과 검증 흐름을 한 장으로 정리한 이미지입니다.

    8. 정리와 FAQ: 결국 핵심은 병목을 정확히 찾는 겁니다

    OpenVAS 성능 저하가 보이면 무조건 설정 파일부터 열지 마세요. 운영체제 자원, 서비스 상태, 대상 특성, 피드 동기화 순으로 보시면 생각보다 빨리 풀립니다. 저도 처음엔 스캐너 자체 문제라고 단정했었는데, 실제로는 메모리 부족과 과한 동시 실행이 원인이었던 적이 많았습니다.

    정리하면 이렇습니다.

    • 리소스 병목이 있는지 먼저 확인
    • 대상 범위를 잘게 나눠 스캔
    • 동시성은 높을수록 좋은 게 아님
    • 로그 패턴에서 타임아웃과 반복 오류를 먼저 확인
    • 피드 동기화 직후에는 상태 안정 여부를 점검

    자주 묻는 질문

    Q. CPU가 남는데도 느릴 수 있나요?
    네, 가능합니다. 디스크 I/O나 네트워크 타임아웃, DB 조회 지연 때문일 수 있습니다.

    Q. Greenbone VM 팁이 따로 있나요?
    있습니다. 작은 VM에 과한 동시 작업을 넣지 말고, 피드 동기화 직후에는 상태를 먼저 보는 습관이 좋습니다.

    Q. 어디부터 손대야 제일 효과가 큰가요?
    대상 분리와 메모리 확인부터 해보세요. 실제로 가장 빨리 효과를 보는 경우가 많습니다.

    다음 글에서는 스캔 결과를 운영 우선순위로 정리하는 방법, 즉 단순 취약점 개수보다 실제 대응 순서를 어떻게 잡아야 하는지 다뤄볼 예정입니다. 이전 글에서 다룬 홈랩 모니터링 구성과 함께 보시면 더 이해가 잘 되실 거예요.

    OpenVAS 성능 저하 원인과 해결책 요약 인포그래픽

    원인별 점검 순서와 최적화 포인트를 마지막에 다시 확인할 수 있도록 정리한 요약 이미지입니다.

    결론은 단순합니다. OpenVAS 문제 해결은 감이 아니라 순서입니다. 혹시 지금도 스캔이 이상하게 느리다면, 오늘은 딱 세 가지만 보세요. 메모리, 디스크 I/O, 그리고 대상 분리. 여기서 풀리는 경우가 정말 많습니다. 이거 진짜 편하더라고요.