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

목차

• 1. 왜 OpenVAS 활용에서 효율이 갈리는가
• 2. GVM과 OpenVAS 개념, 헷갈리는 부분부터 정리
• 3. OpenVAS 활용 체크리스트 10가지
• 4. 실전 구현: 설치 후 가장 먼저 확인할 것
• 4-1. 설치 직후 상태 점검
• 4-2. 피드 동기화 확인
• 4-3. 웹 UI 접속 전 기본 확인
• 5. 실전 구현: 효율을 높이는 스캔 정책 구성
• 5-1. 대상 그룹 분리
• 5-2. 인증 스캔 계정 관리
• 5-3. 스케줄 분리
• 6. ⚠️ 자주 겪는 문제와 해결 방법
• 6-1. 스캔이 너무 오래 걸립니다
• 6-2. 오탐이 많습니다
• 6-3. 인증 스캔이 실패합니다
• 7. 결과 검증: 무엇을 보고 성공이라고 할 것인가
• 8. 제가 정착한 운영 체크리스트 요약
• 9. 자주 묻는 질문 FAQ
• Q1. OpenVAS 활용 시 인증 스캔은 꼭 필요한가요?
• Q2. 네트워크 장비도 같은 정책으로 스캔해도 되나요?
• Q3. 결과가 너무 많을 때는 어디부터 봐야 하나요?
• 10. 마무리: 많이 돌리는 것보다, 잘 설계하는 게 먼저입니다

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

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

이 글은 제품 홍보용이 아니라, 취약점 스캔을 조금 더 현실적으로 잘 굴리기 위한 실전 메모에 가깝습니다. 특히 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가 안 뜨면 무조건 브라우저부터 의심하기 쉬운데, 실제로는 서비스 바인딩이나 인증서 쪽 문제인 경우가 많더라고요.

스캔 정책, 대상(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 scanuser@192.168.10.10 'uname -a'
ssh scanuser@192.168.10.10 'dpkg -l | head'

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

5-3. 스케줄 분리

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

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

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

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

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

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

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

6-2. 오탐이 많습니다

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. 자주 묻는 질문 FAQ

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

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

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

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

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

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

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

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

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

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

📚 함께 읽으면 좋은 글

• IDS IPS 비교: Snort vs Suricata 선택 가이드
• SQL 인젝션 방어: 모의 해킹 사례로 본 실전 대응
• 웹 취약점 진단: Burp Suite vs OWASP ZAP 심층 비교