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

목차

• 1. 왜 OpenVAS 성능 저하가 자주 생길까요?
• 2. OpenVAS 구조를 이해하면 문제 원인이 빨리 보입니다
• 3. 실전 점검 1단계: 리소스 병목부터 확인해보세요
• 4. 실전 점검 2단계: 서비스 상태와 로그를 같이 봐야 합니다
• 5. 취약점 스캔 최적화: 제가 효과 봤던 설정 포인트
• 5-1. 한 번에 너무 많은 대역을 넣지 마세요
• 5-2. 동시 스캔 수를 환경에 맞게 낮춰보세요
• 5-3. DNS와 라우팅을 의심해보세요
• 5-4. 피드 동기화 직후에는 상태를 한 번 더 확인하세요
• 6. 자주 겪는 트러블슈팅 4가지
• 6-1. 스캔이 유난히 오래 걸리고 끝나지 않는 느낌
• 6-2. 웹 UI만 느리고 스캔은 도는 경우
• 6-3. 피드 동기화 후 이상하게 무거워진 경우
• 6-4. 가상머신에서만 유독 느린 경우
• 7. 검증은 이렇게 해보시면 됩니다
• 8. 정리와 FAQ: 결국 핵심은 병목을 정확히 찾는 겁니다
• 자주 묻는 질문

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

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

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

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를 경쟁하면 금방 티가 납니다.

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가 유독 굼뜬 날이 있었는데, 잠시 기다린 뒤 다시 시도하니 정상화된 적이 꽤 있었습니다.

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

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

📚 함께 읽으면 좋은 글

• VPN 비용 분석: 매니지드 VPN과 WireGuard 자체 호스팅 3년 TCO 비교
• 방화벽 설정, 이것만은 꼭! 10가지 필수 점검 항목
• CIS 벤치마크 기반 서버 보안 강화: 실제 적용 사례와 효과