실측 결과
2026년 9월 11일 재실행 결과입니다. Hostveil 점수와 함께 Lynis, CIS Docker 벤치마크, Docker 브리지에서 실행한 TCP 스캔, 커널의 수신 소켓을 비교했습니다. 개선된 수치뿐 아니라 남은 위험과 롤백으로 돌아오지 않은 상태도 공개합니다.
무엇을 확인한 실험인가요?
Hostveil이 고친 뒤 자체 점수가 오르는 것만으로는 실제 개선을 입증할 수 없습니다. 다른 도구로도 같은 호스트를 측정해 변화를 확인했습니다. 폐기 가능한 VM에 취약한 설정을 심은 실험이며, 운영 서버 전체를 대표하거나 보안을 보장하는 결과는 아닙니다.
공개 수치는 9월 10일 실행을 대체하는 이번 최종 재실행을 기준으로 합니다. 수정·롤백 실험과 대조군 실험은 각각 새 VM에서 시작했고, 측정 전에 수동으로 하드닝하지 않았습니다. 실행 기록과 한계, 수정·롤백 원본 JSON, 대조군 원본 JSON을 확인할 수 있습니다. 이전 실행도 저장소에 보존했습니다.
측정한 호스트
Nextcloud와 PostgreSQL, Jellyfin과 Redis, Portainer와 Watchtower를 실행하는 구성입니다. root SSH 로그인을 허용하고 방화벽과 자동 업데이트를 끈 뒤, 계정·에이전트 설정·커널 설정에도 취약한 값을 넣었습니다. 13개 영역을 점검했으며, 13개 모두 점검 범위 누락 없이 완료했습니다.
| 운영체제 | Ubuntu 24.04.5 LTS |
| 아키텍처 | x86_64 |
| 커널 | 6.8.0-134-generic |
| Hostveil 버전 문자열 | hostveil v3-dev |
| 측정 시각 | 2026-09-11T04:52:54+00:00 |
| 소스 커밋 | 290b4d1ad429df94e95e6628fbb583eed800750d |
바이너리의 버전 문자열은 v3-dev이며 소스 커밋은 별도로 기록했습니다. 이 수치는 해당 빌드의 결과로, 이후 모든 릴리스의 결과를 뜻하지 않습니다.
측정 도구
| 도구 | 버전 / 범위 |
|---|---|
Hostveil scan --json | 설정 문제와 자체 점수 |
| Lynis | 3.0.9; 264개 테스트(적용 전), 270개(Review 적용 후) |
| docker-bench-security | 154869da6418089decf7e1ab0cfca0e1cdfc5c49; 44개 이미지·컨테이너 런타임 검사 |
| Docker / Trivy | Docker version 29.8.0, build 88096ef / Version: 0.74.0 |
| 외부 TCP 스캔 | Docker 브리지의 컨테이너에서 연결 시도 후 응답·거부·필터링 여부 기록 |
ss -ltn | 커널의 wildcard·라우팅 가능 주소에 바인딩된 소켓 수. 외부 응답 여부와 별도 집계 |
다섯 측정 시점
| 시점 | 측정 전 작업 |
|---|---|
| before | 취약한 설정을 심은 직후 |
| after | hostveil fix --all --yes; Auto 수정 적용, 서비스 재시작 전 |
| restarted | 서비스 재시작·재로드 및 각 스택에 docker compose up -d 실행 |
| reviewed | hostveil fix --all --review --yes; 이후 다시 재시작·재로드. 되돌릴 수 없는 명령 실행도 포함 |
| restored | 모든 체크포인트 롤백 후 재시작·재로드. 명령 실행의 효과는 롤백 대상에서 제외 |
파일 수정의 적용 시점은 서로 다릅니다. 파일 권한은 즉시 바뀔 수 있지만 실행 중인 컨테이너의 포트 매핑은 재생성해야 바뀝니다. 접속을 끊을 수 있는 SSH 변경은 Review가 필요합니다. 수정 자체와 재시작, Review 적용의 효과를 구분할 수 있도록 모든 시점을 표시했습니다.
측정 결과
| 측정 항목 | before | after | restarted | reviewed | restored |
|---|---|---|---|---|---|
| Hostveil 점수 | 28 | 37 | 40 | 58 | 32 |
| 미조치 발견 | 140 | 97 | 83 | 52 | 121 |
| Lynis 하드닝 지수 | 57 | 63 | 66 | 79 | 67 |
| Lynis 경고 | 4 | 4 | 4 | 3 | 3 |
| Lynis 제안 | 37 | 33 | 33 | 22 | 31 |
| CIS Docker 통과 | 17 | 17 | 19 | 20 | 16 |
| CIS Docker 경고 | 15 | 15 | 13 | 12 | 16 |
| wildcard·라우팅 가능 수신 포트 | 6 | 6 | 2 | 2 | 7 |
| Docker 브리지에서 응답한 포트 | 6 | 6 | 2 | 1 | 6 |
Auto 수정 55건은 실패 없이 적용됐습니다. 이어서 적용한 Review 수정 40건 중 24건은 체크포인트를 남겼고, 16건은 [not reversible]로 표시됐습니다.
바뀐 것과 남은 것
첫 재시작 뒤 외부 스캔에서 응답하지 않은 포트는 5432, 6380, 8080, 8096입니다. Review 적용 후에는 22만 응답했습니다. 커널에는 여전히 22, 6379가 wildcard·라우팅 가능 수신 포트로 남아 있었습니다. Redis의 6379 바인딩은 유지됐지만 스캔에서는 필터링으로 기록됐습니다. 바인딩과 TCP 연결 성공은 서로 다른 관측값입니다. 2375는 수정 전부터 연결이 거부됐습니다.
재시작 후 CIS 경고 5.14, 5.26, 5.3가 해소됐고, Review 적용 후에는 컨테이너 메모리 제한에 관한 5.11도 해소됐습니다. 경고 5.32가 새로 생겨 전체 경고는 세 건 줄었습니다. 5.3의 통과는 해석에 주의해야 합니다. docker-bench는 SecurityOpt가 비어 있지 않은지 확인하므로, SELinux를 설정하지 않아도 no-new-privileges만으로 통과할 수 있습니다.
Lynis 지수는 Auto 수정 직후부터 올랐으며, 재시작과 Review 적용 후에도 개선됐습니다. 경고 목록도 바뀌었습니다. AUTH-9283, PKGS-7392가 해소됐고 KRNL-5830가 새로 생겼습니다. AUTH-9204와 AUTH-9208은 남았습니다. 둘 다 추가로 만든 UID 0 계정에 관한 경고이며, Hostveil도 accounts.uid0으로 보고하고 수동 조치로 남깁니다.
| 영역 | before | reviewed |
|---|---|---|
| SSH | 10 | 100 |
| 컨테이너 | 0 | 2 |
| CVE | 5 | 5 |
| AI 에이전트 | 0 | 13 |
SSH 영역은 Review까지 적용한 뒤에야 만점에 도달했습니다. 컨테이너에는 Docker 소켓 마운트, 호스트 네트워킹, 환경 변수 속 비밀값 등의 위험이 남았습니다. 이번 실행에서는 CVE 점수가 개선되지 않았습니다. 최신 이미지 태그를 받더라도 취약점이 없다고 보장할 수는 없습니다. 에이전트 영역도 점수는 올랐지만 발견 항목이 남았습니다. 이는 측정한 커밋의 결과이며 현재 수정 레지스트리의 지원 범위와는 구분해야 합니다.
다른 기준으로 하드닝해도 점수가 오르나요?
별도로 새 VM을 만든 뒤 scripts/measure/run.sh -C를 실행했습니다. control.sh가 CIS 기준과 Lynis 제안에 따라 하드닝하고, Hostveil은 점검만 했습니다. 대조군 운영체제는 Ubuntu 24.04.4 LTS이며 측정 시각은 2026-09-11T05:07:49+00:00입니다.
| 측정 항목 | before | controlled |
|---|---|---|
| Hostveil 점수 | 28 | 38 |
| 미조치 발견 | 140 | 126 |
| SSH 영역 | 10 | 59 |
| 계정 영역 | 15 | 30 |
| 파일 권한 영역 | 25 | 50 |
| 커널 영역 | 14 | 27 |
| Lynis 하드닝 지수 | 57 | 62 |
| Lynis 경고 | 4 | 2 |
| Lynis 제안 | 37 | 37 |
| CIS Docker 통과 | 16 | 17 |
| CIS Docker 경고 | 16 | 15 |
| Docker 브리지에서 응답한 포트 | 7 | 2 |
| wildcard·라우팅 가능 수신 포트 | 7 | 7 |
Hostveil의 수정 없이도 SSH·계정·파일 권한·커널 영역 점수가 올랐습니다. Lynis에서는 AUTH-9204, AUTH-9208, CIS에서는 5.26가 해소됐습니다. 방화벽·컨테이너·CVE·에이전트·Docker 데몬 영역 점수는 바뀌지 않았습니다.
대조군에서 외부 응답 포트는 줄었지만, ss에 기록된 wildcard·라우팅 가능 포트 일곱 개는 전후가 같았습니다. 이번 실행에서는 원인을 규명하지 못했습니다. 따라서 외부 응답 감소를 바인딩을 닫았다는 증거로 해석하지 않습니다.
롤백 복원율
| 감시한 경로 | 60 |
| 변경된 경로 | 28 |
| 정확히 복원된 경로 | 25 |
| 롤백한 체크포인트 | 79 |
| 복원율 (%) | 89 |
체크포인트 롤백은 실패 보고 없이 완료됐지만, 호스트 전체가 원래 상태로 돌아온 것은 아닙니다. 수정 전 해시와 일치하지 않은 경로는 /etc/issue, /etc/issue.net, /etc/shadow입니다.
| 경로 | 기록된 원인 |
|---|---|
/etc/shadow | ssh.emptypasswords가 passwd -l로 빈 비밀번호 계정을 잠갔습니다. 복원 체크포인트가 없는 명령 실행입니다. |
/etc/issue, /etc/issue.net | Hostveil이 직접 편집한 내용은 롤백됐지만, updates.disabled의 패키지 설치 과정에서 base-files도 업그레이드돼 배너가 바뀌었습니다. 9월 10일에 dpkg.log로 원인을 확인했고, 9월 11일에는 같은 잔여 상태가 재현됐습니다. 원인 추적을 다시 수행하지는 않았습니다. |
해시는 수정 전에 실제 호스트에서 수집하며 Hostveil의 체크포인트와 비교하는 방식이 아닙니다. 수정 전 상태를 관측하지 못한 경로도 기록돼 있습니다: /usr/bin/x86_64-linux-gnu-as, /usr/bin/x86_64-linux-gnu-as (0755), /usr/bin/x86_64-linux-gnu-ld.bfd, /usr/bin/x86_64-linux-gnu-ld.bfd (0755). 이 경로는 복원 성공의 근거로 셀 수 없습니다.
롤백 후 점수는 32로, 수정 전 28과 다릅니다. 외부에서 응답한 포트는 22, 5432, 6380, 8080, 8096, 9000이고, 커널이 기록한 수신 포트는 22, 5432, 6379, 6380, 8080, 8096, 9000입니다. Redis는 계속 필터링됐고 Portainer의 9000은 새로 응답했습니다. 포트 수가 같아도 같은 포트가 열린 것은 아닙니다. 파일 롤백으로 패키지 설치·계정 잠금·방화벽 명령까지 되돌릴 수는 없습니다.
결과의 한계
이번 실험은 Auto와 Review를 모두 적용했으며 되돌릴 수 없는 조치도 포함합니다. fix --all만 실행한 결과가 아닙니다. 의도적으로 취약하게 만든 호스트에서 모든 영역을 점검했지만, systemd와 프록시 영역은 수정 전부터 100점이었습니다. 모든 영역을 점검했다는 사실이 모든 규칙을 검증했다는 뜻은 아닙니다.
TCP 스캔은 인터넷이 아니라 Docker 브리지에서 시작합니다. 라우팅·필터링·측정 시점에 따라 결과가 달라질 수 있으며 클라우드 보안 그룹이나 모든 네트워크 경로를 검사하지는 않습니다. 대조군의 불일치도 미해결 상태입니다. 이 도구들이 측정하는 것은 설정과 도달 가능성이지 침해 확률이 아닙니다.
9월 10일과 11일의 수정·롤백 실험에서는 점수·발견 수·감사 도구의 변화·복원되지 않은 경로가 같았습니다. 이는 이 구성에서의 반복 측정 결과입니다. 패키지 저장소·이미지·취약점 데이터베이스가 바뀌면 이후 결과도 달라질 수 있습니다. Hostveil 버전 간 비교에는 점수 규칙과 점검 범위의 변화도 반영됩니다.
재현 방법
scripts/measure/Vagrantfile로 폐기 가능한 VM을 사용합니다. 스크립트는 실행 대상 호스트를 의도적으로 취약하게 만든 뒤 수정합니다. 정확한 환경은 위 실행 기록에 있습니다. 수정 실험과 대조군 실험은 각각 새 VM에서 시작해야 합니다.
# Inside the first disposable VM, using the recorded source commit:
sudo scripts/measure/seed.sh
sudo scripts/measure/run.sh -c -p cisc-w2026-seeded-v2 /tmp/fixes.json
# Inside a separate, freshly provisioned disposable VM:
sudo scripts/measure/seed.sh
sudo scripts/measure/run.sh -c -C -p cisc-w2026-control-v2 /tmp/control.json두 실행 모두 check.py를 통과했습니다. 이 검사는 되돌릴 수 없는 Review 조치가 있으면 잔여 변경을 허용하므로, 종료 코드 0이 파일 복원율 100%를 뜻하지는 않습니다. 웹사이트 수치는 공개 기준인 원본 실행과 대조하며, 대조군 수치는 별도로 지정한 원본 파일과 대조합니다.