050. Linux 서버 보안 — 종합 하드닝 점검 시나리오 — 점검부터 관제 등록까지

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

선행 학습

• 049. 실전 시나리오 — 하드닝 해제 후 침해 시도 타임라인
• 001. 기본 보안 점검 항목과 하드닝 로드맵
• 50. Linux 시스템 침해사고 종합 분석 실습

1. 개념

049편이 "무너진 서버를 분석하는" 시나리오였다면, 이 편은 반대로 새 서버를 관제 가능한 상태로 만드는 시나리오입니다. A영역 50편 전체를 한 번에 적용하는 운영 절차입니다.

[신규 서버 투입 절차 — 실습 예시]

① 1차 점검        001 5축 triage, 041~043 자동 점검(OpenSCAP·Lynis)
      ↓
② 조치            계정·sudo·SSH(003~012) → 서비스·포트·방화벽(013~016)
                  → MAC·파일시스템·커널(017~023, 035~036) → 패치·무결성(024~025)
                  → 예약작업·systemd(026~027)
      ↓
③ 로그·감사 구성  journald·rsyslog 원격 전송(028~029), auditd 정책·불변(030~031), 시간 동기화(032)
      ↓
④ 검증            재점검(OpenSCAP·자체 점검 044) → FAIL 0 또는 예외 문서화
      ↓
⑤ 기준선 저장      002 방식 + 외부 사본
      ↓
⑥ 관제 등록        Wazuh 에이전트·SCA(045), 룰셋(047), 대시보드(046), 수신 공백 감시
      ↓
⑦ 운영            드리프트 분류(037), 변경 추적(038), 정탐·오탐 판단(048)

2. 왜 중요한가

• 하드닝과 관제는 따로 존재하지 않습니다. 조치(②) 없이 관제(⑥)만 하면 볼 것이 너무 많고, 관제 없이 조치만 하면 무너지는 것을 모릅니다.
• ③ 로그·감사 구성이 ⑥ 관제보다 먼저 와야 합니다. 로그가 없으면 등록해도 탐지할 수 없습니다.
• ④ 검증과 ⑤ 기준선이 있어야 이후 모든 변화(드리프트, 침해)를 "기준 대비 차이"로 설명할 수 있습니다.

3. 핵심 명령어 / 설정

종합 체크리스트 (재사용 템플릿)

영역	점검 항목	기대값	편
계정	root 외 UID 0 / 빈 패스워드 / 서비스 계정 셸	없음 / 없음 / nologin	003
권한	주요 파일 권한 매트릭스, umask	기대값 일치, 022~027	004·005
sudo	NOPASSWD:ALL·와일드카드 없음, 로깅 설정	없음 / logfile·log_output	006·007
SSH	root 로그인, password 인증, AllowGroups, 한도	no / no / 설정됨 / 3·30	008~012
서비스·포트	역할 외 서비스, 포트 기준선	없음 / 일치	013·014·040
방화벽	zone 설계, 런타임=영구, firewalld 외 규칙	적용 / 일치 / 없음	015·016
MAC	SELinux / AppArmor	Enforcing / enforce	017·018
파일시스템	/tmp·/var/tmp·/dev/shm 옵션	nodev,nosuid,noexec	019·020
커널	보안 sysctl, 네트워크 sysctl, core_pattern, 모듈 차단	기대값, ip_forward 0	022·023·035·036
패치·무결성	보안 업데이트, 재부팅 필요, 바이너리 검증	0 / 불필요 / 변경 없음	024·025
예약작업	cron.allow, 사용자 crontab	관리 계정만	026
로그	journald persistent, rsyslog 원격, 시간 동기화	적용 / ESTAB / synchronized	028·029·032
감사	감사 정책 규칙, enabled, lost	정책 일치 / 2 / 0	030·031
관제	에이전트, SCA, 수신 공백 감시	active / 등록 / 운영	045~047

4. 실습 (실습 예시)

실습 예시: 투입 전 최종 검증 묶음

# 044편 자체 점검 + 042편 OpenSCAP + 핵심 상태 요약
sudo systemctl start hardening-check.service
journalctl -t hardening-check -n 10 --no-pager | grep -E 'FAIL|summary'

sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results /root/go-live-results.xml --report /root/go-live-report.html "$DS" >/dev/null
grep -o 'result>fail<' /root/go-live-results.xml | wc -l

# 관제 연결 확인
systemctl is-active wazuh-agent
sudo grep -i 'Connected to the server' /var/ossec/logs/ossec.log | tail -1
logger -p authpriv.notice "GO-LIVE-TEST $(hostname) $(date +%F)"   # SIEM에서 수신 확인

# 기준선 저장 (002편) + 외부 사본
sudo /usr/local/sbin/baseline-collect.sh && sudo rsync -a /root/baseline/ backup01:/baseline/$(hostname)/

