042. Linux 서버 보안 — OpenSCAP 자동 점검과 결과 해석

시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 42/50편 (전체 042/450)
학습 단계: 4단계 · 자동 점검·로그 분석
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 041. CIS Benchmark 관점의 점검 구조

1. 개념

OpenSCAP 은 SCAP(보안 설정 자동화 표준) 형식의 점검 정책을 실행하는 도구입니다. 정책 내용은 SCAP Security Guide(SSG, ComplianceAsCode 프로젝트) 가 배포판별로 제공하며, 그 안에 CIS·PCI-DSS 등 여러 프로파일이 들어 있습니다.

scap-security-guide 패키지
  └─ 데이터스트림 파일 (*.ds.xml / *-ds.xml)
        ├─ 프로파일: cis_server_l1, cis_server_l2, pci-dss, ...
        └─ 규칙(rule) 수백 개: 각 규칙 = 점검 로직(OVAL) + 조치 스크립트
                ↓
oscap xccdf eval --profile ... 데이터스트림
                ↓
결과: results.xml (기계용) + report.html (사람용)

RHEL 계열(Rocky)은 패키지로 바로 쓸 수 있고, Ubuntu는 Ubuntu Security Guide(USG, Ubuntu Pro 필요) 또는 ComplianceAsCode에서 빌드한 콘텐츠를 사용합니다.

2. 왜 중요한가

• 수백 개 항목을 사람이 명령어로 하나씩 점검하는 것은 현실적이지 않습니다. 자동 점검은 같은 기준을 모든 서버에 반복 적용할 수 있게 해 줍니다.
• 결과가 표준 형식(XCCDF/ARF)이라 다른 도구·보고 체계와 연동할 수 있습니다.
• 다만 자동 조치(remediation)를 운영 서버에 그대로 적용하면 서비스 장애가 날 수 있으므로, 점검과 조치를 분리하는 것이 원칙입니다.

3. 핵심 명령어 / 설정

명령	용도
sudo dnf install -y openscap-scanner scap-security-guide	설치(Rocky)
ls /usr/share/xml/scap/ssg/content/	데이터스트림 파일명 확인(배포판별 상이)
oscap info 데이터스트림	포함된 프로파일 ID 목록
oscap xccdf eval --profile ID --results r.xml --report r.html 데이터스트림	점검 실행
oscap xccdf generate fix --profile ID --fix-type bash ...	조치 스크립트 생성(검토용)

4. 실습 (실습 예시)