baseline-collect.sh, backup01은 002편의 수집 명령을 스크립트로 묶고 외부 저장소로 보내는 구성을 가정한 예시 이름입니다.

5. 정상 상태

[투입 판정 — 실습 예시]
자체 점검        : summary result=PASS (6/6)
OpenSCAP CIS L1  : fail 3 → 3건 모두 예외 승인(EXC-2026-011~013)
Lynis            : warning 0
관제             : agent active, SCA 등록, GO-LIVE-TEST 수신 확인(지연 2초)
기준선           : 2026-10-01 저장, 외부 사본 해시 일치
판정             : 투입 승인

6. 이상 상태

투입을 보류해야 하는 결과 예시입니다.

자체 점검        : audit_enabled expected=2 actual=1 result=FAIL
OpenSCAP CIS L1  : fail 17 (예외 승인 3, 미조치 14)
관제             : GO-LIVE-TEST 미수신 → rsyslog 원격 전송 미구성
판정             : 보류 — 감사 불변 모드·로그 원격 전송 없이 투입하면 049편과 같은 사고 시 재구성 불가

특히 로그·감사(③)와 관제 연결(⑥)이 실패한 서버는 투입하지 않는다는 원칙을 세워 두는 것이 중요합니다.

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

투입 이후 첫 주의 관제 로그는 "기준선 대비 변화"로 읽습니다(분석 방법).

[투입 후 7일 요약 — 실습 예시]
하드닝 FAIL 전환       : 0
설정 변경 Alert        : 12건 (전부 CHG 티켓 매칭, 정상 행위)
신규 리스닝 포트       : 0
로그 수신 공백         : 0분
SCA passed→failed     : 0

이 요약이 매주 쌓이면 서버별 정상 운영 패턴이 되고, 049편 같은 사고는 이 패턴에서 벗어나는 순간 드러납니다.

8. SOC 관제 포인트

• 신규 서버 투입 절차에 로그·감사·관제 연결 확인을 필수 관문으로 둡니다.
• 체크리스트 결과와 예외 승인 내역을 기준선과 함께 보관합니다.
• 투입 후 첫 주 요약을 기준으로 서버별 정상 패턴을 정의합니다.

9. 탐지 규칙

A영역 탐지 체계를 한 장으로 정리하면 다음과 같습니다.

          [예방]                          [탐지]                          [대응]
  하드닝 조치(003~036)        auditd·FIM·SCA·점검 로그(030~045)      판단(048) → 사고 대응(049)
          ↓                              ↓                                ↑
     기준선(002)  ── 차이 ──→  룰셋(047) → SIEM 상관·대시보드(046) ──────┘
          ↑                                                                │
          └──────────────── 재발 방지: 기준선 갱신·룰 튜닝 ←───────────────┘

다음 B영역 「계정 · 인증 보안 강화」에서는 이 구조 중 계정·인증 축을 깊게 다룹니다. A영역에서 설정한 PAM·SSH·sudo가 실제 로그인·실패·잠금·권한 상승 로그로 어떻게 나타나는지, 그리고 이를 brute-force·이상 로그인·계정 탈취 탐지로 연결합니다.

10. 대응 방법

1. 초기 확인 — 투입 대상 서버에 체크리스트 전 항목을 점검하고 FAIL을 목록화합니다.
2. 범위 확인 — 같은 이미지로 만든 서버들의 공통 FAIL을 확인해 이미지 수준에서 수정합니다.
3. 증거 확보 — 점검 결과, 예외 승인, 기준선, 관제 연결 확인 기록을 투입 기록으로 보관합니다.
4. 차단/조치 — FAIL 조치 또는 예외 승인 후 재점검하고, 로그·감사·관제 실패 시 투입을 보류합니다.
5. 재발 방지 — 투입 절차를 표준 문서로 만들고 주간 변화 요약으로 운영 패턴을 관리합니다.

11. 핵심 정리

단계	핵심 내용
점검·조치	계정 → SSH → 서비스·방화벽 → MAC·커널 → 패치·무결성 → 예약작업
로그·감사	journald·rsyslog 원격, auditd 정책·불변, 시간 동기화
검증·기준선	재점검 FAIL 0 또는 예외 문서화, 외부 사본
관제 등록	에이전트·SCA·룰셋·대시보드·수신 공백 감시
면접 포인트	"로그·감사·관제 연결이 안 된 서버는 투입하지 않는다"

12. 다음 편 예고

A영역 「Linux 서버 보안 설정」 50편을 마칩니다. 다음은 B영역 051. 계정 · 인증 보안 — Linux 사용자 계정 구조와 인증 흐름 전체 지도 로 이어지며, 로그인·인증 로그를 중심으로 계정 탈취와 권한 상승 탐지를 다룹니다.

---

이전 편: 049. Linux 서버 보안 — 실전 시나리오 — 하드닝 해제 후 침해 시도 타임라인
📚 시리즈 전체 보기: 시스템 보안 · 취약점