# Rocky 9 테스트 VM
sudo dnf install -y openscap-scanner scap-security-guide
ls /usr/share/xml/scap/ssg/content/
DS=$(ls /usr/share/xml/scap/ssg/content/*-ds.xml | head -1); echo "$DS"

# 프로파일 ID 확인
oscap info "$DS" | grep -A1 -i 'cis' | head

# CIS Server Level 1 점검 (프로파일 ID는 위 출력으로 확인한 값 사용)
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results /root/oscap-results.xml \
  --report  /root/oscap-report.html \
  "$DS" | tail -20

# 결과 요약
grep -o 'result>[a-z]*<' /root/oscap-results.xml | sort | uniq -c

oscap xccdf eval은 FAIL 항목이 있으면 종료 코드 2를 반환하므로, 자동화 스크립트에서 오류(1)와 구분해 처리합니다.

5. 정상 상태

Title   Set SSH Daemon LogLevel to VERBOSE
Rule    xccdf_org.ssgproject.content_rule_sshd_set_loglevel_verbose
Result  pass

Title   Disable SSH Root Login
Rule    xccdf_org.ssgproject.content_rule_sshd_disable_root_login
Result  pass
...
    312 result>pass<
      9 result>fail<
     41 result>notapplicable<

결과 수치는 예시입니다. FAIL이 소수이고 모두 승인된 예외 목록에 있는 상태가 운영상 정상입니다.

6. 이상 상태

Title   Disable SSH Root Login
Result  fail
Title   Ensure SELinux State is Enforcing
Result  fail
Title   Make the auditd Configuration Immutable
Result  fail

지난 점검에서 PASS였던 핵심 항목(SSH root, SELinux, auditd 불변)이 FAIL로 바뀌었다면 039편의 하드닝 해제 징후와 같은 의미입니다. 자동 점검 결과도 변화(diff) 로 봐야 합니다.

결과값	의미
pass / fail	기준 충족 / 미충족
notapplicable	해당 환경에 적용 안 됨(패키지 미설치 등)
notchecked	자동 점검 불가(수동 확인 필요)
error	점검 실행 오류 → 결과를 신뢰할 수 없음

7. 로그 분석 (분석 방법)

OpenSCAP 결과는 XML이므로, 핵심만 뽑아 로그·SIEM으로 보내는 방식이 실용적입니다(분석 방법 예시).

# FAIL 규칙 ID만 추출해 이전 결과와 비교
xmllint --xpath '//*[local-name()="rule-result"][*[local-name()="result"]="fail"]/@idref' \
  /root/oscap-results.xml 2>/dev/null | tr ' ' '\n' | sed 's/idref=//; s/"//g' | sort > /root/oscap-fail-$(date +%F).txt
diff /root/oscap-fail-2026-09-15.txt /root/oscap-fail-2026-10-01.txt

> xccdf_org.ssgproject.content_rule_audit_rules_immutable
> xccdf_org.ssgproject.content_rule_selinux_state
> xccdf_org.ssgproject.content_rule_sshd_disable_root_login

새로 FAIL이 된 규칙 ID 목록이 곧 조사 대상 목록입니다. 각 규칙 ID로 보고서(report.html)의 Audit·Remediation 설명을 바로 찾아볼 수 있습니다.

8. SOC 관제 포인트

• 점검은 정기 실행(예: 주 1회)하고, 새로 FAIL이 된 규칙만 Alert로 올려 피로도를 줄입니다.
• error, notchecked 비율이 높으면 점검 결과 자체의 신뢰성을 먼저 확인합니다.
• 자동 생성 조치 스크립트는 테스트 VM에서 검증 후 변경관리 절차로 적용합니다.

9. 탐지 규칙

<!-- 신규 FAIL 목록을 syslog로 보낸 경우 (logger -t oscap-diff "new_fail=규칙ID") -->
<rule id="100470" level="9">
  <match>oscap-diff</match>
  <regex>new_fail=\S+</regex>
  <description>OpenSCAP 신규 FAIL 규칙 발생</description>
</rule>

여러 서버를 운영한다면 결과 XML을 중앙에 모아 비교하거나, 같은 정책을 에이전트 기반으로 상시 점검하는 Wazuh SCA(045편)로 역할을 나누는 구성이 일반적입니다.

10. 대응 방법

1. 초기 확인 — 신규 FAIL 규칙 목록과 해당 설정의 현재 값을 확인합니다.
2. 범위 확인 — 같은 규칙이 다른 서버에서도 새로 FAIL이 됐는지 확인합니다.
3. 증거 확보 — results.xml, report.html, 이전 결과 파일을 보존합니다.
4. 차단/조치 — FAIL 원인에 따라 설정 복원(드리프트) 또는 예외 승인 문서화를 진행합니다.
5. 재발 방지 — 정기 점검과 신규 FAIL 알림, 조치 스크립트 검증 절차를 운영합니다.

11. 핵심 정리

구분	핵심 내용
구성	oscap(실행기) + SSG 데이터스트림(정책·프로파일)
실행	oscap xccdf eval --profile ID --results --report
결과값	pass · fail · notapplicable · notchecked · error
운영 원칙	점검과 조치 분리, 신규 FAIL만 Alert
면접 포인트	"자동 점검 결과도 diff로 봐야 이상 징후가 된다"

12. 다음 편 예고

다음 편 043. Linux 서버 보안 — Lynis 하드닝 점검 결과 해석 에서는 에이전트 없이 빠르게 전체 상태를 훑는 Lynis 하드닝 점검 결과 해석을 다룹니다.

---

이전 편: 041. Linux 서버 보안 — CIS Benchmark 관점의 점검 구조
📚 시리즈 전체 보기: 시스템 보안 · 취약점